淘宝Fourinone和Hadoop的完整对比-CSDN博客

	fourinone-1.11.09	hadoop-0.21.0
体积	82K	71M
依赖关系	就一个jar,没有依赖	约12项jar包依赖
配置	就一个配置文件	较多配置文件和复杂属性
集群搭建	简单，每台机器放一个jar和配置文件	复杂，需要linux操作基础和ssh等复杂配置，还需要较多配置文件配置
计算模式	提供两种计算模式：包工头和工人直接交互方式，包工头和工人通过消息中枢方式交互，后者不需要工人节点可直接访问	计算更多倾向于文件数据的并行读取，而非计算过程的设计。JobTracke 跟TaskTracker直接交互，查询NameNode后，TaskTracker直接从Datanode获取数据。
并行模式	N*N，支持单机并行，也支持多机并行，多机多实例并行	1*N，不支持单机并行，只支持多机单实例并行
内存方式	支持内存方式设计和开发应用，并内置完整的分布式缓存功能	以hdfs文件方式进行数据处理，内存方式计算支持很弱
文件方式	自带文件适配器处理io	Hdfs处理文件io
计算数据要求	任意数据格式和任意数据来源，包括来自数据库，分布式文件，分布式缓存等	Hdfs内的文件数据，多倾向于带换行符的数据
调度角色	包工头，可以有多个，支持链式处理，也支持大包工头对小包工头的调度	JobTracke，通常与NameNode一起
任务执行角色	农民工，框架支持设计多种类型的工人用于拆分或者合并任务	TaskTracker，通常与Datanode一起
中间结果数据保存	手工仓库，或者其他任意数据库存储设备	Hdfs中间结果文件
拆分策略	自由设计，框架提供链式处理对于大的业务场景进行环节拆分数据的存储和计算拆分根据业务场景自定义	以64m为拆分进行存储，以行为拆分进行计算实现map接口，按行处理数据进行计算
合并策略	自由设计，框架提供农民工节点之间的合并接口，可以互相交互设计合并策略，也可以通过包工头进行合并	TaskTracker不透明，较少提供程序控制，合并策略设计复杂实现reduce接口进行中间数据合并逻辑实现
内存耗用	无需要制定JVM内存，按默认即可，根据计算要求考虑是否增加JVM内存	需要制定JVM内存，每个进程默认1G，常常namenode，jobtracker等启动3个进程，耗用3G内存
监控	框架提供多环节链式处理设计支持监控过程，通过可编程的监控方式，给于业务开发方最大灵活的监控需求实现，为追求高性能不输出大量系统监控log	输出较多的系统监控log，如map和reduce百分比等，但是会牺牲性能，业务监控需要自己实现
打包部署	脚本工具	上传jar包到jobtracker机器
平台支撑	支持跨平台，windows支持良好	多倾向于支持linux，Windows支持不佳，需要模拟linux环境，并且建议只用于开发学习
其他	协同一致性、分布式缓存、通讯队列等跟分布式计算关系密切的功能支持	不支持
总结：	Hadoop并不是为了追求一个并行计算的框架而设计，提供快捷和灵活的计算方式去服务各种计算场景，它更多的是一个分布式文件系统，提供文件数据的存储和查询，它的map/reduce更倾向于提供并行计算方式进行文件数据查询。而fourinone相反。

Fourinone和hadoop运行wordcount的对比测试（平均4核4g配置，输入数据为文件）：

	fourinone-1.11.09(n*4)	fourinone-1.11.09(n*1)	hadoop-0.21.0(n*1)
3台机器*256M	4s	12s	72s
3台机器*512M	7s	30s	140s
3台机器*1G	14s	50s	279s
19台机器*1G	21s	60s	289s
10台机器*2G	29s
5台机器*4G	60s