2. 数据流水线架构基础：批处理与流处理架构、ETL与ELT模式、Lambda与Kappa架构对比
2.1 批处理与流处理架构
数据流水线的处理模式决定了系统的延迟、吞吐量和一致性模型。工程分析场景下，批处理与流处理并非互斥，而是根据数据特征与业务需求选择不同的时间窗口与计算策略。
| 维度 | 批处理 (Batch Processing) | 流处理 (Stream Processing) |
|---|---|---|
| 数据范围 | 有界数据集（如一天的历史日志） | 无界数据流（如实时传感器读数） |
| 延迟 | 分钟级到小时级 | 毫秒级到秒级 |
| 触发方式 | 时间调度（Cron）或数据量阈值 | 事件驱动（每条记录到达即处理） |
| 典型引擎 | Apache Spark Batch, Hive, MapReduce | Apache Flink, Kafka Streams, Spark Streaming |
| 一致性 | 强一致性（Exactly-Once） | At-Least-Once / Exactly-Once（需状态后端） |
| 资源特征 | 高吞吐、长周期、可弹性伸缩 | 低延迟、持续运行、资源预留 |
工程分析选型建议： 对于设备故障诊断、质量趋势分析等非实时场景，优先采用批处理以降低运维复杂度；对于产线异常告警、实时能耗监控等场景，必须引入流处理引擎。
批处理与流处理融合趋势： 现代数据平台（如 Apache Beam、Spark Structured Streaming）提供统一的 API 抽象，允许同一套业务逻辑在批模式和流模式下运行，减少架构割裂。
2.2 ETL 与 ELT 模式
数据流水线的核心环节是数据从源系统到目标系统的转换过程。ETL（Extract-Transform-Load）与 ELT（Extract-Load-Transform）代表了两种不同的处理哲学，直接影响流水线的资源规划与参数调优策略。
| 对比维度 | ETL（先转换后加载） | ELT（先加载后转换） |
|---|---|---|
| 处理位置 | 在中间处理层（ETL Server / Spark）完成转换 | 在目标数据仓库/数据湖内完成转换 |
| 存储需求 | 需要临时存储区（Staging Area） | 直接加载到目标系统，利用其计算能力 |
| 适用场景 | 数据质量要求高、源系统性能受限 | 目标系统计算资源充足、数据量极大 |
| 典型工具 | Informatica, Talend, AWS Glue | dbt, Snowflake, BigQuery, Databricks |
| 参数调优重点 | 转换并行度、内存分配、Shuffle 分区 | 目标系统集群大小、查询并发、物化策略 |
常见误区： 在工程分析数据平台中，ELT 并非总是优于 ETL。当原始数据包含大量敏感信息或需要复杂清洗逻辑时，ETL 的提前转换可以降低目标系统的安全风险与计算负载。
2.3 Lambda 与 Kappa 架构对比
Lambda 架构和 Kappa 架构是数据平台领域两种经典的架构模式，分别对应不同的容错、延迟和开发复杂度权衡。工程分析数据平台在选择架构时，需要综合考虑数据源特征、查询模式与运维能力。
| 对比维度 | Lambda 架构 | Kappa 架构 |
|---|---|---|
| 核心思想 | 批处理层 + 速度层 + 服务层 | 统一流处理层，批处理视为流处理的特例 |
| 代码维护 | 两套代码（批处理逻辑 + 流处理逻辑） | 一套代码（流处理逻辑） |
| 数据一致性 | 批处理层保证最终一致性，速度层补偿实时性 | 通过重放数据流保证一致性 |
| 运维复杂度 | 高（需维护两套流水线） | 中（需维护流处理引擎与消息队列） |
| 适用场景 | 对历史数据回溯要求高、实时与离线结果需合并 | 数据源为可重放的消息队列，实时性要求高 |
| 典型实现 | Spark Batch + Spark Streaming + HBase | Kafka + Flink + 对象存储 |
工程分析场景推荐： 对于设备历史数据回溯与实时告警并存的场景，Lambda 架构仍是成熟选择；若数据源已全面 Kafka 化且团队具备流处理能力，Kappa 架构可显著降低运维成本。
2.4 架构选型决策要点
在工程分析数据平台中，架构选型直接影响后续的参数调优方向与资源规划策略。以下决策要点可作为评估框架：
- 数据源特征： 若数据源为有界文件（如 CSV、Parquet 快照），优先批处理 + ETL；若为无界消息流（如 Kafka Topic），优先流处理 + ELT。
- 查询延迟要求： 秒级响应需求驱动流处理架构引入；分钟级响应可接受时，批处理架构更稳定。
- 团队技术栈： 熟悉 Spark 生态的团队更适合 Lambda 架构；熟悉 Flink + Kafka 的团队更适合 Kappa 架构。
- 数据一致性需求： 需要 Exactly-Once 语义且允许一定延迟时，批处理层提供强一致性；流处理层需配合状态后端与幂等写入。
- 资源规划影响： Lambda 架构需要为批处理层和速度层分别规划资源，资源利用率较低；Kappa 架构资源集中，但流处理引擎需持续运行，预留资源要求高。