阿里大数据管理全景揭秘：元数据、计算、存储与质量保障实战精华

May 31, 2026

深入元数据：数据管理的基石

1.1 元数据概览：定义与价值

1.1.1 何为元数据？

元数据如同数据仓库的“脉络”，串联起源数据、数据仓库和应用数据，完整记录数据从产生到消费的全过程。它核心记载着数据仓库模型的定义、各层级之间的映射关系，同时监控数据状态和ETL任务运行状况。

按照用途，元数据可分为技术元数据与业务元数据两大类：

技术元数据：聚焦数据仓库系统的技术细节，是开发和管理数据仓库的技术支撑数据。
分布式计算系统存储元数据涵盖表、列、分区等信息，包括表名、分区信息、责任人、文件大小、表类型、生命周期，以及字段名、字段类型、字段备注、是否分区字段等。
分布式计算系统运行元数据记录所有作业运行信息，类似于Hive的任务日志，包含作业类型、实例名称、输入输出、SQL、运行参数、执行时间，以及最细粒度的FuxiInstance（MaxCompute中MapReduce执行的最小单元）执行详情。
数据开发平台涉及数据同步、计算任务、任务调度等信息，包括同步任务的输入输出表和字段及节点详情；计算任务则包含输入输出和节点信息；调度任务含有依赖类型、依赖关系和各种调度任务的运行日志。
数据质量与运维相关元数据覆盖任务监控、运维报警、数据质量和故障信息，如监控运行日志、告警配置与运行日志、故障信息等。
业务元数据：从业务视角描述数据仓库中的数据，搭建了使用者与底层系统之间的语义桥梁，让非技术出身的业务人员也能“读懂”数据。

1.1.2 元数据的核心价值

元数据在数据管理、数据内容和数据应用三个层面具有重大应用价值：

在数据管理层面，元数据为数据在计算、存储、成本、质量、安全、模型等治理领域提供坚实的数据基础。例如，在计算治理中，可利用元数据识别超长运行节点，进行专项优化，从而保障数据基线的及时产出。
在数据内容层面，元数据为数据域、数据主题和业务属性等维度的提取分析提供素材。例如，借助元数据构建知识图谱，为数据打标签，清晰掌握当前数据资产全貌。
在数据应用层面，元数据打通产品和应用链路，确保产品数据准确、及时地输出。例如，打通MaxCompute与应用数据，明确数据资产等级，更有效地护航产品数据质量。

1.1.3 构建统一元数据体系

元数据的质量直接关系到数据管理的准确性，建设一套高质量的元数据体系至关重要。其目标是贯通数据接入、加工到消费的全链路，规范元数据体系与模型，提供统一的元数据服务出口，保证元数据产出的稳定性和高品质。

1.2 元数据应用实战

核心价值：数据驱动决策，实现数字化运营。

通过数据驱动的手段，我们得以判断趋势，开展有效动作，发现自身问题，推动创新或解决方案的产生。
对于数据使用者，元数据帮助其快速定位所需数据。
对于ETL工程师，元数据可指导模型设计、任务优化和任务下线等日常ETL工作。
对于运维工程师，元数据能引导整个集群的存储、计算和系统优化等运维活动。

1.2.1 数据Profile：构建血缘图谱

核心思路：为庞杂的数据建立清晰的血缘图谱。利用图计算和标签传播算法等技术，系统化、自动化地对计算和存储平台上的数据进行打标、整理、归档，实际承担了为元数据“画像”的任务，并开发了四类标签：

基础标签：针对数据的存储情况、访问频次、安全等级等进行标注。
数仓标签：标记数据是增量还是全量、是否可再生，以及数据的生命周期。
业务标签：根据数据归属的主题域、产品线、业务类型打上不同标签。
潜在标签：揭示数据可能的应用场景，如社交、媒体、广告、电商、金融等。

1.2.2 元数据门户：一站式数据管理

元数据门户致力于打造一站式数据管理平台和高效的一体化数据市场。
其“前台”产品为数据地图，定位消费市场，满足用户“找数据”的需求，例如检索数据、理解数据等。
“后台”产品为数据管理，定位于一站式数据管控，覆盖成本管理、安全管理、质量管理等功能。

1.2.3 应用链路分析

借助应用链路分析，可产出表级血缘、字段血缘和表的应用血缘。表级血缘主要有两种计算方式：

通过对MapReduce任务日志进行解析；
依据任务依赖关系进行解析。

常见的应用链路分析场景包括影响分析、重要性分析、下线分析、链路分析、寻根溯源以及故障排查等。

1.2.4 数据建模：元数据驱动

通过元数据驱动的数据仓库模型建设，可在一定程度上破解建模难题，提升数据仓库建模的数据化指导水平，提高建模效率。

表的基础元数据：下游引用情况、查询次数、关联次数、聚合次数、产出时间等。
表的关联关系元数据：关联表、关联类型、关联字段、关联次数等。
表的字段基础元数据：字段名称、字段注释、查询次数、关联次数、聚合次数、过滤次数等。
其中，查询指SQL的SELECT，关联指SQL的JOIN，聚合指SQL的GROUP BY，过滤指SQL的WHERE。

星形模型设计时，使用的元数据信息包括：

依据下游使用中关联次数或查询次数超过阈值的表等元数据，筛选用于构建数据模型的表。
基于表的字段元数据，如时间字段、下游过滤次数等，选择业务过程标识字段。
依据主从表的关联关系和关联次数，确定与主表关联的从表。
根据主从表字段的使用情况，如查询次数、过滤次数、关联次数、聚合次数，选定进入目标模型的字段。

1.2.5 元数据驱动ETL开发

计算管理：效能与优化

2.1 系统优化策略

2.1.1 HBO：基于历史的优化

（History-Based Optimizer，基于历史执行的优化器）

当任务趋于稳定时，可以依据任务历史执行情况进行资源评估，即采用HBO。

提升CPU利用率
提高内存利用率
增加Instance并发数
降低执行时长

针对“大促”等数据量暴涨的场景，HBO还新增了按数据量动态调整Instance数的功能，主要依据Map端的数据量增长情况灵活调整。

2.1.2 CBO：基于代价的优化

基于代价的优化器，根据收集的统计信息计算每种执行方式的代价，进而选择最优执行路径。

引入了Join重排序和自动MapJoin优化规则等，同时基于Volcano模型的优化器会探索尽可能大的搜索宽度以获取最优计划。

可设置规则白名单（启用哪些优化规则）、黑名单（关闭哪些优化规则）。

优化器还将提供谓词下推优化，主要目的是尽早进行谓词过滤，以减少后续操作的数据量，提升性能。但需注意：

UDF：对于用户自定义函数，优化器不会随意下推，因为不同用户编写的函数含义各异，不能一概而论。
不确定函数：如sample函数，若出现在where子句且存在Join，优化器不会将其下推到TableScan。
隐式类型转换：编写SQL时应尽量避免Join Key发生隐式类型转换。

2.2 任务优化实战

2.2.1 Map端倾斜

Map端读取数据时，由于输入文件大小分布不均，导致部分Map Instance处理数据过多，而某些Map Instance处理数据很少，造成Map端长尾。

上游表文件大小极不均匀，且小文件非常多，致使当前表Map端读取的数据分布不均，引发长尾。解决手段有二：

对上游进行小文件合并 + 调节本节点的小文件参数加以优化。
使用“distribute by rand()”将Map端分发后的数据按随机值重新分发一次。

Map端长尾的根本原因是读入文件块的数据分布不均，再叠加UDF函数性能、Join、聚合等操作，使得读取数据量大的Map Instance耗时更长。开发中若遇到Map端长尾，应首先考虑让Map Instance读取的数据量尽量均匀，然后判断哪些操作导致Map Instance变慢，最后考虑这些操作是否必须在Map端完成，在其他阶段是否会做得更好。

2.2.2 Join倾斜

由数据倾斜引起的长尾现象非常普遍，严重影响任务执行时间，尤其在“双11”等大型活动期间，长尾程度更为严重。比如某些大型店铺的页面浏览量远超一般店铺，当用浏览日志数据与卖家维表关联时，会基于卖家ID进行分发。

MapJoin方案：Join倾斜时，若某路输入较小，可采用MapJoin避免倾斜；但MapJoin的使用有限制，要求Join中的从表较小。
Join因空值导致长尾：将空值处理为随机值。
Join因热点值导致长尾：先将热点key取出，对主表数据用热点key拆分成热点数据和非热点数据两部分分别处理，最后合并。

2.2.3 Reduce端倾斜

Reduce端产生长尾的主要原因是key的数据分布不均匀。

对同一个表按不同维度列进行Count Distinct操作，会导致Map端数据膨胀，进而使下游的Join和Reduce出现链路上的长尾。
Map端直接聚合时出现key值分布不均，造成Reduce端长尾；应对热点key单独处理，再通过“UnionAll”合并。
动态分区数过多时可能造成小文件过多，从而引发Reduce端长尾；可将符合不同条件的数据放入不同分区。解决小文件过多的参数：set odps.sql.reshuffle.dynamicpt=true;
多个Distinct同时出现在一段SQL代码中时，数据会被分发多次，不仅造成数据膨胀N倍，还会将长尾现象放大N倍（常见）。提前进行Group By，消除Distinct，即分别将指标Group By到“原始表的数据粒度”，然后再进行Join操作。当Distinct个数不多、表数据量不大、数据分布较均匀时，不使用Multi Distinct的计算效果也是可以接受的。

存储与成本管理：降本增效

3.1 数据压缩优化

针对3份副本的压缩方案：archive压缩方法，将存储比从约1:3提升至1:1.5。

恢复数据块的时间会比原方式更长，读取性能会有一定损失。
主要应用于冷备数据和日志数据的压缩存储。

3.2 数据重分布

基于列存储，每张表的数据分布不同，插入数据的顺序不同会导致压缩效果差异显著，因此通过调整表的数据重分布，避免列热点，可节省存储空间。
主要通过修改distribute by和sort by字段进行数据重分布。
通常筛选重分布效果高于15%的表进行优化处理。

3.3 存储治理项优化

优化项包括未管理的表、空表、最近62天未访问的表、数据无更新且无任务的表、数据无更新但有任务的表、开发库数据大于100GB且无访问的表、长周期表等。

3.4 生命周期管理

生命周期管理的根本目的是用最少的存储成本满足最大的业务需求，实现数据价值最大化。

3.4.1 生命周期管理策略

周期性删除策略
彻底删除策略
永久保留策略
极限存储策略
冷数据管理策略
增量表merge全量表策略：交易增量数据，使用订单创建日期或订单结束日期作为分区，同时将未完结订单放在最大分区中。对于存储，一个订单在表中只保留一份；对于用户使用，通过分区条件即可查询某一段时间的数据。

3.4.2 通用的生命周期管理矩阵

历史数据等级划分

P0：非常重要的主题域数据和非常重要的应用数据，具有不可恢复性，如交易、日志、集团KPI数据、IPO关联表。
P1：重要的业务数据和重要的应用数据，具有不可恢复性，如重要的业务产品数据。
P2：重要的业务数据和重要的应用数据，具有可恢复性，如交易线ETL产生的中间过程数据。
P3：不重要的业务数据和不重要的应用数据，具有可恢复性，如某些SNS产品报表。

3.5 数据成本计量

将数据成本定义为存储成本、计算成本和扫描成本三个部分，能够很好地体现数据在加工链路中的上下游依赖关系。

扫描成本：对上游数据表的扫描。
存储成本：计量数据表消耗的存储资源。
计算成本：计量数据计算过程中的CPU消耗。

3.6 数据使用计费

根据3.5所述，分为计算付费、存储付费和扫描付费。
通过成本计量，可以较为合理地评估数据加工链路的成本，从成本角度反映加工链路是否存在加工复杂、链路过长、依赖不合理等问题，间接辅助数据模型优化，提升数据整合效率。
通过数据使用计费，可以规范下游用户的数据使用方法，提高数据使用效率，从而为业务提供优质的数据服务。

数据质量：完整性、准确性与时效保障

4.1 数据质量保障原则

如何评价数据质量好坏，业界有不同标准，阿里巴巴主要从四个维度进行评估：完整性、准确性、一致性、及时性。

1. 完整性

完整性是数据最基础的保障。

完整性：指数据记录和信息是否完整，有无缺失情况。
数据缺失：主要包括记录的缺失和记录中某个字段信息的缺失。例如，记录缺失：交易系统每日支付订单量通常都在100万笔左右，如果某天突然降至1万笔，很可能是记录丢失了；字段缺失：订单的商品ID、卖家ID等必然存在的字段，其空值个数应为0，若大于0则违反了完整性约束。

2. 准确性

准确性：指数据记录的信息是否准确，有无异常或错误。准确意味着数据表中记录的信息必须与业务真实发生的事实一致。判断准确性的方式通常是通过卡点监控——制定相应规则，根据规则校验数据，符合规则的数据才被视为准确的。例如，一笔订单若确认收货金额为负，或下单时间早于公司成立日期，或订单缺少买家信息，这些必然存在问题。

3. 一致性

一致性：通常体现在跨度很大的数据仓库体系中。阿里巴巴的数据仓库内有多个业务数据仓库分支，对于同一份数据，必须保证一致性。一致性要求多个业务数据仓库间的公共数据在各个分支中保持一致。例如，用户ID从在线业务库加工到数据仓库，再到各个消费节点，都必须是同一类型且长度相同。因此，阿里巴巴在建设数据仓库时专门构建公共层进行加工，以确保数据的一致性。

4. 及时性

及时性：指数据能够及时产出，主要体现在数据应用上，必须及时提供给需求方。一般决策支持分析师希望当天就能看到前一天的数据，若等待三五天则失去了数据及时性的价值。例如，阿里巴巴“双11”的交易大屏数据就要做到秒级产出。

4.2 数据质量方法概述

阿里巴巴数据质量建设体系：

1. 消费场景知晓

功能：分析并解决消费场景的知晓问题。
方法：通过数据资产等级和基于元数据的应用链路来解决消费场景知晓问题。先依据应用的影响程度确定数据资产等级；再根据数据链路血缘，将资产等级向上推送到数据生产加工的各个环节，明确链路上所有涉及数据的资产等级，并在各加工环节根据等级差异采取不同的处理方式。

2. 数据生产加工各环节卡点校验

主要对两部分数据进行卡点校验：在线系统（OLTP）和离线系统（OLAP）数据生产加工的各环节。

在线系统：OLTP系统。其卡点校验包括：根据资产等级不同，当对应业务系统变更时，决定是否通知下游；对于高资产等级业务，若有新业务数据产生，是否纳入统计需经过审批卡点。
离线系统：OLAP系统。其卡点校验主要包括：代码开发、测试、发布、历史或错误数据回刷等环节的校验。代码开发阶段和发布前的测试阶段，会根据数据资产等级的不同，对校验的要求有所区别。

3. 风险点监控

风险点监控主要针对数据运行过程中可能出现的数据质量和时效等问题。

在线数据风险点监控：针对在线系统日常产出的数据进行业务规则校验，主要使用“实时业务检测平台BCP”。
离线数据风险点监控：针对离线系统日常产出数据进行数据质量监控和时效性监控。DQC负责监控数据质量；摩萨德负责监控数据时效性。

4. 质量衡量

事前衡量：如DQC覆盖率。
事后衡量：跟进质量问题，确定原因、责任人、解决情况等，用于数据质量复盘，防止类似事件重演；根据质量问题对不同等级资产的影响程度，判为低影响事件还是较大影响故障。
质量分：综合事前和事后的衡量数据进行打分。

5. 质量配套工具

针对数据质量的各个方面，都有相应的工具来保障，以提高效能。

4.2.1 消费场景知晓

消费场景知晓的问题：数据研发工程师难以判断几百PB数据中哪些是重要的，哪些需要全面保障，哪些已经过期，是否所有需求都需要精确的质量保障。
解决方案：数据资产等级方案。
产出：根据数据产品和应用的影响程度，划分资产等级并打标；再根据数据链路血缘，将资产等级上推到生产加工各环节，明确链路上所有数据的资产等级并打标（等级标签与对应的数据产品/应用一致）。

数据资产等级定义

背景：阿里巴巴数据仓库规模已达EB级，若不加区分地统一对待，会导致精力分散、保障不精准。

五个数据等级，重要性依次降低：

毁灭性：数据一旦出错，将引起重大资产损失，面临巨大收益损失，造成重大公共风险。
全局性：数据直接或间接用于集团业务和效果评估、重要平台运维、对外数据产品透出、影响用户在阿里系网站的行为等。
局部性：数据直接或间接用于内部一般数据产品、运营或产品报告，出现问题会给事业部或业务线造成影响，或导致工作效率损失。
一般性：数据主要用于小二的日常数据分析，出现问题几乎不会带来影响或影响很小。
未知性：无法明确说出数据的应用场景，则标注为未知。

对于不同资产等级，用英文Asset标记：

毁灭性：A1等级
全局性：A2等级
局部性：A3等级
一般性：A4等级
未知性：A5等级
重要程度：A1 > A2 > A3 > A4 > A5

若一份数据出现在多个应用场景中，遵循就高原则。

数据资产等级落地方法

需要解决的问题：如何为海量数据逐一打上等级标签？

数据资产等级落地的步骤：

数据流转过程

数据从业务系统产生，经同步工具进入数据仓库，在数据仓库中经过清洗、加工、整合、算法、模型等运算，再由同步工具输出到数据产品中进行消费。数据从业务系统到数据仓库再到数据产品，均以表的形式体现，流转过程如下图：

同步到数据仓库（对应阿里巴巴的MaxCompute平台）的是业务数据库的原始表，用于承载业务需求，通常不能直接用于数据产品（一般是ODS层的全量数据）。数据产品中使用的都是数据仓库加工后的产出表。

具体步骤：

划分数据资产等级；
根据数据流转过程，建立元数据，记录数据表与数据产品/应用的对应关系；
根据影响程度，为数据产品和应用划分资产等级；
打标：依托元数据的上下游血缘，将整个消费链路打上某一类数据资产标签（即对消费链路数据打标）。

链路定义：数据从业务系统到数据产品的流转过程。

通过上述步骤，即完成了数据资产等级的确认，为不同数据赋予不同重要程度，这一过程需要元数据的强大支撑。

4.2.2 数据加工过程卡点校验

目的：保障数据准确性，保障与离线数据的一致性。

在线业务系统卡点校验（数据产出环节）

在线系统卡点校验指的是在线系统数据生产过程中进行的卡点校验。
目的：保障与离线数据的一致性。
背景/问题：在线业务复杂多变，不断发生变更，每一次变更都可能带来数据变化，因此需要：1) 数据仓库适应多变的业务发展，及时保障数据准确；2) 高效地将在线业务变更通知到离线数据仓库。阿里巴巴通过工具和人工双管齐下：既在工具上自动捕捉每次业务变更，也要求开发人员主动进行业务变更通知。

工具

发布平台：发送重大变更通知，内容包括变更原因、变更逻辑、变更测试报告、变更时间等。
数据库平台：发送库表变更通知，内容同上。

发布平台

功能：在业务发生重大变更时，订阅发布过程并通知离线开发人员，使其知晓变更内容。因为业务系统日常发布变更十分频繁，不可能每一次变更都通知离线，那样会造成浪费并影响在线迭代效率。订阅范围仅针对全集团重要的高等级数据资产，整理出哪些变化会影响数据加工，才进行订阅。例如，财报属于A1等级资产，若业务系统改造会影响财报计算口径，则必须告知离线业务，离线开发人员也应主动关注此类发布变更信息。卡点机制：发布平台集成通知功能，针对重要场景的发布进行卡点，确认通知后方可完成发布。

数据库表的变化感知

无论是业务发展引发的数据库扩容，还是表的DDL变化，都必须通知离线开发人员。DDL（数据定义语言）是SQL的重要组成部分，用于描述数据库对象，如CREATE DATABASE、CREATE TABLE等；DML（数据操纵语言）如insert、delete、update、select等。数据仓库采用DataX工具进行数据抽取，可能限定某个数据库表，若发生扩容或迁移，DataX感知不到，可能导致数据抽取错漏，影响下游应用。解决方法是通过数据库平台发送库表变更通知。

开发人员

资产等级的上下游打通，同样要让在线开发人员知晓哪些是核心高价值数据资产，哪些仅用于内部分析。通过培训，让在线开发人员了解离线数据的诉求、加工过程以及数据产品的应用方式，意识到数据的重要性和出错后果，使其在实现业务目标的同时也关注数据目标，做到业务端与数据端一致。

离线系统卡点校验（数据离线加工环节）

背景/问题：数据在离线数据仓库加工过程中，需要保障数据质量，即保障数据准确性。卡点校验在两个环节实施：

代码提交时卡点校验

背景：数据研发人员水平不一，代码质量难以高效保障。通过开发代码扫描工具SQLSCAN，对每次提交上线的代码进行扫描，提取风险点，实现卡点。

任务发布上线时卡点校验

为了保障线上数据准确性，每次变更都必须在完成线下测试后再发布到线上，线上测试通过才算发布成功。卡点方式：对任务上下线进行测试。

发布上线前测试：包括Code Review和回归测试。Code Review是通过复查代码提高代码质量的过程；回归测试是修改旧代码后重新测试，确保未引入新错误或影响原有逻辑。对于资产等级较高的任务变更发布，采用强阻塞形式，必须通过回归测试才允许发布。
发布上线后测试：进行线上Dry Run测试或真实环境运行测试。Dry Run仅运行执行计划，不执行代码，避免环境不一致导致的语法错误；真实环境测试则使用真实数据。对于节点变更或数据重刷新，要提前通过通知中心将变更原因、逻辑、测试报告、时间等自动通知下游，下游无异议后，再按约定时间执行发布变更，将对下游的影响降至最低。

4.2.3 风险点监控

风险点监控主要针对数据日常运行中容易出现的风险进行监控，并设置报警机制，涵盖在线和离线数据风险点监控，目的是保障数据准确性。

在线数据风险点监控

目的：减少在线业务系统产生的脏数据，为数据准确性把好第一道关；同时减少用户错误信息投诉，也减少离线数据错误回滚。
BCP：阿里巴巴的实时业务检测平台。
监控过程：在每个业务系统完成业务数据落库时，BCP订阅一份相同数据，根据预设的业务规则进行逻辑校验，校验不通过时以报警的形式通知规则订阅人，以完成数据校对。校验过程：用户在BCP平台订阅数据源，获取需校验的数据；针对数据源编写规则（校验逻辑）。规则是校验的核心，只有通过规则的数据才被认为是正确的。例如，校验“订单拍下时间”的规则：订单拍下时间不可能大于当天时间，也不会早于淘宝创立时间。配置告警：根据规则的不同配置不同的告警方式。由于BCP的配置和运行成本较高，主要根据数据资产等级来实施监控。
离线数据风险点监控

主要监控数据准确性和数据产出的及时性。

数据准确性监控

数据准确性是数据质量的关键，是所有离线系统加工的第一保障要素。主要通过DQC（数据质量中心）进行监控。DQC关注数据质量，通过配置数据质量校验规则，在数据处理任务过程中自动监控。监控规则有强规则（阻断任务执行，使其失败，下游任务不再执行）和弱规则（仅告警而不阻断）。常见的DQC监控规则包括主键监控、表数据量及波动监控、重要字段非空监控、重要枚举字段离散值监控、指标值波动监控、业务规则监控等。规则配置依赖于数据资产等级，因为DQC检查本质是运行一个嵌套在主任务中的SQL任务，过多检查点会影响性能。因此依据资产等级确定规则的配置情况。此外，不同业务有特定的业务规则约束，这些规则来源于数据产品的消费需求，由消费节点配置，然后上推到离线系统起点进行监控，以最小化规则影响。

数据及时性

在保证数据准确性的基础上，还需确保数据及时提供服务，否则数据价值将大打折扣甚至丧失。阿里巴巴大部分离线任务以天为间隔（天任务），数据产品或决策报表通常要求在每天9:00甚至更早产出。为确保前一天数据完整，天任务从零点开始运行，但计算任务在夜间执行，要确保按时产出，需要一系列报警和优先级设置，使重要任务优先且正确地完成。重要任务是资产等级较高的业务。

任务优先级

对于Map和Reduce任务，调度为一个树形结构（RelNode树），当配置叶子节点的优先级后，该优先级会传递到所有上游节点，因此优先级设置都落在叶子节点，而叶子节点往往就是服务业务的消费节点。设置优先级时，首先确定业务的资产等级，高等级业务对应的消费节点配置高优先级，一般业务配置低优先级，确保高等级业务准时产出。

任务报警

任务报警与优先级类似，也通过叶子节点传递。任务运行难免出错，因此需要有一套监控报警系统，对高优先级任务一旦出错或可能延迟，就报警通知任务和业务负责人。摩萨德是阿里巴巴自主开发的监控报警系统。

摩萨德

摩萨德是离线任务的监控报警系统，是数据运维不可或缺的保障工具。它根据离线任务运行情况实时决策是否告警、何时告警、告警方式及告警对象等，有两个主要功能：强保障监控和自定义告警。

强保障监控是摩萨德的核心，紧密围绕运维目标即业务保障设计，只要业务的预警时间受到威胁，摩萨德就一定会告警给相关人员。强保障监控包括：监控范围覆盖强保障业务的任务及其所有上游任务；监控异常包括任务出错、任务变慢、预警业务延迟；告警对象默认为任务Owner，也可设值班表；告警时机根据业务设置的预警时间判断；业务延迟预警和出错报警均依据“产出预警时间”。产出预警时间由摩萨德根据业务上所有任务最近7天运行的平均时间推算而来。告警方式支持电话、短信、旺旺、邮件等，视重要紧急程度而定。例如，生意参谋业务资产等级为A2，要求早上9:00产出数据，可定义强保障监控，业务产出时间9:00，预警时间7:00。若摩萨德推测生意参谋产出时间要到7:30，则电话告警值班人员，由其判断如何加速产出。产出时间推算虽有误判可能，但总体准确。

自定义监控是轻量级功能，用户可按需配置，主要包括：

出错告警：可根据应用、业务、任务三个监控对象配置，出错即告警；
完成告警：可根据应用、业务、任务配置，完成即告警；
未完成告警：可根据应用、业务、任务配置，未完成即告警；
周期性告警：针对某个周期的小时任务，若在某时间未完成即告警；
超时告警：根据任务运行时长配置，超时即告警。

摩萨德甘特图服务

对于业务的运行情况，摩萨德提供一天的关键路径，即完成业务的最慢任务链路图。由于每个业务上游可能有成百上千个任务，这条关键路径对于业务链路优化至关重要。

4.2.4 质量衡量

保障数据仓库的数据质量有许多方案，评价这些方案的优劣需要一套度量指标：

数据质量起夜率：数据仓库的作业任务通常在夜晚运行，一旦出现问题就需要值班人员起夜处理。每月起夜次数作为衡量数据质量建设完善度的指标。
数据质量事件：记录每一次数据质量问题，既衡量数据本身质量，也衡量数据链路上下游的质量，是重要度量指标。功能包括：跟进问题处理过程；归纳分析数据质量原因；查漏补缺，找到问题根源，并针对类似问题提出后续预防方案。
数据质量故障体系：对于严重的数据质量事件，会升级为故障。故障指问题影响严重，已给公司带来资产损失或公关风险。数据从采集到消费整个链路经过数十个系统，任何环节出现问题都会影响产出，因此需要一种机制将各团队捆绑在一起，目标一致、形成合力，故障体系由此诞生。一旦出现故障，通过故障体系要求相关团队第一时间跟进解决，消除影响。

故障定义：首先识别出重要业务数据，将其注册到系统，填写业务情况，如技术负责人、业务负责人、数据应用场景、延迟或错误带来的影响、是否会发生资产损失等。完成后，将这部分数据的任务挂到平台基线上，一旦延迟或错误，即自动生成故障单，形成故障。
故障等级：故障发生后，根据故障时长、客户投诉量、资金损失等标准判断故障等级，分为P1至P4。各团队有故障分概念，年底据此评估本年度的运维效果。
故障处理：故障发生后，需快速识别故障原因并迅速解决，消除影响。处理过程中会尽量将进展通知相关方，减少对业务的影响。
故障Review：故障复盘，分析故障原因、处理过程复盘、形成后续整改措施（Action），并以文字详细记录，对故障责任归属到人。