在这篇文章中，我将尝试从我的角度来解释，包括我自己在Blibli.com开发沿袭Lineage追踪器的个人经验。
随着最近越来越多的人关注数据线（Data Lineage），有几个积极开发的开源工具和库开始出现，并做出了突破性的改变，诱人地被采用。
Apache Atlas
列表中的第一个是Apache Atlas。Apache Atlas是一个开源项目，提供开放的元数据管理和治理能力，正如他们的主页上所说。基本上Atlas是一个管理元数据的工具，特别是为了数据编目。Atlas最初是为了支持Hadoop，然而他们也为其他系统提供支持，如Hive、Sqoop和Kafka。
Atlas的一个很大的缺点是缺乏对关系型数据库（如Postgres和MySQL）的挂钩支持。另一个需要注意的是，Atlas有自己的系统，与你现有的环境分开，意味着你需要额外的计算资源来运行它。如果你只是想跟踪血统，Atlas是一个多余的东西。在对这个系统进行研究后，我发现缺乏整合和僵化的设计是不利的。
Airflow
对于那些熟悉ETL的人来说，一定会在某一时刻接触到Airflow。Airflow是一个工作流执行器，你可以在其中设计任务，在一个有向无环图中执行，也被称为DAG。Airflow在执行批量数据处理方面相当受欢迎。由于有大量的集成，各种插件和不断增长的社区，Airflow是任何刚刚学习数据仓库的人以及拥有数百个服务和数据源的企业的最佳选择。
从1.10.0版本开始，Airflow增加了对通过数据线后端自动跟踪数据线的支持。这个数据线后端是可插拔的，这意味着你可以开发自己的后端并将其与Airflow集成。Apache Atlas也被支持为其中一个后端。要使用这个功能，你只需要配置任务的入口和出口参数。出口参数甚至可以被设置为自动从上游任务中获取。
然而，这个优点也伴随着缺点。1.10.xx版本的Airflow的实验状态是有可能改变的，而且仍然缺乏功能。Airflow记录的数据也不够丰富，无法满足我的需要。
Marquez
接下来是Marquez。它是LF AI & Data的一个孵化项目。Marquez是一个开源的元数据服务，用于元数据的收集、聚合和可视化。它主要支持数据脉络，但它也是数据发现和数据治理的强大工具。Marquez使用一个名为OpenLineage的开源数据数据线标准。通过使用OpenLineage，Marquez允许它的用户使用称为Facets的东西来定义他们自己的元数据结构。
Marquez支持元数据版本的开箱即用。它有一个简单而抽象的数据模型。Marquez中的所有数据存储被称为数据集，一个数据集由一个Job产生，Job的一个实例被称为Run。Run包含执行的具体配置，而Job定义了整体配置。由Job产生的数据集会根据其模式自动分配到一个版本ID。
Marquez的最大缺点是它还处于起步阶段。它仍然是一个非常不成熟的项目。很多东西都还没有得到支持。例如，Marquez的库有命名一个数据集和它的来源的标准。有几个数据存储系统被原生支持，如Postgres、MySQL、MongoDB等。然而，如果你使用现有系统以外的任何存储系统，你就必须自己创建命名规则。但是在这个命名规则上没有明确的规则。另一个缺点是他们目前的REST API的功能不足，根据我的经验，感觉几乎没有用。
OpenLineage
OpenLineage是一个开源的框架，用于在服务之间发送数据线元数据。这是Marquez和许多其他系统使用的标准，如Apache Atlas、Amundsen和Egeria。如果你阅读文档，OpenLineage似乎与Marquez有非常紧密的联系。但是不要担心，OpenLineage应该是一个通用的框架，任何人都可以使用。
就其本身而言，OpenLineage并没有提供太多的甚至是任何功能。但从行业标准的角度来看，这是一个好东西。因为在未来，越来越多的数据线迹工具会出现，我们需要以某种方式将其标准化。
在分析了几个数据线追踪工具和框架之后，人们不能不说这是一个混乱的问题。由于数据移动技术的多样性，特别是在追踪方法上有很多不一致的地方。有些系统使用基于查询的转换，有些使用API，有些则是针对流媒体数据。展望未来，我认为我们必须在兼容和适用于多个ETL执行器的基础上，更多地倡导标准和抽象。
挑战
在开发数据线追踪器时，你可能会面临很多挑战。通过了解这些挑战，你就会明白在开发数据线追踪器之前你需要准备什么。
从颗粒度问题开始。跟踪任务之间的数据移动很容易，这就是Airflow如何通过了解任务的依赖性来跟踪行踪。但你有没有想过，如何跟踪一行到另一行之间的移动？或者一个元组（行、列）到另一个元组？我想你已经想到了。粒度是使开发行追踪器头疼的原因。因此，在开始你的追踪器项目之前，对颗粒度设置一个硬性限制总是一个好主意。就我个人而言，我已经开发了能够跟踪表级运动的数据线，而且我认为大多数行业反正只需要这么多细节。
第二是缺乏标准。正如我之前所解释的，数据线工具缺乏标准是一个大问题。因为即使我们有能力开发我们自己的内部数据线追踪器，我们仍然希望有一个现成的系统，因为我们将免于更新和维护的负担。目前可用的开源工具还没有准备好用于生产，但谁知道1-2年后我们会有什么。
接下来是各种数据源和转换技术。如果你已经在颗粒度方面遇到了很多麻烦，那就准备好迎接这一次吧。DBA可以自由选择他们所使用的任何数据库或数据存储，这也是一件好事。更多的选择创造了更多的竞争，这反过来又创造了创新的竞赛。在一个组织中，很少只使用一种单一类型的数据库。你通常会发现许多种数据存储系统，从关系型到列型，从基于文档到图形。对于数据线追踪器来说，数据源通常决定了数据转换技术。因此，一个组织使用的数据库种类越多，就越难完全跟踪所有的数据移动。
数据从A点移动到B点是通过一些东西，通常是一个脚本或一个系统。这些脚本或系统正在做的事情通常被称为ETL或提取、转换和加载。另一件要记住的事情是在你的公司中使用的数据移动或ETL技术。不同的技术显然需要不同的出处追踪方法。
详细点击标题