基于大模型的数据血缘异常归因分析

近日，以“元数据技术及应用创新”为主题，最新一季StartDT Hackathon（奇点云黑客马拉松）正式收官。

本期黑客松共吸引了近50位选手参赛，有的在实时数仓领域显神通，有的则再次请出了大模型。这些小组都有个共同点——基于数据云平台DataSimba的元数据域“搞事情”。

篇幅所限，下文仅择本期最具代表性的2组，逐一介绍成果：

• 基于图引擎及可视化的作业异常诊断分析
• 基于大模型的数据血缘异常归因分析

赛前须知

“元数据域”能干啥？

元数据（Metadata），是描述数据的数据，能够提供数据的定义、结构、特征、关系等信息，例如字段、数据类型、数据来源、关联关系、质量特征等等。

在错综复杂的数据世界，元数据极为重要。它帮助我们更好地理解、管理、利用数据。

举个例子，在数字图片中，元数据包括拍摄日期、相机型号、曝光时间、光圈值等技术信息，也可能包含地理位置信息；在文档文件中，元数据则可能包含作者姓名、创建日期、最后修改日期、字数统计等等。

那“元数据域”又是干啥的？

根据“资源抽象，接口统一”的原则，数据云平台DataSimba将复杂的业务对象抽象为6个域、32个对象，以标准、简洁的RESTful API向上提供能力。对象的属性和行为可以被继承、更新、扩展及复用，从而规避重复建设、底层对接难度高、数据系统日益庞大冗杂等问题。

“元数据域”属6大域之一，主要负责帮助上层数据应用快速完成元数据实体的创建、关系和血缘维护、实体检索等相关操作。

 

 例如，DataSimba“资产检索”功能离不开元数据域中的“搜索”对象；对Hive表的影响分析功能，则得益于元数据域中的“血缘”和“关系”对象能力。

此外，元数据域提供统一标准的元数据模型，抽象不同大数据引擎、可视化BI、任务调度平台的元数据，实现元数据标准化和跨引擎转换，帮助上层应用屏蔽底层异构性，通过标准接口即可使用元数据。

简单来说，如果要在数据云平台上用元数据“搞事情”，就离不开元数据域的能力供给。

因此本次比赛，参赛各组不仅要熟知“元数据”的相关技术与场景，也要学会基于元数据域做应用和创新，才有可能在短短几天的赛期内完成项目闭环，交出优秀答卷。

#1 可观测、可修复，跟恐慌说拜拜

基于图引擎及可视化的作业异常诊断分析

作业出现了异常！Why？

受大数据平台组件、上下游依赖、高并发计算及人为配置等多重因素影响，作业出现异常时往往难以快速定位问题所在，评估出异常的影响面并及时修复。

“破壁者”组选择直面这个业内由来已久的问题，借力“元数据”，让异常问题可视可解，让企业的数据工程师不再因作业异常而恐慌。

破壁者组介绍，对作业异常的诊断处置分为三个阶段：

阶段一，异常可观测。

试想，如果你负责维护成百上千个数据开发任务，如何第一时间感知到哪些任务出现了问题？

通过元数据域，破壁者组获取了完整的数据源、表、任务、作业、实例等对象的元数据信息，构建了全域全流程的元模型，通过图引擎及可视化工具展示数据血缘，明确异常所在。

 阶段二，异常可便捷修复。

在阶段一的基础上，破壁者组结合历史作业的运行日志及自身的业务元数据信息，通过机器学习算法（主要使用R-GCN，即Relational Graph Convolutional Networks），初步预测出作业异常的原因，并结合领域知识引导解释。用户只要点击大屏中的异常作业，就可以获取异常原因及解决方案的参考说明。

进一步，破壁者组整合了数据云平台DataSimba的各项能力接口，比如数据重跑、任务下线、资源扩充等，从而实现基于准确策略的快速修复，甚至支持批量修复异常作业，提升修复效率。

 阶段三，智能自动化修复，即自动化识别作业异常，智能化完成修复，甚至能基于历史数据和模型分析预测作业异常，采取预防措施，防患于未然。

在有限的赛期内，破壁者组输出了生产级的任务、作业和实例元模型，可直接应用于数据血缘和任务删除的关联影响分析等多个场景中。

“受限于时间及技术成熟度，本次破壁者组未能如愿实现阶段三，但还是给我们展示了清晰的解题思路和完整闭环的成果。”评委、资深算法专家曾博评价道，“从业务场景梳理，到元数据采集的元模型设计和采集方案设计，再到基于采集的元数据信息结合图分析可视化工具进行异常诊断分析，全流程可落地性强，场景价值高，值得鼓励。”

#2 AI加持，为异常诊断提效

基于大模型的数据血缘异常诊断分析

同样聚焦作业异常诊断，荣耀百星组表示，数据血缘链路复杂，往往涉及多个数据源、转换过程和目标，导致故障定位难、具体问题诊断难。完成诊断后，还需要提供解决方案，例如修复受损数据、重新运行失败的节点或修复底层问题等等。

这个听起来“非人哉”的漫长过程，不如交给大模型试试。

“荣耀百星”组再度请出了他们的老伙计——奇点云自有的、离线部署的大语言模型（下文简称“大模型”），基于此搭建了一个作业异常归因分析的小工具。

用户可以便捷地完成数据血缘分析、潜在故障节点识别，并获得相应的建议，为故障排除、问题解决提效。

以一张异常节点table4_5的表为例，荣耀百星组现场演示了作业异常诊断的完整过程：

1. 全链路解析异常表。

该工具支持识别血缘中的作业节点、数据节点，找到故障（的数据）节点；支持识别多类问题，包括字段值为空、字段值期望不符、数据表为空等。

在这个环节，用户得知异常节点上游存在一个数据节点和一个作业节点。

2. 在线分析表结构，判断有影响的SQL。

该工具支持解析血缘中数据的表结构及相关的处理SQL，识别出其中有影响的SQL，并解释来帮助定位问题来源。

在这个环节，用户了解了上游各节点的相关信息。

 3. 针对异常，分析血缘链路，诊断病因。

这是最关键的一步——通过设定好的提示工程，逐步分析数据血缘，帮助用户理解、定位原因。

如下图所示，大模型帮助用户判断出异常节点和数据节点有关，和作业节点无关。

 大模型不是生来就会异常诊断。

组长步方介绍，本次的技术难点在于整个推理过程较为复杂：其一，让大模型理解图结构、数据节点和任务节点的关系，其二，让模型分析出问题节点的根因节点。

因此，针对该场景，有三个技术面必须搞定：特定的提示工程技术；质量较高的数据输入；血缘关系相关的业务知识。

步方透露，关于提示工程，考虑了如何最大限度缩减token量，而不让模型推理性能下降；如何让模型的回答更符合业务人员的表达习惯；如何在异常分析时，给出更全面且富有建设性的答案等。

关于数据来源，元数据的高质量数据对训练模型提供了极大帮助，包括节点溯源、业务表架构、任务节点SQL、日志等信息，都为大模型做最终决策提供了强力的依据。

此外，大模型学习了元数据及血缘分析等语料，具备了一定的业务知识，形成了长期记忆，方才能给出符合用户要求的专业反馈。

荣耀百星组表示，接下来将继续拓展可识别类型（例如数据异常分布、逻辑错误等），也将着手打通表数据及多种数据类型，优化对多节点、多来源血缘链路的能力，让异常定位和分析建议更精准。

“荣耀百星组的成果涉及未发布的部分核心技术，‘过分先进，不便展示’。”评委、奇点云CTO地雷对荣耀百星组给予了高度评价，“使用私有化部署的大模型，解决故障处理和血缘分析问题。从现场演示看，完成度也很高。对其他各组降维打击，直接碾压。”

评委们一致认为，本期难度很大，挑战在于元数据抽象度极高，真正理解元数据并做相关技术创新并不容易。

伴随DataSimba架构升级，以Simba OS（数据云操作系统内核）的6大域及32个对象为基础，上层数据应用与创新变得更加简单，才让几天内完成元数据小项目闭环成为可能。

与此同时，这些应用也在向Simba OS提出挑战：API要足够标准、简洁，能力要足够全面、不重不漏，只有能让开发者心无旁骛开发“APP”的“OS”，才算得上好“OS”。

本期黑客松只是起点，数据云操作系统的进化仍在继续，我们也将邀请更多DT开发者们共同创新，探索数据价值！