为什么要使用MapReduce?

        在对各种日志进行统计时，逻辑通常是比较简单的，当文件存储在hdfs上时，就会被切分成许多block,针对一个具体存储节点，一般是存储的是某个文件的某个块，因此，在这种情况下做统计，永远是一个局部的数据，如果客户端读文件的每个block，最后做统计，就变成了一个单机版，用单机版处理动辄几十G的文件时，除了内存需求的问题，速度也会变得非常慢，由此看来，专门写客户端去做统计肯定不合适，应该是把程序分发到每台机器上，也就是把运算往数据去移动，而不是把数据往运算移动，运算逻辑移动到数据，就是我们说的分布式了，每一部分产生的运算结果都只是局部的结果，但是这样，面临的第一个问题就是代码怎么分发到各个运算节点上去运行，能否用U盘把你的jar包一个节点一个节点的去拷贝，然后启动运行，如果节点数量比较大，启动到最后一台时，第一台已经运算结束了，看来，用手动的方式去做是不合适的，所以，当一个简单的逻辑变成分布式后，会面临代码分发、启动环境配置、启动方式等等诸多问题，需要额外开发一个负责代码分发、环境配置、程序启动的系统，耗费代价肯定比较大，现在数据都已经存储在hdfs上，但是不代表每个节点都有你要处理的那个文件的block，当集群较大时，某些节点有你要处理文件的block,其它节点上就没有，我们的代码最好能在有数据的节点上运行，如果在其它节点运行，要处理的数据肯定来自网络，效率会比较低，代码究竟要分发到哪些节点上运行，要有一个策略，实现这个策略，要有一个算法，为了实现一个逻辑简单的统计工作，又要开发一个策略系统，现在我们回头看，就算这些问题都解决了，所有节点都工作了，其中一个节点宕机了，那么统计这部分局部数据就没有了，那汇总肯定就不对了，因此必须还要时时刻刻监控着程序的运行情况，哪些节点正常，哪些节点不正常，假设这个问题也解决了，统计数据还有一个汇总的问题，针对一条或几条统计需求，是放在一个台节点上汇总，还是放在几台节点上汇总，这中间还需要数据调度系统，所以，一个很简单的逻辑，如果变成分布式，会面临许多与业务逻辑无关的问题，mapreduce就是为了解决这些问题的架构，让开发人员能够只关心来务逻辑，处理字符串，查询数据库等等。