張延松， 王 珊， 周 烜

（1.中國人民大學DEKE實驗室，北京 100872；2.中國人民大學 信息學院，北京 100872；3.中國人民大學 中國調(diào)查與數(shù)據(jù)中心，北京 100872）

0 引 言

數(shù)據(jù)倉庫是企業(yè)級大數(shù)據(jù)應用重要的平臺，長期以來一直受性能問題的制約而難以在企業(yè)級實時分析處理（Real Time Analytics）領域發(fā)揮出其應有的作用.隨著計算機硬件技術的發(fā)展，多核處理器和大內(nèi)存成為主流配置，如最新的Intel？Xeon？Processor E7－8890

v2處理器擁有15個處理內(nèi)核、30線程，每插槽最大支持1.5TB內(nèi)存，而DRAM的價格每12個月下降32%，內(nèi)存計算技術在內(nèi)存容量支持、硬件成本和計算性能等幾個方面已經(jīng)能夠滿足企業(yè)級大數(shù)據(jù)計算的需求，內(nèi)存計算平臺逐漸成為大數(shù)據(jù)計算新興的高性能平臺.Gartner公司在2013年IT行業(yè)十大技術發(fā)展趨勢中指出內(nèi)存計算將成為主流［1］，內(nèi)存數(shù)據(jù)庫技術，已經(jīng)被越來越多的傳統(tǒng)和新興的數(shù)據(jù)庫廠商所采納，如MonetDB［2］、Vectorwise［3］、HANA［4］、IWA［5］、Oracle Exadata X3［6］、SQL server2014［7］等，并成為主流產(chǎn)品，內(nèi)存數(shù)據(jù)庫不僅能夠提供傳統(tǒng)數(shù)據(jù)庫無法實現(xiàn)的實時分析處理性能，由于內(nèi)存相對于磁盤能耗更低，內(nèi)存數(shù)據(jù)庫技術的引入還能夠更好地降低數(shù)據(jù)中心總成本（TCO）［8］.同時，由于內(nèi)存計算性能更高，不需要依賴存儲代價極大的物化視圖及索引機制，在列存儲和壓縮技術的支持下，內(nèi)存存儲相對于傳統(tǒng)的磁盤存儲具有更高的效率.

在軟、硬件技術的支持下，內(nèi)存數(shù)據(jù)倉庫將會成為新的大數(shù)據(jù)實時分析處理平臺.內(nèi)存數(shù)據(jù)倉庫需要解決的關鍵問題主要包括性能和擴展性.內(nèi)存相對于傳統(tǒng)的磁盤，其數(shù)據(jù)訪問性能得到了極大的提升，但內(nèi)存訪問延遲和帶寬性能的緩慢提升使大內(nèi)存相對于高性能多核處理器成為“新硬盤”，仍然是內(nèi)存數(shù)據(jù)倉庫大數(shù)據(jù)處理性能的瓶頸因素.性能問題，一方面需要采用多核CPU、GPU、Phi協(xié)處理器等新硬件提升數(shù)據(jù)處理性能；另一方面需要面向Flash、PCM（相變存儲）等新的存儲硬件技術提高性價比和綜合性能.在當前硬件水平下，內(nèi)存數(shù)據(jù)倉庫集群仍然是擴展內(nèi)存數(shù)據(jù)倉庫處理能力和性能的有效技術手段，通過中低端內(nèi)存計算集群構建高性能內(nèi)存數(shù)據(jù)倉庫平臺，降低內(nèi)存數(shù)據(jù)倉庫的成本并提供高可擴展的并行內(nèi)存計算能力.

內(nèi)存數(shù)據(jù)倉庫集需要解決兩類關鍵技術問題：數(shù)據(jù)分布模型和集群計算模型.數(shù)據(jù)分布模型需要考慮模式和關系兩個層面的分布策略：模式層面的分布策略需要考慮數(shù)據(jù)倉庫中不同類型的表，如維表和事實表，如何在集群中分布存儲，分布模型所帶來的數(shù)據(jù)存儲代價以及數(shù)據(jù)更新代價；關系層面的分布模型需要考慮采用基于行還是基于列的分布存儲模型等問題.集群計算模型則以數(shù)據(jù)分布式存儲模型為基礎，針對不同計算類型實現(xiàn)不同的并行計算.

本文以內(nèi)存數(shù)據(jù)倉庫集群技術為中心，概要地介紹了我們在內(nèi)存數(shù)據(jù)倉庫集群技術方面的研究技術、方法和手段，探討在不同的應用需求和硬件支持下的內(nèi)存數(shù)據(jù)倉庫集群不同的實現(xiàn)技術及其特點.大體結構是第1節(jié)介紹以列相關分布模型和列計算服務為基礎的內(nèi)存數(shù)據(jù)倉庫集群系統(tǒng)ScaMMDB的設計思想和系統(tǒng)實現(xiàn)技術路線；第2節(jié)介紹基于水平分片的內(nèi)存數(shù)據(jù)倉庫集群系統(tǒng)ScaMMDBⅡ及其面向不同類型聚集函數(shù)的并行查詢處理技術；第3節(jié)介紹基于reverse－star schema數(shù)據(jù)分布模型和向量處理技術的內(nèi)存數(shù)據(jù)倉庫集群系統(tǒng)MiNT－OLAPCluster系統(tǒng)的實現(xiàn)技術；第4節(jié)總結全文并對內(nèi)存數(shù)據(jù)倉庫集群技術的技術發(fā)展趨勢進行展望和分析.

1 基于列相關分布模型和列計算服務的ScaMMDB系統(tǒng)

MonetDB是一種基于列存儲和BAT algebra列計算的開源數(shù)據(jù)庫系統(tǒng)，是分析型內(nèi)存數(shù)據(jù)庫最具代表性的系統(tǒng).MonetDB的高性能構建在充足內(nèi)存空間的基礎上，當數(shù)據(jù)量超過內(nèi)存容量時，MonetDB通過虛擬內(nèi)存進行I／O交換，查詢處理性能受到極大的影響.ScaMMDB系統(tǒng)根據(jù)網(wǎng)絡技術的發(fā)展趨勢構建了一個基于高速網(wǎng)絡平臺的可擴展內(nèi)存數(shù)據(jù)庫集群系統(tǒng)，將數(shù)據(jù)和計算分布在不同的節(jié)點上，通過集群擴展技術保證內(nèi)存存儲和內(nèi)存計算，其關鍵技術包括：基于網(wǎng)絡傳輸代價的列分布策略、基于內(nèi)存塊的節(jié)點間列復制技術、分布式列計算技術等.

1.1 ScaMMDB系統(tǒng)結構

ScaMMDB是一種協(xié)同計算模式的內(nèi)存數(shù)據(jù)庫集群，如圖1所示，數(shù)據(jù)庫以列為單位在集群節(jié)點的內(nèi)存上進行數(shù)據(jù)分布.每個節(jié)點均可以訪問本地內(nèi)存和其他節(jié)點的網(wǎng)絡虛擬內(nèi)存NetMemory，通過輕量數(shù)據(jù)字典表獲取每個列的存儲位置信息，將計算下推到列存儲節(jié)點，完成協(xié)同計算任務，只將列操作結果傳回查詢發(fā)起節(jié)點.在并發(fā)查詢處理時，查詢?nèi)蝿湛梢跃獾胤植荚诩褐械乃泄?jié)點，每個節(jié)點負責完成本節(jié)點和其他節(jié)點的協(xié)同式列計算任務.數(shù)據(jù)列作為存儲的基本單位提供列上的計算服務，可以由本地節(jié)點調(diào)用列計算API，也可以由集群其他節(jié)點遠程調(diào)用，每個節(jié)點既是查詢服務的提供者又是查詢服務的消費者，集群節(jié)點通過協(xié)同計算完成整個查詢?nèi)蝿?當集群規(guī)模變化時，即增加或減少集群節(jié)點時，通過數(shù)據(jù)列在節(jié)點間的遷移和對輕量數(shù)據(jù)字典的更新重置列計算API調(diào)用的服務位置.

圖1 ScaMMDB系統(tǒng)結構Fig.1 Architecture of ScaMMDB

1.2 ScaMMDB的關鍵技術

ScaMMDB的目標是構建一個可擴展的虛擬內(nèi)存以支持大數(shù)據(jù)內(nèi)存分析，基礎的技術假設是高速網(wǎng)絡技術的發(fā)展使網(wǎng)絡帶寬的增長速度大大優(yōu)于磁盤I／O的增長速度.世界超級計算機500強系統(tǒng)中主要采用InfiniBand和千兆以太網(wǎng)技術，這兩種技術都能夠提供超過100Gbps的數(shù)據(jù)傳輸性能.基于高速互聯(lián)網(wǎng)絡的虛擬網(wǎng)絡內(nèi)存NetMemory可以作為本地內(nèi)存的下一級存儲，共享集群中節(jié)點內(nèi)存存儲資源.Oracle RAC的內(nèi)存融合技術（Cache Fusion）實現(xiàn)共享內(nèi)存訪問，將集群節(jié)點的內(nèi)存融合為一個虛擬的大內(nèi)存.分布式內(nèi)存技術（distributed shared memory，DSM）是一種將本地和遠程節(jié)點內(nèi)存通過虛擬內(nèi)存地址來訪問和處理的技術，也是一種構建集群虛擬內(nèi)存的技術.與這兩種虛擬內(nèi)存技術不同，ScaMMDB的NetMemory的存儲單位是數(shù)據(jù)列，通過MonetDB底層的BAT訪問API將遠程數(shù)據(jù)列上的操作下推到列存儲節(jié)點，通過遠程BAT操作API的調(diào)用實現(xiàn)數(shù)據(jù)列的本地計算，只將較小的列處理結果返回數(shù)據(jù)請求節(jié)點.相對于Cache Fusion和DSM技術，NetMemory提供的不僅僅是虛擬內(nèi)存上的存儲訪問服務，還包括遠程節(jié)點的列計算服務.

ScaMMDB系統(tǒng)的關鍵技術包括如何實現(xiàn)基于集群節(jié)點協(xié)同計算模式的查詢重寫，如何優(yōu)化數(shù)據(jù)列的網(wǎng)絡傳輸性能，如何根據(jù)查詢負載特征實現(xiàn)數(shù)據(jù)列的關聯(lián)分布等.

1.2.1 基于集群節(jié)點協(xié)同計算模式的查詢重寫

SQL命令在MonetDB內(nèi)部被轉(zhuǎn)換為MAL命令集，由查詢引擎執(zhí)行.我們通過客戶端獲得SQL命令，根據(jù)MAL命令轉(zhuǎn)換規(guī)則將其重寫并由MAL引擎執(zhí)行，完成ExMAL的執(zhí)行.在將MAL命令序列轉(zhuǎn)換為ExMAL命令執(zhí)行序列時，我們通過擴展MonetDB底層的mserver.connect（）函數(shù)實現(xiàn)集群節(jié)點間的遠程列計算調(diào)用，并開發(fā)了節(jié)點間列復制接口mserver.PutBat（）和mserver.GetBat（），實現(xiàn)從遠程節(jié)點中獲取BAT和將當前BAT推送到遠程節(jié)點的操作，通過MonetDB的BBP緩沖池機制實現(xiàn)不同線程之間的列數(shù)據(jù)共享訪問.在擴展的底層BAT接口的支持下，SQL命令能夠被改寫為面向集群分布式列存儲模型的協(xié)同計算ExMAL命令集.

如圖2所示的TPC－H的Q1測試查詢對應的MAL命令序列中，兩條MAL命令分別在場地：node1和node2上執(zhí)行，其中，在node2上執(zhí)行的MAL命令需要node1上的BAT作為操作數(shù)BAT，需要通過線程間數(shù)據(jù)共享訪問機制和GetBAT完成BAT遠程復制.

圖2所示的例子中，遠程MAL命令執(zhí)行步驟如下：

（1）在主控節(jié)點node0上建立與node1的連接；

（2）通過與node1的連接，將BAT的bind命令發(fā)送到node1節(jié)點上運行；（3）在主控節(jié)點node0上建立與node2的連接；

（4）通過與node2的連接，在node2上執(zhí)行與node1的連接；

（5）node0與node1的連接與node2與node1的連接對應不同的處理線程，通過將node1連接中的BAT變量＿56裝入BBP，然后在node2的連接中訪問BBP中的共享變量＿56；

（6）通過node1與node2的連接，在node2上執(zhí)行遠程復制node1上的BAT＿56；

（7）通過GetBAT（RemoteBind）在本地生成遠程BAT復本；

（8）通過與node2的連接，在node2上執(zhí)行連接操作.

圖2 ScaMMDB的協(xié)同計算［9］Fig.2 Co－computing in ScaMMDB［9］

當MAL命令中涉及不同節(jié)點上的BAT時，需要通過對BAT大小和數(shù)量的估算評估網(wǎng)絡傳輸代價，選擇網(wǎng)絡傳輸代價最低的節(jié)點作為當前MAL命令的執(zhí)行節(jié)點.

1.2.2 數(shù)據(jù)列的網(wǎng)絡傳輸優(yōu)化技術

集群節(jié)點間進行列數(shù)據(jù)傳輸時，我們在目標節(jié)點根據(jù)源節(jié)點BAT結構通過BAT.new（）函數(shù)構造相同結構的BAT，在發(fā)送端PutBat（）函數(shù)調(diào)用時根據(jù)BAT的內(nèi)存結構直接復制列數(shù)據(jù)塊，如圖3所示，varchar類型的列需要復制BAT列和數(shù)據(jù)實際存儲內(nèi)存塊，以提高網(wǎng)絡傳輸效率，并在接收端克隆出與源BAT相同的目標BAT，完成BAT在節(jié)點間的復制.通過基于內(nèi)存塊的傳輸優(yōu)化技術，在千兆以太網(wǎng)中我們能夠獲得80 MB／s左右的傳輸速度，接近千兆以太網(wǎng)理論的傳輸速度.

圖3 基于BAT存儲結構的網(wǎng)絡傳輸Fig.3 BAT structure oriented BAT transmission

1.2.3 基于查詢負載特征的數(shù)據(jù)列關聯(lián)分布

ScaMMDB系統(tǒng)的協(xié)同計算模式能夠?qū)LAP查詢中選擇率低的操作下推到列存儲節(jié)點執(zhí)行，降低網(wǎng)絡數(shù)據(jù)傳輸代價，但在普通的千兆以太網(wǎng)環(huán)境下，網(wǎng)絡數(shù)據(jù)傳輸代價仍然占較高的比例.圖4列出了TPC－H中部分測試查詢在千兆以太網(wǎng)中的列傳輸代價占查詢總代價的比例，以及模擬10 Gbps和Tbps以太網(wǎng)的數(shù)據(jù)傳輸代價.我們可以看到，在未來的Tbps高速網(wǎng)絡傳輸技術的支持下，BAT傳輸延遲將低于0.5%，能夠更好地發(fā)揮ScaMMDB的可擴展查詢處理性能.

圖4 不同網(wǎng)絡性能下的網(wǎng)絡傳輸代價比例Fig.4 Network transmission cost ratio in different networks

除了依賴高速網(wǎng)絡技術的發(fā)展來降低虛擬內(nèi)存訪問延遲之外，我們進一步通過提高列分布的關聯(lián)性減少協(xié)同計算時的數(shù)據(jù)傳輸.我們采用屬性距離矩陣（Attribute Distance Matrix，ADM）來評估并量化分析出屬性之間相關性的強弱，優(yōu)先分布相關性高的屬性集合.系統(tǒng)數(shù)據(jù)分布策略分為三個階段：① 根據(jù)相對固定的OLAP查詢命令集和統(tǒng)計信息生成ADM；② 根據(jù)屬性相關性度量值進行屬性聚類，根據(jù)節(jié)點數(shù)量將相關性強的屬性集聚類為節(jié)點數(shù)量個相關屬性集合，確定高訪問頻率的屬性的分布策略；③ 根據(jù)第二階段的部分數(shù)據(jù)分布策略和節(jié)點內(nèi)存容量（內(nèi)存占用低于75%時性能較優(yōu)）調(diào)整其余屬性的分布策略，保證全部屬性分布在系統(tǒng)節(jié)點上并保證每個節(jié)點上的數(shù)據(jù)負載相對均衡.

在列存儲數(shù)據(jù)庫中，查詢處理的最小單位是屬性列，即任何查詢都最終被分解為一系列的列操作，關聯(lián)性體現(xiàn)在屬性列之間的協(xié)同訪問關系上，所以在列存儲數(shù)據(jù)庫中，關聯(lián)性定義為屬性與屬性之間是否存在關聯(lián)訪問關系，如在MAL命令“＿21｛rows＝4：lng｝：＝algebra.join（＿18，＿19）；”中，BAT ＿18、＿19對應的屬性存在關聯(lián)性.根據(jù) BAT 代數(shù)的特點，我們確定了屬性關聯(lián)性規(guī)則：① 出現(xiàn)在同一謂詞表達式中的屬性具有屬性關聯(lián)性；②GROUP BY、ORDER BY屬性為關聯(lián)性屬性；③ 代數(shù)表達式中的屬性為關聯(lián)性屬性；④ 邏輯運算符連接的所有屬性具有關聯(lián)性.通過屬性關聯(lián)性的定義，我們將MAL命令中BAT操作的多元操作數(shù)盡量集中在相同節(jié)點上，減少BAT操作時的網(wǎng)絡傳輸代價.我們通過關聯(lián)矩陣聚類算法將TPC－H的列聚類到n個節(jié)點上，并通過節(jié)點內(nèi)存容量進行調(diào)整，生成最優(yōu)數(shù)據(jù)分布策略.圖5（b）圖為不同數(shù)據(jù)分布策略在TPC－H查詢中所產(chǎn)生的網(wǎng)絡傳輸數(shù)據(jù)量，基于統(tǒng)計和聚類算法的分布策略能夠有效地降低查詢處理時的網(wǎng)絡傳輸代價.圖5（a）顯示了ScaMMDB集群計算模式相對于集中式計算模式的性能提升，內(nèi)存數(shù)據(jù)庫集群能夠有效地消除I／O代價，發(fā)揮出內(nèi)存計算的優(yōu)越性能.

ScaMMDB是一個可擴展的內(nèi)存數(shù)據(jù)庫系統(tǒng)，系統(tǒng)的各個節(jié)點可以同時接受用戶的查詢請求并在各個節(jié)點的協(xié)同下輸出最終的結果，系統(tǒng)吞吐量將大于單節(jié)點內(nèi)存數(shù)據(jù)庫系統(tǒng).

我們在2007—2008年期間開展內(nèi)存數(shù)據(jù)庫集群ScaMMDB的研究工作，當時還沒有內(nèi)存數(shù)據(jù)庫集群系統(tǒng)和產(chǎn)品，2012年，Vectorwise系統(tǒng)上進行了一些集群并行的研究工作［18］，但并沒有形成獨立的產(chǎn)品.我們在ScaMMDB性能測試時沒有可對比的內(nèi)存數(shù)據(jù)庫系統(tǒng)，因此我們采用了通過TPC－H測試基準中的吞吐量指標Throughput＠Size來衡量ScaMMDB的吞吐量的方法來測量ScaMMDB系統(tǒng)的加速比指標，在一個3節(jié)點的內(nèi)存數(shù)據(jù)庫集群中，ScaMMDB的吞吐量是單節(jié)點MonetDB的近3倍.

1.3 ScaMMDB的應用場景

圖5 數(shù)據(jù)傳輸性能和查詢性能［10］Fig.5 Network transmission and query processing performance［10］

ScaMMDB是一種以列存儲和列計算為中心的集群協(xié)同計算模型，它實現(xiàn)簡單，能夠在MonetDB底層API的基礎上通過擴展網(wǎng)絡傳輸與遠程計算調(diào)用API實現(xiàn)系統(tǒng)功能，能夠支持全部復雜的TPC－H查詢處理任務.在數(shù)據(jù)分布策略上，基于列的聚類分布策略相對于基于表的數(shù)據(jù)分布策略更加細粒度且操作性更強，結合數(shù)據(jù)挖掘的功能能夠自動對系統(tǒng)負載進行監(jiān)測并更好地實現(xiàn)負載均衡.

ScaMMDB不適用于訪問負載集中于少數(shù)列的應用場景，也不適合較大的集群規(guī)模.ScaMMDB的每個節(jié)點都能夠獨立地接受查詢請求，適合于并發(fā)查詢處理場景.ScaMMDB依賴于對MonetDB底層API的擴展，隨著MonetDB版本的升級和MAL命令集的不斷擴充，增加了ScaMMDB系統(tǒng)實現(xiàn)的成本.

2 基于水平分片的內(nèi)存數(shù)據(jù)倉庫集群系統(tǒng)ScaMMDBⅡ

TPC－H是一個用3NF實現(xiàn)的數(shù)據(jù)倉庫，是一個雙事實表雪花形結構，其中事實表lineitem和orders表構成訂單事實數(shù)據(jù)集，事實表lineitem和partsupp表構成訂單零件供應事實.這兩部分事實數(shù)據(jù)集占整個TPC－H數(shù)據(jù)量的95%以上（如SF＝100時，linteitem：68.24%；orders：14.74%；partsupp：12.28%，而其余5個維表數(shù)據(jù)量僅占4.74%），而這些巨大的事實表之間的連接操作代價成為影響TPC－H性能的關鍵因素，當采用集群處理模式時，跨節(jié)點的查詢處理任務產(chǎn)生巨大的網(wǎng)絡數(shù)據(jù)訪問延遲.

數(shù)據(jù)倉庫在存儲模式設計時需要考慮其查詢處理的類型和未來計算平臺上的性能問題，現(xiàn)實中數(shù)據(jù)倉庫通常采用星形或雪花形模型，使用一個巨大的事實表和多個較小的維表，消除龐大事實表之間的連接操作，簡化集群并行處理.圖6所示的SSB基準是對TPC－H基準面向OLAP的多維處理特性而進行的模式優(yōu)化，數(shù)據(jù)倉庫中只有一個事實表，在SF＝100時事實表數(shù)據(jù)量占整個數(shù)據(jù)庫98%以上，較小的維表使多維OLAP查詢優(yōu)化更加簡單，也適合大數(shù)據(jù)集群處理模式.圖6所示的HANA技術白皮書中示例的星形模型數(shù)據(jù)倉庫是一個高維結構，維表數(shù)量眾多但非常小，位于中心的事實表非常龐大，這種數(shù)據(jù)量極端傾斜的多／高維星形結構能夠采用多種優(yōu)化技術，并且能夠簡化集群分布模型和集群計算模型，提高大數(shù)據(jù)分析處理效率.

圖 6 星 形模型數(shù)據(jù) 倉庫［11－12］Fig.6 Star schema data warehouses［11－12］

ScaMMDBⅡ針對星形模型為特征的數(shù)據(jù)倉庫集群技術而設計，根據(jù)維表數(shù)據(jù)量極小和OLAP查詢結果集極小（在SSB中結果集為1－800行）的特征采用事實表水平分片，維表全復制的簡單數(shù)據(jù)分布策略，集群的任意節(jié)點可以充當動態(tài)的協(xié)調(diào)者（coordinator），將查詢?nèi)蝿辗峙山o各個工作節(jié)點并行執(zhí)行，并對各執(zhí)行節(jié)點返回的OLAP查詢結果集進行聚集歸并.

2.1 ScaMMDBⅡ系統(tǒng)結構

我們提出了基于sibling cube的可擴展內(nèi)存數(shù)據(jù)庫系統(tǒng)ScaMMDBⅡ（ParaCube），如圖7所示，數(shù)據(jù)倉庫的完整數(shù)據(jù)集被劃分為多個數(shù)據(jù)倉庫子集，其中事實表被劃分為不相交的n個數(shù)據(jù)子集分布在n個MMDB節(jié)點上，維表在n個數(shù)據(jù)節(jié)點上被全復制，每個節(jié)點上運行一個middle ware（ParaCube mediator）作為OLAP客戶端軟件，各個數(shù)據(jù)庫節(jié)點中數(shù)據(jù)是同構的但各節(jié)點上的數(shù)據(jù)庫可以是異構的，可以根據(jù)應用的需要選擇不同的數(shù)據(jù)庫，對節(jié)點上的數(shù)據(jù)訪問通過標準的數(shù)據(jù)庫訪問接口JDBC來實現(xiàn)，屏蔽系統(tǒng)之間的差異，在ParaCube mediator上需要記錄每個數(shù)據(jù)節(jié)點的元數(shù)據(jù).ParaCube mediator的功能是接受用戶的查詢請求，根據(jù)查詢內(nèi)容完成查詢重寫，通過JDBC將查詢?nèi)蝿障峦撇⒎祷夭樵兲幚斫Y果子集，然后通過多路歸并算法將聚集結果子集歸并為最終的查詢結果.系統(tǒng)中可以有唯一的ParaCube mediator也可以維護多個ParaCube mediator來提高系統(tǒng)的并發(fā)查詢處理能力.

圖7 基于ParaCube mediator的ScaMMDBⅡ系統(tǒng)Fig.7 ParaCube mediator oriented ScaMMDBⅡsystem

2.2 ScaMMDBⅡ關鍵技術

ScaMMDBⅡ是以數(shù)據(jù)為中心的并行OLAP查詢處理模型，根據(jù)OLAP查詢處理中數(shù)據(jù)量大、數(shù)據(jù)粒度大、查詢復雜度高、查詢目標為聚集結果、高輸入低輸出的特點，優(yōu)化傳統(tǒng)的并行查詢處理技術，提高并行查詢處理過程中的并行性，優(yōu)化OLAP性能.ScaMMDBⅡ是一種開放的結構，支持異構數(shù)據(jù)庫的集成，因此系統(tǒng)能夠根據(jù)應用中數(shù)據(jù)量和查詢負載的變化動態(tài)擴展系統(tǒng)處理規(guī)模，同時也支持不同類型系統(tǒng)的集成，支持將事務型數(shù)據(jù)庫與分析型數(shù)據(jù)庫從邏輯上組織為統(tǒng)一的系統(tǒng)，支持操作型BI（Operational Business Intelligence）的應用需求.

2.2.1 數(shù)據(jù)分布策略

如圖8所示，在SF＝100的TPC－H中5個維表數(shù)據(jù)量低于5%，SSB中4個維表數(shù)據(jù)量僅占1%左右，當集群規(guī)模較小時，維表全復制策略能夠最大化本地計算，最小化網(wǎng)絡數(shù)據(jù)傳輸代價，維表全復制所帶來的存儲空間開銷能夠控制在可接受的范圍之內(nèi)，維表全復制策略或者維表廣播策略是面向數(shù)據(jù)倉庫模式特征而廣泛采用的簡單有效的數(shù)據(jù)分布技術.從數(shù)據(jù)量分布特征我們也可以看到，將TPC－H滿足3NF的模式設計轉(zhuǎn)換為星形模式設計能夠使其更加適合集群并行計算，簡化并行計算模型.

圖8 TPC－H和SSB測試集事實表、維表數(shù)據(jù)分布Fig.8 Data distribution of fact tables and dimension tables in TPC－H and SSB

2.2.2 并行聚集計算技術

OLAP計算的特征是聚集計算，即將連接后的記錄按維層次分組后計算出聚集值.聚集計算是一個數(shù)據(jù)收斂的過程，在人機交互的ad－h(huán)oc OLAP應用中，用戶通常以低勢集的多維數(shù)據(jù)集為目標，因此，當聚集計算可以在集群節(jié)點間并行處理時，每個節(jié)點只產(chǎn)生非常小的聚集結果集，網(wǎng)絡傳輸代價能夠被極大地降低.

對于滿足結合律的可分布式聚集函數(shù)（SUM、COUNT、MAX、MIN、FIRST、LAST等），以SUM為例，即若A＝A1∪A2∪…An并且φ＝A1∩A2∩…An則有SUM （A）＝SUM（SUM （A1），SUM （A2），…，SUM （An））.將數(shù)據(jù)集劃分為多個不相交的數(shù)據(jù)子集后，使用聚集函數(shù)的OLAP查詢可以直接下推到數(shù)據(jù)子集上獨立執(zhí)行，最后將查詢結果子集合并.對于代數(shù)可分布聚集函數(shù)，如AVERAGE可以通過SUM和COUNT聚集結果計算得出，方差函數(shù)可通過如下公式轉(zhuǎn)換為SUM（A）、SUM（A2）、COUNT（A）三個聚集函數(shù)的代數(shù)表達式計算得出.

對于不可分布式聚集函數(shù)，如MEDIAN、PERCENTILE等則需要將集群中的數(shù)據(jù)傳輸?shù)揭粋€節(jié)點上集中處理，增加了網(wǎng)絡傳輸代價.我們在文獻［13］中提出了一種迭代式中值計算技術，如圖9所示.通過在集群節(jié)點本地排序數(shù)據(jù)集上求出各自的中值，然后通過網(wǎng)絡匯集各節(jié)點邊界值并根據(jù)最小邊界值在各節(jié)點上對排序數(shù)據(jù)集進行剪枝，逐漸縮減中值候選窗口，最后只對較小候選窗口中的數(shù)據(jù)進行集中式的中值處理以得到全局中值結果.實驗結果表明，由于事實表數(shù)據(jù)的分布具有數(shù)據(jù)隨機性，而且group－by屬性隨著查詢而動態(tài)變化，因此排序記錄子集一般分布較為均勻，迭代剪裁能夠有效縮減并行中值計算的網(wǎng)絡傳輸代價.

2.2.3 面向Operational BI需求的ScaMMDBⅡ模型

現(xiàn)代大型企業(yè)每天產(chǎn)生大量的事務數(shù)據(jù)，用戶的決策支持越來越多地依賴于對及時性數(shù)據(jù)的分析結果，需要數(shù)據(jù)倉庫支持更短的更新周期.我們提出在事務型系統(tǒng)和分析型數(shù)據(jù)倉庫系統(tǒng)之間建立一個中等規(guī)模的分析型數(shù)據(jù)緩存層，提供高性能的ad－h(huán)oc查詢處理能力.為保證查詢處理的性能，采用MMDB查詢處理引擎的ScaMMDBⅡ（ParaCube）來實現(xiàn)高性能OLAP查詢處理.如圖10所示，全部的數(shù)據(jù)被分為三個層次：Fresh data表示前端OLTP數(shù)據(jù)，數(shù)據(jù)量較小，支持數(shù)據(jù)的更新操作，采用OLTP引擎，OLAP查詢處理性能的保證是較小的數(shù)據(jù)集；Buffer data是OLTP和OLAP系統(tǒng)之間的緩存數(shù)據(jù)，它接受來自OLTP系統(tǒng)的較短時間間隔的更新操作，一般是批量的追加和數(shù)據(jù)遷移，緩存數(shù)據(jù)量的大小取決于數(shù)據(jù)倉庫的更新策略和物化cube的更新代價.一般來說，從OLTP系統(tǒng)向緩存數(shù)據(jù)層的更新以天為單位，從緩存數(shù)據(jù)層向數(shù)據(jù)倉庫的更新以月或年為單位.在數(shù)據(jù)分析時，最近的數(shù)據(jù)往往具有更高的分析權重，因此OLTP系統(tǒng)和數(shù)據(jù)緩存層的查詢負載相對較高，數(shù)據(jù)緩存層的數(shù)據(jù)量動態(tài)變化，因此需要ScaMMDBⅡ的可擴展性提供支持.對于可分布聚集計算函數(shù)來說，將OLAP查詢?nèi)蝿障峦频絆LTP系統(tǒng)、Buffer data（ParaCube）和數(shù)據(jù)倉庫層，各個層次獨立完成在其數(shù)據(jù)集上的OLAP查詢處理任務，生成查詢處理結果子集并由系統(tǒng)進行查詢結果子集歸并，產(chǎn)生最終的查詢結果.通過可分布聚集計算OLAP的并行處理，能夠構建一個異構的OLAP系統(tǒng)，并且將OLTP系統(tǒng)與OLAP系統(tǒng)從邏輯上組織為統(tǒng)一的系統(tǒng)，提高分析數(shù)據(jù)的及時性，增加分析結果的操作性，提高系統(tǒng)分析任務的有效性.

圖9 迭代式中值計算Fig.9 Iterative Median computing

圖10 Operational BI三層模型Fig.10 3－level operational BI model

相對于Vertica的WOS和ROS機制以及SAP的OLTP＆OLAP技術，我們采用的是一種異構數(shù)據(jù)庫平臺上的邏輯集成技術，降低系統(tǒng)的復雜性.我們同時提出異步更新通道模型以實現(xiàn)將OLTP系統(tǒng)中的數(shù)據(jù)在后臺以異步方式增量更新到內(nèi)存OLAP數(shù)據(jù)庫集群，減少集群節(jié)點間的數(shù)據(jù)更新代價.

2.3 ScaMMDBⅡ的應用場景

ScaMMDB采用基于列的數(shù)據(jù)分布策略，面向只讀型的數(shù)據(jù)倉庫應用.ScaMMDBⅡ采用的維表全復制機制和事實表異步更新通道機制支持insert－only更新類型的數(shù)據(jù)倉庫應用，維表的存儲和更新的代價較大.

基于水平分片的并行OLAP機制對于基礎的SPJGA（S：選擇，P：投影，J：連接，G：分組，A：聚集）操作只需要簡單的查詢重寫和查詢結果歸并處理，非常適合SSB數(shù)據(jù)集上的OLAP應用.對于帶有復雜子查詢的TPC－H查詢則需要將查詢轉(zhuǎn)換為SPJGA查詢樹才能實現(xiàn)并行處理，系統(tǒng)實現(xiàn)復雜度較高.

3 基于向量技術的內(nèi)存數(shù)據(jù)倉庫集群系統(tǒng)MiNT－OLAPCluster

ScaMMDB采用與Oracle RAC的Cache Fusion技術類似的NetMemory擴展內(nèi)存數(shù)據(jù)倉庫的內(nèi)存容量以支持大數(shù)據(jù)內(nèi)存計算.ScaMMDBⅡ采用與HadoopDB類似的集群并行計算技術構建基于SQL的異構內(nèi)存數(shù)據(jù)倉庫集群.系統(tǒng)實現(xiàn)技術以MonetDB為基礎，雖然能夠利用MonetDB優(yōu)秀的性能和豐富的API支持，但受MonetDB系統(tǒng)設計的限制，難以對內(nèi)存數(shù)據(jù)倉庫集群進行更加深入的優(yōu)化.

當前數(shù)據(jù)倉庫技術的發(fā)展趨勢是及時性（just－in－time）分析處理需求越來越高，甚至將前端業(yè)務系統(tǒng)與后端分析系統(tǒng)相結合，將OLTP與OLAP系統(tǒng)融合在一起，代表性技術包括SAP HANA、ScyPer［14］等系統(tǒng).因此，在內(nèi)存數(shù)據(jù)倉庫集群的設計中需要將數(shù)據(jù)更新代價作為一個重要的設計因素.MiNT－OLAPCluster系統(tǒng)根據(jù)數(shù)據(jù)倉庫模型和負載特征采用反星形（reverse－star schema）模式存儲策略，即將較小的維表集中存儲，消除冗余副本的存儲代價和網(wǎng)絡更新代價，事實表則采用水平分片存儲于集群節(jié)點，形成以維表為中心，事實表分片為分支的星形分布式存儲.在OLAP查詢處理中我們采用基于位圖或向量的星形過濾技術，在維表上生成較小的向量數(shù)據(jù)結構并廣播到各工作節(jié)點，在事實表分片上完成本地化SPJGA計算，并將各工作節(jié)點的OLAP結果集在中心節(jié)點進行全局聚集歸并，生成最終的查詢處理結果.

3.1 MiNT－OLAPCluster系統(tǒng)結構和關鍵技術

與ScaMMDB、ScaMMDBⅡ采用 MonetDB查詢處理引擎不同，MiNT－OLAPCluster系統(tǒng)的OLAP查詢處理以我們自己設計的DDTA－JOIN算法為核心，通過向量計算模型簡化OLAP查詢處理過程，將OLAP查詢處理中維表與事實表之間的數(shù)據(jù)傳輸最小化為位圖或向量，從而最小化集群計算時的網(wǎng)絡傳輸代價.

圖11顯示了DDTA－JOIN（Directly Dimensional Tuple Accessing，DDTA）算法對于典型SPJGA模式的OLAP查詢處理過程.首先SQL命令中維表上的過濾操作按維表進行劃分，在維表上過濾后生成與維表等長的過濾位圖；通過事實表外鍵與維表主鍵之間的地址映射（address mapping）在事實表掃描時將維表外鍵映射到維表過濾位圖進行過濾操作，滿足星形過濾（star－filtering）的記錄通過外鍵映射到維表分組屬性列中抽取分組屬性，與事實表度量屬性組合為輸出記錄進行哈希分組聚集計算.

Oracle Exadata X3采用的SmartScan技術通過where謂詞篩選和JOIN聯(lián)接篩選在存儲服務器節(jié)點上過濾掉大部分不符合查詢條件的記錄，只將少量記錄返回給數(shù)據(jù)庫服務器完成查詢處理.類似的Bloom filter過濾技術也大量被數(shù)據(jù)庫系統(tǒng)所采用，通過增加額外的連接過濾處理消減連接操作的記錄數(shù)量，從而降低連接計算代價.數(shù)據(jù)倉庫的星形模型中維表較小且增長緩慢，以SSB數(shù)據(jù)集為例，即使SF＝1 000時，4個維表過濾位圖總大小為4.08 MB，過濾位圖的存儲和網(wǎng)絡廣播代價極小.對于低選擇率的維表過濾操作，位圖還可以進一步通過壓縮技術減少位圖存儲和網(wǎng)絡廣播代價.

圖11 DDTA－JOIN 算法示例［15］Fig.11 Example of DDTA－JOIN algorithm［15］

當OLAP查詢的選擇率較高時（如SSB中選擇率最高為3.4%），SmartScan技術仍然需要傳輸大量的數(shù)據(jù)到數(shù)據(jù)庫節(jié)點進行查詢處理，而這些數(shù)據(jù)本地分組聚集后的結果集非常小，因此在OLAP集群計算時，將分組聚集計算下推到存儲節(jié)點能夠極大地提高集群并行計算性能.如圖12所示，我們進一步將SQL中維表上的謂詞和分組操作整合，即根據(jù)維表謂詞條件投影出維表分組屬性組（可以是單一分組屬性，也可以是維表上多個分組屬性的組合值）并對其進行編碼，然后生成基于分組屬性編碼的維表過濾分組向量（predicate vector），雖然相對于維表過濾位圖，維表過濾分組向量增加了向量寬度，但由于能夠通過維表過濾分組向量在事實表分片節(jié)點完成完整的SPJGA操作，只需要返回非常小的分組聚集結果集，能夠進一步降低集群OLAP并行處理時的網(wǎng)絡傳輸代價.

圖12 謂詞向量Fig.12 Predicate vector

基于DDTA－JOIN算法的MiNT－OLAPCluster系統(tǒng)結構如圖13所示，整個內(nèi)存數(shù)據(jù)倉庫集群由一個中心節(jié)點和若干個處理節(jié)點組成，維表集存儲于中心節(jié)點，支持維表上的實時更新操作，事實表水平分片均衡分布于各工作節(jié)點以保證負載均衡，事實表是歷史數(shù)據(jù)，其特征決定了主要支持insert－only類型的更新操作.在星形模型數(shù)據(jù)倉庫中，事實表分片以數(shù)據(jù)量為主要考慮因素，簡化數(shù)據(jù)分布模型.

圖13 MiNT－OLAPCluster系統(tǒng)結構［16］Fig.13 Architecture of MiNT－OLAPCluster［16］

MiNT－OLAPCluster的集群OLAP處理分為三種不同的方式.

（1）star－filtering only.中心節(jié)點僅將維表過濾位圖廣播到工作節(jié)點，工作節(jié)點完成事實表謂詞過濾和維表連接過濾后將篩選的事實表記錄傳輸給中心節(jié)點完成OLAP查詢處理.此種處理方式類似于SmartScan技術，但采用維表位圖過濾能夠準確地過濾出所有滿足條件的記錄，不存在bloom filter過濾的誤判斷問題.當OLAP查詢的選擇率很低且查詢處理任務難以并行處理（如不可分布的聚集計算或復雜子查詢處理）時，各工作節(jié)點提供分布式的記錄篩選功能，中心節(jié)點負責集中式的復雜查詢處理任務.

（2）位圖廣播和分組屬性緩存.當維表上的分組屬性更新率較低時，我們可以將查詢中常用的維表分組屬性列緩存于工作節(jié)點內(nèi)存，OLAP查詢處理時只廣播維表過濾位圖，在工作節(jié)點與維表分組屬性列共同完成本地化的分組聚集計算.當中心節(jié)點的維表分組屬性列更新時，工作節(jié)點上緩存的分組屬性列需要重新加載或更新.

（3）維表過濾分組向量廣播.查詢處理時在中心節(jié)點實時生成維表過濾分組向量，并廣播到各工作節(jié)點完成分布式的分組聚集計算.維表過濾分組向量廣播的網(wǎng)絡傳輸代價有所提高，但由于維表行數(shù)較少，其網(wǎng)絡傳輸代價有限，而且這種機制能夠支持維表上的實時更新.

DDTA－JOIN算法將維表上的查詢處理與事實表上的計算劃分為獨立的兩個階段，OLAP查詢在中心節(jié)點上的處理過程和工作節(jié)點上的分組聚集計算可以流水并行，即當查詢Q1在中心節(jié)點生成維表過濾分組向量并廣播給工作節(jié)點進行集群并行處理時，中心節(jié)點可以繼續(xù)執(zhí)行查詢Q2在維表上的處理任務.由于維表較小且生成維表過濾分組向量的操作比較簡單，我們可以在工作節(jié)點進行OLAP查詢處理時創(chuàng)建查詢組Q的維表過濾分組向量組，在下一個工作節(jié)點OLAP查詢處理時執(zhí)行查詢組Q上的并發(fā)查詢處理任務，進一步提高查詢吞吐性能.

進一步地，我們將內(nèi)存數(shù)據(jù)倉庫集群技術擴展到Hadoop平臺，如圖14所示.我們在Hadoop多復本機制的基礎上將一個副本升級為內(nèi)存列存儲副本，支持內(nèi)存副本上的集群并行內(nèi)存OLAP查詢處理，其余復本作為容錯副本，將內(nèi)存OLAP集群技術與Hadoop集群技術相結合，發(fā)揮內(nèi)存OLAP集群的高性能和Hadoop集群的高可擴展性和高可靠性.

圖14 基于Hadoop平臺的內(nèi)存OLAP集群［17］Fig.14 In－memory OLAP cluster on Hadoop［17］

3.2 MiNT－OLAPCluster性能驗證

我們在核高基重大專項“大型通用數(shù)據(jù)庫管理系統(tǒng)與套件研發(fā)及產(chǎn)業(yè)化”的子課題“國產(chǎn)數(shù)據(jù)庫高性能高安全關鍵技術研究（2010ZX01042－001－002－002）”中采用 MiNT－OLAPCluster技術實現(xiàn)內(nèi)存數(shù)據(jù)倉庫集群系統(tǒng).我們在集群測試中使用14個節(jié)點（每節(jié)點2個6核處理器，48GB內(nèi)存，SSB測試集在SF＝100時內(nèi)存占用45.8GB），一個節(jié)點作為主節(jié)點，用于查詢解析、任務調(diào)度和查詢結果歸并，13個工作節(jié)點用于并行查詢處理.整個集群測試數(shù)據(jù)集大小SF＝100×13，事實表分片均勻分布到13個工作節(jié)點上.由于我們沒有SF＝1 300的內(nèi)存做集中式的內(nèi)存OLAP性能基準測試，因此采用通過單個數(shù)據(jù)分片查詢處理時間×節(jié)點數(shù)來近似獲得（由DDTA－JOIN算法的線性特征決定），集群并行查詢處理時間為系統(tǒng)實際執(zhí)行測試時間，集群的并行處理加速比SR≈13×單分片執(zhí)行時間／集群并行執(zhí)行時間，實驗中平均并行加速比為12.64.見圖15所示.

圖15 內(nèi)存數(shù)據(jù)倉庫系統(tǒng)集群并行性能Fig.15 In－memory Data Warehouse cluster parallel performance

3.3 MiNT－OLAPCluster的應用場景

我們當前的研究工作以圖6所示的星形模型為目標，以基礎的SPJGA操作符的集群并行處理技術為對象，提供一個內(nèi)存數(shù)據(jù)倉庫的基礎平臺，在此基礎上可以構建以SPJGA操作符樹為基礎的更加復雜的查詢處理任務.也就是說，我們的實現(xiàn)技術能夠完全解決SSB測試基準類型的OLAP負載，也可以作為內(nèi)存數(shù)據(jù)倉庫集群的SPJGA操作API提供給更加復雜的OLAP查詢處理任務調(diào)用.

多事實表的TPC－H數(shù)據(jù)集也可以采用 MiNT－OLAPCluster的實現(xiàn)技術.事實表lineitem與orders表存在主外鍵參照完整性引用約束關系，而且lineitem表的orderkey與orders表的orderkey存在偏序關系，我們可以采用orders（orderkey）→lineitem（orderkey）的分片策略將lineitem表和orders表按orderkey劃分為不相交的數(shù)據(jù)分片存儲于不同的集群節(jié)點上.Partsupp事實表在集群上獨立進行水平分片，TPC－H查詢中Q2、Q11、Q16、Q20查詢中，part表、supplier表和partsupp事實表之間的星形OLAP操作遵循MiNTOLAPCluster實現(xiàn)技術.TPC－H查詢中包含lineitem？orders？partsupp操作的查詢Q9中，partsupp表上的查詢子集在經(jīng)過集群并行生成后需要廣播到各工作節(jié)點參與連接操作.因此，TPC－H數(shù)據(jù)集在事實表協(xié)同分片策略下也可以使用MiNT－OLAPCluster實現(xiàn)技術，但相對于SSB標準的SPJGA查詢，TPC－H需要將更為復雜的查詢轉(zhuǎn)換為SPJGA查詢樹并對MiNT－OLAPCluster的集群SPJGA操作API進行調(diào)用.表1對三種內(nèi)存數(shù)據(jù)倉庫集群技術進行了綜合對比.

表1 內(nèi)存數(shù)據(jù)倉庫集群技術對比Tab.1 Comparison for different in－memory data warehouse cluster technologies

4 結 論

本文概括地描述了我們在內(nèi)存數(shù)據(jù)倉庫集群研究上的技術路線，不同原型系統(tǒng)所面對的問題及解決方案.在三個原型系統(tǒng)的研究過程中，我們最大的感受是需要建立自己的內(nèi)存OLAP查詢執(zhí)行框架，并使之平臺化，掌握自己的關鍵技術，提高對系統(tǒng)實現(xiàn)的掌控能力.

本文給出了當前大內(nèi)存發(fā)展趨勢下內(nèi)存數(shù)據(jù)倉庫集群實現(xiàn)技術的框架結構.與具有高可擴展性的key／value存儲類似，當采用極大事實表、多個極小維表的星形或雪花形模型時，數(shù)據(jù)倉庫具有良好的可擴展性.在事實表－維表地址映射技術和向量計算技術的支持下，多維／高維OLAP查詢處理具有較高的效率，通過對OLAP查詢命令在維表和事實表上的分而治之處理技術，數(shù)據(jù)倉庫能夠較好地支持OLTP任務，實現(xiàn)實時分析處理.

隨著CPU和內(nèi)存技術的發(fā)展，大數(shù)據(jù)內(nèi)存實時分析相對于傳統(tǒng)的數(shù)據(jù)倉庫技術具有更高的性能和性價比，隨著實時分析性能的提升，OLAP的應用將逐漸從少數(shù)決策管理用戶層擴展到大量業(yè)務處理的普通用戶層，因此實時OLAP查詢響應性能和高并發(fā)查詢吞吐性能將成為未來內(nèi)存數(shù)據(jù)倉庫重要的性能指標，需要結合多核／眾核并行處理技術及新的存儲硬件技術方面的最新成果不斷提高大數(shù)據(jù)實時OLAP分析處理性能.數(shù)據(jù)倉庫也將逐漸從只讀型分析處理向OLTP＆OLAP相結合的需求發(fā)展，需要提高OLTP負載與OLAP負載并發(fā)時的綜合性能.大數(shù)據(jù)處理對集群技術的需求需要重新考慮和設計面向集群處理特征的數(shù)據(jù)倉庫模式設計，高密度事實表（事實表數(shù)據(jù)量占比高）和高維模式設計將簡化集群并行計算模型并且提高數(shù)據(jù)倉庫的擴展性能.基于SPJGA操作符的OLAP查詢樹優(yōu)化技術能夠?qū)⒏呤諗啃缘木奂嬎阆峦频綌?shù)據(jù)存儲節(jié)點，相對于傳統(tǒng)的基于關系操作符的查詢樹優(yōu)化技術能夠更好地適應數(shù)據(jù)倉庫集群計算.

［1］ Gartner Identifies the Top 10 Strategic Technology Trends for 2013［EB／OL］.（2012－10－23）［2013－04－12］.http：／／www.gartner.com／newsroom／id／2209615.

［2］ BONCZ P A，KERSTEN M L，MANEGOLD S.Breaking the memory wall in MonetDB.Commun［J］.ACM51，2008（12）：77－85.

［3］ ZUKOWSKI M，BONCA P A.Vectorwise：Beyond Column Stores［J］.IEEE Data Eng Bull，2012，35（1）：21－27.

［4］ SIKKA V，F(xiàn)?RBER F，LEHNER W，et al.Efficient transaction processing in SAP HANA database：the end of a column store myth［C］／／SIGMOD Conference.2012：731－742.

［5］ IBM Informix Warehouse Accelerator－Performance is everything http：／／public.dhe.ibm.com／common／ssi／ecm／en／imw14587usen／IMW14587USEN.PDF.

［6］ Overview of ExaData.http：／／www.oracle.com／us／products／database／exadata／overview／index.html.

［7］ DIACONU C，F(xiàn)REEDMAN C，ISMERT E，et al.Hekaton：SQL server＇s memory－optimized OLTP engine［C］／／SIGMOD，2013：1243－1254.

［8］ ELLIOTT T.Why In－Memory Computing Is Cheaper And Changes Everything［EB／OL］.（2013－04－17）［2014－06－18］.http：／／timoelliott.com／blog／2013／04／why－in－memory－computing－is－cheaper－and－changes－everything.html.

［9］ 張延松.大規(guī)?？蓴U展數(shù)據(jù)分析技術研究［D］.北京：中國人民大學信息學院，2010.

［10］ 黃云奎.可擴展內(nèi)存數(shù)據(jù)庫ScaMMDB數(shù)據(jù)分布策略研究［D］.北京：中國人民大學信息學院，2009.

［11］ RABL T，POESS M，JACOBSEN H A，et al.Variations of the star schema benchmark to test the effects of data skew on query performance［C］／／ICPE，2013：361－372.

［12］ HANA S.Performance Efficient Speed and Scale－Out for Real－Time Business Intelligence［EB／OL］.（2012－4－28）［2013－04－12］http：／／www.saphana.com／docs／DOC－1647.

［13］ ZHANG Y，WANG S，HUANG W.ParaCube：a scalable OLAP model based on distributed aggregate computing with Sibling Cubes［C］／／APWEB，2010：323－329.

［14］ MüHLBAUER T，R?DIGER W，REISER A，et al.ScyPer：A Hybrid OLTP＆OLAP Distributed Main Memory Database System for Scalable Real－Time Analytics［C］／／BTW，Magdeburg，Germany，2013.

［15］ 張延松，焦敏，王占偉，等.海量數(shù)據(jù)分析的 One－size－fits－all OLAP技術［J］.計算機學報，2011（10）：1936－1947.

［16］ JIAO M，ZHANG Y S，WANG Z W，et al.MiNT－OLAP cluster：minimizing network transmission cost in OLAP cluster for main memory analytical database［J］.Frontiers of Computer Science，2012，6（6）：668－676.

［l7］ 張延松，王珊.面向數(shù)據(jù)庫與 Hadoop混合平臺的OLAP查詢處理方法：中國，201210114112.0.2［P］.2013－11－20.

［l8］ Costea A，Ionescu A.Query Optimization and Execution in Vectorwise MPP［D］.Amsterdam：Vrije Universiteit Amsterdam（＠VectorWise），2012.