数据研发就只是写代码吗？

大数据真有意思 2020-09-03

789

点击关注上方“知了小巷”，

设为“置顶或星标”，第一时间送达干货。

几件有意思的事儿

与数据中台有关的角色：数据产品、数据架构师、数据开发、应⽤开发、分析师。数据中台要⽤到很多组件或⼯具，⼜涉及这么多⻆⾊，如果没有配套的协同流程和规范，那也没办法达到数据中台⾼效、⾼质量、低成本的建设⽬标。这里有两件有意思的事⼉。

郝有才（化名、数据开发）修改了数据中台⼀个数据加⼯任务，变更了产出的数据表字段，因为没有通知到下游数据的负责⼈，结果影响了10多个任务，⼤量数据应⽤出现异常。这属于⽐较典型的“协作事故”，下面看⼀个跨团队之间协作的问题。

张漂亮（化名、业务系统的服务端开发）今天业务上线，她提交了数据库变更⼯单，修改了商品交易明细表的商品类型枚举值。但这个升级并没有通知数据部⻔，结果导致基于商品类型计算的多个指标数值出现错误，严重影响了第⼆天多个数据产品的数据产出。

这些教训告诉我们，建设数据中台是⼀项系统性的⼯程，参与者不但要有技术的思维，更要有管理者的视⻆。为此，在数据中台中，需要把握三个最常⻅的协作流程：数据研发、数据分析、资产管理。

作为一名普通的数据开发，在面对数据研发的场景以及使用场景化的⼯具产品时是如何进行高效协作的呢？

重点理解⼀个协作流程是如何运转的。

⼀个流程中涉及到了哪些环节？
这些环节涉及到哪些⻆⾊参与？
承载这个场景的⼯具产品是什么？
这些环节之间是如何衔接的？

也许在很多⼈的印象中，数据研发就是写代码、甚至是写SQL的，其实对⼤规模、标准化的数据建设来说，这远远不够。标准的数据研发流程包括四个阶段：需求阶段、开发阶段、交付阶段和运维阶段。每个阶段中⼜涉及多个环节，如果缺失了这些环节，就很容易出问题，数据也会因此没办法⾼效、⾼质量的交付。

需求阶段

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

在数据中台中，数据需求通常是以指标的形式出现的，⽐如李天真提了个需求（计算每⽇⿊卡会员的消费额），⽽承载这个场景的产品就是指标系统【如何统⼀管理纷繁杂乱的数据指标？】。

那什么时候会提需求？⼜什么时候会频繁⽤到指标系统呢？

⼀般来说，分析师在制作新的报表，数据产品经理在策划新的数据产品时，会提⼀些新的指标需求，然后就会在指标系统登记指标（包括指标的业务⼝径，可分析维度、关联的应⽤、时间周期信息）。这个时候，指标的状态就是待评审状态。

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

指标是新指标还是已经存在的指标；
如果是新指标，那么是原⼦指标还是派⽣指标；
确认指标业务⼝径、计算逻辑和数据来源。

那评审后的结果⼜是什么呢？

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

研发阶段

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

因为很多开发都习惯边开发、边设计，想到哪⾥，代码写到哪⾥，这其实并不是⼀个好习惯。这会造成缺少整体的设计，开发过程中经常出现表结构频繁修改，代码返⼯，整体研发效率不⾼。

要先做好模型设计，⽽承载这个场景的⼯具产品就是模型设计中⼼【数据模型⽆法复⽤，归根结底还是设计问题】。数据开发在设计的过程中，可能要⽤到⼀些已经存在的数据，这时就要利⽤数据地图发现已经存在的表，然后理解这些表中数据的准确含义。

除此之外，在模型设计过程中，要对模型中每个字段关联前⾯设计好的指标，以及可分析的维度。⽐如，我们对下图的account字段，标记为指标“⽤⼾消费⾦额”；user标记为“买家维度”。这个标记会把模型和指标建⽴关联关系，然后把前⾯设计的指标落实到了表中。

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

数据域的负责⼈⼀般是数据架构师，他需要检查数据是不是重复建设，要保证⾃⼰管理的域下模型设计的相关复⽤性、完善度、规范性的相关指标。

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

⽐如，甄可爱是⼀名数据开发，她接到需求，完成模型设计之后，就要开始模型的开发了。⾸先她要把数据从业务系统导⼊数据中台中，那她第⼀步就要申请对应数据库的权限，然后在数据传输中⼼建⽴数据传输任务，把数据同步过来。

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

任务代码完成以后，甄可爱要在数据测试中⼼，验证数据：

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

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

在数据测试完成后，甄可爱还要在数据质量中⼼⾥配置稽核校验规则。⽬的是对任务产出的数据进⾏校验，在数据出现问题时，第⼀时间发现问题，快速地恢复故障。

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

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

任务发布与模型发布⼀样，也需要进⾏审核。 ⾸先甄可爱需要发起任务发布上线的⼯单，然后⼯单会根据产出表所在域流转到对应域负责⼈贾英俊审批，审批的主要内容：

确认任务参数设置是否合理，⽐如Spark Executor分配内存和CPU资源；
检查任务依赖、报警设置是否正确，核⼼任务必须要开启循环报警，同时要开启报警上报；
重点审核稽核规则是否完备，是否有缺失需要补充。
在审批通过以后，任务就会发布上线，每天就会有数据源源不断的产⽣了。

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

⽽数据研发完，接下来就是数据的交付了，如何让数据快速接⼊到数据应⽤中呢？

交付阶段

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

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

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

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

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

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

运维阶段

承载运维阶段的⼯具产品主要是任务运维中⼼。

在这个阶段的第⼀责任⼈是任务负责⼈（⼀般是这个任务对应的数据开发）。这⾥有这样⼏个过程：

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

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

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