|
|
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 |
|
|
說明：Fourinone可以充分利用單機並行能力，4覈計算機可以4個並行實例計算，hadoop目前只能N*1；另外，可以由上圖看出，如果要完成20g的數據，實際上fourinone只需要使用5臺機器用60秒完成，比使用19臺機器完成19g的hadoop節省了14臺機器，並提前了200多秒
demo源碼和開發包下載：
http://www.skycn.com/soft/68321.html