原文大佬的这篇本文主要介绍滴滴大数据在成本治理方面的实践。有些内容是有借鉴意义的，这些摘抄下来用作沉淀学习。如有侵权，请告知~
一、滴滴大数据成本治理总体框架
1.1 数据体系
从上图所示：最底层是以数据引擎为基础的数据存储，分为离线计算、实时计算、OLAP、NoSQL、日志检索和数据通道六个部分。
在数据计算层，滴滴自研了一站式数据开发平台——“数据梦工厂”，主要包含离线开发、实时开发、任务调度、同步中心等一系列开发组件。数仓的同学和数据分析同学利用数据梦工厂进行数据的清洗与加工、构建其各自业务线的数据仓库。
在数据服务层，滴滴自研了一站式数据应用消费平台——“数易”，用来满足各类看数、取数、用数的场景。
最上层，数据科学的同学利用已加工好的数据进行决策支持、业务分析和数据挖掘等算法类场景的工作。
管理整套的数据体系、是通过以“元数据”为中心建设的两个产品，“数据地图”和“资产管理平台”。
治理工作，围绕五个核心方向展开，分别是成本、安全、质量、模型和价值。去年整个团队的工作重心，主要围绕数据安全方面。今年的重心则是成本治理。接下来，对成本治理方面的工作实践进行介绍。
1.2 大数据资产管理平台
滴滴大数据资产管理平台主要以六个分数来衡量使用数据的“好”与“坏”，分为计算健康分、存储健康分、安全健康分、质量健康分、模型健康分和价值健康分。根据这六个维度分数的几何平均，算出一个总分 DataRank 分，来衡量总体使用数据“好”与“坏”的程度。成本治理主要是提升计算健康分和存储健康分。
使用大数据资产管理平台进行成本管理，主要是对引擎（Hadoop、ES、Flink、Click House、Kafka、Hbase），和以“数据梦工厂”和“数易“为核心的两个数据中台产品，提供成本计费、账单分析和成本治理相关能力。
1.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的分布不均。解决方案之一是用 map join将小表广播；另外，也可以适当增加并发度，比如通过 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 审计日志，即可得到每个资源被访问的情况。
将血缘信息和访问信息相结合，并在产品上给到用户醒目的提示，确保用户对资源进行下线、删除等操作的安全。做到治理工作的长治久安。
三、实践经验
做数据治理，需要有自上而下的成本目标与组织保障，否则难以推动。组织保障的最上层是集团的预算委员会，主要负责制定每个事业部，今年整体的预算目标，将目标派发给事业部的成本负责人。事业部的成本负责人，领到今年的预算目标，需对目标进行拆分，具体到今年要完成的治理优化数量，同时成本负责人向预算委员会，汇报治理工作的进展。事业部的负责人将拆分后的优化目标派发给各个团队的成本治理接口人，治理接口人根据治理目标，拆分出治理任务，将治理任务分配给资源的归属人，由其完成治理动作。同时成本治理接口人需要向事业部的成本负责人汇报治理进展。
开展成本治理工作，最终的执行者都是一线具体的资源归属同学，他们每天的工作任务压力已经是较大的。若还需抽出额外的精力，做成本治理工作，往往推动较难，这也是治理工作的难点之一。将“被迫治理”转为“积极治理”，在滴滴每年会通过运营活动的方式，营造氛围。如开展《数据治理大赛》，将个人或者团队的治理完成率进行排名，对排名较高的个人或团队进行奖励。希望能为枯燥的治理工作带来一点娱乐性，进而激发大家的治理积极性。
参考文章：文章来源：https://www.toymoban.com/news/detail-839464.html
滴滴大数据成本治理实践文章来源地址https://www.toymoban.com/news/detail-839464.html
到了这里，关于数据治理——滴滴大数据成本治理实践的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
