导读

本文概述了在业务高速发展和降本增效的背景下百度MEG（移动生态事业群组）大数据成本治理实践方案，主要包含当前业务面临的主要问题、计算数据成本治理优化方案、存储数据成本治理优化方案、数据成本治理成果以及未来治理方向的一个思路探讨，为业界提供可参考的治理经验。

01 背景

随着百度各业务及产品的快速发展，海量的离线数据成本在持续地增长。在此背景下，通过大数据治理技术来帮助业务降本增效，实现业务的可持续增长变得至关重要。我们通过对当前资源现状、管理现状以及成本现状三个角度进行分析：

• 资源现状：各个产品线下业务类型繁多，涉及的离线AFS（百度公司分布式文件存储：Appendonly File Storage）存储账号和EMR（百度公司全托管计算集群：E-MapReduce EMR+）队列数量非常多，成百上千，什么时候启动治理，采用什么手段治理，并没有明确规划，且各业务间缺少统一的治理标准。

• 管理现状：针对离线资源的使用参差不齐，存储账号和计算队列资源的管理和使用较为混乱，有的使用率高，有的使用率低；此外，业务间的离线作业管理并不统一且不完全规范，没有完善的流程机制以及规范来对离线资源以及作业进行管理管控，并且计算任务的执行效率较低，整体运维难度较大。

• 成本现状：MEG各个产品线离线计算资源达数千万核，存储资源达数千PB，各产品线的离线计算和存储资源成本每年可达数亿元，随着业务的增长，如果不进行成本治理和优化，离线资源成本还会持续增加。

整体来说，目前主要面临数据散乱、资源浪费、成本增加等问题。基于以上存在的问题，我们通过构建统一的治理标准，并利用大数据资源管理平台搭建各产品线下的的离线存储资源视图、计算资源视图、任务视图以及成本视图，基于引擎能力对存储和计算进一步优化，帮助MEG下各产品线下的业务持续进行数据成本治理，接下来将具体阐述我们在大数据成本治理过程的实践方案。

△ 数据成本治理现状

02 数据成本治理实践方案

2.1 数据成本治理总体框架

针对目前存在的问题，我们主要围绕数据资产度量、平台化能力以及引擎赋能三个方面构建数据成本治理总体框架，实现对计算和存储两大方向的治理，来达到降本增效的目的，具体如下图所示，接下来将进行具体地介绍。

△ 数据成本治理总体框架

2.1.1 数据资产健康度量

为了对当前各个业务的计算和存储资源进行合理的评估和治理，我们采用统一的标准：健康分来进行衡量，而健康分计算的数据指标来源依赖于离线数据采集服务，该服务通过对当前计算队列，计算任务，存储账号，数据表等元数据信息进行例行采集，然后再进一步对于采集的数据进行分析和挖掘，形成一个个计算治理项和存储治理项，比如计算治理项可包含：使用率不均衡的计算队列个数、长耗时高资源消耗的计算任务、数据倾斜的任务以及无效任务等；存储治理项可包含1年/2年/N年未访问的冷数据目录、存储目录生命周期异常、inode占比过低以及未认领目录等。通过产生的数据治理项信息汇聚形成计算健康分和存储健康分两大类，如下：

• 计算健康分：基于队列使用平均水位+队列使用均衡程度+计算治理项进行加权计算获取。

• 存储健康分：基于存储账号使用平均水位+存储账号使用峰值+冷数据占比+治理项进行加权计算获取。

最终，通过统一规范的健康分来对当前各产品线下业务所属的数据资产进行度量，指导业务进行规范化治理。

2.1.2 平台化能力

此外，为了完成对当前产品线下离线计算和存储资源的全生命周期管理，我们通过搭建大数据资源管理平台，完成对各个产品线的离线计算资源和存储资源的接入，并基于平台能力为业务构建统一的计算视图、存储视图以及离线成本视图，整合离线计算任务需要的存储和计算资源，并将各类工具平台化，帮助业务快速发现和解决各类数据成本治理问题，具体如下：

• 计算视图：包含各个计算队列资源使用概览和计算治理项详情信息，并提供计算任务注册、管控、调度执行以及算力优化全生命周期管理的能力。

• 存储视图：汇聚了当前所有存储账号资源使用详情以及各类存储治理项信息，并提供给用户关于存储目录清理、迁移以及冷数据挖掘相关的存储管理以及治理能力。

• 成本视图：构建各个产品线下关于离线存储和计算资源总成本使用视图，通过总成本使用情况，更直观地展示治理成果。

2.1.3 引擎赋能

在实际离线大数据业务场景中，很多业务接口人对于大数据计算或者存储引擎的原理和特性不是非常熟悉，缺乏或者没有调优意识，通常在任务提交时没有根据任务的实际数据规模、计算复杂度以及集群资源状况进行针对性的参数调整，这种情况就会使得任务执行效率无法达到最优，且计算和存储资源不能得到充分的应用，进而影响业务迭代效率。针对上述计算和存储资源浪费的问题，我们结合大数据引擎能力，来实现对于计算和存储进一步地优化，助力业务提效，为业务的持续发展提供有力的支持。主要包含以下两个场景：

• 计算场景：结合任务运行历史信息以及机器学习算法模型能力，建立一套完善的智能调参机制，对于提交的任务参数进行动态调整，最大程度保障任务在较优的参数下执行，进一步提升任务执行效率，并高效利用当前计算资源。

• 存储场景：针对海量的存储数据，我们通过不同类型数据进行深入的分析和特征挖掘，实现了对存储数据智能压缩的能力，从而在不影响业务数据写入和查询的前提下，完成对现有数据存储文件的压缩，帮助业务节约存储资源和成本。

03 计算&存储数据成本治理优化

3.1 计算成本治理

在计算成本治理方向，我们主要基于平台和引擎能力，通过管理管控，混合调度以及智能调参三大方面对现有的计算资源和计算任务进行治理和优化。

3.1.1 管理管控

在MEG离线大数据场景下，主要涉及对上千EMR计算队列、以及上万Hadoop和Spark两大类型的计算任务管理。

• 一方面，我们针对各个业务的计算队列和计算任务的管理，通过平台能力实现了从计算资源的注册接入，到计算队列和任务数据的采集，再到离线数据分析和挖掘，最终形成如使用率不均衡的计算队列、长耗时高资源消耗的计算任务、数据倾斜的任务、无效任务以及相似任务等多个计算治理项，并基于统一规范的健康分机制来对业务计算资产进行度量，指导业务对计算进行治理。

• 另一方面，在离线混部场景，可能会存在部分用户对于任务使用不规范，影响离线例行任务或者造成资源浪费，我们针对Hadoop和Spark不同任务类型，分别建立了任务提交时和运行时管控机制，并结合业务实际场景，实现了并发限制、基本参数调优，队列资源限制以及僵尸任务等30+管控策略，对于天级上万的任务进行合理的管理管控，并及时挖掘和治理相关异常任务。目前运行的管控策略已经覆盖多个产品线下离线EMR计算队列上千万核，每天任务触发各种管控次数20万+。

通过对计算资源全生命周期的管理和管控，我们可以及时有效地发现可治理的队列或者任务，并推进业务进行治理。

△ 任务管理管控流程

3.1.2 混合调度

通过对于平台接入的队列资源使用情况以及任务执行情况的深度分析，我们发现当前各个业务使用的计算资源存在以下几个问题：

1. 不同产品线业务特点不同，存在Hadoop和Spark两种类型计算任务，并且Hadoop任务CPU使用较多、内存使用较低，而Spark任务CPU使用较低，内存使用较高。

2. 有些队列整体资源使用率不高，但是存在部分时间段资源使用很满，不同队列资源使用波峰不完全一致，有的高峰在夜间，有的高峰在白天。

3. 存在队列碎片化问题，一些小队列不适合提交大作业且部分使用率不高。

为解决上述问题，我们建设Hadoop和Spark混合调度机制。针对公司不同业务来源的任务，基于Hadoop调度引擎以及Spark调度引擎完成各自任务的智能化调度，并通过调度策略链在多个候选队列中选择最优队列，最终实现任务提交到EMR计算集群上进行执行。具体流程如下：

• 任务提交：针对不同产品线下的业务提交的Hadoop或者Spark任务，服务端会通过不同任务类型基于优先级、提交时间以及轮数进行全局加权排序，排序后的每个任务会分发到各自的任务调度池中，等待任务调度引擎拉取提交。

• 任务调度：该阶段，调度引擎中不同任务类型的消费线程，会定时拉取对应任务调度池中的任务，按照FIFO的策略，多线程进行消费调度。在调度过程中，每个任务会依次通过通用调度策略链和专有调度策略链来获取该任务最优提交队列，其中，通用和专有调度策略主要是计算队列资源获取、候选队列过滤、队列排序（数据输入输出地域，计算地域）、队列资源空闲程度以及高优任务保障等20+策略。比如某任务调度过程中，请求提交的队列是A，调度过程中存在三个候选队列A、B、C，其中候选队列A使用率很高，B使用率中等且存储和计算地域相差较远，C使用率低且距离近，最终通过智能调度可分配最优队列C进行提交。

• 任务执行：通过调度引擎获取到最优队列的任务，最终会提交到对应的EMR计算集群队列上进行执行，进而实现各个队列的使用率更加均衡，并提高低频使用队列的资源使用率。

△ 任务混合调度流程

3.1.3 智能调参

在数据中心业务场景，多以Spark任务为主，天级提交的Spark任务5万+，但这些任务执行过程中，会存在计算资源浪费的情况，具有一定的优化空间，我们通过前期数据分析，发现主要存在以下两类问题：

1. 用户没有调优意识，或者是缺乏调优经验，会造成大量任务资源配置不合理，资源浪费严重，比如并发和内存资源配置偏大，但实际可以继续调低，如case示例1所示；

2. 在Spark计算引擎优化器中， 只有RBO(Rule-Based Optimizer)和CBO(Cost-Based Optimizer)优化器， 前者基于硬规则，后者基于执行成本来优化查询计划，但对于例行任务， 只有RBO和CBO会忽略一些能优化的输入信息，任务性能存在一定的瓶颈，如case示例2所示。

△ 任务参数配置case示例

针对第一类问题，我们实现了对Spark任务基本参数智能调优的能力，在保证任务SLA的情况下，结合模型训练的方式，来支持对例行任务长期调优并降低任务资源消耗。每轮任务例行会推荐一组参数并获取其对应性能，通过推荐参数、运行并获取性能、推荐参数的周期性迭代，在多轮训练迭代后，提供一组满足任务调优目标并且核时最少的近似最优参数，其中涉及的参数主要有spark.executor.instances, spark.executor.cores, spark.executor.memory这三类基本参数。具体实现流程如下：

1. 任务提交流：任务提交过程中，会从调优服务的Web Controller模块获取当前生成的调优参数并进行下发；

2. 结果上报流：通过任务状态监控，在任务执行完成后，调优服务的Backend模块会定时同步更新任务实际运行配置和执行耗时等执行历史数据信息到数据库中；

3. 模型训练流：调优服务的Backend模块定时拉取待训练任务进行数据训练，通过与模型交互，加载历史调优模型checkpoint，基于最新样本数据进行迭代训练，生成新的训练模型checkpoint以及下一轮调优参数，并保存到数据库中。

4. 任务SLA保障：通过设置运行时间上限、超时兜底、限制模型调优范围，以及任务失败兜底等策略来保障任务运行时间以及任务执行的稳定性。

最终，通过任务提交流程、结果上报流程、训练流程实现任务运行时需要的并发和内存基本参数的自动化调优，并基于运行时间保障和任务稳定性保障策略，确保任务的稳定性，整体流程框架如下图。

△ 基本参数智能调优流程

针对第二类问题，我们构建HBO(History Based Optimization)智能调优模块实现对复杂参数场景的任务自动调优能力。首先，通过性能数据收集器完成对运行完成的Spark任务History的详情数据采集和AMP任务画像，然后在任务执行计划阶段和提交阶段，基于任务历史执行的真实运行统计数据来优化未来即将执行的任务性能，从而弥补执行之前预估不精确的问题，具体如下：

• 执行计划调优阶段：主要进行Join算法动态调整、Join数据倾斜调整、聚合算法动态调整以及Join顺序重排等调优；

• 任务提交阶段：基于任务运行特点智能添加或者改写当前提交的Spark任务运行参数，比如Input输入、合并小文件读、Output输出、拆分大文件写、Shuffle分区数动态调整以及大shuffle开启Kryo Serialization等参数，从而实现对运行参数的调优；

通过数据采集反馈和动态调参，不断循环，进而完成对于复杂参数场景的智能调优能力，让任务在执行资源有限的条件下，跑得更稳健，更快。整体实现流程图如下：

△ HBO智能调优流程

3.2 存储成本治理

在百度MEG大数据离线场景下，底层存储主要是使用AFS，通过梳理我们发现目前针对离线使用的各个存储账号，缺乏统一管理和规范，主要存在以下几个核心问题：

• AFS存储账号多且无归属：离散账号繁多，涉及目录数量多且大部分无Quota限制甚至找不到相关负责人，缺乏统一管理和规范；

• AFS存储不断增加：不少业务对于数据存储缺少优化治理措施，且存在很多历史的无用数据，长期存放，导致数据只增不减；

• 安全风险：各个账号使用过程中，数据随意读写甚至跨多个账户读写，安全无保障，并且缺少监控报警。

3.2.1 存储生命周期管理

针对上述问题，我们基于平台能力构建存储一站式治理能力，将存储资源的全生命周期管理分为五层：接入层、服务层、存储层、执行层以及用户层，通过建立存储资源使用规范，并基于采集的相关存储元数据，深度分析业务的离线AFS存储账号使用现状，将用户存储相关的问题充分挖掘和暴露出来，针对各种问题提供简单易用的通用化工具来帮助用户快速进行治理和解决，整体实现了各个集群存储账号的存储数据接入，采集，挖掘和分析，自动清理，监控预警全生命周期的管理。整体流程架构图如下：

△ 存储生命周期管理流程

• 接入层：通过建立规范的存储资源管理机制，比如存储的接入和申请规范、目录的创建规范、使用规范、利用率考核规范（Quota回收规范）以及冷数据的处理规范等通用化的规范，进而来完成用户从存储资源的接入-申请（扩容）、审核、交付、资源的例行审计的整体流程。

• 服务层：基于离线服务完成对各集群存储目录&存储冷数据Quota采集，然后进一步对数据进行深入分析和挖掘，包含但不限于冷数据、异常目录使用、存储变化趋势以及成本数据等分析。

• 存储层：建立账号、产品线、目录、任务、负责人以及账号的基本使用信息的元数据存储，通过Mysql进行存储，确保每个集群存储账号有对应归属；对于各个集群目录数据使用详情信息，选择Table（百度公司大规模分布式表格系统）进行存储。

• 执行层：基于存储管理规范，对于各个集群存储账号进行每天例行的存储自动清理，数据转储和压缩，并提供完善的存储使用监控报警机制。

• 用户层：通过平台，为用户构建不同维度的AFS存储现状概览视图，以及整合现有数据，对于各个集群的存储账号或目录进行分析，提供优化建议、存储工具以及API接口，帮助业务快速进行存储相关治理和存储相关问题的解决。

3.2.2 存储基础治理

在AFS存储资源的生命周期管理过程中，我们主要基于服务层和执行层为用户提供一套基础的存储AFS账号数据基础治理能力。通过离线解析Quota数据和冷数据目录相关的基础数据，完成对其计算、分析、聚合等处理，实现存储趋势变化、成本计算、异常目录分析、冷数据分析、数据治理项和治理建议等多方面能力支持。之后，用户便可结合存储数据全景视图分析和相关建议，进行存储路径配置、转储集群目录配置、压缩目录配置以及监控账号配置等多维度配置。基于用户的配置，通过后台离线服务定时执行，完成对用户存储的数据清理、空间释放和监控预警，保障各个业务存储账号的合理使用以及治理优化。

△ AFS存储数据基础治理流程

3.2.3 智能压缩

平台侧管理的MEG相关AFS存储数据上千PB，存在一部分数据，是没有进行相应的压缩或者压缩格式设置的并不是非常合理，我们通过结合业务实际使用情况，针对业务存储数据进行智能压缩，同时不影响数据读写效率，进一步优化降低业务存储成本，主要实现方案流程如下图。由于业务场景不同，我们采用不同的压缩方案。

• 针对数仓表存储数据场景：首先是通过对采集的数仓表元数据信息进行数据画像，完成表字段存储占比和数据分布情况分析，之后基于自动存储优化器，实现对数仓表分区数据读取、压缩规则应用以及分区数据重写，最终完成对数仓表数据的自动压缩，在保证数仓表读写效率的前提下，进一步提升数据压缩效率，降低存储数据成本。其中压缩规则应用主要包含：可排序字段获取、重排序优化、ZSTD压缩格式、PageSize大小以及压缩Leve调整等规则。

• 针对非数据仓表存储数据场景：在该场景下的存储数据，一般是通过任务直接写入AFS，写入方式各种各样，因此，需要直接对AFS存储数据进行分析和挖掘。我们首先对这部分数据进行冷热分层，将其分为冷数据、温数据以及热数据，并挖掘其中可进行压缩和压缩格式可进一步优化的数据，以及压缩配置可进一步调整的任务；之后，通过自动存储优化器，针对增量热数据，基于例行写入任务历史画像选择合适的压缩参数进行调优，并记录压缩效果；针对存量温冷数据，定期执行离线压缩任务进行自动压缩；最终我们对热数据进行压缩提醒，温冷数据进行自动压缩，从而实现该类型存储数据的压缩智能优化。

△ 智能压缩流程

04 治理成果

通过数据成本治理，我们取得了一些不错的优化和实践效果，主要包含数据开发和成本优化方面以及治理资产两大方面：

1. 数据开发和成本优化

• 数据开发提效：基于离线资源的全生命周期管理，计算和存储资源交付效率从月级或者周级缩短至天级，效率大幅提升，进而降低数据开发周期，此外基于混合调度和智能调参等能力，任务排队情况大幅降低，数据产出时效性平均提升至少一倍，大幅提高数据开发效率。

• 计算成本优化：实现了MEG下上千个队列使用更加均衡，并完成了千万核EMR计算队列资源平均使用率提升30%+，增量供给日常业务需求数百万核资源的同时，优化退订数百万核计算资源，年化成本可降低数千万元。

• 存储运维提效：通过利用存储数据基础治理等能力，完成了对上千个AFS存储账号管理、无用数据挖掘和清理，以及监控预警等，使得存储账号的运维更加可控，效率大幅提升。

• 存储成本优化：实现了对MEG下上千PB存储资源整体使用率平均提升20%+，增量供给日常业务需求数百PB资源的同时，优化退订数百PB存储资源，年化成本同样降低数千万元。

2. 治理资产

• 数据开发规范：逐步完善了资源交付规范、计算任务开发规范、存储和计算资源使用规范、以及数据质量和安全规范等多种规范流程。

• 计算&存储资源成本：形成各个产品线下关于计算资源、存储资源以及成本使用详情的概览视图，对于资源使用和成本变化趋势清晰可见。

• 数据任务资产：基于任务历史画像，构建任务从提交到运行再到完成的全生命周期的执行详情数据概览视图，帮助业务高效进行任务管理。

• 数据治理项：通过数据挖掘和分析形成的计算任务，计算队列和存储账号相关的治理项详情数据看板，助力业务快速发现可治理的数据问题。

05 未来规划

目前，通过标准化、平台化以及引擎化的技术能力，进一步完成了对MEG下离线存储和计算资源管理和数据成本治理，并取得一定治理成果，但数据成本治理作为一个长期且持续的一项工作，我们将持续完善和挖掘数据成本治理技术方案，并结合治理过程中的经验、流程和标准，实现更规范、更智能化的治理能力。