一条管道有哪些环节
典型的数据管道包含五个环节：采集从数据库、日志或接口把数据取出来；传输用消息队列或对象存储把数据送到加工位置；处理由批或流引擎完成清洗、关联与聚合；存储把结果落到数仓、数据湖或在线库；服务把结果以报表、接口或指标的形式交付给使用者。
三条支撑线
环节之外还有三条贯穿全链路的支撑线：调度负责依赖与重跑，质量负责校验与告警，监控负责延迟与积压。这三条线不做，链路平时看起来正常，一旦出问题就只能被动等待业务反馈。
基本信息
| 采集 | 从库、日志、API、文件拉取或接收数据 |
|---|---|
| 传输 | 消息队列或对象存储落地，起缓冲与解耦作用 |
| 处理 | 批/流引擎完成清洗、关联与聚合 |
| 存储 | 数仓、数据湖、在线库，按访问模式选择 |
| 服务 | BI 报表、数据接口、指标系统 |
| 支撑线 | 调度（依赖与重跑）、质量（校验）、监控（延迟与积压） |
典型链路示意
典型链路示意
# 主干：源 → 采集 → 传输 → 处理 → 存储 → 服务
源库/日志 → 采集（CDC 或 Agent）→ 消息队列 → 处理（批/流引擎）→ 存储（数仓/湖）→ 服务（BI/接口）
# 支撑线（贯穿每一段，不属于某一段）
调度：依赖编排、失败重试、按日期补数
质量：行数与分区校验、主键唯一性、勾稽对账
监控：采集延迟、队列积压、任务产出时间、SLA 达成率每段该看什么指标
| 环节 | 核心指标 | 异常表现 |
|---|---|---|
| 采集 | 抽取耗时、抽取条数、失败率 | 条数骤降，通常是对源库压力或权限问题 |
| 传输 | 队列积压、生产与消费速率差 | 积压持续上涨，下游时效退化 |
| 处理 | 任务耗时、失败次数、产出时间 | 窗口越跑越长，最终跑不完 |
| 存储 | 分区是否存在、文件数量与大小 | 分区缺失或小文件过多 |
| 服务 | 查询响应时间、接口成功率 | 报表变慢或接口报错 |
典型使用场景
- 新链路设计：先按五个环节画清边界，再决定每段用什么组件
- 故障定位：按「源端—采集—传输—处理—服务」逐段核对指标，快速收敛范围
- 容量规划：找出链路中最窄的一段，避免只扩容不瓶颈的那一段
- 值班交接：为每段定义可观测指标，交接时按指标判断是否健康
- 成本优化：识别长期闲置的传输跳数与冗余存储副本
端到端新鲜度由最慢的一段决定。链路上任何一段变慢，业务感受到的都是「数据没更新」，因此分段定义指标是值班与排障的基础设施，而不是可选项。
只监控最终任务的成功状态，不监控中间环节的积压与延迟：等最终任务失败才发现问题，往往已经晚了好几个小时，且无法判断瓶颈具体在哪一段。