數據立方

我們以B+樹的結構建立了欄位的索引，每個B+樹結構的欄位索引相當於一個數據平面，這樣一個全局數據表與其多個重要欄位的索引就組成了一個類似於立方體的數據組織結構，我們稱之為“數據立方(DataCube)”。

基本介紹

• 中文名：數據立方
• 外文名：DataCube
• 用於：數據分析與索引
• 類型：技術架構

架構介紹

數據立方(DataCube)是一種用於數據分析與索引的技術架構。它是針對大數據(big data)的處理利器，可以對元數據進行任意多關鍵字實時索引。通過數據立方對元數據進行分析之後，可以大大加快數據的查詢和檢索效率。

數據立方是凌駕於數據存儲層和資料庫系統之上的，通過數據立方解析後，可以大大增加數據查詢和檢索等業務，可以讓系統平台具備數據實時入庫、實時查詢、查詢結果實時傳輸等優勢。

主要套用於大數據處理的數據立方大數據一體機。

背景

隨著計算機技術的發展，各領域數據的增長越來越快。這些數據來自方方面面，從蒐集天氣情況的感測器，接入社交媒體網站的指令，數碼圖片，線上的視頻資料，到網路購物的交易記錄，手機的全球定位系統信號等等。隨著數據規模的急劇膨脹，各行業累積的數據量越來越巨大，數據類型也越來越多、越來越複雜，已經超越了傳統數據管理系統、處理模式的能力範圍，傳統的串列資料庫系統已經難以適應這種飛速增長的套用需求。在這種需求的驅動下，雲計算中的MapReduce技術、並行資料庫技術以及雲計算與資料庫相結合的技術應運而生。

在大數據的背景下，對大數據處理技術進行了探討，將其分為三類：MapReduce技術、並行資料庫技術和雲計算與資料庫相結合的技術。通過研究這些技術的架構、適用環境，提出了一種全新的雲計算資料庫－－數據立方。

數據立方技術

雲計算中的大數據處理技術－－MapReduce

MapReduce計算架構把運行在大規模集群上的並行計算過程簡單抽象為兩個函式：Map和Reduce，也就是分解與規約。簡單說，MapReduce就是“任務的分解與結果的匯總”。程式將大數據分解為多個數據塊由Map函式處理，Reduce把分解後多任務處理產生的中間結果匯總起來，得到最終結果。適合MapReduce處理的任務特徵為：待處理的大規模數據集可以切分為多個小的數據集，並且每一個小數據集都可以完全並行地進行處理。

圖1介紹了用MapReduce處理大數據集的過程。一個MapReduce操作分為兩個階段：Map階段和Reduce階段。

圖1 MapReduce處理大數據集的過程

圖1 MapReduce處理大數據集的過程

在映射階段，MapReduce並行計算架構將用戶的輸入數據切分為M個數據段，每個數據段對應1個Map任務。每一個Map函式的輸入是數據段中的鍵值對<K1,V1>集合， Map函式是用戶繼承MapReduce並行計算架構而編寫的，Map操作調用此函式，輸出一組中間結果，即鍵值對<K2,V2> 集合。接下來，按照中間結果集合的K2將中間結果集進行排序，生成一個新的<K2,list(V2)> 集合，使得對應同一個K2的所有值的數據都聚集在一起。然後，按照K2的範圍將這些元組分割為R個片斷，對應Reduce任務的數目。在規約階段，每一個Reduce操作的輸入是一個<K2,list(V2)>片斷，Reduce操作調用用戶定義的Reduce函式，生成用戶需要的鍵值對<K3,V3>進行輸出。

這種簡潔的並行計算模型在系統層面解決了可用性、擴展性、容錯性等問題，是非關係數據管理和分析技術的典型代表。MapReduce是面向廉價計算機組成的大規模集群設計的，其非共享結構、松耦合性和較強的容錯能力帶來了較強的擴展能力，同時，MapReduce在工業界被廣泛套用，Google、twitter、Facebook、Yahoo等廠商對其進行了深度的改進和擴展。此外，MapReduce的<key,value>存儲模型能夠存儲任意格式的數據，Map和Reduce函式可以進行各種複雜的數據處理，這也使得程式設計師的負擔加重，在對上層業務的開發效率上不如SQL簡單。在相同的硬體條件下，對於有具體條件的查詢來說，並行資料庫的性能是遠遠超過MapReduce的，但是對於在大數據上的複雜統計業務來說，MapReduce在速度上會占有一定優勢，MapReduce是為非結構化大數據的複雜處理而設計的，這些業務具有一次性處理的特點，此外由於採取了全數據掃描的模式以及對中間結果逐步匯總的策略，使其在擁有良好擴展能力和容錯能力的同時也導致了較高的磁碟和網路I/O的負載以及較高的數據解析代價。

並行資料庫技術

在上世紀80年代，資料庫流行的同時並行資料庫也開始起源，早期並行資料庫（例如：Gamma和Grace）的基礎架構被沿用至今，當前的並行資料庫主要有Oracle的Exdata、EMC的Greenplum、Teradata和，這些資料庫都支持標準SQL。並行資料庫一般可以分為shared-nothing和shared-disk兩種存儲架構，如圖2所示。這兩種架構有各自的優缺點，在shared-nothing系統中，數據集被切分為多個子集，集群中每個節點分別存儲。

shared-nothing和shared-disk存儲架構

一個子集在本地磁碟上，一般來說，shared-nothing系統可以提供很高的並行I/O和並行計算能力，但是也有多節點事務處理、數據傳輸以及數據傾斜等問題。在shared-disk系統中，數據被集中存儲，所有的資料庫節點都可以訪問存儲系統的任意一個磁碟，因此數據也沒有必要被切分，這也避免了數據傾斜的問題，這種系統主要的缺陷在於較低的I/O頻寬和擴展能力。

雲計算與資料庫相結合的技術

與資料庫相結合的雲計算技術一般指的是MapReduce技術，當前主要有Teradata公司的Aster Data[15]和耶魯大學提出的HadoopDB。

Aster Data將MapReduce與SQL引擎相結合，針對大數據處理和分析提出了SQL/MapReduce框架，用戶可以使用JAVA、C++等多種語言在Aster Data的並行框架上編寫MapReduce函式，編寫的函式可以作為一個子查詢在SQL中使用，從而獲得SQL的易用性和MapReduce的開放性。同時Aster Data能夠對多結構化數據、原始數據進行處理和分析，並擁有豐富的統計軟體包可以講數據分析推向資料庫內進行，提升了數據分析性能。

在HadoopDB 中,系統清晰地分成兩層,上層使用 Hadoop 進行任務的分解和調度,下層用 RDBMS(Postgresql)進行數據的查詢和處理，在處理查詢時，執行的是SQL to mapReduce to SQL操作過程(SMS planner)。該工作的創新之處是:試圖利用 Hadoop 的任務調度機制提高系統的擴展性和容錯性,以解決大數據分析的橫向擴展問題;利用 RDBMS 實現數據存儲和查詢處理,以解決性能問題.在其性能實驗中,HadoopDB 的性能仍然落後於關係資料庫系統.如何提升MapReduce的性能,已引起研究人員的高度重視,研究人員提出了MapReduce的各種最佳化技術,獲得了重要的性能改進.Yale 大學 Abadi 領導的小組正在使用包括列存儲、持續裝載和分析(continuous loading and analysis)等技術,以改進 HadoopDB 的性能。

HadooopDB結構

圖3是HadooopDB的一個結構圖，在原來的hadoop與hive的基礎上，增加了一些組件：其中SMS Planner的作用是在hive解析SQL語句生成MapReduce任務樹之後，對MapReduce任務樹進行最佳化，指導hadoop去並行資料庫中執行SQL。Catalog裡面存儲了並行資料庫的一些信息。Data loader負責把原始數據載入到並行資料庫中，需要完成的工作是對原始數據的劃分。Database Connector用於向各個節點傳遞信息，包含了節點裡面資料庫的連結信息和需要執行的SQL語句。Paralled DataBase用於代替HDFS在各個節點上存儲數據。

新一代EB級雲計算資料庫－－數據立方

通過對MapReduce、並行資料庫和兩者的混合技術研究，南京雲創存儲科技有限公司推出了實施雲計算資料庫－－數據立方，該系統通過引入索引模組、並行執行架構以及讀取本地磁碟的執行方式，使查詢達到了實時完成、簡單易用、高可靠安全的效能，使EB級的數據能夠秒級處理，極大地提高了用戶執行查詢操作後的使用效率，不僅在查詢和檢索這部分數據的時候具有非常高的性能優勢，數據立方還可以支持數據倉庫存儲、數據深度挖掘和商業智慧型分析等業務。

體系架構

數據立方（DataCube）的結構分為用戶接口、索引、SQL解析器、作業生成器、元數據管理、並行計算架構、分散式檔案系統等部分，如圖4所示。用戶接口主要有兩個：JDBC和Shell。JDBC主要執行數據的定義操作，即建立資料庫、建表、建分區，對資料庫、表和分區的刪改等，同時可執行數據查詢的SQL語句，暫不支持單條記錄的增刪改；數據立方提供友好的shell互動界面，shell支持資料庫、表的增刪改以及數據查詢的SQL語句。

圖4 數據立方架構

數據在入庫的同時與數據對應的索引也在同時建立，索引是一顆B樹，數據插入到記憶體的同時，索引B樹也在生成，當達到設定上限時，數據和索引會刷新到分散式檔案系統上成為檔案。數據立方的元數據存儲在資料庫中。其中包括，資料庫的名字和屬性，資料庫中的表，表的名字，表的列和分區及其屬性，表的屬性，表的數據所在目錄等等。SQL解析器接收從JDBC和SHELL傳來的SQL查詢語句，同時對SQL進行詞法分析、語法分析、編譯、最佳化。作業生成器根據SQL語法樹生成查詢作業，分析所要處理的數據表對應的索引檔案的所在存儲子節點位置，並將作業傳送給並行計算架構。並行計算架構接收到作業生成器生成的作業，根據索引檔案的位置切分查詢作業形成子任務，然後將子任務傳送給數據所在的存儲子節點，每個節點執行這些子任務查詢索引得到結果記錄所在的數據檔案名稱與偏移量，並以廣播的方式傳送查詢子任務到數據檔案所在的節點，在執行完畢後將結果返回。數據立方可以使用HDFS和cStor作為底層存儲系統，cStor是一個主從結構的分散式檔案系統，不僅具有HDFS的高吞吐率、高讀寫性能等特性，還支持HDFS所不具備的對檔案修改等功能，並且支持POXIS接口。

分散式並行計算架構（DPCA）

雲計算資料庫——數據立方的分散式並行架構（DPCA）是典型的主從結構，主Master與從Master分別部署在HDFS的主從NameNode物理節點上，而Slave部署在DataNode物理節點上，主從Master使用Zookeeper同步，並共享系統日誌，Master與Slave之間用心跳信息保持信息交換。

圖5 DPCA架構

相對於MapReduce架構，DPCA具有實時性、計算的數據本地性以及數據平衡性。MapReduce架構的job提交過程較為複雜，客戶端將job提交到JobTracker有較長的延遲， JobTracker將job處理為MapReduce task後，通過TaskTracker的心跳信息將task任務返回給TaskTracker，此過程中也存在延遲。MapReduce架構雖然也遵循數據本地性，但仍會有很大比例的數據處理不是本地的，相對於MapReduce架構， DPCA的job提交是實時性的，在提交job之前所需程式jar包已經分發到所有計算節點，在job提交之後，master在初始化處理之後即將task直接分發到所有slave節點上，如圖6所示，在job提交後， master根據數據檔案所在位置分配task，這樣在每個計算節點上要處理的HDFS上的數據塊就在本地，這樣避免了數據的移動，極大地減少了網路IO負載，縮短了計算時間，每個計算節點會根據Task中SQL解析器生成的執行計畫對Task執行的結果進行分發，分發的方式有三種：分發所有中間數據到所有計算節點，分發所有中間數據到部分節點，根據數據所在位置分發，如圖7所示。並行計算架構能夠周期性地對HDFS上的數據表進行維護，保持數據表在所有的DataNode節點上所存儲的數據量的平衡，減少因數據負載的不平衡而導致的計算負載的不平衡。

舉一個典型的小表與大表join連線的實例，如圖7所示，Master解析Job中的執行計畫，判斷小表的位置後，將Task0傳送給了Slave0，指令Slave0傳送小表到所有節點，而其他節點接收到的子任務是等待接受小表的數據，接收到數據後將小表與大表連線並將數據返回給Master，當所有數據返回完成則這個job完成。

分散式索引

MapReduce是對每個查詢都是直接從分散式檔案系統中讀入原始數據檔案，I/O代價遠高於資料庫，相對於MapReduce架構以及在其之上的SQL解析器Hive，數據立方引入了一種高效的分散式索引機制，不同於並行資料庫的 shared-nothing和shared-disk架構，數據立方的數據檔案與索引檔案都存放在分散式檔案系統之上。

B樹索引

圖8 B樹索引

數據在入庫的同時B樹索引在記憶體中同步生成，B樹中的葉子節點存儲的是數據檔案路徑與記錄在檔案中的偏移量，如圖所示，在B樹中的葉子節點達到設定上限後，索引將被序列化到分散式檔案系統之上，在根據條件進行單表查詢的時，job被提交到並行計算框架，master節點首先分析該表的索引檔案根據索引檔案所在的節點將task傳送到相應的節點，每個節點在查詢本地的索引檔案之後將符合條件的數據檔案路徑+偏移量打包成task根據數據檔案位置進行再次分發，在數據檔案中的記錄查詢出來之後將結果返回，如圖8所示。

實驗與評估

實驗環境

實驗環境搭建在兩個機架的12台物理機組成的集群上。每台物理機使用Ubuntu9.04 server系統，JDK版本為1.6.0.18,使用的Hadoop版本為2.0.0，將HDFS作為分散式存儲環境。軟硬體配置如表1、表2所示。

當前與數據立方類似的產品有分散式資料庫和數據倉庫，如：開源的HIVE、HadoopDB等，因此我們在數據入庫、查詢、查詢的並發量以及線性擴展等多方面對數據立方、HIVE和HadoopDB做了對比實驗。

數據入庫實驗

數據立方能夠快速進行數據入庫同時實時建立索引，相對於基於傳統資料庫的HadoopDB來說具有天然的優勢，而對於HIVE來說，雖然入庫速度相差不大，但由於HIVE在數據入庫的同時並沒有建立索引使其在查詢的過程中沒有優勢。

實驗結果如下圖所示：

數據入庫實驗

單表查詢實驗：

數據立方的每個節點支持200個並發查詢，同時每個查詢均是秒級回響，HadoopDB由於是SMS的中間層，由於MapReduce架構本身的心跳機制而導致了較大的延遲，所以是很難達到秒級回響的，HIVE的任務並發數取決於MapReduce的並發任務數，所以會更低。

實驗結果如下圖所示：

並發查詢實驗

線性擴展實驗：

數據立方、HadoopDB和HIVE均支持線性擴展，而數據立方的擴展效率更高，即對系統的軟硬體做擴展後，性能也能夠達到類似線性的增長。

實驗結果如下圖所示：

線性擴展實驗

　

意義：

Hadoop是一種流行的MapReduce計算模型的開源實現，用於大規模數據集的並行化分析處理，並行資料庫是在單機資料庫基礎之上發展而來的資料庫集群，通過研究MapReduce技術、並行資料庫技術以及混合技術探討了一系列相關的大數據處理技術，更深一步探索了基於分散式檔案系統的並行計算架構和分散式海量數據實時索引機制，以此為基礎並輔以其他技術形成了一個支持非結構化、結構化和半結構化數據高效存儲，支持離線數據分析和線上專題套用，支持結構化數據與非結構化、半結構化數據之間的複雜計算的實時雲計算資料庫數據立方。

數據一體機

數據立方大數據一體機是一種處理海量數據的高效分散式軟硬體集合的雲處理平台，該平台可以從TB乃至PB級的數據中挖掘出有用的信息，並對這些海量信息進行快捷、高效的處理。平台支持100GBps以上量級的數據流實時索引，秒級回響客戶請求，秒級完成數據處理、查詢和分析工作。平台可以對入口數據進行實時索引，對數據進行分析、清理、分割，並將其存儲在雲存儲系統上，不僅在入庫和檢索時具有非常高的性能優勢,還可以支持數據深度挖掘和商業智慧型分析等業務。

系統架構

cProc雲處理平台是搭建在雲存儲系統上，對業務層直接提供對外開發接口和數據傳輸接口的分散式數據處理平台。cProc雲處理平台是一種處理海量數據的並行編程模型和計算框架，用於對大規模數據集的並行計算。

系統架構

雲存儲層包括cStor雲存儲和apache開源雲儲存系統HDFS;而在數據管理層中，包含數據立方、Hbase;數據處理層包含JobKeeper和MapReduce;最後的監控協調層則包括zookeeper和Chukwa來實現對整個系統的實時監控和數據管理。

cProc雲計算平台通過把對數據集的大規模操作分發給網路上的每個節點實現數據處理,每個節點會周期性的把完成的工作和狀態的更新報告回來。隨著節點的增多，cProc雲計算平台的處理能力將成倍數增長。cProc支持100GBps以上量級的數據流實時索引，1s內回響客戶請求，秒級完成數據處理、查詢和分析工作。

任務監控器

JobKeeper調度平台是建立於虛擬化資源層之上，統一調度，統一配置的管理平台，用於對集群中任務實時的處理調度，實時結果集的反饋，集群的負載均衡，失敗調度，集中管理，集中配置的平台。用來保證整個集群的超低人員干預。同時，提供完善的集群伸縮機制為整個服務提供更高的可靠性。

任務監控器（JobKeeper）

套用層是一組用於管理和結果反饋的顯示組件，用於顯示任務的處理情況以及集群中機器的活動情況，同時其也是一個上層套用和底層服務的對接平台，是整個系統面向用戶和開發人員的基礎承載。

業務層是對於套用層的相關功能的業務化，數位化處理，用於將套用層的需求任務進行規則化劃分，形成統一的處理化模式。

數據處理層是獨立的數據處理程式，是對不同需求數據的統一處理方案，它的運行與監控的工作將由JobKeeper調度平台進行統一的配置管理。

存儲層是用來存儲數據存儲層的處理結果集或者其它中間結果集的單元。

虛擬化資源層是將實體的機器進行虛擬化，形成更大範圍的服務集群。

JobKeeper調度平台是由一組管理節點(Master Node)和一組處理節點(Task Node)組成，管理節點組是一組基於Webserver的RPC(RPC採用客戶機/伺服器模式。請求程式就是一個客戶機，而服務提供程式就是一個伺服器。首先，客戶機調用進程傳送一個有進程參數的調用信息到服務進程，然後等待應答信息。在伺服器端，進程保持睡眠狀態直到調用信息的到達為止。當一個調用信息到達，伺服器獲得進程參數，計算結果，傳送答覆信息，然後等待下一個調用信息，最後，客戶端調用進程接收答覆信息，獲得進程結果，然後調用執行繼續進行。)伺服器，負責對處理節點的系統信息以及任務處理信息進行實時的跟蹤和保存，對應的信息鏡像存儲在基於cStor或者NFS服務的存儲系統上，保證每個管理節點中的鏡像信息的實時同步。同時架設在管理節點上的ZooKeeper服務(ZooKeeper是一個分散式的，開放源碼的分散式應用程式協調服務，包含一個簡單的原語集。分散式套用可以使用它來實現諸如：統一命名服務、配置管理、分散式鎖服務、集群管理等功能。)用於對整個管理節點組進行統一的配置化管理。處理節點組通過RPC的遠程調用獲取各自節點的任務處理目標，並實時的和處理節點上的任務處理目標進行對比，控制程式的執行和結束。(註：這裡的程式，可以是任何語言任何形式的獨立程式，但是必須提供執行腳本，和運行參數選項)處理節點組會在一個設定的心跳間隔內主動的和管理節點組聯繫一次，報告節點存活狀態。如果在若干個心跳間隔後管理節點組仍然沒有獲取到處理節點心跳報告，那么該處理節點將會被踢出處理節點組，同時該節點處理的所有處理任務也會被重新調度。隨著集群處理數據量的不斷增大，處理節點組提供了簡單高效的自動化部署方案，當新機器加入處理集群後，會主動的與管理節點組同步心跳信息，從同一配置伺服器ZooKeeper上獲取相關配置信息，通過WebServer服務獲取任務列表，開始執行數據處理工作。

JobKeeper調度平台提供了一套基於Web的管理化界面，可以實時的觀察各個處理節點的任務運行狀態，以及任務列表的分配情況，機器的負載情況等。用戶在管理系統界面上可以完成所有的工作，如新任務的添加，任務的手動調度以及集群日誌的查看與分析等。

可靠性設計

使用ZooKeeper的選舉機制解決MapReduce的單點故障，當JobTracker節點宕機時，能夠在一台備用的JobTracker節點上啟動JobTracker進程，並使用虛擬IP機制將虛擬IP指向備用JobTracker節點。在JobTracker進程啟動後，ZooKeeper將未完成的MapReduce作業提交給備用JobTracker節點重新執行。