数据开发平台

背景

• 数仓团队通过git来管理调度任务脚本，通过DataIn系统实现调度任务脚本的开发及维护。由于两套系统各自维护了一套调度脚本，难以保证完全一致，需要一套平台化的工具来辅助调度任务的开发并管理代码
• 缺少生产和开发环境的隔离，验证脚本通常是在本地修改SQL后再复制到zue或者beeline运行，测试过程中容易污染线上数据，测试代码误发布到线上，导致产生数据质量问题
• 通过引入开发平台，希望能够将调度任务脚本的开发及审批流程固化下来，提高开发效率，减少团队协作成本和平台使用成本

目标

• 使用开发平台替代git实现调度任务源码的管理，保证代码的一致性
• 通过开发平台实现调度任务的开发、测试、审批、上线，不需要跨多个系统，一站式开发，提升开发效率
• 上线流程规范化，对线上任务的修改需要负责人审批之后才能生效，保证线上任务的稳定运行
• 版本控制，用户的每次修改保存都会记录版本，历史记录可以追溯

架构图

环境隔离

• 物理隔离的本质是底层存在两套不同的集群，分别是测试集群和生产集群，用户在测试集群上进行代码的开发以及数据的读写，经过上线以后才发布到生产集群，整个过程中无法接触到线上数据，如果要进行测试数据的构建，可能需要同步线上数据或者通过采样、脱敏等方式去生成数据。
• 逻辑隔离的核心是底层只有一套生产环境的集群，只不过是进行了测试库和生产库的逻辑划分。这套方案对于开发人员而言其实是聚焦于写数据的隔离，不限制对线上数据的读操作，经过发布上线以后，所有的读写操作都在生产库上进行。
• 物理隔离方案的不足：
  • 业务灵活性：物理隔离其实是屏蔽了所有对数据的访问，对于一些低资产、低安全的一些表数据来说，其实是没有必要的。
  • 代码可复用性：多数据源对于集群的维护是比较困难的，测试过程中可能需要替换表名，上线负担比较重，代码的可复用性其实是不够的。
  • 测试数据的可维护性：离线数据开发，一般会采取局部测试方案，需要进行上游表的梳理，对于上游这些测试表的数据同步，工作是比较复杂的，由于这些数据是从线上同步过来的，对于这些数据在测试环境的权限管控也会带来新的问题。而且这些数据是线上数据，通常数据量都比较大，对于测试数据本身的生命周期管控也是比较繁琐的，综合来看，业务的维护意愿其实并不强，比较难以落地。
• 逻辑隔离方案：通过库表来进行隔离，一套代码就可以实现开发和生产环境的隔离

--线上脚本
INSERT OVERWRITE TABLE db.table PARTITION(p_date='$yesterday')
SELECT * FROM db.read_table t1 join db.read_table t2 on t1.id = t2.id

--在开发平台执行测试会自动替换写入的库名
INSERT OVERWRITE TABLE db_dev.table PARTITION(p_date='$yesterday')
SELECT * FROM db.read_table t1 join db.read_table t2 on t1.id = t2.id

上线流程

有了基本的环境区分，还需要进一步完善任务开发上线流程的设计。整个开发流程中引入了审核人角色，开发者需要完成数据开发与测试过程，审核人进行代码Code review。审批通过后，离线作业才能发布上线。

开发效率

有了环境隔离，上线流程，还要解决用户在开发中的效率问题

• 开发效率：用户在测试环境中需要手动再创建一张测试表，上线时还要同步修改线上表，为了解决这个问题，采用自动同步线上表结构的方式，无需再手动创建测试表，上线发布时会和线上表结构diff，生成DDL语句，一键同步到生产环境
• 协作效率：为了提高用户之间的协作效率，通过版本管理进行同步脚本内容
• 代码审核效率：上线过程增加了审核流程，为了降低审核人的审批负担，除了增加常规的版本对比，还增加了未在测试环境测试通过的任务不能提交发布，和线上版本冲突的需要同步后才能提交审核，通过这些检查项对用户上线的过程进行阻断

交互式开发

前文提到整个数据平台，其定位是偏生产调度的平台，业务通常没有在数据平台上进行开发的习惯

例如，一般用户可能会通过跳板机进行开发，高级用户可能会使用数据查询来进行一些开发。

有了开发平台后，用户可以直接在平台上进行SQL的编写，实时查看结果，提高用户的开发效率。

版本对比

保存作业的快照，在版本比对环节，将所有的作业属性抽象为代码和表单两种类型，最后在前端实现这两类属性的比对

为什么不使用Git? 如果我们用Git的方式去做打通的话，会受限于Git本身的能力，Git本身还是倾向于对文件的版本的管理 但是对于开发平台而言，其中的作业类型多种多样，不仅仅包含了代码，还有更多的像一些可配置项。 那么对于这些过程，如果通过Git，将所有的作业类型转换成代码的形式再去做统一的版本管理，难度是非常大的

WebIDE

为了进一步提升开发效率和用户体验，最终是以WebIDE为终态去做演进，具体如下图所示：

落地推广

• 前面讲到整个产品是从一个生产调度平台逐步演进为一个开发在线化平台，整个平台的产品体验以及代码流程、开发流程都有比较大的改造，为了保证产品开发过程中每个阶段都能及时获得阶段性成果，于是采用了MVP(最小化可行产品)的研发方式，具体分为四期进行，每期都会完成最小可行的一个能力。
  • 最小化引入开发流程：同步线上调度的脚本到开发平台，在开发平台修改脚本后实时同步到调度平台
  • 数据隔离：通过替换写入库名来实现在不同环境下进行开发
  • 上线审核：和审批流程对接，在审批环节进行Code Review
  • 提交检查：在测试环境自测通过后才能发布上线
• 推广
  • 按项目组逐步灰度：下线原来任务上传脚本入口，让用户通过开发平台上线任务，对用户在使用平台提出的反馈及时进行优化，做到让用户平滑过渡
  • 平台培训：帮助用户更好的使用平台

项目成果

• 使用情况：
  • 业务通过开发平台完全实现了生产和测试环境的隔离
  • 超过2万次上线审批
  • 测试表的总数量超过6000张
  • 每天UV100+, 100%覆盖数据开发用户
• 数据质量：使用开发平台后，因流程不规范导致的质量问题大幅度降低