简介:阿里巴巴一直将数据作为自己的核心资产与能力之一,从最早的淘宝、天猫等电商业务,到后续的优酷、高德、菜鸟等板块,DataWorks、MaxCompute、Hologres等产品用一套技术体系来支持不同业务的发展与创新,为企业带来整体的“数据繁荣”。 数据繁荣为我们带来了红利,同时也带动了各类数据治理需求的井喷,特别是降本等需求的不断出现,阿里云DataWorks团队将13年的产品建设经验整理成最佳实践,从数据生产规范性治理、数据生产稳定性治理、数据生产质量治理、数据应用提效治理、数据安全管控治理、数据成本治理、数据治理组织架构及文化建设等7个方面为大家揭秘数据治理平台建设实践

作者:阿里云DataWorks团队

阿里巴巴一直将数据作为自己的核心资产与能力之一,通过多年的实践探索建设数据应用,支撑业务发展。在不断升级和重构的过程中,我们经历了从分散的数据分析到平台化能力整合,再到全局数据智能化的时代。如今,大数据平台面临全新的挑战,特别是降本等数据治理需求的不断出现,今天阿里云DataWorks团队将其中一些建设经验与大家进行一些分享。

一、数据繁荣的红利与挑战

大数据平台的建设,到底可以为企业带来什么样的价值?

对于技术同学来说,往往会用一些技术指标来衡量,例如数据量,机器数量,任务数量等等。根据我们往年已经对外公开的数据,我们可以看到大数据计算引擎MaxCompute的单日数据处理量在不断增长,在2021年双11的时候,MaxCompute单日数据处理量已经达到了2.79EB。有趣的是,双11不仅仅意味着当年的波峰,同时也是来年的起点,成为了2022年日常每天的数据处理量,去年的峰值成为了来年的日常。在大数据开发治理平台DataWorks上,单日任务调度实例数也超过了1000万,其中也包含着业务之间50多种各类复杂的数据处理关系,保障数据正常、有序产出,如果将整个阿里巴巴集团的数据任务依赖全部展开,将会是一副非常广阔的数据画卷。

规模当然可以一定程度上反馈我们为业务带来的支持,特别像双11这种世界级的场景,对很多技术都是全新的挑战。但是从大数据平台到创造价值之间,还有一个很重要的环节是“人”,是大数据平台的用户。

对于DataWorks来说,作为大数据平台最贴近用户的工具层,可以看到DataWorks集团内的用户数正在以每年5位数的量级不断快速增长,当前每月在DataWorks上进行各类数据操作的活跃用户数超过5万人,除了数据工程师、算法、开发等技术人员在上面进行数据同步、开发、治理等工作,同时也服务运营小二、分析师、财务、HR等各类业务人员,进行个性化的找数、取数、用数等分析工作。所以,大数据平台不仅仅应该停留在数据团队,我们要有更多的用户进来,更多地走向业务团队,提升数据使用的效率,让平台、用户、业务达成正向循环,推动企业数据价值不断释放。

从最早的淘宝、天猫等电商业务,到后续的优酷、高德、菜鸟等板块,DataWorks与MaxCompute等产品用一套技术体系来支持不同业务的发展与创新。因此我们认为大数据平台的价值体现,不仅仅是数据量的增长,同时也是用户数的增长,数据应用(业务)的增长,人人参与数据建设,为企业带来整体的“数据繁荣”。

数据繁荣为我们带来了红利,同时也带动了各类数据治理需求的井喷。从2009年算起,我们做DataWorks已经15年了,对于一款发展了如此之久的产品,我们走过了阿里巴巴集团几乎所有外部知名的数据架构进化的时代,同时在当前也面临众多全新挑战。在大数据平台的建设过程中,我们经常遇到一些数据治理的问题,例如:

● 数据稳定性不足

任务调度随着规模增大经常挂掉,不稳定,集群计算资源不足;员工经常起夜处理告警,故障无法快速恢复;突发大流量导致数据服务宕机或不可用

● 数据应用效率低

表数量越来越多,找不到需要的数据;缺少数据规范与标准,每次使用都要沟通;数据需求经常变更,数仓人员压力巨大

● 数据管理风险大

数据使用人员多,管理与易用难以平衡;数据出口多,人为泄露行为管控难;法规不断更新,敏感数据发现难,数据分类分级难度

● 数据成本压力大

降本成为大趋势,技术挑战大;不知道成本问题在哪,在哪个部门/人;数据不敢删、任务不敢下

不管是阿里巴巴集团内部,还是我们服务的众多阿里云上客户,和我们沟通的时候都希望聊聊数据治理相关的主题。他们面对众多数据治理需求,往往感觉无从下手,就像“按下葫芦浮起瓢”,每天都会冒出新的问题。。我们其实没法一次性解决所有问题,但是可以逐步解决主要问题。基于DataWorks的建设经验,我们将企业的数据治理需求整理成四个大的阶段,每个阶段都有不同典型的数据治理问题,应该投入更多的精力来处理这个阶段的主要矛盾,并且从这些实践中,逐步形成企业数据治理各类方法论与规范的沉淀。

一、起步阶段-数据量与稳定性的矛盾

起步阶段我们最重要的是得保障“有”数据,数据不断产生,数据量不断增长,我们需要保证数据产出的时效性,稳定性、数据质量的准确性,这些也是数仓同学最常面对的问题类型之一。在这个时候遇到的数据治理问题主要集中在集群上,例如任务长时间等待,计算、存储、调度等各种资源不足,数据无法产出,或者产出脏数据,集群挂了,运维无法定位问题,问题处理时间长,补数据止血难度大,人肉运维无自动化等等。这个时候,业务将会明显感受波动,有些故障甚至会造成业务资损。

二、应用阶段-数据普惠与使用效率的矛盾

当我们“有”数据的时候,接下来面临的就是“用”数据,我们想要更多人来使用数据,实现数据普惠,但是用的人越多,需求也会越多,效率反而会受阻。我们的产品满足50人使用还是5万人使用,可以说是天差地别。这时遇到的更多数据治理需求主要集中在效率上,例如:各个部门人员找数、查数、用数需求不断增加,使用数据人员开始增多,数仓人员疲于取数;数据开始赋能业务,各类数据应用需求井喷,数据团队压力增大等等。这个时候,数仓建设可能逐步变得有点混乱,甚至有走向失控的节奏。

三、规模阶段-灵活便携与风险管控的矛盾

随着用数据的人越来越多,前台也会建设越来越多的数据应用,带来的各类数据风险就会增大,我们要开始“管数据”,但是各类数据安全的管理动作往往会和效率背道而驰。在这个阶段我们解决的数据治理主要问题主要集中在各类安全管控能力上,例如:各类法律法规直指内部各类数据安全风险;不知道谁在什么时候怎么使用数据,出现一些数据泄露事件。

四、成熟阶段-业务变化与成本治理的矛盾

成熟阶段意味着我们能实现数据业务化,但是面对当前的环境,经常会提出“降成本”的需求。

如果业务增长、成本线性增长,我们需要成本治理

如果业务受限,成本冗余大,我们也需要成本治理

那应该怎么降、降哪些,对于多企业也是一个难以回答的问题。而且对于一个成熟阶段来说,成本治理不应该是一个“运动式”“项目式”的工作,而应该将之前提到的各类公司数据治理的理念深入人心,形成常态化的工作。

可以看到,降本往往是在数字化建设偏后期的需求。很多人一来和我们聊数据治理就说降本,其实在我们看来,对于绝大部分企业来说,降本的需求本身并没有问题,后面我们也会重点讲解下,但不妨可以回顾下前面几个阶段,我们是否做的足够充分,例如当前的成本高企,或许是因为第一阶段堆叠了过多的人肉,又或许是因为第二阶段各种人员无序使用资源。

在经历这么多数据治理场景和需求之后,阿里巴巴在内部逐渐形成数据模型规范、数据开发规范、数据质量规范、数据安全规范等多种方法论,并且这些实践经验我们也会逐步沉淀到DataWorks平台上,让规范落地,逐步形成全链路数据开发治理平台。包含数据建模、数据集成、数据开发、数据运维、数据资产、数据治理、数据质量、数据安全、数据分析、数据服务等数据处理全链路流程,以一站式的大数据开发治理平台能力,满足数据治理中关于规范、稳定、质量、管理、安全、分析、服务等各个方面的诉求,我们在后面的各类实践场景中还会为大家详细讲解。

小结

面对大数据平台众多数据治理问题的挑战,我们用1套组织架构,1部数据治理方法论,1套全链路治理平台来满足各类数据治理的需求。在大数据的“起步、应用、规模、成熟”阶段,对应“稳定、提效、管控、降本”等不同的目标,将精力投入到主要矛盾上,让数据治理平台需要紧密结合各类经验、场景与方法论。

二、阿里巴巴数据治理平台建设实践

刚才我们提到了各个阶段的主要矛盾与问题,接下来我们将会为大家介绍DataWorks在各个数据治理场景下的主要实践,包含数据生产规范性治理、数据生产稳定性治理、数据生产质量治理、数据应用提效治理、数据安全管控治理、数据成本治理、数据治理组织架构及文化建设等方面。需要提一点的是,数据治理平台的开放性也非常重要,很多场景的实践也是DataWorks平台与集团内各个业务部门共创和紧密合作实现的。

01-数据生产规范性治理

我们将数据规范性放在第一个讲,这是很多数据治理问题的源头,不管是第一阶段的生产稳定,还是第二阶段的应用提效,都和数据规范性紧密相关,我们举几个简单的例子:

1、数仓架构混乱

跨bu、跨团队依赖较多,数仓架构逐渐混乱,逐步有失控趋势,面临重建危机

2、数据开发效率低

业务含义不清、数据模型设计与物理表开发断链,有了模型开发效率也没提高

3、数据指标构建难

业务需要的数据指标开发较慢,类似指标没有批量构建的方式,缺乏指标的统一管理

4、找数用数难

业务数据含义口口相传,人工问口径耗费大量时间,交接人员也不清楚数据情况

5、数据稳定性差

数据混乱,导致数据产出时效受影响,数据质量稳定性不高

6、数据成本不断增长

数据随意开发、大量任务重复计算、找不到也治不了,导致成本不断增加

所以,我们希望在第一部分就和大家强调下数据规范的重要性,有些企业由于业务的发展,往往会忽视规范的建设,经常采用“先污染,后治理”的方式,然后陷入各类业务需求,而良好的数据规范建设往往可以起到“事半功倍”的效果。DataWorks的智能数据建模同天猫、淘宝、盒马、本地生活、菜鸟等多个事业部进行共创,我们以某个事业部为例为大家讲解下数仓规范性的建设思路,该业务数仓团队从2020年开始与DataWorks团队不断共建智能数据建模产品,从最初版简单的录入系统,到集成逆向建模、多表克隆、多种引擎的代码模式、excel交互等功能,最终让整个数仓团队的开发效率提升30%,并且下线15%不规范的冗余的数据表。同时在整个数仓公共层团队与业务数据开发团队进行推广,全员使用,成为事业部落地数仓规范的统一平台。

数仓规范性治理的方案主要围绕稳定性、扩展性、时效性、易用性、成本五大目标展开,整体方案主要包含两部分,分别是模型线上化与模型管理&评估。模型线上化部分,首先设计了“数据架构委员会”这样的组织保障团队,即搭建架构师团队,并将模型管理责任到数据负责人;接着拟定事业部数仓的规范制度,例如数据模型规范、数仓公共开发规范、数仓命名规范等;最后将规范制度和模型负责人通过产品工具DataWorks 智能数据建模产品进行落地。完成模型线上化只是第一步,接下来模型管理&评估是重点,通过事前模型评审、事中模型评估打分、事后模型治理推送,实现模型管理的闭环,促进模型不断优化和完善。

方案设计完成后,通过对所需功能进行梳理,总结出从规范定义、便捷开发、发布评审、业务管理四个模块来建设智能数据建模平台:

1、规范定义

在前期,数仓团队是没有这个数据建模平台的,大家都是以线下的建模方式,比如数据开发对 Excel 梳理后,先进行数据探查了解数据基本情况,之后进行模型的设计,然后再线下进行模型评审。整个模型设计和评审都在线下,最终导致大家数据建模的时候没有形成一个规范,数据开发的过程不严谨,下游有了大量的引用之后,切换的成本也非常高。并且从维护角度来说,用Excel建模的方式,当数仓开发人员变动后,Excel中模型交接不便,难以持续维护,容易造成企业宝贵的数据业务知识流失。所以数仓团队希望将规范的定义搬到线上,下图中列出了线上规范定义的主要内容。

2、发布评审

之前数仓团队的评审也是在线下进行,在架构师和工程师比较忙的时候,评审流程就不够严谨,甚至没有走评审的过程就直接发布了,所以希望将这个功能也搬到线上去。发布前我们会对表命名、字段命名进行强校验,同时支持多引擎发布,比如离线数据存在 MaxCompute 或者 Hive 上面,还有一部分数据存在 MySQL 或者 Oracle 上面等等。影响性检查是模型发布之后,对于下游的引用这个模型的 ETL 脚本是不是有一些影响,比如有的时候新增了一个字段,下游同学使用的时候是 Select * 的方式,而表没有新增的这个字段,就会导致下游任务报错。

3、便捷开发

这是核心重要的一点。数仓团队希望将建模方式从线下搬到线上之后,不要影响数仓同学的开发效率,所以设计了各种提高效率的便捷开发功能。

4、业务管理

这是从使用的角度上来说的。对于研发人员来说,有业务分类和数据域的视角,对于业务人员来说,提供数仓大图和数据字典的视角。从成本治理的角度来说,比如一些历史上的模型可以做归并或下线。

这些功能落地成智能数据建模平台产品,从实践来说,主要分为两部分,首先是正向建模,相对比较清楚,基于维度建模的理论基础,以及我们在数据中台的众多实践,从数仓规划、业务域定义、数据域&业务域过程定义、数据标准定义、维度建模、原子&派生指标定义、模型发布七个步骤。

针对存量的历史模型,通过DataWorks逆向建模的能力,对存量模型进行了全面分析和盘点,下线了若干历史、低价值的模型,并完成存量模型100%的线上化管理。

以数据中台方法论为指导,DataWorks智能数据建模形成了数仓规划、数据标准、数据建模、数据指标四大产品模块,成为各部门统一使用的数据建模平台,累计形成数据模型表超过1万张,有效提升阿里巴巴集团整体数据的规范性。

小结

数据生产规范性是很多问题的源头,建议要最先考虑起来,往往能起到事半功倍的效果。数据模型是企业特别重要的数据知识,建模平台需要通过平台化的工具来做,而不是原先线下Excel之类的方式,一时方便,长期成本反而很高。这样不仅能提高对内交流、应用的效率,还能防止由于员工的变更,造成企业数据知识的流失。

02-数据生产稳定性治理

数据生产的稳定性是企业在建设大数据平台时会遇到的第一个问题,对于数仓同学来说,值班是工作的一部分,值班同学的一晚大概是这样的:

● 凌晨1:30,收到电话告警,机器人自动播报“XX任务已延迟XX分钟,请尽快处理!”

● 凌晨1:31,起床打开电脑,处理告警问题,1:40、1:50、2:00,电话告警不断轰炸,手机不断震动,前往客厅办公

● 凌晨2:00,对于上下游任务逻辑不太清楚,拉起一批同学起夜

● 凌晨3:00,老板被Call醒,打来电话询问情况,沟通后续处理方案

● 凌晨5:00,所有任务处理完成,等待集群资源计算数

● 上午7:00,睡眼朦胧,起床前往公司上班

● 上午9:00,刚出电梯口,被业务小二围住追问数据产出时间,并开启一天的工作

可以说,天下数仓同学苦值班久矣!在阿里巴巴内部,当我们在做数据稳定性治理的时候,往往会围绕两个核心指标进行优化,分别是起夜率与基线破线率。

● 起夜率

指在日常工作中,数仓值班同学需要起来处理问题的天数占比全年天数,如果一个晚上无事发生,数仓同学不需要起夜,我们也引用了游戏中的一个概念,称为平安夜,起夜率相对越低越好。

● 基线破线率

基线是DataWorks独创的理念,在基线上我们可以为任务设置最晚产出时间。例如当天营收数据,最晚产生时间设置为凌晨2:00,如果这个任务最终产出超过2:00,那么这条基线就破线了,基线破线率同样也是越低越好。

在治理实践中,通常是以下流程:

1、基线配置

梳理团队核心数据产出任务与链路,确定基线任务分级,将不同的任务配置1/3/5/7不同的基线等级,同时配置基线产出时间与告警余量。告警余量是一个非常重要的概念,类似抢救时间。例如刚才我们提到的任务产出时间设置为凌晨2:00,如果告警余量设置成1小时,基线会预测任务产出时间,如果时间超过凌晨1:00便会进行告警,方便我们提前知晓核心任务的产出风险。

2、基线治理

基于基线功能以及一些元数据,数仓团队针对基线告警进行治理,包括告警的认领、评估、处理等,同时会针对基线告警进行根因分析,看下是由于什么原因导致的数据稳定性问题,常见的有据质量报错、SQL语法报错、系统环境报错、权限报错、同步任务报错等,进行生产稳定性的根治治理

3、稳定性评估

最终,团队产出稳定性周报,每周报告基线破线率及平安夜数,在值班手册中,也会形成常见问题排查宝典,治理问题清单,将稳定性治理的经验沉淀成团队共同的知识资产,并且进行责任公示,设计奖惩制度、达到稳定性治理正向循环。

智能基线可以说是DataWorks中守护数据安全生产的核心功能,里面结合了DataWorks多项运维诊断和MaxCompute引擎能力。

1、智能分级调度与资源分配

当1个任务被设置1/3/5/7不同的基线等级后,整个平台运行的时候会按照优先级为核心数据产出进行重要性分级,高优先级任务及其上游,将获得更多的任务调度与MaxCompute的计算资源,以保障高优先级任务的运行资源。DataWorks也将其中涉及众多调度与资源分配的核心技术申请了国家专利。

2、智能预测与告警

1个核心任务可能会前置依赖多个任务,当我们在最终产出的任务节点配置基线后,前置的依赖任务就不需要再逐个配置运维告警了,将会极大提升运维效率。任务开始运行时,DataWorks会回溯依赖链路上所有任务的历史运行记录,同时结合平台当前运行及集群资源情况,每30秒刷新智能预测数据产出时间。例如设置核心任务期望产出时间基线在2:00,在核心链路中间,有个平时20:00产出的任务20:30仍未产生,结合当前集群水位情况,判断将会导致希望在2:00产出的最终核心任务延时,那么数仓同学将会在20:30就收到告警,提前干预处理延迟任务,而不是等到最终2:00任务已经延时了,才开始处理。

3、全链路智能诊断与排障

提前收到告警后,运维同学也会在DataWorks的运维中心处理告警任务, 在DAG图上查看上下游及每个周期实例的运行情况,通过运行诊断排查全链路上的告警问题,例如上游依赖告警、当前任务定时检查,调度资源检查、MaxCompute资源检查等等,可以快速定位并排障。

智能基线的配置及故障处理参考下方,针对任务责任人和值班人不同的情况,DataWorks还设置了值班表的功能,可以将不同责任人的告警消息统一推送给当前值班表对应人员。

以内部某个数仓团队为例,在稳定性治理之前,团队每周需要2.5人日进行值班,其中每年损失的不仅仅是135天的值班人日,凌晨起夜的同学135天日间的工作效率也会收到极大的影响,严重丧失工作的幸福感。稳定性治理之后,团队7级基线的破线率从每月的4次降低到了0次,值班同学起夜率从97%降低到了33%,同时极大地提升了员工的工作幸福感,这也是稳定性治理的重要意义。

小结

数据生产稳定性核心会用起夜率和基线破线率来衡量,通过围绕智能基线构建的全链路运维诊断能力来支持稳定性建设。智能基线可以基于集群当前水位,历史运行情况,智能分配计算与调度资源,让核心数据优先产出,并提供智能告警的能力方便提前干预处理。另外,稳定性的治理对于员工的工作幸福感也是非常大的提升。

03-数据生产质量治理

在我们针对数据生产稳定性进行保障过程后,往往同步会关注到的,就是数据生产的质量问题治理。数据质量的好坏,往往对业务侧所要执行的决策和流程有着直接关联,各种场景不但需要能“成功获取数据”,还需要能“成功获取正确的数据”,这样才能实现业务侧的成功。

以阿里集团最常见的电商包裹场景举例,我们能看到,当一件包裹上出现了数据质量问题后,能引发不同维度上的业务问题。

通常在实际生活中,我们针对包裹会有重点关注的基础数值属性,比如包裹的重量、体积,因为会和包裹的价格、包裹的运输安排都有关系。当出现这些属性不符合预期的情况时,就会出现针对这件包裹的各种业务问题的追查。

例如,当重量值为空值时,或者等于0的时候,按数据规则反应现实过程,则是出现了没有重量的空包裹,这是不符合对物流和计价的业务要求的。而当重量、体积值超过了正常定义的阈值时,例如1个小包重量很大,按实际情况也是不合理的情况。

所以,当出现这种数据质量问题时,我们就会关注,到底是业务上出现了真实问题,还是实际数据加工过程出现了污染。如果真实业务没问题,而是数据出现了问题,则会影响到后续针对包裹的结费计算、运输网络的规划、供应链优化等等。平台与消费者、平台与商家、平台与供应商之间的交互,都会被数据质量问题所影响。

而这些数据质量问题,如果没有治理管控,则会在数据生产过程非常普遍地出现,如数据残缺不全、数据不一致、数据重复等等,导致数据不能有效地被利用,影响数据可靠性保障和有效的业务产出。所以数据质量管理,需要如同产品质量管理一样,贯穿于数据生命周期的各个阶段。当生产环境中产生了与现有规则不符的持久化数据,或数据延迟的问题,则定义为「数据质量问题」。其中引发故障的,则定义为「数据质量故障」。而数据生产质量治理的过程,也就是我们为了避免「数据质量问题」所要建设的重要体系。

我们从业务出发,从对业务侧最核心关键的业务实体,进行数据质量需求的梳理,来明确数据质量问题。如针对电商交易,最关心的就是商品、用户、计费、营收方面数据的质量情况。那什么是影响这些业务实体生产稳定性的关键质量要求呢?在阿里巴巴内部,面向这类商业产品的数据服务支撑流程中,重点会关注以下两大方面:

[责任编辑：王娟]