数据中台-协作流程

一.简介

数据中台产品工具很多，管元数据，管开发，管安全等等，中间涉及到角色也很多数据产品、数据架构师、数据开发、应用开发、分析师……多个角色。既然数据中台要用到这么多工具，又涉及这么多角色，如果没有配套的协同流程和规范，那也没办法达到数据中台高效、高质量、低成本的建设目标。来看几件有意思的事儿。

二.协作流程

2.1 问题

建设数据中台是一项系统性的工程，不但要有技术的思维，更要有管理者的视角。所以接下来，数据中台最常见的协作流程：数据研发、数据分析、资产管理

协作流程如何运转关键问题

• 一个流程中涉及到了哪些环节？
• 这些环节涉及到哪些角色参与？
• 承载这个场景的工具产品是什么？
• 这些环节之间是如何衔接的？

标准的数据研发流程包括四个阶段：需求阶段、开发阶段、交付阶段和运维阶段。

三.设计

研发角色角度协作开发

3.1 需求阶段

需求是数据开发的起点，如果想让后面的流程高效运作，那需求的定义一定要清晰，这样协作者（数据开发、应用开发、数据产品 / 分析师）对需求的理解才能一致。

在数据中台，数据需求通常是以指标的形式出现的，比如提了一个需求（计算每日黑卡会员的消费额）。 那什么时候会提需求？又什么时候会频繁用到指标系统呢？ 一般来说，分析师在制作新的报表，数据产品经理在策划新的数据产品时，会提一些新的指标需求，然后就会在指标系统登记指标（包括指标的业务口径、可分析维度、关联的应用、时间周期信息）。这个时候，指标的状态就是待评审状态。

评审

然后，管理指标的数据产品（没有这个角色的，分析师也行）会叫上相关的数据开发、应用开发、提出这个需求的分析师或者数据产品，对指标进行评审：

• 指标是新指标还是存在的指标；
• 如果是新指标，那么是原子指标还是派生指标；
• 确认指标业务口径、计算逻辑和数据来源。

评审结果

• 如果是新指标，就在指标系统上录入相关信息，指标状态是待开发状态；
• 如果是存在的指标，应用开发可以直接找到这个指标所在的表，然后看这个表是否已经有现成的接口可以被直接使用，如果有，就直接申请授权，如果没有，可以基于这张表发布一个新的接口。

3.2 研发阶段

3.2.1 研发流程

现在，新指标的状态是待开发状态，接下来就要进入开发阶段。在这个阶段，你要秉持“先设计，后开发”的理念。

注意

数据开发设计过程，可能要用到一些已存在的数据，这时就要利用数据地图发现已存在的表，理解这些表准确含义。

设计

在模型设计过程中，要对模型中每个字段关联前面设计好的指标，以及可分析的维度。比如，我们对下图的 account 字段，标记为指标“用户消费金额”，user 标记为“买家维度”。这个标记会把模型和指标建立关联关系，然后把前面设计的指标落实到了表中。

提交工单

到这一步，模型设计还不算完，数据开发还要提交模型上线工单。工单会根据模型所属的主题域，流转到对应域的负责人，并通知对应域负责人进行审批。审批通过后，模型会自动发布到生产环境。

这里你要注意一下，数据域的负责人一般是数据架构师，他需要检查数据是不是重复建设，要保证自己管理的域下模型设计的相关复用性、完善度、规范性的相关指标。

模型变更

除了新建模型之外，已有模型也会存在变更的情况（比如增加一个字段或变更字段枚举值）。这个时候，要根据数据血缘，通知所有依赖这个表的下游任务的负责人，在负责人确认以后，才能进行模型变更。

3.2.2 示例

一名数据开发，接到需求完成模型设计之后，就要开始模型的开发，首先他要把数据从业务系统导入数据中台中，第一步申请对应数据库权限，然后在数据传输中心建立数据传输任务，把数据同步过来。

接下来，要清洗和加工数据，那他要在数据开发中心开发数据的 ETL 任务，根据之前模型设计，编写对应任务的代码。

测试验证

代码完成后，要在数据测试中心，验证数据：

• 一个是进行数据探查，确定新加工的数据是否符合预期；
• 另外一类是对原有模型的重构，新增字段或者更新部分字段。此时不仅要验证新加工数据的正确性，还要确保原有未修改数据与修改前是否有改变，我们管它叫数据的比对。

数据测试中心还提供了静态 SQL 代码检查的功能，主要是发现一些使用固定分区、使用测试环境的库、使用笛卡尔积等代码问题，我们把这个过程叫 SQL Scan。 在我们的开发规范中，只有通过 SQL Scan 的代码才被允许发布上线。

数据质量

在数据测试完成后，数据开发角色还要在数据质量中心里配置稽核校验规则。目的是对任务产出的数据进行校验，在数据出现问题时第一时间发现问题，快速地恢复故障。

在开发规范中，主键唯一性监控、表行数绝对值以及波动率监控等属于基础监控，是必须要添加的，另外还需要根据业务过程，添加一些业务规则，比如一个商品只能归属一个类目等。

发布

配置完稽核规则，数据开发要任务发布上线了。任务发布上线，要设置调度周期，配置任务依赖，设置报警规则以及报警对象，选择提交的队列。

审批

任务发布与模型发布一样，也需要进行审核。首先数据开发需要发起任务发布上线的工单，然后工单会根据产出表所在域流转到对应域负责人审批，审批的主要内容：

• 确认任务参数设置是否合理，比如 Spark Executor 分配内存和 CPU 资源；
• 检查任务依赖、报警设置是否正确，核心任务必须要开启循环报警，同时要开启报警上报；
• 重点审核稽核规则是否完备，是否有缺失需要补充。

在审批通过以后，任务就会发布上线，每天就会有数据源源不断的产生了。

小结

数据开发模型研发流程，虽然是一个模型研发的环节，可涉及这么多的工具产品，还包括了多个审批流程，但是这些工具和流程，都是标准化研发不可或缺的。例如如果不测试，就会导致大量的 BUG 上线，如果没有稽核监控规则配置，就会导致出了 BUG 还不知道，等着被投诉。

3.3 交付阶段

在数据中台之前，其实并不存在单独的交付阶段，因为数据开发加工好数据应用需要的表，他的工作就已经结束了，剩下的就是应用开发的事儿了。应用开发需要把数据导出到应用所属的数据库，然后开发 API 接口，供客户端调用。

数据中台，提出了数据服务化的思想，数据中台暴露的不再直接是数据，而是服务。数据开发不仅需要加工数据，还需要把数据发布成 API 接口或者其他服务形式，提供给业务系统或者数据产品调用，从而形成了单独的数据交付阶段。

数据服务承载了数据交付的整个流程。数据开发，可以直接选择一张数据中台的 Hive 表，然后在数据服务上创建一个数据抽取任务，把数据抽取到中间存储中（中间存储可以是 DB，KV，MPP 等）。这个过程，数据服务会自动根据中台数据的产出时间，在调度系统中创建数据导出任务，建立到产出任务的依赖。

接下来，数据开发可以基于中间存储发布 API 接口，定义输入和输出参数，测试 API 后发布上线。这个时候，数据开发的工作才算完成。

最后，应用开发在数据服务上创建应用，然后申请对该接口的授权，等数据开发审批通过后，就可以直接调用该接口获取数据了。

小结

数据交付完呢，还不算完，接下来数据开发的工作，还需要保证任务的正常运行，这就进入了第四个阶段，运维阶段。

3.4 运维阶段

承载运维阶段的工具产品主要是任务运维中心。 在这个阶段的第一责任人是任务负责人（一般是这个任务对应的数据开发）。这里有这样几个过程：

• 数据开发接到报警后，要第一时间认领报警；
• 任务运维中心提供了报警认领的功能，数据开发点击认领，代表数据开发开始处理这个报警；
• 如果报警迟迟没有人认领，任务运维中心会每隔 5 分钟会发起一次电话报警，直到报警认领；
• 如果报警一直没有认领，系统会在 3 次报警，15 分钟后进行报警的上报，发送给模型所在域的负责人。

这样的机制设计，确保了报警能够在第一时间被响应，我们在实施这项机制后，报警的平均响应时间从 2 个小时缩短到 15 分钟内。

那么当数据开发认领报警之后，需要开始排查，首先要确认上游依赖任务稽核规则是否有异常（也就是输入数据是否存在异常）。如果没有异常，数据开发要通过任务运行日志，排查当前任务的问题原因，并进行紧急修复，接下来再重跑该任务，任务重跑完，还要通过数据地图，找到所有依赖该表的下游任务负责人，发送“下游任务需要进行重跑”的通知。

故障恢复完，还要进行复盘，其中重要的事情就是补充稽核规则，确保不再出现犯过的错误。通过这样不断沉淀和记录，数据中台的数据质量就会越来越高，数据质量问题也会减少。