ddia/part-iii.md

# 第三部分：衍生数据

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

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

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

## 记录系统和衍生数据系统

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

* 记录系统（System of record）

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

* 衍生数据系统（Derived data systems）

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

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

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

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

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

## 章节概述

我们将从 [第十章](ch10.md) 开始，研究例如 MapReduce 这样 **面向批处理（batch-oriented）** 的数据流系统。对于建设大规模数据系统，我们将看到，它们提供了优秀的工具和思想。[第十一章](ch11.md) 将把这些思想应用到 **流式数据（data streams）** 中，使我们能用更低的延迟完成同样的任务。[第十二章](ch12.md) 将对本书进行总结，探讨如何使用这些工具来构建可靠，可伸缩和可维护的应用。

## 索引

10. [批处理](ch10.md)
11. [流处理](ch11.md)
12. [数据系统的未来](ch12.md)


------

| 上一章                         | 目录                            | 下一章                    |
| ------------------------------ | ------------------------------- | ------------------------- |
| [第九章：一致性与共识](ch9.md) | [设计数据密集型应用](README.md) | [第十章：批处理](ch10.md) |