大数据压缩与列式存储选型：提升Spark和Hive性能的关键实践

1. 从“存储缩水”到“速度飙升”：压缩到底动了谁的奶酪

先抛一个可能颠覆直觉的结论：在大数据领域，给数据做压缩，很多时候不是为了省硬盘，而是为了“缩短计算时间”。我最早接触大数据那会儿，团队里一位老前辈跟我说过一句话，印象特别深：“数据压缩不是存储的事，它是计算的事。” 当时没太听懂，后来自己搭集群、调作业、追慢任务追到凌晨，才慢慢咂摸出这句话的分量。

很多刚入门的朋友一听到“数据压缩”，第一反应就是“文件变小了，省存储空间”。这个理解不算错，但放在大数据场景下，压缩真正的价值远远不止省那点磁盘空间。想想一个典型的数据处理链路：数据存在HDFS上，计算引擎（比如Spark、Hive）去读文件，经过网络传输到计算节点，再反序列化进内存，然后才开始真正的计算逻辑。你会发现，这条链路上最贵的东西根本不是CPU，而是IO——磁盘IO、网络IO、甚至内存带宽。而压缩，恰好就是拿CPU的廉价计算去换IO的昂贵等待。

举个具体例子。假设你有一个2TB的文本日志文件，里面全是JSON串。不做压缩，Spark读这个文件可能要把2TB的数据从磁盘搬出来，经过网络分发到几十台机器上，耗时40分钟。但如果先用Snappy压缩，文件在HDFS上只占600GB，Spark读取时只需要搬600GB的数据量，虽然解压需要一点CPU开销，但整体时间可能直接降到15分钟。这就是压缩提升数据处理效率的核心逻辑：用一定的CPU开销，换取磁盘和网络IO的大幅削减，而IO通常才是数据处理链路里的真正瓶颈。

这个逻辑也解释了为什么大数据生态里几乎没有“裸存”的说法。你去问任何一个有经验的平台工程师，HDFS上跑的数据是裸的TextFile还是压缩过的，答案基本是一致的：除非是极特殊的临时中间结果，否则没有理由让数据裸奔。压缩已经成为大数据平台里默认的基础配置，关键在于怎么选压缩算法、怎么配压缩级别、怎么让压缩方式和存储格式及计算框架契合，这几个点没做好，压缩不仅帮不了你，还可能拖慢作业。

这篇文章我会从原理到实操，把大数据数据压缩这件事拆开揉碎，讲清楚怎么通过合理的压缩选型和配置来提升整体的数据处理效率。内容适合正在准备大数据面试的朋友、刚搭集群的运维开发，以及被慢查询困扰的数据工程师参考。

2. 压缩算法选型：不是越快越好，也不是越小越好

2.1 四大主流压缩算法的性格差异

大数据生态里，经常听到的名字就那么几个：gzip、bzip2、LZO、Snappy、LZ4、Zstandard（常叫zstd）。它们各自性格鲜明，有的追求极致的压缩率，有的追求极致的速度，有的在找平衡点。

先说压缩率天花板最高的bzip2，它的压缩比通常能到惊人的水平，但代价是压缩和解压都慢得让人抓狂。在大数据实时链路里基本见不到它，除非是归档冷数据，几年都不读一次那种，才可能考虑用它把存储成本压到极致。

然后是gzip，这是最“均衡”的老牌选手。压缩率不错，解压速度尚可，但压缩速度偏慢。在Hive数仓里，gzip是常见选择，因为它压缩出来的文件比较小，而且支持split（可拆分），配合TextFile或Parquet格式都行。

LZO和Snappy属于“速度型”选手，它们的哲学是：压缩率够用就行，但速度一定要快。Snappy在Google出品之后，几乎成了Hadoop生态的默认选项，因为它在压缩速度和压缩率之间找到了一个让工程界都很舒服的平衡点。LZO有个历史优势是可拆分，但后来Snappy解决了这个问题（下文细说），所以LZO逐渐淡出主流。

LZ4是另一个速度狂魔，它的压缩速度比Snappy还快，解压速度更是惊人，常用在对延迟极其敏感的实时计算场景。不过LZ4的压缩率一般，文件会比Snappy版本略大。

Zstandard（zstd）是Facebook开源的后起之秀，它最厉害的地方在于压缩级别可以调，从1到22，1级别的速度跟LZ4差不多，19级别的压缩率甚至可以逼近bzip2。这意味着你可以用同一套算法应对从“热数据实时处理”到“冷数据极致压缩”的各种场景，这也是近年来越来越多平台从gzip/Snappy迁移到zstd的原因。

2.2 表格对照：一句话讲清每种算法适合谁

这表格里有一个词需要注意：可拆分（splittable）。这是大数据场景专用的概念，意思是文件能否被切成多个分片，让不同机器并行处理。如果你的压缩算法不支持拆分，那整个文件只能被一台机器处理，文件再大也无法并行——这会造成严重的数据倾斜，任务跑得比乌龟还慢。举例来说，早期Snappy刚出现时不支持可拆分，导致很多MapReduce作业宁可继续用LZO。后来Snappy在容器格式层面支持了拆分，才彻底铺开。所以记住：选压缩格式时，先看是否支持并行拆分，再看压缩率和速度。

2.3 为什么说“更快”比“更小”更值钱

做压缩选型时，新人最容易掉进的坑是盲目追求高压缩率——“压缩率越高，文件越小，存储越省，不是越好吗？” 真实场景里恰恰相反。回想一下大数据计算的基本模型：数据分布在多台机器上，任务并行处理。处理时间由两件事决定，一个是读数据的时间（IO），一个是算数据的时间（CPU）。如果一个算法压缩率很高，但解压要吃掉大量CPU时间，整个作业的速度反而会被拖慢。更麻烦的是，高压缩率往往意味着压缩时间长，如果你处理的是实时流数据，压缩环节本身就可能成为链路瓶颈，导致消息积压。

用汽车来类比可能更好理解：gzip像是一辆省油的家用车，跑长途很划算但起步肉；Snappy和LZ4像是跑车，提速猛但油耗高；zstd像是一台带9个挡位的变速箱，你想要省油就挂高档，想要极速就挂低档。在大数据场景里，大多数时候你要的不是“最省油”而是“平均速度最快”。因为存储成本相对可控，而作业跑得慢意味着集群资源被占用更久、调度排队更严重、业务方等待时间更长，这些隐性成本远远超过那点存储差价。

从量化角度看，假设你有一个TPC-DS基准测试里的典型分析查询，全表扫描一个1TB的gzip压缩表，解压耗时约占整个任务时间的40%；换用Snappy后，表体积变大35%，但解压耗时占比降到15%，整体任务时间反而缩短了20%以上。这就是“大一点，但快很多”的实际效果。

3. 数据格式与压缩的“组合拳”：Parquet和ORC为什么是大数据压缩的最佳搭档

3.1 压缩算法只是半条腿，容器格式才是另外半条

很多新手困惑一件事：我明明选了Snappy，文件也变小了，为什么Spark读起来还是不够快？这里面藏着一个关键认知：压缩算法负责把字节变小，但真正决定“能不能只读需要的部分”的，是容器格式（Container Format）。大数据处理里最常用的行式存储TextFile一行一行读，列式存储Parquet和ORC按列批量读，两者的性能和压缩效果天差地别。

先说最朴素的行式存储TextFile + gzip。每条记录在文件中是一整行JSON或CSV。查询的时候如果你想只取某一列，引擎也得把整行数据完整解压后读进来。这意味着你扫描了100列的数据，可能最后只用到了其中2列，剩下的98列白白浪费了磁盘IO和解压CPU。在大数据量级下，这种浪费是灾难性的。

而Parquet和ORC这类列式存储格式，天生就是为“按列裁剪”而生的。数据在文件内部按列分块存储，查询时只解压和读取涉及的列。假设一张200列的大宽表，某个报表查询只用到5列，Parquet模式下可能只需要扫描2.5%的数据。再叠加压缩，效果就是：底层字节被压缩算法变小，列裁剪让引擎只碰需要的那部分字节，两者叠加之后的数据处理效率提升不是加法，而是乘法。

我实操中的一个真实案例：一张宽120列、底层3TB的Hive表，原始格式是TextFile + gzip，一个中等复杂度的聚合查询跑20分钟。后来花了一个周末把表转成Parquet + Snappy存储，表体积变成1.1TB，相同查询的运行时间降到4分钟。文件小了三分之二，时间缩短了八成。这里面有压缩的功劳，但更核心的是列裁剪带来的IO跳过。

3.2 Parquet与ORC的技术细节和选型差异

Parquet和ORC都支持列式存储，但两者有一些底层差异直接影响实际使用体验。

Parquet源自Twitter和Cloudera的合作项目，它的设计哲学是跨平台、跨语言、跨组件通用。在Spark生态里，Parquet几乎是默认的“亲儿子”，配合Spark SQL有非常好的优化。Parquet很适合通用数据湖、多引擎共用的场景，比如同一份数据同时给Spark、Hive、Presto/Trino查，Parquet的兼容性和生态完整度最高。

ORC则起源于Hive社区，由Hortonworks主导开发。ORC在底层做了更极致的优化，比如内置了轻量级索引（Row Group Index）、Bloom Filter等能力，在Hive里跑查询性能往往比Parquet更猛。但ORC对Spark和Presto的支持历史上有过一些小坑，跨引擎兼容性没Parquet那么顺滑。如果你的环境就是纯Hive数仓，选ORC通常能榨出更高的查询性能。

回到压缩这个话题，Parquet和ORC对压缩算法的支持也略有差异。实际操作中，Parquet最常用的是Snappy和zstd，ORC最常用的是zlib（跟gzip同源）和zstd。我的建议是：如果判断不出该选哪个格式，先用Parquet + Snappy跑几个生产查询试试，这组合大概率能让你满意。如果想压榨极致性能且引擎以Hive为主，再仔细测ORC + zstd。

3.3 一份数据要多大才值得转列式存储

有个很现实的问题：是不是所有表都值得转成Parquet？答案是否定的。列式存储也有开销，比如写入时需要在内存里按列缓冲，对吞吐有要求；小文件场景下列式存储的优势也会被放大损耗吞噬。以我的经验，单表数据量小于500GB时，转列式存储带来的收益不一定明显；超过1TB时，收益就会非常显著。如果你面对的是几百张小表，与其花精力转格式，不如先优化查询写法和资源配额。这也是数据治理中先看投入产出比的原则。

4. 压缩级别调优实操：从HDFS到Hive、Spark、Kafka的完整配置指南

4.1 先搞清楚你的数据形态再说配置

压缩配置不能一刀切。生产环境里数据至少分成三类：静态数仓表、计算中间结果、实时流数据。它们对压缩的诉求完全不同。

静态数仓表（比如日活明细表、订单宽表）的特点是：写入一次、读取多次、总量巨大。这类数据值得花时间“精细压缩”，压缩率可以适当高一些，因为压缩时间成本被分摊到了每一次查询上。中间结果（比如Shuffle落盘文件、临时表）的特点是：生命周期极短，写入后马上被读取，读写频次几乎1:1。这种数据压缩速度比压缩率重要得多，应该选LZ4或Snappy这种快速算法。实时流数据（Kafka里的消息）的特点是：延迟极其敏感，每条消息都要在毫秒级完成压缩/解压。这里的压缩策略通常是LZ4，甚至考虑是否值得压缩都要谨慎评估。

理解了这三类场景，再去看网上五花八门的“最佳配置”，就不会被带偏了。

4.2 HDFS和Hive层面的压缩配置

在Hadoop生态里，压缩设置通常分两层：文件编码层面和作业执行层面。前者决定数据落盘时用什么格式编码，后者决定MapReduce或Spark任务运行过程中产生的中间数据用什么压缩。

如果你用的是Hive数仓，建表时可以这样指定存储格式和压缩：

sql复制-- 推荐：Parquet + Snappy，兼顾查询性能和压缩速度
CREATE TABLE dwd_order_detail (
  order_id STRING,
  user_id BIGINT,
  amount DECIMAL(10,2),
  create_time TIMESTAMP
)
STORED AS PARQUET
TBLPROPERTIES ('parquet.compression' = 'SNAPPY');

这里有个很容易踩的坑：很多老教程会建议在Hive会话里跑“SET hive.exec.compress.output=true; SET mapreduce.output.fileoutputformat.compress.codec=org.apache.hadoop.io.compress.SnappyCodec;”这类设置。这套配置在MapReduce引擎时代确实有效，但如果你的Hive已经切换到Tez或Spark引擎，这两个参数根本不会生效。正确做法是优先在建表DDL里指定格式和压缩编码，让元数据自己说话，而不是依赖会话级设置。

Spark作业如果想把Shuffle中间结果压缩打开，可以在提交作业时加参数：

bash复制spark-submit \
  --conf spark.shuffle.compress=true \
  --conf spark.shuffle.spill.compress=true \
  --conf spark.io.compression.codec=snappy \
  --class com.example.BigJob \
  myjob.jar

这一组配置对Spark作业的稳定性影响很大。Shuffle是所有分布式计算里最昂贵的环节之一，Map端产出的中间数据要落盘然后被Reduce端拉取。如果不压缩，几TB的Shuffle数据会直接把磁盘和网络打满，作业跑得又慢又不稳定。开了Snappy压缩之后，Shuffle数据量通常能减少一半以上，整个作业的时间甚至能缩减30%以上。

4.3 Kafka实时链路里的压缩配置

Kafka是实时场景里绕不开的组件。Kafka消息的压缩策略是在Producer端指定的。如果你的下游消费速度经常跟不上生产速度，调整Producer压缩参数往往是立竿见影的手段：

properties复制# Producer端配置示例
compression.type=lz4
linger.ms=20
batch.size=65536

这里的设计意图是：Kafka开启压缩后，Producer会在内存里攒一批消息，压缩成一个大的批量消息再发给Broker。一来减少网络带宽占用，二来减少Broker的磁盘写入量。LZ4就是为这种场景量身定做的：极快的压缩和解压速度，能保证Producer端不会因为压缩而增加明显的延迟。实测下来，在日志量级每秒几十万条的场景下，开启LZ4后Kafka集群的网络流量能下降大约60%，而Producer端的CPU使用率只增加了不到10%。这种性价比在实时链路里是非常值得的。

Broker端也有一层压缩设置，用于Broker间的数据转发存储。一般来说，Producer已经压缩过的消息，Broker端保持默认即可，不建议再二次压缩，否则就是白白消耗CPU。这些细节在面试中也很容易被问到——面试官通常想听的正是“能不能分清不同层级的压缩代价”。

4.4 压缩级别的精确控制和代价计算

很多压缩算法支持调整压缩级别。zstd是级别跨度最大的一个，从1到22。级别越高，压缩率越好，但压缩时间和CPU消耗也越大。注意一点：压缩级别影响的是压缩速度，解压速度几乎不受级别影响。所以你在优化压缩级别时，主要权衡的是写入成本和存储/读取收益。

以zstd为例，在集群环境里推荐的使用方式：

实际操作中，我通常会让离线大批量任务固定用ZSTD的6级别。把zstd级别调到6之后，压缩率通常比gzip高10%~15%，但压缩速度比gzip快好几倍，属于“又快又小”的甜蜜点，非常适合数仓T+1任务的典型需求。

有一个计算压缩成本的小公式可以分享：如果一批任务的压缩前数据量是X GB，压缩后是Y GB，压缩耗时是T分钟，那么每压缩1GB数据的时间成本就是T / X，而存储节省是(X - Y) / X。只有当“压缩耗时增加”造成的等待成本低于“存储节省带来的IO收益”时，提高压缩级别才是划算的。如果拿不准，先用默认级别跑，不要一上来就追求最高压缩率——生产环境出问题往往不是因为压缩不够狠，而是CPU被打满了。

5. 实战案例：一个千亿级日志平台的压缩改造全记录

5.1 问题背景与瓶颈定位

前两年我参与维护过一个日志分析平台，每天接入几十个业务系统的应用日志，日均新增原始日志约500亿条，折算成未压缩的TextFile大约每天30TB。平台底层是HDFS加Spark SQL做离线分析，加一套Kafka加Flink做实时告警。

最初平台每天的链路是这样的：应用日志通过Filebeat采集，写入Kafka；一个Flink作业消费Kafka数据，清洗后落地到HDFS上的Hive表。Hive表最初的设计是TextFile + gzip。没过多久就发现问题了：凌晨两点的离线批处理作业越跑越慢，用户反馈“昨天的报表怎么还没出来”。去集群上看指标，发现磁盘IO早就打满了，大量任务卡在数据读取上。内存和CPU反而还有不少余量。

这时候我意识到：问题根本不在计算逻辑，而在数据读取路径上。每天30TB的裸日志数据，虽然gzip压缩后只有约9TB，但每次跑离线分析时，Spark都要把整张表的数据扫一遍——不是扫9TB的压缩文件，而是把30TB的数据完整解压出来，还要经历网络传输和反序列化的开销。日志表是典型的宽表，一条记录有几十个字段，而分析查询经常只关心其中四五个字段。TextFile模式下，列裁剪完全派不上用场，每一行都得完整解析。

5.2 改造方案：Parquet + Snappy + zstd分层存储

经过大概两周的测试和评估，我们决定做一套组合方案：

第一，把核心的日志明细表从TextFile + gzip迁移到Parquet + Snappy。选择Snappy而不是zstd的考虑是：该表仍然承担实时写入的任务，Flink作业对写入吞吐和延迟都敏感，Snappy的写入性能在实测中比zstd级别3更稳定一些。压缩率略低完全可以接受，因为Parquet本身的列式编码已经自带了一层很好的体积压缩效果。

第二，对于需要长时间保留的月度归档表，使用Parquet + zstd级别8落盘。这些表不参与实时写入，一天只跑一次归档任务，压缩慢一点无所谓，但存储上能再省30%，半年下来省了上百TB的存储空间。

第三，Kafka链路全部切到LZ4压缩。Flink消费端解析速度明显变快，因为LZ4解压的开销几乎是所有主流压缩算法里最低的。

改造后的核心DDL大致长这样：

sql复制-- 实时明细表：Parquet + Snappy
CREATE TABLE dwd_app_log_detail (
  app_name STRING,
  log_time TIMESTAMP,
  trace_id STRING,
  user_id STRING,
  req_path STRING,
  status_code INT,
  resp_time_ms INT,
  ...
)
PARTITIONED BY (dt STRING)
STORED AS PARQUET
TBLPROPERTIES ('parquet.compression' = 'SNAPPY');

-- 归档表：Parquet + zstd
CREATE TABLE dws_app_log_monthly_archive (
  app_name STRING,
  log_time TIMESTAMP,
  ...
)
PARTITIONED BY (month STRING)
STORED AS PARQUET
TBLPROPERTIES ('parquet.compression' = 'ZSTD', 'parquet.compression.codec.zstd.level' = '8');

5.3 上线后的收益对比

改造完成、数据积累了两周后，我拉了改造前后的对比数据：

看到这些数字的那一刻，说实话心里还是很爽的。但更值钱的不是这些数字本身，而是这套改造让我们积累了数据压缩选型的完整方法论。

后面又迭代了一次：把部分高频查询改为直接读Parquet文件配合Presto/Trino引擎，配合Parquet的谓词下推能力，很多查询从分钟级降到秒级。原因是Parquet文件内每个行组都带了统计信息（min/max、null count等），Presto扫描时可以直接跳过不符合过滤条件的行组。这相当于在列裁剪之上又加了一层“块裁剪”，IO开销进一步被压缩。

5.4 迁移过程中的数据一致性保障

这块容易忽略，但非常关键。压缩改造不是简单的“改个DDL、重新导数据”就完事。如果你面对的是线上还在持续写入的生产表，必须考虑迁移期间的数据一致性问题。

我们当时的做法是：先用Flink跑一个双写任务，新数据同时写入旧表和新表，持续三天；然后用Spark作业把旧表的历史分区批量回填到新表；每天对比新旧两张表的记录数和几个关键字段的校验和（checksum），两边对上了才把下游读取任务切到新表。整个过程大约一周，没丢一条数据，也没让业务方感知到切换动作。如果你的表没有持续写入，直接用CTAS（CREATE TABLE AS SELECT）重建就行了，简单得多：

sql复制CREATE TABLE dwd_log_parquet_snappy
STORED AS PARQUET
TBLPROPERTIES ('parquet.compression' = 'SNAPPY')
AS SELECT * FROM dwd_log_text_gzip;

这里有一个细节：CTAS在Hive/Spark里默认就有，写完了记得做数据对比和文件数量检查，避免小文件过多拖垮后续查询。

6. 常见问题与排查技巧实录：压缩相关的坑，我帮你踩过了

6.1 为什么开启了压缩，作业反而更慢了

这是最常被问到的现象。如果你在Spark作业里开了压缩，但数据量很小（比如只有几百MB），压缩和解压的CPU开销可能大于IO收益，结果就是负优化。压缩不是越多越好，它有一个阈值，一般建议数据总量在数GB以上再考虑压缩。如果数据量不大，保持不压缩也许综合效率更高。

另一个可能原因是压缩编码器没配对。比如Hive表底层文件是Parquet，但parquet.compression没设置对，Spark可能用默认的UNCOMPRESSED去读或者写，导致数据集比预期大；或者配置里写了gzip，但集群上没装对应的native codec库，Hadoop在无法加载codec时会直接报错或用Java版本的慢速实现——这一个坑非常隐蔽，因为任务不会失败，只是慢得离谱。排查时先确认每个节点上$HADOOP_HOME/lib/native目录是否包含对应压缩库（如libsnappy.so、libzstd.so等），有经验的工程师会第一时间用hadoop checknative命令验证。

6.2 压缩文件无法并行处理：split的坑

前面提过“可拆分”特性，这里展开一下实际影响。假设你用gzip压缩了一个20GB的日志文件，然后提交Spark作业处理。gzip本身是不支持split的（这是格式的硬限制），Spark只能把这个文件当作一个不可切分的整体交给单个任务处理。哪怕你的集群有100个核，也只有1个核在干活，其他99个在围观，跑完要将近一个小时。如果你用Snappy配合容器格式（比如Parquet或SequenceFile），文件内部被划分成多个数据块，Spark可以并行读取各块，100个核一起跑，几分钟就完事。

所以，当发现某个作业的并发度上不去时，先检查源文件的压缩格式。不要用gzip压缩超大文件后直接丢给Spark读。如果历史数据已经这么存了，建议做一次解压重写，把数据转成Parquet + Snappy。

6.3 解决Parquet文件中小文件的困扰

Parquet文件可以拆分，但文件如果太小（比如小于HDFS默认Block大小128MB），就会产生大量小文件碎片。MapReduce或Spark作业启动时，每个文件块对应一个任务，文件块越多任务调度越频繁，整体效率不升反降。

实践中常见的情况是：Flink或流式作业每几分钟就往HDFS上写一个Parquet文件，一天下来积攒了上千个小文件。解决方法通常是跑一个定时合并任务，或者用Hive的INSERT OVERWRITE把一天的散文件合并成少量大文件。合并后的Parquet查询性能会显著提升，因为减少了文件打开和任务调度开销。

6.4 压缩率远低于预期时的排查思路

如果你压缩后的文件还很大，先不要怀疑算法选错。大概率情况是：底层数据本身重复度就很低，比如随机数、加密串、UUID等消息，它们经任何压缩算法都几乎压不动。还有一个常见原因：数据虽然看着像文本，但实际上是Base64编码过的二进制内容。Base64编码后的数据熵很高，压缩效果很差。碰到这种情况，调整算法收益有限，建议从数据源头考虑是否真的需要存储Base64形式，或者在写入前用更合适的二进制序列化方式（如Avro、Protobuf）降熵，再做压缩。

6.5 踩坑速查表

7. 扩展思考：压缩与未来大数据架构的演进关系

聊完了具体实操，最后想超出“怎么配”的层面，聊聊压缩在大数据架构演进中的位置。这几年数据湖架构（Lakehouse）越来越流行，以Iceberg、Hudi、Delta Lake为代表的新一代表格格式开始在存储格式之上加了一层“表管理”能力。这些格式对压缩的处理和传统Hive表有本质区别：它们可以在文件级别做增量压缩（compaction），也可以让服务端自动选择最优压缩策略。

比如Hudi的MOR（Merge On Read）表，会把实时写入的小文件和新数据放在log文件里，后台异步做压缩合并，把log文件和base文件合并成更大的Parquet文件。这个过程既是一次文件治理，也是一次压缩重写。如果你在设计新平台，尽量把这些格式的内在能力用起来，而不要停留在手动跑压缩作业的层面。

另一个值得关注的方向是存算分离架构下的压缩策略变化。以前数据在HDFS上，计算节点和数据节点往往是同一批物理机，“本地读”占便宜。现在云原生数据湖越来越流行，数据放在对象存储（比如S3、OSS）上，计算引擎通过网络远程读文件。这时网络带宽成为更核心的瓶颈——对象存储的读取吞吐受限，压缩的价值比例进一步放大。同一份数据，冷热分层存储时，怎么选压缩算法、怎么配合成本更优的存储级别，都会直接影响账单数字。zstd在这个场景下越来越受欢迎，因为它能提供接近LZ4的速度和接近gzip的压缩率，可以在不牺牲太多读性能的前提下把存储成本压下来。

最后提一个反直觉的个人体会：很多人把压缩当作“存储优化动作”，一年只做一次数据归档时才会想起它。但在真正的生产系统里，压缩策略应该是和表结构Schema一起设计、一起迭代的“一等公民”。建表的时候就该想清楚：这张表的存储格式是什么、压缩算法是什么、预计的写入读取模式是什么，而不是等数据堆积成山了再回头处理。

我自己折腾这么多年，踩过的最大的坑就是以为压缩只是“把文件变小”那么简单，结果被各种IO瓶颈、split陷阱、codec缺失折腾得够呛。希望读完这篇文章的你，能少走点弯路，回去以后重新审视一下集群里的压缩配置——说不定你会发现，很多运行了很久的慢作业，改一行压缩配置就有质的提升。