一、滴滴大数据成本治理总体框架

1、滴滴数据体系

在介绍滴滴成本治理之前，首先来简单介绍一下滴滴的数据体系。

最底层是以数据引擎为基础的数据存储，分为离线计算、实时计算、OLAP、no SQL、日志检索和数据通道六个部分。

在数据计算层，滴滴自研了一站式数据开发平台——“数据梦工厂”，主要包含离线开发、实时开发、任务调度、同步中心等一系列开发组件。数仓的同学和数据分析同学利用数据梦工厂进行数据的清洗与加工，构建其各自业务线的数据仓库。

在数据服务层，滴滴自研了一站式数据应用消费平台——“数易”，用来满足各类看数、取数、用数的场景。

最上层，数据科学的同学利用已加工好的数据进行决策支持、业务分析和数据挖掘等算法类场景的工作。

管理整套的数据体系，是通过以“元数据”为中心建设的两个产品，“数据地图”和“资产管理平台”。

治理工作，围绕五个核心方向展开，分别是成本、安全、质量、模型和价值。去年整个团队的工作重心，主要围绕数据安全方面。今年的重心则是成本治理。接下来，对成本治理方面的工作实践进行介绍。

2、滴滴大数据资产管理平台

滴滴大数据资产管理平台主要以六个分数来衡量使用数据的“好”与“坏”，分别为计算健康分、存储健康分、安全健康分、质量健康分、模型健康分和价值健康分。根据这六个维度分数的几何平均，算出一个总分 DataRank 分，来衡量总体使用数据“好”与“坏”的程度。成本治理主要是提升计算健康分和存储健康分。

使用大数据资产管理平台进行成本管理，主要是对引擎（Hadoop、ES、Flink、Click House、Kafka、Hbase），和以“数据梦工厂”和“数易“为核心的两个数据中台产品，提供成本计费、账单分析和成本治理相关能力。

3、滴滴大数据成本治理总体框架

滴滴的“资产管理平台”于 2019 年初上线，当时只提供了 Hadoop 计算和存储的两种治理能力。在上线之前，整个集团的 Hadoop 存储量，以一条缓慢上涨的曲线，逐渐增长。平台上线之后，这条曲线逐渐拉平，说明通过治理的动作，抵消了业务增长带来的用量上涨。这个阶段称为治理 1.0 阶段。随着平台的发展，我们遇到两个问题，第一个问题是越来越难找出相对容易的治理项；第二个问题是治理工作的成果和价值，很难被说清楚。所以常被业务质疑，也影响了同学们治理的积极性。所以我们在 2022 年投入精力做定价，再做成本看清，再进行成本治理能力的建设，这就是成本治理 2.0 阶段。

一个产品的硬件成本主要来自于三大方面：服务器、网络和该产品所使用的中间件资源（比如 MySQL、MQ 等）。此外，还有维护该产品，所消耗的人力维护成本，这四大块构成了产品的总成本。有了产品的总成本，要看这个产品今年需要达到的利润目标，是达到收支平衡即可，还是要有要留有一定的利润空间。将成本乘以（1+ 利润率），就可以预估出产品的预计总收入。随后要对产品收入进行拆分，确定通过哪些定价项来收费。拆分定价项的难点是，需要预估该产品今年的总用量。预估过大会造成成本损失，预估过小则会造成利润损失。

有了产品定价，便可开展成本看清的能力建设。底层来源于元数据，主要分为存储元数据和计算元数据两块。存储元数据基本为各个引擎的 Metastore。计算元数据基本来源于各个引擎运行时的日志。将拿到的元数据同步至离线数仓，进行清洗加工处理。

最终在 app 层，形成计算、存储、安全、质量、模型、价值 6 个数据域。其中与成本相关的是计算和存储两部分。将所消耗的计算和存储的明细按个人、项目、组织、账户四个维度进行汇总，可看到这四个维度下具体的用量情况。对这些数据进行汇总，可得到财务结算的账单，对账单进行下钻分析可发现异动点。

用户的成本等于单价*用量。单价是引擎测算得出的，用量是用户实际使用的。对单价治理，需要引擎层进行技术优化。对用量治理，需要用户开展治理工作。

引擎的优化主要分为计算和存储。计算方面，主要为通过各种技术手段提升 CPU 的利用率，包括峰值和均值，或通过混部的技术来更多地压榨机器资源。存储治理，一般是将冷热数据分区存储，因为冷数据的单价比热数据更低。同时可以引入一些压缩技术，将数据进行压缩存储。

用户做治理的前提是要有一套完善的用量管控的逻辑。滴滴内部有两套逻辑，第一个是按账户进行拆分，该拆分逻辑主要用于财务结算。另一个是按组织架构进行拆分，该拆分逻辑主要用于追踪和跟进成本治理的进度与目标，其优势是便于找到相关的接口人。同时，由于组织架构存在上下级的汇报关系，可使得成本治理工作的推动更加顺畅。

按账户拆分，一个成本账户会有多个项目，需要做一个换算，把真正使用的预算金额换算成每个项目具体可以用的总体用量，再对每个项目的用量进行管控，如果项目用量超出规划用量，则需先治理再申请额外用量。遇到特殊情况，比如某一业务非常重要，没有时间做治理，那么走较高层级的审批，审批通过之后才可以放开继续用量申请。

用户治理具体分为两块，一是“资产管理平台”要做的事，二是用户要做的事。

“资产管理平台”需要找出更多可被用户治理的资源。首先需要接入各类元数据，主要包括运行时的信息、资源的基础信息、血缘信息和访问信息。运行时的信息，主要为各个引擎的运行时日志、审计日志和 GC 日志等。资源的基础信息，为该资源的创建人、创建时间、所属项目等。血缘信息和访问信息，是判断下游是否有访问，可以被删除的重要依据。平台在离线层计算出可以被治理的资源，主要分为“存储待治理资源”和“计算待治理资源”，将这些待治理的资源进行打包，形成治理工单，推送给用户。

用户根据今年的预算目标和治理目标，对治理工单确定治理节奏，并可查看治理的收益。

二、Hadoop 成本治理实践

Hadoop 的定价主要参考四个维度，第一个是 Hadoop 的历史单价，第二个是服务器效率优化目标，第三个是预估当年 Hadoop 所需用量，第四个是期望利润。基于这四个维度，将定价项拆分为计算和存储两块。存储定价项，分为常规存储、冷存储和文件数；计算定价项，为任务运行时消耗的核数*运行时长。确定 Hadoop 定价项之后，开展看清成本的能力建设。

最底层也是需要接入 Hadoop 的元数据。存储元数据主要来自于 Metastore 和 FSimage，两者记录了表及路径的详细信息。计算元数据主要来源于各类日志，详细记录了任务运行时的各类状态。将存储和计算元数据同步到 ODS 层，进行清洗加工，形成计算和存储两个数据域。再对其按个人、项目、组织、账户四个维度进行汇总。汇总后的数据，形成财务结算的账单，对其进行下钻分析，可知晓 Hadoop 的费用具体消耗在哪些计算任务与存储上。同时可看清所消耗的费用和用量的具体值及环比，以及待节省的空间。

滴滴内部将 Hadoop 可被治理的资产，分为“无效资产”和“有效资产”。“无效资产”是指这些数据资产确定不会被使用，但可能由于没有被关注，仍然存放在那里，占用额外的存储与计算资源。“有效资产”是指这些资源还在被用户使用，只是使用的效率较低，需要对其进行优化。

对“无效资产”进行治理，底层接入四类日志，Hadoop 审计日志，Spark 审计日志，任务 GC 日志，HDFS 审计日志。将这些日志同步到 ODS 层进行清洗、加工和解析，可得到“存储待治理推荐项”和“计算待治理推荐项”。“存储待治理推荐项”主要有生命周期调整、空表空路径和无效访问等。“计算待治理推荐项”主要有数据倾斜、暴力扫描，参数不合理、高耗任务和无效计算等。

有效资产治理主要包括两方面，第一方面是重复模型的治理，主要依赖于字段血源的能力。第二方面是全量小时分区表的改造。由于历史原因，当时业务需要按小时来建立分区，可随着业务的发展，原先的需求已经不存在。将其改造成按天调度的表，可节省 23 倍的资源，收益非常大。“无效资产”的治理需要依赖用户的配合，将计算出的待治理资源形成治理工单，通过『治理工作台』分发给治理用户，通过工单流转方式来完成治理动作。

针对数据倾斜这一治理项，需要两类引擎日志：Spark 执行日志和 Hadoop 执行日志。对这两类日志进行解析，得到三个指标，task 运行时的时长，task 处理的数据条数，task 处理的数据字节大小。对三个指标进行计算，计算公式：所有 task 运行的最大值除以所有 task 运行的中位数，可分别得到三个倾斜率。这三个倾斜率，赋予不同的权重就可以得到该任务的倾斜率。根据倾斜率可以判断任务是否发生了数据倾斜。判断条件是所有 task 运行的最大时间大于 15 分钟，且计算出的执行时间倾斜率大于 5。同时满足这两个条件，认为任务发生了数据倾斜。

解决数据倾斜一般有三种方案。第一种，造成数据倾斜的原因是数据分布不均匀，比如存在热点 k，空值比较多的情况。解决的方法就是将热点 k，尤其是空值提前进行处理，比如排除，或者用随机k代替空值。第二种，发生数据倾斜的原因是大表 join 小表，造成k的分布不均。解决方案之一是用 MAPJOIN 将小表广播；另外，也可以适当增加并发度，比如通过 REPARTITION 进行重新分区。还有其它一些解决数据倾斜的方案，主要是参数调整，针对的是数据倾斜不太严重的情况，比如调整广播的大小，或者是对内存进行调适。

针对参数不合理这一治理项，如运行的 Spark 或者 Hadoop 任务，用户需要设置相关参数，如何判断用户设置的参数是否合理，我们总结出一套参数推荐的规则。首先拉取该任务运行时 GC 日志，对 GC 日志进行解析，解析后对特征进行匹配，特征主要是 GC 率和所消耗的内存。有了特征之后，会调用一个参数规则表，根据调参表对参数进行优化。将优化后的参数值推送给用户，用户判断是否进行参数调整。调参表是我们内部总结得出的，我们认为GC率大于 20%，说明当前运行的任务，内存是不足的，需要对内存进行适当的调整。如果内存在 4G 到 22 之间，认为当前内存是偏小的，需要调大当前的内存值；如果内存值已经比较大了，比如在 24G 到 30G，这时再增大内存的收益也许不大了，需要适当地降低并发数，让每一个运行的线程尽可能分配到更多的内存。

对于降内存的操作，若GC率小于 0.08，说明当前设置的内存过大，因为任务几乎不发生 GC，需要对内存进行适当的缩小。我们希望整个 task 运行的平均 GC 率在 0.08-0.2 之间，这是一个相对健康的区间，且要确保任务运行时没有发生抖动。

该项治理上线后，每天节省内存约 1TB。

进行治理操作，最终的落脚点都是对一个资源进行下线、停用或者删除。这三类操作，最容易引发线上故障，从而造成稳定性问题。判断这三类操作是否可以进行，主要判断该资源是否在被使用。这时需要用到“血缘信息“和”访问信息“。接下来介绍如何构建表级血缘。

构建表级血缘主要来源于四部分：

首先是 SQL 解析。我们使用的是开源的 Antlr，将 SQL 转化成一个抽象语法树，随后对这个语法树进行解析，可得到表 A 到表 B 的血缘关系。

第二是路径解析。若任务跑在 Yarn 上，会有 HDFS 输入路径与输出路径的映射关系，再结合元数据信息，便能拿到输入路径与输入表、输出路径与输出表的对应关系。这样就可以得到表 A 到表 B 的血缘关系。

第三是运行时 LogicalPlan 的解析。SQL 任务跑在 Spark 上，Spark 会将输入的 SQL 转化成一棵抽象语法树，随后再转化成逻辑计划，这些都是在内存里面完成的。将内存里面的逻辑计划，以 Json 格式输出，随后对该 Json 进行解析，便得到表 A 到表 B 的血缘关系。

第四是任务调度间的 tag 依赖。任务之间的调度会有依赖关系，比如，表 A 产出后，生成 tag 标记，表示表 A 已产出。表B的执行依赖表 A 的产出，当表 B 获取到表 A 生产 tag，便可开始执行。通过解析该 tag，可得到表 A 到表 B 的血缘关系。

最后对这四种方式获得的血缘信息求并集，得到最全面的血缘关系。之所以要取并集，是因为每种解析方式，都存在自身的局限性。

SQL 解析，由于用户总会写一些奇奇怪怪的 SQL，导致 SQL 解析无法做到 100% 正确。Yarn 路径解析，该方式 100% 正确，但总有一些特殊的任务不是通过 yarn 提交的，因此这些特殊的任务也就不能被覆盖到。对于运行时 LogicalPlan，主要解决临时资源，比如临时表和临时 UDF 的血缘匹配。配置 tag 的方式，完全依赖于用户的配置，如果用户不配置 tag 依赖或者 tag 依赖配置错误，也会导致血缘信息的错误。

将这四个解析方式的结果求并集，最终正确率达到了 99. 97%。

相比血缘信息，访问信息的获取较为简单，通过解析 HDFS 审计日志，即可得到每个资源被访问的情况。

将血缘信息和访问信息相结合，并在产品上给到用户醒目的提示，确保用户对资源进行下线、删除等操作的安全。做到治理工作的长治久安。

三、ES 成本治理实践

ES 的定价项，分为“共享集群”和“独立集群”定价。共享集群的收费项为存储费用，分为常规存储和冷存储。独立集群的定价，为集群全部的硬件费用，加上维护集群的相关服务费用。

ES 成本看清，整体逻辑与 Hadoop 类似。接入相关的元数据，分为存储快照、索引基础信息与 Gateway 日志。将接入的元数据，同步到数仓层进行清洗、加工，得到按个人、项目、组织和账户四个维度的用量明细。对用量进行汇总，可用于财务结算。对其进行下钻，便可分析具体的账单。下图中展示了产品示意图，可以按照不同的视角，看清成本消耗在哪些索引上，对于每位用户或账户，可以看清所消耗的费用和用量的具体值及环比，以及待节省的空间。

ES 成本治理基础也是相关的元数据：存储快照、Gateway 日志和索引基础信息。存储快照记录了存储量信息，Gateway 日志记录了具体的访问信息，索引基础信息为访问人、创建时间等等。滴滴内部可以对 ES 进行成本治理，一个很重要的原因是，ES 引擎自建了 Gateway，该网关封装了所有对 ES 的查询请求。

ES 的待治理项主要包括：空模板、未设置生命周期、不合理生命周期、33 天无访问，以及字段优化。其中字段优化分为两类，一是关闭倒排索引，二是关闭正排索引。ES 的收费项是对存储进行收费，因此关闭倒排和正排可减少索引的存储量，从而降低成本。关闭倒排索引的依据，该索引是不是长时间没有被检索。对于正排索引，如果长时间没有聚合或者排序的操作，则可以关掉。

根据待治理项，拉出待治理的资源列表，形成治理工单，分发给相应的索引负责人。治理的相关接口人可通过治理工作台，追踪治理进展。

除了 ES 和 Hadoop，滴滴内部也对其它引擎，如 Flink、ClickHouse 等和一些中台产品也开展了成本治理工作，整体逻辑与前文所述类似。首先对产品进行定价，定价之后可以做成本看清的工作，具体知晓哪些资源消耗了多少成本。接下来就可以开展成本治理的工作，基础是元数据的接入，再对元数据进行清洗加工，得到待治理的资源列表，将其打包形成治理工单，通过治理工作台跟踪治理进展。

四、一些心得

做数据治理，需要有自上而下的成本目标与组织保障，否则难以推动。组织保障的最上层是集团的预算委员会，主要负责制定每个事业部，今年整体的预算目标，将目标派发给事业部的成本负责人。事业部的成本负责人，领到今年的预算目标，需对目标进行拆分，具体到今年要完成的治理优化数量，同时成本负责人向预算委员会，汇报治理工作的进展。事业部的负责人将拆分后的优化目标派发给各个团队的成本治理接口人，治理接口人根据治理目标，拆分出治理任务，将治理任务分配给资源的归属人，由其完成治理动作。同时成本治理接口人需要向事业部的成本负责人汇报治理进展。

开展成本治理工作，最终的执行者都是一线具体的资源归属同学，他们每天的工作任务压力已经是较大的。若还需抽出额外的精力，做成本治理工作，往往推动较难，这也是治理工作的难点之一。将“被迫治理”转为“积极治理”，在滴滴每年会通过运营活动的方式，营造氛围。如开展《数据治理大赛》，将个人或者团队的治理完成率进行排名，对排名较高的个人或团队进行奖励。希望能为枯燥的治理工作带来一点娱乐性，进而激发大家的治理积极性。