导读：本文根据 Fabarta 产品总监陈振在金科创新社公开课整理而来。文章依据 Fabarta 利用自主可控的图引擎和先进的 AI 解析能力构建智能数据血缘治理解决方案的实践经验，分享了数据血缘的定义、演进过程、数据血缘平台的核心能力，以及在应用领域的多样性等内容，全文分为三个主要部分：
- 探讨了数据血缘的本质和意义，及其在数据治理和业务开展中的重要价值。
- 数据血缘的演进以及对数据血缘平台的要求。
- 最后深入讨论了数据血缘在实际应用中的作用，并分享了数据血缘的实际应用场景。
01 什么是数据数据血缘？
数据血缘是什么？实际上，目前对于这个问题并没有一个标准的答案。在国际上，许多权威机构、资深从业者都对数据血缘提出了自己的定义：
- DAMA：数据血缘是指能够同时追踪数据区域内的数据对象，并能展示其之间的处理步骤和派生关系的元数据。
- Gartner：数据血缘是指通过记录和跟踪数据的存在、移动和使用情况来创建数据生命周期视图的过程。它通过数据的入口点、处理、传输、存储和使用之间的关联关系来跟踪数据的流动。
- 信通院：数据血缘是指对数据全生命周期的跟踪，包括数据的产生、获取、处理、存储、传输、共享、汇聚以及清理等各个环节，通过这种跟踪可以判断数据的来源和流向。
当然，不同机构对于数据血缘可能存在细微的差异，因此还有许多其他的数据血缘定义。下面是我个人提取的一些关键词，这些关键词目前是被大家广泛认可的，可以用于描述数据血缘的要求：
首先，数据血缘要能够覆盖数据的整个生命周期。数据最初是从业务端生成的，不同业务过程会产生各种不同类型的数据。从业务端生成后，数据需要经过传输和各种复杂的加工过程。例如，在当下数据还被用于训练或微调大型模型，这也属于数据处理的过程。此外，处理完成的数据可能需要再次传输到其他地方进行存储，并与其他数据相关联。所有这些环节都应纳入数据的完整生命周期，并被血缘关系所描述。
其次，数据血缘应该包含不同类型的关系。无论是 DAMA、Gartner 报告还是信通院的研究，都明确指出数据血缘应涵盖传输、存储、加工和关联等多个关系。然而，当前许多数据血缘平台更加注重加工关系，这种偏重在目前看来较为片面。加工关系仅是数据血缘的一部分，例如从明细表到汇总表的加工关系，虽然属于血缘关系的一部分，但是否能满足全面的数据资产管理、数据编织以及对数据的要求仍值得商榷。事实上，完整的数据血缘应涵盖传输、存储、加工和关联等多个方面，才能真正称之为完备的数据血缘。
02 数据血缘的使用场景
这里再跟大家探讨另外一个问题，为什么我们要关注数据血缘？我们为什么要费力地解析数据血缘关系？个人理解主要有四个方面：
首先，数据血缘有助于理解数据的含义。明细数据和原始数据通常具有更精确的定义。例如，当我们对数据进行加工时，比如产品销售数据的统计表，这个统计表涵盖了各种维度的统计。这时候，我们可能会对销售额的计算方式产生疑问：应收账款是否应该计入销售额？还是只计算实际回款？还是按照国际会计准则来定义销售额？如果我们有一份完善的数据文档，我们可以快速了解销售额的具体定义。然而，总会有一些情况下，我们并不清楚具体数据的含义。这时，我们可以通过追溯数据的血缘，观察原始数据的来源和加工过程，从而准确理解手头数据的含义。
第二，数据血缘可以优化数据的生产方式。数据血缘包含了数据传输和加工的内容。如果能够准确地反映数据的传输和加工方式，就能够揭示一些不合理之处。我们可以通过血缘关系的解析发现一些不合理的数据生产方式，例如发现热点数据、冷数据或循环依赖数据的存在。通过发现这些不合理的数据生产方式，我们就有机会进行优化。
第三，特别是在金融领域，数据质量和合规监管是关注重点。解决数据质量问题和合规性挑战成为痛点。如何及早发现数据质量问题？是否有相关问题可整合处理？能否在最后关头之前解决质量卡点？数据血缘关系在其中起到重要作用。然而，这涉及复杂的内容，包括上游到下游的加工方式、质量卡点的直接关系，以及如何从最后往前推进。技术性问题值得深入讨论。
第四，数据血缘还可以用于验证数据分析的结果。现如今，我们使用数据不仅仅是查看已有的报表，而是通过查询和强大的数据库分析能力，实时生成分析结果。在这个过程中，数据血缘可以帮助验证数据分析的结果。那么，我们如何进行验证和对比，以理解分析结果呢？通常情况下，我们不会仅仅依靠单一的结果来分析业务。举个例子，假设我们关注销售额，我们可能会查看不同品类的销售额。然而，我们可能会发现某个品类的销售额异常高。这时候，我们需要探究为什么该品类的销售额高于其他品类。通过数据血缘关系，我们可以追溯到上游的明细数据，进一步进行分析，这就属于验证数据分析结果的领域。
我将以上问题列出并与大家讨论，旨在梳理我们的思路。我们需要明确数据血缘的应用场景，了解应该解析哪些血缘，并明确对血缘平台和血缘解析的要求。这样，我们就能更清楚地确定我们需要做些什么。
03 常见的大数据平台血缘
数据血缘的类型、复杂度和演进过程究竟是怎样的呢？同时，我们对现代化业务对数据血缘平台的具体要求是什么？让我们来简单总结一下常见的大数据平台的情况。这些平台是目前许多客户生产环境中常用的解决方案，它们通常是建立在单一的数据基础设施上，可能是 Hadoop 平台或其他大型数据库平台。虽然这些平台不涉及跨平台的数据血缘关系，但在平台内部数据血缘关系变得非常复杂。这是因为它涉及到上下游表之间精细的加工关系。如果按照严格的自上而下的维度建模方法构建，血缘关系可能包含多个层次的表，例如明细层、汇总层、应用层和维度表。在这种情况下，加工、聚合和筛选的关系需要严谨地按照维度建模方法处理，使得血缘关系变得复杂而严谨。解析这些关系对于我们来说非常重要，因为它不仅有助于我们理解数据血缘的含义，还可以指导大数据平台的建设。这也是我们目前常见到的数据血缘的现状。那么，刚才提到的这种模式是否符合企业内部的要求呢？从我个人的观察来看，可能越来越多的情况下不再满足要求。我们不仅关注单一数据基础设施内部的情况，还需要考虑到上下游不同数据库之间的关系。举个例子来说，现在我们更加关注数据安全的问题。然而，仅仅在大数据平台内部管理数据安全是不够的。因为一些敏感数据和高安全等级的数据可以直接从业务系统的数据库中获取。因此，在涉及到数据安全分类和分级的场景中，我们必须将整个业务系统的数据库考虑在血缘关系中，通过血缘链路来进行数据分级分类。这就涉及到业务数据库与大数据平台、数据中台或数据湖等单一数据基础设施之间的数据传输。
3.1 全链路血缘：整合上下游不同数据库
再举一个例子，有时候我们需要将数据上报给监管机构，这是一个常见场景。在大多数情况下，这是由一个独立于大数据平台之外的业务系统来完成的。在这个过程中也涉及到数据的传输，因为如果我们的血缘关系要满足监管报送数据的质量要求，那么它必然与监管报送的数据库相关联。这个关联实际上也涉及到跨数据基础设施的传输。因此，我们需要将这种传输考虑在血缘关系之内。这种血缘关系一般被认为是全链路的血缘。从本质上讲，它将上下游不同的数据库都纳入到整个血缘关系中，这也是当前业务上最常要求的一种血缘形态。然而，很遗憾的是，很少有血缘平台能够真正做到这一点。即将各种不同的数据库都考虑在内，并完整解析传输关系。要实现这一点，相信还存在一些技术难题需要克服。
3.2 数据资产图谱：融合逻辑模型和物理模型
另外，仅仅做到这一步也还不足够，构建血缘平台有一个非常重要的目的。首先，我们要去理解数据。在理解数据时，一个关键问题是确定数据在逻辑上的实际意义。目前，大多数数据库中的原始数据所能承载的业务或逻辑含义的信息量是有限的。因此，我们需要通过外部补充来增加数据的实际业务关联性。其中，最直接的方法是利用建模和逻辑模型来补充数据的关联性。然而，由于历史原因，这些逻辑模型往往独立于我们整个原始数据体系之外。在将逻辑模型与我们的数据进行映射时，我们需要思考以下问题：
- 如何确保逻辑关系与数据之间的一致性？这可能听起来有些抽象，但实际上是我们面临的现实问题。
- 目前很多大型企业和金融机构都在建立各种指标体系，有些已经建立多年。这些指标体系是否得到了有效的管理？
- 各个指标的逻辑实体是否与我们的技术上原始数据有良好的关联性？即使建立了关联，我们是否能够将这些关系与数据的血缘关系进行联动呢？
- 例如，我们可能了解某两张表之间的关系，但我们是否了解这两张表背后的指标是否也存在着相同的关联关系？当我们查看这些指标时，是否能够同时考虑到这种血缘关系？这涉及到逻辑模型和我们的技术原始数据之间的映射问题。
另一方面，我们还需要考虑面向数据的运维。这涉及到确定数据存储的位置，例如选择使用哪种数据库，以及数据库的逻辑结构是哪个版本，是否存在某些重叠关系等。整个过程涉及从逻辑模型到物理模型的转换，将其融入到数据血缘关系中，形成数据资产的图谱。然而，仅仅依靠这些还不能构建完整的数据资产图谱，因为数据资产图谱本身是一个广泛而综合的概念。但是逻辑模型、物理模型以及数据技术属性，包括上下游的血缘关系，是构建数据资产图谱不可或缺的一部分。如果我们想要构建数据资产图谱，以便更多的业务人员能够使用我们的数据资产，那么理解企业现有的数据资产，并构建如下图所示的血缘关系图是非常必要的。
3.3 面向数据编织：整合数据应用场景
在不久的将来，仅仅面向数据资产构建血缘关系可能是不够的。因为这种方法只能静态地展示数据在业务上的含义以及数据之间的关联。随着数据编织、数据虚拟化和 AIGC 等技术的日益成熟，数据的表达形式将变得多种多样，不再局限于物理表格。它们可能是 API 服务、AI 模型、或者是与 AI 模型对接的知识服务。这种不同的表达方式是否能够纳入整个数据血缘体系中呢？这可能是一个愿景。举个例子，我们的数据下游汇总表可能以某种形式被应用。这实际上展示了数据业务的一个出口。这又回到了数据编织的概念，即实际数据实体与业务出口之间的关联关系。这实际上是一个编织的概念。虽然这个概念可能有些遥远，目前实际需求也并不是很多。但我相信最终会出现许多这样的需求，即将实际数据应用场景整合到数据血缘关系中。同时，这也对整个学员平台的产品提出了更高的要求。
04 数据血缘的不同类型以及对血缘平台的要求
数仓血缘应该包括加工关系、聚合关系和筛选关系。如果加入传输关系，就演变成全链路血缘了。在全链路血缘的基础上，再增加逻辑模型到物理模型的映射关系，以及数据运维领域的归属关系，就形成了数据资产图谱的一部分。在数据资产图谱血缘之上，再加上一些应用关系，就是面向编织的整合，可以整合到数据应用场景中的血缘。
目前看来，大多数企业的需求已经在快速发展，已经进化到了数据资产图谱的这一部分。实际上，要将一些数据模型和数据实体之间的映射关系纳入血缘关系之中需要考虑。但目前大多数血缘平台的能力可能仍处于数仓血缘和全链路血缘之间。大家正在努力朝着全链路血缘的目标努力。然而，真正能够解析出多元的跨平台血缘关系的平台还是比较少见的。
如上图所示，我们可以看到血缘平台面临一些挑战，尤其是在数仓血缘方面。准确识别数仓中的血缘关系是一项复杂而关键的任务。我们需要深入分析热点数据、冷数据、孤岛数据以及不合理的数据处理，以便在血缘链路中建立清晰的关联。这也是血缘平台面临的重要难题。尽管现今许多血缘平台已具备相关能力，但其实现程度仍存在差异。
要实现全链路的血缘平台，除了现有功能外，还需要增强对异构数据库的兼容性。此外，全链路血缘平台涉及业务系统和实时更新系统。血缘关系可能在实时动态中变化，不再局限于按天或按小时的更新频率。这对血缘平台提出了更高的要求。此外，全链路血缘的展示过程更为复杂，涉及多种数据库类型和血缘关系种类。因此，建立复杂血缘链路的交互界面，以便业务端同学更好地管理和查看，也是一项相当具有挑战性的任务。在进一步发展至数据资产图谱层面时，管理逻辑模型与技术原数据的映射变得更加复杂。这涉及将原始数据转换为图形表示，并利用图数据库等技术进行存储。如何以图化模型的方式存储原始数据和血缘关系，也是一个具有技术难度的问题。在数据编织领域，尤其是非关系型数据载体，如图数据库、向量数据库和大型模型中，如何准确表达数据血缘关系，成为一个全新而值得共同探讨的课题。
05 数据血缘平台的核心能力
5.1 核心能力 1：支持多种数据血缘来源
第一个数据血缘平台的核心能力：支持多种数据血缘来源。血缘关系的来源多种多样。首先，我们需要确定血缘关系的起源。对于多样化的血缘关系，存在多个可能的来源。其中，数据加工的 SQL 端是较为常见且相对容易解析的来源之一。在大数据平台或数据中台内部，通过解析 SQL 语句或利用开源工具，可以提取出数据加工过程中的血缘关系。对于仅关注内部大数据平台或数据中台的血缘关系，这一层可能已经足够满足需求。
然而，若要实现全链路的血缘关系，就不可避免地需要涉及业务系统的关系型数据库。这些数据库内部的血缘关系通常是通过存储过程实现的，尤其是传统的数据仓库技术。因此，存储过程是不可忽视的血缘关系来源之一。尽管存储过程的使用可能减少，并且有专家不建议过度依赖存储过程，但考虑到业务的实际需求，我们无法回避存储过程的存在，因为它在业务中广泛使用。因此，存储过程也必须纳入血缘关系的来源之一。其次，我们还需关注数据库之间的数据传输，其中 ETL 基础设施至关重要。特别是对于具有强实时性要求的业务，涉及大量流式数据的数据管道也是血缘关系的重要来源。因此，周期性的 ETL 数据传输和实时流式数据管道的加工都应包含在血缘关系的范畴内。此外，如果我们对血缘关系有更高的要求，希望将业务逻辑和后端的数据分析应用纳入血缘关系图中，这些关联关系可能不是通过显式的 SQL、存储过程或 ETL 脚本来定义的。它们可能需要通过分析日志或其他手段来挖掘隐含的数据关系。这部分也是非常重要的。综上所述，以上是根据获取血缘关系的难易程度进行的分类。实际上，大多数数据血缘平台可能只能涵盖其中的一部分。然而，我们应明确，要完整地展现数据血缘，这四个方面都是必须包含的。只有这样，我们才能实现一个完备的数据血缘平台，满足我们的期望。这也是对数据血缘平台核心能力的要求。
5.2 核心能力 2：实时且自动化的血缘更新方式
第二个核心能力：实时且自动化的血缘更新方式。前面已经提到，全链路血缘关系的变化非常迅速，因此采用适当的血缘更新方式至关重要。手动维护是一种必备的能力，虽然它可能很困难，但它是准确性最高且实现成本最低的方式。由于无法保证数据解析的百分之百准确和完整，手动维护作为一种兜底手段是必要的。手动维护的信息准确性最高，每一项的录入都由人负责，但更新速度相对较慢，成本较高。另一种常用的血缘解析方式是上传血缘文件，这是一种高效的批量更新血缘关系的方式。它基于血缘数据的载体通常是 SQL 脚本或存储过程，将它们写入文件中，然后上传该文件以高效地更新血缘关系。这种方式同样具有比较高的准确性，因为它不需要过于复杂的技术，只需通过语法解析即可提取血缘文件中的血缘关系。它的效率也很高，因为一个文件可以容纳大量的血缘关系，并且可以一次性上传多个文件进行批量操作。然而，它仍然存在一个问题，即它不是自动触发的过程，仍然需要人工干预。由于它是程序化解析的过程，无法保证百分之百的准确性，仍然需要人工辅助。第三种常见的方式是定时自动采集，这种方式相对容易实现，并没有太多的技术难度，主要是工程上的处理。它需要兼容不同血缘文件格式和来源，并处理异常情况。由于是自动化采集，更新过程必然涉及版本管理，包括新增、消失和修改血缘关系。由于都是自动化处理，需要保留自动化处理的记录，并具备版本更新的机制。这需要在工程上进行良好的处理，才能成为一个合格的定时自动血缘采集系统。第四种方式血缘变化自动推送，目前在云环境中被广泛采用。它能够同时控制底层数据库技术和上层血缘平台技术，实现实时的自动血缘更新和推送。一旦血缘发生变化，不是由血缘平台主动抓取，而是由数据库或数据平台主动推送给血缘平台。这种方式的技术难度最高，但可以实现实时更新，并且准确性最高。因为它是由底层平台推送的，已经对原始脚本进行了加工处理，或者从技术角度来说，是由执行计划产生的血缘，因此准确性较高。然而，它对数据库有一定的侵入性。在实际操作中，常见的血缘更新方式通常是将这四种方法结合使用。对于处理技术较为先进的底层数据平台，可以采用血缘变化自动推送的方式。一些开源大数据平台或自研大数据平台的云平台厂商已经具备了自动推送血缘变化的能力。此外，手动上传文件的方式或者定时采集的方法也可以用来补充，以确保血缘关系的及时获取。当存在不确定性时，常常采用手动维护的方式进行补充。以上是四种常见的血缘更新方式。
5.3 核心能力 3：丰富的血缘地图交互方式
第三个核心能力是具备丰富的血缘地图交互方式。虽然早期的数据质量软件可能已经具备了血缘的基本功能，但它们更多地只提供简单的关系图展示。这是因为在过去，血缘关系相对较简单，主要涉及节点类型和关系类型。从拓扑图的角度来看，节点和边是其主要组成部分，而节点类型和边类型相对一致，使得整个血缘关系图比较简单。因此，过去的需求更多地集中在简单呈现链路图上，而对于深度分析或查看元素信息的需求相对较少。然而，现在的血缘关系更加复杂且具有广泛的应用。血缘地图不仅包含丰富的内容，还涉及到多种用途。因此，对于血缘地图的交互方式提出了新的要求，以下是七个关键点：
- 针对表、字段等实体的搜索：随着数据量的增加和关系复杂性的提高，强大的搜索能力是至关重要的。搜索能力不仅限于精确匹配实体名称，还需要支持模糊搜索或基于 AI 语义层的高级搜索，同时适用于表字段等其他实体。
- 链路层级的控制：随着链路层级的复杂性增加，对链路层级的控制变得必不可少。用户需要获得友好的体验。否则，用户在使用血缘平台时可能会面临搜索结果过多或未找到所需信息的问题。这往往是由于对层级控制不足造成的。
- 数据库、数仓层级、数据表、字段等多层次对象的嵌套显示：嵌套关系在血缘地图中扮演着重要角色，特别是涉及各种存储和嵌套关系的情况。交互方式应准确展示这些关系，使用户能够清晰理解血缘地图中各个元素之间的联系。
- 复杂血缘关系的下钻、聚焦：为了更好地查看血缘关系的实质信息，交互方式应提供高亮显示、聚焦和下钻功能。这样用户能够方便地查看和分析血缘关系的详细内容。
- 兼容多类型数据库/数据应用的集中展示：由于血缘图涉及多种类型的数据，全链路血缘分析需要兼容多种数据库。交互方式应清晰地展示更详细的数据信息，包括深入到业务系统和监管层的数据。
- 相关详细元数据信息的高效查询
- 详细血缘信息的导出，便于二次加工：为了满足更高级的二次分析需求，交互方式应支持血缘关系的导出，以便用户能够更方便地进行分析。
5.4 核心能力 4：智能建立逻辑模型与技术元数据映射
第四个核心能力是智能建立逻辑模型与技术元数据的映射。这涉及到逻辑模型的建立方式。在企业中，如果已经存在设计好的模型文件，血缘平台必须支持导入这些设计，以避免浪费过去的设计成果，并与在线的数据建模平台集成。许多语音和数据建模平台供应商都提供在线化的解决方案，例如风行科技的在线血缘平台和数据建模平台，可以集成到在线数据建模平台中。
然而，如果缺乏相关数据，我们可以考虑使用大型模型的技术。尽管各家都在尝试，但目前尚未达到具备生产能力的阶段。另一种方法是通过 AI 模型智能解析数据设计文档，因为过去的设计过程可能没有严谨地记录在设计文件中，部分原因是建模工具通常价格昂贵。然而，许多数据工程师和专家具备使用设计文档构建完整数据体系的能力。但是，从设计文档中提取逻辑模型仍然是一个新的课题。这可以通过 AI 模型的方式进行提取。在提取完成后，我们还需要将逻辑模型与技术元数据进行映射，这也是一个新的挑战。当然，如果设计文件本身包含了一些物化结果，或在线建模平台具有模糊关系，那么映射会更加自然。然而，如果这两种情况都不适用，是否可以通过 AI 的方式推断逻辑模型和技术元数据之间的映射关系？这种推断可能不会百分之百准确，但至少可以作为一种补充方法。需要强调的是，并非所有逻辑模型都会转化为物理表，也不是所有物理表都是由逻辑模型衍生而来的，这是正常的现象。因此，追求逻辑和物理之间的完美映射并非必须。然而，对于血缘平台来说，逻辑模型与技术元数据的映射仍然是一个核心要求，只有实现了这种映射，才能实现前面提到的数据资产图谱的完整性。
5.5 核心能力 5：高性能的血缘关系查询分析方式
第 5 个核心能力：关于高性能的血缘关系查询分析方式。实际上，高性能的血缘关系查询和分析方式应该优先考虑，因为血缘关系变得越来越复杂，查询和展示的技术难度也随之增加。尽管目前对血缘查询和分析的要求并不高，我们可能会使用一些巧妙而迂回的方法。例如，在查询各种血缘关系时，我们一次只能查询其中的一部分，而无法完整展示全部的血缘关系。有时候，我们还需要进行手工操作，例如展开血缘地图，以获取更完整的信息。然而，这主要是因为后台数据查询和分析的能力受到限制，特别是在处理复杂多层次的血缘关系数据结构时。因此，我们需要建立一套高效的查询和分析方式，以支持复杂关联关系的查询，并进行深入的血缘关系分析。
06 几个数据血缘的实际应用场景
6.1 孤岛数据清理
孤岛数据处理是血缘关系分析的一个常见应用场景。当一个数据没有上游或下游的血缘关系，或者上下游的血缘关系都不存在时，我们可以将其识别为孤岛数据，并进行清理。清理孤岛数据有两个目的：一是避免不必要的存储和计算开销，二是防止错误数据的使用。如果孤岛数据一直存在而被错误使用，将带来潜在的问题。
通过血缘关系分析，我们可以发现这些孤岛数据。一种典型的血缘关系应用是针对单表的入度和出度为零或极少的情况，将其判定为孤岛数据。这可以帮助我们识别孤岛数据的存在。另外，对于非单表数据，可以通过血缘关系的加工和分析来聚类数据，并发现某些数据与其他数据的关系非常有限或根本不存在，从而将其判定为孤岛数据。发现孤岛数据的过程中，我们也可以了解到一些导致孤岛数据产生的常见情况。首先是数据冗余，即复制了一份数据，但实际上只有原始数据或复制数据被广泛使用。这种情况下，复制的数据就成为了孤岛数据。其次是临时数据，它在产生的时刻可能有用，但只是一次性使用，之后就没有更多的用途了，这样的数据也会变成孤岛数据。另一种情况是历史数据与新版本数据存在差异，两者没有统一起来，导致历史数据成为孤岛数据的可能性增加。还有一种可能是血缘关系缺失，形成了一种假孤岛情况。对于不同可能性的孤岛数据，我们可以采取各种策略进行进一步处理。例如，如果只有上游血缘关系而没有下游血缘关系，那可能是冗余数据，确认后可以将其删除。如果只有下游血缘关系而没有上游血缘关系，很可能是历史数据，可以考虑优化表结构并与新版本数据进行合并存储。如果既没有上游血缘关系也没有下游血缘关系，那可能是临时表，可以进行清理操作。以上基于血缘信息识别孤岛数据，并根据不同情况采取不同策略的方法，是一种实际应用的方式。
6.2 关键数据保障
关键数据是指在数据流中被下游广泛使用的数据。对于这些关键数据，我们需要确保其可靠性和时效性。此外，如果某个数据变得异常热门，我们需要警惕其中是否存在不合理的数据加工链路。理论上来说，由于数据平台或大数据平台的存在，不应该出现某个数据特别热门的情况，而应将其总结为更通用的公共层指标。如果出现了特别热门的数据，我们必须警惕其中是否存在不合理因素。下面是一些常见的热点数据类型：
- 核心业务的明细表：这些表通常是非常热门的，因为它们包含了核心业务的详细数据。
- 重要的维度表：这些表不断被关联和使用，因此也是热门的。为了简化对物理表的管理，可能会创建被多次复用的汇总表。
- 重度复用的汇总表：为了简化管理，一些指标被放置在同一个汇总表中，即使它们在业务上并没有太多的关联。从技术角度来看，这种做法可能是合理的，但从血缘关系的角度来看，会导致出现特别热门的汇总表。长期来看，这种做法是不建议的，因为后续的维护成本会很高，数据管理、数据治理和数据质量监控都会变得非常困难。
为了发现这种重度复用的汇总表，可以从热点数据的血缘关系中进行观察。对于不同类型的热点数据，可以采取不同的处理方式。例如，对于重要的维度表，我们应重点保障其稳定性，并可能优化存储方式以提高访问性能。对于热门的明细表，可以考虑提取公共指标，以简化数据加工复杂度，并让其频繁被读取。如果无法提取公共指标，仍需重点保障其稳定性。如果存在重度复用的汇率总表，可以考虑按照不同的指标或业务维度进行拆分，并进行分表存储。这样做可以简化其他方面的数据治理复杂度。如果所有指标都存在于同一张汇总表中，那么数据质量的监控会面临困难。同样，数据安全的分类和分级也会变得复杂。因此，尽可能进行分表存储是明智的选择。
6.3 发现数据循环依赖
此外，第三个场景涉及到循环依赖，这是一个相对复杂的应用情景。也许你会疑惑，为什么会存在数据之间的循环依赖关系？尽管这看起来十分奇怪，但实际上确实存在这种情况。在我看来，这种情况可以归结为两种情形。首先是合理的逻辑循环依赖，即数据在不同时间周期内相互依赖。举个例子，某个指标的值在新的一天依赖于前一天对应指标的值。这种情况下，数据自身与自身形成了依赖关系，或者说形成了数据依赖的循环，这是合理的。然而，也存在一些意外情况。例如，某些数据开发人员在开发详细表时，可能需要使用一些复杂的指标，并且应该直接使用业务系统中的数据来源。然而，由于某种原因，这位同事可能采取了一种不合理的方式，直接从汇总层的表中获取数据。这样就直接形成了一个闭环。我们可以通过血缘关系图中的图匹配模式来检测出这种循环。一旦发现，如果是正常的持续依赖，则属于正常的业务需求。然而，如果是持续的循环依赖，很可能是前面提到的第二种情况。在这种情况下，需要采取相应的纠正措施。
6.4 数据质量：问题溯源、影响分析和卡点前推
还存在一个关键的场景，即我们需要追溯数据质量问题的根源。当我们发现数据质量问题时，我们需要准确确定其对业务产生的影响。这个过程不仅仅涉及表与表、字段与字段之间的关系，更加关乎业务规则和数据质量问题之间的紧密关联。通过建立这种关联，我们能够清楚地了解质量问题的影响范围，以及它违反了哪些监管要求。一旦数据被提交后，我们也能够预见到可能引发的严重后果。此外，在实际应用中，数据质量问题可能会向上游延伸，影响到其他表。因此，如果我们发现下游表存在数据质量问题，而上游并没有触发相应的数据质量警报，这表明我们的监控点设置可能不够精确。在这种情况下，人工干预是不可或缺的，因为血缘关系可能涉及一系列复杂的数据加工操作。因此，我们需要探索如何将后续的质量规则转化为更早的明细层质量规则，并将监控点前移，这是一项值得深入研究的问题。
07 Fabarta ArcFabric 多模态数据编织平台
大模型技术的应用，需要打通企业海量私有数据，而当前企业数据类型多、数量大、质量杂，如何将“私有数据”梳理为 AI 可用？这对数据管理提出了全新挑战：
- 数据形态升级：从专注于核心经营报表，到全面覆盖原始的 Raw data，如 CRM 数据、ERP 数据、产品手册、规章制度、图片、视频文件等，不只是从结构化数据到非结构化数据的升级，更需要全新的数据连接、抓取的技术方式，也需要更普适的元数据管理方式；
- 治理目标升级：治理的目标，从数据的“DAMA 六性”（Completeness 完整性、Uniqueness 唯一性、Timeliness 时效性、Validity 有效性、Accuracy 精确性、Consistency 一致性），升级为对语义的理解和对隐含关系的提取；
- 数据服务升级：数据治理的服务对象，从 BI 升级为 AI 进而演化为大模型，因此数据服务的形态，也从传统的二维表，升级为适配于大模型生态的知识服务。
FabartaArcFabric 多模态数据编织平台，是面向 AI 的数据管理平台，更加智能的连接、理解、治理数据，将企业数据转化为企业知识，为 AI 的应用落地提供数据驱动力，同时也兼容传统的数据治理场景。平台基于 ArcNeural 智能引擎，连接企业私有数据，自动获取并分析其中的元数据和数据语义，形成数据血缘和资产图谱，在此基础上提供智能化数据标准贯标、数据质量分析、指标链路优化、数据分类编目等功能，为业务应用和大模型提供数据服务。其核心模块包含：
- 图增强数据治理：采集并识别包括结构化数据库、文档、图片在内的多模数据的元数据信息，通过数据处理脚本、系统访问日志等原始技术信息解析数据血缘，全方位管控数据标准、数据质量、数据安全，并可兼容对接企业已有数据治理平台；
- 智能数据资产盘点：利用准确的元数据、血缘等信息，对海量企业数据进行筛选和分类，并通过智能化技术的辅助，对数据内容进行理解，提取隐含的数据关系，还原真实的数据模型（Data Model）；
- 多模态数据服务：通过指标建模、数据虚拟化、知识服务等技术，同时适配传统 BI、AI 和大模型场景，提供全面的数据服务，也可对接 Fabarta 企业智能服务平台，快速落地 AI 应用。
Fabarta ArcFabric 多模态数据编织平台架构图FabartaArcFabric 多模态数据编织平台作为 Fabarta 产品矩阵中的“数据翼”，充分利用大模型能力，实现智能数据管理，对接企业已有的大数据平台，梳理和治理企业海量多模态数据，构建数据资产地图，并为 AI 大模型落地提供智能数据基础，提供 AI 落地就绪的数据（Data Reay for AI）。
08 问答
Q1：请问如果没办法做全周期的血缘，那在大数据平台或数仓优先做哪个流程的血缘关系比较好？
A：根据我初步的理解，大数据平台涉及多个流程，包括数据清洗、指标加工和数据集市中的报表层加工等。在这些流程中，公共层的血缘关系应该是优先考虑的，因为它具有较高的投入产出比。然而，公共层的理解在不同机构可能存在差异。具体而言，涉及到核心指标加工的公共层血缘关系是非常重要的，因为它们具有最高的核心价值。此外，整个指标体系的设计在各个行业中都非常严谨，旨在为业务需求提供支持。因此，公共层指标血缘关系的梳理可能会相对较容易。综上所述，优先考虑梳理公共层指标的血缘关系，具体而言，可以从 DWD 到 DWS 层级进行血缘关系的梳理。尽管这只涉及到整个血缘关系的一小部分，但在投入产出方面具有较高的效益。以上这是我个人的观点。
Q2：手工处理血缘关系该怎么做，是不是很难？
A：实际上，完全避免手工操作是不可能的。尽管手工操作成本较高且更新困难，但它确实能提供相对较高的准确性。然而，在血缘关系越来越复杂且涉及的数据开发者越来越多的情况下，完全依赖手工操作是不现实的，因为成本太高。因此，我们需要采用一些智能化的方法来进行血缘关系的解析。
Q3：建立逻辑模型与技术原数据映射关系的比例，应该怎么把握？
A：这个比例实际上是由业务需求驱动的。映射比例并不应成为一个特别关注的指标。我们应更加关注的是，在当前阶段，将这项工作作为一个分阶段的项目完成。我们应该优先考虑为哪个内部业务提供服务，哪个业务部门对我们的能力需求最高。我们需要问自己，我们能否为其提供良好的服务，以及我们是否具备可利用的资源，如设计文件和数据设计文档供我们的 AI 模型解析。在这些基础上，我们再来讨论映射比例。我们应以优先满足业务需求为原则，而不是过于关注映射比例。过于关注映射比例可能会设定过高的要求，但实际上可能无法实现良好的性价比效果。
Q4：目前监管报送数据不同报送任务可能使用相同指标，但不同系统的指标计算逻辑可能不统一，且多个系统重复计算的实际问题，你们产品有在这个场景下的应用案例吗？怎么能更好的结合？
A：这个问题非常常见，业务部门或监管部门更关注指标本身，对指标加工的链路并不太关心，他们认为这是数据部门需要解决的问题。然而，由于历史原因，不同的指标可能由不同的人开发，他们可能没有完全了解上下文，导致可能出现重复开发或部分重复开发的情况。举个例子，如果已经存在一个在中间层进行派生加工的指标，但在进一步加工复合指标时，仍然从明细层开始加工，虽然这种方式也可行，但并非最优路径。我推测，这位听众可能关心的是指标的重复加工问题，即指标可能重复加工，甚至可能具有相同的名称，但实际的计算逻辑可能不统一，或者某些指标可能完全重复。然而，它们的前置链路可能是不同的。我们正在探索这个问题，并在一些实际案例中进行尝试。基本思路是基于血缘关系进行分析，因为每个指标背后都存在一个加工链路，形成一个链路图。通过一些图计算的方法，能够计算出两个指标背后链路图的重叠程度。这其中涉及到的计算方法相对复杂，包括图分析和最新的 AI 技术。然而，我们确实能够定量地计算出两个指标背后血缘关系图的重叠程度。计算得到定量的重叠程度后，可以进行排序，针对重叠程度较高的指标，让真正了解业务或涉及相关数据开发的人员进行审查，以确定是否存在优化的空间。这是我们目前解决问题的思路。然而，要完全避免这个问题还不太现实。尽管如此，我们可以从血缘的角度提供更有用的信息，帮助大家避免该问题，并解决历史上存在的一些遗留问题。
分享嘉宾
陈振（渥龙）
Fabarta 产品总监
长期从事大数据与 AI 产品管理工作，曾负责构建阿里云 DataWorks 与 PAI 产品的商业化，深度支持过金融、政务、能源等领域客户的大数据及 AI 平台建设。
推荐阅读