主动数据沿袭是AI原生亟需的数据管理策略

让我们将数据可视化，就像水在摩天大楼的管道中流动一样。乍一看，它的流动轨迹很有规律：从源头向上流动，然后通过水龙头流出。但建筑物在不断发展 ， 固定装置不断变化 ， 用途也不断改变。随着时间的推移，最意想不到的角落也会出现泄漏。

到处都是水，但没有一滴可以喝。

现在，想想 水龙头 不再只是简单的固定装置。它们是15楼咖啡馆里的浓缩 咖啡机，停车场里的消防喷头，顶层公寓里的恒温淋浴间。这些 就像数据产品：专为特定用例设计的、情境感知的专业输出。销售预测仪表板、客户细分模型、风险评分API。每一个都是为服务于一个用户、一个工作流程和一个决策而构建的。

但 终 端 越定制化，它对流入的数据就越敏感。上游的一个细微变化，例如重命名列、删除字段或延迟同步，都可能对下游造成严重破坏。现在，浓缩咖啡的味道变了。洒水器在关键时刻失灵了。淋浴是冷的。没有人知道原因。

这就是血缘发挥作用的地方。它不仅能追踪水管和水流，还能理解其后果。它是一份架构蓝图，可以让你追踪每根管道、每个阀门、每一次转换。当发生泄漏（或者更糟的是，产品损坏）时， 血缘 不仅能帮你找到故障，还能帮助你重建信任。

除了可观察性，你还需要问责制。而现代数据沿袭技术可以同时满足这两点。

为什么数据沿袭是一项颇具影响力的业务策略，却很少被提及

询问任何数据领导者是什么让他们夜不能寐，答案听起来都很熟悉：对数据的信任、质量问题、持续的救火、董事会会议前仪表板不知何故损坏、延迟的洞察力以及团队不说同一种语言。

但深入挖掘这些层层细节，你会发现其中隐藏着一个共同点： 缺乏对数据实际流动、演变及其对业务影响的可见性 。

这就是 血缘 。

不是工具，不是漂亮的图表，而是 理解数据生命周期的底层能力，将其视为一种活生生的资产：数据战略的盟友。

不幸 的是，对于如此基础的东西， 血缘 却常常被当作事后诸葛亮。就像平台幻灯片上的复选框，或是元数据功能下的脚注。在战略演示文稿或路线图评审中，它几乎从未被提及。

但从总体来看，血缘并非可有可无。至少现在不再如此。它是一种战略推动力。没有 血缘 ，

如果您不知道数据来自哪里，您如何确保数据质量？

如果你不知道它会影响谁，你怎么能改变定义呢？

如果没有人了解事物之间的联系，您如何扩大团队规模？

血缘 是信任、治理、协作和速度的交汇点。它是数据组织的神经系统。与任何神经系统一样，它只有在出现麻木或疼痛时才会受到重视。

我们不再等待症状出现。主动血缘管理策略应运而生。但要理解主动 血缘 策略，我们先来探讨一下传统 血缘 策略的缺陷。

为什么传统（被动）血缘在现代数据架构中不再适用

在您的数据旅程中，您很可能在某个时刻打开过谱系图，结果却感到困惑多于顿悟。这并非您的错，也不是任何用户的错。

这就是大多数传统架构中令人遗憾的 血缘 真相。它只 展示了变化的内容，却没有揭示变化的原因。它揭示了一次又一次的变 迁 ，却隐藏了意图。你看到的是数据流，而不是其背后的故事。

过去， 血缘 被视为一种技术痕迹，就像生产环境中运行的流水线和作业的副产品一样。在更简单的时代，这或许就足够了。当流水线更少、团队规模更小，一个 BI 仪表板就能解答大部分业务问题时，流水线优先的 血缘 就显得合情合理了。

但数据世界已经迅速改变。

如今，现代数据格局是一个充满活力、多团队、多工具的生态系统，其中瞬息万变，利益相关者涵盖从后端工程师到董事会高管的方方面面。静态沿袭快照（通常在持续集成 (CI) 运行期间生成或从元数据目录中抓取）无法跟上数据的变化。它们或许能够捕捉数据跨层的移动，但却很少能够提供上下文来解释这些移动最初存在的 原因。

更糟糕的是，这些流程的所有权是分散的。一个团队负责构建数据采集，另一个团队负责管理转换，第三个团队负责报告，而在中间的某个地方，有人更改了模型定义，而没有通知下游用户。

因此，血缘看起来就像伪装成秩序的数据混乱。

血缘 确实存在。但它是盲目的。它无法理解含义。它无法表述意图。它无法告诉你，当事情发生时该给谁打电话。

但我们正快速迈向AI原生系统、快速实验和可组合数据架构。在这种环境下，什么样的数据沿袭策略才有效？

进化：数据产品和人工智能原生系统时代的变化

数据产品引入了一个基本枢轴。

在传统的集中式设置中， 血缘 是流水线的产物：DAG、脚本和 ETL作业的副 产品 ，通过隐式逻辑拼接在一起。它通常被埋藏在版本控制中，或者通过追踪上游损坏的报告在事后重建。

但当你开始将数据组织成产品时，这些产品就是有意识的、模块化的、可追溯的单元——谱系不再是偶然的，而是经过设计的。每个产品都成为一种边界，而每个边界都定义了一种契约。

突然之间， 血缘 不再是穿过仓库的追逐，而是一系列光线充足、相连的房间。

让我们了解数据沿袭如何通过跨用例特定数据产品的垂直耦合变得更具可操作性和主动性。

当 血缘 范围从意大利面条式管道（集中式系统）转变为垂直产品（混合式系统）时会发生什么？

1.明确的所有权和接口

在数据产品出现之前，血缘 视图通常一团糟。管道像意大利面条一样杂乱无章，无人维护，所有人所有，却很少有人理解。当出现问题时，你最好的希望就是已有知识和 Slack 考古。领域之间没有明确的界限，没有合同，当然也没有问责制。

这不仅仅是技术债务问题，这是一个可见性问题，也是一个信任问题。

有了数据产品，数据堆栈的每个单元都被重新构想为一个模块化数据产品，拥有明确的输入/输出接口和明确的所有者。它不再仅仅是“表格之间互相补充”，而是：

通过合同端口流动的数据

所有权映射到数据产品经理、分析工程师和领域团队

接口形式化，因此可以像代码一样对 血缘 进行分段、查询和管理

观察图表中的沿袭视图：您不再从损坏的仪表板追溯到随机 SQL 作业。

您正在从业务用例 → 通过数据产品 → 跟踪范围明确的逻辑、数据和基础模块，每个步骤都带有上下文和保管权。

这种清晰度将谱系从调试工具转变为合规性、扩展团队和在整个组织内建立数据信任的运营资产。

2.元数据丰富且有据可查

在数据产品出现之前，血缘 工具可以显示数据的来源，但无法解释其重要性。当然，你可以追溯到table_x …… job_y.sql，但你只能猜测： 这是什么用途？谁拥有它？如果我更改它会怎 样？它还在使用吗？

元数据孤立存在（或者更糟的是，存在于某些人的头脑中）。业务含义与流程机制脱节。这导致审计工作变得脆弱，用户引导缓慢，上下文信息获取成本高昂。

使用数据产品后，现在放大图表：每个数据产品都嵌入了上下文绑定的元数据，与数据和逻辑一起流动，不是事后才想到的，而是作为一等公民。

每个数据产品都是：

描述（明确阐述目的和 血缘 ）

Schema'd（字段已记录、版本化并经过测试）

拥有（由专人负责 SLA、质量和影响）

用例（与明确的业务领域和分析意图相关）

这将 血缘 从低级资产转变为业务可读的地图。

你看到的不仅仅是“数据从 A 流向 B”。你还会看到：“ 客户细分（v2.1）丰富了来自 Customer 360 的 LTV 估算，每小时更新一次，由增长分析团队负责 ”

元数据不再仅仅是结构性的，它更是一种叙事。它讲述了数据 流动 的故事：它为什么存在，它服务于谁，以及什么依赖于它。

这就是转变：从列级沿袭到上下文级沿袭。一个对人类清晰易读、设计可审计、并与团队构建、监控和信任其数据的方式深度集成的系统。

3.更好的模块化=更清晰的血缘

数据产品之前，一条管道的变更往往会影响其他五条管道。逻辑、数据、基础设施都杂乱无章，并在管道之间泄漏，这些都被用胶带封存的 SQL 脚本捆绑在一起。

谱系工具可以绘制这些网络，但得到的却是噪音：

数十个连接，数百个表，没有清晰的层次结构。

很难说清哪些转变很重要，哪些只是技术粘合剂。

没有“产品级”关系的概念——只是按比例进行列重组。

使用数据产品后，进入模块化时代，以目的为导向。在图中，你会注意到架构是如何分层的：

源数据通过上下文绑定逻辑（而非共享逻辑堆）进行转换。

该逻辑融入范围明确的数据产品中，每个数据产品都与一个业务用例相关。

基础设施根据用例进行模块化，而不是集中式和脆弱的。

这使得可组合的谱系图成为可能，其中每个单元都有意义且可重复使用。

现在，您不再需要追踪“job_x 写入 table_y”，而是需要追踪：“营销漏斗”产品 → “广告支出归因” → “广告系列投资回报率报告”

就可能性而言，模块化可以显著提升投资回报率 (ROI) 计算的精细度。每个用例都能将支出归因于数据产品、管道以及深层基础设施资源。

模块化也支持重复使用。相同的“客户细分”逻辑既可以用于 CRM 优化，也可以用于营销活动定位。每个产品都有 明确的界限 。

4.影响分析更容易

数据产品之前，调整 LTV 逻辑？你得准备好接收来自四个不同团队的 Slack 警报。沿袭工具提供了 技术线索 ，但都停留在 SQL 步骤或 dbt 模型上。你能看到哪些地方 可能 出现问题，但看不到哪些地方 真正重要 。没有明确的提问方式：

“如果我重新定义客户细分，哪些指标和仪表板会面临风险？”

使用数据产品后，现在，变革的单位是数据产品，而不仅仅是表格或模型。每个产品都是模块化的、范围明确的，最重要的是，具有上下文关联性。

如图所示：

注意每个转换如何流经 垂直 产品层：受目的和所有权的约束。

“上下文绑定数据”连接到“上下文绑定基础设施”和“上下文绑定逻辑”，因此可以在整个堆栈中追踪更改。

明确的输出（右上角）告诉您 谁在哪里消费了什么 。

所以现在，当我们提出“如果我们调整生命周期价值的计算方式……”时，您将获得一个沿袭视图，它不仅显示 技术依赖关系 ，还显示 业务影响 。“客户 360”和“细分健康报告”等下游产品会被标记。依赖这些输出的仪表板和利益相关者可见。您可以将影响分析作为 对话 进行。

编辑 dbt 模型时无需再费力猜测。影响范围已限定在产品级别，并已嵌入元数据、所有者和服务等级协议 (SLA)。这就是面向产品的血缘的强大之处：

除了 数据流 ，您还可以了解业务连锁反应。

5.跨团队可见性

数据产品之前，血缘 传承各自为政。分析工程师有他们的 dbt 文档。数据工程师有 Airflow 图表。业务团队呢？一份 Notion 文档，还有希望。

然后，不同领域之间就出现了争执。咨询团队不理解那些能够带来潜在客户的营销语义（机会流失：交付与预期匹配），营销团队不理解销售人员如何与其数据互动（机会流失：转化率TAT降低）。

每个团队都使用着自己的传承方言。当某些东西损坏或需要重新使用时，没有人掌握 完整的传承地图 。传承不会跨越领域，而是止于团队边界。

使用数据产品，进入上下文绑定的血缘。设计上与团队无关，默认可见。如图所示：

每一层（数据、逻辑、基础设施）都围绕业务用例 模块化，而不仅仅是技术堆栈。

产品可跨角色发现：数据科学家可以看到其模型的数据来源。数据工程师可以看到基础设施和逻辑是如何被复用的。分析师可以看到洞察的来源和所有者。

上下文垂直流动（用户 → 逻辑 → 源），水平流动（跨产品和团队）。这超越了 血缘 ：这是一种协作架构。

打破孤岛循环的方法如下：

它不是“我的管道”和“您的仪表板”，而是“我们的产品”。

具有共享所有权、共享元数据和共享谱系背景。

因此，现在，当市场营销部门需要“客户细分”，财务部门希望重复使用“生命周期价值定义”，而工程部门需要扩展基础设施以支持这两者时，他们都会看到相同的产品谱系，并丰富了业务上下文。正因如此，这种数据谱系策略不仅跨职能，而且与业务上下文保持一致。

成为人工智能原生代：为什么数据沿袭是战略基础设施

AI 原生是指以 AI 作为基础能力 而非事后诸葛亮而构建的组织、系统或架构。在AI 原生公司中，机器学习模型、 大语言模型 (LLM) 和智能代理 深深嵌入到核心工作流程 、产品和决策中。

在这样的组织中，数据不再以原始形式被消费。AI 模型会从数十个来源提取精细的信号、业务定义的指标和复合特征。预测客户流失的模型并非读取“user_id”，而是解析“主动参与度得分”、“上次接触归因”或“风险等级”等层层含义。

这使得 血缘 问题变得更加严重和复杂。

当流程在没有明确沿袭的情况下改变“活跃用户”的定义时，其成本就不仅仅是技术债务了。它还包括糟糕的模型性能、难以解释的决策、合规风险以及信任的丧失。这里的沿袭服务于以下战略目的：

特征来源：准确了解哪些上游变化影响了模型行为

根本原因诊断：准确找出关键绩效指标 (KPI) 或模型突然偏离的原因，无需追踪虚假错误

监管分辨：在任何时间点证明每个自动化决策的内容。

语义对齐：确保下游模型和仪表板在含义上对齐，而不仅仅是结构

在人工智能原生栈中， 血缘 是记录智能如何创建、共享和信任的系统。机器学习的好坏取决于你输入的数据。人工智能的好坏取决于你输入的智能。

本文来自微信公众号“数据驱动智能”（ID：Data_0101），作者：晓晓，36氪经授权发布。