数据治理体系建设实践

01

问题与挑战
 

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

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

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

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

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

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

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

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

02

思考与定位

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

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

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

03

方案与实施

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

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

元数据管理平台对数据资产具有很强的描述能力，比如综合描述存储的 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 

作者：夏日