因为项目的需要，学习使用了 Hadoop，和所有过热的技术一样，“大数据”、“海量” 这类词语在互联网上满天乱飞。Hadoop 是一个非常优秀的分布式编程框架，设计精巧而且目前没有同级别同重量的替代品。另外也接触到一个内部使用的框架，对于 Hadoop 做了封装和定制，使得更满足业务需求。我最近也想写一些 Hadoop 的学习和使用心得，但是看到网上那么泛滥的文章，我觉得再写点笔记一样的东西实在是没有价值。倒不如在漫天颂歌的时候冷静下来看看，有哪些不适合 Hadoop 解决的难题呢？
这张图就是 Hadoop 的架构图，Map 和 Reduce 是两个最基本的处理阶段，之前有输入数据格式定义和数据分片，之后有输出数据格式定义，二者中间还可以实现 combine 这个本地 reduce 操作和 partition 这个重定向 mapper 输出的策略行为。可以增加的定制和增强包括：
- 输入数据和输出数据的强化，例如通过数据集管理起来，可以统一、合并各式数据集，甚至也可以给数据增加过滤操作作为初筛，事实上业务上的核心数据源是种类繁多的；
- 数据分片策略的扩展，我们经常需要把具备某些业务共性的数据放到一起处理；
- combine 和 partition 的扩展，主要是有一些策略实现是在很多 Hadoop 的 job 中都是通用的；
- 监控工具的扩展，这方面我也见过别的公司内部定制的工具；
- 通讯协议和文件系统的增强，尤其是文件系统，最好能用起来像接近本地命令一样，这样的定制在互联网上也能找得到；
- 数据访问的编程接口的进一步封装，主要也是为了更切合业务，用着方便；
- ……
这些定制从某种程度上也反应了 Hadoop 在实际使用中略感局限或者设计时无暇顾及的地方，但是这些都是小问题，都是通过定制和扩展能够修复的。但是有一些问题，是 Hadoop 天生无法解决的，或者说，是不适合使用 Hadoop 来解决的问题。
1、最最重要一点，Hadoop 能解决的问题必须是可以 MapReduce 的。这里有两个含义，一个是问题必须可以拆分，有的问题看起来很大，但是拆分很困难；第二个是子问题必须独立——很多 Hadoop 的教材上面都举了一个斐波那契数列的例子，每一步数据的运算都不是独立的，都必须依赖于前一步、前二步的结果，换言之，无法把大问题划分成独立的小问题，这样的场景是根本没有办法使用 Hadoop 的。
2、数据结构不满足 key-value 这样的模式的。在 Hadoop In Action 中，作者把 Hadoop 和关系数据库做了比较，结构化数据查询是不适合用 Hadoop 来实现的（虽然像 Hive 这样的东西模拟了 ANSI SQL 的语法）。即便如此，性能开销不是一般关系数据库可以比拟的，而如果是复杂一点的组合条件的查询，还是不如 SQL 的威力强大。编写代码调用也是很花费时间的。
3、Hadoop 不适合用来处理大批量的小文件。其实这是由 namenode 的局限性所决定的，如果文件过小，namenode 存储的元信息相对来说就会占用过大比例的空间，内存还是磁盘开销都非常大。如果一次 task 的文件处理较大，那么虚拟机启动、初始化等等准备时间和任务完成后的清理时间，甚至 shuffle 等等框架消耗时间所占的比例就小得多；反之，处理的吞吐量就掉下来了。（有人做了一个实验，参阅：链接）
4、Hadoop 不适合用来处理需要及时响应的任务，高并发请求的任务。这也很容易理解，上面已经说了虚拟机开销、初始化准备时间等等，即使 task 里面什么都不做完整地跑一遍 job 也要花费几分钟时间。
5、Hadoop 要处理真正的 “大数据”，把 scale up 真正变成 scale out，两台小破机器，或者几、十几 GB 这种数据量，用 Hadoop 就显得粗笨了。异步系统本身的直观性并不像那些同步系统来得好，这是显而易见的。所以基本上来说，维护成本不会低。
文章未经特殊标明皆为本人原创，未经许可不得用于任何商业用途，转载请保持完整性并注明来源链接 《四火的唠叨》
×Scan to share with WeChat
