跳到主要内容

数据管道设计模式

问题​

数据管道有哪些设计模式？如何保证幂等性和数据质量？

答案​

三种处理模式​

模式延迟代表工具适用场景
批处理T+1（小时/天）Hive、Spark（批）离线报表、数据仓库
微批处理秒~分钟Spark Structured Streaming准实时指标
流处理毫秒~秒Flink、Kafka Streams实时风控、实时看板

幂等性设计​

幂等性：同一任务重跑多次，结果不变。

策略做法适用
OVERWRITE写入前清空目标分区Hive 分区覆盖
UPSERT按主键更新/插入ClickHouse、Doris
去重上游去重后再写入Flink 窗口去重
唯一约束数据库唯一索引MySQL/PG
-- Hive 分区覆盖（天然幂等）
INSERT OVERWRITE TABLE dws.user_daily PARTITION(dt = '2024-01-15')
SELECT user_id, COUNT(*) AS action_cnt
FROM dwd.user_action
WHERE dt = '2024-01-15'
GROUP BY user_id;
关键原则

ETL 任务必须设计为幂等的——因为失败重跑是常态，不是异常。

数据管道监控​

监控项指标告警阈值
时效性任务完成时间超过 SLA 时间
数据量输入/输出行数波动超过 ±30%
空值率关键字段空值占比> 5%
一致性上下游数据量差异> 0.1%

常见面试问题​

Q1: 如何保证 ETL 任务的幂等性？​

答案：

  • 分区覆盖：INSERT OVERWRITE PARTITION 是最简单的幂等策略
  • UPSERT：按主键做 MERGE INTO 或 INSERT ... ON DUPLICATE KEY UPDATE
  • 先删后写：DELETE + INSERT 在事务中执行
  • 唯一约束 + 忽略冲突：INSERT IGNORE 或 ON CONFLICT DO NOTHING

Q2: 数据管道失败了怎么办？​

答案：

  1. 告警通知（钉钉/邮件/PagerDuty）
  2. 定位原因（日志 + Airflow UI + 数据源检查）
  3. 修复问题（代码/配置/数据源）
  4. 重跑任务（幂等设计确保安全重跑）
  5. 补数：如果影响了下游，从失败节点向下全部重跑

Q3: 批处理和流处理如何选择？​

答案：

  • 看延迟要求：T+1 用批处理，秒级用流处理
  • 看成本：流处理资源常驻消耗高，批处理按需启停
  • 看复杂度：简单聚合两者皆可，复杂 SQL 批处理更成熟
  • 趋势：流批一体（Flink SQL）是未来方向

相关链接​