AS Ranking
US (1st) TW (2nd) CN (3rd) JP (4th)
55
countries <63MB >63MB Total
Q1 194 4 198
Q2 190 3 193
Q3 213 4 217
Q4 213 4 217
表 12、Q1 至 Q4 之待處理資料總量大於 63MB、小於 63MB 與全部的國家數
56
segment size (GB)
<63MB >63MB Total
Q1 0.28911 1.40129 1.69041
Q2 0.33246 1.44656 1.77901
Q3 0.33985 1.82499 2.16485
Q4 0.38940 1.79671 2.18611
表 13、Q1 至 Q4 之待處理資料總量
表 11 中可以看到完成合併後之檔案總數大約只剩下原本的 3%，而針對流量較大 的前四名國家 (分別是美國、台灣、中國、日本，依名次排序)其數量更下降至 1%。
我們對資料進行合併處理後，其大小作為分配依據的執行結果以 Q4 為例呈現在圖 25，
大部分計算節點執行時間因此而下降，整體執行時間更為平衡。平均執行時間由 119.58 秒下降到 67.64 秒；Mean Difference 從 114.65 秒下降到 15.3 秒，約下降了 85%。
藉由以上說明，我們確實了解到透過降低檔案數量能夠減少計算節點間 Disk I/O 讀取 競爭，進而平衡節點間執行時間，達到 Algorithm 1 的最終目的：藉由分配相同工作量，
以期各計算節點能在差不多的時間內完成。不只是在一台實體機上多個虛擬計算節點 的架構下，計算節點間的 disk I/O 競爭減少，有效降低各節點的執行完成時間；並且，
大部分計算節點在單獨隔離的執行環境下的執行完成時間也減少。
圖 25、Q4 在檔案合併前後其執行時間與 Baseline 之比較
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
before merging w/ VM (Avg: 119.58s, MD:114.65s) before merging baseline(Avg: 40.93s, MD: 6.98s)
After merging w/ VM (Avg:67.64s, Mean Difference:15.30s)
After merging baseline (Avg:32.77s, Mean Difference:11.38s)
57 (sec)
Query ID
Multi-worker, based on size (MB)
Baseline, based on Estimated number of
Records
Multi-worker, based on size with file
merging
Baseline, based on size with file merging
Avg Std Max MD Avg Std Max MD Avg Std Max MD Avg Std Max MD Q4 199 97.4 393 114 40.9 6.0 53.4 7.01 67.6 13.1 91.3 15.0 32.8 9.75 51.9 11.4
表 14、Q4 在合併小檔案前後之工作完成時間以及與 Baseline 之比較
合併小檔案的做法會讓資訊的顆粒度 (Granularity)下降：原先能夠透過路徑得知 該筆資料隸屬的國家與 AS，但是合併後可能需要透過 Metadata 以辨識找出在這查詢 下待處理的資料檔案藉以換取處理的效率。在下一個小節中我們將說明如何在檔案合 併後依然保有原先的資訊。
3.7 Hierarchical Path 改進
當我們將國家內 AS 合併之後，原本設計的 Hierarchical Path 就不再適用。以前，
依照國家－AS－日期的規則我們可以根據 Query 拼湊出檔案的路徑，以快速讀取特定 合併，根據 Merge Metadata 內紀錄合併到的檔案，再去其對應的 Metadata 中找出該 AS 的 Offset。相較修改前可以直接拼湊出資料路徑，修改後需要最多兩次的 Table Lookup 才能找出資料位置。雖然需要額外查詢次數，但是我們相信藉由合併小檔案；
減少檔案數量所降低的 I/O Overhead，會大於額外查詢的 Overhead。
3.8 資料執行時間過久處理方式
當完成一天的流量之後，接著我們想瞭解當待處理資料量的規模擴大時其處理時 間會是如何。因為本研究的目的是想探討規模化資料量與計算節點以及執行時間的關 係，以達到互動式查詢的合理回應時間。在此目的下，有兩個議題。第一個議題是在 一定的計算節點下，規模化資料量與執行時間的關係。第二個議題是給定最大可接受
58
的執行時間，規模化資料量與計算節點需求的關係。因此，接下來我們將 Query 的時 間範圍擴大至兩天與三天。我們定義兩天與三天的 Query 為 Q5 與 Q6 並以表格比較不 同天數的 Query 之檔案數量與資料總量。
Query ID Direction Time Total segments size Workload capacity per
worker