行式存储和列式存储有什么区别？数仓为什么常用 Parquet？

一句话：行存按「一行」排数据，适合点查和更新；列存按「一列」排数据，适合分析扫描。数仓常用 Parquet，不是因为它名字时髦，而是因为看板和 SQL 大多是「读几列、滤一批分区、聚合很多人」。

先看访问模式，再谈格式。
- OLTP（订单库、用户库）：一次拿某一行的很多字段，还可能改状态、改库存。行存（InnoDB 页、Heap）把一行的列放在相邻字节里，一次 I/O 就能拼出整行。
- OLAP（数仓、明细宽表）：一次扫昨天几千万行，但 SELECT 往往只有 user_id, gmv, dt，WHERE 也只碰到两三列。行存必须把整行从盘上读出来再扔掉不用的列；列存只读被点名的那些列文件。

列存靠四件事把扫描量打下去。
1. 列裁剪（projection）：查询没用到的列，文件都不用打开。宽表 200 列、查询 5 列，I/O 可以掉一个数量级。
2. 编码压缩：同一列类型相同、重复值多，字典编码、RLE、delta 比行存的通用压缩狠得多。字符串状态码、低基数字段尤其明显。
3. 谓词下推（predicate pushdown）：footer / 行组里记 min/max、null 计数。WHERE dt='2026-10-22' AND city='北京' 能跳过整块行组，不必解压每一页。
4. 向量化：一次处理一列的一批值，CPU 缓存和 SIMD 更友好。

口述对比可以用一张订单宽表：

-- 典型分析：只碰 4 列，过滤一个分区
SELECT user_id, SUM(pay_amt) AS gmv
FROM dwd_trade_order
WHERE dt = '2026-10-22'
  AND pay_status = 'success'
GROUP BY user_id;
-- 列存：几乎只读 dt / pay_status / user_id / pay_amt
-- 行存：每一行的 sku 名、地址、备注也会被读进来再丢掉

列存不是免费午餐。
- 改一行要重写多个列文件，OLTP 更新用行存或先写行式日志再批量转列。
- SELECT * 点查主键，列存要拼很多列，未必更快。
- 超小文件让 footer、行组统计比数据还重，列存优势会被小文件打没——这和「小文件治理」是同一条链。

为什么数仓落地常见 Parquet。
Parquet 是列存文件格式：文件按 row group（行组，一批行，常见几十到几百 MB）切，组内再按列拆成 column chunk，chunk 里是 page。文件末尾 footer 有 schema、各列统计。Spark/Hive/Presto 读的时候先看 footer，再决定打开哪些列、跳过哪些行组。和它并列的是 ORC（Hive 系更常见，也有索引和统计）；Avro 更偏行式序列化，适合 Kafka 传输和 schema 演进，不适合当仓里的分析主格式。实践上：入仓明细用 Parquet/ORC 分区表，流式管道用 Avro/Protobuf，业务库继续行存。

收尾三句：匹配访问模式、列存赢在少列扫描、Parquet 用行组统计做跳读。能主动说「更新和点查看行存、分析看列存、小文件会让列存变慢」，这题就过了。