网易数帆大数据场景下的 DataOps 实践

导读：目前，数据开发面临的质量问题呈现不断增加的趋势，对数据的交付影响也越来越大。如何通过 DataOps 思想规范数据开发流程、减少质量问题，需要数据平台开发人员进行更多的探索与实践。本次分享介绍了网易数据平台结合 DataOps 思想后，在解决数据质量问题方面的落地和实践。

今天的介绍会围绕下面四点展开：

• 数据开发面临的质量问题

• 网易大数据平台的事前防控

• 网易大数据平台的事后防控

• 网易大数据平台的数据沙箱

网易有数是网易杭州研究院下辖的业务线。网易有数支撑了网易内部所有的数据中台产品，同时也为公司外部客户提供服务。网易内部客户包括，音乐、电商、教育、传媒、办公，网易外部客户涉及了金融、零售、农业、能源、制造、物流、医药行业和公司。

企业内部数据面临着效率，质量，成本和安全问题。

效率方面，数据中台提升了数据需求交付速度，没有数据中台时数据需求平均需要一周时间才能被满足。由于数据表建设标准不同，导致数据表数量庞大，数据中台规范了表的设计和使用，不再出现一个业务八万张表的情况。

质量方面，在中台建设不完善时平均每周有 10 个数据质量问题，数据使用的业务方对数据中台的信任程度会因为数据质量问题降低。90%数据质量问题通常是在使用过程中发现的，在数据开发过程中比较难通过测试保障数据开发结果是完全正确的，业务方使用过程中发现问题会有投诉。每个季度都会出现由于指标统计口径不统，用户反馈数据有问题的情况，指标统计口径不统一导致的数据不一致问题会让业务方无所适从。超过 50%的 Bug 都是数据开发造成的，提升数据质量是非常迫切的需求。

成本方面包含计算成本和存储成本，各个业务线下有很多表，但是有大量 30 天内没有使用的表、这些表占用了大量存储资源。此外，表的计算也要消耗大量计算资源，但很多表没有人用或是被不重要的数据应用所使用。

安全方面，数据权限体系混乱，流程不清晰，申请权限流程需要 1 天时间。权限缺少生命周期管理，一旦授权就长期持有权限，权限最小化原则难以落实。权限粒度粗，授权难以精细化控制。权限较大的情况下存在数据被误删除的风险。权限缺少治理环节，申请权限但不使用的现象广泛存在，存在安全隐患。

01 数据开发面临的质量问题

数据应用的实际交付周期比计划交付周期长很多，其中由于返工再交付，导致的时间拖延问题可能由多方面问题引起。如缺乏需求设计，Code Review，充分的测试和数据校验环节，数据开发交付了慢 SQL，资源占用多，任务编排难度大。

数据开发过程中经常面临以下问题：

① 物理资源不足

可能由于计划内或计划外大促活动，容量规划不足引起；也可能是数据开发交付的数据计算任务性能差，消耗大量资源导致。

② 数据开发导致的质量问题

问题包括：代码发布上线，引用了测试库；使用了固定分区；代码格式处理异常，鲁棒性不高；任务没有配置依赖等任务配置问题。

③ 基础设施问题

如开源系统 Bug，人为运维故障。

④ 业务源系统变更

业务源系统数据库表结构变更没有及时同步，例如数据进入数仓前是从其他数据源中读取的，业务源方面的数据源变更、表变更都会影响后续数据处理加工逻辑。业务源系统环境变更、新增日志节点后没有采集，没置日志同步任务、导致数据缺失，源系统数据格式异常，例如非法的 IP 格式等。

我们记录了 321 个数据质量事件，由数据开发的质量问题导致的数据问题超过 50%。数据质量问题为什么这么多？我们认为有如下四点原因：

• 缺乏管理：数据开发任务经常变更，常常由于没有经过测试和确认就上线，导致出现了很多线上问题。

• 协作困难：数据链路长，上游表和任务的变更可能会导致下游任务延迟或数据混乱。

• 上线时间紧：任务变更需要人工 Review 再发布上线，Review 过程会对上线速度影响较大。但业务方更期望任务尽快上线，Review 流程难以落地，数据开发流程中难以完全规避开发除低质量 SQL。

• 没有支撑工具：缺少自动化的数据测试工具，数据开发任务的测试成本较高。

网易大数据 DataOps 在数据开发流程的事前防控方面，基于数据开发的沙箱模式，在任务上线前进行质量检查。任务提交上线前需要通过了 Code Review、检查是不是通过了 SQL Scan、表形态探查，需要运行任务对比和之前数据表的结果区别，还需要分析新上线的任务对下游数据的影响。经过质量检查后，需要为上线的任务提交工单，工单需要有相应流程负责人审批，审批时需要确认质量检查是否全部通过。经过审批后运行调度检查，检查点包括：任务调度依赖是否已经配置，运行参数是否合理，例如 Spark 参数不可以配置过大，是否配置了任务失败时自动报警。

事后防控是基于数据沙箱的线上模式的。事后防控包括数据质量中心监控，基线报警，任务关键链路，任务产出影响，实例运行概况。

02 网易大数据平台的事前防控

1. SQL Scan

SQL Scan 依托于我们的通用 SQL 解析服务，可以对任务 SQL 进行扫描，按照相应的规则进行匹配，检出质量隐患。

常用的检查包括代码规范、代码质量和代码性能几方面。首先代码规范中规定了不能使用 Drop、Truncate、Create 关键字，而且会检查 SQL 语法是否通过校验。代码质量类的检查包括 select 的字段和插入表的字段的数量和类型需要是一致的，表关联 on 字段也要一致。代码性能相关检查包括是否使用了 select *语法，我们默认为 select *添加 limit；distinct 关键字结果过多、表关联 on 产生笛卡尔积过大时候提示。

2. 形态探查

对表进行数据形态的探查，一般用于新接入的源头表或者新加工出来的数据的初步探查，目的是了解数据整体的情况。也可以通过探查，发现数据的潜在问题，比如检查主键唯一性、字段空值、非常规字段值等。

表级探查会检查探查总记录数、主键去重记录数、确定主键唯一性。字段级会查看枚举字段枚举值分布、查看字段去重后总量、字段空值/空串比例、字段最大长度、字段最大长度预览、字段最小长度、字段最小长度预览、字段最大值、字段最小值。

图中是数据测试中心-形态探查的一个案例，可以看到表级和字段级探查的结果。

3. 数据比对

对两个表进行逐字段级别的比对，一般用于重要表的加工逻辑调整后或者模型重构后，比对原有数据，确保加工出来的新数据和原有数据的一致性。如果比对结果一致或差异可解释并能接受，则可认为新的逻辑可以提交上线。图中是数据比对的案例，其中整体不一致率在 21%和 30%，如果认为这个值在可接受的范围内则认定测试通过。

4. 下游影响分析-数据血缘

任务 A 产出了表 A，表 A 作为任务 B 的上游表，任务 B 产出表 B 和表 C。任务 C、任务 D 分别依赖表 B 和表 C，并分别产出表 D 和表 E。针对每个不同的表，业务方可以通过元数据中心打标签，例如为表 D 打“数据应用 A”的标签。表 D 表 E 分别打了标签 2 和标签 1。可以看到，表 A 的变动会影响表 B、C、D、E，从而影响到标签 1 和标签 2。上游任务的表 A 可能影响到数据应用中用到的标签 2 和标签 1。

下游影响分析的主要作用是获取当前任务产出表及其所有下游产出表的影响标签，确定影响范围。

下游影响分析，基于自研通用 SQL 解析引擎，获取任务输出表，和数据血缘比对后，获得影响标签，为任务负责人快速确认变更的影响范围。SQL 解析引擎可以解析 Hive、Oracle、MySQL 等 SQL。根据血缘标签、数据标签确定影响范围，根据配置的策略进行工单审批。

下图是下游影响分析的例子，提交上线时可以看到当前提交任务可能产生的影响。

5. 上线流程管控

提交上线前可以配置流程的工单配置，包括强制测试走工单，圈选核心任务走工单，圈选核心标签走工单。

提交上线前需要进行任务校验，检查是否有待测试的节点和影响的标签。确认可以上线后会交给审批人做相应审批，审批通过后任务上线完成。

6. 自动推荐依赖

自动推荐依赖功能同样依赖于数据血缘功能，任务在设置上游依赖时，会用 Antlr 的通用 SQL 解析分析当前任务的 SQL，获取输入表，以此输入表作为输出表，查找上游任务，把它作为依赖推荐给用户。

下图展示了自动推荐依赖的例子，和严选用户给我们的评价。

03 网易大数据平台的事后防控

1. 基线影响分析 - 预计完成时间

1）预计完成时间，是基于预计运行时长计算而来的；

2）任务运行时的依赖图，可以看做是一个有向无环图。针对图中任意节点，可以根据历史的运行数据，计算出一个预计执行时长；

3）当前节点预计运行时长 = Avg(近 14 天运行时长) （加权平均）；

4）当前任务的预计完成时间 = Max（上游预计完成时间） + 当前任务的预计运行时长，以此递归。

基线影响分析的流程是：设定几条时间线，并将认为重要的线上任务关联到这些时间线上，当这些任务的实例或上游实例运行失败，或者这些实例的预计产出时间超过对应的时间线时，系统会触发报警通知给值班人员。

如下图所示，实际任务 D 设定了 9 点的时间基线，如果数据任务在 7 点由于上游任务失败下游等待而没能运行完毕或运行失败，此时任务系统发出报警，提示需要人工介入和设置基线的任务的依赖任务失败情况。如果上游依赖的任务产出超出基线设定时间，任务平台也会发出报警提示由于上游任务拖延导致数据产出延迟的情况。

2. 基线运维

基线运维可以配置基线和优先级，每个基线都有预警时间和破线时间，我们会根据前面介绍的公式展示运行预估信息，如果需要预警会发报警并在平台上展示报警情况。这样能做到提前预警、提前解决、将事故扼杀在摇篮中。

3. 实例运行概况

下图是实例运行概况，主要功能是宏观展示项目下所有任务产出进度。可以看到离线任务在夜间运行，7 点左右已经完成了 80%的任务，是一个治理得比较好得例子。图中上面一排是失败的任务情况等信息。

4. 任务关键链路

任务关键链路类似于项目管理中计算工期的功能，可以寻找任务链路瓶颈，定位和优化关键任务、保障数据按时产出。

5. 任务产出影响

我们将任务血缘、数据血缘进行打通，评估任务产出影响。图中是电商用户的案例，可以看到标签关联的相关任务产出信息。血缘是通过 SQL 静态解析分析出任务的依赖，这里我们根据 spark 和 hive 运行中获得数据的实际血缘信息后进行计算和展示，能更加精确地计算和定位问题。

6. 任务冻结池

当上游任务产出数据出错时，可以快速冻结此任务及其下游任务，减少错误数据的影响。任务冻结池主要用于大规模数据错误恢复。找到有问题的任务，冻结它和它下游的任务，如果任务已经未运行则不再开始运行任务、如果任务已经在运行中则杀死任务。冻结完成后，数据开发恢复了数据，再把任务解冻，数据链路就可以恢复运行了。

7. 任务加速器

加速器和冻结类似，冻结是把整个链路停止，加速器是只允许一条链路跑。在客户计算资源较少但计算任务多的情况下，离线数仓在 0 点开始运行导致 0 点成为任务的高峰期，此时资源竞争、可能出现核心任务跑不完的情况。此时可以把核心任务加到加速器中，优先保障核心任务产出，其他任务在核心任务运行完毕后继续运行。

8. 数据质量中心

这一模块核心目的是让数据问题的早发现、早恢复。数据质量中心校验数据的完整性、一致性、正确性和时效性。

数据完整性方面对表数据量、主键唯一性、字段空值和为 0 情况进行监控。一致性方面，需要校验同一个指标在不同模型一致，对相关数据一致性监控，对如商品购买率与商品访问用户数、商品购买等用户数相关指标进行了监控。正确性方面，校验字段格式，例如 IP 格式、商品只能归属一个 BU、数据违反尝试，例如日期还未发生等。时效性方面，基于任务产出时间、任务的历史运行时间、对任务的产出时间进行预测。

数据质量中心的一个功能，质量大屏，可了解当前数据质量的监控情况，如下图所示。

下图是数据质量中心提供的质量分排行榜功能，是一个以开发人员为维度的排行情况，方便数仓负责人快速查看其他人员的数据质量。

04 网易大数据平台的数据沙箱

设计数据沙箱目的是解决我们在数据开发过程中的常见问题。

在数据开发过程中，可能出现测试任务影响了线上任务运行的情况，例如测试任务执行大量文件操作，导致 NN 负载过高，影响了线上任务调度。我们通过物理隔离生产测试集群规避了这个问题。有开发模式下调试任务不小心写入线上数据的表，导致测试任务污染线上数据的问题，我们禁止了开发模式下写入生产集群。有任务发布忘记修改测试库的问题，发布后忘记修改导致线上任务引用了测试库，引发了数据混乱问题，我们通过变量引用的方式让任务从开发模式到生产模式不用修改代码。为了防止出现 HDFS、Yarn 这类基础组件升级引起兼容性问题，我们让测试集群承担起灰度集群的功能，让基础组件先在测试集群上运行一段时间后上线到线上集群。数据开发需要利用数据进行测试，为解决数据导入导出效率问题，我们支持了开发模式读取线上数据进行测试的模式。

数据沙箱的线上模式和开发模式共用 MetaStore、调度系统、开发平台，但是开发模式和线上模式各自有独立的 YARN、HDFS 集群。

升级版数据沙箱，适用于金融行业客户的高标准隔离场景。

客户需要将开发环境和测试环境完全隔离，两套数据沙箱叠加在一起，在开发平台和开发模式下做开发，在开发平台线上模式下做联调，联调通过后通过离线任务批量导出数据到线上环境的验收环境中，在线上用户经过验收后把开发任务提交到线上集群的线上环境作为生产运行。

关于解决开发环境和测试环境引用数据库，我们规定涉及到数据库的地方通过变量进行引用，根据不同环境平台提供自动替换的能力，这样开发者就不再需要上线时修改 SQL。如图中的 ${dm}，我们在开发模式下使用开发模式的数据库变量，在线上模式使用线上变量。

今天的分享就到这里，谢谢大家。

分享嘉宾：