在软件的每个子领域中,我们一遍又一遍地看到相同的故事。产品一开始规模小,时间长,在其产品中添加相邻的垂直领域和功能,最终成为一个平台。一旦这些平台变得足够大,人们就开始思考如何更好地为被忽视的垂直领域服务,或者抽象出功能,以便将其分解为专门构建的块,然后开始分解。最经典的例子就是Craigslist的拆分。你可能在网上的某个地方看到过这个图表的一个版本:
在数据世界里,它';很难理解是什么构成了一个平台,但幸运的是,有些工具自我宣传。气流是其中之一:
Airflow是由社区创建的一个平台,用于以编程方式编写、安排和监控工作流。
人们可能会认为工作流是工作流管理器,但毫无疑问,产品的灵活性允许它承担额外的责任。大量使用Airflow的用户可以在不离开平台的情况下完成大量与数据相关的任务;从提取和加载脚本到生成报告,再到使用Python和SQL进行转换,再到将数据同步回BI工具。
在数据堆栈碎片化之前,创建带有气流的端到端管道并不罕见。过去,企业通常将几乎整个数据工作流构建为内部数据工程师开发的定制脚本。更大的公司甚至在Airflow内部构建了自己的框架,例如具有类似dbt的SQL转换功能的框架,以便数据分析师更容易编写这些管道。
如今,数据从业者拥有许多工具,他们很少需要使用气流之类的工具。Fivetran和Airbyte负责使用Airflow编写的提取和加载脚本。dbt用于数据转换,人口普查和Hightouch用于反向ETL。度量和实验层也有自己的专注工具;使用Transform、Metriql、Supergrain和Eppo实验等工具进行度量。某些公司在数据科学和ML工作负载方面依赖气流,但随着MLOP的普及,这一层也被抽象出来。像Feast这样的开放源代码工具正在将过去作为独立Python脚本存在的功能管理最佳实践分解开来。
如果气流的分离意味着所有的重物都是由单独的工具完成的,那么剩下什么呢?
缺少的差距是,对于需要在非SQL语言中发生的事情,我们仍然没有一个好的解决方案。例如,在dbt DAG中添加数据转换仍然是一项非常重要的任务。另一个例子是dbt实验室的特里斯汀指出的实体解析场景。DAG中的Python节点不是转换也是很常见的。这样的节点可能会使用ML模型计算风险用户,将预测写入表中,然后由SQL转换进一步处理。我们在Features and Labels上通过向dbt添加双语支持来解决这个问题。
另一项重要职责是安排时间,但这是一项相对简单的任务。EL通常是数据管道的起点,所以我可以看到EL工具(甚至是dbt Cloud)在没有气流的情况下执行此操作。人们非常喜欢Airflow UI,它提供了整个系统的整体视图,可以轻松发现失败的地方,并在必要时重新运行作业。这是一个正确的观点,但随着更多的复杂性被转移到其他工具中,整体观点的回报越来越小。例如,如果气流工作流正在调用复杂的dbt云作业,则无法从气流UI中观察到dbt DAG的复杂性。
还有一些工具正试图通过更容易地部署任务或更具可扩展性、容器化或资产驱动,成为更好的工具。。。在不断变化的数据环境中很难做出预测,但我不确定我们是否需要更好的气流。构建更好的气流感觉就像是试图优化编写本来不应该编写的代码。
各种各样的工具正在分解气流,这种多样性正在现代数据堆栈中造成大量碎片。和其他人一样,我也预测这些工具在未来几年会得到一些整合。我相信dbt云是实现整合的最佳位置。下一篇文章将对此进行详细介绍!