• 卢经理 151 5399 4549
    扫一扫,加我咨询
扫码关注我们
蚂蚁集团 EB 级大数据治理架构与实践
发布时间:2024-04-30

一、数据治理概况

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

图片

为什么是这五个方面呢?

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

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

二、数据质量治理

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