存储

一句话

你以为存储就是「选一个数据库」，其实它是一个三层的栈：底下是硬盘、内存、网络这些物理原料，中间是文件 / 块 / 对象存储这些系统，上面才是数仓、数据湖、湖仓这些抽象。本章要建立的认知是：每一层的选择都在「延迟—成本—扩展性—持久性」之间取舍；云时代的默认答案是「对象存储 + 列式文件 + 按需算力」，但「计算存储彻底分离」只是半个真相，真实系统都是分离与就近缓存的混合。

Glossary · 术语表

坐标

Part II「生命周期详解」第二章。上接第 5 章「数据从哪来」，下启第 7 章采集、第 8 章查询与转换。作者特意把它放在采集之前：存储是贯穿整个生命周期的那块地基，采集、转换、服务每一步都在读写它。现实里对应「S3 / GCS 上的数据湖、Snowflake / BigQuery 数仓、Kafka 的消息保留」这些选型。

这章要解决什么

数据工程师很少从零造存储，但每天都在选存储，而选错的代价往往几年后才显现。设想一家电商每天新增 1 TB 点击日志、保留三年——约 1 PB。放在本地 SSD 集群上，钱和运维都扛不住；全放在归档层又意味着分析师查一次要等几小时。不懂存储的典型后果：

• 为不需要的性能付钱。把三年前几乎没人查的数据放在最贵的热存储里。
• 用错访问模式。拿对象存储当数据库，频繁改单条记录——每改一条就重写一个文件，又慢又贵。
• 被架构绑死。计算和存储绑在一起时，存储涨了只能连算力一起扩容。

核心内容，讲透

一、先看清三层：原料 → 系统 → 抽象

本章的骨架是一张分层图：最底层是原料（raw ingredients）——磁盘、SSD、内存、网络、CPU，以及序列化、压缩、缓存这些手段；中间是用原料搭起来的存储系统——文件存储、块存储、对象存储、HDFS、缓存、流存储；最上层是数据工程师直接打交道的存储抽象——数仓、数据湖、湖仓。作者的提醒是：别只在最上层选型，上层的性能与成本特性全来自下层。

二、原料：延迟差着数量级，缓存是对这个差距的回应

原料之间的差距不是几成，而是数量级：内存一次访问约 100 纳秒，SSD 约 0.1 毫秒，机械硬盘一次寻道约几毫秒，从对象存储读第一个字节通常要几十毫秒，归档层取回则以小时计。价格大致反过来排。于是有了书里的缓存层级思路：最热的数据放最快最贵的层，越冷越往下放。

另两个常被忽略的原料是序列化与压缩。同样一份数据，存成 CSV 还是列式的 Parquet，读取量可以差一个数量级；压缩则用 CPU 换磁盘和网络——在网络常是瓶颈的云上，通常划算。

三、行式 vs 列式：同一张表，两种摆法

行式把一条记录的所有字段连着存，适合「取一张订单的全部信息」这种事务访问；列式把同一列的值连着存，适合「对一列求和、过滤」这种分析访问。分析查询往往只碰几十列里的几列，列式只读这几列；同一列的值类型相同、重复多，压缩效果也好得多。代价是：改一行要动很多列文件，单行写入和更新很慢——所以列式格式天生适合「批量写、大量读」。

四、三种存储系统：文件、块、对象——重点是对象存储

文件存储是熟悉的目录树，支持随机读写与原地修改，云上有托管的网络文件系统。块存储是操作系统看到的「裸盘」，数据库和虚拟机的系统盘都建在它上面——云上的虚拟化块存储可以快照、挂载到实例；而实例自带的本地盘最快，但实例一停数据就没了。

对象存储（S3、GCS、Azure Blob）是本章分量最重的系统：数据以「对象」形式按键存放在扁平的桶里，对象不可变——不能改其中一部分，只能整件覆盖或删除。这个限制换来的是：几乎无限的容量、极高的并行读写吞吐（成百上千个任务同时读不同对象）、多副本带来的高持久性（S3 宣称的设计持久性是 11 个 9），以及按用量付费。它的短板是单次请求延迟高、不适合频繁小更新。S3 在 2020 年底改为强读后写一致性，此前写后立刻读可能读到旧版本——这是书里特别提醒的历史坑。对象存储还提供多个存储类别：标准、低频访问、归档，越冷越便宜，但取回更慢、还有取回费。

其余几种系统各有位置：HDFS 把大文件切块、多副本存在集群各节点上，并让计算就近执行（脱胎于 Google 的 GFS）；缓存（Memcached、Redis）把热数据放内存；流存储（Kafka）按保留期存事件，可回放。另外，数仓不再靠传统索引，而靠分区与聚簇——按日期切分、把相近的值放一起，让查询跳过大量不相关的数据块（如 Snowflake 的微分区）。

五、存储抽象：仓、湖、湖仓

数据仓库是结构严格、为分析优化的中心库；云数仓已经把存储放到对象存储之上、计算按需伸缩。数据湖把原始文件扔进对象存储，先存后定结构；第一代数据湖的教训是容易变成「数据沼泽」——没有事务、没有 schema 管理，改一条记录要重写整个分区。湖仓（lakehouse）是两者的合流：数据仍是对象存储上的开放列式文件，但上面加一层表格式（Delta Lake、Apache Iceberg、Apache Hudi），用元数据记录「哪些文件构成这张表的哪个版本」，从而支持事务、更新删除、schema 演化和时间旅行。书里还提到流转批存储架构：数据写进流存储，同时落到批存储供长期查询。

六、几条大趋势：分离、冷热、schema 的时机

计算与存储分离。旧的 Hadoop 时代讲「数据就近计算」（colocation）：数据在哪台机器，就在哪台机器上算。云把它倒过来：数据放对象存储，计算集群临时拉起、用完即毁（短暂集群），存储和算力各自扩展、各自计费。但作者强调，真实系统是混合的：云数仓会把热数据缓存到计算节点的本地 SSD，Spark 等引擎也会把中间结果放在本地盘——分离带来弹性，就近缓存找回速度。

数据生命周期与保留。按访问频率把数据分为热、温、冷三档，配合对象存储的生命周期规则自动降级；同时要按合规要求定保留期——该删的必须删，不只是省钱。

schema 的时机：写入时定结构（schema on write，数仓的做法）保证质量但不灵活；读取时定结构（schema on read，数据湖的做法）灵活但把解析的麻烦推给每个读者。此外书里还点到数据目录（让人找得到、看得懂数据）、数据共享（云数仓之间直接授权读，不拷贝）、零拷贝克隆（复制一张表只复制元数据），以及单租户 vs 多租户存储的隔离与成本取舍。

关键权衡与选型

表 1 · 三种存储系统

表 2 · 存储抽象

表 3 · 冷热分层

判据：先问访问模式（随机小更新还是大批扫描），再问数据多热、要留多久，最后问要不要多个引擎共用同一份数据——要，就倾向开放表格式的湖仓。

为什么重要 / 落到真实系统

面试里「每天 1 TB 日志、保留三年、分析师要能查」这类题，好的答案会这样落地：原始数据以 Parquet 写入对象存储、按日期分区；用表格式管理事务与 schema；近 30 天的数据由数仓或查询引擎缓存加速；一年以上的数据用生命周期规则降到归档层；计算集群按查询负载伸缩。每一步都对应本章的一个权衡。

易错点与争议

• 「对象存储就是一块很大的硬盘」。它不能原地修改、单次请求慢；当文件系统频繁小写，会又慢又贵。
• 「计算存储分离 = 不要本地盘」。真实系统都靠本地缓存找回速度，分离是混合而非绝对。
• 「列式总是更快」。对单行查询和高频更新，行式更合适；列式赢在大批扫描少数列。
• 「小文件无所谓」。上百万个 KB 级小文件会让元数据与请求数爆炸，湖仓要定期合并。
• 「归档便宜所以全扔进去」。取回费、最短存放期和小时级等待，可能让一次紧急查询比全年存储还贵。
• 「schema on read 就是不用管 schema」。结构问题只是推迟，并转嫁给每个读者。
• 时代局限。书出版于 2022 年，当时湖仓与各表格式之争还在早期；此后开放表格式被各大云数仓更广泛地支持，但「分离 + 缓存」的基本权衡并未改变。

要点