分治算法在海量数据处理中的应用

分治算法

核心思想就是分而治之，将原问题划分成 n 个规模较小，并且结构与原问题相似的子问题，递归地解决这些子问题，然后再合并结果，就得到原问题的解。

这个定义看起来有点类似递归。关于递归和分治的区别：分治算法是一种处理问题的思想，递归是一种编程技巧。实际上，分治算法一般都比较适合用递归来实现，分治算法的递归实现中，每一层递归都会涉及这样三个操作：

• 分解：将原问题分解成一系列子问题

• 解决：递归地求解各个子问题，若问题足够小，则直接求解

• 合并：将子问题的结果合并成原问题

分治算法能解决的问题，一般需要满足下面的这几个条件：

• 原问题与分解的小问题具有相同的模式

• 原问题分解成的子问题可以独立求解，这也是分治算法和动态规划的明显区别

• 具有分解终止条件，也就说，当问题足够小时，可以直接求解

• 可以将子问题合并成原问题，而这个合并操作的复杂度不能太高，否则就起不到减小算法总体复杂度的效果了

分治思想在海量数据处理中的应用

分治算法的典型应用场景，一个用来指导编码，降低问题求解的时间复杂度，另一个是解决海量数据处理问题。有些数据结构和算法是基于内存存储和单机处理。但是，如果要处理的数据量非常大，没法一次性放到内存中。

比如，给 10 GB 的订单文件按照金额排序这样一个需求，看似一个简单的排序问题，但是因为数据量大，有 10 GB，而我们的机器内存可能只有 2GB 或 3GB，无法一次性加载到内存中，也就无法单纯地通过快排、归并等基础算法来解决了。

 

要解决这种数据量大到内存装不下的问题，可以利用分治思想，将海量数据集合依据某种方法，划分成为几个小的数据集合，每个小的数据集合单独加载到内存来解决，然后再将小数据集合合并成大数据集合。实际上，利用这种分治的处理思路，不仅仅能克服内存的限制，还能利用多线程或者多机处理，加快处理的速度。

如果订单数据存储在类似 GFS（Google File System）这样的 Google 研发的可伸缩、高可用、高可靠的分布式文件系统上，当 10GB 的订单被划分成多个小文件的时候，每个文件可以并行加载到多台机器上处理，最后再将结果合并在一起，这样的并行处理速度也加快了很多。不过，这里有一个点要注意，就是数据的存储与计算所在的机器是同一个或者网络中靠的很近（比如一个局域网内，数据存取速度很快），否则就会因为数据的访问速度，导致整个处理过程不但不会变快，反而有可能变慢。

MapReduce

除此之外，MapReduce 的本质就是分治思想，刚才举的订单的例子，数据有 10GB 大小，可能给你的感受还不够强烈，那如果要处理的数据是 1T，10T，100T 这样子的，那一台机器处理的效率肯定是非常低的。而对于 Google 搜索引擎来说，网页爬取、清晰、分析、分词、计算权重、倒排索引等等各个环节中，都会面对如此海量的数据（比如网页）。所以利用集群并行处理显然是大势所趋。

一台机器过于低效，那我们就把任务拆分到多台机器上处理。如果拆分之后的小任务之间互不干扰，独立计算，最后再将结果合并，这不就是分治思想吗？

实际上，MapReduce 框架只是一个任务调度器，底层以来 GFS 来存储数据，以来 Borg 管理机器，它从 GFS 中拿数据，交给 Borg 中的机器执行，并且时刻监控机器执行的进度，一般机器出现宕机、进度卡壳等，就重新从 Borg 中调度一台机器来执行。

尽管 MapReduce 的模型非常简单，但是在 Google 内部应用非常广泛，它除了可以用来处理这种数据与数据之间存在关系的任务，比如 MapReduce 的经典例子，统计文件中单词出现的频率。除此之外，它还可以处理数据与数据之间没有关系的任务，比如对网页分析、分词等，每个网页可以独立的分析、分词，而这两个网页之间并没有关系。网页几十亿、上百亿，如果单机处理效率低下，就可以利用 MapReduce 提供高可靠、高性能、高容错的并行计算框架，并行地处理这几十亿、几百亿的网页 。