企业降本增效是越来越热门的话题，2022年大数据平台面临容量增长快，成本压力大，在二十多个部门紧密合作下，通过建设大数据平台容量管控体系，全方位应对容量挑战，最终完成2022年容量控制目标。在此回顾一下大家是如何实现降本增效的。
一
大数据平台简介
首先简单介绍一下微众银行大数据平台架构体系，是一套一站式、金融级、全连通、开源开放的大数据平台套件，从建设之初就确立了开源+自研的研发路径，依托开源社区力量共建金融级大数据平台能力。当前已具备了数据开发应用管理的完备能力，形成了一个“434”阵型：
1. 前场，是数据分析、数据治理、机器学习和运营管理 4 大功能工具工场，提供完整的数据+AI应用开发管理能力。
2. 中场，是计算中间件、元数据中间件和微前端中间件；做到承上启下，提供连通、管控、扩展、复用等独有的中间件能力。简化平台整体架构，降低开发运维成本。
3. 后场，是批量计算、交互式计算、流式计算和复杂计算 4 大基础计算存储模块。提供面向各场景的基础计算存储能力。
整个大数据架构是自上往下、相互依赖的体系，承载的业务应用也是丰富多样，各应用之前相互依赖，由此引发的容量管控也会比较复杂。
二
为什么要做容量管控
在平台规模还比较小的时候，业务对大数据处理能力需求丰富，平台建设优先完善平台功能建设。提供完整、丰富的数据处理分析能力，未对各业务应用的存储容量和计算资源强加限制，以满足业务需求。各业务应用的快速上线，大量数据重复全量抽取、多次拷贝，在数仓架构上未统一规划，数据存储容量快速增长。同时一些计算量大的任务较少考虑性能优化，主要靠增加计算资源来满足任务时效。
近年来，随着业务的发展，各种数据存储和分析的需求快速增加，到2022年初，集群机器数已达几千台的规模，其中批量集群存储几十PB 数据，日增上百TB，每天离线计算任务有近百万级。根据近年的统计数据，差不多每年有50%左右的机器规模增长，带来了较大的成本压力，容量管控迫在眉睫。
三
面临的问题与挑战
我们如何才能在保障平台和应用稳定，保障数据任务准点执行完成的要求下，将成本降下来。这驱使我们必须建立一套容量管控体系，在资源使用方和资源管理方紧密合作下，通过升级技术，完善工具，并在此过程中控制风险来达成。
2022年大数据平台的容量管控主要是批量集群的存储容量管控。面临的问题和挑战主要体现在为四方面：
指标体系：基础运营数据指标体系不完善，管控前的指标粒度粗。
流程机制：预算和容量预警等流程机制不健全，大数据成本未能透明到业务侧。
平台工具：工具功能缺失，风险控制能力、性能等均需大幅提升。
业务应用：涉及几十万张表，关联业务和子系统多，数据上下游依赖复杂，需充分评估影响，沟通成本大。改造和清理需确保业务稳定和数据正确，改造成本大。
四
如何做容量管控
我们批量集群容量管控的思路如下：
首先是对数据资产梳理，完善指标体系和流程机制。业务方根据业务价值做每年的预算，并以此预算建立每月预算限额和对应的容量限额，通过报表形式透明各业务方容量使用及成本分摊情况。
其次是由平台从基础引擎和功能工具上进行技术优化，为业务提供成本治理的方法和工具，比如说数据压缩能力，表删除能力、生命周期能力、归档能力等能力。
最后是业务方的基于数据价值、管控目标，利用基础引擎和功能工具提供的辅助能力，优化数仓模型架构，实现容量控制，从而降低成本。
通过对指标体系、流程机制、平台工具和业务应用四方面的多轮迭代，不断完善容量管控体系，总体如下：
下面针对指标体系、流程机制、平台工具和业务应用，详细介绍具体如何落地。
1、指标体系建设
整个平台的运营指标，通过统一的数仓架构进行构建，分为ODS数据采集层、DM数仓层和ADS应用层。对批量计算、交互式、流式计算、复杂计算，进行统一采集运营数据到Hive容量报表数仓，各层级不同组件之间的加工依赖通过调度系统信息串联，各个组件的采集指标都拆解并关联到部门/科室、业务产品、子系统维度。以批量集群存储容量为例，直接管控指标包括：总存储量、总存储限额，日增存储、日增限额、剩余可支撑天数、评价指标（压缩占比、归档占比、冷数据占比、全量切片占比、ODS占比，疑似重复数据占比等）。
2、流程机制建设
主要建立了两套管控流程：预算跟踪和容量预警。提供涵盖大数据平台所有组件、统一的预算评估计算公式模板，供各业务应用方结合业务需求、业务价值、合理性维度进行评估，并将预算提交部门领导审核后统一上报，最终根据确定的预算额度制定每月预算限额，每月容量限额。每月统计各部门容量和预算使用情况进行跟踪，结合管控指标进行分析，对预算/容量预测会超限的部门预警或升级，提供优化措施和优化完成时间。
3、平台工具完善
对于存量容量的控制，要实现控增量，降存量，需要对底层基础引擎和功能工具进行开发，以支撑最终降本的目标。
在批量计算基础引擎上，Hive、Spark统一推荐使用ORC+Snappy进行压缩存储，通过开发修复各种数据精度和兼容性问题，通过多轮测试，根据不同应用场景、不同租户逐步灰度开启了BDP（Big Data Platform, Hadoop批量集群，承载核心批量）和BDAP（Big Data Analytical Platform, Hadoop批量集群，用于探索分析）的默认压缩功能。
通过分析，批量集群上的大部分历史数据很少访问，因此引入Hadoop的分层存储技术，开发相关功能，让我们的Hadoop联邦集群支持归档能力。通过采购更高存储密度的专用归档机型，压测通过后，用于将不能通过下线无用表、数据生命周期来节省成本的数据，进行归档存储。实现方式是对存储介质加上标签，然后将需要归档数据设置成Cold (默认为Hot)，然后执行HDFS的Mover命令，将归档数据从计算机型移动到归档机型上。该归档机型不具有计算能力，只提供数据存储，单机存储容量是计算机型的9倍，单机价格只是计算机型的1.7倍。整个归档过程对用户无感，无需恢复即可访问历史冷数据。
Hadoop引入归档后，计算机型的扩容将会变少，对于计算资源的消耗需求还在，因此还对YARN调度性能进行优化，通过优化排序比较函数、优化作业跳过时间、队列并行排序优化等技术升级。同时提供基于规则的动态队列功能，定时调整同部门下多个队列的计算资源配置，实现计算资源的充分利用。
在功能工具上，通过开发运营门户系统(Portalis), 元数据中间件(DataShapis)和数据操作管理系统(DOPS)辅助进行容量管控的落地。其中Portalis提供预算管理和成本分摊功能；DMS提供元数据管理，数据血缘分析，生命周期规则管理功能，降低操作风险，提升管理效率；DOPS串联DataShapis、计算中间件Linkis和数据质量校验Qualitis，提供数据压缩，数据清理与恢复，数据归档和小文件合并功能，在确保数据准确和可恢复前提下，完成管控措施的真正落地。DOPS系统架构如下：
4、业务应用优化
整个批量集群容量控制，最终都需要由各业务应用方通过制定相关规则和进行数仓架构优化才能真实落地。各业务应用方利用平台提供的运营数据，进行数据资产梳理，进一步将表归属及目标分解到对应具体的负责人，识别依赖，评估操作风险，提单申请进行数据压缩、无用表下线、数据生命周期清理和数据归档。同时通过优化数仓架构和业务逻辑，制定数仓开发规范，开发拉链表改造工具，逐步实施每日全量切片改增量切片或改造成成拉链表，降低日增存储。
五
容量管控效果
通过各部门的紧密合作，容量管控效果显著。2022年管控后，总存储量较管控前增长预估节省几十PB,日增降幅30%+，预估节省成本（包含增量收益）在千万以上。
同时DOPS数据清理性能从提升到百万分区/天，提升10倍；数据压缩性能也提升到上百TB/天，提升17倍；数据归档性能提升到近百TB/天，提升73倍。相关工具的逐步完善为长效容量管控夯实基础。
六
总结与展望
回顾2022年的整个容量管控过程，容量管控体系分为指标体系、流程机制、平台工具和业务应用。通过指标体系建设，让业务方了解各业务产品在大数据平台上的资源及成本使用情况，更好地评价数据的业务价值；通过预算和容量预警机制，确保预算和容量使用情况得到有效跟踪；通过对基础引擎和功能工具的建设，帮助业务方在风险可控条件下进行容量控制，提升容量管控的效率，实现降本增效；通过业务应用侧深入优化，从根源上实现批量计算存储增长更可控，与业务增长曲线更吻合。
最后分享一些成本管控的思考与展望：
首先，成本管控需要依靠于体系化的建设，相关指标、流程机制和平台工具的完善是整个管控过程能够有效运转的基础。这样才能实现业务的自助式治理从而达到持续控本目标，这样做大数据团队可以释放更多精力进行一些技术相关的成本优化探索。
其次，大数据场景多样性且有个性化特征，成本优化需要持续精进不断地探索。2023年将继续在现有基础上完善数据生命周期管理，同时覆盖交互式计算、流式计算和复杂计算等基础引擎。如ES/KAFKA/HBASE等小集群合并；批量集群减少不必要的容量同步，优化容灾；细粒度的行列授权支持，用权限控制替代行列拆表，减少数据拷贝；BDP和BDAP计算资源打通，提升资源利用率；以及对批量Job进行任务诊断，基于健康度的方式进行运营，持续优化。
第三，大数据计算存储技术快速更新，存算分离、容器化调度、湖仓一体、流批一体等技术是大数据发展的趋势，我们也将探索计算存储成本更低的技术，进一步实现成本优化。
如何成为社区贡献者
1 ► 官方文档贡献。发现文档的不足、优化文档，持续更新文档等方式参与社区贡献。通过文档贡献，让开发者熟悉如何提交PR和真正参与到社区的建设。参考攻略：保姆级教程：如何成为Apache Linkis文档贡献者
2 ► 代码贡献。我们梳理了社区中简单并且容易入门的的任务，非常适合新人做代码贡献。请查阅新手任务列表：https://github.com/apache/incubator-linkis/issues/1161
3 ► 内容贡献：发布WeDataSphere开源组件相关的内容，包括但不限于安装部署教程、使用经验、案例实践等，形式不限，请投稿给小助手。例如：
4 ► 社区答疑：积极在社区中进行答疑、分享技术、帮助开发者解决问题等；
5 ► 其他：积极参与社区活动、成为社区志愿者、帮助社区宣传、为社区发展提供有效建议等；
本文分享自微信公众号 - WeDataSphere（gh_273e85fce73b）。
如有侵权，请联系 [email protected] 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。