在编写任何一行代码或在ETL工具中拖放任何组件之前，您需要清楚地知道自己究竟要实现什么。就像建造房屋需要蓝图一样，构建ETL流程需要一套清晰的需求。跳过这一步是项目延迟、预算超支以及最终未能提供用户实际所需数据的原因之一。
明确需求包括提出正确的问题，以弄清数据源、期望结果以及实现过程所需的步骤。可以将其视为在开始一项任务前收集信息。
为何要在需求上投入时间？
花时间提前定义需求能带来多项重要优势：
- 目标明确： 确保所有参与者都理解ETL流程的目标以及为何要构建它。
- 准确设计： 指导提取、转换和加载步骤的设计，确保最终的数据结构和内容符合需求。
- 减少返工： 尽早发现误解或缺失信息，比之后修复已完成的流程成本低得多。
- 实际估算： 有助于估算开发和维护所需的工作量、时间和资源。
- 明智的工具选择： 需求（如数据量、转换复杂性、所需速度）会影响选择合适的ETL工具或技术。
- 可测试性： 清晰的需求使得定义测试用例以验证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必须存在于产品表中。”）
- 未能通过验证的数据应如何处理？（例如：拒绝该记录、将其加载到错误表、标记 (token)以供审核、尝试修正）。
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流程的第一步，也是必要一步。
