摘要：随着业务快速发展，大数据平台所支撑的业务矩阵愈发庞大且繁杂多样，数据业务在高速发展建设阶段，更关注的是数据交付效率、稳定性、平台易用性等方面，与此同时，数据规模爆炸式增长和计算需求的不断攀升，使大数据平台成本呈现快速上扬态势，如何有效控制和优化这些成本，成为数

随着业务快速发展，大数据平台所支撑的业务矩阵愈发庞大且繁杂多样，数据业务在高速发展建设阶段，更关注的是数据交付效率、稳定性、平台易用性等方面，与此同时，数据规模爆炸式增长和计算需求的不断攀升，使大数据平台成本呈现快速上扬态势，如何有效控制和优化这些成本，成为数据团队面临的巨大挑战。

朴朴数据平台建设历经多个发展阶段：从早期的报表取数 -> 数仓体系建设 -> 以指标平台为数据建设核心 -> DATA+AI，而每个阶段的发展变更均会对成本造成巨大冲击。我司开展较大规模成本治理迄今已三度春秋，个中艰辛难以言表，整体可概括为“降本增效”三部曲：成本发现与分析、成本优化与控制、体系化治理构建。本文是对过往成本治理过程做阶段性总结，意在复盘亦为分享，希望对大家如何开展云上大数据平台成本治理有所帮助。

成本发现与分析

2022 年某个时间节点，云厂商 TAM 团队反馈我司月成本急剧上涨，在此之前，数据团队核心关注点在数据中台建设，由于云产品服务计费规则较为精细复杂，需要投入大量时间学习和对接才能掌握有效的成本分析方法。初期的成本跟进依赖于 TAM 团队月会反馈，缺少主动洞察手段，面对成本急剧上涨的情况，着手进行第一阶段成本分析与治理工作。

1.1 分析 & 治理初试

初期，在 SA 和 TAM 团队的帮助下对大数据成本进行分析，主要集中在：存储、计算、网络流量和 EMR 托管四大方面，根据服务类别的成本占比分析结果，确立下一步优化方向和优先级。

EMR 作为大数据平台基础架构底座，可针对不同实例组配置灵活调度组合各类计算资源，结合其弹性伸缩能力满足不同时段业务计算所需，关于 EMR 的使用可参考笔者另一篇文章《EMR 实战心得浅谈》。EMR 的成本组成可拆分为两大部分：

EMR 集群管理费

经由 EMR 启动计算实例时产生的管理费用，按小时、实例规格大小阶梯式收取

EMR 计算实例 (我司主要使用 EMR ON EC2 模式)

EC2 计算实例本身费用 (On Demand、Spot、Savings Plan 三种计费模式）

EC2 计算实例产生的跨可用区流量费

EC2 计算实例所挂载的 EBS 卷费用 (系统盘、数据盘)

从已产生的 EMR 成本清单数据细化分析，进而得出治理方向和措施：

削减 EMR 托管费用

全面下线小规格机型使用 (低于 8x)，最大化减少托管费用

结合业务计算峰谷，配置适当的扩缩容策略

降低 EC2 计算实例单价

在不降低业务计算性能前提下，使用单价相对便宜的机型 (如 INTEL -> AMD)

降低 On Demand 计费类型占比，提升 RI & Savings Plan 合约购买比例

有溢出的部分，尽可能多使用 Spot 竞价机型

调整集群内计算实例挂载 EBS 卷

启用 Core 分区独占模式，将存储与计算节点彻底分离

实践测算，在存算分离离线 EMR 集群中，EBS 的配置可结合计算节点核心数规格线性配比 (如 1C:10G)，实时计算集群中因状态存储，比例可酌情往大调整

自动化批量调整 GP2->GP3

存储层优化

在云上，前期主要使用 EBS 卷和 S3 两类存储服务。前者由于单价较低，使用者容易忽视其成本影响，当集群扩大一定规模时，特别是早期低规格实例数量较多时，EBS 卷的使用容量会随之激增，导致成本上涨，EBS 卷的治理方向可参考上文所列，本节不再赘述。

由于湖仓的建设和推广使用，S3 存储用量每年均大幅度上涨，导致存储费用极其可观。早期对 S3 的使用缺乏认知，结合业务读写的特性 (缺少热度观测和存在历史数据回刷)，数据均存放在标准层 (Standard Storage)，避免请求费大于存储费的情况。因此，首次针对 S3 存储开展治理行动，集中在：

清理无效数据和调整数据保留周期

关闭数据桶的版本控制

未完成分段上传清理

治理完成后，共计清理数据容量 PB+，以标准层费率计算月削减成本十万 +。

流量层优化

云服务 (S3、EC2 等) 使用过程若存在跨可用区数据传输是需要额外收取费用，具体收费条目可查看官网说明。为保障计算集群可用性和稳定性，我司在 A/B 区分别构建了多个业务 EMR 集群，直接加剧了此类费用的产生，由于流量费用夹杂在 EC2 的费用中，难以被直接观测到，直至成本出现较大异常增量时才被分析识别出来。

在 SA 和 TAM 的协助下，分析各 VPC 间数据流向及所产生的成本条目，最终完整地呈现流量成本构成：

VPC Peering：主要成本产生自离线 Bigdata 和在线 PROD 的 VPC 之间数据往返传输流量

DTAZ-Bigdata VPC：bigdata VPC 内部 DTAZ 流量，业务流向为 AZ1 的 kafka 到 AZ2 的 EMR，再返回到 AZ1 的分布式数据库

NAT GW Bigdata：主要为 EMR 通过 NAT GW 拉取 S3 数据

S3 DTO 与 EC2 VPN DTO：S3 公网拉取数据与建立专线通道从 bigdata VPC 拉数据

以此依据可得出优化措施为：

分析跨可用区流量热点，调整 EMR 集群计算任务分布架构，尽量往数据源可用区靠近

调整 EMR 集群访问 S3 endpoint 方式

1.2 构建更周全的分析方法

CUR+ 自定义标签

首次治理即取得明显成效后，深刻认知到洞察成本花费在哪里的重要性，而要实现洞察的前提是要熟悉并掌握 CUR(Cost and Usage Report) 清单分析 (详见链接：CUR 连接)。CUR 清单里提供较为精细的费用明细数据，结合各种计费规则基本可还原出月成本构成，计费规则可从 TAM 团队对接获取。

除 CUR 基本数据词典定义外，我司设计了一套标签体系，进一步区分清单中每条费用对应使用方归属，标签涵盖：

系统标签：数据中心 region、环境 env、应用 appId、归属域 domain

应用扩展标签：平台类型 system、实例类型 instance-type ......

特定领域标签：emr 集群名 emr-cluster、emr 实例角色 emr-role、kafka 集群名 kafka-cluster ......

为便于统一分析，我们对 CUR 清单数据建模后使用 Spark 汇入湖仓，再整合对接到自研 BI 平台，便于持续监控和上卷下钻分析。也可采用云原生服务组合方式实现，如 Glue+Lambda+Athena+QuickSight。下图为 S3 成本下钻分析的一个示例，通过细分操作类型可进一步确定成本分布是否合理。

基于这份每日成本清单明细，在后续的一项治理行动 (针对桶级别全局开启智能分层上线) 提供了很重要的数据依据，而智能分层的全面上线在存储层带来年节约上百万的治理效果。

inventory 和 access log 组合

S3 本身提供了一些监控工具，其中笔者认为最为重要的有两个：inventory 和 access log。

inventory

inventory 是一个元数据信息统计镜像功能，用户自定义前缀匹配和指定时间点后，可导出一份对象元数据信息到指定数据桶 (详见: s3 inventory)，用户可据此开展治理行动项 (抓大放小)，这也是前期我们针对 S3 治理的一个重要数据依据来源。inventory 导出后由 manifest 和 symlink 分割不同时间周期的元数据情况，对于 ORC 和 Parquet 格式的清单文件，不支持使用 Apache Hive 和 Spark 读取 symlink.txt 文件，因此建议 symlink 设置为 CSV 格式导出，便于进一步数据处理。

在 inventory 文件中存储每个对象的信息 (绝对路径，如 s3://bucket1/xxxx/xxxx/file1.parquet)，而在实践过程中，此类明细数据对于治理开展帮助不大，因为用户需要的是每一级路径的情况。针对此问题，我们使用 spark 对 inventory 文件中每个对象信息按路径拍平，并逐级处理两类操作：

聚合出每级路径大小、文件数

递归将底层文件最后更新时间反射到上层每一级路径

经此处理后的 inventory 数据，可迅速确定各级路径 (对象存储中无路径这一概念，此为虚拟概念) 的大小和最后更新时间，这为治理过程判断极大地提高了效率和准确性。

access log

access log 详细记录了上层各类应用对 S3 存储桶提交的各种请求操作，因此在安全审计和访问查询方面很有用，开启方式详见：s3 access log。以我们的数据规模对应每日产生的 access log 量达数十亿条，分析 access log 的难度和成本无疑是巨大的。到了治理第二阶段，再依靠于人工确认数据访问情况显然不现实，此时迫切需要真实的数据文件访问热度信息。我们使用 Spark 将每日产生的 access log 做 ETL 处理后接入湖仓 ODS 层，再将其与 inventory 结合，最终还原出每一级路径的访问和元数据信息:

s3 inventory 是隔日类镜像式导出，客观上会存在元数据空洞，例：在两次导出间隔期间若存在某些对象文件创建和删除，所操作的对象文件不会被 inventory 记录，但会存在于 access log 中。针对此问题，我们的做法是将 inventory 和 access log 以 bucket+path 为关联键，按生成时间点切割后做 Full Join，如此可将数据访问热度最大化进行还原，过程实现参考下图：

inventory 和 access log 组合为后续开展的一系列 s3 治理专项提供极为重要的数据依据，在存储层成本节约做出巨大贡献。

1.3 阶段一治理小结

第一阶段治理通常具有最高 ROI，主要得益于前期粗放式资源使用模式下存在的优化空间。历经一个季度分批推进，以成本占比作为优化顺序，完成上述三个层面优化专项后，实现不影响业务增长前提下月成本同比削减 32% 的治理成果，也为第二阶段更深层次的治理奠定了一些分析基础。

成本优化与控制

完成第一阶段的成本分析方法构建与治理后，虽然取得了显著的成本节约效果，但随着业务持续增长和数据规模不断扩大，仅依靠一次性治理行动难以实现长期的成本控制目标。因此，需要从更深层次的平台能力建设和技术架构改造入手，构建可持续的成本优化措施。

第二阶段围绕两个维度展开：一是平台能力建设，从数据生命周期管理、任务性能诊断、计算效率提升等方面提升平台的内在效率；二是技术改造专项，从计算引擎升级、架构迁移、资源使用优化等方面实现技术栈的整体成本降低。通过这种"内外兼修"的优化策略，建立长效的成本管控机制，确保在业务快速发展的同时，成本增长保持在可控范围内。

2.1 平台能力建设

数据生命周期管理

数据平台建设过程中，为满足业务使用所需引入多种数据源，主要有 Hive、Clickhouse、Elasticsearch、Cassandra。随着数据业务扩增和时间推移，大量历史数据长期占用存储资源，但实际访问频次不一，造成资源浪费。若以人工方式实现数据清理，面临着效率低下和难以规模化管理的问题，因此需要一个自动化数据生命周期管理工具。

该工具设计之初即涵盖数据平台常用数据源对象，数据源对象从资产元数据 API 接口获取，自动按域过滤，从源头上规避用户配置规则执行时误操作其他域同名对象。数据生命周期是基于预定义规则自动管理数据平台存量数据的系统化解决方案，支持对数据集按不同执行窗口实现自动清理，保障数据留存在合理区间。同时具备执行监控能力，支持清理容量大小、记录数等量化指标，便于事后治理效果评估。运营至今，每日清理的数据容量可观，实现清理量抵消增量的目标。

此外，还开发了任务生命周期管理，用于数据开发验证阶段的任务运行管控，避免开发验证类任务长期运行造成计算资源浪费。

Spark 任务诊断治理

进入主题之前，先提个问题：为什么需要诊断治理？

数据开发者经常面临的问题有：

资源使用不平衡：比较常见的情况是集群中内存被申请满了，但是 CPU 还有剩余，亦或 CPU 用光但内存还有剩余

运行时间不稳定：同个作业多次运行时间波动幅度大

资源滥用：每个业务方都希望自己的作业能尽可能快的完成，导致资源被滥用，带来一些不必要的资源紧张

从这些问题不难得出任务诊断治理的必要性。

诊断治理平台的实现分为 4 个模块：数据采集 -> 诊断分析 -> 生成报告 -> 治理优化。

数据采集

利用原生 spark listener bus 机制，任务指标数据采集后推送到 kafka，如下图所示：

诊断分析

使用 Flink 对 kafka 中指标数据做诊断分析处理，支持诊断类型：

资源成本类：任务 CPU 利用率、任务内存利用率、任务花费

耗时类：Application 运行时长、Job/Stage 阶段运行时长

失败类：Application/Job/Stage/Task 粒度失败检测

空跑类：任务 submit 之后未提交 Job 运行

效率类：数据倾斜、Task 长拽尾 or 读写卡顿、大表扫描、GC 异常...

诊断类型较多，以任务 CPU 和内存利用率的诊断为例简述实现过程

实现过程类似 CPU 利用率，不同之处是采用 peakMemory 作为计算指标，若能采集 executor GC 获取内存利用率，会更精准一些

生成报告

上游诊断分析处理后，诊断服务按 application 粒度将结果指标整合，形成最终的任务诊断报告。报告采用结构化设计，从两个方面呈现：一是任务元数据信息，如归属集群、任务 ID、任务名、负责人、耗时等；二是诊断信息，除诊断异常等级、命中异常项这类概要信息外，用户可切换诊断类型页查看详情数据分析，便于快速异常定位。

治理优化效果

所产生的诊断数据结果，平台运维人员可推进数据开发人员优化。工具上线后，数据运维团队多次开展 Spark 任务资源利用率治理，实测结果显示，在执行时间相近前提下，离线计算集群资源水位线最高能下降 20~30%，成本节约效果显著。

Spark 小文件自动合并

作为数据从业人员，对于 Spark 计算生成小文件的问题应不陌生。数据开发者常见做法是增加 repartition 算子以减少小文件的生成，但通常来说，每个批次生成数据集大小、动态分区插入数据量等均会给数据开发人员造成困扰，如何配置才能达到理想状态是个难题。为此，我们深入研究社区内几种小文件合并实现方案后，最终选择自研实现。

合并的核心思路是在 Commit 前进行拦截，通过重写 SparkSqlParquetOutputCommitter 方式加入合并 job 检测，当数据开发人员提交的 Spark 任务生成的小文件达到阈值时，会串行触发 compact 和 delete Job，且针对小文件众多的情况，会多轮触发 compact 直至达到预设阈值。

小文件合并插件上线后效果 (取一线上表为例)

从图中可以看出，小文件合并插件上线后，天分区文件个数大幅下降，对应的天分区路径访问次数也随之明显减少，具体数据显示：单一天分区文件数减少 97%，下游访问频次减少 85%，其他小文件表的合并效果因小文件规模数量而异。

小文件合并过程会对上游任务造成一定延时，但换来的是下游计算任务效率大幅提升和资源有效削减，产生的影响正面大于负面。这一点可通过小文件合并插件上线后运行一段时间的数据得到验证：离线任务诊断系统新生成的低资源利用率待治理任务数达到总 DAG 数 25%，证实了整体计算任务效率得到提升。

2.2 技术架构改造专项

EMR 升级

我司自 2019 年开始使用 EMR。

彼时，Spark3.0 发布不久，虽推出许多重磅特性，但其稳定性有待提升，结合 hudi 官方建议的集成版本，内部研讨决定基于 Spark 2.4.x 和 Hudi 0.5.x 构建离线湖仓 1.0 版本。之后 Hudi 社区发展迅猛，陆续推出许多数据湖领域稀缺特性，且在实时湖仓领域 flink-hudi 也日趋完善，结合数据业务发展在性能和功能方面述求，使得升级成为刚需。

持续至今，已完成两次 EMR 原地升级 (EMR5 -> EMR6 -> EMR7)，第二次是今年刚完成，均涉及集群管理、元数据、存储、离线计算、实时计算等全平台范围组件，核心组件版本迭代如下：

每次 EMR 升级难度极大，过程中如履薄冰，需大胆规划，小心求证。升级推进过程较为漫长，时间跨度周期以半年计，可概括为如下步骤：

风险评估：了解链路主要组件新版本特性，梳理风险点，确定升级目标大致可行性

制定计划：制定升级改造计划，拆解升级目标映射到个人，以串行与并行方式推进

升级测试：升级功能细粒度测验，评估是否符合预期以及投入人力周期

兼容性验证：涉及平台底层，需特别关注上层应用兼容性，如读写访问、任务提交、数据兼容性等

切换方案：制定升级切换计划和回滚方案，分批次进行切换，将问题影响程度降至最小

逐步升级 & 复盘整改：组件 & 服务单位功能按自测 -->PRE 集群 -->PROD 集群逐步升级，将遇到的问题均记录下来，总结、复盘和整改。当存在较大范围共性问题时，修复后视情况校正切换方案 (主体不变，细节调整随机应变)，直至完成全线切换

事后复盘整个升级专项推进过程，存在诸多思虑不周之处。虽然主体方向未变，但过程中充满各种变数 (客观和主观因素)，有些变数甚至足以影响专项的落地实施，尤其是行进至中后期，非主观性阻力因素尤为严重。得益于数据 & 上下游业务部门的大力支持，团队以不变应万变，见招拆招，攻克诸多困难，一起完成升级专项落地。

经历两次全面升级后，数据平台在多个维度取得收益。性能方面，Spark 的新特性在大部分离线场景计算效率提升 30~50%，成本优化效果明显；功能方面，hudi 和 flink 大量的新版本特性完善了流式湖仓管理能力，满足业务对数据新鲜度和计算效率的述求；稳定性方面，计算任务稳定性得到明显提升的同时，生态兼容性也得到较好的整合，为数据平台长期稳定运行奠定了坚实的基础。

Flink 架构优化

前文用较大的篇幅介绍了关于 Spark 成本优化，本节着重阐述我司如何针对 Flink 进行成本优化，围绕两个层面展开：Flink 容器化演进和 Flink Hudi 优化。

Flink 容器化

平台建设初期，Flink 任务运行在 EMR YARN 集群中。持续几年后，随着业务团队计算任务扩增，稳定性逐渐成为数据平台团队面临的重大挑战，主要体现在：资源隔离粒度粗糙存在资源争抢、集群计算节点容易被大状态任务打崩、集群扩缩容速度有限等几方面。基于稳定性和成本因素考量，于 2024 年初启动 Flink 容器化适配工作，简单列举 Flink on YARN vs K8S 对比：

确定方向后，下一步则是部署模式的选型 (Native vs Operator)，选型期间做了较深入的调研，包含深度研读社区文档、部署验证、与业内多个大厂技术团队交流，最终结合当前平台建设现状及未来动态弹性伸缩的需求，选择 FKO(Flink Kubernetes Operator) 方案。选型 FKO 方案的关键因素：

便捷式管理集群作业：FKO 提供了更高级的抽象和管理功能，专用于管理和运行 Flink 作业。它可以处理 Flink 特定的配置、依赖项和作业管理，简化作业的部署和操作，无需为不同 job 定义各自单独 YAML 声明。FKO 可以自动管理 Flink 作业的生命周期，包括创建、更新、扩展和停止作业，同时可以按需求自动缩放作业资源，并提供作业级别的操作和监控功能。

声明式：以脚本命令行创建需要额外确认资源是否按预期创建成功，而借助 FKO 的控制器模式，用户只需声明所期望的集群运行资源及状态，其余全部交由 FKO 保证实现。如运行中突然出现 JM/TM 节点故障，FKO 会自动重建节点以恢复集群运行状态。

故障恢复：FKO 集成了 Flink 的故障恢复机制，如 Checkpoint 和自动重启恢复：1. 用户只需指定 autoSavePointSeconds 和保存路径，FKO 会自动定期保存快照；2. 流式任务的显著特点是长期运行，运行过程中可能面临各种因素导致任务失败，借助 FKO，用户可以指定任务恢复策略 FromSavePointOnFailure，自动处理作业的状态恢复和故障处理，提供更可靠的作业运行环境。

生态集成成熟度：FKO 与 Flink 生态系统紧密集成，可以使用 Flink 的特性和工具，如保存点、检查点、状态后端、指标等，还支持 Flink 配置和用户代码的自定义，以满足特定的需求。同时集成 Ingress，方便用户访问 WEB UI 查看作业运行情况或者查看运行日志。

历经一个季度的开发迭代，内部流计算任务管理平台集成 FKO 正式上线，之后逐步推广给数据开发者使用。得益于前期的充分调研和验证，Flink ON YARN -> Kubernetes 的切换过程整体较为平滑，虽有间歇性问题出现，但都被数据团队攻克解决，未发生重大阻塞。最终我们花费近两个季度时间完成全部通用性任务切换，再结合资源利用率的治理推进，实现通用流计算集群月成本削减 30% 的目标。

Flink Hudi 优化

社区内关于 Flink Hudi 的优化案例众多，本节仅列举我司内部实践后效果明显的两个专题案例。

Hudi 表入湖合并

Flink Hudi 实时表入湖从零开始扩大使用规模，初期出于表接入效率考量，采用表与实时任务一对一捆绑关系。至第二阶段成本治理时，实时表入湖所占用的计算资源已上千核，成本比重较为明显。因此，实时表入湖合并很自然地被列为一个成本优化方向。

社区虽提供了一套单 job 多表 sink 解决方案，但经过一段时间实践后，发现在性能和稳定性方面难以满足我司使用需求，主要问题包括：单 job 内大表可能占用过多资源影响小表写入、单表接入问题可能导致整个作业失败、单 job 表数量增加时性能会急剧性下降、不同表引用不同配置时管理复杂。经调研后，另行实现合并方案，核心设计思路：同源 source 接入后按表粒度构建 multi job 提交运行，作业内表和 job 保持一对一捆绑关系，提交后每个 job 各自运行 Pipelines.hoodieStreamWrite。以一个 topic(mysql db) 多表配置为例，数据管理人员可在自研数据集成服务中按不同阶段表数据量级拆分为多个批次分别创建作业运行，从而极大地消除了稳定性方面的影响。

合并分批推进，该项完成后取得 Flink Hudi 入湖集群计算资源削减 20% 的治理收益。

Bucket Index

实时表入湖合并方案上线后虽然使集群资源用量得到削减，但在数据业务团队对数据新鲜度愈发强烈的背景下，一段时间后规模用量再度翻涌上来。此外，在 flink on emr yarn 模式下经常因计算节点异常导致任务重启现象，而 flink hudi 每次重启状态恢复的代价极大，个别大表会卡在 bootstrap 阶段长达半小时以上，导致实时 ODS 层数据 SLA 频繁遭受质疑。

针对此问题的解法来自于社区，这正是开源技术的魅力所在。Apache Hudi 在 0.14 版本支持 Bucket Index 方案，与其他索引机制相比尤为特殊，其核心实现原理是基于记录键哈希值进行确定性分桶，通过预分桶机制避免全局索引性能开销，客户端在插入过程中，直接定位传入记录对应的待写入文件位置，无需顾及全局性记录键分布情况，原有备受诟病的 bootstrap 和大状态存储问题也随之得到根除。

因 Bucket Index 改造涉及实时 ODS 层数据，需严加谨慎对待。数据团队先针对该方案实现原理进行剖析研究，接着集成到平台上验证测试，平台开发人员按功能和性能类别分别进行验证，覆盖十几种测试用例场景，充分验证效果符合预期后再结合 Flink & Hudi 升级规划，分批切换生效，最终无损完成全量 flink hudi ods 表 (上千张) 的升级切换。

在推进升级切换的同时，也完成全量 hudi 表任务 flink on yarn -> k8s 的平滑切换，Hudi Bucket Index 方案上线后效果极其明显，以如下一组数据体现：

2.3 阶段二治理小结

相比于第一阶段，第二阶段的成本治理迈入更深层次的优化领域，为达成治理目标，除上文列举的典型优化方案外，内部还制定了多个治理专项，采用双线并行推进模式，在保持业务增量的前提下再度实现月成本节约 30% 的治理效果。

体系化治理构建

前两个阶段成本治理以技术视角开展，在取得成果的同时也意识到一些局限性，即单纯依赖技术优化难以实现可持续性的体系化成本管控，需从更高维度的能力建设入手。阿里的数据治理实践指出，成本治理的核心目标应聚焦于人效和资源，通过技术平台建设提升单位人效也是一种至关重要且有效的降本措施，这也是我司投入大量资源建设大数据研发治理平台套件的一大根因。

在平台范围内，从数据生产到数据消费涉及的环节和处理链路繁多且复杂，而首要难关就是如何识别并分离数据处理链路。若能针对每个处理环节给予标签定义，再辅以一定程度的量化 (计量和计费)，即可持续性进行全链路数据成本治理。治理的理想状态是经由平台工具化将治理过程的理念、方法、流程沉淀下来，再结合多维度治理措施，实现在数据开发交付过程中顺带完成数据治理，达成治技合一的效果。整体框架遵循如下原则：

3.1 成本数仓

成本数仓按 ODS、DWD/DWS、DIM、ADS 等经典层级结构设计即可，层级越简单计算损耗越小。

指标定义

在大数据平台中成本消耗来源众多，典型成本来源包括：

物理机计算资源：CPU、GPU、内存、硬盘等

网络传输：交换机、路由器、网络带宽等

机房基础设施：机柜租赁、电费、防火墙等

大数据平台架构各层软件服务研发成本

现实中，我们很难将单一性计算任务与上述所有环节链路花费关联起来，因此只需将数据平台上可用于优化和治理部分成本信息予以量化即可，于大数据平台而言，主要以 存储和计算 这两类指标作为量化表达，如：

离线计算任务：CPU、MEM、计算缓存容量、任务归属元数据信息

Hive、S3：表 / 分区存储容量、路径访问频次及类型、资产归属元数据信息

量化

计算实际成本的规则极为复杂，如阶梯式计费、折扣、代金券、波动用量、分摊等，需要系统性工程建设。受限于大量细分计费项无法关联到业务团队一级，一种较为可行的量化方案是结合业务用量再构建一层抽象定价关系，即以达成收支平衡为目标对云资源用量再作售卖。

计算层

对于计算任务的资源指标量化均按 CPU(vcore_second)、MEM(mem_second) 每秒用量进行量化，实现计算任务在 YARN 或 Kubernetes 运行时指标度量统一，便于后期资源使用分析、成本分摊与治理。

存储层

以 S3 为例，其计费体系极为庞大，有冷热分层、阶梯式存储用量计价、操作分类计费等数十种细分类型，概括起来可分为三大类：存储、数据请求、数据传输。

计费说明及定价实现参考

存储

SS/FA 层：¥ 0.006122 per GB / day，IA 层：¥ 0.004397 per GB / day，AIA 层：¥ 0.001098 per GB / day

假设 A 用户使用 s3 多个桶总存储 1PB，各层存储用量分布 (SS 层 /20TB、FA 层 /150TB、IA 层 /170TB 、AIA/660TB)，则日均存储量化成本 = ¥ 2600.5504 / day，转化为 GB 的存储单价费率为¥ 0.00248

计算每日量化成本与账单成本的差异系数 (折扣影响)，如系数为 1，则存储单价费率不变

数据请求：处理 access log 访问明细数据，按 operator 类型划分 ETL 处理还原计算出路径产生的读写请求费用

用户可基于资产用量和每日单价费率，以通俗易懂的方式计算得到存储成本量化参考。

数据采集与建模入仓

在成本领域中除资源使用计量外，还需采集云厂商账单数据、API 调用和日志数据等，以补充成本分析维度信息。数据采集入仓时命名需符合规范。示例：

ODS 层，库名：ods_govern

DWD 层，库名：dwd_govern_cost，表命名规范：{一级主题}_{二级主题}

成本数仓涉及业务过程较为单一，主要以实现成本 [量化 + 分摊] 为业务核心，建模部分可遵循 OneData 概念，以维度建模为基础构建总线矩阵，定义业务域、数据域、业务过程、度量 / 指标、维度、维度属性。入仓 ETL 时需预先规划数据加载和更新策略，分场景采取增量或批量处理等方式，确保成本数据及时、准确地在各层传递。

3.2 持续化治理产物

数据治理平台

治理到达一定程度后，为实现常态化、持续性的治理目标，需要工具平台提供支撑，数据治理平台随之诞生。我司的数据治理平台自顶向下采用三层设计。

治理领域层：按业务特性划分，如成本 (计算和存储)、质量、稳定性、安全等

治理对象层：领域内治理目标，如计算任务、存储表、数据开发过程质量等

治理项层：可执行的具体动作，如计算任务资源优化、存储表数据活性度等

用户可在此框架内定义和捆绑治理任务，底层治理项数据均来自指标平台，依托于成熟的指标管理体系，最大程度削减口径确认和数据处理成本。

双层治理协作模式

以过往的治理经历而言，采用双层治理协作模式（用户层治理和平台层治理）效果最佳，双方以 OKR 作为媒介对齐治理目标后，各自开展治理行动项。以成本治理为例，双方协作方式如下图所示：

平台层治理

平台层接入各类治理类指标后抽象为计算、存储两类可治理资源，根据预设规则判定形成待治理项，确保治理过程标准化和自动化，待治理项生成后推送给负责人做后续治理操作，同时平台会监控治理进度，量化治理效果。除此之外，平台层对技术架构改进优化实现成本优化的幅度是巨大的，如对平台计算引擎升级、汰换和湖仓一体迭代升级等。

用户层治理

用户层负责具体治理措施的执行和业务层面的优化，基于已制定的预算和治理目标，有节奏地开展治理事项，在治理完成后查看治理收益，评估投入产出比。需特别注意的是：平台在建立用量管控机制的同时，需完善项目 ->组织架构>层级关系，按组织架构治理推进的优势是方便直接找到相干人，便于追踪和跟进目标进度，依托于组织架构的上下级汇报关系，能使治理推进更加顺畅。

治理健康分

治理类别划分多个领域，涉及资源成本、数据质量、数据安全、数仓 / 组件稳定性等各个方面，围绕着这些领域会各自形成具体的治理策略和方法，在运营发展到一定阶段时，就需要一个多方共认的治理考核指标 (如健康分)，使各个团队有一个统一的量化标准，共同朝着同一个目标努力。

健康分是以数据资产在数据生产、数据流通、数据特性、数据管理、任务性质等元数据为依托，经模型化数据处理后进行综合评估，在个人、组织的维度呈现资产状态的综合分值。以成本领域 -spark 任务计算这个治理对象为例，我们将其拆分为五个维度呈现：

这种多维度的健康分评估体系，能够较全面地反映治理对象的健康状况，同时结合数据治理运营机制，周期性调整维度组合和权重，避免健康分计算失衡。

结 语

以当前视角回顾大数据成本治理历程，能深刻体会到成本、稳定性、易用性三者之间既互斥又平衡的三角博弈关系，表象为：追求成本最优往往需要在稳定性和易用性做权衡取舍；过度成本压缩会极大概率地增加系统不稳定性；过分追求平台易用性和稳定性则会带来资源成本浪费。因此，成本治理绝非简单的降本行为，而是在多重约束条件下寻求最优解的系统工程，这种平衡关系不能一蹴而就，需要在持续的实践中不断调整和完善。

道虽远，行则将至。在大数据成本治理这一漫长而复杂的道路上，从最初的被动应对成本压力，到如今建立起相对完善的治理体系，这一路走来充满挑战与收获，特别感谢在此历程中内外部团队的大力支持，才让我们在治理这条道路上披荆斩棘。

未来，随着业务规模的持续扩大和技术架构的不断演进，成本治理工作亦将面临新的挑战和机遇。我们将继续秉承精益求精的态度，在实践中总结经验，在创新中寻求突破，为构建更加高效、稳定、经济的大数据平台而不懈努力，愿我们都能在各自的技术道路上行稳致远。

作者信息

吴建阳，朴朴科技大数据运维负责人，在大数据平台离线 / 实时计算、数据湖、OLAP 等基础设施，具有多年的大数据实战经验。

今日好文推荐

来源：极客邦科技