大数据编排引擎历史回顾 - Ananth


我在 Hadoop/Bigdata 的早期阶段开始研究数据管道,当时大数据是一个流行词。Apache Oozie (有人还记得 Oozie 吗?)是一种用于编排数据管道的首选工具,您必须在 XML 文件中手动编码工作流(毫不奇怪,文件名是 workflow.xml)。
Apache Airflow 极大地改进了数据管道。以编程方式编写数据管道的能力、DAG 的概念,以及最重要的是,第一次使用出色的 UI 比以前的工具好一个数量级。

Airflow - 任务执行
Airflow 的首次发布是在2015年 6 月,也就是[url=https://www.globenewswire.com/news-release/2014/10/21/1186817/0/en/Snowflake-Raises-26M-in-Funding-to-Reinvent-the-Data-Warehouse.html]Snowflake 推出其商业产品[/url]六个月后。云数据仓库在那个时候才刚刚开始起飞。编排引擎主要专注于运行 Hadoop Map Reduce、Pig、Crunch 和 Hive 作业。在 Apache Spark 统一 SQL 和 fluent 数据处理模型之前,我们已经看到了碎片化的大数据处理框架。 

Airflow 采用了任务(Airflow 算子)作为功能计算单元。Airflow 提供了传感器和任务依赖来捕获依赖。Airflow DAG 模型是定义任务依赖关系的优秀抽象;但是,任务沿袭的可见性仅限于单个 DAG。如果要运行回填,我们必须开发一个专用工具来了解整体依赖关系。 

一些公司采用“一个 DAG”模型将所有任务捆绑在一个管道中,在 Slack 数据团队中,我们构建了一个 DAG 解析器来构建一个统一的 DAG 视图 

任务执行的挑战
随着原始数据转换为更结构化的表,我们看到了一种模式,即采用 Hive SQL 作为构建数据模型的事实上的标准。SQL 赢得了数据处理抽象。由于转换逻辑的单元在 SQL 中表示为模型,因此任务依赖性被证明是难以管理的,并且为每个 Hive 表查找任务依赖性是一项繁重的工作。Airflow 提供了HivePartitionSensorSQL Sensors ,但它并没有解决模型框架的任务依赖问题。 

dbt - 模型执行
到 2019 年,云数据仓库被广泛采用。任务执行没有被云数据仓库系统很好的采用,进入dbt。dbt 中最重要的函数是ref() 。dbt 使用模型之间的这些引用来自动构建依赖关系图。
参考模型极大地简化了数据管道,dbt 成为数据管道的实际工具。需要注意的是,Airflow 还支持其他流行的功能,如 Jinja 模板和 dbt 文档。我在这里记录了我对 dbt 的想法。

独立执行单元的影响
任务和模型执行单元源于多样化的数据处理框架以及支持各种业务用例的需求。SQL 非常适合数据分析/BI,其中 ML 和原始数据处理使用更流畅的界面。 
由于单独的执行单元,任务编排引擎和模型执行引擎都不能具有组织的端到端数据沿袭。它为专门的数据沿袭/元数据系统铺平了道路。
任务单元和模型单元增加之间的握手变得复杂。我们开始看到数据可观察性工具的兴起,这些工具强调用于定义特定数据质量标准和 SLA 的 数据合同和数据认证。

数据平台解绑的开始
数据平台的分拆是单独执行模型的结果。编排引擎在组织范围的数据管理状态上的上下文越来越少。 

同时,我们也应该承认,数据编排、数据质量、沿袭和模型管理本身就是重大问题。各个工具正在尝试解决特定问题;然而,从整体架构的角度来看,会产生管道胶带系统。它使数据的梦想成为资产对于许多公司来说仍然是一个有抱负/不切实际的目标。 

捆绑:数据操作系统
数据社区经常将现代技术堆栈与Unix 哲学进行比较。但是,我们缺少数据的操作系统。我们需要将模型和任务执行单元合并为一个单元。否则,我们在没有统一的情况下构建的任何抽象都会进一步放大数据的混乱。作为资产的数据仍将是一个理想的目标。
我们需要将模型和任务执行单元合并为一个单元。否则,我们在没有统一的情况下构建的任何抽象都会进一步放大数据的混乱。