数据工程ETL或ELT中的转换与提取加载，会议、博客文章、企业路线图甚至预算都侧重于数据转换T以及随之而来的“业务洞察”的诱惑。对于提取和加载数据EL的步骤有时会被打折为编写脚本和计划一些 API 调用的微不足道的步骤。

然而，提取加载EL的优雅不仅仅是结果，而是执行 – 保证不会出错的艺术。正如室内装饰无法挽救在运输过程中损坏的画作，或者如果一半的用料缺货，则无法准备精心计划的菜单一样。数据处理的提取加载EL步骤有无数的陷阱，可能会使数据团队远离他们雄心勃勃的议程和愿望。基础不牢地动山摇。

这篇文章是解释提取加载的一些潜在复杂性的系列文章中的第一篇。了解这种复杂性说明了像Airbyte这样的数据集成工具如何通过减少认知负担，加快开发时间，降低未来错误和中断的风险，并让他们专注于组织特定的问题来减轻数据团队的负担。

这篇文章将从开头开始：从上游源系统中提取数据。就像节俭地用每周优惠装满您的购物车或小心翼翼地装载移动的货车以保护您的物品一样，我们将探索全面而有效地提取数据所需的策略。

数据提取基础知识

所有 EL 管道都从某个源系统提取数据开始。Airbyte 提供了一个方便的抽象层，用于从许多类型的系统中提取数据。为了集中讨论，我们将重点关注REST API，因为它们是与上游供应商工具（例如Facebook Ads，Salesforce）集成时最常见的来源之一。

从 API 成功提取数据涉及制定精确的 API 查询并大规模执行该查询。这些步骤中的每一个都可能带来许多不同的挑战，这些挑战可能会使数据团队花费宝贵的时间来编写样板代码，或者危及结果的准确性和完整性。我们将逐一研究其中一些关键问题。

制定 API 查询

尽管 REST API 无处不在，但每个 API 的结构都存在许多任意的唯一性。如果没有适当的注意，很容易遇到错误消息或检索误导性结果，这些结果正是您所要求的，但根本不是您想要的。

认证

API 保护身份验证层后面的机密数据。API 开发人员可以启用许多不同的身份验证策略。其中包括基本身份验证（未加密的凭据传递）、API 密钥和现代 OAuth2 方法，这些方法通常需要在长时间运行的会话期间多次检索临时刷新令牌。

然后，身份验证要求数据团队编写死记硬背的 API 特定代码，对于 OAuth2，可能需要在检索新刷新令牌和进行实际数据收集 API 调用之间进行迭代。如果没有构建正确的健壮性和迭代层，此类超时可能会导致对 API 的长时间运行或顺序调用出现意外故障。

凭据保护

无论使用哪种身份验证模式，都需要将某种类型的凭据传递给 API。与个人密码一样，必须小心处理此类凭据。安全性可以采用各种不同的方法，例如将凭据存储为环境变量与硬编码。

但是，虽然大多数技术人员都知道不要以纯文本形式保留密码，但这并不是您在进行 API 调用时无意中危及网络安全的唯一方法。更简单的身份验证方法可能会泄露您的凭据，除非您确定通过安全连接提交呼叫;其他时候，严格的日志记录可能会意外地泄露凭据并引入泄漏，从而允许不良行为者访问您的系统。

导航端点

数据团队应该在了解他们打算从 API 检索哪些数据以及要应用哪些查询参数方面发挥积极作用。但是，他们可能经常面临大量选项和共享连接器，允许“人群的智慧”突出显示最常见的端点和感兴趣的参数。

尽管“我们甚至无法定义客户”是数据中的陈词滥调，但在收集可能使用不同命名法的外部数据时，组织内存在的相同类型的歧义会被放大。使用常用工具有助于突出显示最重要的信息，并有助于捕获数据团队可能无法预料的极端情况。例如，您是否知道 GitHub API 将拉取请求视为一种问题？

结构化查询和有效负载

因此，一旦您证明您有权访问信息（身份验证）并确定您希望访问哪些信息（端点），您如何有效地要求 API 检索它？

即使是像查询 API 这样司空见惯的任务也可能包含任意唯一性，并引入数据团队检索错误结果的风险。例如，将多个可能的值传递给单个查询参数可能不是简单的，并且特定于 API。一些 API 更喜欢像 ？key=value1&key=value2 这样的格式，而另一些 API 则期望 ？key=value1，value2。

使用意外格式可能会导致 API 错误，或者更糟糕的是，当查询被误解时，会导致静默失败。对于那些来自SQL类型语言的人来说，其中一些结构可能不直观;例如，尽管上面显示的第一个选项中有 & 符号，但两种语法都在结果中请求“要么或”而不是“两者和”值。

大规模查询 API

因此，您有一个有效的 API 查询！这很好，但进行一次成功的调用与大规模查询 API 以定期提取大量数据大不相同。除了 API 查询中的业务逻辑之外，分析工程师可能会发现自己需要调整其代码以应对以下挑战：

分页

通常，API 查询的结果可能是大量记录。为了更有效地传输此数据，API 使用分页来返回结果的离散子集。从本质上讲，分页是将查询返回的一组记录分解为不同的块，并且每个 API 请求只返回一个的过程——类似于 Google 搜索将结果分解到多个页面上的方式。例如，如果您的查询有 120 条相关记录，则您的第一次 API 调用可能会返回前 50 条记录。要获得下一个 50（在第二个“页面”上），需要另一个 API 调用。

虽然这使得检索查询结果更有效，但数据工程师通常必须编写样板代码来确定是否存在更多记录并重复检索下一组。否则，数据团队可能会面临提取不完整记录的风险。

重试

即使是正确的 API 查询也可能由于系统中断和网络问题等临时问题而失败。进行 API 查询后，需要检查返回的状态码，确认命中是否成功。如果不是，系统需要决定如何处理此错误以及是否再次尝试调用。

重试和分页的交集会产生进一步的数据收集丢失风险。例如，如果您以迭代方式调用 API 来检索结果的下一个“页面”，只要存在下一页，即使“第 4 页”失败，朴素的 for 循环也可能会继续查询“第 3 页”。

速率限制

重试和分页都会造成需要多次调用 API 才能成功提取的情况。但是，为了防止暴力帐户接管和拒绝服务攻击，API 通常具有速率限制，该限制决定了给定时间段内允许的最大查询数。弹性提取过程应认真遵守速率限制，并实施重试回退等方法。

总结

正如这篇文章所说明的，数据收集可能需要大量的专业知识——既包括一般查询数据，也包括每个 API 的具体细微差别。获取和部署这些知识可能会占用数据团队的大量带宽。数据团队可以“租用”像Airbyte这样的提取工具，而不是让团队成员重新发明轮子。Airbyte 的源连接器封装了工程最佳实践和特定领域的知识，以帮助应对上述风险。在单个连接器（例如亚马逊广告）的文档上，您会发现对上述许多问题的详细讨论，例如如何提供连接器将适当传递给 API 的凭据，以及哪些终端节点包含跨行业最普遍有用的信息。

即使 Airbyte 还没有适用于您的用例的现有连接器，它也为数据团队提供了有用的样板框架，以创建应用其中一些相同最佳实践的新连接器。例如，可以轻松配置不同的分页策略，而无需使用样板代码重新发明轮子。

仅仅因为您可以自己打包一辆搬家的货车，没有人会拒绝朋友或搬家公司的帮助，以使手头的工作更安全、更快、更愉快。通过在上述无数决策、痛点和陷阱上提供统一的抽象层，像 Airbyte 这样的优秀 EL 工具可以为您的数据团队带来相同的价值。