这一章在做什么

读之前：先预测

这是全书的第一章，不讲具体机制，先交代后面十三章都要用的眼光和词汇。第 2 章接着把「到底要什么」说清楚：性能、可靠、可扩展、好维护。这一章立下的业务与分析之分，到第 4 章变成两类截然不同的存储引擎；记录系统和派生数据，是第 11 到 13 章的主线；分布式的麻烦留到第 9 章细讲；法律和伦理在第 14 章展开。

1. 分析师为什么不直接去查业务数据库？至少找出三条理由。§1.2
2. 什么样的数据丢了也不要紧？一份数据算正本还是派生，取决于用的数据库，还是别的什么？§1.3
3. 云服务最大的缺点是什么？什么条件下自己部署反而更便宜？§2.1
4. 「多加几台机器」在什么情况下反而更慢、更难排查？§3.1

这一章的骨架

这一章是四组「A 对 B」，彼此独立，每一组都是先讲一边的好处，再讲它的代价。容易乱的是前两组：§1 里数据仓库、数据湖、HTAP、记录系统一个接一个出场；§2 在讲完云的利弊之后，插进一大段存算分离和运维的变化。先认准每组的两端，再把这些名词挂上去。

边读边填：每行一个问题，读到答案就写一两句。只存在你这台设备的浏览器里，别人看不到。

分节地图

全章约 1 万词，建议分三次读，每次对应一到两组对比。第一次最长、新名词最多；第二次讲云，书里的例子多是具体的产品名，读起来快；第三次把分布式和法律与社会放在一起，后者篇幅不长。

1. 第一次坐下§0–§1.3 · 约 4100 词 · 业务系统和分析系统，数据从哪来、到哪去
2. Data is central to much application…约 1000 词开篇什么叫数据密集型应用，这本书帮你做哪类决定，本章四组对比的清单。方框里解释前端和后端。
3. Operational Versus Analytical Systems约 500 词业务系统和分析系统和数据打交道的几类人，以及全书都会用到的「业务／分析」二分。
4. Characterizing Transaction Processing and Analytics约 700 词事务处理和分析各是什么样「事务」一词的来历，点查和扫描汇总两种访问模式，嵌进产品里的实时分析。
5. Data Warehousing约 1500 词数据仓库为什么把分析搬到单独的库：ETL、HTAP、数据湖，以及数据怎么流回业务系统。本章最长的一节。
6. Systems of Record and Derived Data约 500 词记录系统和派生数据哪份数据是正本，哪些丢了能重建。全书后半部分的伏笔。
7. 第二次坐下§2–§2.3 · 约 2900 词 · 云还是自建，云改变了什么
8. Cloud Versus Self-Hosting约 300 词上云还是自己部署买还是自己做：从完全自研到完全外包，中间有好几档。
9. Pros and Cons of Cloud Services约 800 词云服务的利与弊什么时候云更省钱，什么时候自建更划算；「失去控制」具体指哪几种情况。
10. Cloud Native System Architecture约 1100 词云原生的系统架构在底层云服务上搭高层服务；存储和计算为什么拆开；多租户的好处和难处。
11. Operations in the Cloud Era约 600 词云时代的运维运维的目标没变，干的活变了。抓住「容量规划变成了什么」。
12. 第三次坐下§3–§5 · 约 3300 词 · 单机还是分布式，再加上法律和社会
13. Distributed Versus Single-Node Systems约 500 词分布式还是单机走向多台机器的九条理由。读的时候分一分：哪些躲不掉，哪些是可选的。
14. Problems with Distributed Systems约 400 词分布式系统的麻烦请求会超时，排查难，跨服务的一致性落到应用头上；单机为什么常常够用。
15. Microservices and Serverless约 700 词微服务和无服务器拆成服务的好处、代价和它真正解决的问题；无服务器把按量计费带到了代码执行上。
16. Cloud Computing Versus Supercomputing约 400 词云计算和超级计算超算在故障处理、信任和网络上，和云走了不同的路。
17. Data Systems, Law, and Society约 900 词数据系统、法律与社会隐私法规怎么伸进系统设计；存数据的成本为什么不只是账单。
18. Summary约 400 词小结全章回顾。先自己回忆一遍四组对比，再读它。

先用中文过一遍

两种用数据的方式：一条条地改，一大片地算

拿一个外卖平台来想。用户下单、骑手接单，后端按订单号取出一条记录，改一个状态，再写一行新的；每秒成千上万次，每次只碰几行，要快。周一早上，运营想知道「上个月每个城市的午餐营业额」：一条查询扫过几千万行订单，只用其中两三列，最后得到几十个汇总数字。前一种叫在线事务处理（OLTP），后一种叫分析，书里也提到它的另一个叫法：在线分析处理（OLAP）。

两种查询都能用 SQL 写，早年也确实跑在同一个库里。后来分开，是因为挤在一起互相伤害：分析的大扫描会拖慢线上用户；一家大企业的业务系统可能有几十上百个，数据各在各的库里，一条查询拼不起来。于是有了数据仓库：把各个业务库的数据抽出来（定期导出，或者持续同步改动），整理成方便分析的样子，导入一个单独的库，这个过程叫 ETL。业务系统里的查询是写死在代码里的那几种，分析师则想到什么查什么，这也是两边的一个区别。

正本和派生：数据从哪来，丢了能不能重建

一份数据第一次写进来的地方，叫记录系统（system of record），也叫事实来源：每个事实在这里只记一次，别处和它对不上，以它为准。从它加工出来的东西，缓存、搜索索引、数据仓库里的表、用这些数据训练的模型，都是派生数据。派生数据严格说是冗余的，丢了可以从正本再算一遍。

冗余并不等于浪费。同一批订单，搜索要按菜名找，看板要按城市汇总，推荐要按用户口味，各要一种摆法，只靠正本哪一种都快不起来。麻烦在于正本一改，派生的那些都得跟着改，而很多数据库默认你只用它一个，不帮你把改动传出去（第 11 章回到这个问题）。还有一点容易想错：一个库是不是正本，不看它是什么数据库，只看它在你的系统里扮演什么角色。

数据仓库之外还有数据湖：数据科学家要把数据变成训练模型用的特征，要处理评论文本和图片，关系表和 SQL 不顺手。数据湖只放文件，不规定格式和模式，数据保持业务系统产出时的「生」样子，谁用谁加工。分析出来的结果有时还会流回业务系统，比如训练好的推荐模型部署到线上，这叫反向 ETL。

存储和计算拆开

传统的做法里，一台机器既管存（磁盘）又管算（CPU 和内存）。写进磁盘就当它不会丢，怕坏盘，就用 RAID 在同一台机器上多存几份。到了云上，这个假设站不住了：虚拟机坏了，或者为了应付负载换成更大的规格（搬到另一台物理机上），原来的本地盘就够不着了。所以云原生系统通常把本地盘当临时缓存。

云厂商也提供能从一台虚拟机卸下、挂到另一台上的虚拟磁盘，传统数据库因此能直接搬上云。但它其实是另一群机器在模仿一块盘，每次读写都是一次网络调用，网络稍一抖动就感觉得到。云原生的数据库换了个思路：把很多值打包成大块，写进对象存储（S3 这类），零碎的小值交给单独的服务；计算节点按需起停，不再和数据绑在一起。代价是数据要经网络搬到计算的地方，这把话题引向了 §3。

什么时候才该上多台机器

用多台机器的理由，书里列了九条。有几条躲不掉：用户各拿各的设备，系统天然就是分布式的；有的国家要求本地人的数据存在本地。另外几条是可选的：数据大到一台机器装不下、要容错、要离用户近、要按负载伸缩。可选的那几条要掂量代价：每次跨网络的调用都可能失败，超时以后你不知道对方到底收没收到，贸然重试未必安全；调用另一台机器比调用本进程里的函数慢得多；出了问题要先查清是哪一环慢；每个服务有自己的库时，跨服务的数据一致性就成了应用自己的事。

微服务是同一个取舍在组织层面的版本：系统按服务拆开，每个服务一个团队、一个接口，可以各自上线；代价是每个服务都要有自己的部署、监控、告警，接口改起来也牵一发动全身。无服务器（serverless）再进一步，连机器的起停都交给云厂商，按代码实际运行的时间计费。

书里还拿超级计算机（高性能计算）和云对照。超算多用来跑天气、气候、分子模拟这类大批量的科学计算，一个节点坏了，常见的做法是把整个任务停下，修好再从上一个检查点接着算；云上的服务要一直在线，不能这样停。两边对信任、网络的假设也不一样。

这一章点名的系统

词与短语

词条按在书里出现的顺序排，按节分组；读一节之前先把这一节的过一遍，读的时候就不用停。斜体小字是原句里连续的几个词，在电子书里搜它就能找到那一句。标着「每个字都认识」的，是字面意思会把你带偏的。行话（compaction、quorum 这类）不在这里，在上面的术语表里。

§0 Data is central to much application…

§1 Operational Versus Analytical Systems

§1.1 Characterizing Transaction Processing and Analytics

§1.2 Data Warehousing

§1.3 Systems of Record and Derived Data

§2 Cloud Versus Self-Hosting

§2.1 Pros and Cons of Cloud Services

§2.2 Cloud Native System Architecture

§2.3 Operations in the Cloud Era

§3 Distributed Versus Single-Node Systems

§3.1 Problems with Distributed Systems

§3.2 Microservices and Serverless

§3.3 Cloud Computing Versus Supercomputing

§4 Data Systems, Law, and Society

§5 Summary

读完：回到你的预测

判断题：换成你来选

场景都是本站编的。先选，再看解释；解释里写了对应的节号，拿不准就回原书看那一节。

和本站其他书对照

值得停下来的句子

no one approach is fundamentally better than others; everything has pros and cons.— §0。本站译：没有哪一种做法从根本上比别的更好，一切都有利有弊。

这句话是全书的立场，也是这一章的写法：四组对比，没有一组给出「选 A」的结论，只给出判断时要问的问题。读后面的章节时，它提醒你别去找「最好的数据库」：LSM 树和 B 树、各种复制方式，书里都按这个口径讲，选哪个取决于你的负载和你的团队。

Microservices are primarily a technical solution to a people problem: allowing different teams to make progress independently without having to coordinate with each other.— §3.2。本站译：微服务首先是用技术手段解决人的问题：让不同的团队各自推进，不必彼此协调。

谈微服务时，人们常争的是性能、扩展性和技术栈；作者把它的主要价值放在组织上。这样一来判断就清楚了：团队少的公司拿不到这份好处，却要付全部的代价，包括部署、监控、接口演化和跨服务的一致性。这句话也点出全章的一条暗线：架构决定往往是人和组织的决定，不只是技术的。

检查一下理解

用一句话说这一章（写给一个没读过的朋友）：

精彩回顾

一句话：数据系统里没有标准答案：分不分开、上不上云、要不要多台机器、存不存这份数据，每个选择都要说清省了什么、付在哪。