第四章 系統實作
第三節 資料庫 HAWQ
國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
第三節 資料庫 HAWQ
HAWQ 為 MPP 架構的資料庫，由於架構較新且正值發展期，因此推出對應 的作業系統選擇不多，提供的作業系統：CentOS/ RedHat 6.X、CentOS/ RedHat 7.X，這麼做的好處是以上兩種版本的作業系統非常穩定，不易有 Bug 產生，但 壞處則是此二作業系統的內部編譯器或套件，版本都較為舊，若是要安裝近幾年 推出的套件會遇到版本不相容的問題。
HAWQ 容器化
為了解決上述問題，本研究決定將HAWQ 用 Docker 虛擬化成 Container，
並運行在Ubuntu 上，這樣既不會有版本不相容問題也能保有 HAWQ 資料庫。
在Apache 開發的專案 incubator-hawq [41]裡，就提供讓 HAWQ 運行在 docker 上 的版本，開發者可透過修改Makefile 選擇映像檔的作業系統以及生成的節點數。
在擴增節點的同時，需要注意彼此節點內核的最大共享內存段（SHMMAX）配 置，若是節點數過多，可能要適時地調高SHHMAX 值，或是降低緩存
shared_buffers 值。下圖為 HAWQ 包裝成 Docker 的容器狀態圖：
圖 四-10 Docker HAWQ 各容器狀態
（資料來源：本研究繪製）
‧
有Statement Memory 不夠的問題，導致速度變慢，因此本研究較推薦剩下兩種 指令。第二種則是COPY 指令，將要匯入資料庫的資料存進 txt 檔，並透過 COPY_FROM 把 txt 檔的資料全數匯進資料庫，速度足足快上第一種指令幾十 倍。最後一種是gpfdist 指令，資料儲存同樣以 txt 格式，但 gpfdist 會讓資料檔 案轉為External Table 的形式，使資料得以透過平行化的方式匯入資料庫，為以 上三種指令唯一能平行運算匯入資料庫的指令，速度也較第二種快上幾倍。
HAWQ Resource Queue
平台會根據使用者的不同，將依其權限配置相對應的資源，HAWQ 的 Resource Queue 即可做到這點，像是更改配置的記憶體大小、Statement 數目、內 核資源的比例等，讓資料庫上的資源分配更具彈性。下圖為本研究配置的 Resource Queue：
圖 四-11 Resource Queue 配置
（資料來源：本研究繪製）
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
YARN Capacity Scheduler
透過Ambari 搭建出 Hadoop 架構，其中必定包含許多好用的開源軟體，像 是Spark、Storm 等，但若這些軟體同時被執行時，服務彼此將會佔據伺服器的 資源，讓少數服務分配不到資源而無法提供服務，因此，YARN 的資源分配就顯 得十分重要，YARN 即是透過 Capacity Schedule 來標示每個服務最低及最高限度 能分配到的資源，以確保平台上的服務都能正常地被執行。下圖為本研究的 Capacity Schedule 配置：
圖 四-12 Capacity Schedule 配置
（資料來源：本研究繪製）
‧
l CPU：Intel(R) Xeon(R) CPU E5-2650 0 @ 2.00GHz l 記憶體：128GB
l 作業系統：Ubuntu 14.04.5 LTS trusty l GPU：Grid K520
第一節 平台負載能力
為了要做到平台負載能力測試，使用第四章提到能在JupyterHub 上創建大 量使用者的Shell Script，建立 50 名使用者，分別為 jhuser01~jhuser50，並撰寫 測試程式，程式中包含Python BuiltIn Function、File IO&EE、Numpy 陣列運算、
Pandas 表格輸出與 MatPlotLib 做圖等範例。
執行幾次測試程式後，單一容器執行時間大致落在22-24 秒，在確定基礎執行時 間後，將讓 50 名使用者同時執行程式，並觀察各個容器所執行的時間，得出的 結果如下圖：