背景

  近年來，隨著計算機(jī)技術(shù)的發(fā)展，各領(lǐng)域數(shù)據(jù)的增長越來越快。這些數(shù)據(jù)來自方方面面，從搜集天氣情況的感測器，接入社交媒體網(wǎng)站的指令，數(shù)碼圖片，在線的視頻資料，到網(wǎng)絡(luò)購物的交易記錄，手機(jī)的定位系統(tǒng)信號等等。隨著數(shù)據(jù)規(guī)模的急劇膨脹，各行業(yè)累積的數(shù)據(jù)量越來越巨大，數(shù)據(jù)類型也越來越多、越來越復(fù)雜，已經(jīng)超越了傳統(tǒng)數(shù)據(jù)管理系統(tǒng)、處理模式的能力范圍，傳統(tǒng)的串行數(shù)據(jù)庫系統(tǒng)已經(jīng)難以適應(yīng)這種飛速增長的應(yīng)用需求。在這種需求的驅(qū)動下，云計算中的MapReduce[1]技術(shù)、并行數(shù)據(jù)庫技術(shù)以及云計算與數(shù)據(jù)庫相結(jié)合的技術(shù)應(yīng)運(yùn)而生。font>

  我們在大數(shù)據(jù)的背景下，對大數(shù)據(jù)處理技術(shù)進(jìn)行了探討，將其分為三類：MapReduce技術(shù)、并行數(shù)據(jù)庫技術(shù)和云計算與數(shù)據(jù)庫相結(jié)合的技術(shù)。通過研究這些技術(shù)的架構(gòu)、適用環(huán)境，提出了一種云計算數(shù)據(jù)庫--數(shù)據(jù)立方。font>

產(chǎn)品介紹

  通過對MapReduce、并行數(shù)據(jù)庫和兩者的混合技術(shù)研究，南京云創(chuàng)大數(shù)據(jù)科技股份有限公司推出了實施云計算數(shù)據(jù)庫--數(shù)據(jù)立方，該系統(tǒng)通過引入索引模塊、并行執(zhí)行架構(gòu)以及讀取本地磁盤的執(zhí)行方式，使查詢達(dá)到了實時完成、簡單易用、高可靠安全的效能，使EB級的數(shù)據(jù)能夠秒級處理，較大地提高了用戶執(zhí)行查詢操作后的使用效率，不僅在查詢和檢索這部分?jǐn)?shù)據(jù)的時候具有非常高的性能優(yōu)勢，數(shù)據(jù)立方還可以支持?jǐn)?shù)據(jù)倉庫存儲、數(shù)據(jù)深度挖掘和商業(yè)智能分析等業(yè)務(wù)。

數(shù)據(jù)立方的體系架構(gòu)

  數(shù)據(jù)立方（DataCube）的結(jié)構(gòu)分為用戶接口、索引、SQL解析器、作業(yè)生成器、元數(shù)據(jù)管理、并行計算架構(gòu)、分布式文件系統(tǒng)等部分，如圖4所示。用戶接口主要有兩個：JDBC和Shell。JDBC主要執(zhí)行數(shù)據(jù)的定義操作，即建立數(shù)據(jù)庫、建表、建分區(qū)，對數(shù)據(jù)庫、表和分區(qū)的刪改等，同時可執(zhí)行數(shù)據(jù)查詢的SQL語句，暫不支持單條記錄的增刪改；數(shù)據(jù)立方提供友好的shell交互界面，shell支持?jǐn)?shù)據(jù)庫、表的增刪改以及數(shù)據(jù)查詢的SQL語句。數(shù)據(jù)在入庫的同時與數(shù)據(jù)對應(yīng)的索引也在同時建立，索引是一顆B樹，數(shù)據(jù)插入到內(nèi)存的同時，索引B樹也在生成，當(dāng)達(dá)到設(shè)置上*，數(shù)據(jù)和索引會刷新到分布式文件系統(tǒng)上成為文件。數(shù)據(jù)立方的元數(shù)據(jù)存儲在數(shù)據(jù)庫中。其中包括，數(shù)據(jù)庫的名字和屬性，數(shù)據(jù)庫中的表，表的名字，表的列和分區(qū)及其屬性，表的屬性，表的數(shù)據(jù)所在目錄等等。SQL解析器接收從JDBC和SHELL傳來的SQL查詢語句，同時對SQL進(jìn)行詞法分析、語法分析、編譯、優(yōu)化。作業(yè)生成器根據(jù)SQL語法樹生成查詢作業(yè)，分析所要處理的數(shù)據(jù)表對應(yīng)的索引文件的所在存儲子節(jié)點(diǎn)位置，并將作業(yè)發(fā)送給并行計算架構(gòu)。并行計算架構(gòu)接收到作業(yè)生成器生成的作業(yè)，根據(jù)索引文件的位置切分查詢作業(yè)形成子任務(wù)，然后將子任務(wù)發(fā)送給數(shù)據(jù)所在的存儲子節(jié)點(diǎn)，每個節(jié)點(diǎn)執(zhí)行這些子任務(wù)查詢索引得到結(jié)果記錄所在的數(shù)據(jù)文件名與偏移量，并以廣播的方式發(fā)送查詢子任務(wù)到數(shù)據(jù)文件所在的節(jié)點(diǎn)，在執(zhí)行完畢后將結(jié)果返回。數(shù)據(jù)立方可以使用HDFS和cStor[19]作為底層存儲系統(tǒng)，cStor是一個主從結(jié)構(gòu)的分布式文件系統(tǒng)，不僅具有HDFS的高吞吐率、高讀寫性能等特性，還支持HDFS所不具備的對文件修改等功能，并且支持POXIS接口。

分布式并行計算架構(gòu)（DPCA）

  數(shù)據(jù)立方的分布式并行架構(gòu)（DPCA）是典型的主從結(jié)構(gòu)，主Master與從Master分別部署在HDFS的主從NameNode物理節(jié)點(diǎn)上，而Slave部署在DataNode物理節(jié)點(diǎn)上，主從Master使用Zookeeper同步，并共享系統(tǒng)日志，Master與Slave之間用心跳信息保持信息交換。

    相對于MapReduce架構(gòu)，DPCA具有實時性、計算的數(shù)據(jù)本地性以及數(shù)據(jù)平衡性。MapReduce架構(gòu)的job提交過程較為復(fù)雜，客戶端將job提交到JobTracker有較長的延遲， JobTracker將job處理為MapReduce task后，通過TaskTracker的心跳信息將task任務(wù)返回給TaskTracker，此過程中也存在延遲。MapReduce架構(gòu)雖然也遵循數(shù)據(jù)本地性，但仍會有很大比例的數(shù)據(jù)處理不是本地的，相對于MapReduce架構(gòu)， DPCA的job提交是實時性的，在提交job之前所需程序jar包已經(jīng)分發(fā)到所有計算節(jié)點(diǎn)，在job提交之后，master在初始化處理之后即將task直接分發(fā)到所有slave節(jié)點(diǎn)上，如并行計算架構(gòu)上作業(yè)執(zhí)行過程圖所示，在job提交后， master根據(jù)數(shù)據(jù)文件所在位置分配task，這樣在每個計算節(jié)點(diǎn)上要處理的HDFS上的數(shù)據(jù)塊就在本地，這樣避免了數(shù)據(jù)的移動，大大地減少了網(wǎng)絡(luò)IO負(fù)載，縮短了計算時間，每個計算節(jié)點(diǎn)會根據(jù)Task中SQL解析器生成的執(zhí)行計劃對Task執(zhí)行的結(jié)果進(jìn)行分發(fā)，分發(fā)的方式有三種：分發(fā)所有中間數(shù)據(jù)到所有計算節(jié)點(diǎn)，分發(fā)所有中間數(shù)據(jù)到部分節(jié)點(diǎn)，根據(jù)數(shù)據(jù)所在位置分發(fā)，如并行計算架構(gòu)的三中分發(fā)方式圖所示。并行計算架構(gòu)能夠周期性地對HDFS上的數(shù)據(jù)表進(jìn)行維護(hù)，保持?jǐn)?shù)據(jù)表在所有的DataNode節(jié)點(diǎn)上所存儲的數(shù)據(jù)量的平衡，減少因數(shù)據(jù)負(fù)載的不平衡而導(dǎo)致的計算負(fù)載的不平衡。

  舉一個典型的小表與大表join連接的實例，如圖7所示，Master解析Job中的執(zhí)行計劃，判斷小表的位置后，將Task0發(fā)送給了Slave0，指令Slave0發(fā)送小表到所有節(jié)點(diǎn)，而其他節(jié)點(diǎn)接收到的子任務(wù)是等待接受小表的數(shù)據(jù)，接收到數(shù)據(jù)后將小表與大表連接并將數(shù)據(jù)返回給Master，當(dāng)所有數(shù)據(jù)返回完成則這個job完成。

分布式索引

  MapReduce是對每個查詢都是直接從分布式文件系統(tǒng)中讀入原始數(shù)據(jù)文件，I/O代價遠(yuǎn)高于數(shù)據(jù)庫，相對于MapReduce架構(gòu)以及在其之上的SQL解析器Hive，數(shù)據(jù)立方引入了一種高效的分布式索引機(jī)制，不同于并行數(shù)據(jù)庫的 shared-nothing和shared-disk架構(gòu)，數(shù)據(jù)立方的數(shù)據(jù)文件與索引文件都存放在分布式文件系統(tǒng)之上。

  MapReduce數(shù)據(jù)在入庫的同時B樹索引在內(nèi)存中同步生成，B樹中的葉子節(jié)點(diǎn)存儲的是數(shù)據(jù)文件路徑與記錄在文件中的偏移量，如圖所示，在B樹中的葉子節(jié)點(diǎn)達(dá)到設(shè)置上限后，索引將被序列化到分布式文件系統(tǒng)之上，在根據(jù)條件進(jìn)行單表查詢的時，job被提交到并行計算框架，master節(jié)點(diǎn)首先分析該表的索引文件根據(jù)索引文件所在的節(jié)點(diǎn)將task發(fā)送到相應(yīng)的節(jié)點(diǎn)，每個節(jié)點(diǎn)在查詢本地的索引文件之后將符合條件的數(shù)據(jù)文件路徑+偏移量打包成task根據(jù)數(shù)據(jù)文件位置進(jìn)行再次分發(fā)，在數(shù)據(jù)文件中的記錄查詢出來之后將結(jié)果返回，如上圖所示。

測試與評估

測試環(huán)境

  MapReduce測試環(huán)境搭建在兩個機(jī)架的12臺物理機(jī)組成的集群上。每臺物理機(jī)使用Ubuntu9.04 server系統(tǒng)，JDK版本為1.6.0.18,使用的Hadoop版本為2.0.0，將HDFS作為分布式存儲環(huán)境。軟硬件配置如表1、表2所示。

  當(dāng)前與數(shù)據(jù)立方類似的產(chǎn)品有分布式數(shù)據(jù)庫和數(shù)據(jù)倉庫，如：開源的HIVE、HadoopDB等，因此我們在數(shù)據(jù)入庫、查詢、查詢的并發(fā)量以及線性擴(kuò)展等多方面對數(shù)據(jù)立方、HIVE和HadoopDB做了對比測試。

數(shù)據(jù)入庫測試

  數(shù)據(jù)立方能夠快速進(jìn)行數(shù)據(jù)入庫同時實時建立索引，相對于基于傳統(tǒng)數(shù)據(jù)庫的HadoopDB來說具有天然的優(yōu)勢，而對于HIVE來說，雖然入庫速度相差不大，但由于HIVE在數(shù)據(jù)入庫的同時并沒有建立索引使其在查詢的過程中沒有優(yōu)勢。測試結(jié)果如下圖所示：

單表查詢測試

  對于簡單的單表查詢來說，數(shù)據(jù)量較小時，HadoopDB與數(shù)據(jù)立方的查詢速度都是比較快的，但在大數(shù)據(jù)量下，數(shù)據(jù)立方的高效分布式查詢更有優(yōu)勢，而HIVE的底層是基于MapReduce，所以速度較慢。測試結(jié)果如下圖所示：

多表查詢測試

  在多表查詢方面，在小表與小表、大表與小表之間的關(guān)聯(lián)查詢，數(shù)據(jù)立方和HadoopDB都是較快的，但在大表與大表之間做關(guān)聯(lián)查詢時，數(shù)據(jù)立方相對于HadoopDB更快，而HIVE是很慢的。測試結(jié)果如下圖所示：

并發(fā)查詢測試

  數(shù)據(jù)立方的每個節(jié)點(diǎn)支持200個并發(fā)查詢，同時每個查詢均是秒級響應(yīng)，HadoopDB由于是SMS的中間層，由于MapReduce架構(gòu)本身的心跳機(jī)制而導(dǎo)致了較大的延遲，所以是很難達(dá)到秒級響應(yīng)的，HIVE的任務(wù)并發(fā)數(shù)取決于MapReduce的并發(fā)任務(wù)數(shù)，所以會更低。測試結(jié)果如下圖所示：

線性擴(kuò)展測試

  數(shù)據(jù)立方、HadoopDB和HIVE均支持線性擴(kuò)展，而數(shù)據(jù)立方的擴(kuò)展效率更高，即對系統(tǒng)的軟硬件做擴(kuò)展后，性能也能夠達(dá)到類似線性的增長。測試結(jié)果如下圖所示：