4. 离线存储选型：HDFS架构、Hive与分区表、ORC/Parquet列式存储

离线存储选型，说白了就是给数据找个靠谱的“家”。这个家得能装下海量数据，还得让后续的分析任务跑得快。我这些年折腾下来，核心就三样东西：HDFS 做底层存储，Hive 管元数据和 SQL 接口，列式存储（ORC/Parquet）来优化读写性能。咱们一个一个聊。

4.1 HDFS 架构：分布式文件系统的基石

HDFS 是 Hadoop 生态的“地基”。它的设计哲学很简单：把大文件切成小块，分散存到多台机器上，再通过冗余副本保证数据不丢。

核心组件就两个：

• NameNode（老大）：管理文件系统的元数据。它知道每个文件被切成了多少块，每个块存在哪几台 DataNode 上。嗯，这里要注意——NameNode 是单点，它的内存大小直接决定了集群能存多少文件。
• DataNode（小弟）：真正存数据的地方。每个块默认 128MB，存 3 个副本。DataNode 定期向 NameNode 汇报“我还活着，我的块都好好的”。

HDFS 写入流程（简化版）：

1. 客户端向 NameNode 请求“我要写一个文件”。
2. NameNode 返回一个 DataNode 列表（比如 3 个节点）。
3. 客户端把数据分成 128MB 的块，依次写入第一个 DataNode。
4. 第一个 DataNode 把数据复制给第二个，第二个再复制给第三个——形成“管道复制”。
5. 所有副本写完后，客户端通知 NameNode “写完了”。

这个流程保证了数据的高可靠。但代价是写入延迟比较高，所以 HDFS 适合“一次写入、多次读取”的场景，不适合频繁修改。

4.2 Hive 与分区表：把 SQL 翻译成 MapReduce

Hive 的出现，让不会写 Java 的分析师也能操作 HDFS 上的数据。它把 SQL 语句翻译成 MapReduce 或 Tez 任务。说白了，Hive 就是个“翻译官”。

Hive 的核心概念：

• 表（Table）：对应 HDFS 上的一个目录。
• 分区（Partition）：按某个字段（比如日期）把数据拆成子目录。查询时只扫描相关分区，能大幅减少数据量。
• 分桶（Bucket）：在分区内部再按哈希值切分，适合做采样和 Join 优化。

分区表建表示例：

CREATE TABLE user_behavior (
    user_id STRING,
    action STRING,
    amount DOUBLE
)
PARTITIONED BY (dt STRING)
STORED AS ORC;

查询时带上分区过滤：

SELECT * FROM user_behavior WHERE dt = '2025-04-01';

这样 Hive 只会扫描 dt=2025-04-01 这个目录下的数据，而不是全表扫描。你想想看，如果表里有 3 年的数据，不分区的话得扫多少无用数据？

4.3 ORC/Parquet 列式存储：为什么比行式快 10 倍？

行式存储（比如 TextFile、SequenceFile）按行存数据。查询时哪怕你只想要一列，也得把整行读出来。列式存储则相反——按列存，查询时只读需要的列。

列式存储的优势：

• 减少 I/O：只读取需要的列，而不是整行。
• 高压缩比：同一列的数据类型相同，压缩效果更好。比如性别列只有“男/女”，压缩比能到 10:1 以上。
• 向量化执行：CPU 缓存利用率更高，适合批量处理。

ORC vs Parquet：怎么选？

特性	ORC	Parquet
出身	Hive 社区（Apache ORC）	Cloudera/Twitter（Apache Parquet）
压缩率	略高（自带轻量级索引）	优秀（支持多种编码）
嵌套结构	支持，但不如 Parquet 灵活	原生支持复杂嵌套（JSON-like）
适用引擎	Hive、Spark、Presto	Spark、Impala、Presto、Hive
索引	内置轻量级索引（min/max、布隆过滤器）	无内置索引，依赖统计信息

列式存储的物理布局（以 Parquet 为例）：

Row Group 1:
  Column "user_id": [u1, u2, u3, ...]
  Column "action":  [click, view, buy, ...]
  Column "amount":  [10.0, NULL, 200.0, ...]

Row Group 2:
  Column "user_id": [u100, u101, ...]
  ...

每个 Row Group 包含若干行，内部按列存储。查询时，引擎只读取需要的 Column Chunk，跳过无关数据。

4.4 知识体系总览

下面这张图把本章的核心逻辑串起来了。你可以看到数据从业务系统流入，经过 HDFS 存储、Hive 元数据管理，最终以列式格式供分析引擎使用。

4.5 选型实战建议

说了这么多理论，最后给点实在的。我这些年总结了一套选型 checklist：

1. 数据量多大？ 如果每天不到 100GB，HDFS 随便搭，甚至可以用单节点测试。如果每天 TB 级，必须规划好 NameNode 内存和网络带宽。
2. 查询模式是什么？ 如果经常做全表扫描（比如 ETL 清洗），行式存储也不是不能用。但如果是 OLAP 分析（比如 BI 报表），必须上列式存储。
3. 团队技术栈？ 如果团队 Spark 用得多，无脑选 Parquet。如果 Hive 是主力，ORC 更省心。
4. 分区策略怎么定？ 我习惯按日期分区，每天一个分区。如果数据有地域属性，可以再加一层地域分区。但分区层级别超过 3 层，否则元数据会膨胀。