成本治理-存储治理

中台 数据  收藏
0 / 285

引言

在社交电商时代,业务发展飞速,数据技术及时响应业务,也落下很多债务。对此,大数据部门在19年的时候发起了一系列的数据项目。

以下我会分几篇文章来梳理所做的事和分享已经带来的收益。

背景

在做数据开发的过程中主要涉及数据产生,数据采集,数据生产,数据存储,数据应用,数据销毁这些环节,这些环节都会带来熵增。主要表现以下问题,质量,成本,效率,安全几大问题。

null

image.png

贝贝数据也在这些方面遇到了很大的问题。

数据治理策略

null

治理是一个跨部门协同的大项目,其实施的周期长,涉及的人员多,我们在治理的过程中组建了数据治理专项小组,涉及数据开发,BI,风控,算法,数据平台,业务开发,产品经理,运营等主要同学,并每个部门都有一个对口人,让各部门同学都参与进来。

存储治理

后续我会从质量治理,成本治理,效率治理,安全治理等角度分享我们做的一些工作,同时也欢迎大家交流。

本篇主要分享从接口、报表、任务孤岛、生命周期、存储分布,hive 元数据,存储压缩,数据接入等角度切入存储治理的过程。

贝贝存储的基本情况,每月增长 1PB,且增长的速度越来越快。如果不进行治理,那么未来半年存储就不够用。

null

接口治理

接口治理是直接面向业务,数据产品的。好在我们有 OneService 服务,把接口的使用情况,业务方,接口人等元数据都有采集。针对在一定时间内(90天,30天)没有被调用的接口清单,我们给到对应的业务接口人,确认该数据功能是否还有必要。

一期下线 152 个 90 天内无访问,下线 20 个

null

null

报表治理

null

结合星云星空数据产品,根据业务方,最近使用情况进行治理,一期下线 28 张报表。

任务孤岛治理

null

接口治理、报表治理完,也会多出应用层任务孤岛。梳理应用层跟数据产品的元数据。

对没有下游的任务直接降级下线。

生命周期治理

任务不能只上不下,存储也不能只存不删。

对于数仓各层都需要指定合理的生命周期。对于这块,我们执行分层大保障,单表个性化的思路。分析现阶段每层的生命周期,梳理现阶段情况下每层的存储占比和每层的作用,反推设置生命周期的合理性。

null

也正是通过对存储根目录,存储数据库、表和每日新增的纬度分析,我们发现 1%的大表占用了 90% 现阶段的存储资源,马太效应十分明显。

大表治理

重点治理大表,缩减大表的生命周期。

null

元数据修复

在对表级别每日新增GAP分析时,发现一些表每日新增大小接近完整的一天大小,判断是过期的分期未能及时删除。

经排查系上云过程中hive元数据有问题,且这是一个较为普遍的问题。

所以写了脚本批量修复所有表的hive元数据问题。光这个操作,涉及519张表,修复1592个分区元数据,整体存储就下降了 2% 左右。

null

null

存储压缩

null

textfile 是以文本形式存储的,是对存储资源的极大浪费。上图14.5G每天的大小是 textfile 格式存储的,353M是 orc 格式存储的,在对这个模型的存储效率上约缩小为原来的1/42。

数据开发平台也是开放给各业务方,包括业务开发,风控,BI等团队。早期数据开发也比较粗放式,没有好的规范,这些团队的任务有较多使用 textfile 形式。我们梳理出存储方式是 textfile 且存储占用在 top 50 任务,进行突击改善。这个阶段,存储也节省了整体占比的3%以上。同时 orc 是列式存储,对计算查询都有明显的效率提升。

数据接入治理

数据接入的质量关系后续数据流的整个质量,原来较多任务都是全量接入,费时费力。在做这块的时候,我们划分了2道线,接入时间在 15 分钟以上,接入数据量在 5000万行以上的。

对以上两种情况的数据接入进行重点改造成增量接入,同时关注串行,串列,关键字,字段注释的完整性。同时也率先将标准规范落地成工具产品 OneClick。保证接入规范,基础数据在 1 点前就位,核心基础数据在 0:30 前就位。

效果

存储的治理下来,整体的存储资源利用率从75%降为60%。我们确定的发现这是一个长期的事情,应该成为数据开发的日常工作的一部分。

展望

治理的过程包括被动治理,主动治理,智能治理,现阶段贝贝存储治理也在第二第三阶段进行中。我们试图通过收集的元数据在个人,部门等不同纬度量化存储情况,提出了存储分。观察的指标有存储格式,存储大小,生命周期,下游任务数等。并在数据门户提供可视化面板,打通告警系统,将存储治理融入到日常数据开发的过程中去。