大数据处理概述

大数据是时下的热门话题,你不说几句大数据都不好意思出门跟人打招呼,今天就抽空理理自己对于大数据处理的理解吧。
大数据,顾名思义就是一堆非常非常大的东西丢在那边,一堆杂乱,原始的数据,然后要求我们根据自己的业务要求,抽取并分析出价值来。看起来很简单的事情吧,是的,若是时间足够的话,我们可以慢慢的处理,最简单的就是线性的,之后是就二分,树结构查找,再快点就哈希。但是,在大数据面前,简单的使用上面的手段是不能满足实际的业务要求的。只好继续探索探索。

在分析这批数据,第一个从脑海中冒出的问题我们应该用什么工具来处理,第一就是使用什么语言来分析,这个时候就需要分析各自语言的各自特性及使用场景,从生态圈的繁荣程度来看,首选必然是java,活跃的开源社区为我们提供了很多产品来选择,MPI,PVM,HADOOP,SPARK等等OLAP处理框架的,以及hadoop延伸出来的hive,pig等等。都是我们快速处理大数据的产品,当然其他语言也都是可以的。

这些产品的最外层解决思路还是利用我们现在多核CPU的优势,尽情的提高CPU的利用率,并行就成为了必然。
并行的大致解决思路是:
1.数据的分割和分配
2.并行的处理数据
3.将已经处理的处理进行汇总
根据阿姆达尔定律:系统性能提升的效果,会随着无法并行的部分而饱和。所以我们能做的就是 尽量提升并行的性能。

那考虑的就是如何并行?采用线程或是进程?
线程的优势是是基于单进程下的,那么共享数据在多线程下是共享的,所以没有通信上的开销,性能会高点,但是它的缺点很明显,对于这些共享数据必须保证线程安全,而在多并发下即要求性能,又保证安全就成为一个很大的问题。同时在同一个进程内,若是其中一个线程的异常导致整个进程退出的话,会影响到其他的线程。再一个缺点是它的扩展限制于服务器的CPU核数,也就是说最大的并行度就是CPU的数量。

进程的优缺点就是线程的反面了,不共享内存,存在数据通信问题,性能上会稍微差点,但是是安全的。采用这种就必然考虑的是如何做进程间的通信了,常用了有TCP,UDP,AMQP等,这些通信有自己的实现方式,各自的优缺点,我们能做的就是在选择其中一项后,尽量深挖并优化。

到此为止:选择一种语言 + 通过线程或是进程的并行(或是开源的并行处理框架) + 存储,就可以构建起一套大数据处理的样子了。 那么剩下的就是尽量优化我们这种架构。
第一步从语言开始,既然选择的是java,我们必然了解的就是JVM的一些实现细节,如何做内存分配,如果处理内存回收等工作。要求我们要写出更符合JVM规范的代码。同时代码中数据的存储的结构和采用的算法也是一个非常大的因素。

第二,并行的核心是CPU,那么了解CPU的运行机制就是必修课了,采用SMP架构还是NUMA亦或MPP,各种架构的优点和各自的瓶颈在何处,都是需要深究的地方,同时服务器是采用X86架构的CISC指令集还是ARM架构的RISC指令集,两种的不同特性,也是花时间去了解的。

第三,存储,也是很大的一头。存储分两块,一个存储格式的选择,NOSQL or RDB ,还有就是存储的介质,SAS,SATA,SSD,内存?这两块就必须根据实际数据量的大小去考量,NOSQL这个是必然伴随着大数据的概念出现的,它们基本是砣不离秤。

再之后就是程序运行的环境了,服务器性能的优化,网络的跳转,交换机的配置等等。

通过以上各种手段,基本就能够满足大数据的处理了!从这个角度看,大数据真的是一盘很大的棋啊。中间要走N多的岔路,填很多的坑,慢慢长路。
再换个角度看,我们学习编程的初衷是什么?养活自己or纯粹的兴趣爱好?干软件的人是可怜的,因为追求一些东西,我们被各种语言折磨着,被各种硬件蹂躏着,我们总想着更靠近它们一点,以提高那么点性能。是不是很苦逼?所以写ruby的孩子是幸福的!

作者: inter12

在这苦短的人生中,追求点自己的简单快乐

发表评论

电子邮件地址不会被公开。 必填项已用*标注