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