或者几、十几GB这种数据量，5Hadoop要处理真正的大数据”把scaleup真正变成scaleout两台小破机器。用Hadoop就显得粗笨了异步系统自身的直观性并不像那些同步系统来得好，这是显而易见的所以基本上来说，维护利息不会低。

学习使用了Hadoop和所有过热的技术一样，因为项目的需要。大数据”海量”这类词语在互联网上满天乱飞。Hadoop一个非常优秀的分布式编程框架，设计精巧而且目前没有同级别同重量的替代品。另外也接触到一个内部使用的框架，对于Hadoop做了封装和定制，使得更满足业务需求。最近也想写一些Hadoop学习和使用心得，但是看到网上那么泛滥的文章，觉得再写点笔记一样的东西实在没有价值。倒不如在漫天颂歌的时候冷静下来看看，有哪些不适合Hadoop解决的难题呢？

Map和Reduc两个最基本的处置阶段，这张图就是Hadoop架构图。之前有输入数据格式定义和数据分片，之后有输出数据格式定义，二者中间还可以实现combin这个外地reduc操作和partit这个重定向mapper输出的战略行为。可以增加的定制和增强，例如通过数据集管理起来，输入数据和输出数据的强化。可以统一、合并各式数据集，甚至也可以给数据增加过滤操作作为初筛，事实上业务上的核心数据源是种类繁多的

经常需要把具备某些业务共性的数据放到一起处置；数据分片战略的扩展，主要是有一些策略实现是很多Hadoopjob中都是通用的combin和partit扩展，这方面我也见过别的公司内部定制的工具；监控工具的扩展。

尤其是文件系统，通讯协议和文件系统的增强。最好能用起来像接近外地命令一样，这样的定制在互联网上也能找得到。主要也是为了更切合业务，数据访问的编程接口的进一步封装。用着方便；但是这些都是小问题，这些定制从某种水平上也反应了Hadoop实际使用中略感局限或者设计时无暇顾及的地方。都是通过定制和扩展能够修复的但是有一些问题，Hadoop天生无法解决的或者说，不适合使用Hadoop来解决的问题。

Hadoop能解决的问题必需是可以MapReduc这里有两个特别的含义，最最重要一点。一个是问题必需可以拆分，有的问题看起来很大，但是拆分很困难；第二个是子问题必需独立—很多Hadoop教材上面都举了一个斐波那契数列的例子，每一步数据的运算都不是独立的都必需依赖于前一步、前二步的结果，换言之，无法把大问题划分成独立的小问题，这样的场景是根本没有方法使用Hadoop

作者把Hadoop和关系数据库做了比拟，数据结构满意足key-valu这样的模式的HadoopInAction中。结构化数据查询是不适合用Hadoop来实现的虽然像Hive这样的东西模拟了ANSISQL语法）即便如此，性能开销不是一般关系数据库可以比较的而如果是复杂一点的组合条件的查询，还是不如SQL威力强大。编写代码调用也是很花费时间的

namenod存储的元信息相对来说就会占用过大比例的空间，3Hadoop不适合用来处置大批量的小文件。其实这是由namenod局限性所决定的如果文件过小。内存还是磁盘开销都非常大。如果一次task文件处置较大，那么虚拟机启动、初始化等等准备时间和任务完成后的清理时间，甚至shuffl等等框架消耗时间所占的比例就小得多；反之，处置的吞吐量就掉下来了有人做了一个实验，参阅：链接），高并发请求的任务。这也很容易理解Hadoop不适合用来处置需要及时响应的任务。上面已经说了虚拟机开销、初始化准备时间等等，即使task里面什么都不做完整地跑一遍job也要花费几分钟时间。