24、ETL性能优化：并行处理、分区策略、索引优化、数据压缩、资源管理

ETL跑得慢，说白了就是钱在烧。

我见过太多团队，每天凌晨跑批到早上八九点还没结束，业务方急得跳脚。其实很多性能问题，不是硬件不行，而是策略没到位。今天咱们就聊聊ETL性能优化的五个核心方向——并行处理、分区策略、索引优化、数据压缩、资源管理。这五个点，你吃透了，ETL效率至少翻一倍。

24.1 并行处理：别让CPU闲着

并行处理是ETL提速最直接的手段。你想想看，一个任务拆成多个子任务同时跑，时间自然就压缩了。但并行不是无脑开线程，得讲究策略。

我在项目中遇到过一个问题：开了32个并行任务，结果跑得比8个还慢。为什么？因为数据倾斜严重，大部分任务都在等那个最慢的“长尾任务”完成。所以并行处理的前提是数据分布均匀。

常见的并行模式

• 数据并行：把大表按某个字段拆成多个分片，每个分片独立处理。比如按日期、按区域。
• 任务并行：多个不相关的ETL步骤同时跑。比如维度表和事实表可以并行加载。
• 管道并行：一个任务的输出直接流到下一个任务，不用等全部完成。Spark的DAG调度就是典型。

-- 示例：在Spark中设置并行度
spark.conf.set("spark.sql.shuffle.partitions", 200)
spark.conf.set("spark.default.parallelism", 100)

-- 或者用Hive的并行设置
SET hive.exec.parallel=true;
SET hive.exec.parallel.thread.number=16;

24.2 分区策略：数据组织决定查询速度

分区是ETL性能优化的基石。没有分区，全表扫描就是噩梦。我见过一张10亿行的日志表，没分区，每次查询都要扫半小时。加了日期分区后，秒级返回。

分区策略的核心是：让查询只扫描必要的数据。你想想看，如果每次都要全表扫描，那索引、压缩都救不了你。

分区字段怎么选？

• 时间字段：最常用。按天、按月、按年。适合日志、交易流水。
• 业务维度：比如区域、部门、客户类型。适合数据有明显业务边界的情况。
• 哈希分区：适合数据分布均匀但无自然分区的场景。比如用户ID取模。

分区类型	适用场景	优点	缺点
静态分区	数据量稳定，分区固定	管理简单，性能稳定	灵活性差
动态分区	数据量变化大，分区未知	自动创建分区	可能产生小文件问题
混合分区	既有固定维度又有时间维度	兼顾查询效率和灵活性	管理复杂

-- Hive创建分区表示例
CREATE TABLE sales_data (
    order_id STRING,
    amount DECIMAL(10,2),
    customer_id STRING
)
PARTITIONED BY (order_date STRING, region STRING)
STORED AS PARQUET;

-- 加载数据时指定分区
INSERT OVERWRITE TABLE sales_data PARTITION (order_date='2024-01-01', region='华东')
SELECT order_id, amount, customer_id FROM raw_sales WHERE order_date='2024-01-01' AND region='华东';

24.3 索引优化：查询的加速器

索引这东西，用好了是神器，用不好是累赘。ETL过程中，索引主要用于加速数据查找和关联操作。但要注意，索引本身也有维护成本。

我个人的经验是：在ETL的读取阶段用索引，写入阶段慎用索引。为什么？因为写入时维护索引会拖慢速度，尤其是频繁的INSERT和UPDATE操作。

索引类型选择

• B-Tree索引：适合等值查询和范围查询。比如按订单ID查。
• 位图索引：适合低基数列。比如性别、状态字段。Oracle和PostgreSQL支持较好。
• 哈希索引：适合精确匹配。比如按主键查。
• 全文索引：适合文本搜索。比如日志内容检索。

-- PostgreSQL创建索引示例
CREATE INDEX idx_order_date ON orders (order_date);
CREATE INDEX idx_customer_region ON customers (region, customer_type);

-- 注意：ETL过程中可以先禁用索引，加载完再重建
ALTER INDEX idx_order_date UNUSABLE;
-- 执行数据加载...
ALTER INDEX idx_order_date REBUILD;

24.4 数据压缩：空间换时间，但也不全是

数据压缩能减少存储空间和I/O开销，但会增加CPU消耗。所以压缩策略的选择，本质上是I/O和CPU的权衡。

我记得有一次，一个客户的数据仓库存储成本高得离谱。我们做了压缩优化后，存储节省了70%，查询速度反而提升了30%。为什么？因为I/O瓶颈被缓解了，CPU的额外开销完全值得。

常用压缩格式对比

压缩格式	压缩比	压缩速度	解压速度	适用场景
Snappy	中等	快	快	实时查询、流式处理
Gzip	高	慢	中等	归档、冷数据
LZ4	低	极快	极快	日志、实时ETL
Zstandard	高	快	快	通用场景，平衡性好

-- Spark设置压缩格式
spark.conf.set("spark.sql.parquet.compression.codec", "snappy")
spark.conf.set("spark.sql.orc.compression.codec", "zstd")

-- Hive设置压缩
SET hive.exec.compress.output=true;
SET mapred.output.compression.codec=org.apache.hadoop.io.compress.SnappyCodec;

24.5 资源管理：别让任务抢资源

资源管理是ETL性能优化的“隐形杀手”。很多团队只关注SQL优化，却忽略了资源分配。你想想看，如果两个大任务同时抢内存，结果就是两个都跑得慢。

我见过最典型的场景：一个ETL任务把集群内存吃满，导致其他任务全部等待。最后排查发现，是某个开发把并行度设成了500，而集群总共只有200个核。

资源管理的关键点

• 内存分配：给每个任务分配合理的内存。Spark中executor内存和shuffle内存要分开配置。
• CPU核数：并行度不要超过可用核数的2-3倍。太多会导致上下文切换开销。
• 任务优先级：关键任务优先，非关键任务可以排队。YARN的Fair Scheduler和Capacity Scheduler都能做。
• 资源隔离：不同业务线的ETL任务跑在不同的资源池里，避免互相影响。

# YARN资源配置示例
# 设置单个任务最大内存
yarn.scheduler.maximum-allocation-mb=8192
yarn.scheduler.minimum-allocation-mb=1024

# Spark资源分配
spark.executor.memory=4g
spark.executor.cores=2
spark.driver.memory=2g
spark.memory.fraction=0.6  # 执行和存储内存比例

知识体系总览

下面这张图，是我梳理的ETL性能优化核心逻辑。五个方向互相影响，你得综合考虑。

这五个方向，说白了就是一套组合拳。并行处理解决“快不快”，分区策略解决“查不查得准”，索引优化解决“找不找得到”，数据压缩解决“存不存得下”，资源管理解决“抢不抢得到”。

你在实际项目中，别指望一招鲜。先分析瓶颈在哪——是I/O慢？CPU不够？还是数据倾斜？然后对症下药。我个人的习惯是：先做分区，再调并行，然后看索引和压缩，最后管资源。这个顺序，基本能覆盖80%的性能问题。

---

公众号:蓝海资料掘金营，微信deep3321