数据治理体系建设实践

2023-04-09 17:52 浏览量:234

导读 随着大数据的不断发展,数据量越来越大,处理方式越来越丰富,跨部门或者跨业务线的数据可能会造成数据孤岛,对整个公司的数据分析带来很大阻力,所以需要引入数据治理来提高数据处理效率。

今天的介绍会围绕下面四点展开:

1. 问题与挑战

2. 思考与定位

3. 方案与实施

4. 总结与规划

 

 

01

问题与挑战
 

DataCake 拥有庞大的资产体量。此外,对于我们来说,大业务部门比较多,而且相对比较独立,比如商业化、内容电商等等。每个大业务线都有自己的数据开发团队,通过自己的一个体系管理自己的数据和任务。

以治理的视角,深入到各个业务当中,我们就会发现有几个比较典型的问题。

① 首先是数据孤岛,如果要跨业务去取数,首先要知道从哪个业务线可以取到,如果很幸运的找到了,可能还要通过去查一些他们的维护文档才能得到,还可能这个信息并不置信,整个过程中的沟通成本很高。最后很可能决定自己来搞,就会造成数据的冗余存储,间接的也会造成成本的浪费。

② 第二个问题是数据治理无从下手,工具差异化比较严重,有脚本、开源工具等等,并且理解不一致,很难达成共识。

③ 第三个问题,成本是一笔糊涂账。账单标签混乱,宏观难量化,也没有能力去探查到细粒度的细节。

我们切换到不同的视角来去审视这样的一个问题。

假如你是一个 manager,如果没有一个数据资产报告和一个清晰的账目,那么可能很难去决策要不要做数据治理,或者做数据治理能否达到预期的收益。如果你是一个开发者,你可能要进行大量的沟通和确认,最后决定要不要下线任务和表。假如你是一个算法工程师,你可能对任务的优化并不在行。反复试错,或者是找别人去帮忙。如果你是一个治理运营者,没有一个一以贯之的量化体系并做阶段性的跟踪回顾,很容易让数治理动作走样。因为治理动作从发起到落地,其执行单元会逐渐发散,最后很可能会失败。

因此,如何建立一个数据治理的体系,把各个业务线的局部解法转变成一个全局最优解,是我们当前面临的核心问题和挑战。

02

思考与定位

在对上面的问题与挑战进行深入剖析之后,我们就开启了数据治理的建设之路。在环视传统和非传统企业治理思路的过程中,我们发现大家对于治理之道上有普遍的共识,通过不同的策略和标准来提高组织的数据可用性、质量、安全等等。但是在治理之术上,每家企业结合自己的不同背景,走的路不太一样,侧重点也不相同。可以用一个词来形容——因地制宜。

企业在数据治理的起步阶段,一般都是在于制度和工具。由于团队刚成立,还在发展初期,以组织的形式去出台政策和规范,切入到业务当中,其实很难推进下去,并且短期也没有实质性的收益。所以,我们结合用户当前的一些实际痛点,还有以往我们参与治理过程中沉淀出来的方法论经验,集中精力在平台建设上逐渐去完善元数据的观测、成本分析治理的实施这样一个闭环体系。因此我们制定了第一愿景,就是让数据的参与者心里有数,让他们能够自管自控。

落到具体的目标,首先就是构建统一的元数据管理平台。我们统一地去采集、观测、维护元数据,消除各个大业务线下文档管理口口相传这种非标准流程。同时,还要做一个统一的治理工作平台,门槛一定要很低,使用起来要很方便,要一键化、智能化、辅助化。我们也要建立一个成本的分析工具,让不同的角色都能够清清楚楚地把账算明白。比如对于开发人员来说,他日常涉及到的开发的任务和表,要做到最细粒度的核算。最后我们要构建一个全局的资产盘点平台,把治理的动作分门别类,分而治之。无论是 manager 还是开发人员,又或是运维人员,都能够对资产有一个整体的把握。

03

方案与实施

首先我们的整体资源是在一个混合云之上,包括云计算资源,还有存储资源。基础设施层面主要是为上游数据的上报和流转提供技术支撑。平台和工具层面主要是接入各方数据。这里面的 DE,是 DataCake 下边的一个任务管理模块。数据采集层负责将各类的信息收集和加工,并且将过程中的数据放入到平台数仓层,同时平台数仓层会把数据定时同步到数据应用层。数据应用层和元数据中间件会直接与 backend 进行对接,实现元数据的管理和展示。后端划分为源数据、权限、成本、存储任务等几个模块,用于支撑上层的应用场景。

1. 元数据管理模块

对于元数据管理,我们会对元数据范围做一个定义,这里划分了技术元数据、业务元数据和操作元数据。技术元数据又细分成了存储元数据、计算任务元数据、质量元数据、成本元数据以及安全元数据。

元数据管理平台对数据资产具有很强的描述能力,比如综合描述存储的 region,还有存储信息、产出的来源、字段信息、血缘关系等等,比较全面。同时平台还提供了一些标签进行展示,比如访问热度、存储量,让用户有一个更直观的印象。如果对某些表感兴趣,还可以收藏关注。

2. 治理工具模块

治理工作台模块,主要是面向两个场景去做治理,一个是计算的任务,第二个是云存储上的表。对于计算任务,平台主要是针对 Spark 的任务进行优化,比如提高它的资源使用率,解决它的数据倾斜,降低它的报错频率。提高资源使用率往往有两种手段,一个是优化代码逻辑,另一个就是参数的调优。对于开发者来说,一般都是多角色的,有数据分析师、算法工程师等等,他们的参数调优能力都参差不齐,因此要思考如何更好地服务用户,降低使用的门槛。

我们打通了治理工作台和任务管理模块,实现了一键发布,这样就不需要多端操作了。我们也引入了策略和 AI 模型的方式,实现了智能化的推荐、配置推荐。还有在 Spark 任务的运行指标上,我们也做了一定的采集和披露,来辅助用户决策如何优化。

在存储治理方面,我们的数据一般是存在 S3 和 OBS。云存储的特点是,有比较多样的存储策略,带来的优化手段也不太一样。我们的优化手段是调整存储策略,比如是标准存储还是智能分层,冷冻还是深度冷冻等等。另外就是物理删除,以及合并小文件。对于优化策略,理想的状态是千表千面。每一个表根据其实际使用频率,还有场景定制不同,分开去配置。但我们也是受到了云存储的一些条件约束,它单个桶下的配类策略的配置其实是有上限的,千表千面的配置显然是太大了,这也是我们接下来要着重思考去解决的。

上图展示的是计算任务的工作台,用户可以通过检索筛选出异常任务。根据任务披露出来的信息,比如运行状况、资源使用率、报错的频率等等进行优化。这里面有一些披露的任务标签,比如数据是否倾斜,使用率高低,评价高低等等,可以更友好地服务于用户优化。优化动作一旦触发,平台就会根据优化前后的效果进行全流程的跟踪。在治理记录中有治理策略,如果治理策略里面展示的是推荐配置,就说明用户当时是根据平台推荐的配置一键发布出去的,如果是自定义的,说明用户有更好的优化想法,自主去优化的。

3. 成本分析模块

成本分析模块,我们建立了一套完整的成本加工链路。对于云上资源来说,要是想把精细化管理到任务和表最细的粒度,并不容易,因为受安全合规敏感数据方面的约束,云商给出的账单的粒度往往都很粗,比如集群维度、机型维度、区域维度、桶粒度等。通过成本信息数据链路的搭建,我们把表和任务最细粒度和成本挂勾,并且和 owner 挂勾,这样才能做到真正的精细化管控。同时我们也建立了一套成本分摊制度。比如一个数据开发工程师,如果同时要为 a 部门和 b 部门两个业务线的部门去做开发任务,就可以把计算的成本分摊给两个部门。

至此,已经可以看出,从最初各个业务线分而治之,逐渐变成了跨部门合作。

成本分析的效果图如上图所示,会对账单进行一个汇总,还有按模块的分类汇总和成本的波动。用户在 DataCake 上做的一些 SQL 查询,还有数据开发、任务开发等等,都可以算到成本中心当中。成本分析页面维度也非常丰富,囊括了数据开发者所有工作中的场景,同时还支持按组、owner、任务标签等维度进行统计,目前基本满足了用户日常的分析场景。其中有一个是相关成本和非相关相成,也就是根据前文中提到的分摊制度计算的,也可以理解为直接成本和间接成本。

4. 资产盘点模块

了解了以上 3 个功能模块之后,我们至此就拥有了完备的元数据的可观测能力,自动化的治理工具,以及成本的分析工具。接下来我们要把这几个功能矩阵连接起来,打造出一个治理闭环,让用户真正能够做到自管自控。

我们在存储和计算上面定义了一些指标。比如存储方面,对于 30 天无访问的表,平台会提示 owner 下线或配置生命周期。对于无存储策略的,平台会做一个策略的推荐。对于无人认领的,就会交给平台自己处理,我们一般就会先禁止读写一到两周,然后再物理删除,或是把读写分开来做,缩小影响面。重复映射指的是有一些重复表映射到相同的 location,这种情况对于数据治理存在很大的干扰,平台也会把这些信息盘点出来,让用户进行消减。

计算方面的治理项,首先做到了实例级的信息上报,并且会有相应的场景做推荐配置。对于大表的任务,平台会提醒用户进行下线和代码优化。对于非法的任务,平台会识别并统一做线下的处理,比如任务 owner 已经离职了,或者是任务在线的状态是已下线,实际上还在上报自己的信息,就是一个僵尸任务。对于评分低,平台围绕一些指标,做了一套评价体系,并且围绕着低分,会定时对 owner 进行告警,push 他们去做优化。相应地,也会有一些什么红黑榜、治理小达人等比较有趣的排名,目的也是为了调动大家的治理积极性。

在分析页面,可以看到按照不同的分组进行了治理项的统计。不同部门的 leader 可以根据自己筛选的结果制定治理计划,并且进行任务的下推。整个过程平台会对数据进行打标和跟踪。

04

总结与规划

当前 DataCake 的数据治理从具备了资产的可观测能力,到具备了一键的治理能力,再到具备了成本的追踪能力,最后到了拥有了治理的运营能力。目前累计有 60% 的员工参与到了常态化的治理当中,从而使计算的资源使用率累计提升了 25%,云存储总计释放了 3.5 个 PB。

未来我们也会向后看和向前看。向后看,我们会持续的去打磨我们现有的产品功能,同时提升用户体验;向前看我们会借鉴业界的治理思路来打磨我们的产品。

05

问答环节

Q1:有没有评价体系来衡量治理的效果?

A1:对一个单任务来说,对这个任务是有一个评价分的,这个评价分来自于它的历史执行状态。一个指标上报的统计,比如治理完了之后,和原来比 CPU 使用率,内存紧密提升等因素去表达一个任务的治理效果。从总体治理效果来看,比如作为一个 leader,他在资产盘点里面做一个治理项目的圈定,做任务下推过程中,比如对于计算任务来说,从成本上能够看到它历史到现在的一个成本波动,做完治理之后是否有下降。对于计算任务的使用率,资源使用率来说,同样也有一个历史到现在的跟踪,看一看体现出来的收益。对于存储来说,也可以回归到账单层面,去看看这一圈定出来的治理动作,成本有没有下降。

Q2:治理项执行怎么推进?

A2:我们让用户回归到任务成本上,让他对这个任务的成本有感知。我们会有一些排名,激发用户在数据治理上的响应程度。对于一些成本治理的成本,管控部门也会来找开发人员进行治理。

Q3:基于云原生的数据治理主要的难点有哪些?

A3:基于云原生的难点主要还是成本,因为我们的数据主要是在华为云,还有 AWS。对两边云,他们出的账单粒度很粗,我们要给它掰到最细,怎么掰对于我们来说是最难的。这个过程中,我们会搭建一个数据的链路,先把数据按比如计算任务来分,每次在节点上执行的时候,都会分钟级上报它自己的信息,比如所在的机型、机型的单价,以及整体的运行时长等等。我们会把这些数据整合到一起去,最后拿着数据再去和云商的账单核对。对不上就会有一定的 gap 率,比如 gap 率 5%,我们就会把这 gap 5% 去以运行时长或者是资源使用率的占比情况分摊给各个任务,其实也是在做一个最大化的公平权衡。

Q4:血缘分析如何做到完整链路的拓扑分析?

A4:血缘拓扑分析主要是看你的意图,如果是想站在治理的角度去想,看你的表是不是想下线,可以来到 catalog 元信息管理里面,去看它的下级的分层里面如果有群数据的依赖,同时还有下游的依赖,同时下游还有访问,并且访问人有很多,这样你会有一个直观的感受,表是有价值的,不能下线。其实数据血缘的价值之一就是让你能有一个直观的感受,清晰明了,能表达出来数据是否有价值。

Q5:数据治理的流程是如何闭环的?

A5:可以倒着思考如何去闭环。首先第一个问题一定是成本,成本很高,你一定想知道是哪块高,就需要有一个成本分析工具。有了一个成本的分析工具之后,就要去做一个细粒度的观测,其实也就是对元数据的观测。从后往前推,观测完了之后,紧接着你下一个动作一定是想进行治理,需要一个数据治理的工具。这样就能把整个流程串起来。

Q6:收入成本如何控制到任务力度?

A6:比如计算任务,一旦提交到集群上,节点的任务就会把信息上报到监控平台里面。下游的 Flink 任务,实时地去消费监控系统的数据,把数据进行汇总。汇总之后,会有任务在从开始到结束的运行时长,还有它跑在了哪些机型,以及不同机型对应的单价。拿到这些信息之后,我们再去和云商的账单去做一个比对,会有 gap,我们会找一个平衡点,按照整个集群上的任务用量的占比情况,做一个划分,划分到各个任务上去。

 

来源:DataFunSummit 

作者:夏日

上一篇:龙石数据入选中国信通院数字政府产业图谱,赋能数字政府建设

下一篇:数据治理要治理那些数据、又要怎么做

  • 分享:
龙石数据
咨询电话: 0512-87811036,18013092598
联系我们
商务联系微信

商务联系微信

0512-87811036,

18013092598

咨询电话