複製鏈接
請複製以下鏈接發送給好友

數據立方

鎖定
我們以B+樹的結構建立了字段的索引,每個B+樹結構的字段索引相當於一個數據平面,這樣一個全局數據表與其多個重要字段的索引就組成了一個類似於立方體的數據組織結構,我們稱之為“ [1]  數據立方(DataCube)”。
中文名
數據立方
外文名
DataCube
類    型
技術架構

數據立方架構介紹

數據立方(DataCube)是一種用於數據分析與索引的技術架構。它是針對大數據(big data)的處理器,可以對元數據進行任意多關鍵字實時索引。通過數據立方對元數據進行分析之後,可以大大加快數據的查詢和檢索效率。
數據立方是凌駕於數據存儲層和數據庫系統之上的,通過數據立方解析後,可以大大增加數據查詢和檢索等業務,可以讓系統平台具備數據實時入庫、實時查詢、查詢結果實時傳輸等優勢。
主要應用於大數據處理的數據立方大數據一體機。

數據立方背景介紹

隨着計算機技術的發展,各領域數據的增長越來越快。這些數據來自方方面面,從蒐集天氣情況的感測器,接入社交媒體網站的指令,數碼圖片,在線的視頻資料,到網絡購物的交易記錄,手機的全球定位系統信號等等。隨着數據規模的急劇膨脹,各行業累積的數據量越來越巨大,數據類型也越來越多、越來越複雜,已經超越了傳統數據管理系統、處理模式的能力範圍,傳統的串行數據庫系統已經難以適應這種飛速增長的應用需求。在這種需求的驅動下,雲計算中的MapReduce技術、並行數據庫技術以及雲計算與數據庫相結合的技術應運而生。
在大數據的背景下,對大數據處理技術進行了探討,將其分為三類:MapReduce技術、並行數據庫技術和雲計算與數據庫相結合的技術。通過研究這些技術的架構、適用環境,提出了一種全新的雲計算數據庫--數據立方。

數據立方數據立方技術

雲計算中的大數據處理技術--MapReduce
MapReduce計算架構把運行在大規模集羣上的並行計算過程簡單抽象為兩個函數:Map和Reduce,也就是分解與規約。簡單説,MapReduce就是“任務的分解與結果的彙總”。程序將大數據分解為多個數據塊由Map函數處理,Reduce把分解後多任務處理產生的中間結果彙總起來,得到最終結果。適合MapReduce處理的任務特徵為:待處理的大規模數據集可以切分為多個小的數據集,並且每一個小數據集都可以完全並行地進行處理。
圖1介紹了用MapReduce處理大數據集的過程。一個MapReduce操作分為兩個階段:Map階段和Reduce階段。
圖1 MapReduce處理大數據集的過程 圖1 MapReduce處理大數據集的過程
圖1 MapReduce處理大數據集的過程
在映射階段,MapReduce並行計算架構將用户的輸入數據切分為M個數據段,每個數據段對應1個Map任務。每一個Map函數的輸入是數據段中的鍵值對集合, Map函數是用户繼承MapReduce並行計算架構而編寫的,Map操作調用此函數,輸出一組中間結果,即鍵值對 集合。接下來,按照中間結果集合的K2將中間結果集進行排序,生成一個新的 集合,使得對應同一個K2的所有值的數據都聚集在一起。然後,按照K2的範圍將這些元組分割為R個片斷,對應Reduce任務的數目。在規約階段,每一個Reduce操作的輸入是一個片斷,Reduce操作調用用户定義的Reduce函數,生成用户需要的鍵值對進行輸出。
這種簡潔的並行計算模型在系統層面解決了可用性、擴展性、容錯性等問題,是非關係數據管理和分析技術的典型代表。MapReduce是面向廉價計算機組成的大規模集羣設計的,其非共享結構、松耦合性和較強的容錯能力帶來了較強的擴展能力,同時,MapReduce在工業界被廣泛應用,Google、twitter、Facebook、Yahoo等廠商對其進行了深度的改進和擴展。此外,MapReduce的存儲模型能夠存儲任意格式的數據,Map和Reduce函數可以進行各種複雜的數據處理,這也使得程序員的負擔加重,在對上層業務的開發效率上不如SQL簡單。在相同的硬件條件下,對於有具體條件的查詢來説,並行數據庫的性能是遠遠超過MapReduce的,但是對於在大數據上的複雜統計業務來説,MapReduce在速度上會佔有一定優勢,MapReduce是為非結構化大數據的複雜處理而設計的,這些業務具有一次性處理的特點,此外由於採取了全數據掃描的模式以及對中間結果逐步彙總的策略,使其在擁有良好擴展能力和容錯能力的同時也導致了較高的磁盤和網絡I/O的負載以及較高的數據解析代價。
並行數據庫技術
在上世紀80年代,數據庫流行的同時並行數據庫也開始起源,早期並行數據庫(例如:Gamma和Grace)的基礎架構被沿用至今,當前的並行數據庫主要有Oracle的Exdata、EMC的Greenplum、Teradata和,這些數據庫都支持標準SQL。並行數據庫一般可以分為shared-nothing和shared-disk兩種存儲架構,如圖2所示。這兩種架構有各自的優缺點,在shared-nothing系統中,數據集被切分為多個子集,集羣中每個節點分別存儲。
圖2 圖2
圖2 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 的性能。
圖3 HadooopDB結構 圖3 HadooopDB結構
圖3是HadooopDB的一個結構圖,在原來的hadoop與hive的基礎上,增加了一些組件:其中SMS Planner的作用是在hive解析SQL語句生成MapReduce任務樹之後,對MapReduce任務樹進行優化,指導hadoop去並行數據庫中執行SQL。Catalog裏面存儲了並行數據庫的一些信息。Data loader負責把原始數據加載到並行數據庫中,需要完成的工作是對原始數據的劃分。Database Connector用於向各個節點傳遞信息,包含了節點裏面數據庫的鏈接信息和需要執行的SQL語句。Paralled DataBase用於代替HDFS在各個節點上存儲數據。
新一代EB級雲計算數據庫--數據立方
通過對MapReduce、並行數據庫和兩者的混合技術研究,南京雲創存儲科技有限公司推出了實施雲計算數據庫-- [1]  數據立方,該系統通過引入索引模塊、並行執行架構以及讀取本地磁盤的執行方式,使查詢達到了實時完成、簡單易用、高可靠安全的效能,使EB級的數據能夠秒級處理,極大地提高了用户執行查詢操作後的使用效率,不僅在查詢和檢索這部分數據的時候具有非常高的性能優勢,數據立方還可以支持數據倉庫存儲、數據深度挖掘和商業智能分析等業務。

數據立方體系架構

圖4 數據立方架構 圖4 數據立方架構
數據立方(DataCube)的結構分為用户接口、索引、SQL解析器、作業生成器、元數據管理、並行計算架構、分佈式文件系統等部分,如圖4所示。用户接口主要有兩個:JDBC和Shell。JDBC主要執行數據的定義操作,即建立數據庫、建表、建分區,對數據庫、表和分區的刪改等,同時可執行數據查詢的SQL語句,暫不支持單條記錄的增刪改;數據立方提供友好的shell交互界面,shell支持數據庫、表的增刪改以及數據查詢的SQL語句。
數據在入庫的同時與數據對應的索引也在同時建立,索引是一顆B樹,數據插入到內存的同時,索引B樹也在生成,當達到設置上限時,數據和索引會刷新到分佈式文件系統上成為文件。數據立方的元數據存儲在數據庫中。其中包括,數據庫的名字和屬性,數據庫中的表,表的名字,表的列和分區及其屬性,表的屬性,表的數據所在目錄等等。SQL解析器接收從JDBC和SHELL傳來的SQL查詢語句,同時對SQL進行詞法分析、語法分析、編譯、優化。作業生成器根據SQL語法樹生成查詢作業,分析所要處理的數據表對應的索引文件的所在存儲子節點位置,並將作業發送給並行計算架構。並行計算架構接收到作業生成器生成的作業,根據索引文件的位置切分查詢作業形成子任務,然後將子任務發送給數據所在的存儲子節點,每個節點執行這些子任務查詢索引得到結果記錄所在的數據文件名與偏移量,並以廣播的方式發送查詢子任務到數據文件所在的節點,在執行完畢後將結果返回。數據立方可以使用HDFS和cStor作為底層存儲系統,cStor是一個主從結構的分佈式文件系統,不僅具有HDFS的高吞吐率、高讀寫性能等特性,還支持HDFS所不具備的對文件修改等功能,並且支持POXIS接口。
分佈式並行計算架構(DPCA)
圖5 DPCA架構 圖5 DPCA架構
雲計算數據庫——數據立方的分佈式並行架構(DPCA)是典型的主從結構,主Master與從Master分別部署在HDFS的主從NameNode物理節點上,而Slave部署在DataNode物理節點上,主從Master使用Zookeeper同步,並共享系統日誌,Master與Slave之間用心跳信息保持信息交換 [2] 
相對於MapReduce架構,DPCA具有實時性、計算的數據本地性以及數據平衡性。MapReduce架構的job提交過程較為複雜,客户端將job提交到JobTracker有較長的延遲, JobTracker將job處理為MapReduce task後,通過TaskTracker的心跳信息將task任務返回給TaskTracker,此過程中也存在延遲。MapReduce架構雖然也遵循數據本地性,但仍會有很大比例的數據處理不是本地的,相對於MapReduce架構, DPCA的job提交是實時性的,在提交job之前所需程序jar包已經分發到所有計算節點,在job提交之後,master在初始化處理之後即將task直接分發到所有slave節點上在job提交後, master根據數據文件所在位置分配task,這樣在每個計算節點上要處理的HDFS上的數據塊就在本地,這樣避免了數據的移動,極大地減少了網絡IO負載,縮短了計算時間,每個計算節點會根據Task中SQL解析器生成的執行計劃對Task執行的結果進行分發,分發的方式有三種:分發所有中間數據到所有計算節點,分發所有中間數據到部分節點,根據數據所在位置分發。並行計算架構能夠週期性地對HDFS上的數據表進行維護,保持數據表在所有的DataNode節點上所存儲的數據量的平衡,減少因數據負載的不平衡而導致的計算負載的不平衡。
舉一個典型的小表與大表join連接的實例,Master解析Job中的執行計劃,判斷小表的位置後,將Task0發送給了Slave0,指令Slave0發送小表到所有節點,而其他節點接收到的子任務是等待接受小表的數據,接收到數據後將小表與大表連接並將數據返回給Master,當所有數據返回完成則這個job完成。
分佈式索引
MapReduce是對每個查詢都是直接從分佈式文件系統中讀入原始數據文件,I/O代價遠高於數據庫,相對於MapReduce架構以及在其之上的SQL解析器Hive,數據立方引入了一種高效的分佈式索引機制,不同於並行數據庫的 shared-nothing和shared-disk架構,數據立方的數據文件與索引文件都存放在分佈式文件系統之上。
圖8 B樹索引 圖8 B樹索引
圖8 B樹索引
數據在入庫的同時B樹索引在內存中同步生成,B樹中的葉子節點存儲的是數據文件路徑與記錄在文件中的偏移量,如圖8所示,在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的併發任務數,所以會更低。
圖9 併發查詢實驗 圖9 併發查詢實驗
實驗結果如圖9所示:
線性擴展實驗:
數據立方、HadoopDB和HIVE均支持線性擴展,而數據立方的擴展效率更高,即對系統的軟硬件做擴展後,性能也能夠達到類似線性的增長。
圖10 線性擴展實驗 圖10 線性擴展實驗
實驗結果如圖10所示:
 
意義:
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調度平台進行統一的配置管理。
存儲層是用來存儲數據存儲層的處理結果集或者其它中間結果集的單元。
虛擬化資源層是將實體的機器進行虛擬化,形成更大範圍的服務集羣。
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節點重新執行。 [3] 
參考資料