提取数据听起来很简单，但在实际操作中，事情并非总是一帆风顺。你连接的系统可能不在你的直接控制范围，需要处理网络问题，并且读取的数据格式也可能发生变化。在提取阶段几乎不可避免地会遇到问题。规划这些潜在问题是构建可靠ETL过程的重要组成部分。
考虑一下当你尝试从数据库、文件服务器或API等源获取数据时可能出现的问题：
- 数据源不可用： 数据库服务器可能正在维护，网络连接可能暂时中断，或者文件服务器可能已离线。
- 凭据或权限不正确： 你可能使用了错误的用户名/密码，或者你的ETL过程使用的账户可能没有读取所需特定数据的必要权限。
- 数据格式意外变化： 想象一下，你预期一个CSV文件有五列，但今天它有六列，或者列名发生了变化。又或者JSON响应中的某个字段缺失或数据类型与预期不同。这有时被称为“模式漂移”。
- 数据缺失或损坏： 源文件可能为空、不完整或包含无法正确读取的损坏数据。
- 超时： 源系统响应可能很慢，导致你的提取过程等待太久后放弃。
- 资源限制： 一些数据源，特别是API，可能会限制你可以请求的数据量或请求频率（速率限制）。超出这些限制可能导致错误。
忽视这些潜在问题意味着你的ETL流程会很脆弱；它可能会意外失败，导致目标系统中的数据不完整或过时。让我们来看看一些基本的策略来妥善处理这些情况。
记录日志：你的第一道防线
你至少应该做的是记录提取过程中发生的事情。记录日志意味着将关于过程执行的信息记录到一个文件或专门的日志系统中。
- 记录什么： 至少，记录提取何时开始、何时成功完成，以及特别是何时失败。如果发生错误，记录详细信息：哪里出了问题，涉及哪个数据源，以及收到的任何错误消息。
- 为何记录： 日志提供了事件的记录。当提取在夜间失败时，日志通常是诊断问题的唯一方法。它们帮助你判断错误是暂时的故障还是需要调查的长期问题。
良好的日志会告诉你出错了；下一步是决定如何处理。
重试失败尝试
有些错误是暂时的。短暂的网络中断或数据库服务器重启可能导致提取失败，但稍后再试一次可能会成功。这就引出了重试操作的策略。
- 简单重试： 最基本的方法是在提取失败时立即再次尝试。这适用于非常短期的瞬时问题。
- 带延迟重试： 通常，最好等待一小段时间后再重试。如果源系统暂时过载，立即重试可能只会加重问题。等待可以给系统恢复的时间。
- 指数退避（更智能的延迟）： 一种常用技术是增加重试之间的延迟。例如，第一次失败后等待5秒，第二次后等待10秒，然后20秒，依此类推。如果源系统出现问题，这种方法可以平稳地“退让”。通常你会设置一个最大重试次数，以避免无限期地尝试。
重试对于连接问题和超时特别有效。它们无法解决诸如权限不正确或数据格式从根本上损坏的问题。
失败警报
如果提取反复失败，即使在重试之后，也需要有人知道此事以便进行调查。这就是警报或通知的作用。
- 方式： 当一个重要提取失败且无法自动恢复时，这可以简单到发送一封电子邮件或一条消息到聊天系统（如Slack）。
- 时间： 通常在重试用尽后，或者对于重试无法解决的错误（如认证失败）发送警报。
警报确保长期存在的问题不会被忽视。
决定如何处理不良数据（跳过或失败）
有时，连接正常，但特定记录或文件存在问题。例如，一个大型CSV文件中的一行数据可能格式不良。你有以下选择：
- 使整个提取失败： 如果数据质量非常重要，并且任何错误都无法接受，你可能会选择在即使只有一条记录有问题时也停止整个过程。这可以防止潜在的损坏数据向下游传输。
- 跳过不良记录/文件： 如果偶尔出现不良记录可以接受或符合预期，你可以记录错误，跳过有问题的记录或文件，然后继续提取其余数据。这能保持管道运行，但需要仔细考虑数据缺失的影响。
- 隔离不良数据： 一种更高级的做法是将有问题的数据移动到一个单独的“隔离区”，以便后续检查和可能的S手动修正。
正确的选择取决于你的ETL过程的具体要求以及每条数据的重要性。
可视化简单的错误处理流程
此图显示了一个带有日志记录和重试的基本流程：
此图显示了一种常见模式：尝试提取，检查是否成功。如果成功，很好。如果失败，记录错误，查看是否还有重试次数。如果是，等待片刻并再次尝试。如果没有更多重试次数，则通知相关人员并停止。
处理提取错误可能看起来是额外的工作，但它是构建弹性且可信赖的ETL流程的根本。通过预见常见问题并实施日志记录、重试和警报等基本策略，你可以显著提高数据提取过程的可靠性。
