中華大學

(1)

中華大學碩士論文

關聯感知技術應用於 SQL 與 NoSQL 資料轉換

Correlation Aware Technique for SQL to NoSQL Transformation

系所別：資訊工程學系碩士班學號姓名：M10102009 徐仁淳指導教授：許慶賢博士

中華民國 103 年 8 月

(2)

摘要

Hadoop 為了平行分散式運算，將匯入的資料切割後存放在資料節點上，如此的放置方法對於一般資料的分析可能擁有很大的好處，但如果資料之間擁有關聯性(例如：資料庫)，要如何存放這些有關聯性的資料便是一大議題。大數據時代來臨，要存放在資料庫裡的東西越來越多，若還是使用傳統資料庫來存放這些龐大的數據，資料庫的效能已經無法讓一些即時系統能夠提供有效率的服務。為了改善資料庫的性能問題，大家都向雲端資料庫邁進，而這時 Apache 推出一套工具 Sqoop，主要是讓傳統關聯式資料庫與 Hadoop 之間進行高效率的大規模數據交換；透過 Sqoop 的幫助下可以輕鬆的在指令模式下把數據導入到 Hadoop 與其相關系統。Apache Sqoop 在將資料庫匯入到 Hadoop 的時候，套用 Hadoop 切分資料的概念，將資料庫中的 Table 分成 4 等分後隨機存放在資料節點上。此種放置方法對於往後資料庫的效能上有很大的問題，我們針對此問題提出方法加以改善。

本篇論文提出了 Correlation Aware on Sqoop(CA_Sqoop)，用以改善 Table 被隨機放置的問題，目的在於希望資料能夠盡量地放置再一起，以減少資料透過網路傳輸而增加整個資料庫往後的效能。CA_Sqoop 同時考慮了 Table 之間的關聯度和 Table Size，以得到最大的 Data Locality 以加速資料庫的查詢，讓整體系統效能得到改善。經由我們的模擬可以看出，透過 CA_Sqoop 做 Table 的匯入後，

整體系統所得到的 Data Locality 平均都是傳統 Sqoop 的兩倍以上。

關鍵字: Sqoop，雲端計算，NoSQL，Hadoop，資料局部性。

(3)

Abstract

For better efficiency of parallel and distributed computing, Apache Hadoop distributes the imported data randomly on data nodes. This mechanism provides some advantages for general data analysis, when the data have the relationship between the data sets (example: Database), it’s a popular issue that stores the data with relevance.

With the data sets increasing, a lot of data to be stored in a database, if we still use traditional database that has been unable to capable of providing an efficient service to real-time system. Most people wanted to use Hadoop to improve database performance. At this time, Apache provided a tool named Sqoop that can import all databases to Hadoop environment by command line interface. Have the same concept with Hadoop, Apache Sqoop separates each table into four parts and randomly distributes them on data nodes. However, there is still a database performance concern with this data placement mechanism.

This paper proposes a Correlation Aware method on Sqoop (CA_Sqoop) to improve the data placement. By gathering related data as close as it could be to reduce the data transformation cost of the network and improve the performance in terms of database usage. The CA_Sqoop also considers the table correlation and size for better data locality and query efficiency. Simulation results show the data locality of CA_Sqoop is two times better than that of original Apache Sqoop.

Keywords: Sqoop, Cloud computing, NoSQL, Hadoop, Data Locality.

(4)

致謝

本篇碩士論文能夠順利完成，在此要誠摯感謝我的指導教授許慶賢教授。在這求學期間，隨著跟老師的腳步在這雲端運算的領域慢慢摸索，也慢慢的深入研究。在寫論文的過程，教授不斷的協助我，對於原本凌亂的想法做整合，在遇到我無法解決問題的時候，能夠給我一些專業的想法能讓我能夠尋求解答。並且，

對我的論文提出一些看法以及意見，使我得論文更有組織性。

再來就是要感謝實驗室的各位學長，可以即時的幫助我解決我遇到的困難，

在寫論文的時候，告知我該注意的地方，避免重蹈覆轍。另外要感謝的是碩士班的同學，平常互相討論，互相勉勵對方。

最後要感謝的是我的家人，在我就學期間，能夠支持與鼓勵我，使我無後顧之憂，能夠專心的在寫論文上，讓我能夠順利完成我的學業。最後，僅以此文獻給我的師長，以及在學的時候，支持我的各位朋友以及家人。

(5)

表目錄

表 3.1:資料庫中內含５張 Table 的關聯度範例……….13 表 3.2:料庫中內含５張 Table 的範例……….14

(7)

圖目錄

圖 2.1: MapReduce 的運作流程圖 ... 5

圖 2.2: HBase 的系統架構圖 ... 7

圖 2.3: Sqoop 的系統架構圖 ... 8

圖 3.1: MapReduce join example ... 11

圖 3.2: Algorithm flowchart ... 12

圖 3.3: ECT 範例 ... 16

圖 3.4: CA_SQOOP 方法演示(一) ... 17

圖 3.5: CA_SQOOP 方法演示(二) ... 18

圖 3.6: CA_SQOOP 方法演示(三) ... 19

圖 3.7: CA_SQOOP 方法結果 ... 19

圖 4.1: Impact on different sizes of cluster ... 21

圖 4.2: Importing twenty tables to a small cluster ... 22

圖 4.3: Importing one hundred tables to a large cluster ... 22

圖 4.4: Importing different number of tables to a cluster ... 23

圖 4.5: A database has different correlation range ... 23

(8)

Chapter 1 緒論

1.1 動機

不同於傳統的儲存概念，分散式檔案系統會把資料切割並放在不同的 VMs(Virtual Machine)上來做儲存(如 : Hadoop)，然而在資料庫中經常使用Join operation，常常需要用到兩個Table作運算，所以這些資料如何放置在這些叢集裡便是一個重大的問題。

Sqoop在轉換資料的時候，預設的情況下會把資料庫的Table切分成4等分用 MapReduce的Mapper透過JDBC把這分割好的Table存到叢集內的節點上；這些資料庫裡的Table透過MapReduce來做放置的時候，會依照Hadoop把Mapper在哪一台VM上執行來放置在該台VM上，然而Hadoop在分配Mapper執行的機器的時候是隨機的。

如此隨機的放置這些分割後的Table，對往後整個資料庫的應用上(如 : Join operation)，會造成許多資料必須透過網路傳輸，因而造成查詢緩慢。

1.2 背景

在過去幾十年前個人電腦還沒有這麼普遍的情況下，當時所提供服務的硬體設備主要還是以大型主機為主，所有的工作都只能透過那一台主機運行，既不方便也沒有彈性，因此，IBM則在當時開發了一套虛擬機監視器(Virtual Machine Monitor)，藉此將大型主機的資源分割成多個虛擬機器，提供給使用者使用，這些虛擬機器可以模擬成多個操作環境，用以平行分散的方式進而得到更好的資源使用率。現今虛擬化技術[1]越來越成熟，雲端運算環境透過此技術，整合了分

(9)

散在各處的資源，使資源可做統整，藉此提供各項的資訊服務。

現今網路的蓬勃發展，已經成為人們生活中不可或缺的一部分，現今人們對於網際網路依賴性越來越大，因此產生大量的資料，而這些資料在格式上有些許不同，要如何儲存資料，如何分析這些大量資料變成有用的數據，成了最大的議題。因此，雲端運算這類專有名詞，從而衍生出來，而在此背景之下，Google 在2003年提出分散式檔案系統架構Google File System(GFS) [2]、2004年提出 MapReduce架構 [3]，可用來處理大規模的資料處理，以及2006年提出BigTable [4]，

這是基於Google File System針對資料結構化儲存的分散式系統。

雲端運算(Cloud Computing)，其實早在1983年就有人提出「The Network is the

computer」，但受限於當時網路的傳輸技術並沒有這麼成熟，但隨著時光推移，

現在的網路傳輸技術已經成熟，雲端運算便蓬勃發展起來。簡單來說它不是一個技術，而是一個概念，希望可以藉由雲端叢集[5]，透過網際網路來處理在雲端存放的龐大資料。而Google提出的MapReduce架構，將這些龐大資料拆解成許多小資料，再交給雲端叢集的每個節點去做運算，之後每個節點在將運算後的結果，

進行整合，再回傳給使用者。這樣的方式由原本只能單一處理，變成平行處理，

進而加快了處理速度。

Google雖然提出了雲端運算的技術，但是，並沒有開放原始碼出來，使得企業們受到局限。直到Apache開發出Hadoop平台 [6]，企業或使用者才可以自己研發相關的MapReduce技術 [7][8][9]，不再被受到限制。MapReduce技術具有高容錯性、資源使用率高、平行處理，使得它在企業界備受青睞。

以現今的企業來說，還是使用傳統的關聯式資料庫(例如 : MySQL)，但隨著資料越來越龐大，這些關連式資料庫已經在效能上已經是不堪使用，紛紛邁進雲端資料庫的行列，但是這些龐大的資料庫是公司重要的資產，不太可能重新建置，

以企業的角度來說如果有一個工具能夠直接把資料移進雲端資料庫，進而直接使用雲端的技術來提升整個資料庫的性能。

(10)

Apache開發出Sqoop[10]，這套工具是在指令模式中提供SQL和NoSQL的資料轉換，這套工具在2012年被Apache定為最高層級的專案，有了這套工具，使用者便可以輕易的把資料庫大量的資料放進雲端的環境裡並使用雲端的技術來對資料進行操作。

1.3 貢獻

本論文針對以上敘述的問題尋找能夠提高往後資料庫的性能的做法。在傳統的資料庫裡面都有log去紀錄資料庫的所有行為，這些log檔同時也會記錄下所有在資料庫裡使用的查詢，這些log便是資料庫的使用型態。

藉由分析這些紀錄檔便可以知道那些查詢是經常被使用，並且把這些常用查詢所用到的Table盡量的擺放在一起，減少資料透過網路傳輸，因而加速整個資料庫放到雲端環境後的整體效能。

1.4 組織

本論文研究探討Sqoop將資料庫匯入到NoSQL環境下時，將Table切割後隨機儲存在資料節點上的問題，隨機的存放這些被分割後的Table，往後資料庫的性能並沒有辦法得到很好的提升，我們的方法將針對資料庫的不同來有效的存放這些Table，讓匯入的資料庫在雲端的分散式環境下能有更好的效能。

本論文章節介紹如下:第一章緒論，簡述研究動機與目的，以此為基礎。第二章相關研究，介紹前人在NoSQL上針對Join操作所做的改善。第三章Preliminary，

介紹Hadoop、MapRedcue、NoSQL以及我們要改善的工具Sqoop。第四章演算法，

介紹本篇論文所提出的關聯度感測技術的流程，另外，介紹關聯度感測所考量資料庫的特性以及用範例演示我們的方法。第五章性能分析，透過實驗模擬的結果，

將其分析與比較。最後，第六章為結論以及未來可以繼續研究的方向。

(11)

Chapter 2 相關研究

現今所屬資料爆炸的時代，任何實體的紀錄(如 : 書、圖片。)漸漸走向數位化資料，時光飛逝，這些數位化資料實在難以統計到底有多大，但國際數據資訊 (IDC)預估 2006 年「數位世界(Digital universe)」的資料總量約為 0.18ZB(zettabytes)，

1 ZB 等於 10 的 20 次方位元組，相當於 1,000,0000PB(petabytes)[31]。

這些龐大的資料量已經不是傳統的技術足以應付的了，然而雲端運算的技術

與架構，便針對這些大量資料(Big data)來設計，用以處理、儲存、分析這些大量資料。

2.1 Hadoop

Hadoop[23]是由Apache所開發的開放原始碼軟體，提供了一個分散式系統架構。Hadoop技術主要由兩個主要元件所組成: Hadoop Distributes File System (HDFS)分散式檔案系統、Hadoop MapReduce平行分散式運算，以下一一敘述。

HDFS (Hadoop Distributes File system) 是根據Google提出的GFS(Google File System)所延伸的，主要就是將各個節點連結起來，將這些節點組成一個大型的分散式檔案系統，可以有效的處理大量檔案，並提供安全的儲存環境以及可以避免因為單一的硬體發生異常而影響整個系統。

而HDFS為了維護資料的一致性，當使用者將資料存進去HDFS，就不能去更動或修改。HDFS會將儲存的資料，複製副本，分別儲存在幾個不同的節點，

這樣可以在儲存資料的節點發生異常後，其他節點還是擁有資料的副本以確保資料的一致性，然而整個工作不會因為資料節點異常而導致工作無法完成。

(12)

2.2 MapReduce

Hadoop最重要的技術即是MapReduce，使用MapReduce模型，將一個大問題，

由程式開發人員分析問題，將問題切割成許多小問題，在將此小問題平行分散給各個Mapper，當Mapper處理完的結果在傳送到相對映的Reducer去做運算，

Reducer將這些結果進行合併，在把合併的結果輸出。

圖2.1 MapReduce的Word Count運作流程圖[28]

如圖1.1即為簡單的MapReduce流程圖。

1. 將輸入的資料切割成固定大小。

2. Master會挑選空閒的Worker當Mapper或Reducer。

3. Mapper會從切割好的資料，透過雜湊函數讀取相對映的資料，會產生Key / Value，會先暫存在記憶體內，再週期性的傳送到Local Disc。

4. 執行Reducer程式的Worker，讀取每一個Mapper的結果，並進行排序以及彙整，

再將整合的結果輸出。

時代的更替，數位化時代來臨，緊跟而來的資料量暴增，傳統資料庫的效能已經無法應付即時系統(如 : 電信付費系統)，Comparison of Map-Reduce and

(13)

比較，由該實驗結果顯示，雖然較小的資料量的情況下傳統的關聯式資料庫的效能的確比 Hadoop 來的好，但隨著資料量越來越大的情況下，Hadoop 確實是能夠節省許多時間。

MapReduce主要透過雜湊函數來產生Key / Value，再藉由分配這些Key / Value 到不同的運算節點來平行運算達到加速目的，所以這些Key / Value的產生和運算便是一大議題，LoadAtomizer[12]、ESAMR[13][14]針對MapReduce的排程問題進行優化。

理想化的雲端環境是每個節點都擁有相同的運算能力(如: CPU 執行效率、記憶體大小)，但實際來說往往因為伺服器中並不是每次都是空閒狀態因而虛擬機器的運算能力會有所改變，這就會造成每個節點的效能不一致的情況 (也就是所謂的異構性環境)，當 Hadoop 運行在異構性環境，對於性能上是有很大的落差，

LATE(Longest Approximate Time to End) [26]，針對其任務的排程上做改良，設計了一個新的投機性任務，用以估算完成時間，根據估算的完成時間，來調整任務的分配，雖然對回應時間有點影響，但是，整體性能明顯的比 Hadoop 改善很多。

MapReduce 在運算的時候會把資料平均分散給運算節點，這在節點能力不同的環境下並不是明智之舉，動態切割資料[24]點出了資料分配的問題並提出動態資料切割和虛擬機器對映，在 Map 階段，根據虛擬機的效能，將資料做動態切割，

來給予相對應的運算節點，使得完成時間盡量接近。在 Reducer mapping 方面，

根據 Communication locality，來給予相對應的虛擬機進行運算，讓所有的任務完成時間盡量相同，也就可以縮短整個工作時間。

(14)

2.3HBase

圖 2.2 HBase 的系統架構圖[29]

HBase是仿照Google BigTable 發展出開放源始碼的非關聯式的分散式資料庫，HBase架構在Hadoop HDFS，與傳統關聯式資料庫不同。HBase使用列鍵和族列存取資料值以及每一筆資料都有一個時間戳記。

HBase 專門用來處理大規模的資料，是由 HMasrter 、HRegion server 、 Zookeeper 組成，一個 HMaster 透過 Zookeeper 管理多部 HRegion Server。HMaster 透過 Zookeeper 監控與管理各個 HRegion Server 系統狀態，Zoopkeeper 主要得功能是記錄各個 HRegion 的位置及 metadata，而 HRegion Server 利用記憶體存取快速的優點，可以加速資料讀寫。

(15)

2.4 Sqoop

圖 2.3 Sqoop 的系統架構圖[30]

Apache Sqoop 主要是在協助傳統關聯式資料庫與 Hadoop 之間進行高效率的大規模數據交換；透過 Sqoop 的幫助下可以輕鬆的在指令模式下把數據導入到 Hadoop 與其相關系統(如: HBase、Hive)。在 2012 年三月 Apache 把 Sqoop 定為最高階層的項目。

隨著資料的增長，要存在資料庫裡的東西也越來越多，這些龐大的資料存在關聯式資料庫(如: MySQL)中，會對資料庫的效能產生很大的影響。在這種情況下就可以使用 Sqoop 把資料庫導入 Hadoop 的環境中，便可使用 MapReduce 來增加運算的效能。

(16)

2.5 NoSQL

Join 操作是資料庫裡常見且耗時的動作，許多的研究都針對 Join 操作的優化探討，DDRM[15]提出了在 reduce 階段將中間產物重新分區並複製給其它已經完成的節點上用以加速運算。Theta-Joins[25]提出了使用了 MapReduce 的簡化 Join 模型。許多研究也顯示 MapReduce 的性能瓶頸在於頻繁的檢查各個節點和中間結果的 shuffling ，Map-Join-Reduce[16]提出了使用 MapReduce 模型的自然延伸，

加入了過濾的動作，使得 MapReduce 是先使用邏輯過濾來省略掉中間結果的 shuffling 而讓整個完成時間減少許多。

隨著數據在雲端環境的迅速增加，如何處理大數據量的高效已經成為一個至關重要的問題。LRDFS[27]提出了在雲端的分散式環境下資料放置的方法，用以解決附載不平衡的問題。MapReduce 是有著可擴展性和容錯性的大數據的處理框架，主要目標在處理大量的非結構化資料[20]，但在現今的企業中資料庫裡還是儲存著大量的結構化資料，希望能透過 NoSQL 的技術得到提升， Clydesdale[21][22]就點出了這個問題，並且提出一套建立在 Hadoop 之上的架構，

然而這是不需要去更改複雜的 Hadoop 架構，並透過幾項技術來加速結構化的資料的處理，因而改善 Hadoop 在處理結構化資料效能不足的問題。

傳統的 SQL 語法還是被大眾所使用的，SQLMR[19]提出了一套為雲端設計的數據管理系統，將類似 SQL 的查詢轉譯成 MapReduce 工作，將現有的 SQL 應用能夠直接使用 MapReduce 來加速查詢，而不用重新撰寫 MapReduce 程式。大多的 NoSQL Database 的查詢語言通常都使用 Hive[17]來做 SQL 到 MapReduce 的轉譯工作，許多篇論文都提到 Hive 所轉譯出來的 MapReduce 工作並不是這麼的有效率。Hive 在做查詢語言的轉譯的時候是採一對一的模式來做轉譯，所以並沒有考慮到查詢語言中間的關聯性的問題，YSmart[18]所提出改善 Hive 所轉譯出來的 MapReduce 工作，將整個查詢語言根據其關聯性將不必要的 Join 進行

(17)

合併動作，大大的減少了非必要性的 join 操作，因此大大降低了查詢所需要的時間，而這樣的合併查詢語言的作法在 2012 年被 Hive 整合。

(18)

Chapter 3 Sqoop 搭配關聯度感測

Apache Sqoop 在資料庫匯入的時候，初始設定會把一張 Table 切分成 4 等分 (table split)，再用 Mapper 透過 JDBC 將資料匯入 NoSQL(如 : HDFS、HBase )。

然而這些 Mapper 會依照 Hadoop 的工作配置，隨機的被啟動在空間的工作節點上，所以這些被分割的 Table 就隨機放在資料節點上，這樣的資料放置方法並不是很好的做法。

在一個資料庫的應用中常經常使用許多的查詢語言用以呈現資料庫的內容，

而這些查詢語言中通常大多都包含 Join 語法，而 Join 語法通常都是把兩個 Table 透過相對應的欄位做合併的動作(如圖四)。

圖 3.1 MapReduce join example

如圖 3.1 所示，Inputs 的兩個 Table，若分別放在不同的 8 個節點上，要想 Join 這兩張 Table 的時候想必有需多資料必須得透過網路來傳輸來完成動作。

由於資料透過網路傳輸比起直接在硬碟中讀取資料實在慢了許多，因此只要減少資料透過網路來傳輸，盡量地的把資料擺放在一起，便可以提升 Join 的效率，因而提升整體資料庫的效能。要透過何種資訊來擺放這些資料庫的 Table 便

(19)

是此問題的一大重點，以下將會敘述我們考慮了哪些資訊。圖 3.2 為演算法的流程圖，可以看到第一步我們先藉由分析資料庫的 log 中取得 Table 之間的關聯度，

第二步是考慮 Table size，再運用關聯度和 Table size 來進行我們的方法將資料庫中的 Table 做匯入的動作。

圖 3.2 Algorithm flowchart

3.1 分析資料庫表之間的關聯性

關聯式資料庫中的記錄檔中記錄了資料庫裡的所有操作，記錄檔裡包含各種資料庫的操作，包含資料庫的設定，資料的修改，以及查詢。原本這個檔案的功能在萬一資料庫有任何問題發生，便可以從該檔案得知問題出在哪裡，而該檔案所記錄起來的查詢便是直接對應到資料庫的應用，因此只要分析這個記錄檔便可以知道那些查詢是被經常使用，我們便透過這個特性來將資料庫做分散化的擺放動作。

因此只要出現在記錄檔的查詢，該查詢所用到的Table將對其做關聯度的註記，經由這樣的分析整個資料庫的log檔，便可以得到整個資料庫裡所有Table之間的關聯度，並用以一個二維陣列 Table Correlation(TC)表示（如表3.1）。

Analysis database log file to find the table correlation

Gets the size of tables in the database

Tables are distributed according to ECT

Using table correlation and table size to define an array named Effective Correlation Table (ECT)

(20)

表3.1 資料庫中內含５張Table的關聯度範例

TC所記錄的便是該Table與其它Table之間的關聯度，以Table1和Table2來說，

兩張Table之間的關聯度為１５，代表著資料庫的log檔裡，有１５次的查詢會用到這兩張Table。

3.2 考量資料庫表之大小

除了考慮Table之間的關聯度之外，我們還考慮了table size的問題，原因是如

果兩張Table之間的關聯度非常大的情況下，但這兩張Table的大小相較於資料庫中其它Table是較小的情況下，這樣把這兩張Table擺在一起便不是明智的決定。

Hadoop在執行任務的時候，會把task起在資料量比較大的節點上，以減少資料透過網路來傳輸而影響執行的效率，我們便透過這個特性來考慮table size的問題。

我們便針對資料庫裡的Table，來做兩兩比較，而選出較小的Table作為代表，

並同樣運用一個二維陣列 Table Size(TS)表示(如表3.2)。

表3.2 資料庫中內含５張Table的範例

(21)

3.3 方法

Table Correlation(TC)和 Table Size(TS)作相對應的位置相乘，便可以得到 Effective Correlation Table(ECT)。同時我們假設叢集內的節點都有一個儲存 table split 的容量限制稱為 capacity，然而我們將透過 ECT 作為擺放 table 的依據，以下便是我們做擺放的流程：

1.對ECT裡的每個row取capacity-1個較大的值做加總為Sr

2.取Sr中最大為Smax，將Smax之組成做擺放動作 3.將Smax所組成標示為已擺放

3.如果剩餘的Table數量大於capacity，重複步驟1、2、3 4.將剩餘的Table做最後一次的擺放

在步驟2擺放動作的同時我們所得到Data Locality，簡單說就是這些資料可以 不須透過網路傳輸，當然所得到的Data Locality並不是只有Smax的值，還必須去計算其組成的成員中，兩兩配對也是所得到的Data Locality，然而之後的實驗模擬我們便用Data Locality做為評比的標準。在此方法細部拆解可以分為在方陣中取最大值的時間複雜度為，和有[

]個回合才做完所以整體時間複雜度為

針對以上Correlation Aware on Sqoop擺放流程我們給予演算法描述如下 :

Algorithm : Correlation Aware on Sqoop

(22)

Input

ECT : Effective correlation table . n : Number of tables on database.

capacity : Number of table split which can be stored per node . α: capacity-1.

L = 0 //Data Locality P=1

Output

Sets of tables. S₁,S₂,…..S^β ,where β=[] Begin

{

while(n >0){

For(i=1 to n){

Select α larger values from row_i of ECT, assume ECT[i][m_1], ECT[i][m_2], ECT[i][m3]…,ECT[i][m^α].

Sumrow_i= ∑^α [i][mj]. //mj is column of larger values on ECT.

}

Summax = max{ Srow₁ , Srow₂, ..., Srow_n }, and assumed Summax = Sumrow_k.

Remove rows k,m₁,m₂,m₃….,m^αfrom ECT.

Remove columns k,m1,m2,m3….,m^αfrom ECT.

Add tables t_k,tm₁,tm₂,tm₃……,t^m^α to S_P. P++.

L += Sum_max. n -= capacity.

}

(23)

}

End of Correlation Aware on Sqoop

3.3 範例

ECT ¹ ² ³ ⁴ ⁵ ⁶ ⁷ ⁸ ⁹

1 11 10 45 69 5 51 99 16

2 85 50 36 42 39 88 68

3 76 42 53 39 9 49

4 70 46 31 16 45

5 54 35 78 25

6 29 41 59

7 67 68

8 28

9

圖3.3 ECT 範例

我們在這給一個ECT的範例，如圖3.3中可以看到這個資料庫中有9張Table，

同時我們在此叢集內每一個節點能夠儲存3個table split，來做方法演示。

每個節點只能存放3個table split，在這個情況下capacity=3，因此我們便取每一列 中最大的兩個值(capacity-1)來做加總(sun)如圖3.4。下一步就是，取sum欄位中最 大的數值，取其組成做第一次Table擺放；圖3.4的範例中，sum最大的是173(圖3.4 中圓形)，由2、3、8所組成，因此將Table2、Table3、Table8擺放在一起。由於173 只有包含Table2和Table3的關聯度加上Table2和Table8的關聯度，因此我們還要再

(24)

加上Table3和Table8的關聯度(圖3.4中三角形)，這樣才是資料庫系統所得到的 Data Locality。做完第一次擺放的動作之後，我們所得到的 Data Locality為 173+9=182。

ECT ¹ ² ³ ⁴ ⁵ ⁶ ⁷ ⁸ ⁹ ^Sun

1 11 10 45 69 5 51 99 16 168

2 85 50 36 42 39 88 68 173

3 76 42 53 39 9 49 129

4 70 46 31 16 45 116

5 54 35 78 25 132

6 29 41 59 100

7 67 68 135

8 28 28

9

圖3.4 CA_Sqoop方法演示(一)

在做下一次Table擺放之前，我們得先針對上一次已經被擺放過的Table做註記，這樣下一次擺放便不會考慮到已經擺放過的Table，我們的註記動作是把已經擺放過的Table欄位將其值設定成0，這樣就部會影響到下一次的Table擺放。做完註記的動作之後我們用同樣的方法做第二次的Table擺放，同樣取每一列中最大的兩個值做加總存在sum欄位中，取sum欄位中最大值(圖3.5中圓形)的組成 Table1、Table5、Table7擺放在一起，同樣的sum欄位中的最大值並不包含Table5 和Table7的關聯度，所以還是再加上Table5和Table7的關聯度(圖八中三角形)所以做完第二次擺放之後，這時候方法所得到的Data Locality為182+120+35=337。

(25)

ECT ¹ ² ³ ⁴ ⁵ ⁶ ⁷ ⁸ ⁹ ^sun

1 45 69 5 51 16 120

2

3

4 70 46 31 45 116

5 54 35 25 89

6 29 59 88

7 68 68

8

9

圖3.5 CA_Sqoop方法演示(二)

完成第二次擺放動作的時候，同樣的把擺放過後的Table做註記(如圖3.6)，

這時候所剩餘Table數量剛好等於一個節點所能存放的Table數量，所以直接把剩餘的Table做最後一次擺放，做完最後一次擺放整個方法所得到的Data Locality為 337+46+45+59=487。Table最後擺放的情形如圖3.7。這邊所得到的Data Locality 表示經過我們的方法放置這些Table後，有487GB的資料在提供服務的時候不需要透過網路來傳遞資料，便可以提高資料庫的性能。

(26)

ECT ¹ ² ³ ⁴ ⁵ ⁶ ⁷ ⁸ ⁹

1

2

3

4 46 45

5

6 59

7

8

9

圖3.6 CA_Sqoop方法演示(三)

圖3.7 CA_Sqoop擺放結果

(27)

Chapter 4 效能評估

本篇論文，用以C++程式模擬的方式針對原始的Sqoop跟我們的方法

CA_Sqoop做Data Locality的比較，ECT(Effective Correlation Table)我們以隨機的動態陣列來表示，ECT陣列中所產生出來的數值代表著當某兩張Table要被Join起來的時候可以省下的資料傳輸量，而這不需要被傳輸的資料我們稱之為Data Locality這將是我們實驗比較的重要數值；同時在此定義幾個程式模擬實驗的相關變數範圍如下：

 Table Size : 1~10 GB

 Table Correlation : 1 ~ 1000

 Node capacity : 2~50

 # of tables : 20 ~300

 # of nodes : 20~100

在定義方面，Table size 指的是資料庫裡一個 Table 的大小，在實驗模擬中以 1~10GB 來隨機設定資料庫中每一張 Table 的大小；Table Correlation 給定的範圍以 1 ~ 1000 來模擬資料庫 log file 中查詢所使用到的 Table 之間的關聯性；Node capacity 為給定叢集內的每個節點能夠儲存 table split 的上限。# of tables 為資料庫裡 Table 的數量；# of Nodes 為叢集的大小。

(28)

圖 4.1 Impact on different sizes of cluster

圖4.1中可以看到，一個大型資料庫若匯入太小的叢集中，CA_Sqoop會在這種狀況下輸給Sqoop，因為所有的節點都已經放滿的情況下，Sqoop隨機所得到的Data Locality還是會有很大的機率會贏過我們的方法，但是隨著叢集數量的上升，Sqoop同樣的會隨機擺放這些Table，所以所得到的Data Locality便會越來越小，相反的我們的方法CA_Sqoop採用集中式擺放的做法所以能夠維持一定的 Data Locality。

圖4.2、圖4.3都是以capacity來做比較，不同的是圖4.2是以較小的capacity和少量的Table做比較，主要是模擬小型資料庫匯入小型叢集的情形，這將針對一些小型企業想接軌雲端資料庫時所提供的參考數據。圖4.3則是大量Table和較大的capacity來做模擬，主要是看看大型資料庫資料匯入大型叢集後是否還是一樣能夠得到較好的Data Locality。圖4.2、圖4.3中可以明顯看出我們的方法CA_Sqoop 隨著capacity的升高進而得到更大的Data Locality，所以不管大型小型資料庫要匯入的時候我們的方法CA_Sqoop均適用。

(29)

圖 4.2 Importing twenty tables to a small cluster

圖 4.3 Importing one hundred tables to a large cluster

圖4.4中可以看到，隨著Table的數量增大兩個方法的差距越來越小，這表示著如果節點數不變，在叢集裡面放置的Table越來越多的情況下並不是非常理想。

(30)

圖 4.4 Importing different number of tables to a cluster

在圖 4.5 可以看到，若資料庫裡 Table 之間的關聯度越大的情況下，Sqoop 和 CA_Sqoop 所得到的 Data Locality 也隨之增長，但 CA_Sqoop 所得到的 Data Locality 都是 Sqoop 的兩倍以上。

圖 4.5 A database has different correlation range

經過一連串的實驗結過顯示，在一般的狀況下 CA_Sqoop 都能比 Sqoop 得到更大的 Data Locality。叢集夠大的情況下，CA_Sqoop 的改善率大約是 110% ～ 400%，整體平均改善率大概是 200%。資料庫的性能對於任何系統來說都是一個

(31)

很重要的環節，所以提高了資料庫的性能也等同於加速整個系統的效能。我們改善了 Sqoop 的隨機匯入策略讓資料庫匯入到雲端的分散式系統時能夠有更好的效能。我們的方法藉由分析不同的應用能夠有效地找出資料庫中 Table 之間的關聯性的強弱，將這些關聯性較強的 Table 存放在相同的節點上來加速 Join 運算的速度。

(32)

Chapter 5 結論和未來展望

根據分散式檔案系統的概念，將匯入的資料切分後隨機儲存在資料節點上，

當然這些資料隨機散在不同的節點上是有助於平行分散式計算，但所有的資料的使用程度並不是相同的，如此隨機的資料放置方法用在資料庫的匯入中並不是明智之舉，這便是我們這篇論文的主要發想。

Join是資料庫裡時常發生的操作，這個操作非常消耗運算資源，以分散式計算的角度來說，將Join切分成幾個小工作用以平行分散式運算，但若是這些資料分散在許多不同的節點上的時候，資料必須透過網路傳輸這勢必影響整個Join完成的時間。我們的方法第一件事就是想到資料庫裡會有log檔用以紀錄資料庫裡的各種操作，透過分析log檔便可以知道那些Table被Join在一起，並同時考慮到一個Join所用到的資料量所以我們考慮到Table size的問題，我們便透過我們的方法CA_Sqoop，在匯入資料庫的同時將有關連性的Table盡量的放置在同一個節點中。

在實驗模擬中可以清楚得看到我們的方法 CA_Sqoop 在 Data Locality 的改善，

如此大量的資料不需要透過網路傳輸，只需要在本地端的硬碟上讀取，想必能夠減少非常多的運算時間。

在本篇論文中我們並沒有考慮到 HDFS 中資料副本的問題，日後若能同時考慮副本放置的問題，想必能夠對資料庫匯入到 Hadoop 後的性能有更大的幫助。

此外節點的容量上限定義(Capacity)，簡化了節點儲存的問題，在實際的系統上應該定義為每個節點擁有的容量來定義，而此種作法雖然較為實際但可能在匯入的時候會花大量的時間來決定到底該放在那些節點才能有更大的效能改善，但如此的作法才切乎實際這將是未來我們研究的主要方向。

(33)

文獻參考

1. Paul Barham, Boris Dragovic, Keir Fraser, Steven Hand, Tim Harris, Alex Ho, Rolf Neugebauer, Ian Pratt and Andrew Warﬁeld, “Xen and the Art of Virtualization,” SOSP '03 Proceedings of the nineteenth ACM symposium on Operating systems principles, vol. 37, Issue 5, pp. 164-177, 2003.

2. Sanjay Ghemawat, Howard Gobioff, and ShunTak Leung, “The Google file system,” In Proceedings of 19th Symposium on Operating Systems

Principles, pp. 29-43, 2003.

3. Jeffrey Dean and Sanjay Ghemawat, “MapReduce: Simplified Data

Processing on Large Clusters,” Communications of the ACM, vol. 51, no. 1, pp. 107–113, 2008.

4. Fay Chang, Jeffrey Dean, Sanjay Ghemawat, Wilson C., Hsieh Deborah A., Wallach Mike Burrws, Tushar Chandra, Andrew Fikes, and Robert E.Gruber,

“Bigtable: A Distributed Storage System for Structured Data,” 7th UENIX Symposium on Operating Systems Design and Implementation, pp. 205-218, 2006.

5. Kasim Selcuk Candan, Jong Wook Kim, Parth Nagarkar, Mithila Nagendra and Ren-wei Yu, “Scalable Multimedia Data Processing in Server Clusters,”

IEEE MultiMedia, pp. 3-5, 2010.

6. J. Tan, X. Pan, S. Kavulya, R. Gandhi, and P. Narasimhan, “Mochi: Visual Log-Analysis Based Tools for Debugging Hadoop,” USENIX Workshop on Hot Topics in Cloud Computing (HotCloud), pp. 1-5, 2009.

7. S. Ibrahim, H. Jin, L. Lu, L. Qi, S. Wu and X. Shi, “Evaluating MapReduce on Virtual Machines: The Hadoop Case,” Proceedings Conference Cloud Computing (CloudCom 2009), Springer LNCS, pp. 519-528, 2009. Dec.

8. C. Jin and R. Buyya, “Mapreduce programming model for net-based cloud computing,” in Proceedings of the 15th International Euro-Par Conference on Parallel Processing, Euro-Par (Berlin, Heidelberg), pp. 417–428, 2009.

9. R. Nanduri, N. Maheshwari, A. Reddyraja, and V. Varma, “Job aware scheduling algorithm for Mapreduce framework,” in 3rd International Conference on Cloud Computing Technology and Science,

CLOUDCOM ’11, (Washington, DC, USA), pp. 724–729, 2011.

10. Apache Sqoop. Available from: http://sqoop.apache.org/

11. Jenq-Shiou Leu, Yun-Sun Yee, Wa-Lin Chen, ”Comparison of Map-Reduce and SQL on Large-scale Data Processing,” International Symposium on Parallel and Distributed Processing with Applications, pp. 244-248, 2010.

12. Masato Asahara, Shinji Nakadai and Takuya Araki, “LoadAtomizer: A

(34)

Locality and I/O Load aware Task Scheduler for MapReduce,” in 4th IEEE International Conference on Cloud Computing Technology and Science (CloudCom), pp. 317-324, 2012.

13. Sanjay Ghemawat, Howard Gobioff, and ShunTak Leung, “The Google file system,” In Proceedings of 19th Symposium on Operating Systems

Principles, pp. 29-43, 2003.

14. Sven Groot, “Jumbo: Beyond MapReduce for Workload Balancing,” Fuzzy Systems and Knowledge Discovery (FSKD), 2011 Eighth International Conference on Cloud Computing Technology and Science, vol. 4, pp.

2675-2678, 2011.

15. Steven Lynden, Yusuke Tanimura, Isao Kojima and Akiyoshi Matono,”

Dynamic Data Redistribution for MapReduce Joins,” IEEE International Conference on Coud Computing Technology and Science, pp. 717-723, 2011.

16. Dawei Jiang, Anthony K. H. Tung, and Gang Chen,” MAP-JOIN-REDUCE:

Toward Scalable and Efficient Data Analysis on Large Clusters,” IEEE Transactions on knowledge and Data Engineering, vol. 23, no. 9, pp.

1299-1311, 2011.

17. A. Thusoo, J. S. Sarma, N. Jain, Z. Shao, P. Chakka, S. Anthony, H. Liu, P.

Wyckoff, and R. Murthy, “Hive - a warehousing solution over a Map-Reduce framework,” PVLDB, vol. 2, no. 2, pp. 1626–1629, 2009.

18. Rubao Lee, Tian Luo, Yin Huai, Fusheng Wang, Yongqiang He, and

Xiaodong Zhang, ” YSmart: Yet Another SQL-to-MapReduce Translator,”

International Conference on Distributed Computing Systems, pp. 25-36, 2011.

19. Hung-Ping Lin, “Structured Data Processing on MapReduce in NoSQL Database,” Master Thesis in National Chiao Tung University, 2010.

20. Meng-Ju Hsieh, Chao-Rui Chang, Jan-Jan Wu, Pangfeng Liu and Li-Yung Ho, “SQLMR : A Scalable Database Management System for Cloud Computing,” International Conference on Parallel Processing (ICPP), pp.

315-324, 2011.

21. Andrey Balmin, Tim Kaldewey, Sandeep Tata, “Clydesdale: Structured Data Processing on Hadoop,” ACM SIGMOD International Conference on

Management of Data, pp. 705-708, 2012.

22. Andrey Balmin, Tim Kaldewey, Sandeep Tata, “Clydesdale: Structured Data Processing on MapReduce,” International Conference on Extending

Database Technology, pp. 15-25, 2012.

(35)

24. Tsung-Hui Cai,” Dynamic Data Partitioning and Virtual Machine Mapping Towards Efficient Data Intensive Computation with Heterogeneous

MapReduce,” Master Thesis in Chung Hua University, 2013.

25. Alper Okcan, Mirek Riedewald, “Processing Theta-Joins using MapReduce,”

Proceedings of ACM SIGMOD International Conference on Management of data, pp. 949-960, 2011.

26. Matei Zaharia, Andy Konwinski, Anthony D. Joseph, Randy Katz and Ion Stoica, “Improving MapReduce Performance in Heterogeneous

Environments,” 8th Symposium on Operating Systems Design and Implementation, pp. 29–42, 2008.

27. Hung Chang Hsiao, Huesh Yi Chung, Haiying Shen, and Yu Chang Chao,

“Load Re-balancing for Distributed File Systems in Clouds,” IEEE Trans on Parallel and Distributed Systems, vol. 24, pp. 951-962, 2012.

28. MapReduce, Hadoop. Available from:

http://sls.weco.net/CollectiveNote20/MR.

29. HBase. Available from: http://zh.wikipedia.org/wiki/Apache_HBase.

30. Surajit Paul, “Sqoop: Big data conduit between NoSQL and RDBMS,” IBM, 2013.

31. Digital universe. Available from:

http://www.amnh.org/our-research/hayden-planetarium/digital-universe.

中 華 大 學

中 華 大 學 碩 士 論 文