首先，这在很大程度上取决于用户组织当前的使用案例及其成熟度。

在我看来，数据工程师喜欢查看数据流并对依赖关系有直观的了解，但他们最终真的会使用数据沿袭吗？使用频率是多少？具体用例是什么？

从我们的观察来看，数据沿袭确实引起了人们的兴趣。然而，在实际使用中，它并不是核心功能。这可能是因为我们的实现仅限于某些数据源。然而，将沿袭限制在某些管道上对我来说似乎也不太有意义（即 dbt 或Dataform中的沿袭），因为提取和其他过程被忽略了。一个典型的用例可能是组织中的某个人每周大约两次花几分钟搜索特定的管道或模型。

数据沿袭的常见用途

我们看到的最常见的血统用例是：

• 该公司正在迁移或重建其数据平台。
• 该组织正在招募新的队友，通常是为了新的数据计划。

在这些时候，血统就变得非常有用。基本上，当公司开始不仅维护其数据仓库或数据湖中的内容，而且实际构建和现代化数据生态系统时，血统就变得非常有用。

这是否意味着在这种情况下必须有血统？绝对不是。但如果你想更快更聪明地行动，那么答案绝对是肯定的。

需要考虑的问题

因此，这很大程度上取决于组织当前正在做什么。我并不是想在这里表现得自信，而是明智而诚实地询问您是否真的需要数据沿袭。您可能希望从以下问题开始：

1. 它是用来做什么的？
2. 您需要什么级别的覆盖？
3. 是否需要将生产源可视化，还是数据仓库就足够了？
4. 您是否需要连接 BI 解决方案？如果需要，需要到什么程度？

然后你向宇宙发声并决定：购买还是建造。这里有很多需要考虑的地方。我的看法如下：

• 它将仅由数据团队使用，还是业务用户也会参与？（考虑所需的 UX/UI 级别。）
• 您准备为此投资多少？（计算内部构建的成本（以团队的工作时间为代价），并将其与从供应商处购买的成本进行比较。）请不要忘记将您的团队最初向您承诺的工作时间增加一倍。听我说；我是以产品经理的身份发言的。
• 考虑一下您的数据平台中已有的内容：数据湖、使用第三方数据源以及数据团队已在使用的堆栈。这听起来很简单也很有趣，直到您开始处理复杂的情况，例如跨项目依赖关系、临时表的视图，或者分片表等，等等。
• 您的团队的战略重点和技能组合是什么？这对您来说是一项战略投资吗？您是否有能力维护和发展它？因为无论您相信与否，您的数据平台都会不断发展。

结论

最终，我个人认为，数据沿袭作为独立的可视化效果并不有效。我们使用数据沿袭的案例是帮助排除损坏的管道或模型错误，因为当组织拥有包含数百条管道和数千张表的活动仓库时，不可能跟踪一切是否按预期运行。当我们谈论数据质量时，那些是 SQL 规则和已经预料到和已知的东西，但管道和模型是另一回事。它很大程度上与数据平台的连接性、兼容性和有效性有关。将数据管道/模型错误检测与数据沿袭配对是我们看到用户响应和价值的领域。此外，它还帮助我们的客户节省资金，因为它还与成本洞察有关。

仅凭血统并不能解决问题；它会产生新问题。没有人理解解决方案是如何使用的，因为仅凭血统并不能产生作用。相反，结合异常检测和管道错误检测，它有助于更​快地解决问题。

虽然数据沿袭本身可能只是另一个闪亮的工具，但当与全面的监控机制以及组织和数据团队建立强大而可靠的数据平台的承诺相结合时，它的真正价值就会显现出来。