etl介绍与etl工具比较
人们通常会低估ETL设计，并从一个简单的想法开始，然后这个想法逐渐发展为包含其他功能和转换，直到最终变得非常混乱。 用手指交叉睡觉时，这会导致IT头疼，一切都会正常进行。 这样的ETL看起来像这样：
有一些要求可以帮助维护ETL：
- 能够重新启动/恢复过程
- 有关执行历史和问题的结构化信息
- 外部配置
- 监控API
- 轻松恢复故障
为了实现上述所有目标，我们可以遵循一些步骤。
ETL原子性
这只是将我们的ETL分解为小型独立工作的幻想。 这是实现目标的最重要要求。 简单的工作易于理解，易于更改且易于维护。 我知道我们大多数人可能仍然认为他们会这样做，但是根据我在一家定制软件开发公司的经验，它经常被忽略。 让我们看下面的例子：
它看起来很简单，但是如果您需要在不加载表2的情况下执行它呢？ 您需要重新创建作业并部署新版本。 或者，当由于数据库崩溃而导致表3加载失败时，您将重新启动所有内容，而不是仅加载该表。
想象一下，如果该工作被分解成一些小的幂等工作，例如：
从FTP载入
和3个负载表作业（可以是通过参数重用的同一作业）
（请注意放置表和装入数据在同一作业中的状态。我们不想将它们分成两部分，因为装入数据将不再是幂等的，如果我们运行两次，则将使行数加倍）
可配置执行
现在，当我们的ETL流程由许多小的原子作业组成时，我们需要一种执行它们的方法。 一个简单的解决方案是将它们全部链接在一个主作业中，但这不是很灵活，并且不允许我们轻松配置它。 更好的方法是创建一个主任务，该任务从外部配置读取所需的作业并执行它们。 这样，我们可以修改执行流程，而无需重新部署ETL，也无需修改代码。
一个简单的YAML存储配置对于一个小型项目可能就足够了。 但是为了使其灵活并能够扩展它，可以使用数据库。 在我们的示例ETL中，拥有两个表可以很简单。 版本控制将用于保留正确的执行历史记录：
我们的主要工作可以是：
维护执行流程历史记录
搜索大ETL的日志文件可能是一场噩梦。 由于我们已经有一个专用于ETL的数据库，因此可以轻松地扩展主任务以跟踪执行流程。 这样，我们的工作就不必担心日志记录和故障处理（请记住，它们是执行简单工作的很小的原子代码段）。 因此，让我们在该数据库中添加另外两个表：
每次运行ETL时，我们都会读取当前版本的必需作业，在ETL Execution Runs表中添加一条记录，并在ETL Run Jobs表中添加所有计划的作业的记录。 这使我们（和我们的主任务）可以轻松跟踪执行情况。 我们还具有有关以前的ETL运行及其工作，时间，状态等的信息。主任务负责处理这些表并控制过程。 我们可以通过添加用于元信息的其他字段（或其他表）来扩展该字段，例如加载的行，已处理的文件等。
将ETL执行引擎与ETL解耦
现在，当我们将ETL作为小型作业的结构化列表以及数据库的主任务来跟踪执行情况时，我们可以轻松地看到这两个不需要耦合在一起。 这样的主任务可以运行由不同工作组成的不同ETL，并保持其正常运行。 它只是简单的“ ETL服务器”的示例，但要使其成为真正的服务器还需要做一些其他事情。
- 首先，它需要一个简单的API，以便更轻松地访问有关执行运行的信息并控制这些执行运行。 对于管理员来说，它可以是简单的CLI，甚至可以是更好的Web服务，以允许不同的用户访问和操作。 最后，即使没有访问服务器，也应该很容易查看ETL的状态并继续/重新启动/停止。 数据库具有查看哪个步骤失败所需的所有信息，并且我们已经创建了幂等步骤，因此可以重新启动它们。
- 我们需要一种简单的方法来部署新的ETL。 有很多可能性，但是归结为提供包含作业和配置的软件包。
一个简单的包装是一个包含所有作业的.zip文件和一个位于根文件夹中的config.yml文件。 当我们的服务器获取到etl.zip时，它可以部署它，安排它并开始执行它。 ETL开发人员不需要知道服务器的工作方式，只需要以约定的格式描述流程即可。
结论
现在，有了基本知识后，就可以扩展服务器以使其可以投入生产了。 一遍又一遍地用不同的ETL处理相同的问题后，我确信它可以做得更好。 我们从上述步骤完全开始，甚至对于一个简单的ETL甚至是非常相似的表结构，都从此开始。 最后，我们最终获得了可运行生产的服务器，该服务器运行多个ETL，并具有易于监视，故障恢复以及企业级客户所需的所有其他功能。 这里的示例是在Pentaho Data Integration中制作的，但是相同的基本原理适用于所有工具 。
如果您有任何疑问，请随时询问，并分享建议！
翻译自: https://hackernoon.com/how-to-design-scalable-and-maintainable-etls-bfd1664211a7
etl介绍与etl工具比较