针对存量的历史模型，通过DataWorks逆向建模的能力，对存量模型进行了全面分析和盘点，下线了若干历史、低价值的模型，并完成存量模型100%的线上化管理。
以数据中台方法论为指导，DataWorks智能数据建模形成了数仓规划、数据标准、数据建模、数据指标四大产品模块，成为各部门统一使用的数据建模平台，累计形成数据模型表超过1万张，有效提升阿里巴巴集团整体数据的规范性。
▌小结 数据生产规范性是很多问题的源头，建议要最先考虑起来，往往能起到事半功倍的效果。数据模型是企业特别重要的数据知识，建模平台需要通过平台化的工具来做，而不是原先线下Excel之类的方式，一时方便，长期成本反而很高。这样不仅能提高对内交流、应用的效率，还能防止由于员工的变更，造成企业数据知识的流失。 二、数据生产稳定性治理 数据生产的稳定性是企业在建设大数据平台时会遇到的第一个问题，对于数仓同学来说，值班是工作的一部分，值班同学的一晚大概是这样的：
可以说，天下数仓同学苦值班久矣！在阿里巴巴内部，当我们在做数据稳定性治理的时候，往往会围绕两个核心指标进行优化，分别是起夜率与基线破线率。
指在日常工作中，数仓值班同学需要起来处理问题的天数占比全年天数，如果一个晚上无事发生，数仓同学不需要起夜，我们也引用了游戏中的一个概念，称为平安夜，起夜率相对越低越好。
基线是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%，同时极大地提升了员工的工作幸福感，这也是稳定性治理的重要意义。
▌小结 数据生产稳定性核心会用起夜率和基线破线率来衡量，通过围绕智能基线构建的全链路运维诊断能力来支持稳定性建设。智能基线可以基于集群当前水位，历史运行情况，智能分配计算与调度资源，让核心数据优先产出，并提供智能告警的能力方便提前干预处理。另外，稳定性的治理对于员工的工作幸福感也是非常大的提升。 三、数据生产质量治理 在我们针对数据生产稳定性进行保障过程后，往往同步会关注到的，就是数据生产的质量问题治理。数据质量的好坏，往往对业务侧所要执行的决策和流程有着直接关联，各种场景不但需要能“成功获取数据”，还需要能“成功获取正确的数据”，这样才能实现业务侧的成功。 以阿里集团最常见的电商包裹场景举例，我们能看到，当一件包裹上出现了数据质量问题后，能引发不同维度上的业务问题。 通常在实际生活中，我们针对包裹会有重点关注的基础数值属性，比如包裹的重量、体积，因为会和包裹的价格、包裹的运输安排都有关系。当出现这些属性不符合预期的情况时，就会出现针对这件包裹的各种业务问题的追查。 例如，当重量值为空值时，或者等于0的时候，按数据规则反应现实过程，则是出现了没有重量的空包裹，这是不符合对物流和计价的业务要求的。而当重量、体积值超过了正常定义的阈值时，例如1个小包重量很大，按实际情况也是不合理的情况。 所以，当出现这种数据质量问题时，我们就会关注，到底是业务上出现了真实问题，还是实际数据加工过程出现了污染。如果真实业务没问题，而是数据出现了问题，则会影响到后续针对包裹的结费计算、运输网络的规划、供应链优化等等。平台与消费者、平台与商家、平台与供应商之间的交互，都会被数据质量问题所影响。
而这些数据质量问题，如果没有治理管控，则会在数据生产过程非常普遍地出现，如数据残缺不全、数据不一致、数据重复等等，导致数据不能有效地被利用，影响数据可靠性保障和有效的业务产出。所以数据质量管理，需要如同产品质量管理一样，贯穿于数据生命周期的各个阶段。当生产环境中产生了与现有规则不符的持久化数据，或数据延迟的问题，则定义为「数据质量问题」。其中引发故障的，则定义为「数据质量故障」。而数据生产质量治理的过程，也就是我们为了避免「数据质量问题」所要建设的重要体系。 我们从业务出发，从对业务侧最核心关键的业务实体，进行数据质量需求的梳理，来明确数据质量问题。如针对电商交易，最关心的就是商品、用户、计费、营收方面数据的质量情况。那什么是影响这些业务实体生产稳定性的关键质量要求呢？在阿里巴巴内部，面向这类商业产品的数据服务支撑流程中，重点会关注以下两大方面： （1）面向商业级服务的数据质量高保障要求：由于在阿里巴巴中台里，数据大量以服务的形态，提供给各个商业化的业务应用，因此，这意味着不只是数据本身产出的保障，也直接影响着最终业务侧承诺质量的保障。 比如，由于更多客户业务根据数据进行决策，数据高准确性要求也因此出现，对数据准确性的不再只是满足一定的数据分布即可，需要结合更多的业务知识对数据准确性进行更准确地评估。再如，由于部分TOB业务对数据产出的时效性有一定要求，单一架构的数据库可能不能完全满足业务的产出速度需要，需要异构数据库合作进行数据链路建设，因此如何保证异构数据的一致性也是需要解决的问题。 （2）对数据质量协作保证过程的高效率要求：多角色流水线作业下，如果要保证数据质量，除了需要制定数据质量规范外，还需要在各环节完成对应事宜，比如研发环节、测试环节、监控环节都有面向各环节要完成工作的人员，分别需要到各模块各自操作，往往还会出现重复性工作，比如质量测试的用例，和质量监控的设置逻辑，通常是类似的，需要能有平台工具，帮助多角色用户，针对数据链路中所产出的所有线上数据质量问题，进行汇总，分析；能帮助质量小组，把纸面要求、规章制度中定义的数据问题，能定期复盘，转化为数据度量落在系统中；能反推研发各阶段，共同高效地提升数据质量。
在这些关注点的牵引上，阿里巴巴数据质量的全流程体系，相应地在如下领域完成重点增强。 |
