这届黑客马拉松，和效率“杠上了” | StartDT Hackathon

“能自动化的事，绝不亲自动手！”

不久前，StartDT Hackathon（2024 春季）圆满收官。

本季由各小组携自选题参赛，他们不约而同地提出了为各个生产环节提效的选题。最终，有 5 组通过提测，参与终审。

“自动评审代码质量，什么中台产品都能用。”

# 编码卫士队：代码质量评价模型

代码不规范，运行两行泪。在大数据平台，质量不达标的代码不仅会让单个任务失败，还可能出现“把整个项目资源打满了”、“下游任务都挂了”、“生产环境搞崩了”等连带问题。

过去业内常见做法是建立并维护项目代码规范的文档，再人工评审（或者直接不评审）。这不仅耗时费力，对审核代码的同事不友好（低级问题遇到得多了，谁能不暴躁呢），对于企业的数据生产来说更是重大隐患。

因此，编码卫士队出手，建立了“代码质量评价模型”，包括“Hive-SQL 代码质量评价模型”、“Hive 表质量评价模型”：

· 提供开发任务中不符合规范的详细清单，以便逐条处理；

· 自动产出质量分，以便项目管理者直观了解代码规范程度。

代码质量评价流程

Hive-SQL、Hive 表采用了不同的质量评价模型，但流程一致，且均产出质量分和评价明细。质量分由模型各细项及权重综合得出，如需要，可以根据不同客户、不同项目调整质量分的构成。

Hive 表质量评价模型，基于 SimbaMetric 的数据标准功能落地

 输出的质量评价结果

“这套模型已嵌入到 DataSimba 产品中，可以融入到客户日常的数据开发工作中，持续保障代码质量。”编码卫士队介绍，“如果没有使用 DataSimba（而是其他平台产品），我们也有一套‘外挂’模型，支持客户对接使用。”

“资产和它相关的资产都能自动打标签。”

# 元数据小分队：基于血缘的标签传播

基于前期集中化的用户调研结果，元数据小分队发现客户需要更精细化、更高效地管理数据资产，而给资产打标签是其中的重要一环。

为此，元数据小分队提出了“批量打标签”和“基于血缘的标签传播”两大方案，不仅能提高打标签的效率，还能确保不会遗漏增量资产。

 如上图所示，基于 SimbaOS Kernel 元数据域“实体”对象的打标签能力，元数据小分队实现了给资产设置标签的功能，并可设置标签是否支持传播（通过传播完成批量打标）。标签传播基于图（Graph）的数据结构进行。

可传播的标签将随血缘向下传播（gif 图）

资产支持被打上/传播多个标签

进一步，当元数据域检测到数据流动或处理发生变化时，会实时更新其血缘关系图和标签信息，确保标签的准确性。举个例子，资产 A 先打上了可传播的标签 a，此后 A 的下游出现新的资产 B，B 也会自动被贴上标签 a。

血缘标签实时传播（gif 图）

优化数据资产的标签管理体系设计，对于数据安全管控、重要数据监管等场景有重要意义。在今年初夏的产品发布会上，奇点云的资产工厂将正式面市，期待客户的反馈。

“让我手动配置 1000 个 job，我是不想干的。”

# 简单点队：自动“上云”与 Job 自动合并入 Task

在数据中台建设、从旧中台迁移到新中台的前期环节，有 2 件事，简单点队想让它们简单点。

· 其一，把业务系统里的表导入到 DataSimba（即“上云”）。

简单点队设计了技术方案，能自动获取源库对应的表结构信息，配置数据库数据类型和 Hive 数据类型的映射关系，自动生成上云任务，从而提高上云环节的效率。

· 其二，把 Job（作业）合并到 Task（任务）。

DataSimba 采用 Task/Job 双层混合调度，Task 决定任务在可用资源上的调度顺序，编排不同 Job 的执行计划，Job 则通过与配额（Quota）配合，完成底层资源的调度和优化。所以在 Job 开发完成后，还需要划分合并为若干个 Task。

“双层调度在使用过程中是好，但如果客户是从其他平台迁移过来，前期的配置令人抓狂。”简单点队表示，“企业客户通常有 600 个以上存量 Job，有些客户有上千个 Job，逐个手动操作不仅耗时费力，还容易漏配置依赖。”

为此，简单点队设计了自动合并 Task 的技术方案：

 “原本整个过程，大的项目可能要 30 个人天，现在只要 0.5 人天。（视资产数量不同，时间略有差异）”简单点队谈到，“不仅是在前期上中台、模型设计的环节，后期客户运维时也可以简单地完成 Job 添加，而不需要一个一个解锁依赖、配置依赖。这能把数据开发工程师从枯燥无味的工作中释放出来，去完成真正需要人来解决的事。”

“提效 62%！”

# 双人成行：多分支代码合并提效工具

正如在这篇生产线改造的记录里所说：私有化部署的大型平台软件产品，不同客户的独立环境（M），维护不同的产品发布版本（N），从数学上说，就会有 M*N 种维护场景。具体到 Bug 修复的代码合并环节，双人成行组介绍：每个 Bug 往往涉及 3-4 个版本，每个版本都会经历重复且繁琐的修复动作。

为解决上述问题，双人成行组开发了代码分支合并工具 Branch-merge-cli，以快速完成代码分支处理和终端交互。

 经多次测试，使用该工具确能提高反向合并流程的效率，通过批量执行一系列步骤，有效简化反向合并的过程，合并净效率提升了 62%。“马上就可以用！”双人成行组自信满满。

“让工程化在数据开发团队真正落地。”

# 勇往直前队：发布助手

“小明又热改 SQL，出 bug 把生产环境搞崩啦！”

数据生产无小事。伴随数据系统从边缘走向业务核心，企业的数据生产应当建立一套符合工程标准的发布机制，避免未经测试、审核的行为直接影响到生产环境。

为此，勇往直前队提出了“基于 GitLab 的发布助手”。简单理解，（数据开发）在 DataSimba 中对作业、任务、数据源、表、函数、数据服务、资源等的种种改动，均需要经过发布助手，方可发布到生产环境（或生产域）。同时，也可以通过发布助手追溯各项变更，更方便地完成版本管理。

勇往直前队介绍，发布助手基于 GitLab 与 DataSimba 协同实现，通过 GitLab 完成运行环境管理、版本管理、发布审核、数据平台配置资源可视化展示等职能，DataSimba 则提供项目一键发布（按项目维度全量发布）、资产特定发布等能力。

示意：部分增量发布，经过 MR 审核

“要求每一项变更/发布必须经过发布助手，能让数据开发的工作流更规范，控制代码质量，从而规避未经审核的代码直接发布、影响生产环境的致命问题。”评委谈到，“这也是客户建立数据团队过程中越来越重视的。”

本期黑客松更新了计票方式，在场所有观众和评委均有投票权。最终共 3 组优胜：“元数据小分队”第 1 名，“编码卫士队”第 2 名，“双人成行”第 3 名。

评委组表示，这是 StartDT Hackathon 有史以来首次采用全自由命题的方式，而几乎所有参赛组都“英雄所见略同”地选择向“提效”的方向探索——客户的数据质量、数据资产管理，以及奇点云自身的工程生产线，都还有大量的提效空间。

本期黑客松较为突出的“自动化批量处理”是提效的常见手段，我们将继续追踪“提效”这一命题，带来更多新鲜讨论（包括 AI），敬请期待~

第一名：元数据小分队

感谢评委，感谢各位给我们投票的小伙伴们。本次黑马选题上灵活性很高，又因为本次赛制是现场实时投票实时出结果，真是紧张又刺激，特别好玩。

借着黑马这个机会我们完成了之前一直想做的内容。最终拿到第一名真的是意料之外，行业线同学的作品特别优秀，从技术难度上和完成度上很好，可能是我们现场进行答辩效果比较好，特别侥幸获得了第一。

本次选择这个主题，是因为实现智能治理是我们团队的初心。相信通过我们的努力，可以让这一目标触手可及。

第二名：编码卫士队

非常荣幸能够在此次答辩中获奖，这是对"代码质量评价模型"的极大肯定和鼓励。

感谢数开同学们沉淀的模型规则和俊哥完成的代码实现，也感谢评委们的认可。欢迎感兴趣的同学一起交流！

第三名：双人成行

虽然上次失利了，但这一次，我要拿回属于我的一切（嚣张脸.JPG）。