电商数据 ETL 管道搭建：从平台 API 到数仓的 6 层架构

多平台卖货的第一天，你就会发现数据是散的：

• 天猫后台一套；
• 抖音后台一套；
• 京东后台一套；
• 客服工单在飞书 / 企微；
• 物流信息在 SaaS。

这些数据一旦要跨平台对齐分析，就得"拉"出来。**ETL（Extract → Transform → Load）**管道就是干这个的。

整体 6 层架构

┌────────────────────────────────────────────────────┐
│                  6. 应用层（BI / API）               │
├────────────────────────────────────────────────────┤
│                 5. 指标层（Metrics）                 │
├────────────────────────────────────────────────────┤
│               4. 维度建模层（DWB/DWS）                │
├────────────────────────────────────────────────────┤
│              3. 数据集成层（ODS / Stage）             │
├────────────────────────────────────────────────────┤
│              2. 数据清洗层（CDM）                     │
├────────────────────────────────────────────────────┤
│           1. 数据接入层（Sources / Sinks）            │
└────────────────────────────────────────────────────┘

层 1：数据接入

数据源类型

• API 拉取：平台商家后台 API（天猫开放平台、巨量、京东商家）；
• 文件下载：CSV / Excel 定时导出；
• 数据库同步：MySQL / MongoDB / SQL Server 业务库；
• 日志采集：网站 / App 埋点；
• 第三方工具：SaaS 导出。

工具选择

• API 编排：Apache Airflow、Dagster、Prefect；
• 变更数据捕获（CDC）：Debezium、Canal；
• 埋点：神策、GrowingIO、自建 Kafka。

接入频率

数据类型	频率
订单数据	5-15 分钟
流量数据	30 分钟 - 1 小时
广告数据	1-2 小时
库存数据	实时 / 5 分钟
客服数据	每日

层 2：数据清洗

做什么

1. 格式规范化：

   • 日期统一 YYYY-MM-DD；
   • 手机号脱敏；
   • 金额单位统一（分 vs 元）。

2. 缺失处理：

   • 空值填默认值；
   • 业务关键字段缺失 → 记录异常表。

3. 异常过滤：

   • 订单金额负数 → 记录；
   • 重复订单 → 去重；
   • 测试数据 → 过滤。

4. 数据校验：

   • 主键唯一性；
   • 外键完整性；
   • 业务规则（如订单金额 = sum(商品金额) - 优惠）。

工具

• SQL：在数仓里直接处理；
• DBT (Data Build Tool)：主流的变换工具；
• Pandas / PySpark：Python 处理；
• Apache Spark：大数据量。

层 3：数据集成（ODS / Stage）

特点

• 原始数据 + 已清洗；
• 按"平台 + 业务"分表（如 ods_tmall_orders、ods_douyin_orders）；
• 保留所有字段，不做合并。

命名规范

• 表名：ods_{平台}_{业务}；
• 字段：原始字段名 + 注释；
• 分区：按 dt 日期。

保留时长

• 详细数据：180 天 - 3 年；
• 汇总数据：永久。

层 4：维度建模（DWB / DWS）

维度（DIM）

• dim_sku：商品维度；
• dim_user：用户维度；
• dim_channel：渠道维度；
• dim_date：日期维度。

事实（FACT）

• fact_order：订单事实表（按订单粒度）；
• fact_traffic：流量事实表（按 UV / PV 粒度）；
• fact_ad：广告事实表（按广告 + 日期粒度）。

汇总（DWS）

• dws_sku_day：商品日汇总；
• dws_channel_day：渠道日汇总；
• dws_user_month：用户月汇总。

建模方法

• Star Schema（星型模型）：主流，易懂；
• Snowflake Schema（雪花模型）：复杂层级；
• Data Vault：大型企业定制。

层 5：指标层

什么是"指标层"

标准化的业务指标定义，供 BI / 应用统一引用。

示例指标

指标	口径	SQL 示例
GMV	订单金额	SUM(order_amount)
成交	已付款	SUM(paid_amount)
毛利率	(GMV - 成本) / GMV	-
UV	唯一访客	COUNT(DISTINCT user_id)
CVR	订单 / UV	-

工具

• LightDash / Metabase：开源；
• Cube.dev：开源 / 商业；
• DBT Semantic Layer；
• 自研服务层（Spring Boot + 缓存）。

层 6：应用层

BI 工具

• FineBI、QuickBI、帆软；
• Tableau、Power BI；
• Superset、Metabase（开源）。

API 应用

• 广告系统（自动出价）；
• 会员系统（精准营销）；
• 客服系统（订单信息展示）；
• 供应链（库存预测）。

工具选型组合

方案 A：小规模（月订单 < 1 万）

• 数据源：API + Excel 导出；
• ETL：Python 脚本 + Airflow；
• 数仓：PostgreSQL / MySQL；
• BI：Metabase；
• 成本：云服务器 2000/月。

方案 B：中规模（月订单 1-10 万）

• 数据源：API + CDC；
• ETL：Airflow + DBT；
• 数仓：ClickHouse / Doris；
• BI：FineBI / Superset；
• 成本：云服务器 1 万 / 月。

方案 C：大规模（月订单 > 10 万）

• 数据源：Kafka + Flink 实时流；
• ETL：Airflow + DBT + Spark；
• 数仓：MaxCompute / BigQuery；
• BI：Tableau + 自研；
• 成本：5 万 - 20 万 / 月。

落地 Roadmap

月 1：MVP

• 核心 3-5 个数据源接入；
• 基础清洗；
• 5-10 个核心指标。

月 2-3：扩展

• 全部平台接入；
• 维度建模完善；
• 20-30 个常用指标。

月 4-6：优化

• 性能优化（分区、索引）；
• 数据质量监控；
• 实时 / 近实时需求；
• 全团队使用。

月 7-12：进阶

• 机器学习特征工程；
• 数据产品化；
• 开放给其他团队。

数据质量监控

4 类监控

1. 完整性：关键字段非空；
2. 准确性：业务规则校验；
3. 及时性：数据新鲜度；
4. 一致性：跨系统数据对得上。

工具

• Great Expectations：Python 数据质量框架；
• Apache Griffin：阿里开源；
• 自建告警：SQL 日跑 + 钉钉 / 飞书通知。

常见错误

错 1：没有数据字典

每个分析师 / 运营"自己理解"指标，结果 GMV 一人一个数。

错 2：ODS 保留所有字段但没文档

半年后没人知道字段含义。

错 3：一次性上大而全

想一开始就做 100 个指标 → 3 个月都没上线。对策：小步快跑，先 10 个核心。

错 4：没有数据 owner

表归属不清，出问题找不到人。

错 5：忽视数据权限

所有人都能看全部数据 → 安全 / 合规风险。

延伸阅读

• 多渠道数据看板搭建
• 电商核心指标字典
• BI 数据看板 4 屏模板