在第十章的时候，我们讨论了批处理——它总是读取一些文件作为输入，产生一些新文件作为输出。这里的输出就是一种“衍生数据”：即，如果有需要，我们可以通过再跑一遍批处理任务获取相同的结果集。从之前章节的讨论我们可以看出，这种思想简单却强大：像搜索引擎、推荐系统、分析系统等很多现代常见的数据系统都是基于这种思想构建的。然而，在第十章进行讨论时我们有一个很强的假设：输入数据集是有界的——即事先知道输入尺寸——因此批处理的程序知道输入何时结束。举个例子，MapReduce中非常重要的排序操作，就必须读入所有待排序的输入数据后才能开始排序并输出。这是因为，最后一条数据，没准可能是被需要排在最前面（具有最小的

批处理工作流的输出我们已经讨论了串起MapReduce工作流的一些算法，但我们忽略了一个重要的问题：当工作流结束后，处理结果是什么？我们一开始是为什么要跑这些任务来着？对于数据库查询场景，我们会区分事务型处理场景（OLTP）和分析性场景（OLAP，参见事务型还是分析型）。我们观察到，OLTP场景下的查询通常只会涉及很小的一个数据子集，因此通常会使用索引加速查询，然后将结果展示给用户（例如，使用网页展示）。另一方面，分析型查询通常会扫描大量的数据记录，执行分组（grouping）和聚集（aggregating）等统计操作，然后以报表的形式呈现给用户：比如某个指标随时间的变化曲线、依据某种排序方式

在分布式计算领域，共识问题是最重要而基础的问题。从表面上看含义很直接：可以粗略的理解为多个节点就某件事达成共识。乍看起来，你会觉得，这有什么难的？但不幸的是，很多系统都因为低估了共识算法的实现难度而问题百出。尽管共识问题非常之重要，但在本书中直到现在才才被提及，似乎有点晚了。这是因为这个主题实在是太艰深了，而欣赏其精妙需要非常多的前置知识。即使在学术界，对共识问题的研究也是历经数十年坎坷才逐渐有了一些沉淀。在本书里，我们在第五章铺垫了冗余（replication），在第七章铺陈了事务，在第八章探讨了分布式系统的系统模型，在本章又讨论了线性一致性和全序广播，到现在，我们终于做足了准备来好好谈谈共

零、开篇词欢迎各位，给大家分享一下自己最近读的书，ddia,全名叫做：designdata-intensiveapplication直译为：设计数据密集型应用；或者叫做，数据密集型应用的设计🎈为什么分享这本书🎈我相信在场的各位一定历经过这样的场景：春节档档期一下子上映了很多场电影，一场电影要不要去看，你是如何决策的？对于我来说呢，通常都是先看一下豆瓣评分，如果高的话，就买票入场，对吧，所以为什么选择分享这本书，那就不得不说下这本书0.1-关于ddia的溢美之词可以看到，这本书的评价惊人的高，居然达到了9.7分的高分，有的同学可能觉得9,7分并不是一个很高的分数，来看下面这部是个码农都知道的书《