明确ETL需求

在编写任何一行代码或在ETL工具中拖放任何组件之前，您需要清楚地知道自己究竟要实现什么。就像建造房屋需要蓝图一样，构建ETL流程需要一套清晰的需求。跳过这一步是项目延迟、预算超支以及最终未能提供用户实际所需数据的原因之一。

明确需求包括提出正确的问题，以弄清数据源、期望结果以及实现过程所需的步骤。可以将其视为在开始一项任务前收集信息。

为何要在需求上投入时间？

花时间提前定义需求能带来多项重要优势：

1. 目标明确： 确保所有参与者都理解ETL流程的目标以及为何要构建它。
2. 准确设计： 指导提取、转换和加载步骤的设计，确保最终的数据结构和内容符合需求。
3. 减少返工： 尽早发现误解或缺失信息，比之后修复已完成的流程成本低得多。
4. 实际估算： 有助于估算开发和维护所需的工作量、时间和资源。
5. 明智的工具选择： 需求（如数据量、转换复杂性、所需速度）会影响选择合适的ETL工具或技术。
6. 可测试性： 清晰的需求使得定义测试用例以验证ETL过程是否正确运行变得更容易。

收集需求的基本问题

为了给您的ETL流程奠定坚实基础，您需要通过提出具体问题来收集信息。以下是需要考察的基本方面：

1. 业务目标是什么？

这是“为什么”。您通过这些数据要解决什么问题或促成什么机会？

• 示例问题:
  • 这些数据将支持哪些业务决策？（例如：“我们需要查看各区域的每日销售总额以调整营销。”）
  • 哪些报告、仪表板或应用程序将使用这些数据？（例如：“这些数据将为主要销售业绩仪表板提供支持。”）
  • 最终数据应该能够回答哪些具体问题？（例如：“哪些产品的退货率最高？”）

理解目标为所有后续决策提供了背景信息。

2. 数据来自何处？(来源)

确定包含您所需数据的每个源系统。

• 示例问题:
  • 哪些系统存储原始数据？（例如：“我们的在线商店的PostgreSQL数据库”、“营销部门使用Salesforce”、“库存数据在FTP服务器的每日CSV文件中。”）
  • 我们如何访问每个来源？（例如：数据库凭据、API密钥、文件路径）。
  • 数据采用何种格式？（例如：关系表、API返回的JSON对象、定宽文本文件）。
  • 我们是否有权限访问这些数据？

3. 需要哪些具体数据？(范围)

通常，您不需要来自某个来源的所有数据。请明确具体范围。

• 示例问题:
  • 哪些具体的表、文件或API端点是相关的？
  • 这些来源中哪些列或字段是必需的？
  • 是否存在任何筛选条件？（例如：“仅限‘已完成’订单”、“北美客户”、“过去12个月的数据。”）

4. 数据需要如何改变？(转换)

这定义了ETL中的“T”。原始数据必须如何修改才能在目标系统中变得有用？

• 示例问题:
  • 清洗： 如何处理缺失值（例如：删除行、填充默认值、估算）？如何处理错误或异常值？
  • 格式化： 日期、数字或地址是否需要标准化？（例如：“将所有日期转换为 YYYY-MM-DD 格式。”）
  • 结构化： 数据集是否需要连接？（例如：“将客户数据与订单数据合并。”）数据是否需要拆分？（例如：“将地址组件拆分为街道、城市、省份。”）
  • 丰富： 我们是否需要添加信息？（例如：“计算利润率”、“根据产品ID查找产品类别。”）
  • 聚合： 数据是否需要汇总？（例如：“计算每日总销售额”、“统计每月独立客户数量。”）

5. 数据去向何处？(目标)

明确已处理数据的目的地。

• 示例问题:
  • 目标系统是什么？（例如：“一个Snowflake数据仓库”、“MySQL数据库中的特定表”、“Amazon S3中的文件。”）
  • 目标中期望的结构（模式）是什么？（例如：表名、列名、数据类型）。如果目标模式不存在，定义它属于需求的一部分。
  • 数据应如何加载？（例如：完全覆盖现有数据（全量加载）？添加新数据并更新现有记录（增量加载）？）

6. 数据需要多久更新一次？(频率与延迟)

确定ETL过程的时效要求。

• 示例问题:
  • ETL过程需要多久运行一次？（例如：每小时、每日凌晨3点、每周日、由事件触发）。
  • 源系统中事件发生与数据在目标中可用之间的可接受延迟是多少？（例如：“数据必须在1小时内可用”、“次日可用即可。”）

7. 数据量有多大？(数据量与速度)

估算数据流的大小和速度。

• 示例问题:
  • 初始数据加载的大约大小是多少？（例如：兆字节、吉字节、太字节）。
  • 每天/每小时/每周生成多少新数据？（例如：“每天大约10,000条新记录。”）
  • 数据是批量到达还是作为连续流到达？

这些答案会影响基础设施选择和处理策略。

8. 什么构成正确数据？(数据质量)

设定数据准确性和完整性的预期。

• 示例问题:
  • 数据必须满足哪些规则才能被视为有效？（例如：“订单总额必须为正数”、“电子邮件地址必须包含‘@’”、“产品ID必须存在于产品表中。”）
  • 未能通过验证的数据应如何处理？（例如：拒绝该记录、将其加载到错误表、标记以供审核、尝试修正）。

9. 谁需要访问权限以及规则是什么？(安全与合规)

考虑数据保护和用户访问。

• 示例问题:
  • 是否存在任何敏感数据元素（个人身份信息 - PII）？
  • 是否存在适用的监管要求（如GDPR、HIPAA、CCPA）？
  • 目标数据的最终用户是谁，他们需要哪些权限？

记录您的发现

不仅仅是提出问题；还要记下答案！需求应清晰记录并与所有相关方（业务用户、开发人员、分析师）共享。这份文档将成为开发和测试的参考点。对于简单项目，它不需要过于正式；一份清单或结构化文档通常足够。

下图说明了这些不同的调查领域如何共同促成需求文档的创建。

此图显示了涉及信息收集的主要问题类别，它们都共同促成了最终的ETL需求文档。

简单示例：每日销售汇总

让我们将这些问题应用于一个基本场景：创建按产品类别划分的每日总销售额汇总报告。

• 目标： 为销售经理提供每日快照，查看哪些产品类别表现最佳。
• 来源： 一个名为orders_YYYYMMDD.csv的单CSV文件（每日生成），包含order_id、product_id、quantity、price_per_item。一个单独的products.csv文件（不经常更新），包含product_id、category。
• 范围： 每日订单文件中的所有记录。产品文件中的product_id和category。
• 转换：
  • 针对每行订单计算total_sale（quantity * price_per_item）。
  • 将每日订单数据与产品数据通过product_id连接，以获取category。
  • 按category聚合total_sale。
  • 将输出格式化，包含category和total_sales_amount列。
• 目标： 一个名为daily_category_summary_YYYYMMDD.csv的新CSV文件。
• 频率： 每日orders_YYYYMMDD.csv文件到达后，每日运行一次。
• 数据量： 订单文件每日大约5MB（约50,000行）。产品文件较小（1MB）。
• 质量： quantity和price_per_item必须是正数。订单文件中的product_id必须存在于产品文件中（对于此简单情况，忽略包含未知产品的订单行）。
• 安全： 不涉及个人身份信息。销售经理需要对输出文件有读取权限。

即使是这种简单情况，回答这些问题也能大大明确任务。随着ETL流程变得更复杂，涉及更多来源、复杂的转换和更严格的性能要求，这种结构化方法变得不可或缺。投入时间理解并记录需求是构建高效可靠ETL流程的第一步，也是必要一步。