Laxcus大数据管理系统2.0版本推出有两个多月了，最近做了一次使用情况调查，发现最受欢迎的竟是流式处理。这大大出乎我们推出新版本时的预料。因为当时新版本推出时，流式处理只是做为磁盘数据处理的一项辅助功能而附带提供的，而且最初设计流式处理时，技术上也并没有花太多心思，因为它很容易实现，只是改变一下数据处理流经的路线而已。不过现在想想，再看看当下SPARK火热的情况，流式处理大热也就不奇怪了，毕竟更多更快更强的大数据处理效果是大家共同追求的目标。举一个例子，我们一个合作伙伴，原来做一次大数据计算，大概需要一两个小时的时间，现在改用了流式处理，同样的数据量，只用几分钟就搞掂了，计算效率一下子提升了几十倍。这样的数据处理，不招人喜欢才怪！
不过做为大数据技术开发者和运营管理者，对于流式处理，我们却要冷静对待，下面就从技术和运维的角度，来说一说我自己的看法。
流式处理的好处这里就不说了，大家都已经看得到：快！仅凭这一点，就足以让没有耐心的用户心满意足。
下面主要说一说“弊”的方面。
大家应该都知道，流式处理是以内存取代硬盘来达到快速处理效果的。不管现在任何流式处理产品，包括SPARK、STORM、SAMZA，它们怎么说自己的产品与别人有什么不同，这个根本的相同点是回避不了的，这是流式处理所以能够快的根本原因。
在一台计算机里，以存储容量比较，内存是少数，硬盘是多数，这样的例子，我们看看自己用的PC就知道。一台PC，现在硬盘容量最少也是1TB了，但是内存呢，不过几个GB的数量，两者相差近千倍。这种情况在云服务器上也一样，每台服务器，可以分配给用户的空间基本都是足够的，即使偶尔不足，也可以通过负载均衡的办法，分散到其它机器上来弥补。但是内存就不同了，内存在大多数的时候是不足的，而且在不足的情况下，还要满足多个用户的数据请求，每个用户实际分到的内存就更少。而流式处理加入进来后，实际的结果是，把原来分配给多个用户的内存资源，全部分配给一个用户来使用，其他需要内存的用户，因为没有内存可用，将被迫进入等待状态，直到这个用户完成后，才能继续使用。所以，从业务公平和数据公平角度来说，流式处理的这种做法是不合理的。这有点象社会上某些现象，为了满足某些个体的私利，而牺牲掉公众的利益。呵呵。当然，如果是自己搭建集群，只为自己业务服务的，那就另说。
还有一点是流式处理比较尴尬的，这在所有流式处理中都存在，但是我看过很多介绍流式处理的文章，不知他们是有意回避还是其它什么原因，被提及的并不多，也需要各位加以注意：回到根本，流式处理实质仍然是一个分布的计算过程，它的计算过程中，在集群中的作用节点肯定不会是一个，而是N个，这样就要求所有节点都必须同时满足操作流式处理所需要的内存，当任何一个节点不能满足流式处理要求的内存时，这个节点的流式处理将被迫转向磁盘，恢复成磁盘数据处理过程。虽然只是一个节点，但是根据木桶短板原理，这次流式处理的总处理时间将被这个节点拖累，实际的处理时间与磁盘处理无异，并不能达到流式处理的要求。这种现象，目前各种流式处理都无法完全避免，尤其当面临多用户多任务竞用环境的时候。
可以解决这个问题的办法是“预约”。就是在执行计算工作前，先评估一下这次流式计算所需要的内存总量，然后启动一个“代理”工具，到每台计算机上去检查剩余内存，如果符合要求，就锁定这台计算机的内存，检查全部达标后，批准此次流式处理。不过这样又产生新的问题：就是如果内存不足的时候，流式处理任务将被迫转入等待；或者实际内存不能满足要求时，仍然要回到磁盘处理的老路。这样的处理办法，将造成与快速计算的目标相悖。但是目前看，也只能是这样了。
再从运营商的角度来谈谈流式处理。
大家应该都知道，同样单位容量情况下，内存比硬盘太贵多了。这个情况大家可以打开淘宝看看，1TB的硬盘和1TB的内存，它们的价差是多少。此前我们给一个云服务商做预案时做一个测算，以一个中型集群（1000台服务器为单位）来计算，如果提供相对适中、让用户感觉比较顺畅的流式处理，仅内存一项，就是增加一百万元人民币以上的成本。况且在实际部署时，云服务商要部署的集群通常不只一个，那样增加的内存成本就更高。所以，实际上除了阿里、腾讯这样超级土豪级别的公司，没有几个云服务商肯接受这样的成本预案。
最后总结说一句：能不能在大数据集群中执行流式处理，使用户获得满意的快速计算能力，更大的成分，并不是技术问题，而是钱的问题，它和集群所有者兜里的银子成正比。这和金融、地产是一样的，没钱就别玩！
中国广州超算中心的天河2号
美国能源部橡树岭国家实验室的Titan
中国的天河2，美国的Titan，所以有这么强的性能，都是拿银子堆出来的。这样超一流硬件条件，做起超级计算、流式计算、超大规模数据存取工作来，自然是得心应手。
扫一扫
1491
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
