文章编号：915 / 更新时间：2023-12-22 01:34:45 / 浏览：次

批量处理工作流的结果

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

对于数据库查询场景，我们会区分事务性处理场景（OLTP）和分析性场景（OLAP，参见事务型还是分析型）。我们观察到，OLTP场景下的查询通常只会涉及很小的一个数据子集，因此通常会使用索引加速查询，然后将结果展示给用户（例如，使用网页展示）。另一方面，分析性查询通常会扫描大量的数据记录，执行分组（grouping）和聚合（aggregating）等统计操作，然后以报告的形式呈现给用户：比如某个指标随时间的变化曲线、依据某种排序方式的前十个数据条目、将数据按子类分解并统计其分布。这些报告通常会用于辅助分析员或者经理进行商业决策。

那批量处理处于一个什么位置呢？它既不是事务性，也不是分析性。当然，从输入数据量的角度来说，批量处理更接近分析性任务。然而，一组MapReduce任务组成的执行流通常和用于分析性的SQL查询并不相同（参见Hadoop和分布式数据库的对比）。批量处理的结果通常不是一个报告，而是另外某种格式的数据。

构建查询索引

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

我们在全文索引和模糊索引一节粗策略的探讨过像Lucene这样的全文索引引擎是如何工作的：倒排索引是一个词表（thetermdictionary），利用该词表，你可以针对关键词快速地查出对应文档列表（thepostingslist）。当然，这是一个很简化的理解，在实践中，索引还需要很多其他信息，包括相关度，拼写订正，同义词合并等等，但其背后的原理是不变的。

如果你想在一个固定文档集合上构建全文索引，批量处理非常合适且高效：

构建这种按文档分区（document-partitioned，与term-partitioned相对，参见分片和次级索引）的索引，可以很好地并发生成。由于使用关键词进行索引查询是一种只读操作，因此，这些索引文件一旦构建完成，就是不可变的（immutable）。

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

当然，我们也可以增量式地构建索引。我们在第三章讨论过，如果你想增加、删除或者更新文档集，Lucene就会构建新的索引片段，并且异步地将其与原有索引进行合并（merge）和压实（compact）。我们将会在第十一章就增量更新进行更深入的讨论。

以键值存储承接批量处理结果

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

相关标签： DDIA、

本文地址：https://www.rixiy.com/article/d456f5d16dcf6ac22808.html

上一篇：组件?React如何设计更优雅的...
下一篇：五红汤打豆浆可以天天喝吗五红汤打豆浆和煮...