业界对于数据治理有很多概念，回到蚂蚁，我们在大数据治理方面，核心关注对企业运转非常关键的几个点，抽象出来即合规、安全、质量、架构、价值5个方面。
首先，要保证数据在业务上是可以流转起来，可用的。包含两点，第一要符合用户隐私、反洗钱等法律监管，保障数据是合规的。第二是保证数据在各个环境上的存储、流转和使用上的都是安全的。
其次，我们交付给业务的数据不能错，不能漏，不能延迟，这属于数据质量的范畴，解决让业务敢用数据的问题。
再次，整个大数据领域有非常多的人进行协同开发，我们希望数据产出之后是有序的，既是复用又是好用的，需要重点做好数据架构规划与治理，包括数据模型设计、标准规范和主数据等。
最后，数据是一个闭环生态，从拿到数据到再加工，然后赋能业务，希望整个过程是可持续的。在可持续过程中，需要有数据价值体现，这里的价值分成两类，一类是负向价值成本，包括数据运转过程中的计算、存储和数据资产带来的机器资源成本；另一类是正向业务价值，包含数据被使用、消费，以及过程中发挥的价值，甚至产生更好的效果、更大的价值。
今天时间有限，选两个命题分享，数据质量治理和数据计存治理的具体实践和经验。
一. 数据质量治理
说到具体怎么保障大数据的数据质量，首先得看数据质量是怎么产生的。
面向蚂蚁有很多数据来源，不管是行为日志，还是系统服务端收集的数据，这里数据类型包含 DB 类、log 类的数据，还有一类是消息类数据，通过一系列工具会落地到蚂蚁的一站式大数据工作台里面，经过批流处理、分析洞察、决策服务。在这个过程中，数据从业务中来，同时经过大数据平台加工，最后数据又回到了业务中去。其中涉及到非常多的工具引擎，整个数据流转也是很复杂的，任何一个环节、任何操作都可能产生数据质量的问题，最后业务感知的问题就是数据错了、漏了、延迟了。
1. 数据质量治理挑战
首先看蚂蚁整个业务形态，第一部分是大家比较有感知的C端用户产品，包括芝麻分、蚂蚁森林、花呗、借呗；第二部分是面向机构、监管的业务，包括机构清算、计息计提等，这些业务需要用大量技术、数据加算法去融汇，追求价值最大化。在金融业务苛刻性要求下，做好整体数据质量的保障，面临着以下诸多挑战。
业务方面，蚂蚁业务发展非常快，所以变更很多，任何一次变更出错，都可能影响很大。业务上不管是追求用户体验，还是智能化对数据时效要求，对数据产出时效都有很高的要求。
数据方面，大部分是金融业务，对整个数据质量的容错要求非常高。
用户方面，整条链路上有很多类型的角色参与研发，比如BI、技术同学、数据同学，还有大量产品、运营，其中每个人的基本认知不一样，专业技能水平也不一样，这就会导致很多人为的操作带来风险。
在这个过程中可以看到一个数字，目前蚂蚁日均大数据任务变更是4000+以上，每天至少在大数据平台上有100万调度实例，数据服务在线的消费场景大概有4万多个。一句话总结，数据质量已经成为了蚂蚁业务发展的基石和驱动器之一。
2. 金融级数据质量顶层设计
在这么复杂的挑战下，单点解决问题是很难保障的，我们需要有一个良好的顶层设计去解决这些问题。我们将其中的风险分成三类，第一是数据技术引擎风险，第二是数据内容本身风险，第三是数据应用风险。
具体落地的核心思路是什么呢？
首先，保障目标重点聚焦保障高可用和资金安全的业务场景。在保障过程中，事前要做研发质量保障，包含测试、仿真等工作；事中要重点解决变更风险管控；事后出现问题的时候，要确保生产运行是高可用的，需要重点建设主动发现和快速恢复的能力。另外，我们还成立了数据和技术的联合蓝军，对保障体系做攻击，驱动结果验证和布防。
3. 金融级数据质量技术目标
围绕整体的顶层设计思路，面向金融级的数据质量，我们提了比较明确的目标：出现故障时，5分钟故障能发现，50分钟能恢复执行。在真正执行的时候，核心策略是从事前、事中、事后，建设数据端到端核心保障能力。
事前，任务研发过程中，需要具备可测试、可仿真、可联调的能力。在研发阶段需要重点建设测试、比对、冒烟等能力，预发阶段建设应用->数仓链路联调的能力。
事中，需要进行业务SLA全链路配置，具备可灰度、可核对、可分级的能力。生产发布阶段围绕采集、处理、服务应用数据全生命周期，把灰度、主动核对配置等能力植入各个环节。
事后，重点是故障发现和故障恢复，需要具备可演练、可发现、可重跑的能力。主动发现重点建设一键故障定位、全链路数据核对等能力，快速恢复重点做分级恢复、区间恢复和旁路恢复。同时通过组织、文化、运营、流程让整个体系能够持续迭代和生效。
4. 蚂蚁数据质量治理架构
围绕技术目标，具体在能力建设过程中分成三层。
能力层，包含质量管控、质量识别、故障恢复和风险治理能力。我们还建立了统一质量元数据中心，结合大规模机器学习算法，尝试探索智能化的波动异常、离散异动等风险点识别。
系统层，围绕数据测试、发布管控、变更管理、质量监控、应急演练、质量治理，重点建设6大产品能力。
业务层，会把产品能力开放给业务数据质量团队，帮助他们建业务数据质量门户，包含应用分级管控研发流程和全链路质量监控的运维平台。同时，横向也会建设组织文化和制度规范，组织文化包含数据攻防、质量审计、保障小组等，做到全局高效拉通；制度规范包含质量保障规范、基线管理手册、发布变更手册等，形成全局的制度规范。
在整个实施落地过程中，重点会以资损量、故障数为核心目标抓手，发现保障体系里面的问题，驱动整个体系持续迭代优化。
5. 数据质量治理案例
在这个架构之下，围绕整体保障思路，介绍两个案例，一个案例是数据变更免疫，我们具体怎么做的。第二个是数据攻防演练，这是我们创新模式的探索，实施过程中也获得比较好的效果。
案例一：数据变更免疫。
在整个数据变更风险领域，我们的核心目标是希望让错误代码不发布生产。
事前，构建变更准入防线，变更必须满足三板斧、发布窗口等风险底线要求，这些风险底线的要求，会植入到整个变更准入的防线里面。
事中，构建变更灰度防线，用真实流量去预演。在变更生效之前，我们能用真实流程去预演验证，在生产上逐步生效，更充分的提前发现问题。
事后，重点是变更监控，变更生效之后，我们能够持续监控变更的业务变化，有问题及时发现并做恢复。
我们围绕变更事中，在任务发布环节沉淀了非常多的规则，目前的效果是高风险校验规则全年校验6000万次，高风险拦截规则全年累计大概600万次，上线后当年变更类的故障下降约90%，提前发现并规避了很多潜在故障。
案例二：红蓝攻防。
数据红蓝攻防的核心思路是，通过故障注入对生产运行链路进行模拟攻击，发现防控体系的薄弱点。
具体做法，我们把数仓体系分成很多层，我们会把攻击的数仓链路构建一个旁路环境，对任务和数据结果进行攻击，这里面包括对任务攻击和数据攻击两种方法。
在做数据红蓝攻防的过程中，核心需要解决的3个问题：
- 我们如何不影响生产？
- 如何选择攻击对象？
- 如何进行有效的攻击？
不影响生产我们核心通过构建仿真无损的环境，进行无差别的攻击。选择攻击对象我们重点选择数据入口和出口环节，同时有资损和舆情的场景进行攻击。
在有效攻击上，我们确保所有攻击手段要能帮助业务发现有效生产风险，核心是通过历史故障分析和平移，再加上重大业务变更预演。另外在核心攻击能力上，构建了SQL注入能力，包含比较多的方法，比如数据大幅波动、内容格式异常、资金错位攻击；还有节点注入，包括任务重复回流，重复重跑等。
围绕红蓝攻防，我们在蚂蚁连续组织了四年公司级别的红蓝攻防，自动化攻击次数已经达到40万+次，推动数据质量核对规则和配置超过50万+条，发现了非常多的潜在问题。
二. 数据计存治理（成本）
接下来聊一聊计存治理具体做了哪些事。
这是19年蚂蚁离线集群的存储使用率的曲线图，我们知道85%是存储的安全水位线，从图中可以看到后半年全部是在85%以上，整个集群物理容量规模是EB级存储，物理表有300万+，参与数据开发人员大概有3000+。
1. 数据计存治理核心思路
核心从组织设计、规范制定和平台建设三个方面去落地，执行的时候通过战役拉动，支撑业务同时进行资产升级，通过运营活动，帮助做成本规范传播和文化建设。
在组织设计层面，成立了数据架构小组，从架构域维度统筹整个公司的数据架构和成本治理工作。我们也设立了整个数据管理岗位和晋升通道，制定了研发协作机制和流程。
在规范制定层面，我们产出了蚂蚁数据架构规范、研发管理规范和数据治理管控规则。
平台建设分两方面，一个是研发侧，正向提升研发质量和管控资产的无序增长。另一个是治理侧，会搭建平台化的治理工具能力，形成一套自动化的治理机制。
2. 数据计存治理策略
在具体落地的时候，核心思路是开源和节流。蚂蚁数仓原来的资源都是独享的，而且资源需求非常大，第一个思路是资源能不能跟在线数据（类似数据库资源）做一些计算资源共享；第二个是节流，数仓内部从任务和数据角度尽可能优化、节约。
3. 面向开源
面向开源的时候，我们具体做了什么事？
第一，数据计存治理技术方案。
前整个数仓只有杭州专用的集群，我们希望把整个数仓体系用上深圳、上海的集群，这样既能提升整个资源的利用率，又能保障稳定性。在这个架构下有两个问题需要解决：
- 第一，数仓一旦跟在线资源做混部，怎么能确保它在一些高峰期不受在线资源抢占，保证数仓高保业务的稳定运行。
- 第二，因为原来引擎是存储计算一体，数仓有大量的数据交互，一旦跨城，会大量访问带来的网络开销，会直接影响数仓的正常运行。
我们核心做了三件事：
- 所有数仓应用层的数据访问，统一收敛到数据中间层。
- 对中间层里面的热数据做跨层冗余。
- 对于高保业务给予独占资源，跟在线资源做隔离，防止挤占。
第二，数据迁移混部方案。
在这个混部架构下，碰到了一个问题：存量数据任务是开放读取，存在大量跨城访问，怎么才能无风险的迁移到混部集群。
我们制定了一套完整的迁移混部方案。
事前做项目规划，进行迁移评估，对整个业务项目、资源使用做评估，产出迁移的列表。
事中做迁移改造，包含要部署迁移列表的巡检治理规则、进行代码改造和架构升级、部署发布管控规则避免热表跨集群拷贝带来集群风险。
事后做日常巡检和持续优化，包含对跨城任务持续监控，不合理的代码要做改造，对热表要做集群缓存，减少网络带宽带来的集群负载。
第三，数据迁移混部管控与治理方案。
当我们把数仓搬到混部集群，和在线集群资源混在一起用的时候，我们发现数仓增加了50%的可用弹性计算资源，数仓任务平均等待时长降低了50%。同时看到另外一个效果，不仅数仓有更多的资源用，在线CPU资源利用率从25%提升到40%，从全局资源利用率也提升非常多。
4. 面向节流
4.1 数据计存治理关键技术方案
另外一个是面向节流，蚂蚁在大数据成本治理沉淀了非常多的技术方案，接下来从引擎优化、模型优化、代码优化和资产管理优化几个方面做简单介绍。
引擎优化方面，包括参数和调度调优。参数层面包括Split Size、小文件合并、Reducer instantce等；调度层面会做一些HPO优化，加上冷热分层。
模型优化方面，数仓会抽象公共层，通用应用层，大宽表设计，让下游更多复用；代码设计包括全量采集改成增量采集；还有渐进计算，hash cluster等设计；数据格式包括存储归档、cube预计算等。
代码优化方面，包括join优化、数据倾斜优化、UDF优化、聚合优化。
资产管理优化方面，围绕数据生命周期管理，包含临时表、垃圾回收站优化、全表扫描，分区裁剪等。
以上的核心思路就是用技术方法实现自动识别、归因分析，形成常态化治理能力。
接下来重点讲3个数据计存治理计算优化案例，可以用非常小的成本带来较大的治理收益。
4.2 数据计存治理案例
案例一：计算优化—渐进计算
通常用于数据跨分区进行固定窗口或者滑动窗口计算的场景。
我们经常会有一些分析指标叫财年累计，从1月1日到至今，我们叫固定窗口。还有一个是滑动窗口，最近30天，这些指标计算的时候有一个共性，过程中有很多中间表，都可以被复用，如果每次都是重新计算的话，会有非常多的资源浪费。渐进计算的核心原理就是用空间换时间，自动生成里面的中间表，避免重复计算，中间表也可以采用哈希方式快速读取。
下面是风控案例，取最近90天的数据，当我们用了渐进计算以后，每天计算消耗从大概795CU降到22CU，还是有非常大收益的。
案例二：存储优化—存储归档
存储归档通常用于数据查询频次不高冷数据场景。
归档原理采用RAID格式存储，有N个数据块，M个校验块的模式。我们把归档能力内置成一些命令，方便大家处置，离线数据有分区概念，分区有冷有热，对特定分区也可以做归档。
对比一下当前三镜像备份和归档模式的优缺点：第一种是ODPS原生备份能力，实现起来比较简单，数据恢复也比较快，但是有非常大的冗余，成本也高，归档存储占用也是比较少的，大概1.375倍存储，这个时候读取性能会降低。在存储归档用的时候也是要基于场景化去用，而不是一股脑把归档技术全用上去。
案例三：存储优化—重排压缩
重排压缩通常应用于存在大量字段信息冗余的宽表，通过重排提升压缩算法的压缩效果。
重排原理是根据数据特征把具有相同列值字段通过排序放在一起，以提高压缩率。有点像windows碎片整理一样，针对重排键识别一种是专家经验识别，一种是通过技术手段，让它自动迭代，算出字段和字段之间的重复率。拿到重排键之后，我们会根据重排键进行重排，这里分成主链路重排和旁路重排两种方式。
重排压缩适用的场景是一个月使用少于2次的冷数据、记录重复值较多的大表。分享一个案例，我们对网关流量日志做重排压缩之后，整个存储大概减少30%。网关流量是非常大的，动辄上百G日志。其中有一些要注意的事项，重排压缩不适合json串类型字段，重复率不高；做重排的时候不要用全局排序，用分区排序即可。
4.3 数据计存治理存储优化进一步探索
我们现在也在基于数据冷热程度，建立一些自动化识别和分级存储方案，从而实现成本分级优化。
分成4类：高热数据（每天访问）：日常高频访问；热数据（30天内有访问）：访问频率相对正常；冷数据（30天无访问，90天有访问）：数据需要长期保留，但是访问频次低；最后一个是归档数据(90天无访问)，需要长期保留，但是访问频次极低，比如监管要求要长期保留的数据。围绕这个分类做相应分级，做自动化的数据差异化存储，同时针对归档数据目前在进一步探索建立独立的冷备集群和更高压缩比的归档算法。
三. 数据治理的未来思考
首先，围绕整个大数据数仓治理，不管是在线、离线还是图数据，存储的都是数据，只是存储介质不一样，未来需要一体化的数据治理体系，统一解决成本和效率问题，这是共通的。
其次，数据治理如何结合当下比较火的ChatGPT，做到更智能化，也是我们探索的方向。
最后，还有一个比较重要的点，数据作为国家的生产要素，在《个保法》的要求下，要被使用、消费并发挥价值，过程中对数据的保护应该如何处理？这也是未来数据市场化场景下，我们要去探索的。
