数据工程
视频号
微信公众号
知识星球
- 7 次浏览
【数据工程】2023年数据工程路线图
视频号
微信公众号
知识星球
2023年我将如何学习数据工程（如果我可以重新开始的话）
市场上有这么多不同的工具和技术，开始数据工程的职业生涯可能会让人不知所措。
Big Data Landscape — https://mattturck.com/data2021/
常见的问题是，“我应该先学习Databricks还是Snowflake？我应该专注于Airflow还是Hadoop？”
在这个博客中，我将带你从基本水平到高级水平，掌握成为一名数据工程师所需的所有资源和技能。
我将技能分为三种：
- 对于那些对这个领域完全陌生并希望将自己的职业生涯从其他领域转向数据工程的人来说。
- 对于那些了解一些基本知识并想知道如何前进的人来说。
- 适合那些有一定经验并希望在职业生涯中成长的人。
第1节-探索未知
你是否希望将自己的职业生涯转向数据工程，但却被可用的工具和技术的数量所淹没？你并不孤单。许多人发现自己处于同样的位置，无论他们是在非科技工作，还是学生或新生，或者是在不同的科技工作并希望转换。
如果你属于这些类别中的任何一类，你需要做的第一件事就是掌握你的计算机科学基础。
如果你是这个领域的新手，那么在进入数据工程之前，你需要了解计算机科学中使用的基本概念和术语。
这方面的一个很好的资源是哈佛大学CS50在YouTube上提供的系列节目。
通过观看本系列视频，您将获得对计算机科学的基本理解，而无需获得学位或花费数月时间学习基本知识。
一旦你掌握了计算机科学的基本知识，你就可以进入下一步：学习数据工程所需的技能。
数据工程师需要具备三项基本技能：
- 编程语言：作为一名数据工程师，你将编写大量的转换工作，部署脚本，验证和测试它们，为此，你需要掌握一种编程语言。三种流行的选择是Java、Scala和Python。如果你是初学者，Python是一个很好的选择，因为它很容易学习和理解。
- SQL：结构化查询语言是数据行业的王者。无论你是数据分析师、数据工程师还是数据科学家，你都会发现自己经常使用SQL。SQL是与关系数据库通信的方式，了解如何使用它来选择、插入、更新和删除数据非常重要。
- Linux命令：大多数数据工程任务都是在远程机器或云平台上完成的，这些机器通常在Linux操作系统上运行。了解如何使用这些机器并理解基本的Linux命令是很重要的。
第2节：建立牢固的基础
在这个阶段，你的目标应该是学习数据工程所需的最低水平的技能，以及如何开始你的数据工程师职业生涯。
你不必花时间学习市场上可用的每一项技能或工具；在这个阶段，您只需要专注于数据工程所需的高要求和重要级别的技能集。
在这个阶段，我们将专注于为数据工程打下坚实的基础。
您需要关注的第一项基本技能是理解数据仓库。
这有两个部分：
- -学习数据仓库基础知识
- -了解Snowflake或BigQuery等工具。
数据仓库的基本原理通常包括理解OLTP、维度表、提取、转换、加载和数据建模，如理解事实表和维度表。
如果你喜欢从书中学习，你可以阅读Ralph Kimball的《数据仓库工具包》。
这是关于数据仓库的最好的书之一。
一旦学习了数据仓库的基本原理，就可以将所学知识应用到特定的工具中。
市场上有许多不同的数据仓库，如Snowflake、BigQuery和Redshift。
我建议学习雪花，因为它的需求与日俱增。
除了了解数据存储，您还需要了解数据处理框架。
有两个主要框架：
- -批量处理：批量处理数据，例如每天处理一到两次上个月的数据。
- -实时处理：实时处理数据。
对于批处理，大多数公司都使用Apache Spark。这是一个用于数据处理的开源框架。
您可以从学习Apache Spark基础知识开始，然后学习为Apache Spark环境提供动力的工具，如Databricks、AWS EMR、GCP Data Proc或您在市场上找到的任何其他工具。
我的建议是使用SparkCon和Databrick进行练习，并使用PySpark（Python）作为语言。
对于实时处理，我们有Apache Kafka、Apache Flink和Apache Storm等框架和工具。你可以选择一个并了解它。
我们学习的方式是把不同的问题分解成更小的部分。
首先，我们专注于学习基础知识，然后我们学习市场上一种需求很高的工具，您可以将基础知识应用于此。
作为一名数据工程师，你需要掌握的第三项技能是学习云平台。
有三种主要选择：
- -Microsoft Azure
- -亚马逊网络服务（AWS）
- -谷歌云平台（GCP）
我的职业生涯始于AWS，但你可以选择任何云平台，因为一旦你学会了一个，就更容易掌握其他平台。云平台的基本概念是相似的，只是在用户界面、成本和其他因素上略有不同。
在数据工程中，您需要创建数据管道来处理数据。数据管道，也称为ETL管道，用于从关系数据库中提取数据，应用转换和业务逻辑，然后将数据加载到目标位置。要管理这些操作，您需要了解工作流管理工具。
一个受欢迎的选择是Apache Airflow
Airflow是一个开源的工作流管理工具，允许您创建、安排和监控数据管道。它在行业中得到了广泛的应用，并拥有庞大的用户群体。通过学习Airflow，您将能够创建数据管道并自动化ETL过程，使您作为数据工程师的工作更加轻松。
第3节：现代数据堆栈和高级技能
作为一名数据工程师，市场上有很多不同的工具和方法。
保持最新信息并了解所有信息是很重要的。除此之外，您还需要学习如何设计整个数据基础架构，如何管理和扩展系统，并掌握高级技能。
在本节中，我们将重点学习数据工程所需的高级技能。
我推荐的第一件事是探索现代数据堆栈（MDS）。
有一个工具列表，您可以进一步了解和理解它们的核心用例。
- 我强烈建议探索的一个工具是DBT（数据构建工具），因为许多公司都在使用它，而且它在市场上越来越受欢迎。
- 然而，重要的是不要沉迷于太多的工具，只需了解每一个工具的核心用例。
- 另一个重要方面是了解安全性、网络、部署和其他相关主题。
您还可以了解Docker或Kubernetes，它们在生产中部署数据管道时非常有用。
我建议阅读以下书籍：
- -设计数据密集型应用程序
- — Fundamentals of Data Engineering
此外，阅读AWS和GCP等平台上的客户案例研究可以让您更好地了解如何在现实世界中使用这些工具。
Customer Success Stories: Case Studies, Videos, Podcasts, Innovator stories
我已经制作了一个关于这个主题的详细视频，并提供了一份关于课程和项目的完整文档
- 81 次浏览
【数据工程】为什么现代数据平台不再进行ETL
视频号
微信公众号
知识星球
传统ETL流程过时的4个原因
近年来，现代数据平台发生了巨大变化。传统规划的传统内部数据仓库正越来越多地转向基于云的数据湖和数据仓库。
另一个值得注意的变化是摆脱了传统的ETL（提取、转换、加载）过程。相反，现代数据平台依赖于一系列先进的工具和技术来简化数据处理和准备过程。因此，用户可以更快、更可靠地访问高质量的数据。这里的关键词是ELT和Zero ETL方法。
以下四句话是ETL在现代数据环境中变得越来越不重要的关键原因。
原因1：ETL速度慢，需要大量资源。
传统的ETL过程通常涉及跨多个系统和阶段移动大量数据，包括从源系统提取、数据转换和加载到目标数据仓库。这些过程可能缓慢、资源密集且容易出错，尤其是安装在内部部署基础设施上时。这使得它很难跟上现代数据驱动企业的需求[1][2]。
原因2：ETL不够敏捷。
在当今快节奏的商业环境中，数据必须实时可用，以便为组织提供做出明智决策所需的见解。ETL过程可能缓慢且不灵活，因此很难对不断变化的业务需求或不断发展的数据源做出快速响应。因此，通常使用ELT，在没有初始转换的情况下加载数据，甚至使用Zero ETL方法，在源系统中直接收集或查询数据，并自动检测和处理模式更改等情况[1]。
The New Buzzword in Data Engineering: Zero ETL
原因3：ETL成本高昂。
传统的ETL工具还需要在硬件、软件和人员方面进行大量投资以进行操作和维护。现代数据平台可以消除其中的许多成本，使组织能够专注于为用户提供价值，而不是管理复杂的ETL流程。在这里，可以接管数据集成的内置服务和附加组件通常更便宜、更容易实现。谷歌数据流就是一个例子，它可以在没有太多编程或安装的情况下处理实时CDC[3]。
Google launches new Data Service Datastream
New Tool for Seamless Replication from Databases to BigQuery
原因4：现代数据平台支持自助式数据准备。
除了Zero ETL和自动化数据集成服务，它们处理（几乎）所有集成数据的事情之外，现代数据平台的另一个关键优势是它们能够支持自助数据准备，允许用户在没有复杂ETL过程的情况下轻松访问和操作数据。这种方法使用户能够在数据准备中发挥更积极的作用，使他们能够更有效地探索和分析数据。因此，在使用Zero ETL或ELT工具进行数据集成后，您通常可以使用一些技术和工具来实现数据准备和转换（如有必要）。无论是直接在数据仓库中通过SQL，还是在随后的商业智能工具中，这些工具还提供了许多选项，用于从原始形式更正数据，并在必要时对其进行调整或丰富。
总结
总之，可以说，由于成本高、速度慢、资源量大和灵活性高，现代数据平台现在正在远离ETL过程。这些数据平台正朝着先进的技术和方法发展，这些技术和方法能够提供更快、更高效、更灵活的服务，以便用户能够实时访问高质量的数据，从而实现更大的业务成果。
来源和进一步阅读
- [1] CAYLENT, Adam Selipsky Keynote recap — AWS re:Invent 2022 (2022)
- [2] BigData Insider, AWS-Chef Selipsky ruft die Parole „Zero-ETL“ aus (2022)
- [3] Google, Datastream for BigQuery (2022)
- 13 次浏览
【数据工程】数据工程不是软件工程
视频号
微信公众号
知识星球
假装数据和软件是一样的，会对数据工程师的成功产生反作用.
近年来，数据工程似乎正在与DevOps融合。两家公司都采用了云基础设施、容器化、CI/CD和GitOps，为客户提供可靠的数字产品。工具子集的聚合导致许多人认为数据工程和软件工程之间没有明显的区别。因此，数据工程相当“粗糙”的事实仅仅是因为数据工程师在采用良好的软件开发实践方面落后了。
这种评估是错误的。数据工程和软件工程共享许多通用的工具和实践，但它们在许多关键领域也有很大的不同。忽视这些差异，像管理软件产品团队一样管理数据工程团队是错误的。把数据工程想象成西红柿:它是一种水果，但这并不意味着它应该被添加到水果沙拉中。这篇文章旨在强调数据工程中的一些独特挑战，以及为什么这需要自定义方法。
数据管道不是应用程序
软件工程倾向于关注构建应用程序。在本文中，应用程序的定义非常宽泛，可以是一个网站、一个桌面应用程序、一个API、一个大型主机应用程序、一个游戏、一个微服务、一个库，或者介于两者之间的任何东西。它们的共同特点是:
- 通过提供新的交互方式为用户提供价值。一个游戏可以玩，一个网站可以浏览，一个API可以在其他软件中使用。
- 拥有许多独立的功能。网站可以增加页面数量，游戏可以增加关卡或可玩角色的数量，API可以添加更多端点。因此，应用程序永远不会真正完成。
- 处理它们创建的相对较少的状态。状态被设计为支持应用程序。这种状态的管理通常被卸载到外部系统。目标是使软件的大部分是无状态的。web应用程序可以在任何时候被终止和重新启动;它的状态由运行在单独进程中的数据库管理。
- 与其他软件和服务松散耦合。好的软件应该在任何环境下都能独立运行，因此微服务和容器很受欢迎。
数据工程师关心的是构建数据管道。数据管道从产生数据的地方获取数据，对其进行转换，并将其放在消费数据的另一个地方。通常，我们的目标是按照时间表自动化这些管道，这样数据集就会随着时间的推移而更新。与应用程序一样，数据管道通常也是软件的一部分。与应用程序相反，数据管道:
- 不提供任何直接价值。管道中没有用户。只有管道生成的数据集对下游消费者才有价值。如果数据通过一些精心设计的复制粘贴方案到达目的地，客户也会同样满意。
- 只有一个与客户相关的特性:生成所请求的数据集。因此，尽管由于上游系统用户需求的变化，管道将需要持续维护，但有一个明确的完成点。
- 管理大量的状态。管道被设计用来处理来自它不控制的其他软件的现有状态，并将其转换为它可以控制的状态。许多管道以增量方式构建数据集，每次运行都会添加更多数据。从这个意义上说，这些管道可以被视为非常长时间运行的流程，不断地创建越来越多的状态。
- 具有不可避免的紧密耦合。数据管道的目标就是绑定到数据源。输油管的稳定性和可靠性取决于输油管的来源。
这些基本的差异给数据工程带来了独特的挑战，而业务、IT管理甚至软件工程师往往很难理解这些挑战。我们来看看。
管道要么完成，要么毫无价值
如今，许多组织都在某种程度上使用敏捷来管理他们的软件团队。这些框架的核心理念是通过在短迭代中构建和发布软件，最大限度地提高软件向客户交付价值的速度。这应该尽可能快地交付最小可行产品(MVP)，并确保快速反馈循环，从而确保团队始终以最高优先级处理功能。
这些想法并不适用于数据工程。
不能在增加客户价值的小迭代中开发数据管道。在数据管道中没有等价的MVP。它为客户生成所需的数据集，或者不生成。
因此，数据管道开发并不完全适合敏捷框架。复杂的数据管道对应于单个用户故事，但通常需要多个sprint来完成。非技术管理人员很少考虑到这一点，并试图将数据工程师硬塞进scrum团队。结果是用户故事被任务所取代，例如“构建API连接器”和“构建摄取逻辑”，这不可避免地将scrum板变成了微观管理的设备。
当管理人员不了解他们管理的基本原理时，他们往往会做出糟糕的、不可行的决定。一位经理对管道的缓慢进展感到沮丧，他曾经要求我们团队中的数据工程师逐列迭代地构建数据集，这样客户“至少已经有了一些数据可以开始处理”。具有复杂管道实践经验的数据工程师和曾经收到过无用数据集的数据科学家将认识到这种情况的荒谬。对于没有这方面背景的读者，这里有三个原因说明为什么这行不通:
1. 部分数据集没有成比例的效用
如果一个数据集包含10列中的9列，它是否有90%的用处?这取决于省略了哪一列。如果数据科学家的目标是建立一个基于数据的预测模型，但是缺少的列是他们想要预测的标签或值，那么数据集是0%有用的。如果列是一些与标签无关的随机元数据，那么它可能是100%有用的。最常见的是，一列表示一个字段，该字段可能与标签相关，也可能不相关;找出它是否相关正是数据科学家想要通过实验发现的。这就是为什么数据科学家想要一个尽可能完整的数据集来开始实验、探索和逐步优化他们的模型。为他们提供部分数据集，确保一旦有额外的字段可用，就需要重新进行实验和优化。
2. 开发管道的时间与数据集大小无关
即使客户对其中的一半数据集很满意，生成这个数据集所需的时间也不会是生成完整数据集所需时间的一半。数据管道不是由独立的作业组成，每个作业产生一个列。如果多个列来自同一来源，它们可能是相关的，因此在最终数据集中包含一个或多个列的工作量是相同的。但是，将这些列与另一个表中的列合并的逻辑可能像单个连接一样简单，也可能需要一系列复杂的窗口函数。此外，在数据从另一端输出之前，可能需要在数据管道中编写大量样板，例如，访问API的客户端或处理非结构化数据的解析器。一旦这样做了，扩展逻辑来处理其他字段可能就很简单了。因此，最终数据集中的列数是衡量管道复杂性的糟糕指标，就像使用代码行数来衡量生产力一样。
数据集大小也可以指行/记录的数量。设计良好的管道应该能够处理任意数量的记录，因此开发时间应该完全解耦。然而，根据具体需求，开发时间可能会出现“跳跃”，例如:
- 数据集需要多久更新一次，也就是说，我们需要批处理还是流式处理?
- 预期的数据量和速度是多少?
- 数据是否适合RAM?
这些考虑因素应该事先知道，并将影响管道的整个设计。
3.建立数据集的时间和经济成本与数据集的大小相关
就行和列而言，数据集越大，构建和更新它所需的时间就越长。在一个庞大的数据库中编辑一条记录是琐碎和快速的，但是对于分析数据集来说，这是一个不常见的场景。修改分析数据集通常涉及添加/更改整个列(这会更改所有记录)或更新数千或数百万行。有两种方法可以处理数据的变化，但都不便宜。
从开发人员的角度来看，更新数据集最简单的方法是通过更新和重新运行管道来覆盖所有内容。然而，就计算成本和刷新数据集的时间而言，这是最昂贵的。设计一个能够正确覆盖之前运行状态(幂等)的管道也并非总是微不足道的，需要适当的预先规划。
或者，更新数据集的逻辑可以在单独的管道中编码，该管道将旧数据集作为输入。这在计算成本和速度方面可能更经济，但会产生额外的开发时间和精神开销。应用delta的管道不是幂等的，因此跟踪当前状态以及执行特定操作的时间非常重要。即使在第二种情况下，也应该更新旧的管道，以便在新的更新中包含所需的更改。
不管怎样，问题是，数据集有固有的惯性。数据集越大，尝试进行更改需要更多的时间、精力和/或金钱。
结论:将部分管道部署到生产中是浪费的
将部分完成的管道部署到生产环境中对客户没有用处，浪费计算，并且使构建管道的工程师的生活变得复杂，因为他们将不得不处理旧状态。将大量的DevOps和敏捷原则转移到数据管道开发中，在这种开发中，增量更改和频繁部署被鼓励，这完全忽略了数据的惯性。
工程师们希望“第一次就做对”，并尽量减少部署到生产环境中的次数。频繁部署的管道要么表明客户不知道他们想要什么，要么表明数据源非常不稳定，管道需要不断修补。与无状态应用程序相反，在无状态应用程序中，更新往往像杀死几个容器并旋转新容器一样简单，更新数据集与重新部署管道代码不同。将管道代码打包到容器中并在Kubernetes上运行并不能弥补这一差距。
管道开发中的反馈循环是缓慢的
为了快速创建新功能或修复软件中的错误，开发人员需要快速反馈，告诉他们所写的内容是正确的，并将软件推向正确的方向。
在软件开发中，这通常是使用一套单元测试来实现的，开发人员在本地运行单元测试来检查软件的每个组件(仍然)是否按预期工作。单元测试应该是快速的，不与任何外部系统交互，也不依赖于任何状态。他们应该独立地、隔离地测试函数、方法和类。通过这种方式，软件开发人员可以在开发过程中获得快速反馈，并且在打开拉取请求时可以非常确信他们的代码按预期工作。如果需要测试与其他系统的交互，则CI管道也可以运行较慢的集成测试。
这里有一个数据工程的秘密:数据管道很少进行单元测试(喘息!)。数据管道通常通过简单地部署来进行测试——通常首先部署到开发环境中。这需要一个构建和部署步骤，之后工程师必须监视管道一段时间，看看它是否按预期工作。如果管道不是幂等的，重新部署可能首先需要人工干预来重置上次部署留下的状态。与运行单元测试相比，此反馈周期非常缓慢。
那么为什么不直接编写单元测试呢?
1. 数据管道在无法进行单元测试的方面会失败
可以进行单元测试的自包含逻辑通常在数据管道中受到限制。大部分代码都是胶水和管道胶带。因此，几乎所有的故障都发生在系统之间的故障接口或进入管道的意外数据。
系统之间的接口不能用单元测试进行测试，因为这些测试不能单独运行。外部系统可以被模拟，但这只能证明管道与数据工程师认为的外部系统工作方式相同的系统一起工作。实际上，数据工程师很少知道所有相关的细节。让我们举一个现实世界的例子:为了防止DDOS攻击，公共API可能对同一IP在一定时间间隔内可以发送的请求数量有一个未公开的限制。API的模拟可能无法解释这一点，但它存在于实际系统中的事实可能会破坏生产中的管道。此外，外部系统很少是稳定的。事实上，数据管道的建立通常是因为人们希望将数据从不可靠的系统转移到更可靠的系统。模拟不会揭示真实系统是否以破坏管道的方式进行了更改。
众所周知，数据生产者不善于始终如一地交出高质量的数据。数据管道必须总是对将要输入的数据做一些假设。数据中意外的内容或结构会破坏管道，或者至少会产生不正确的结果。保护管道免受松散数据源侵害的一种常用策略是在读取时验证模式。但这并不能防止数据的错误内容和微妙的“数据漏洞”。例如，时间序列是否正确处理日光节约时间?列中是否存在不符合预期模式的字符串?代表真实世界测量值的数值列中的值在物理上有意义吗?这些都与可以用单元测试测试的管道逻辑无关。
2. 单元测试比管道逻辑更精细
测试管道中有限的自包含转换逻辑所需的单元测试比代码本身更复杂，因为它要求开发人员创建具有代表性的测试数据，以及预期的输出数据。这是大量的工作，并没有从本质上提高对管道正确运作的信心。此外，这将把问题从“该功能是否按预期工作?”到“这个测试数据能充分代表我的真实数据吗?”理想情况下，单元测试覆盖了输入参数组合的一个很好的子集。但是在转换数据集的函数中，例如以数据框架的形式，数据集参数本身呈现出接近无限维的参数空间。
结论:开发管道是缓慢的
获得关于数据管道的可靠反馈的最佳方法是部署并运行它。这总是比本地运行单元测试慢，这意味着需要更长的时间来获得反馈。其结果是管道开发，特别是在调试阶段，非常缓慢。
可以考虑比运行整个管道更快的集成测试。然而，这些通常不能在开发人员的机器上运行，因为它不能直接访问相关的源系统。因此，这些测试只能在与管道相同的环境中运行，这同样需要部署。这在很大程度上违背了编写测试以获得快速反馈的目的。
“数据合同”现在在处理鲁莽的数据生产者时非常流行。对进入管道的数据充满信心将消除管道开发中的许多不确定性，并使其不那么脆弱。然而，这些合同似乎很难执行，因为生产者没有动力遵守这些合同。此外，组织将希望使用从外部来源提取的数据，如公共api;祝你在与这些外部方谈判数据合同时好运。
流水线开发不能并行化
我们已经确定，数据管道是一个单一的用户故事，由于反馈周期长，开发速度很慢。但是，由于流水线由多个任务组成，一些管理人员试图将它们分配给多个开发人员，以加快流程。不幸的是，这不起作用。在管道中处理数据的任务是顺序的。为了构建第二步，第一步的输出必须是稳定的。通过构建第二步获得的洞察力会反馈到第一步的改进中。因此，管道作为一个整体必须被视为开发人员迭代的一个特性。
一些管理人员反驳说，这仅仅意味着从一开始就没有充分规划管道。一开始就有数据，最后需要什么数据就很清楚了。那么，在中间需要建立什么就不明显了吗?矛盾的是，提出这种观点的管理者将会激烈地捍卫敏捷的优点。
只要数据源没有得到适当的描述，规划整个管道是行不通的。在没有合同和文档的情况下，数据工程师不得不在黑暗中摸索，以便发现数据的特殊性。这个发现过程塑造了管道的体系结构。从某种意义上说，这是敏捷的;这不是商业利益相关者想要的工作方式。
结论与建议
数据管道是软件，但不是软件产品。他们是服务于制造客户实际要求的汽车的工厂。它们是达到目的的一种手段，是从笨拙的数据源创建易于使用的数据集的自动化配方。它们是系统之间的管道胶带，这些系统不是为相互通信而设计的。它们是数据“最后一英里”问题的丑陋、脆弱和昂贵的解决方案。它们的唯一目的是管理状态，这使得它们的开发缓慢、不可预测，并且经常成为数据分析项目的主要瓶颈。无论数据影响者通过兜售另一种工具来宣称什么，无论有多少层抽象层堆叠在一起，数据从根本上不同于软件。不认识到这些差异，并在数据团队中实施敏捷过程，因为它在软件团队中起作用，只会适得其反。
你能做些什么来让数据团队成功和富有成效?
- 21 次浏览
【数据技术】dbt v1.5-三大新事物
视频号
微信公众号
知识星球
数据契约、模型版本和模型访问
dbt首席执行官最近宣布，dbt 1.5将于4月底发布，其中包括一些重大变化。在本文中，我想总结一下dbt1.5中发布的3个主要新功能（包括数据合约）。
首先，让我们从用例开始——您有一个包含数千个模型的dbt项目，而且越来越难理解谁拥有什么数据模型，并将您的更改发送出去。
因此，你可以考虑的一种方法是让嵌入式数据团队（如财务、销售、产品）拥有某些数据模型——将它们放在子文件夹中，或者你甚至可以将你的大型dbt项目拆分为子项目，并将它们作为包导入（如软件“服务”）。例如：
SELECT * FROM {{ ref('sales_models', 'opportunities') }}第二种方法仍然有效地将两个dbt项目耦合在一起，因此您无法在不破坏下游一切的情况下更改sales_models dbt项目中的opportunities.sql模型。
dbt1.5包含3个新功能，有助于大规模运行dbt：
- 访问：定义谁（以及什么）可以引用dbt项目中的模型
- 契约：指定应用于模型的列、数据类型和约束。考虑dbt测试，但在构建模型之前运行
- 版本：能够创建单个dbt模型的多个版本，因此在不破坏下游模型的情况下更容易进行更改
我将在下面更详细地介绍这些功能，但在我看来，您不必将dbt项目拆分为多个项目来从这些新功能中获得价值。
这些功能是由dbt实验室构建的，目的是帮助将数据管道视为“服务”，并将大型dbt项目拆分为小型dbt项目，每个项目由一个团队所有。
在这种方法中，每个团队都能够快速迭代自己的dbt项目，并且通过合同/访问/版本控制，不必担心上游/下游会破坏他们所依赖（或依赖它们）的其他dbt项目的更改。
这可能对你有用，但可能不行，我在这篇文章中没有立场！
1.访问
设置谁/什么可以引用（ref）dbt模型：
- private:模型只能在同一组中引用
- protected:模型只能在同一个包/项目中引用（这是默认值）
- public：模型可以被任何组、包或项目引用
组在yml文件中定义，模型在yml中被分配访问权限和组，例如：
用例是什么？这是一种干净的表面处理方式，其他项目/人员可以（也不能！）使用它。结果是，您的团队具有较少的下游依赖性，因此开发速度更快，因为不必担心崩溃。
使用private与protected可以在dbt项目中实现这种干净的拆分，而如果您有多个dbt项目，则使用public与private/protected可以实现这种拆分。
2.合同
数据契约在某种程度上已经成为数据领域的热门话题，我将试图将其过于简单化为“数据生产者和数据消费者之间关于如何构建数据的协议”。
如果您将单个dbt项目拆分为多个子项目（“服务”），并且您的项目依赖于customer_success包中的dim_customers表，那么您希望知道数据将始终包含特定的列集，并具有给定的数据类型和约束。
如果你没有走上拆分单个dbt项目的道路，这甚至是相关的——如果你拥有models/finance中的一切，并且依赖models/customer_success中的模型，你可能会希望数据模型是一致的。
dbt测试在一定程度上解决了这些问题，但重要的是，它们在几个主要方面与合同不同：
- 测试在模型建立后运行，而合同在模型建立前运行
- 如果您删除了SQL文件中的一列，并且yml中有该列，那么dbt不会中断，它只会说它不存在。然而，如果yml是在合同下的，那么如果缺少一列，dbt就会中断
在dbt中，契约有三个组件：契约本身、列和约束。下面是一个例子：
一旦签订了合同，数据模型就必须包含指定的列，以及指定的数据类型和约束。如前所述，契约在模型运行之前强制执行，因此如果失败，模型将不会运行！
您可以阅读文档以查看可用的约束类型。
用例是什么？我觉得这很有用，无论你是有多个dbt项目，还是只是一个5人以下的小型数据团队。在运行之前，能够确保您的数据模型具有特定的列、约束和数据类型，这对关键数据管道非常有用！
3.版本
这建立在合同的基础上。如果您有数据模型的下游用户，并且希望对列进行更改，而不破坏任何内容或在下游进行大量重构，那么在dbt1.5中，您将能够创建共存的模型的单独版本。
所以，假设您更改了dim_customers模型（正在签订合同），删除了一个名为country_name的列。然后，您可以通过创建一个dim_customers_v1和一个dim_customers_v2-并在yml文件中指定差异来对模型进行版本设置：
这实际上与创建一个全新的dbt模型相同，但没有为第二个模型创建新的yml条目。请注意，在这一点上，两个模型作为单独的表共存！
你可能会立刻想到一件事——如果我不想在我的数据模型中使用v1/2/3怎么办？dbt有一个可选的配置来处理这一问题：
因此，当您“关闭”v1时，您可以将defined_in:dim_customers放在v2下！
用例是什么？对于团队之间有很多下游依赖关系的大型组织来说，这是能够作为一个团队快速开发和交付新事物的救命稻草。通常，构建和发布数据模型更改以及处理下游影响必须在单个代码更改中完成，而现在它们可以单独处理。
然而，如果不仔细使用，我可以看到这种方法的一些陷阱：
- 下游用户指向不同的数据模型：如果你在不同版本之间更改过滤逻辑，那就特别痛苦！我认为defined_in配置总是指定表的“实时”版本在这里最有用
- 重构留给下游用户：如果在不破坏任何东西的情况下很容易更改模型，那么诱惑就是这样做，并将迁移到新版本的工作留给下游用户
你可以争辩说，第二点是下游用户拥有的有效东西，但如果你做出了真正的重大改变（例如订单<>客户的关系不再是1:1），那么这是一个巨大的责任！
总之，这个版本是dbt朝着允许更大的数据团队处理复杂的dbt生态系统迈出的一大步，但尽管新功能显然非常强大，但在实现之前需要仔细考虑！
感谢阅读。
- 11 次浏览
【数据框架】现代数据堆栈：Spark在哪？
视频号
微信公众号
知识星球
一年前，一些人已经预测dbt有一天会比Spark更大，而2021年证明了他们的正确性：dbt已经变得非常受欢迎，有传言称dbt实验室可能会以60亿美元的估值再次筹集资金。按照这个速度，他们很快就会赶上2021年9月估值达到380亿美元的Databricks。
尽管如此，今年Spark最让我印象深刻的是，几乎每一篇关于现代数据堆栈的博客文章都没有Spark，它是围绕两个关键组件构建的：
- 一个大规模并行的SQL引擎（BigQuery、Redshift、Snowflake）
- 和…dbt
上游：无代码提取/加载工具[no-code Extract/Load tools]（Fivetran，Stitch，Airbyte，Hevo）。下游：BI工具（Tableau、Looker、Power BI、Metabase）和反向ETL工具，用于将数据导出到专用数据库（客户数据平台等）。
The Modern Data Stack according to Dataiku: https://blog.dataiku.com/challenges-to-the-modern-data-stack
我只需要在谷歌图片中键入“现代数据堆栈”，就可以注意到数据市场上的所有公司都在提出自己的技术列表，因为他们通常会试图将自己包括在列表中。
但我也注意到，这个现代数据堆栈通常完全是在没有Spark的情况下构建的，而Databricks生态系统大多被视为它的一个完整替代方案，尝试加入可以放在堆栈中心的SQL引擎的小圈子：他们在12月发布了与dbt Core以及Databricks SQL的完全集成。
最近，我回复了另一家公司的人，他问我是否值得将Spark添加到他们的现代数据堆栈中。由于我的团队目前同时使用pySpark、BigQuery和（一点点）dbt，我自己也思考了很多这个问题。因此，我用一长串的利弊来回答他们，这些利弊激发了我目前的思考，我在这里分享：
基础设施：
BigQuery完全由谷歌管理，你没有什么可做的。相比之下，Spark的掌握要复杂得多，即使这往往会变得更容易（Spark无服务器版在GCP上预览，在Databricks和DatabricksSQL上都有）。
学习曲线：
同样，在BigQuery（它只是SQL）上比Spark更容易找到或培养熟练的人才。我的建议是：在Scala、Java或.Net中，更喜欢pySpark而不是Spark。例如，Python更容易访问，并且已经被Airflow使用。我认为在Spark中使用Python以外的另一种语言的唯一有效理由是：“用RDD做非常高级的事情”和“重用一些公司已经用Java编写的代码，而不必重新实现它”。
A hundred thanks to XKCD web comics who gave me express permission to use one of their comics in this article: https://xkcd.com/1409/
代码组织：
dbt展示了组织SQL转换管道的正确方法（我知道这一点：从2014年到2017年，我开发了一个工具，它做了与dbt相同的事情，但针对Apache Hive）。据我所知，目前没有任何工具可以为pySpark做同样的事情（dbt确实支持spark-sql，但没有完整的pySpark）。这就是为什么我们开发了一个内部工具，我希望有一天能开源。如果没有这样的工具，很容易回到dbt帮助我们停止的糟糕做法。
表达能力：
我喜欢SQL，甚至比BigQuery更喜欢，但我不能只使用SQL来完成我需要的一切。此外，我认为使用Jinja模板不是正确的解决方案：正如Maxime Beauchemin在他的博客文章中所说的那样，这将导致大量的模板化SQL和YAML。就我个人而言，我认为这与第一个调度器中的错误相同：以代码配置有很多限制，而Airflow通过证明以代码配置（感谢Python）工作得更好来扭转局面。是的，JINJA确实解决了作为代码的配置的一些刚性问题，但我仍然觉得JINJA相当沉重和冗长，可读性不强，并且单元测试JINJA代码似乎相当乏味。
SQL的局限性：
和Maxime Beauchemin一样，我相信（至少我希望如此）当BigQuery、Snowflake或Redshift提供类似于pySpark中提供的DataFrame API时，事情会变得更好。Snowflake实际上已经做到了：他们最近发布了Snowpark，其DataFrame API显然借鉴了Spark的API。我最近开始为BigQuery POC一个DataFrame API，以展示这样的东西还可以做什么（我承认，其中一些已经可以用JINJA宏完成了，但在某种程度上我觉得不太优雅，也更难维护）。我将在下一篇文章中详细介绍这个POC。
UDF：
SQL的另一个重要限制是：有些逻辑使用UDF比使用SQL代码更容易实现。在BigQuery中，UDF必须用SQL或Javascript（！！）编写。Idem与Snowflake，这也允许Java。去告诉一个只懂Python的数据工程师/分析师/科学家写一个Javascript UDF…PySpark允许我们用Python写UDF，我等不及BigQuery也允许了。
With explicit permission from xkcd: https://xkcd.com/1409/
提取负载（E/L）：
我很惊讶有很多人似乎使用自定义Airflow操作符来执行E/L任务，而不是Spark。我认为这是Spark最大的优势之一：它有大量的连接器，可以读取/写入所有内容。它还可以对json和xml执行自动模式检测，而不会让人头疼。而且，正如Ari Bajo所指出的，最好使用中心状态（Spark）并具有O(n)连接器，而不是为每个源-目的地对写入O(n²)连接器。Spark可以做到这一切，我认为它的运行成本比Fivetran便宜得多（尽管我必须说，开源工具Airbyte可能是一个很好的选择）。Spark的安装成本可能更高，但一旦支付，复制和添加新的源/目的地不会花费很长时间。另一个优点是：Spark可以同时进行ETL和反向ETL。
的确，它确实需要非开发人员可以使用图形界面的开发人员。但我也有一种感觉，一个没有GUI的开发人员将无法调查和解决潜在的问题（但我可能错了）。
实时：
在我的团队中，我们开始将pySpark用于简单的实时案例（BigQuery中的原始数据摄入），但我对这个主题还不够了解，无法将其与其他替代方案（如lambda函数）进行比较。我们将注意到，由于其微批处理模式，Spark使我们能够非常容易地获得一次保证。
With explicit permission from xkcd: https://xkcd.com/1409/
结论
总之，我认为大多数这些考虑都围绕着一个中心点，这是SQL最大的优势，也是它最大的弱点：它的简单性。正是由于SQL的简单性，像BigQuery和Snowflake这样的平台才如此易于使用，而且它们的采用范围如此之广，同时降低了供应商锁定的风险。相反，这种简单性也是其最大的缺点，因为SQL很快就达到了极限，开发最佳实践更难应用，也不那么普遍。多亏了dbt和JINJA，其中一些不利因素可以得到缓解，但我相信，该行业将不得不走得更远，使用DataFrames或其他类似的API，帮助数据技术人员编写更通用、更高级的转换，并更好地满足不断增长的数据需求。
With explicit permission from xkcd: https://xkcd.com/1409/
在我的团队中，主要的挑战之一是我们倾向于在pySpark和BigQuery之间交替使用，以从每种工具的最佳功能中获益。这使得数据沿袭更加困难，因为dbt只允许我们可视化BigQuery部分，而我们的内部“dbt for pySpark”工具只允许我们查看pySpark部分。从长远来看，我希望BigQuery能够添加与pySpark（DataFrame API和Python UDF）相比所缺少的功能，这将使我们有一天能够将当前的pySparkTransformation迁移到BigQuery。pySpark方面剩下的只有E/L和实时数据处理。
With explicit permission from xkcd: https://xkcd.com/1409/
(A French version of this post is available here)
- 50 次浏览
【数据管道编排】2023年流行的5种开源数据管道编排工具
视频号
微信公众号
知识星球
数据编排工具位于数据基础设施的中心，负责处理所有的数据管道和ETL工作负载。选择开源数据编排工具很困难，因为你可以从中选择很多，而且每一个都有竞争性的功能。您必须选择与现有基础设施配合良好的工具，并且不需要重新设计所有内容。
以下是五种流行的开源数据编排工具的列表
- Airflow
- Dagster
- Argo
- Prefect
- Luigi
Airflow
Airflow概述
Maxime Beauchemin也是Superset的创始人，他于2014年在Airbnb工作时创建了Airflow。自2015年开源以来，Airflow就被广泛采用。一年后，爱彼迎将其移交给Apache软件基金会进行维护。自那以后，Airflow的受欢迎程度有所上升，PayPal、Twitter、谷歌、Square等巨头都在大规模使用它。
AWS和谷歌云都提供Airflow作为托管服务。Airflow在Astronomer中的商业化身提供了先进的部署方法和优先支持。这证明，所有形状和规模的企业都选择使用Airflow，而不是使用更传统的专有工具，如Control-M和Talend。
Airflow数据编排功能
Airflow将数据工程的世界引入了有向无循环图（DAG）。它是一种很少使用的图形数据结构，但在创建没有循环依赖关系的复杂工作流时非常适合。
Airflow的设计考虑了数据工程师和开发人员的观点。其想法是为Airflow提供灵活性和可扩展性，以便使用各种工具和技术。气流运营商就是这样一个例子。有几个内置运算符，但如果它们不能满足您的要求，您可以编写自己的运算符。
在发布时，一些高级功能是Airflow独有的，例如任务使用XComs相互通信的能力，尽管有一些限制。Airflow有趣的新功能和更新可能会帮助您了解它是否是适合您的数据编排工具。
Airflow资源
Documentation | Slack | Guides | StackOverflow | Ecosystem
Dagster
Dagster概述
GraphQL的创建者Nick Schrock创建了Dagster。他是数据产品公司Elementl的创始人，该公司在2019年年中进入开源世界之前负责Dagster的初步开发。
Dagster的使命是增强工程师、分析师和业务用户的测试、开发和整体协作体验，同时处理他们每天遇到的大量工具和技术。
Dagster在市场上相对较新，但包括Mapbox、VMWare、DoorDash等在内的许多公司都足够信任它的能力，可以在生产中使用它。
Dagster数据编排功能
Airflow极大地激励着达格斯特。Dagster试图解决Airflow的许多缺点，例如本地测试和开发、动态工作流和临时任务运行中的问题。
Dagster走了一条不同的道路，它更具流动性，更容易集成。它通过将抽象提升到存储和计算的下一个层次来实现这一点。为了增强任务相关性的清晰度，Dagster要求对Ops进行强类型化。这有助于高效缓存和IO的轻松交换策略。
对基于DAG的工作流模型的全新采用、易于使用的API以及许多其他功能使Dagster成为一个可行的替代方案。Dagster提供了与最流行的工具的轻松集成，如dbt、 Great Expectations、Spark、Airflow、Pandas等。它还提供了一系列部署选项，包括Docker、k8s、AWS和谷歌云。请查看下面列出的资源，以确定Dagster是否适合您的数据编排工具。
Dagster资源
Documentation | Slack | Tutorials | StackOverflow
Argo
Argo概述
Argo是一个开源的本地容器，用于数据编排。它在Kubernetes上运行，如果您的基础设施的很大一部分是云原生的，那么它是一个很好的选择。Applatix（一家Intuit公司）于2017年创建了Argo，以使Kubernetes生态系统更加丰富。
云原生计算基金会（CNCF）维护着这个开源项目。包括GitHub、特斯拉、WordPress、Ticketmaster和Adobe在内的数百家公司使用Argo进行ML和数据管道工作负载。
Argo功能
Argo是独一无二的，因为它是唯一真正通用的云原生数据协调器。与Airflow和Dagster类似，Argo也利用了DAG的力量。在Argo中，DAG的每个步骤都是一个Kubernetes容器。使用Kubernetes，Argo可以毫无困难地协调并行作业，同时允许您随着业务的增长线性扩展。
市场上其他数据编排工具与Argo的另一个区别是，Argo使用YAML而不是Python来定义任务。为了让您的工作更轻松，Argo提供了一个JSON模式，使您的IDE能够验证YAML文件中指定的资源。
Argo还允许您在Kubernetes上本地创建CI/CD管道，而无需安装任何其他软件。这篇引人入胜的帖子讲述了Arthur Engineering如何选择Argo而不是Prefect和Airflow，以及为什么选择Argo可能会帮助您找到合适的数据编排工具。
Argo数据编排资源
Documentation | Slack | StackOverflow | Argo Blog | Roadmap
Prefect
Prefect概述
早在2017年，许多工程师，其中一些人曾在Apache Airflow上工作，在确定并解决了他们所经历的痛点后，创建了Prefect。Prefect的核心理念是创建一个更灵活、可定制和模块化的工具，以满足现代数据堆栈的需求。
包括Slate、Kaggle、Microsoft、PositiveSum和ClearCover在内的许多公司都使用Prefect来处理其数据管道和编排工作负载。
Prefect数据编排功能
Airflow的一个显著缺点是无法进行参数化或动态DAG。Airflow在处理复杂的分支逻辑和特殊任务运行方面也遇到了困难。虽然Airflow中有解决这些问题的方法，但它们并不干净，也不可扩展。Prefect采用了一种新的数据编排方法，并解决了这些问题。
在Prefect中运行特别任务很容易，因为预取将每个工作流都视为可调用的独立对象，不受任何预定义计划的约束。预取还允许任务接收输入和发送输出，从而使相互依赖的任务之间更加透明。
Prefect最近推出了v2.0版本，提供了一系列令人兴奋的功能，如支持永久运行的管道、基于事件的工作流、工作流版本控制等。截至目前，这个新版本的Prefect正在测试版中。您仍然可以尝试v1.0，看看它是否与您当前的数据体系结构相匹配。
预取资源
Documentation | StackOverflow | Slack | Discourse
Luigi
Luigi概述
Luigi于2011年在Spotify开发，改进了一些现有的编排引擎，如Oozie和Azkaban，这些引擎是专门为Hadoop生态系统构建的。Luigi采用了一种更通用的方法，使您能够编排不同类型的任务，如Spark作业、Hive查询等。
目前尚不完全清楚有多少企业在积极使用Oozie，但它仍在积极开发中，并有相当多的使用量，因为最新版本v1.20.0最晚在2021年12月发布。
Luigi数据编排功能
Luigi是Airflow的前身，所以它没有DAG的概念。相反，它使用任务和目标语义来定义依赖关系。一个任务的输出进入目标的输入，目标本身可以是一个为另一个目标提供食物的任务，从而创建一个任务链。由于非DAG设计，在Luigi中开发具有许多依赖项和分支的高度复杂的管道将极其困难。
如果你想要轻量级的东西，管理所需的时间要少得多，那么Luigi可能是一个不错的选择。此外，当您的管道没有复杂的依赖关系时，可以考虑使用基于DAG的工具。要了解更多关于该工具的信息并决定它是否适合您，请访问他们的官方博客，查看一些最新版本的发布说明。
Luigi资源公司
Documentation | Blog | YouTube | Slack
列出的所有开源数据编排工具都是不错的选择。最适合您的将在很大程度上取决于您现有的数据堆栈和您的主要用例。
数据编排工具：相关阅读
- What is data orchestration: Definition, uses, examples, and tools
- Open source ETL tools: 7 popular tools to consider in 2023
- Open-source data observability tools: 7 popular picks in 2023
- ETL vs. ELT: Exploring definitions, origins, strengths, and weaknesses
- 10 popular transformation tools in 2023
- 705 次浏览