3. 存储层设计

存储层是数据湖仓的基石。说白了，选错存储，后面所有优化都是白搭。我这些年见过太多团队，上来就拍脑袋选HDFS，结果云原生时代被对象存储按在地上摩擦；也见过迷信S3的，结果被小文件搞到想哭。

今天咱们就把存储层掰开揉碎，讲清楚三件事：对象存储 vs HDFS、列式存储格式、文件布局与分区。嗯，这三块是湖仓性能的命门。

对象存储 vs HDFS：一场关于「解耦」的战争

先聊HDFS。HDFS的设计哲学是「计算跟着数据走」。数据分块存在本地磁盘，副本机制保证高可用。好处是数据本地性极佳，坏处是——你想想看，集群扩容必须同时加计算和存储，成本高，弹性差。

对象存储（S3/MinIO）则完全相反。它把数据当作对象，通过HTTP API访问。计算和存储彻底分离。我去年帮一家金融客户做湖仓迁移，他们原来用HDFS存了200TB历史数据，每次扩容都要采购整批服务器，周期两个月。换成MinIO后，存储节点独立扩缩，成本降了40%。

维度	HDFS	对象存储（S3/MinIO）
一致性	强一致性（写后读可见）	最终一致性（S3标准版），MinIO支持强一致
扩展性	水平扩展，但受NameNode限制	近乎无限扩展，无单点瓶颈
计算存储耦合	强耦合，数据本地性依赖	完全解耦，计算可独立伸缩
小文件性能	差（NameNode内存瓶颈）	差（大量HTTP请求开销）
成本	高（需本地磁盘+副本）	低（按量付费或廉价对象存储）
典型场景	离线批处理，本地部署	云原生湖仓，数据湖

我个人习惯：新项目首选对象存储。云上用S3，私有化用MinIO。只有一种情况我会坚持HDFS——对延迟极度敏感、且数据本地性收益明显的场景，比如实时特征工程。

列式存储：Parquet vs ORC，谁是你的菜？

行式存储（比如CSV、Avro）在OLTP场景很香，但到了分析型查询就露怯了。你想想看，一个表有100列，查询只取3列，行式存储却要把整行数据都读进来——IO浪费至少97%。

列式存储正好解决这个问题。它按列组织数据，查询时只读取需要的列。再加上压缩率高（同一列的数据类型相同，压缩效果更好），性能提升不是一星半点。

目前主流就两个：Parquet 和 ORC。我两个都用过，说说真实感受。

Parquet

Parquet是Twitter和Cloudera联合开发的，Spark生态的亲儿子。它的核心优势是嵌套数据支持。如果你有JSON、Protocol Buffers这类复杂结构，Parquet能完美保留嵌套关系，不用拍平。

我在项目中遇到过：用Parquet存储用户行为日志，每条记录包含事件列表和属性Map，直接写Parquet，查询时用Spark的嵌套函数处理，代码简洁，性能也好。

ORC

ORC是Hive生态的产物，后来被Apache接纳。它的强项是ACID事务和索引。ORC内置了轻量级索引（如Bloom Filter、Min/Max统计），能快速跳过不相关的数据块。

举个例子：查询某个时间范围的数据，ORC的Min/Max索引直接告诉你哪些Stripes不包含目标时间，跳过率能达到90%以上。

特性	Parquet	ORC
嵌套数据	原生支持，无需拍平	支持，但不如Parquet灵活
ACID事务	需借助Hudi/Iceberg	原生支持（Hive ACID）
索引	无内置索引	Min/Max、Bloom Filter
压缩率	高（ZSTD/Snappy）	更高（ZLIB/ZSTD）
生态	Spark、Presto、Flink	Hive、Spark（需适配）
写入性能	中等	较好（Striped布局）

文件布局与分区策略：小文件是万恶之源

存储选好了，格式定好了，但如果文件布局一塌糊涂，性能照样崩。我见过最夸张的案例：一个表每天产生10万个小文件，每个文件不到1MB。查询时，光打开文件列表就花了30秒。

文件布局的核心原则就两条：文件大小要合理，分区要匹配查询模式。

文件大小：多大才算「合理」？

对象存储和HDFS对文件大小的敏感度不同：

• HDFS：NameNode内存中维护文件元数据，每个文件/块约150字节。1000万个文件就是1.5GB内存，NameNode扛不住。建议文件大小128MB~256MB。
• S3/MinIO：没有NameNode瓶颈，但大量小文件会导致List请求爆炸。建议文件大小64MB~1GB。

我习惯用64MB~256MB作为目标。太小了IOPS高，太大了并行度不够。具体怎么控制？写入时设置好文件大小参数：

-- Spark写入时控制文件大小
df.write
  .option("maxRecordsPerFile", 500000)  -- 每个文件最多50万行
  .option("parquet.block.size", 134217728)  -- 128MB
  .mode("overwrite")
  .parquet("s3a://lakehouse/events/")

分区策略：别瞎分，分错了比不分还惨

分区是湖仓性能的放大器。分得好，查询秒级；分得差，全表扫描。

分区字段的选择原则：高基数且查询频繁的字段。最常见的是时间（年/月/日）、地域（国家/省份）、业务线。

举个例子，一个电商订单表：

-- 推荐的分区结构
s3://lakehouse/orders/
  year=2024/
    month=01/
      day=15/
        part-00001.parquet
        part-00002.parquet
      day=16/
        ...
    month=02/
      ...
  year=2025/
    ...

查询某天的订单：WHERE year=2024 AND month=01 AND day=15，直接定位到对应目录，只扫描两个文件。

分区数量与文件大小的平衡

分区数量和文件大小是跷跷板。分区太多，每个分区文件小；分区太少，每个分区文件大。怎么平衡？

• 时间分区：按天分区，每天数据量在1GB~100GB之间比较理想。如果每天数据量小于100MB，考虑按周或月分区。
• 动态分区：用Spark的partitionBy自动创建分区，但要控制分区数。我一般限制在5000以内。
• 合并小文件：定期跑一个合并任务，把小于32MB的文件合并到128MB。

-- 合并小文件的Spark脚本
spark.read
  .parquet("s3a://lakehouse/orders/year=2024/month=01/")
  .coalesce(10)  -- 合并到10个文件
  .write
  .mode("overwrite")
  .parquet("s3a://lakehouse/orders/year=2024/month=01/")