/%E6%95%B0%E6%8D%AE%E7%AE%A1%E9%81%93/ Recent content in 数据管道 on 老张开工了 Hugo zh-cn Wed, 29 Apr 2026 00:00:00 +0000 /posts/2026/04/etl-project/ Wed, 29 Apr 2026 00:00:00 +0000 /posts/2026/04/etl-project/ 项目概述 经过前面 14 篇文章的学习，你已经掌握了 ETL 的各个核心环节：数据抽取、转换、加载、SQL 技巧、Python 开发、现代工具链和工作流编排。现在是时候把它们全部串联起来了。 本章是一个端到端的实战项目。我们将为一个电商平台构建完整的数据管道，从原始数据采集到业务指标计算，全部自动化运行。 场景设定 假设你在一家中型电商公司工作。公司有以下几个数据源： MySQL 业务数据库：存储订单、用户、商品信息 CSV 文件：存储在 S3 上的每日营销费用数据 REST API：第三方物流服务商的运单状态接口 你的任务是把这些数据汇集到 PostgreSQL 数据仓库中，清洗转换后生成业务报表，并每天自动运行。 技术栈 环节 工具 用途 数据抽取 Python + SQLAlchemy + requests 从数据库、API、文件抽取数据 数据加载 Python + PostgreSQL 加载到数据仓库 数据转换 dbt 在仓库内完成转换 工作流编排 Airflow 调度整个流程 数据质量 dbt test + Great Expectations 数据验证 监控告警 Airflow + Slack 失败通知 第一步：项目结构 ecommerce-etl/ ├── dags/ # Airflow DAG 定义 │ └── ecommerce_pipeline.py ├── dbt_project/ # dbt 项目 │ ├── dbt_project. /posts/2026/04/etl-performance/ Fri, 17 Apr 2026 00:00:00 +0000 /posts/2026/04/etl-performance/ 瓶颈在哪里 ETL 性能优化最忌讳的事就是一上来到处调参数。没有找到真正的瓶颈之前，所有的优化都是瞎蒙。 先搞清楚一个基本事实：ETL 管道中最慢的环节决定了整体速度。这个瓶颈可能出现在抽取阶段（网络带宽限制）、转换阶段（CPU 算力不足）、或者加载阶段（数据库写入太慢）。 定位瓶颈的基本方法是用监控工具观察每个阶段的耗时和资源消耗。一个简单的做法是在管道中埋点记录时间： import time from contextlib import contextmanager @contextmanager def measure_stage(stage_name, logger=None): """记录每个阶段的耗时""" start = time.time() start_mem = get_memory_usage() try: yield finally: elapsed = time.time() - start end_mem = get_memory_usage() print(f"[{stage_name}] 耗时: {elapsed:.2f}s, " f"内存: {start_mem:.0f}MB → {end_mem:.0f}MB " f"(增量: {end_mem - start_mem:.0f}MB)") 在实际案例中，我曾见过一个团队花了两周优化 SQL 查询，把转换阶段从 2 小时降到 20 分钟，但整体 ETL 仍然跑了 3 小时——因为他们没发现瓶颈其实在加载阶段，数据库写入速度跟不上。 并行处理 并行是加速 ETL 最直接的手段。可以把一个大任务拆分成多个小任务同时执行。 数据分区并行 把数据按某个维度分成多个分区，每个分区独立处理。分区方式包括： 按时间分区：每天的数据一个分区，多天的数据可以并行处理 按范围分区：按 ID 范围拆分，比如 1-100 万、100 万-200 万 按业务维度：按地区、产品类别等业务字段拆分 import concurrent.