我们在讨论串起MapReduce工作流的算法时，一直忽略了一个重要的问题：当工作流结束后，处理结果是什么？我们一开始是为什么要跑这些任务来着？

事务型和分析型处理

对于数据库查询场景，我们会区分事务型处理场景（OLTP）和分析性场景（OLAP）。

OLTP场景下的查询通常只会涉及很小的一个数据子集，因此通常会使用索引加速查询，然后将结果展示给用户（例如，使用网页展示）。

OLAP场景下的查询通常会扫描大量的数据记录，执行分组（grouping）和聚集（aggregating）等统计操作，然后以报表的形式呈现给用户：比如某个指标随时间的变化曲线、依据某种排序方式的前十个数据条目、将数据按子类分解并统计其分布。这些报表通常会用于辅助分析员或者经理进行商业决策。

批处理

批处理既不是事务型，也不是分析型。从输入数据量的角度来说，批处理更接近分析型任务。一组MapReduce任务组成的执行流通常和用于分析型的SQL查询并不相同（参见Hadoop和分布式数据库的对比）。批处理的输出通常不是一个报表，而是另外某种格式的数据。

构建查询索引

谷歌发明MapReduce大数据处理框架的最初动机就是解决搜索引擎的索引问题，开始时通过5~10个MapReduce工作流来为搜索引擎来构建索引。尽管谷歌后面将MapReduce使用拓展到了其他场景，仔细考察构建搜索引擎索引的过程，有助于深入地了解MapReduce（当然，即使到今天，HadoopMapReduce仍不失为一个给Lucene/Solr构建索引的好办法）。

倒排索引是一个词表（thetermdictionary），利用该词表，你可以针对关键词快速地查出对应文档列表（thepostingslist）。索引还需要很多其他信息，包括相关度，拼写订正，同义词合并等等，但其背后的原理是不变的。

如果你想在一个固定文档集合上构建全文索引，批处理非常合适且高效：构建这种按文档分区（document-partitioned，与term-partitioned相对，参见分片和次级索引）的索引，可以很好地并发生成。由于使用关键词进行索引查询是一种只读操作，因此，这些索引文件一旦构建完成，就是不可变的（immutable）。

如果被索引的文档集发生变动，一种应对策略是，定期针对所有文档重跑全量索引构建工作流（workflow），并在索引构建完时使用新的索引对旧的进行整体替换。如果两次构建之间，仅有一小部分文档发生了变动，则这种方法代价实在有点高。但也有优点，索引构建过程很好理解：文档进去，索引出来。

我们也可以增量式的构建索引。如果你想增加、删除或者更新文档集，Lucene就会构建新的索引片段，并且异步地将其与原有索引进行归并（merge）和压实（compact）。

以KV存储承接批处理输出

搜索索引只是批处理工作流一种可能的输出。批处理其他的用途还包括构建机器学习系统，如分类器（classifiers，如废品邮件过滤，同义词检测，图片识别）和推荐系统（recommendationsystem，如你可能认识的人，可能感兴趣的产品或者相关的检索）。

这些批处理任务的输出通常在某种程度是数据库：如，一个可以通过用户ID来查询其可能认识的人列表的数据库，或者一个可以通过产品ID来查询相关产品的数据库。

最直观的做法是将批处理的结果导出为CSV文件，然后使用导入工具将数据导入到数据库中。但是，这种方法有一些缺点，例如效率低下和数据完整性问题。

一个更好的方法是使用分布式键值（KV）存储，如HBase或Cassandra。KV存储可以提供高吞吐量和低延迟的读写访问，并且可以轻松扩展到处理大量数据。批处理工作流可以将输出直接写入KV存储，然后web应用程序可以使用简单的API来查询数据。

结论

批处理工作流的输出可以在多种场景中使用，包括构建搜索索引、训练机器学习模型和承接web应用程序的查询。选择输出方法时，需要考虑数据大小、处理速度和数据一致性等因素。KV存储提供了一种高效且可伸缩的方法来承接批处理输出，并且可以轻松与web应用程序集成。

下面哪些是storm计算模型的使用场景

Storm是一个分布式的、可靠的、容错的数据流处理系统（流式计算框架，可以和mapreduce的离线计算框架对比理解）。 整个任务被委派给不同的组件，每个组件负责一个简单的特定的处理任务。 Storm集群的输入流是一个叫spout的组件负责接入处理。 spout把数据传给bolt组件，bolt组件可以对数据完成某种转化。 bolt组件可以把数据持久化，或者传送到其他的bolt。 可以把Storm集群想象成一个bolt组件链，每个组件负责对spout流入的数据（也可以是其他bolt流入的数据）进行某种形式的处理。 有个简单的例子可以说明这个概念。 昨晚我看新闻，节目中发言人在谈论政治家以及他们在不用领域的立场。 他们不停地在重复一些不同的名字，这时我想知道他们提到的每个名字出现的次数是否一样，还是在某些名字被提及次数更多。 把发言人的言语想象成数据的输入流。 我们可以定义一个spout从文件（通过socket、HTTP或者其他方式）读取这些输入。 当几行文本到来时，spout把它们传送给bolt，bolt负责把文本分词。 接着数据流被传送到另外一个bolt，这个bolt负责在一个已经定义好的政治家名单进行比对。 如果匹配到了，将数据库中对应的名字的计数加1。 任何时候你想看结果，只要从数据库中查询就可以，因为当数据到达时整个过程都是实时更新的。 这过程中所有的组件（spout和bolt）以及他们之间的连接被称为拓扑（topology）（见图表 1-1）。 现在很容易想象定义每个bolt和spout并行度，这样可以无限地扩展整个拓扑。 很神奇，对吧？尽管前面讲的只是一个简单的例子，不过你大概已经隐约感觉到Storm的强大了。 那么，Storm适用什么应用场景呢？数据流处理：正如上述的例子，Storm不像其他流处理系统，因为Storm不需要中间队列。 持续计算：持续地向客户端发送数据，它们可以实时的更新以及展现数据，比如网站指标。 分布式远程过程调用：轻松地并行化CPU密集型操作。 （补充）从业务场景上，举例说明Storm的可以处理的具体业务（这部分是黄崇远总结的，觉得比较全面，摘抄在此）条件过滤：这是Storm最基本的处理方式，对符合条件的数据进行实时过滤，将符合条件的数据保存下来，这种实时查询的业务需求再实际应用中很常见。 中间计算：我们需要改变数据中某一个字段（例如是数值），我们需要利用一个中间值经过计算（值比较、求和、求平均等等）后改变该值，然后将数据重新输出。 求TopN：相信大家对TopN类的业务需求也比较熟悉，在规定时间窗口内，统计数据出现的TopN，该类处理在购物及电商业务需求中，比较常见。 推荐系统：有时候在实时处理时会从mysql及hadoop中获取数据库中的信息，例如在电影推荐系统中，传入数据为：用户当前点播电影信息，从数据库中获取的是该用户之前的一些点播电影信息统计，例如点播最多的电影类型、最近点播的电影类型，及其社交关系中点播信息，结合本次点击及从数据库中获取的信息，生成推荐数据，推荐给该用户。 并且该次点击记录将会更新其数据库中的参考信息，这样就是实现了简单的智能推荐。 分布式RPC：Storm有对RPC进行专门的设计，分布式RPC用于对Storm上大量的函数进行并行计算，最后将结果返回给客户端。 批处理：所谓批处理就是数据积攒到一定触发条件，就批量输出，所谓的触发条件类似事件窗口到了，统计数量够了即检测到某种数据传入等等。 热度统计：热度统计实现依赖于Storm提供的TimeCacheMap数据结构，现在可能推荐用RotatingMap，关于这两个数据结构的源码分析，移步Storm TimeCacheMap RotatingMap源码分析，该结构能够在内存中保存近期活跃的对象。 我们可以使用它来实现例如论坛中热帖排行计算等。

在SQL数据库中，什么叫批处理？

批处理就是把一批SQL脚本按顺序执行！通常用GO来分割不同的批处理！