终于来到这本书最后的一章了《Designing Data-Intensive Applications》大部头，这本书应该是我近两年读过最棒的技术书籍。作者Martin Kleppmann帮助我们梳理了数据系统的纷繁复杂的技术逻辑，在这本书的最后，他将带领我们瞭望数据系统的未来,虽然预测未来是一件很主观的事情，但是，立足于现在去展望未来是可能的事情。所以现在，扬帆起航，让咱们来一起看看作者 Martin Kleppmann 眼中数据系统的未来、

1.因地制宜的工具

对于任何给定的数据问题，总会有多种解决方案。所有这些解决方案都会有不同的优缺点和权衡。因此，最合适的软件工具选择也要视情况而定。每一个软件，甚至一个所谓的“通用”数据库，都是为特定的使用模式而设计的。所以，在复杂的应用程序中，数据工具通常会串联起来共同工作。不存在有一个软件适合于使用数据的所有不同环境，因此不可避免地要将几个不同的软件串联在一起，以便更好帮助应用程序工作。

数据流

当需要在多个数据系统中维护相同的数据副本时，为了满足不同的存储需求时，需要非常明确的界定系统的输入和输出：首先写入的数据在何处，哪些表示来自哪个来源？

举个栗子：数据通常会首先写入数据库系统，之后捕获对数据库的更改，然后按相同顺序将更改应用到搜索索引之中。如果捕获数据更改是更新索引的唯一方法，那么就可以确信索引的数据流完全来自数据库，因为数据库的写入操作是向系统提供输入的唯一方法。但是假若允许应用程序直接写入搜索索引，由两个不同数据源同时发送写请求，就很容易出现写冲突，则很容易导致数据的出现不一致，后续需要花大量的功夫来避免这些不一致性。所以通过单个系统来输入所有的输入，那么通过以相同的顺序处理写操作，就可以更容易地派生出数据的其他表示形式。维护程序的输入流很大程度上会简化数据系统的模型。

从另一个角度来说，使用派生数据流的方式同样能够实现分布式事务。在抽象的层面上，通过不同的方法达到了同样的目标。分布式事务通过一个互斥锁，与原子提交来确保数据一致性，而数据流通过日志进行操作排序与操作幂等性来确保数据一致性。 两者最大区别在于：事务能够提供线性化，也就是最强的一致性等级。而数据流的派生系统通常是异步执行的，很难提供最终的时间担保。。所以在愿意承担分布式事务成本的环境中，事务是最优的选择，但是也真是因为分布式事务的成本，严重限缩了它的实用性。

作者认为：在缺乏对良好的分布式事务协议的广泛支持的情况下，基于数据流的派生数据系统是来集成不同数据系统的或许是将来能够大放异彩的方法。（数据流派生系统本质上是最终一致性的模型，所以作者显然看好最终一致性的模型是未来数据系统的发展趋势，最终一致性的模型在对一致性要求不严格的场景下确实是大大提高开发效率与简化系统模型的好方式。）

有序日志的限制

在一个较小的数据系统之中，构建一个有序的事件日志是完全可行的。然而，随着系统向着更大和更复杂的系统扩展时，会出现一些问题。在绝大多数的情况下，构造一个完全有序的日志需要所有事件都通过一个决定顺序的Leader 节点，但如果事件产生的吞吐量大于一台机器所能处理的吞吐量，则需要在多台机器上进行日志分区。此时问题就出现了，两个不同分区日志之中的事件顺序是不明确的。

而如果服务器分布在多个地理上分散的数据中心，为了降低数据中心通信延迟的情况下，可以在每个数据中心的设一个独立的Leader，而因为网络延迟等问题。两个不同的数据中心的事件日志也很难进行排序，一个未定义的排序。同样的，如前文的例子一样，当两个事件源于不同的数据系统，事件是很难定义顺序的。

全序事件的广播，本质上相当于协商一致性。而绝大多数共识算法都是针对单个节点的吞吐量足以处理整个事件流的情况而设计的，而这些算法并没有提供多个节点共享事件排序工作的机制。所以设计一致性算法的问题仍然是一个开放的研究问题，它可以超越单个节点的吞吐量，并且在地理分布的环境中工作得很好。

2.数据的计算

数据系统本质的目标是确保数据以正确的形式出现在所有正确的地方。这样做需要工程师做出很大的努力，处理输入、转换、连接、过滤、聚合、训练模型、评估，并最终产生恰当的输出。

批处理和流处理

批处理和流处理的输出的都是派生的数据集，如搜索索引、物化视图、向用户显示的建议等。批处理和流处理有许多共同的原则，主要的根本区别是流处理器在无界数据集上操作，而批处理输入是已知的、有限的大小数据。

函数式状态

批处理具有相当强的函数式功能性：它鼓励确定性的纯函数，其输出只依赖于输入，而不会产生额外的副作用。流处理，保持了函数性，并且扩展了操作符，所以可以通过重新计算实现容错。 具有明确的输入和输出确定性函数的原理不仅是容错性好，还简化了数据流的推断过程，所以很适合作为派生数据系统的输入。

派生的数据系统可以同步维护，就像关系数据库在同一事务中同步更新次要索引一样，将其写入索引表中。但是，异步模型同样可以用日志实现容错，而不会使错误扩张, 而分布式事务在任何一个参与者失败时中止，因此分布式事务会扩展到系统的其余部分导致故障的放大。

渐变式过渡

在维护派生数据系统时，批处理和流处理可以结合使用。 流处理可以输入的变化时低延迟的反馈在新视图之上，而批处理允许积累的大量历史数据进行再进行处理以获得新的数据集。

通过批处理与流处理作为工具组合，可以对现有数据进行再处理，并将其演进为支持新特性和新需求的数据系统。并将数据集重构为完全不同的模型，以便更好地满足新的需求。 派生视图允许渐进演化: 如果要重构数据集，则不需要突然切换来执行迁移。相反的是，可以将旧模式和新模式并排为建立在同一个数据集上的两个独立的派生视图。一开始，可以开始将少量用户转移到新的数据视图中，以便测试其性能并发现任何bug，而大多数用户继续被使用旧的数据视图。逐步地进行渐变式的过渡，增加访问新数据视图的用户比例，最终删除旧的数据视图。

这种渐进迁移的美妙之处在于：如果出现了问题，这个过程的每个阶段都是可逆的。

Lambda架构

Lambda体系结构是目前分布式计算领域流行的一个解决思路，它的核心思想是：通过将不可变事件附加到不断增长的数据集之上，并从这些事件中派生出读取优化的视图。Lambda体系结构建议并行运行两个不同的系统：一个批处理系统，如MapReduce和一个单独的流处理系统，如Storm。在Lambda体系之中，流处理器消耗事件并快速生成对视图的近似更新；而批处理处理器随后消耗相同的事件集，并生成派生视图的修正版本。 这种设计背后的原因是：批处理更简单，因此不容易出现bug，而流处理器被认为不可靠，难以实现容错。流处理可以使用快速近似算法，而批处理过程使用较慢的精确算法。

但是Lambda架构也存在一些实际的问题：

• 必须保持流处理与批处理具有相同的逻辑。

• 由于流处理和批处理都产生单独的输出，进行数据合并的逻辑可能会相对复杂。

3.再探计算与存储

存储的最终目的是为了服务计算，计算最终的结果也可以写入存储。所以我们再在一个更高的角度，重新看存储与计算。

元数据库

整个系统之中的所有数据流开始看起来像一个巨大的数据库系统。每当批处理、流处理或ETL将数据从一个地方传输到另一个地方时，类似于数据库子系统，保持索引或物化视