Total segment size in the interval (MB)Segment number in theinterval in log10
3.6 計算節點之實體結構
在實際的實驗環境，我們觀察到可能造成執行時間不平衡的另一可能因素是因為 虛擬機器間資源競爭所導致。實驗裡每台實體機器設定有八個計算節點，每個節點的 vCPU 與 vMemory 都有給予專屬使用量，且令此資源的分配在處理資料時都不會用完，
也就是說這兩項資源不會是 Bottleneck。但是我們目前採用 commodity PC 的架構下一 台實體機器只有一顆硬碟、一個讀寫頭，當一台實體上的所有 VM 們皆需要同時讀取 硬碟資料時就會讓 Disk I/O 變成是一個瓶頸，導致同一台實體機器上的計算節點就算 擁有相同待處理資料量也會有完成時間的差異。
表 9 中列出 Q1 與 Q2 中各實體機器上計算節點執行完成順序。我們可以在 Q1 的 實體機器 1 上發現到就算計算節點 5 與計算節點 7 被分配到相同的待處理資料量但其 執行時間卻相差約 23%；而 Q2 的實體機器 1 上計算節點 4 與計算節點 2 也有同樣的狀 況發生。這狀況正說明了就算各計算節點擁有相同計算資源與工作量的情況下，但因 Disk I/O 的競爭導致各計算節點有先後執行完成的狀況。
0 10 20 30 40 50 60 70
0 10 20 30 40 50 60 70
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
W or kloa d ( MB )
Ex ec T im e (se c)
Worker ID
Size w/ estimation (Avg:27MB, MeanDifference:11MB)
Size wo estimation (Avg:57MB, Mean Difference:6MB)
Exec Time w/ estimation size (Avg:40s, Mean Difference:8s)
Exec Time wo estimation size (Avg:40s, Mean Difference:9s)
49
Phy ID
Earliest Latest
1 W4(27,24) W5(19,30) W1(19,31) W6(22,32) W7(19,37) W3(17,37) W2(37,39)
2 W8(19,36) W13(22,36) W15(17,40) W10(19,40) W9(18,40) W14(17,41) W12(37,41) W11(19,41) 3 W19(19,35) W23(22,35) W21(23,37) W17(19,39) W22(30,39) W17(19,39) W20(19,40) W16(63,55) 4 W31(19,37) W25(19,39) W29(44,40) W24(17,41) W27(35,42) W28(27,44) W26(15,46) W30(63,54)
(a) Q1
Phy ID
Earliest Latest
1
(1-7)
W4(20,26) W5(22,30) W1(20,33) W6(20,33) W2(20,37) W7(20,39) W3(49,43)
2
(8-15)
W15(21,33) W13(20,37) W11(20,38) W14(20,38) W12(20,38) W9(20,39) W10(23,45) W8(63,57)
3
(16-23)
W19(24,34) W21(20,36) W18(20,38) W16(20,40) W23(43,44) W22(20,47) W17(20,51) W20(63,57)
4
(24-31)
W24(20,36) W29(27,37) W25(26,40) W30(20,40) W27(20,41) W31(20,42) W26(20,42) W28(63,48)
(b) Q2
表 9、Q1 與 Q2 其實體機器上各計算節點執行完成順序，從最早排到最後 (Workload in MB, Exec Time in Sec)
為了了解實體機器上各虛擬機間 Disk I/O 存取競爭所造成影響，我們設計了一 個實驗，讓每一台虛擬機的計算節點在沒有其他虛擬機的情形下獨立執行，以測量得 該計算節點於隔離環境下的執行時間，視為最基本（最小）的執行時間，作為 Baseline 參考，以釐清 Disk I/O 競爭影響。每台計算節點的工作量依然不變，只是現在每台實 體機器一次只會有一個計算節點執行，比較結果顯示在圖 21。
50
(a) Q1
(b) Q2
0 10 20 30 40 50 60 70
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
Ex ec T im e (se c)
Worker ID
w/ other worker VMs (Avg:39.6s, Mean Difference:7.3s) w/ isolated executed worker (Avg:20.5s, Mean Difference:4.1s)
0 10 20 30 40 50 60 70
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
Ex ec T im e (se c)
Worker ID
w/ other worker VMs (Avg:39.9s, Mean Difference:7.5s)
w/ isolated executed worker (Avg:19.9s, Mean Difference:3.4s)
51
(c) Q3
(d) Q4
圖 21、Q1 到 Q4 中，各計算節點在共同執行與獨立執行時其執行時間之比較
0 50 100 150 200 250 300 350 400
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
Ex ec T im e (se c)
Worker ID
w/ other worker VMs (Avg:168.7s, Mean Difference:94.5s) w/ isolated executed worker (Avg:42.6s, Mean Difference:6.2s)
0 50 100 150 200 250 300 350 400 450
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
Ex ec T im e (se c)
Worker ID
w/ other worker VMs (Avg:199.6s, Mean Difference:114.6s)
w/ isolated executed worker (Avg:40.9s, Mean Difference:6.9s)
52 Compution
ti-me(sec)
Query ID
Based on size (MB), multi-worker
Based on Estimated number of Records,
multi-worker
Based on Estimated number of Records, isolated execution
(baseline) environment 但是只有一個ＶＭ）的執行時間以及 Mean Difference 的統計資料。我們可 以看到在移除 I/O 競爭的因素後，計算節點的執行時間不僅大幅度下降也更加的平衡
第一、Changing Data Storage System：在[24]此篇論文中， 對於如何在 HDFS 下有效處 理小容量檔案，作者認為 MapReduce 等 Parallel Programming Framework 的下層資料儲 存系統應該混合 HDFS 與 Parallel DBMS (Database Management System)，讓它們負責儲 存各自擅長的檔案類型：大容量的資料交由 HDFS 處理；小容量的就儲存在 Parallel DBMS 中。Parallel DBMS[23] 與傳統 DBMS 的差異在於在前者的架構下資料由一群位 在相同地理區域的機器所組成的 Cluster 共同儲存；除了共同儲存外，當接收 Query 後 所有的機器會同時、平行的處理。
與 Parallel DBMS 相似的架構還有 Distributed DBMS，但因為其機器的分佈位置並 沒有位於相同地理區域，所以彼此尚保有高度自主性以自行處理 Query。Parallel DBMS 為解決由 NN 處理過多小容量檔案的 Request 所造成的 Overhead 問題，作者提 出 Fat-Btree [25]－一種自 Parallel B-tree 改良而來的資料結構來儲存 DB index。在 Fat B-tree 中所有檔案會被組織成一顆 Level 3 的樹狀結構，一個根節點、數個中間節點以 及葉節點。葉節點與中間節點相連並記錄對應資料的相關資訊；一台機器可以擁有多
53
個中間節點端看其儲存的資料數量。Fat-Btree 稱為 Parallel 的原因在於這棵 Index Tree 並不會只由一台機器來維護，每台機器都會擁有 Fat-Btree 的一個子樹－包含它所儲存 資料的葉節點和跟葉節點連結的中間節點。這顆子樹就如同 Local Cache 一般，當機器 需要存取檔案時可以先查詢子樹，以避免每次向 NN 查詢的 Overhead。把檔案資訊組 織成樹狀結構有利於資料搜尋，當使用二元搜尋 (Binary Search)演算法時，搜尋檔案 的複雜度可從原先循序搜尋的O n( )下降到O(log(
n
))，進而加快存取檔案的速度。改 善後的系統不僅提升 HDFS 在處理小容量資料的效率，也讓 NN 負擔大為下降進而減 少 Single point of failure 發生的機會。第二、Merge files and Redesign the metadata in NN (NameNode)：在[26]此篇論文中，
作者指出 HDFS 原本設計用以儲存、管理大容量資料，因此當需要從 HDFS 內讀取太 多小容量檔案時就會遇到兩種問題。一是、同時有太多向 NN 索取 Metadata (檔案位置 等)的 Request 而讓 NN 的網路頻寬大量消耗，也會導致 NN 效率下降；整體執行時間 延長。其解決問題的方法是讓 Data Node 擁有關於本地 (Local)儲存 Blocks 的 Metadata，
當 Worker 需要讀取檔案時可以先從 Local Metadata 內尋找，若是沒有再跟 NN 做查詢。
如此就不需要每次都發 Request 向 NN 查詢，減少 NN Overhead 同時也避免網路傳輸導 致的時間延遲。
其 二 為 DataNode 硬 碟會因為檔案位置不同而需要不斷移動讀寫頭導致 I/O Overhead。其改進方法是改善 HDFS 內儲存 Block 方式，使檔案數目減少以降低移動次 數。一般而言，檔案儲存進 HDFS 時會切割成一連串固定大小的 Blocks 後儲存，但是 通常最後一個 Block 會放不滿卻依然單獨儲存為一個 Block。為使檔案數目減少，作者 提出把所有不足固定大小的 Blocks 合併，同時修改 Metadata 格式，讓 Metadata 紀錄合 併後 Block 中原本 Block 的檔名與長度，Clients 能透過 Offset 直接存取所需檔案。如此 在 Client 不需改動太多存取方法同時減少 Blocks 數量，讓 HDFS 更加 Consolidated。
作者認為合併時不應該是隨意合併而應從檔案結構或是邏輯上相關性下手。以本 論文而言，因為一個目標網路 (target network domain)其通聯的網路對象其實是不平均 的，事實上以我們的實驗對象而言，超過 200 個國家中只有前幾個有較多的通聯紀錄。
54