大数据是时下的热门话题，你不说几句大数据都不好意思出门跟人打招呼，今天就抽空理理自己对于大数据处理的理解吧。
大数据，顾名思义就是一堆非常非常大的东西丢在那边，一堆杂乱，原始的数据，然后要求我们根据自己的业务要求，抽取并分析出价值来。看起来很简单的事情吧，是的，若是时间足够的话，我们可以慢慢的处理，最简单的就是线性的，之后是就二分，树结构查找，再快点就哈希。但是，在大数据面前，简单的使用上面的手段是不能满足实际的业务要求的。只好继续探索探索。
在分析这批数据，第一个从脑海中冒出的问题我们应该用什么工具来处理，第一就是使用什么语言来分析，这个时候就需要分析各自语言的各自特性及使用场景，从生态圈的繁荣程度来看，首选必然是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的孩子是幸福的！
1 条评论。