在SIP项目设计的过程中，对于它庞大的日志在早先就考虑使用任务分解的多线程处理模式来分析统计，在前面有一篇Blog中提到了那部分的设计，但是由于统计的内容暂时还是十分简单，所以就采用Memcache作为计数器结合Mysql完成了访问控制以及统计的工作。但未来，对于海量日志分析的工作，还是需要有所准备。现在最火的技术词汇莫过于“云计算”，在Open API日益盛行的今天，互联网应用的数据将会越来越有价值，如何去分析这些数据，挖掘其内在价值，就需要分布式计算来支撑起海量数据的分析工作。
回过头来看，早先那种多线程，多任务分解的日志分析设计，其实是分布式计算的一个单机版缩略，如何将这种单机的工作分拆，变成集群工作协同，其实就是分布式计算框架设计所涉及的。在去年参加 BEA的大会时候，BEA和VMWare合作采用虚拟机来构建集群，无非就是希望使得计算机硬件能够类似于应用程序中的资源池中的资源，使用者无需关心资源的分配情况，最大化了硬件资源的使用价值。分布式计算也是如此，具体的计算任务交由哪一台机器执行，执行后由谁来汇总，这都由分布式框架的Master 来抉择，而使用者只需简单的将待分析内容的提供给分布式计算系统作为输入，就可以得到分布式计算后的结果。 hadoop是Apache开源组织的一个分布式计算开源框架，在很多大型网站上都已经得到了应用，亚马逊，Facebook,Yahoo等等。对于我来说，最近的一个使用点就是服务集成平台的日志分析，服务集成平台的日志量将会很大，这也正好符合了分布式计算的适用场景(日志分析，索引建立就是两大应用场景)。
当前没有正式确定使用，所以也是自己业余摸索，后续所写的相关内容，都是一个新手的学习过程，难免会有一些错误，只是希望记录下来可以分享给更多志同道合的朋友。
What is Hadoop
搞什么东西之前，第一步是要知道What，然后是Why,最后才是How，但很多开发的朋友在做了多年项目以后，都习惯是先How，然后What，最后才是Why，这样只会变得浮躁，同时往往会将技术误用不适合的场景。
Hadoop框架中最核心设计就是：MapReduce和HDFS。MapReduce的思想是由Google的一篇论文所提及而被广为流传的，简单的一句话解释MapReduce就是任务的分解与结果的汇总。HDFS是Hadoop分布式文件系统的缩写，为分布式计算存储提供了底层支持。
MapReduce从它名字上来看就大致可以看出个缘由，两个动词Map,Reduce，Map(展开)就是将一个任务分解成为多个任务，Reduce就是将分解后多任务处理的结果汇总起来，得出最后的分析结果。这不是什么新思想，其实在前面提到了多线程，多任务的设计就可以找到这种思想的影子。不论是现实社会，还是在程序设计中，一项工作往往可以被拆分成为多个任务，任务之间的关系可以分为两种：一种是不相关的任务，可以并行执行;另一种是任务之间有相互的依赖，先后顺序不能够颠倒，这类任务是无法并行处理的。回到过去，大学老师上课时让大家去分析关键路径，无非就是找最省时的任务分解执行方式。在分布式系统中，机器集群就可以看作硬件资源池，将并行的任务拆分交由每一个空闲机器资源去处理，能够极大地提高计算效率，同时这种资源无关性，对于计算集群的扩展无疑提供了最好的设计保证。(其实我一直认为Hadoop的卡通图标不应该是一个小象，应该是蚂蚁，分布式计算就好比蚂蚁吃大象，廉价的机器群可以匹敌任何高性能的计算机，纵向扩展的曲线始终敌不过横向扩展的斜线)。任务分解处理以后，那就需要将处理以后的结果在汇总起来，这就是Reduce要做的工作。
图 1 MapReduce
上图就是MapReduce大致的结构图，在Map前还可能会对输入的数据有split的过程，保证任务并行效率，在Map之后还会有shuffle的过程，对于提高Reduce的效率以及减小数据传输的压力有很大的帮助。后面会具体提及这些部分的细节。
HDFS是分布式计算的存储基石，Hadoop的分布式文件系统和其他分布式文件系统有很多类似的特质。
