并行计算和实时处理：并非增加机器那么简单

大数据由于体量大、维度多，处理起来计算量巨大，它的使用效率取决于并行计算的水平。我们在前面提到了Google的MapReduce（编程模型）和雅虎的Hadoop（海杜普）等工具，它们能够把相当一部分大型计算任务拆成若干小任务在很多并行的服务器上运算。这确实给大数据处理带来了福音，但是并没有完全解决计算瓶颈的问题。在一般人想象中，增加10倍的处理器并行计算，可以同样成倍地节省时间，但是在工程上这是做不到的。

首先，任何一个问题总有一部分计算是无法并行的，这类计算占比越大，并行处理的效率越低。在计算机科学中，通常用可并行比例（Parallel Portion）来度量在一个任务中有多少是可以并行计算的，有多少不能。图5.12给出了在不同的可并行比例下，并行计算处理器的数量和实际加速（speed up）之间的关系。从图中可以看出，如果在一个任务中能够并行处理的比例越高，实际的加速越多，但是即便只有5%的计算不能并行，那么无论使用多少台服务器，实际的加速也不会超过20倍。

图5.12 在不同的可并行比例下，增加处理器数量和实际加速的关系曲线

另一个影响并行计算效率的因素在于无法保证每个小任务的计算量是相同的。例如，我们要进行两个1000000×1000000的大矩阵相乘，一台服务器显然难以完成这样的任务，因此我们使用MapReduce或者Hadoop在1万台服务器上进行并行计算。我们通常会把这个大矩阵按照行或者列分成1万份，每份100行（列），每个服务器上分一份。但是，虽然一个服务器上的任务看上去都是计算100行（列），但是这些小任务的计算量未必均衡，其中一个是另外一个的两三倍是一件很常见的事情。这样一来，并行计算的效率就大打折扣——完成了自己计算任务的服务器，在等待个别尚未完成计算的服务器。最终的计算速度取决于最后完成的子任务。如果考虑到一些子任务会因为系统不稳定出现计算错误需要重新计算，并行计算的效率还会进一步降低。因此，并行计算的时间是远远做不到和服务器数量成反比。事实上，使用的处理器越多，并行计算的效率越低。

大数据处理的另一个挑战是对实时性的要求。一些看似简单的操作一到大数据头上就特别费时间。比如过去用Excel（数据处理软件）在几万行数据中找到最大值只要一两秒钟的时间，排个序所需要的时间也不过十几秒钟。但是在一个几千万行的电商销售日志中要找到销量最好的商品，或者将商品按照销量排一个序，即使采用上千倍的处理器，也不可能在几秒或者几十秒内完成。这里面的原因除了我们前面提到的并非所有的计算都可以并行化之外，还因为早期的大数据都是存储在硬盘上的，而且并行计算工具，比如MapReduce或者Hadoop，都是批处理形式的。通常上述操作的处理时间至少要几十分钟，这对离线的数据分析可能不是一个大问题，但是如果公司主管想实时了解经营情况，这个等待时间就无法忍受了。要解决实时处理大数据的问题，就需要从根本上改变系统设计和算法，而不是增加机器那么简单。事实上对任何大数据问题都做到实时处理是不可能的，但是对于很多特定问题，比如对于日志等结构化或者半结构化数据，还是有可能的。比如，Google为了解决上述问题，专门设计了一个被称为Dremel92的工具，专门针对日志、数据库等大数据，解决实时访问和简单的数据处理问题。与传统的文件系统或者数据库不同的是，它的文件是基于内存的而不是硬盘的，而且在数据的存放上和传统数据库系统不同，Dremel采用以数据列为优先的方式存储，而传统的数据库系统是以行为优先方式存储的。Dremel这样的特殊设计是为了方便多维度数据按照某个特定维度进行处理和数据挖掘。当然，类似Dremel的工具还有很多，通过它我们只是想说明针对大数据的实时处理需要开发很多新的工具，而不是简单地把过去的工具并行化就可以。