数据管道架构图示例

以下示例展示了不同规模的团队如何根据数据量、延迟要求和团队规模来构建数据栈，帮助你找到和自己情况最匹配的参考方案。

真实案例

使用场景: 处理每日百万级订单的中型电商数据工程师

数据源：MySQL（订单/商品）、Kafka（点击流）、Stripe Webhook、S3（应用日志）

摄入：Debezium CDC → Kafka；Kafka Consumer → S3 原始区

转换：每小时 Spark 批处理；dbt 模型将 raw 转为 analytics

质量：Great Expectations 检查行数、空值率、营收总额

数仓：Snowflake，分 raw / staging / analytics / marts 层

服务：Metabase 仪表板、Feast ML 特征、内部数据 API

治理：dbt docs 作为数据目录，Monte Carlo 做异常检测

这样组织的原因: 在数仓中将 raw、staging 和 analytics 分层意味着转换作业出错只影响该层的下游消费者——原始数据保持完整，可以在不重新摄入的情况下重新处理。

使用场景: 构建亚秒级欺诈评分系统的金融科技高级数据工程师

数据源：通过 Kafka 的交易事件（1 万 QPS）

流处理：Flink 有状态聚合（用户速率、商户风险）

特征存储：Redis 实时特征服务（< 5ms 查找）

ML 推理：ONNX 模型通过 gRPC 服务（< 20ms）

输出：Kafka Topic → 交易审批服务

批处理路径：每日用 Spark + Snowflake 历史数据重新训练

这样组织的原因: 在同一张图中同时展示实时路径和批量重训路径，帮助评审者理解模型质量同时依赖流式特征的新鲜度和批量训练数据的质量——两种失效模式需要不同的监控策略。

使用场景: 30 人 SaaS 初创公司的第一位数据工程师

数据源：PostgreSQL（业务数据库）、Stripe API、HubSpot API

摄入：Fivetran 托管连接器（无需自定义代码）

转换：dbt Cloud，每 6 小时运行一次

数仓：BigQuery（按查询计费，固定成本低）

服务：Looker Studio 仪表板、面向销售团队的 CSV 导出

无流处理、无特征存储、无自定义目录——目前不需要

这样组织的原因: 初创公司的架构图要故意展示"缺少什么"——没有 CDC、没有 Kafka、没有实时——传达当前数据栈是根据数据量和团队规模量身定制的，而不是出于省钱妥协。

回到模板页，直接替换成你的课程主题、章节和复习重点，就可以继续使用这套结构。