蚂蚁集团 EB 级大数据治理架构与实践_

导读本文将分享蚂蚁集团在大数据治理实践过程中沉淀的经验。

主要分成四个部分：

1. 数据治理概况

2. 数据质量治理

3.数据计存治理

4. 对数据治理未来的思考

分享嘉宾｜彭欢蚂蚁集团资深数据研发专家

编辑整理｜汪维

内容校对｜李瑶

出品社区｜DataFun

数据治理概况

业界对于数据治理的定义有很多种，蚂蚁在数据治理时主要关注对企业运转非常关键的架构、安全、合规、质量和价值这五个方面。

为什么是这五个方面呢？

首先，要保证整个数据在业务上是可以流转起来的、是可用的，包含两个基本要求：首先是要符合最近关注度非常高的用户隐私、反洗钱等监管法律的要求，保障数据是合规的；第二是要保证数据在各个环境上的存储、流转和使用都是安全的。这些是在安全合规领域要重点去解决的问题。
其次，交付给业务的数据不能错漏，也不能延迟，这属于数据质量范畴，这个领域主要解决让业务敢用数据的问题。
另外，大数据领域有非常多的人在协同开发，希望产出的数据是有序的，既是可复用的又是好用的，所以，需要重点做好数据架构的规划和治理，包括数据模型设计、数据标准规范和主数据等。
最后，数据是一个闭环的生态，从拿到数据到加工数据，再到赋能业务，希望整个过程是可持续的，在这个可持续的过程中需要有数据价值的体现。价值可以分成两类，一类是负向的价值成本，包括数据运转过程中计算、存储、数据资产带来的机器资源成本；另一类是正向的业务价值，是指数据被使用消费过程中发挥的价值。业界一直在关注数据的正向价值，从数据要素来讲，核心是将数据从原来的资源或者产品，转化成面向未来的商品。对数据价值的衡量是未来一大趋势。

本次分享聚焦于其中的两个命题：数据质量治理和计存治理。接下来将分别进行介绍。

数据质量治理

1. 数据质量产生分析

蚂蚁的数据来源众多，包括行为日志、系统服务端收集的数据等。从类型上看，有DB 类、日志类、log 类等，还有消息类的和非结构化的数据。大模型出来之后，我们通过一系列工具，将这些数据都存储到了蚂蚁一站式的大数据工作平台上，经过批流的处理进行分析洞察、决策服务。也就是说，数据从业务中来，通过模型算法加工，最终又回到了业务中去。整个流转过程非常复杂，涉及到很多的工具引擎，中间任何环节和操作都可能引发数据质量问题。提供给业务的数据错了、漏了或者延迟了，是经常遇到的一个痛点。

2. 数据质量治理挑战

在介绍蚂蚁如何进行数据质量治理之前，先来了解一下蚂蚁的业务形态。第一部分是大家感知的“冰山之上”的 C 端业务，包含芝麻分、蚂蚁森林、花呗、借呗等；第二部分是面向机构监管的“冰山之下”的业务，包括机构清算、计息、计提等，这些业务需要大量的技术支撑，甚至是数据加算法融汇，以追求价值的最大化。在金融业务极度严苛的要求下，做好整体的数据质量保障是非常重要的。

数据质量治理面临着诸多挑战，主要包括：

业务方面：蚂蚁业务发展快，变更非常多，任何一次变更出错都可能有很大的影响。无论从用户体验，还是智能化角度，对数据产出的时效都有非常高的要求。
数据方面：大部分是金融层面的业务，对数据质量的要求也非常高。
用户方面：整条链路上有非常多的角色参与，比如有 BI 团队、技术团队、数据团队和产品运营团队等等。每个人的基本认知和专业水平都不一样，人为操作可能也会带来一定的风险。

目前蚂蚁整体日均变更任务量在几千次以上，每天日运行任务调度实例达到了百万次以上，数据应用的核心消费场景有数万个，数据质量已经成为蚂蚁业务发展的基石和驱动器之一。这也是为什么今天蚂蚁非常重视数据质量建设的原因。

3. 数据质量顶层设计

在这么复杂的情况下，怎么解决数据质量的问题呢？单点处理问题很难全面保障数据质量，很有可能拆东墙补西墙，或者这里解决了那里却漏掉了。进行全面的数据质量治理，需要有良好的顶层设计，我们将风险分成三类：数据技术引擎风险、数据内容风险及数据应用风险。

具体落地的核心思路如下。首先，保障目标重点聚焦于高可用和资金安全业务场景：

事前，做到整体的研发质量保障，包括测试、仿真等工作；
事中，重点解决变更风险的管控；
事后，当出现问题的时候，要确保整个生产运行是高可用的，需要重点建设主动发现和快速恢复的能力。
另外，还成立了数据和技术的联合蓝军对整个保障体系去做攻击，来验证布防是否可靠。

4. 数据质量治理架构

从纵向来看，蚂蚁的数据质量治理架构总体分为三层：

能力层，包含质量管控、质量识别、故障恢复和风险治理的能力，并建立了统一质量元数据中心，为后面 AI 加质量的尝试及相关能力的演进打下了一个非常好的基础。建议在做质量风险保障时，要重视元数据的建设，而且前期就要做好规划。同时，围绕元数据，我们结合大规模机器学习等算法去尝试探索智能化的波动、异常、离散等异常及风险点的识别。
系统层，主要围绕数据测试、发布管控、变更管理、质量监控、应急演练和质量治理建设六大产品的能力。
业务层，作为数据中台，产品能力开放给业务数据团队、质量团队使用，帮助建设每个业务数据质量的门户，包含整个应用分级管控研发流程、全链路的质量监控运维平台等。

从横向来看，质量治理贯穿全链路系统，并建设了组织文化和制度规范。组织文化包含数据攻防、质量审计、质量保障小组等，做到了全局高效拉通。制度规范包含质量保障规范、基线管理手册、发布变更手册等，形成了全局制度上的规范。

在整个实施过程中，重点是以止损量/故障数核心指标为抓手，发现保障体系里面的问题，通过核心指标驱动整个体系持续地迭代和优化。

5. 数据质量治理方案

接下来深入介绍数据质量治理围绕事前、事中、事后的技术能力。技术上处理离线数据故障有一个核心目标——“五分钟内发现故障，五十分钟内恢复执行”。处理线上数据故障的目标是“一分钟发现问题，五分钟定位问题，十分钟恢复执行”。之所以离线和线上的目标不同，是因为离线数据整条链路比较长，定位和恢复需要较长的时间，另外，当前的故障发现能力、元数据时效性等也存在一定局限性。

执行的核心策略包括事前、事中、事后三部分。

事前要做到可管控、可仿真和可灰度，在需求阶段做分级变更定义，在研发阶段做规范、测试和发布，在预发阶段做仿真回放和 AB 灰度；
事中要做到可监控、可演练、可应急，数据全链路和应急监控等各个环节都能做演练和巡检；
事后要做到可度量、可审计和可持续，包括事件管理、问题故障审计报告、案例学习和晋级可晋级考试等，蚂蚁每年会有一次公司级别的数据红蓝攻防，也有一年两到三次的必须参加的安全生产晋级考试的运营活动。

6. 数据质量治理案例

（1）数据变更免疫

数据变更免疫的核心目标是希望让错误代码不发布到生产。为了实现这一目标构建了几道防线：事前构建变更准入防线，将变更必须满足的“三板斧”要求、发布窗口要求等风险底线要求植入到变更准入的防线；事中构建变更灰度防线，在变更生效之前，用真实的流程去预验验证，提前发现问题；事后重点是变更监控，变更生效之后，能够持续监控变更的业务变化，有问题快速进行恢复。

下面这张图，是面向发布环节研发的发布管控产品。

所有的变更在通过该产品发布都需要进行校验，类似于现在业界比较火 DataOps，将测试、灰度、仿真、监控全部纳入到流程中，做到在发布的时候自动化地进行质量监控和巡检。

（2）红蓝攻防

红蓝攻防的核心思路是通过故障的注入，对生产链路进行模拟攻击，发现防控体系的薄弱点。

模拟在线环境，用任务攻击和数据攻击两种方法进行攻击。在进行数据红蓝攻防的过程中需要解决三个核心问题：

如何不影响生产？因为数据是一条链，上游污染了，整条数据就污染了，而且恢复成本极高。在生产环境中，构建仿真无损环境进行无差别的供给，通过攻防平台相应的数据链路在无损环境里面去植入，从而不影响生产环境。
如何选择攻击对象？主要选择数据入口，比如数据同步、回流任务、人群标签、有时效性保障的业务基线场景等，要重点关注有止损、有舆情的场景，比如算钱等更重要的且效果更显性化的场景。
如何有效地攻击？要确保所有的攻击字段能够帮助业务发现有效的生产风险，核心是通过历史故障的分析和平移，以及重大业务变更的演练。另外，在核心的攻击能力方面，构建了 SQL 注入等能力，以及数据大幅度波动、内容格式突然异常、资金字段错位、任务重复的回流等多种方法。

红蓝攻防在蚂蚁连续组织了四到五年，整个公司级别的红蓝攻防自动化的攻击次数达到四十多万次，推动数据质量核对规则和配置超过了五十万家，也发现了非常多的潜在问题。

数据计存治理

1. 数据计存治理面临的挑战

下面这张图是 2019 年蚂蚁离线集群存储使用率的曲线图，安全存储的水位线是 85%，一旦超过了 85% 就可能引发异常问题。从图中不难发现，2019 年下半年集群存储使用率都在 85% 以上，当时出了不少安全生产问题。

计存治理会影响到安全生产。当时集群的物理容量规模已经达到了 EB 级，大概有几百万张数据表，参与数据研发的人员数量是几千级别的。在这样一个背景下，我们开始思考计存治理的方案。

2. 数据计存治理核心思路

计存治理的核心思路是从组织设计、规范制定和平台建设三个方面去落地。执行的时候，通过战役拉动支撑整个业务并进行资产升级，通过运营活动进行成本规范的传播和文化的建设。

在组织设计层面，成立了数据架构小组。从架构域的维度统筹整个公司的数据架构和成本治理的工作。设立数据管理岗位和晋升的通道，制定研发协作机制和流程。其中，数据管理的岗位和晋升通道的设置非常关键，因为数据治理和数据管理，与数据研发，虽然都属于数据域领域，但能力与技能要求是不一样的，成长需要以不同的视角去看，所以设计了独立的晋升通道。
在规范制定层面，产出了蚂蚁数据架构规范、研发管理规范和数据治理管控规则。
在平台建设层面，研发侧正向地提升研发质量和管控资产无序增长，治理侧搭建平台化的治理工具，形成一套自动化的治理机制。

3. 数据计存治理策略

从开源和节流两个方面具体落地实施。

开源：数仓原来的资源是独享的，数仓和在线是分开的，而且数仓资源需求量非常大。在线数据库的资源使用率不高，基本在 25% 左右，夜间使用率可能更低，而输出储藏在夜间有非常高的计算资源需求，能不能把在线数据库空闲的资源共享给数仓离线计算呢？
节流：整体逻辑是数仓从任务和数据的角度尽可能去优化和节约，包含存储治理、计算治理、任务治理。

4. 面向开源的数据计存治理方案

以前数仓是独立的专用集群，机器、存储均独立购买。为了提供高效服务，在线应用会在本地化进行多层部署。要能与在线应用混合部署，首先要把数仓集群的架构变更到能跟在线应用混部的跨层模式，既可以提升资源利用率，又能保证稳定性。如果做成这样的“机房架构”，有两个问题必须解决：首先，如何确保数仓在高峰期不受在线资源的抢占，保证数仓高保业务在高峰期仍然可以稳定运行；其次，数仓有大量的数据交互，一旦跨层会有大量的跨层数据访问，从而带来大量的网络开销，这也会直接影响数仓的正常运行。

为了解决这两个问题，核心有三件事：

将数仓应用层的数据访问统一收敛到数据中间层；
对数据中间层的热数据做跨层冗余；
将业务进行分级，对于高保的业务给予独占的资源，跟在线资源做适当的隔离，防止资源挤占。

存量的数据任务都是开放读取的，也存在大量的跨层访问，需要将存量也无风险迁移到整个混部的集群上来。

事前做项目规划，对业务项目划分、资源使用进行评估，产出迁移的列表；事中进行迁移的改造工作，包括部署巡检规则、进行代码改造和架构的升级、部署发布管控，避免热度及大表跨集群拷贝等；事后，做日常的巡检和持续优化，包括对跨层任务持续的监控、对不合理的代码进行改造、对热表做集群的缓存等，减少网络带宽带来的集群负载。

完成混合部署后，数仓可以共享在线资源，在没有额外增加机器成本的情况下，整个数仓增加了 50% 的可用弹性计算资源，而且数仓任务平均等待时长降低了 50%，同时，在线应用的 CPU 利用率也从 25% 提高到了 40%，从全局来看，资源利用率提升非常明显。

总结来说，开源的思路就是在做数据治理的时候不仅仅是只看数仓，还要将数仓的上下游及周边环节协同起来，作为一个整体来看。

5. 面向节流的数据计存治理方案

面向节流的优化可以分成几类：

引擎优化，比如参数优化，调度优化；
模型优化，比如数仓架构的链路、数仓设计、代码语法、数据压缩格式等；
代码优化，比如 join 的优化、UDF 的优化等；
资产管理优化，如果整个链路在业务上都没有应用，则考虑链路的整体下线，实现更敏捷的下线。

节流的整体思路就是用技术的方法提升治理自动化率，实现自动识别、归因分析、自动清理，形成常态化的管控能力。

下面分享两个“小成本，大收益”的案例。

（1）渐进计算

渐进计算的适用场景是固定窗口或者滑动窗口指标计算。有固定起止日期的时间段叫固定窗口（比如年度、1 月 1 日至今等），有固定时长的时间段叫做滑动窗口（比如近 30 天）。固定窗口和滑动窗口计算相同指标时有很多共性，两者在计算过程中的中间表是可以复用的，如果每次查询都重新计算就会造成计算资源的浪费。渐进计算的核心原理是“用空间换时间”，自动生成可持续滚动中间表，将中间计算的过程表保留下来，每次查询时用哈希的方式快速去读取，不用再重复计算。上图右侧是一个风控业务的案例，用渐进计算优化后，每天计算消耗从 795 CU 降到了 22 CU，收益非常显著。

（2）存储归档

存储归档适用于数据查询频次不高的冷数据场景。通过对数仓数据的初步分析发现，一般访问当天数据的频率在 80% 左右，访问前一天数据的频率在 10%-15% 左右，3 天前的数据很少被访问。同时，考虑到一旦对冷数据进行压缩或者重排之后，存储空间虽然会下降，但是读取时的计算性能会消耗比较大，综合考虑，将一定时间内（比如 7 天、30 天等）未被读取的数据定为冷数据，对其进行压缩处理。当然也不是“一刀切”的方式，可以基于更精细的分析进行冷数据的定义和处理。

冷数据的处理逻辑分为两类：

一类叫归档，核心就是采用 RAID 格式的存储，用 n 个数据块和 m 个校验块的模式建设归档的能力。这样，用 8 个数据块和 3 个校验块就达到了 1.375 的备份，一般都是 3 备份。

另一类是重排压缩，是 distribute 和 sort by 的结合，与电脑的磁盘整理一样，当很多空间是碎片化存储的时候，通过重排压缩把行与行之间相似的字段压缩存储。比如，相邻两行都有彭欢，存储的时候只存一个彭欢，并且告知两行都有彭欢的信息，用这种模式去优化存储。用技术的方法，不需要进行各个团队到每个人的存储或者优化，就可以带来非常大的收益。在一个案例中，网关流量日志重排压缩后，减少了约 30% 的存储容量。当然在进行重排压缩的时候也有一些注意事项：distribute 环节不要将数据打散；不适合 Json 串类型字段，重复率不⾼；不需要 order by 全局排序，sort by 分区内排序即可；归档操作降低了可靠性，不如默认的 3 副本。

进一步，希望根据数据的冷热程度，建立自动化的识别和分级存储方案，从而实现成本的分级优化。

将数据分级成四类，在用户无感知的情况下进行自动化的数据差异化存储。

高频访问：热点数据，1 SSD + 3 HDD
热数据：访问频率正常，3HHD
归档数据：数据需要长期保留，访问频次低的，1.375 RAID HDD 归档模式
冷备存储：数据需长期保留，访问频次极低（比如监管数据等），单独建立了冷备集群，压缩比非常高，但是读取时耗费的计算资源比较高，一般是以 90 天的逻辑长期保留。

对数据治理未来的思考

最后，分享对数据治理未来的几点思考。

一体化：数据在哪里治理就在哪里，随着大模型、ChatGPT、AI 的出现，以及蚂蚁自身业务的发展，目前关注在传统离线上的数据治理，未来会转变为基于湖仓一体（在线、离线、实时、图计算等）做一体化的数据治理，解决成本、合规和效率的问题。
价值化：数据作为生产要素，从内部的产品变为流通的商品，涉及到共享交易和开放，在数据确权价值的衡量及隐私保护方面去探索和突破价值点。
智能化：加入大模型做更智能的数据治理，原来是人工走向规则，接下来会探索更智能的方向。

以上就是本次分享的内容，谢谢大家。