设计数据密集型应用-Data-Intensive Application

不懂数据库的全栈工程师不是好架构师              —— Vonng

周六停更 Spring Boot 从入门到实践系列教程

读一本好书《设计数据密集型应用》- Designing Data-Intensive Application

简称：DDIA        

                                                            在正确的时候读一本合适的书是一种幸运~

• 作者： Martin Kleppmann

• 原书名称：《Designing Data-Intensive Application》

• 译者：冯若航

• Gitbook地址：https://legacy.gitbook.com/book/vonng/ddia-cn/details（需要科学上网）

• 建议使用Typora或Gitbook以获取最佳阅读体验。                                                                                                                                                           

 

这本书的作者是少有的从工业界干到学术界的牛人，知识面广得惊人，也善于举一反三，知识之间互相关联，比如有个地方把读路径比作programming language的lazy evaluation而写路径比作eager evaluation，令人拍案。这一本数囊括了几乎所有数据处理相关工作中可能遇到了的内容，而且也有非常棒的实操经验。比如书的一开始，作者反复强调监控中分位数的作用，可以揭示一些被平均数掩盖的事实，我也正好有一个监控从都是监控平均值变成主要监控若干p99分位数的经历，看到这里，不由得掩卷叹息。

 

这本书循循善诱的写作手法应该是相当高超了，讲解得非常深入浅出，一般照着提出问题 -> 解决方案 -> 这个方案的长处短处 -> 发散到其它方案这个模式讲解，看起来可以说是不知不觉，非常轻松，也没有有些作者的拽文习惯，几乎全部是中学词汇，句子也不复杂，保证非英语母语的人可以流畅阅读，这点可以说是非常良心了。

 

作者在最后一小节还讨论了大数据的伦理问题，尽管现实世界中，金钱利益面前，可能无人理会这些事情，但是这些夫子自道，还是很体现作者情怀。我觉得这是升华整本书的地方。

每一个数据工程师和产品经理都应该把最后一节，Doing the right thing，读十遍。

 

为了说服大家为什么值得读十遍，我摘抄几句：

automated systems can systematically and arbitrarily exclude a person from participating in society without any proof of guilt, and with little chance of appeal

machine learning is like money laundering for bias

when services become good at predicting what content users want to see, they may end up showing people only opinions they already agree with, leading to echo chambers in which stereotypes, misinformation, and polarization can breed

 

Data is the pollution problem (as in Industrial Revolution) of the information age

作者最后说：

we should stop regarding users as metrics to be optimized, and remember that they are humans who deserve respect, dignity and agency.

做一个有情怀的工程师当如是啊！

 

内容简介

第一部分 数据系统的基石

本书前四章介绍了数据系统底层的基础概念，无论是在单台机器上运行的单点数据系统，还是分布在多台机器上的分布式数据系统都适用。

1. 第一章将介绍本书使用的术语和方法。可靠性，可扩展性和可维护性 ，这些词汇到底意味着什么？如何实现这些目标？

2. 第二章将对几种不同的数据模型和查询语言进行比较。从程序员的角度看，这是数据库之间最明显的区别。不同的数据模型适用于不同的应用场景。

3. 第三章将深入存储引擎内部，研究数据库如何在磁盘上摆放数据。不同的存储引擎针对不同的负载进行优化，选择合适的存储引擎对系统性能有巨大影响。

4. 第四章将对几种不同的 数据编码进行比较。特别研究了这些格式在应用需求经常变化、模式需要随时间演变的环境中表现如何。

 

第二部分： 分布式数据

在本书的第一部分中，我们讨论了数据系统的各个方面，但仅限于数据存储在单台机器上的情况。现在我们到了第二部分，进入更高的层次，并提出一个问题：如果多台机器参与数据的存储和检索，会发生什么？

你可能会出于各种各样的原因，希望将数据库分布到多台机器上：

可扩展性

如果你的数据量、读取负载、写入负载超出单台机器的处理能力，可以将负载分散到多台计算机上。

容错/高可用性

如果你的应用需要在单台机器（或多台机器，网络或整个数据中心）出现故障的情况下仍然能继续工作，则可使用多台机器，以提供冗余。一台故障时，另一台可以接管。

延迟

如果在世界各地都有用户，你也许会考虑在全球范围部署多个服务器，从而每个用户可以从地理上最近的数据中心获取服务，避免了等待网络数据包穿越半个世界。

 

扩展至更高的载荷

如果你需要的只是扩展至更高的载荷（load），最简单的方法就是购买更强大的机器（有时称为垂直扩展（vertical scaling）或向上扩展（scale up））。许多处理器，内存和磁盘可以在同一个操作系统下相互连接，快速的相互连接允许任意处理器访问内存或磁盘的任意部分。在这种共享内存架构（shared-memory architecture）中，所有的组件都可以看作一台单独的机器。

i. 在大型机中，尽管任意处理器都可以访问内存的任意部分，但总有一些内存区域与一些处理器更接近（称为非均匀内存访问（nonuniform memory access, NUMA）。 为了有效利用这种架构特性，需要对处理进行细分，以便每个处理器主要访问临近的内存，这意味着即使表面上看起来只有一台机器在运行，分区（partitioning）仍然是必要的。 

共享内存方法的问题在于，成本增长速度快于线性增长：一台有着双倍处理器数量，双倍内存大小，双倍磁盘容量的机器，通常成本会远远超过原来的两倍。而且可能因为存在瓶颈，并不足以处理双倍的载荷。

共享内存架构可以提供有限的容错能力，高端机器可以使用热插拔的组件（不关机更换磁盘，内存模块，甚至处理器）——但它必然囿于单个地理位置的桎梏。

另一种方法是共享磁盘架构（shared-disk architecture），它使用多台具有独立处理器和内存的机器，但将数据存储在机器之间共享的磁盘阵列上，这些磁盘通过快速网络连接ii。这种架构用于某些数据仓库，但竞争和锁定的开销限制了共享磁盘方法的可扩展性【2】。

ii. 网络附属存储（Network Attached Storage, NAS），或存储区网络（Storage Area Network, SAN） 

无共享架构

相比之下，无共享架构（shared-nothing architecture）（有时称为水平扩展（horizontal scale） 或向外扩展（scale out））已经相当普及。在这种架构中，运行数据库软件的每台机器/虚拟机都称为节点（node）。每个节点只使用各自的处理器，内存和磁盘。节点之间的任何协调，都是在软件层面使用传统网络实现的。

无共享系统不需要使用特殊的硬件，所以你可以用任意机器——比如性价比最好的机器。你也许可以跨多个地理区域分布数据从而减少用户延迟，或者在损失一整个数据中心的情况下幸免于难。随着云端虚拟机部署的出现，即使是小公司，现在无需Google级别的运维，也可以实现异地分布式架构。

在这一部分里，我们将重点放在无共享架构上。它不见得是所有场景的最佳选择，但它是最需要你谨慎从事的架构。如果你的数据分布在多个节点上，你需要意识到这样一个分布式系统中约束和权衡 ——数据库并不能魔术般地把这些东西隐藏起来。

虽然分布式无共享架构有许多优点，但它通常也会给应用带来额外的复杂度，有时也会限制你可用数据模型的表达力。在某些情况下，一个简单的单线程程序可以比一个拥有超过100个CPU核的集群表现得更好【4】。另一方面，无共享系统可以非常强大。接下来的几章，将详细讨论分布式数据会带来的问题。

复制 vs 分区

数据分布在多个节点上有两种常见的方式：

复制（Replication）

在几个不同的节点上保存数据的相同副本，可能放在不同的位置。 复制提供了冗余：如果一些节点不可用，剩余的节点仍然可以提供数据服务。 复制也有助于改善性能。 第五章将讨论复制。

分区 (Partitioning)

将一个大型数据库拆分成较小的子集（称为分区（partitions）），从而不同的分区可以指派给不同的节点（node）（亦称分片（shard））。 第六章将讨论分区。

复制和分区是不同的机制，但它们经常同时使用。如图II-1所示。

图II-1 一个数据库切分为两个分区，每个分区都有两个副本

理解了这些概念，就可以开始讨论在分布式系统中需要做出的困难抉择。第七章将讨论事务(Transaction)，这对于了解数据系统中可能出现的各种问题，以及我们可以做些什么很有帮助。第八章和第九章将讨论分布式系统的根本局限性。

在本书的第三部分中，将讨论如何将多个（可能是分布式的）数据存储集成为一个更大的系统，以满足复杂的应用需求。 但首先，我们来聊聊分布式的数据。

 

第三部分：衍生数据

在本书的第一部分和第二部分中，我们自底向上地把所有关于分布式数据库的主要考量都过了一遍。从数据在磁盘上的布局，一直到出现故障时分布式系统一致性的局限。但所有的讨论都假定了应用中只用了一种数据库。

现实世界中的数据系统往往更为复杂。大型应用程序经常需要以多种方式访问和处理数据，没有一个数据库可以同时满足所有这些不同的需求。因此应用程序通常组合使用多种组件：数据存储，索引，缓存，分析系统，等等，并实现在这些组件中移动数据的机制。

本书的最后一部分，会研究将多个不同数据系统（可能有着不同数据模型，并针对不同的访问模式进行优化）集成为一个协调一致的应用架构时，会遇到的问题。软件供应商经常会忽略这一方面的生态建设，并声称他们的产品能够满足你的所有需求。在现实世界中，集成不同的系统是实际应用中最重要的事情之一。         

记录和衍生数据系统

从高层次上看，存储和处理数据的系统可以分为两大类：

记录系统（System of record）

记录系统，也被称为真相源（source of truth），持有数据的权威版本。当新的数据进入时（例如，用户输入）首先会记录在这里。每个事实正正好好表示一次（表示通常是标准化的（normalized））。如果其他系统和记录系统之间存在任何差异，那么记录系统中的值是正确的（根据定义）。

衍生数据系统（Derived data systems）

衍生系统中的数据，通常是另一个系统中的现有数据以某种方式进行转换或处理的结果。如果丢失衍生数据，可以从原始来源重新创建。典型的例子是缓存（cache）：如果数据在缓存中，就可以由缓存提供服务；如果缓存不包含所需数据，则降级由底层数据库提供。非规范化的值，索引和物化视图亦属此类。在推荐系统中，预测汇总数据通常衍生自用户日志。

从技术上讲，衍生数据是冗余的（redundant），因为它重复了已有的信息。但是衍生数据对于获得良好的只读查询性能通常是至关重要的。它通常是非规范化的。可以从单个源头衍生出多个不同的数据集，使你能从不同的“视角”洞察数据。

并不是所有的系统都在其架构中明确区分记录系统和衍生数据系统，但是这是一种有用的区分方式，因为它明确了系统中的数据流：系统的哪一部分具有哪些输入和哪些输出，以及它们如何相互依赖。

大多数数据库，存储引擎和查询语言，本质上既不是记录系统也不是衍生系统。数据库只是一个工具：如何使用它取决于你自己。记录系统和衍生数据系统之间的区别不在于工具，而在于应用程序中的使用方式。

通过梳理数据的派衍生关系，可以清楚地理解一个令人困惑的系统架构。这将贯穿本书的这一部分。

 

第四部分：关于作者

Martin Kleppmann是英国剑桥大学分布式系统的研究员。此前他曾在互联网公司担任过软件工程师和企业家，其中包括LinkedIn和Rapportive，负责大规模数据基础架构。在这个过程中，他以艰难的方式学习了一些东西，他希望这本书能够让你避免重蹈覆辙。

Martin是一位常规会议演讲者，博主和开源贡献者。他认为，每个人都应该有深刻的技术理念，深层次的理解能帮助我们开发出更好的软件。

                                  

 

 

更快更新请关注我公众号：be_coder 

公众号：【转行程序员】专注新人转行入门指导，老兵技术提升，包含各种新手学习资料，架构师技能提升系列文章，欢迎关注。