1.5我们能处理多大的数据量
本章前述例子中，我们作了若干假设。比如，我们忽略了CPU时间。对于大多数的商业程序来说，计算的复杂性并不大。但是，随着计算量的提高，从实现的角度来看，各种情况的资源消耗都要考虑。举个例子，在数据挖掘中，会用到复杂的贝叶斯统计算法。这样的情况是计算密集型的应用。针对这样的问题，我们可以增加集群节点数量来提高性能，或者选用其他算法替代。
类似MapReduce这样的大数据计算编程范型可以被扩展到其他大数据计算技术中使用。比如，利用计算机的图形编程单元来进行计算机通用计算的技术（GPGPU）可以实现计算密集型应用程序的大规模并行计算。
我们还忽略了网络I/O开销。拥有50个节点的计算集群需要使用分布式文件系统，为了整合数据，这50台计算节点间的数据通信也是有开销的。在所有的大数据解决方案中，I/O开销是重中之重。在整个大数据处理流程过程中，这些开销消耗会导致串行依赖（Serial dependency）。
1.5.1一个计算密集型的例子
假设50个计算节点来处理200GB的数据，平均每个计算节点需要本地处理4GB的数据。每个节点读取这些数据要花费80秒（速率为每秒50MB）。无论我们的计算多快，这80秒是不能节省的。假设数据处理之后最终的结果数据集大小为200MB，每个计算节点平均产生4MB的计算结果。这些计算结果在带宽1Gbps（一个数据包大小为1M）的网络中传输并汇聚到一个节点以便展示结果。传输这些数据到目的节点需要花费3毫秒的时间（网络中传输1MB的数据需要250微秒，每个数据包的网络传输延时为500微秒，按照Jeff Dean博士之前发表的文章）。忽略计算耗时，整个数据计算流程耗时不低于40.003秒。
如果集群拥有4000个计算节点，平均每个计算节点需要本地读取处理500MB的数据，每个计算节点产生的结果数据量为0.1M。读取50MB的数据块不会少于1秒钟。这意味着，4000台计算节点的集群达到了数据处理速度的极限。换句话说，对于一些特定类型的数据处理问题，如果我们花4000个小时才能完成它，那么无论我们把集群节点数量增加多少，都不会把数据处理完成时间缩短到1小时内。4000台计算节点看起来很多了，但是这也是我们所能达到的速度上限了。在这个简单的例子中，我们做了很多使系统简化的假设。我们同样假设在程序逻辑中没有串行依赖（Serial dependencies），这样的假设往往是不成立的。一旦我们考虑了这些开销，系统的性能表现还可能会大幅下滑。
串行依赖（Serial dependencies）这个所有并行计算算法都存在的问题，严重限制了系统性能的提升。这样的限制已经为众人熟知，并表述为著名的Amdhal定律。
1.5.2Amdhal定律
就像光速被认为是人类在这世界上能达到的理论上的速度极值，Amdhal定律揭示了通过往集群增加更多计算节点的方法来提高集群性能的极限值。
Amdhal定律的完整描述详见：http://en.wikipedia.org/wiki/Amdahl抯_law。
这个定律可以简单描述为，假如一个给定的解决方案，其数据计算处理并行化程度的比例达到P（P的取值范围是0到1），在集群计算节点数量无限的条件下（或者说集群中有海量的计算节点），我们能获得的性能提升最大为1/（1-P）。这样，如果数据计算处理并行化程度的比例达到了99%，系统性能会提升100倍。所有的程序或多或少都会有串行依赖，再加上磁盘I/O和网络I/O的时间消耗。无论采用什么样的程序计算算法，我们能获得的系统性能提升都无法突破那个限制。