大数据流式处理一个不能忽视的问题

       我的上一篇BLOG《大数据处理的两种模式》，谈了大数据基于内存的流式处理和基于硬盘的存储处理。比较这两种处理模式，因为内存的处理性能是硬盘的N个量级，所以流式处理效率要远远高于存储处理，但是流式处理本身有一个缺点，或者说是隐忧，上次没有提到，今天来说一下。
      这要从数据处理的基本面：内存、存储、数据谈起。
      大家都知道,一个大数据集群是由很多台计算机连上网络组成的。计算机里面都有CPU、内存、硬盘，计算机通过网络交换数据执行分布计算工作。集群会按照规则，同时运行着一批执行不同工作的分布计算任务，每次分布计算任务处理的数据容量也不尽相同，少的几十几百M，多的几十几百G，更大的有时候会达到TB的规模（我们在各地部署的Laxcus集群时常处理TB级的数据）。如果当集群中某个时刻迸发出一个超大数据容量的计算任务，这些数据要分散到不同的计算机上去执行计算工作，这个总的数据容量超过集群的内存容量的时候，怎么办？
      在存储模式下，这个问题很容易解决：拿硬盘来做缓存过渡。数据进来，检查一下它的尺寸，如果太大，或者一时半会儿处理过不来，就先放到硬盘保存起来。毕竟现在硬盘都已经做到TB级，不差钱的话，一台计算机还可以多配几个。能够利用的存储空间比内存大得多。
      放到了流式处理模式下，这个问题就纠结了。如果数据进入后硬盘再处理，就和存储模式没啥区别了。如果不是这样，数据就会太多而内存不足，内存就要溢出，数据就要丢失。集群里任何一台计算机出现这样的故障，整个分布计算任务就是失败。
      缓解这个问题的一个办法是升级计算机，CPU换成64位的，然后装更多的内存。原因是32位计算机内存上限是4G，一个集群里，如果都是32位计算机，同时出现几个TB计算任务，那得要多少台计算机？64位计算机可以装更多内存，这样计算机数量可以少些。还顺带提醒一下，虽然内存的价格现在比以前是大大便宜了，但是和硬盘相比，单位容量还是贵得多！这样的成本问题一般运营商会比较在意。另外，这只是暂时的解决办法，谁也不知道下一次的超大数据计算任务啥时候发生，和同时会有几个这样的超大计算任务发生。
      比较靠谱的解决办法是在任务计算前，在数据量和集群内存之间做一个评估。当计算任务进来的时候，判断一下它携带数据的最大尺寸，如果集群的内存足够，就把这些内存"预分配"给这个计算任务（这个工作要细划到每一台计算机）。如果不够，就让它等着，直到其它计算任务完成工作，内存被回收，新的内存足够时，才放它执行工作。第二种办法和存储模式差不多，数据先放在硬盘里存着，然后也是等到内存足够了，再执行它的工作。当然，这两种办法都会降低流式处理的计算效率，但也是没有办法的办法，总比出现内存溢出、计算任务失败这样的故障好吧。
       综上所述，流式处理是一种成本和效费比都高的计算模式。如果你是土豪，像BAT一样，有足够的银子，只关注数据处理的高性能，不在乎往基础设施上多撒几个钱，尽可以配上强劲的CPU、超大的内存和硬盘或者固态盘，万兆的光纤网络，这时候加上流式处理是上选。如果你是一穷人，缺银子，计算机的性能差，手上一把的32位老式计算机（我们有一个Laxcus集群现在还在用PentiumIII图拉丁芯片，就因为这家伙省电，老而弥坚！），内存有限，网络也不咋的，掏不起太多的电费，不计较数据计算的快和慢，那么凑合凑合，还是考虑存储模式吧。