杜小勇，陳躍國，覃雄派

中國人民大學信息學院數(shù)據(jù)工程與知識工程教育部重點實驗室 北京 100872

大數(shù)據(jù)與OLAP系統(tǒng)

杜小勇，陳躍國，覃雄派

中國人民大學信息學院數(shù)據(jù)工程與知識工程教育部重點實驗室 北京 100872

OLAP（online analytical processing，在線聯(lián)機分析處理）是關系數(shù)據(jù)基礎上實現(xiàn)商業(yè)智能的核心技術。在大數(shù)據(jù)時代，人們迫切希望在由普通機器組成的大規(guī)模集群上能實現(xiàn)高性能的OLAP，然而系統(tǒng)性能的挑戰(zhàn)巨大?？上驳氖?，近年來進展迅速，涌現(xiàn)了很多以Hadoop上的數(shù)據(jù)進行OLAP的所謂SQL on Hadoop系統(tǒng)，并且系統(tǒng)性能不斷提升。在綜述OLAP技術發(fā)展的基礎上，重點對幾個有代表性的SQL on Hadoop系統(tǒng)進行了測試分析，并展示了這類系統(tǒng)的性能特點?？梢灶A見，未來在低成本的大數(shù)據(jù)OLAP市場，這類系統(tǒng)會占有重要位置。

大數(shù)據(jù)；OLAP；SQL分析；SQL on Hadoop

1 OLAP的前世今生

數(shù)據(jù)分析一般指為了從數(shù)據(jù)中獲得有價值的信息，而采用的諸如數(shù)據(jù)清理、建模、查詢、統(tǒng)計、挖掘、展示等操作過程，其產(chǎn)生的結果往往用于決策支持，是傳統(tǒng)商業(yè)智能所依賴的重要技術。數(shù)據(jù)分析的類型多種多樣，根據(jù)被分析的數(shù)據(jù)類型和所采用的核心分析方法，常見的數(shù)據(jù)分析有流式分析、SQL分析、深度分析等，復雜度依次遞增。流式分析主要是對數(shù)據(jù)流（動態(tài)連續(xù)產(chǎn)生的數(shù)據(jù)序列）在一定時間窗口內進行簡單的統(tǒng)計分析或者實時監(jiān)控，處理速度快，面向快速洞察新數(shù)據(jù)的實時應用；SQL分析是以SQL語句形式對關系模型下的數(shù)據(jù)進行的查詢分析，習慣被稱作OLAP（online analytical processing，在線聯(lián)機分析處理），通常是在關系查詢基礎上進行的一些統(tǒng)計分析操作；深度分析則采用了復雜度較高的數(shù)據(jù)挖掘和機器學習中的方法，可以處理結構化或非結構化數(shù)據(jù)，通常采用多輪迭代的計算模型，計算代價更高。除此之外，還有更為復雜的分析，光靠機器很難得到令人滿意的數(shù)據(jù)分析結果，往往需要人的參與，形成了人機結合的數(shù)據(jù)分析方法，如眾包技術。

數(shù)據(jù)分析為決策服務，其性能（一個分析任務的平均執(zhí)行時間）對很多應用來說非常重要。一般來講，5 s以內（有些應用可以增加到10 s左右）執(zhí)行完的分析常被稱作實時分析，一兩分鐘以內執(zhí)行完的分析任務則可以稱作交互性分析，半小時以上完成的分析常被稱作離線分析，而介于交互性分析和批處理之間的分析任務，可以稱作非交互性數(shù)據(jù)分析。流式分析一般要求具備實時分析的性能，OLAP則希望具備交互性分析的性能，深度分析在數(shù)據(jù)量大、任務復雜的情況下往往是離線分析任務。

本文重點圍繞OLAP，探討大數(shù)據(jù)對于OLAP系統(tǒng)的深刻影響。截至目前，它還是商業(yè)數(shù)據(jù)分析（數(shù)據(jù)倉庫技術）所依賴的最為重要也最為核心的數(shù)據(jù)分析技術。

使用SQL技術對數(shù)據(jù)進行分析在數(shù)據(jù)庫發(fā)展的早期階段就被人們研究，但OLAP這個詞最早是關系數(shù)據(jù)庫之父Edgar F Codd在1993年給出的[1]，作為與面向聯(lián)機事務處理負載所不同的另一類重要的數(shù)據(jù)庫負載。這個概念主要針對多維數(shù)據(jù)分析（MDA）領域，是商業(yè)智能的核心部分。20世紀90年代，人們在以OLAP為主的數(shù)據(jù)倉庫技術方面做了很多研究，為了提升OLAP的處理性能，最為常見的方法就是基于多維數(shù)據(jù)構建Cube模型，通過大量的預聚集計算，實現(xiàn)生成支持多維分析的Cube，并在此基礎上支持以下鉆、上卷、切片、切塊、旋轉等操作為代表的高性能的OLAP[2]。這種OLAP處理方法也被稱作MOLAP，是最為典型的OLAP處理方法。其優(yōu)點就是通過數(shù)據(jù)的深加工（預聚集計算、索引、壓縮、緩存等），換取高的OLAP性能；缺點是數(shù)據(jù)預處理環(huán)節(jié)多，處理周期長，數(shù)據(jù)維度不宜過高，數(shù)據(jù)冗余多，適合處理幾十GB規(guī)模的數(shù)據(jù)。

OLAP的另一類技術是ROLAP，不做Cube計算，直接使用關系數(shù)據(jù)庫，采用基于事實表和維表的星型模型或者更為復雜的雪花型模型，組織數(shù)據(jù)。在ROLAP過程中，能夠將Cube上的各種操作轉換為數(shù)據(jù)庫上SQL查詢分析語句執(zhí)行。ROLAP的優(yōu)缺點與MOLAP的優(yōu)缺點幾乎是相反的，性能上沒有MOLAP快，但因為沒有數(shù)據(jù)模型轉換和深加工過程，數(shù)據(jù)導入快，而且其擴展性更好（支持分庫、分表等數(shù)據(jù)庫集群技術），查詢也不受Cube模型的限制，廣泛支持各類數(shù)據(jù)庫上的SQL查詢。當然，也有人將MOLAP與ROLAP融合到一起，形成一種兼具數(shù)據(jù)庫和Cube模型的HOLAP解決方案，以更好地發(fā)揮二者的優(yōu)點，避免二者的缺陷。

進入新世紀后，ROLAP技術隨著MPP并行數(shù)據(jù)庫技術的發(fā)展，尤其是在Stonebraker1Michael Stonebraker由于對現(xiàn)代數(shù)據(jù)庫系統(tǒng)底層的概念與實踐所做出的基礎性貢獻，獲得了2014年度ACM圖靈獎等數(shù)據(jù)庫專家所倡導的列存儲技術的支持下[3]，面向OLAP應用的MPP數(shù)據(jù)庫集群技術得到了迅速發(fā)展，出現(xiàn)了以HP Vertica為代表的列存儲并行數(shù)據(jù)庫。列存儲數(shù)據(jù)庫技術針對數(shù)據(jù)分析的特點，能夠對數(shù)據(jù)進行高性能的壓縮，查詢也只需訪問必要的列，節(jié)省了很多I/O，分析性能比傳統(tǒng)行存儲數(shù)據(jù)庫有了很大的提升（可以多達兩個數(shù)據(jù)量級）。正如Stonebraker所說，列存儲數(shù)據(jù)庫已經(jīng)開始成為OLAP的主角，并會在未來一段時間長期保持作為OLAP的主流技術。同時，隨著內存成本的降低、單機內存的增大，以SAP HANA為代表的內存數(shù)據(jù)庫[4]也采用了列存儲技術，支持更高性能的數(shù)據(jù)分析。這些技術的發(fā)展，使得它們成為TB級別數(shù)據(jù)倉庫進行OLAP數(shù)據(jù)分析的最先進技術，已經(jīng)涵蓋了絕大多數(shù)OLAP市場。

然而，市場的發(fā)展并不總以技術論成敗，系統(tǒng)的建造成本和開放性也是重要因素。在建造成本方面，MPP并行數(shù)據(jù)庫和內存數(shù)據(jù)庫依賴昂貴的硬件配置，其中的很多商業(yè)軟件還有價格高昂的使用許可證，這些成本并不是每個公司都能夠承擔或者愿意承擔的；而開源大數(shù)據(jù)系統(tǒng)采用通用、廉價的硬件設施，使得人們更容易嘗試和使用這些系統(tǒng)，數(shù)據(jù)和業(yè)務遷移的成本也更低。在開放性方面，以Hadoop為代表的開源大數(shù)據(jù)系統(tǒng)形成較大的社區(qū)之后，就會有各種相關系統(tǒng)補充進來，構成生態(tài)圈，滿足人們不同的需求；而商業(yè)大數(shù)據(jù)系統(tǒng)則相對封閉，依賴少數(shù)的廠商發(fā)掘用戶需求，再加上歷史系統(tǒng)的遺留問題，系統(tǒng)的迭代發(fā)展效率不高。此外，以Hadoop為代表的大數(shù)據(jù)系統(tǒng)并不一定是免費和廉價的代名詞，參與這些系統(tǒng)研發(fā)的個人或者組織也可以從中獲得巨大的利益。在這樣的驅動力下，很多用戶也希望參與其中，積極地貢獻和完善相關功能，也給了高校和科研院所更多參與大數(shù)據(jù)研究的機會。這些原因使得開源大數(shù)據(jù)系統(tǒng)逐漸得到認可，并成為大數(shù)據(jù)分析的新寵兒。

2 SQL on Hadoop系統(tǒng)

互聯(lián)網(wǎng)公司最先遇到大數(shù)據(jù)難題，需要為海量互聯(lián)網(wǎng)網(wǎng)頁構建倒排列表。2004年，Google公司提出 MapReduce技術[5]，作為面向大數(shù)據(jù)分析和處理的并行計算模型，引起了工業(yè)界和學術界的廣泛關注，并很快形成了MapReduce的開源實現(xiàn)Hadoop計算和存儲的框架。MapReduce 在設計之初，致力于通過大規(guī)模廉價服務器集群實現(xiàn)大數(shù)據(jù)的并行處理，把擴展性和系統(tǒng)可用性放在了優(yōu)先考慮的位置。MapReduce技術框架包含3個層面的內容：分布式文件系統(tǒng)（GFS或者HDFS）、并行編程模型、并行執(zhí)行引擎，具體介紹如下。

分布式文件系統(tǒng)運行于大規(guī)模集群之上，集群使用廉價的服務器構建。數(shù)據(jù)采用鍵值對模式進行組織和分發(fā)。整個文件系統(tǒng)采用元數(shù)據(jù)集中管理、數(shù)據(jù)塊分散存儲的模式，通過數(shù)據(jù)的復制（每份數(shù)據(jù)至少有3個備份）實現(xiàn)高度容錯。數(shù)據(jù)采用大塊存儲（64～256 MB為1塊）的辦法，可方便地對數(shù)據(jù)進行壓縮，實現(xiàn)塊粒度的數(shù)據(jù)復制與查詢處理的容錯。

MapReduce并行編程模型把計算過程分解為兩個主要階段，即map階段和reduce階段。map階段多個任務在多節(jié)點上并發(fā)讀取和處理數(shù)據(jù)，中間結果根據(jù)鍵值對的形式寫入本地磁盤，并經(jīng)過shuffle過程發(fā)到執(zhí)行reduce任務的節(jié)點，再由reduce節(jié)點歸并來自不同節(jié)點的數(shù)據(jù)，將結果輸出或寫入HDFS，完成一輪MapReduce任務。復雜的任務可以轉換為多輪MapReduce任務執(zhí)行。

MapReduce技術是一種簡潔的并行計算模型，在系統(tǒng)層面解決了擴展性、容錯性等問題，通過接收用戶編寫的 map 函數(shù)和reduce函數(shù)，自動在可伸縮的大規(guī)模集群上并行執(zhí)行，從而可以處理和分析大規(guī)模的數(shù)據(jù)。如今隨著Hadoop技術的不斷成熟（如YARN等新一代Hadoop技術），MapReduce任務可以運行在成千上萬個節(jié)點組成的集群上，處理PB級別的數(shù)據(jù)。

Hadoop技術很快也影響了數(shù)據(jù)庫研究領域，有面向簡單的鍵值對讀寫事務型負載的NoSQL系統(tǒng)（如HBase等），也有面向數(shù)據(jù)分析任務的Hive系統(tǒng)。Hive系統(tǒng)的出現(xiàn)，一改傳統(tǒng)的OLAP只能在關系數(shù)據(jù)倉庫中運行的局面，從而可以對HDFS中存儲的結構化數(shù)據(jù)，基于一種類似SQL的HiveQL語言，進行ROLAP方式的數(shù)據(jù)分析。Hive系統(tǒng)將用HiveQL描述的查詢語句，轉換成MapReduce任務來執(zhí)行，并且具備了一定的查詢優(yōu)化能力，這樣就可以在大規(guī)模集群環(huán)境下對TB級別甚至PB級別的大數(shù)據(jù)進行OLAP。這顯然對傳統(tǒng)并行數(shù)據(jù)庫和數(shù)據(jù)倉庫技術構成了挑戰(zhàn)，也很快得到了數(shù)據(jù)分析領域一些著名的學者（如Dewitt和Stonebraker等）的回應，這就有了2009年SIGMOD會議上發(fā)表的在大數(shù)據(jù)分析領域MPP數(shù)據(jù)庫與Hadoop技術的對比[6]。其結論是：結構化大數(shù)據(jù)分析（OLAP）方面MPP數(shù)據(jù)庫的性能要遠好于以Hive為代表的Hadoop上的數(shù)據(jù)分析技術，而Hadoop技術也有其優(yōu)勢，比如高度的擴展能力和容錯性能、對非結構化數(shù)據(jù)的支持、用戶自定義函數(shù)的使用等方面。

然而，來自互聯(lián)網(wǎng)領域或者其他領域很多大數(shù)據(jù)創(chuàng)新公司，并沒有止步于Hive。最近五六年間做出了很多努力，開發(fā)了多個SQL on Hadoop系統(tǒng)，以提升這些系統(tǒng)的性能。這些系統(tǒng)借鑒了20世紀90年代以來在并行數(shù)據(jù)庫方面所積累的一些先進技術，大幅度提升了SQL on Hadoop系統(tǒng)的性能，所以目前這類SQL on Hadoop系統(tǒng)是非常有吸引力的。

接下來，舉出其中幾個典型的系統(tǒng)加以介紹。

2.1 Hive系統(tǒng)

自從Facebook在2007年推出Apache Hive系統(tǒng)及其HiveQL語言以來，已經(jīng)成為Hadoop平臺標準的SQL實現(xiàn)。Hive把HiveQL查詢首先轉換成MapReduce作業(yè)，然后在Hadoop集群上執(zhí)行。某些操作（如連接操作）被翻譯成若干個MapReduce作業(yè)，依次執(zhí)行。早期版本的Hive，性能與Impala、Presto等系統(tǒng)有很大差距[7]。近年來，開源社區(qū)對Hive進行持續(xù)改進，主要包括以下幾個方面。

● 在SQL接口方面，增加了新的數(shù)據(jù)類型、子查詢支持、更加完備的Join語法等。

● 在文本類型、RCFile列存儲格式之外，增加了具有更高效率的列存儲格式ORCFile。

● 和Tez緊密集成，以便執(zhí)行更通用的任務，獲得更高的性能。Apache Tez是一種新的計算模型，擴展了Hadoop的MapReduce計算模型，能夠執(zhí)行復雜的以DAG（directed acyclic graph，有向無環(huán)圖）表達的計算任務。Tez的DAG頂點管理模塊，在運行時從任務收集相關信息，從而動態(tài)改變數(shù)據(jù)流圖的一些參數(shù)，以便優(yōu)化資源消耗，獲得更高的性能。

● 增加初步的查詢優(yōu)化能力，能根據(jù)數(shù)據(jù)特點，包括表格的基數(shù)、各個數(shù)據(jù)列的統(tǒng)計信息（最大值、最小值、平均值、不同值的個數(shù)）等，進行表連接順序調整和連接算法選擇。目前Hive僅支持等值連接，可選的算法包括Multi Way Join、Common Join、Map Join、Bucket Map Join、SMB Join、Skew Join等，連接算法的詳細信息，可以參考參考文獻[8]。

● 新的向量化的查詢執(zhí)行引擎，通過更好地利用現(xiàn)代CPU的特點，提高查詢性能。

2.2 Impala系統(tǒng)

Impala是由Cloudera公司推出的一個支持交互式（實時）查詢的SQL on Hadoop系統(tǒng)。Impala放棄使用效率不高的MapReduce計算模型，設計專有的查詢處理框架，把執(zhí)行計劃分解以后，分配給相關節(jié)點運行，而不是把執(zhí)行計劃轉換為一系列的MapReduce作業(yè)。Impala不把中間結果持久化到硬盤上，而是使用MPP數(shù)據(jù)庫慣用的技術，即基于內存的數(shù)據(jù)傳輸，在各個操作之間傳輸數(shù)據(jù)。Impala后臺進程以服務的形式啟動，避免了類似于MapReduce任務的啟動時間。查詢執(zhí)行引擎針對新硬件做了相關優(yōu)化，比如充分利用新的指令集（包括單指令多數(shù)據(jù)指令SIMD）進行數(shù)據(jù)處理。同時Impala使用LLVM技術，把查詢編譯成匯編指令，以加快其執(zhí)行，無需不斷進行SQL查詢的語法檢查和翻譯。

在磁盤I/O方面，Impala維護每個數(shù)據(jù)塊的磁盤位置信息，對磁盤塊的操作順序進行優(yōu)化調度，保持各個磁盤忙閑均衡。此外，Impala在實現(xiàn)細節(jié)上，進行了一系列優(yōu)化。在存儲格式方面，Impala支持最新研發(fā)的列存儲格式Parquet，有利于提高數(shù)據(jù)倉庫查詢性能，這些查詢一般只涉及少數(shù)屬性列，列存儲可以避免不必要的數(shù)據(jù)列的提取。

在連接操作的處理方面，Impala根據(jù)表的絕對和相對大小，在不同的連接算法之間進行選擇。廣播連接是默認的方式，右側的表默認比左側的表小，小表內容被發(fā)送到查詢涉及的各個節(jié)點上。另外一種連接算法稱為分區(qū)連接，適用于大小相近的大型表之間的連接。使用分區(qū)連接，每個表的內容被散列分布到各個節(jié)點，各個節(jié)點并行地進行本地連接，連接結果再進行合并。Impala使用Compute Stats語句，收集數(shù)據(jù)庫表的統(tǒng)計信息，輔助進行連接算法的選擇。根據(jù)Cloudera的評測結果，對于I/O限制的查詢，相對于老版本的Hive，Impala有3～4倍的性能提升。而對于需要多個MapReduce 作業(yè)或者需要reduce階段實現(xiàn)連接操作的查詢，Impala可以獲得更大的性能提升。對于至少有一個連接操作的查詢，性能提升達到7～45倍。如果數(shù)據(jù)集可以完整地保存到緩存中，則性能提升達到20～90倍之巨，包括簡單的單表聚集查詢。Impala令人印象深刻的性能使人們相信，只要充分利用各種優(yōu)化措施，包括存儲優(yōu)化、執(zhí)行引擎優(yōu)化、查詢優(yōu)化等技術，Hadoop平臺上的SQL查詢也能達到交互式的性能要求。

2.3 Spark SQL

Spark SQL是美國加州大學伯克利分校提出的大數(shù)據(jù)處理框架BDAS（Berkeley data analytics stack）[10]的一個重要組成部分，包括資源管理層、存儲層、核心處理引擎、存取接口、應用層等層次和部件。Spark SQL是實現(xiàn)大數(shù)據(jù)交互式SQL查詢的處理系統(tǒng)，包括接口Spark SQL和處理引擎Spark Core。Spark是一個分布式容錯內存集群，通過基于血統(tǒng)關系的數(shù)據(jù)集重建技術，實現(xiàn)內存計算的容錯。當一個內存數(shù)據(jù)集損壞時，可以從上游數(shù)據(jù)集通過一系列的操作重建該數(shù)據(jù)集。Spark SQL使用內存列存儲技術支持分析型應用。在復雜查詢執(zhí)行過程中，中間結果通過內存進行傳輸，無需持久化到硬盤上，極大地提高了查詢的執(zhí)行性能。Spark SQL在設計上實現(xiàn)了和Apache Hive在存儲結構、序列化和反序列化方法、數(shù)據(jù)類型、元信息管理等方面的兼容。此外，BDAS還支持流數(shù)據(jù)處理和圖數(shù)據(jù)的計算，并通過迭代計算支持各種機器學習算法；甚至可以運行在YARN上，和Hive使用的是同一個資源管理模型。

MapReduce系統(tǒng)性能不佳的原因有很多，包括中間結果持久化到硬盤、數(shù)據(jù)存儲格式性能低劣、不能控制數(shù)據(jù)的并置（copartitioning）、執(zhí)行策略缺乏基于統(tǒng)計數(shù)據(jù)的優(yōu)化、任務啟動和調度的開銷過大等，Spark SQL設計者據(jù)此實現(xiàn)了一系列優(yōu)化措施，包括：采用基于內存的列存儲結構；支持基于散列的shuffle和基于排序的shuffle操作；基于range統(tǒng)計信息進行分區(qū)裁剪，減少查詢處理過程中需要掃描的數(shù)據(jù)量；下推查詢限制條件；支持分布式排序；支持分布式并行裝載；集成機器學習功能，方便在SQL語句中執(zhí)行更加復雜的分析等。Spark SQL部分實現(xiàn)了基于成本的優(yōu)化功能，根據(jù)表格和各列數(shù)據(jù)的統(tǒng)計信息，估算工作流上各個階段數(shù)據(jù)集的基數(shù)，進而可以對多表連接查詢的連接順序進行調整。另外如果連接的中間結果或者最終結果集具有較高基數(shù)，系統(tǒng)可以根據(jù)啟發(fā)式規(guī)則，調整reduce任務的數(shù)量，完成Join操作。此外，新版本的Spark SQL還計劃支持數(shù)據(jù)并置以及部分DAG執(zhí)行技術，允許系統(tǒng)根據(jù)運行時搜集的統(tǒng)計信息，動態(tài)改變執(zhí)行計劃，以獲得更高的性能。

2.4 其他典型系統(tǒng)

由于大數(shù)據(jù)上交互式SQL查詢應用方面的強勁需求以及現(xiàn)有系統(tǒng)在性能方面的不足，近幾年涌現(xiàn)了一批新的大數(shù)據(jù)SQL查詢分析系統(tǒng)。Ebay開源了其Hadoop上的MOLAP系統(tǒng)Kylin2http://www. kylin.io/。Kylin的工作原理是：從Hive獲取數(shù)據(jù)，使用MapReduce預處理這些數(shù)據(jù)，生成數(shù)據(jù)立方體，保存到HBase中，以支持100億行數(shù)據(jù)規(guī)模的低時延查詢，部分查詢可以達到亞秒級的響應時間。Kylin提供REST、SQL和OLAP接口，支持TB級別到PB級別的數(shù)據(jù)量；兼容ANSI SQL標準以及Tableau、Microstrategy和Excel等前端工具；支持數(shù)據(jù)的編碼和壓縮，支持Cube的增量更新功能，支持不同值個數(shù)的近似查詢能力。

Tajo3http://tajo. apache.org/是韓國初創(chuàng)公司Gruter研發(fā)的大數(shù)據(jù)分析軟件，目前已經(jīng)作為Apache一個孵化階段的開源項目。Tajo本質上是Hadoop平臺上基于關系模型的分布式數(shù)據(jù)倉庫系統(tǒng)，其設計目標是：支持存儲于HDFS的大數(shù)據(jù)集上的低時延的即席查詢、在線聚集查詢以及ETL操作等。Tajo使用了基于成本的查詢優(yōu)化技術以及漸進式查詢優(yōu)化技術（即在查詢執(zhí)行過程中，根據(jù)搜集的統(tǒng)計數(shù)據(jù)，動態(tài)改變執(zhí)行計劃）；可以支持內存不足情況下的查詢執(zhí)行；對超長時間運行的查詢，提供容錯保證和動態(tài)調度能力，這種針對性的優(yōu)化是Hive、Impala系統(tǒng)所欠缺的。為了支持Tajo走向實際應用，其開發(fā)團隊在Tajo中集成了不同文件格式的支持，包括CSV、JSON、RCFile、Sequence File以及列存儲格式Parquet等；查詢語言兼容ANSI SQL標準，通過JDBC接口，可以方便存取Tajo系統(tǒng)；可以直接存取Hive的元信息管理服務MetaStore。在最新的Tajo評測中（使用TPCH測試基準），大部分查詢取得和Impala相當?shù)男阅埽承┎樵儎t優(yōu)于Impala，比如Q3以及Q5等查詢。

星環(huán)科技是國內少數(shù)掌握Hadoop和Spark核心技術的高科技初創(chuàng)公司，其大數(shù)據(jù)平臺Transwarp Data Hub (TDH)4http:// transwarp.io/，基于Hadoop和Spark技術，實現(xiàn)了流數(shù)據(jù)處理、大數(shù)據(jù)交互式查詢、批處理和機器學習。其中，Transwarp Inceptor是基于內存處理的交互式SQL查詢分析引擎（基于Spark），同時支持數(shù)據(jù)挖掘功能（通過R軟件包）。星環(huán)公司在Hadoop和Spark上進行了大量的二次開發(fā)，借鑒了MPP數(shù)據(jù)庫的查詢優(yōu)化技術，以提供更高的性能；在SQL接口方面，不但支持HiveQL，還支持Oracle PL/SQL存儲過程語言，支持PL/SQL是Transwarp Inceptor的一大特色；支持R軟件包，實現(xiàn)數(shù)據(jù)挖掘功能，并且提供了若干并行化的算法；支持Tableau、SAP BO、Oracle OBIEE等前端報表工具。

Actian公司收購了列存儲數(shù)據(jù)庫MonetDB的商業(yè)化版本Vector后，對其進行移植，以便可以原生地運行在Hadoop平臺上。SQL分析是Actian Hadoop大數(shù)據(jù)分析平臺的一部分，整個項目稱為Vortex。Actian招募了荷蘭著名研究機構CWI的數(shù)據(jù)庫專家Peter Boncz，同時也是Vector的架構師（Vector是Peter Boncz領導研發(fā)的MonetDB開源列存儲數(shù)據(jù)庫的商業(yè)化版本）。在Boncz的帶領下，研發(fā)團隊把Vector X100 SQL（商業(yè)化版本稱為Vectorvise）查詢引擎進行并行化，運行在Hadoop集群上。Vortex除了完全兼容ANSI SQL標準之外，還支持ACID特性，即支持數(shù)據(jù)的更新。Vector支持細粒度的更新，這些更新首先被保存到獨立的數(shù)據(jù)結構里，稱為PDT（positional delta tree），然后和主數(shù)據(jù)結構進行合并。憑借MonetDB團隊在列存儲、數(shù)據(jù)壓縮、查詢優(yōu)化、向量化查詢執(zhí)行、CPU cache存取優(yōu)化等方面十幾年的研究和開發(fā)積累，Vector獲得了極高的性能，根據(jù)Actian內部的評測，Vector目前是同類系統(tǒng)在TPC-H評測基準上最高性能紀錄的保持者5http://www. datanami.com/ 2014/06/03/ actian-aimsengulf-impalavortex/，其查詢處理性能是Impala的16～32倍。

Flink6http://flink. apache.org和Spark都是通用的大數(shù)據(jù)處理系統(tǒng)，并且都是Apache軟件基金會的頂級開源項目。在處理SQL查詢方面，目前Spark中有Spark SQL，F(xiàn)link中有MRQL。在圖計算、流數(shù)據(jù)處理和機器學習方面，兩者也都有對應的組件予以支持。Spark與Flink都可以部署在HDFS之上，通過內存方面的優(yōu)化來提高計算性能。但Spark和Flink也存在一些差別：Spark通過基于內存的RDD將大批量的數(shù)據(jù)緩存在內存中進行處理，這種方式在做批處理式的計算時比較適合，流計算和實時數(shù)據(jù)處理是通過mini batch的方式實現(xiàn)的，本質上并不是非常適合實時計算；而Flink針對循環(huán)和迭代計算的優(yōu)化更多，可支持的數(shù)據(jù)處理粒度更細，流數(shù)據(jù)處理方式類似Storm的元素粒度的流水線，而不是Spark中的mini batch。

3 大數(shù)據(jù)分析系統(tǒng)技術特點

3.1 實驗設定

虛擬機和物理機使用的硬件環(huán)境見表1。

表1 測試硬件環(huán)境

操作系統(tǒng)采用的是CentOS 6.4版本。Hive-Tez使用的是Hortonworks Hive 0.14版本，用ORCFile存儲格式；Impala的版本為Impala 2.1.3，使用Parquet存儲格式；Spark SQL使用的是Spark 1.2，采用Parquet存儲格式。各個系統(tǒng)在測試之前進行了大量參數(shù)調優(yōu)的工作，以確保查詢在優(yōu)化的參數(shù)配置下執(zhí)行。

3.2 性能對比測試

使用TPC-H基準生成了300 GB規(guī)模的數(shù)據(jù)，在16個節(jié)點組成的虛擬機環(huán)境下，對Hive、Impala和Spark 3個系統(tǒng)的性能進行對比。各查詢的執(zhí)行時間見表2。相應的，Impala和Spark SQL相對于Hive-Tez的加速比在圖1中給出。

綜合表2和圖1的結果，可以看出，Impala僅在Q1、Q6、Q12、Q15上的性能明顯優(yōu)于Hive，這幾個查詢都是比較簡單的查詢，有兩個是直接在事實表lineitem上的單表統(tǒng)計查詢，而另外兩個是包含lineitem的兩表連接，都可以使用廣播連接的方式將小表數(shù)據(jù)復制到各個節(jié)點上與事實表lineitem進行連接操作。這個測試結果一方面說明Hive在過去數(shù)年中在性能上的提升非常顯著，Impala最初在性能上表現(xiàn)出的優(yōu)勢已經(jīng)不明顯；另一方面也說明Impala在一些簡單的查詢上有好的優(yōu)化效果，對于一些復雜的查詢優(yōu)化效果不好，甚至無法成功執(zhí)行。

表2 16節(jié)點-300 GB-OpenStack虛擬機環(huán)境下3個系統(tǒng)的查詢執(zhí)行時間

對于Spark SQL而言，其查詢性能與Hive在很多查詢上相差無幾，各有千秋。Spark SQL僅在Q3、Q4、Q10、Q16上的表現(xiàn)好于Hive（1.5～1.9倍的加速比）。這幾個查詢復雜度不一，從兩表連接到lineitem基礎上的4表連接鏈式查詢都有。Spark SQL在個別查詢上多連接執(zhí)行次序更優(yōu)化一些，也是其在個別查詢上性能明顯好于Hive的一個重要因素。

圖1 16節(jié)點-300 GB-OpenStack虛擬機環(huán)境，相對Hive-Tez的性能提升率

從表2的數(shù)據(jù)能夠看出，Impala在很多查詢上出錯或超時，暴露出其不穩(wěn)定性，尤其是在相對復雜的查詢中。具體分析發(fā)現(xiàn)，Impala在一些查詢上，經(jīng)常會因為內存不足而出現(xiàn)錯誤或者長時間跑不出結果。Impala深度借鑒MPP數(shù)據(jù)庫技術，依賴大內存提升連接執(zhí)行效率。因為拋棄了MapReduce，系統(tǒng)不再具備查詢間容錯，一個查詢如果在一個節(jié)點上出現(xiàn)問題（內存不足或其他節(jié)點故障等），整個查詢就不能夠被成功完成。相比而言，Hive和Spark SQL由于還保留有MapReduce的中間結果shuffle機制，在容錯方面比Impala好很多。

該水源方案存在的主要缺點是：（1）受地形、地質、降雨、氣候等因素的影響，部分山泉水隨季節(jié)變化明顯，開發(fā)利用時必須進行設計保證率條件下的供、需水平衡計算，科學確定可開采量，保證工程的持續(xù)利用。（2）山泉水多出漏于具有良好隔水性的山澗，鋪設輸水管線石方開挖量大，且管線較長。（3）由于水量有限，不利于鄉(xiāng)村企業(yè)、家庭作坊、田園經(jīng)濟的發(fā)展。

從3個系統(tǒng)整體上的性能表現(xiàn)看，相比于一年多以前的測試結果[8]，以Hadoop為基礎的Hive和Spark SQL系統(tǒng)在性能上很多方面已經(jīng)追趕上了以MPP并行數(shù)據(jù)庫技術為基礎的Impala系統(tǒng)。這一方面得益于Hadoop生態(tài)圈的開放性和進取心，同時也充分體現(xiàn)了隨著更多傳統(tǒng)MPP并行數(shù)據(jù)庫技術的引入，SQL on Hadoop系統(tǒng)的分析性能越來越強大。當然也要意識到，因為Hadoop存儲的透明性，數(shù)據(jù)缺少好的劃分和全局索引機制，勢必也會限制SQL on Hadoop系統(tǒng)所能夠達到的性能高度。進一步的技術突破，除了在查詢優(yōu)化方面深度借鑒MPP數(shù)據(jù)庫技術外，在數(shù)據(jù)存儲與劃分方面可能還需邁出堅實的一步，需要犧牲一些Hadoop數(shù)據(jù)存儲的透明性。

總體來看，SQL on Hadoop系統(tǒng)由于其開放性和在容錯方面的優(yōu)勢，性能提升明顯，在Hadoop上的很多OLAP任務已經(jīng)具備交互性能。

3.3 可擴展性能力測試

為了更好地了解各個系統(tǒng)的查詢性能隨著系統(tǒng)節(jié)點數(shù)和系統(tǒng)處理數(shù)據(jù)量的變化情況，分別在這3個系統(tǒng)上，通過調整節(jié)點數(shù)量和系統(tǒng)數(shù)據(jù)量進行可擴展性方面的測量。在Hive-Tez系統(tǒng)上，節(jié)點數(shù)量從8個增加到16個和32個的實驗結果如圖2所示，而在該系統(tǒng)上數(shù)據(jù)量從100 GB變到300 GB的實驗結果如圖3所示。最后，把3個系統(tǒng)在所有查詢上的平均性能變化列在表3與表4中。

通過表3的數(shù)據(jù)能夠看到，隨著節(jié)點數(shù)量的翻倍，系統(tǒng)的查詢性能提升很難達到翻倍的理想線性加速比。相對而言，Spark SQL隨著節(jié)點數(shù)量的增加，查詢提升效果更為明顯，而Impala則隨著系統(tǒng)節(jié)點數(shù)量的增加，性能提升比例最為微弱。這也源于Impala是一個偏MPP數(shù)據(jù)庫型的解決方案，系統(tǒng)的擴展性不好。而Hive和Spark SQL是從Hadoop擴展而來的大數(shù)據(jù)SQL分析解決方案，其擴展性更有優(yōu)勢，能夠更好地發(fā)揮出大規(guī)模集群計算的優(yōu)勢。

圖2 Hive-Tez系統(tǒng)32節(jié)點與16節(jié)點相對8節(jié)點集群的加速比

圖3 Hive-Tez系統(tǒng)300 GB相對100 GB的加速比

從表4的結果來看，各系統(tǒng)的查詢性能都隨著數(shù)量的增加而降低，但性能下降的比例并不如數(shù)量增加的比例高。這是一個好現(xiàn)象，說明系統(tǒng)在處理更大規(guī)模的數(shù)據(jù)量時，性能犧牲的幅度沒有想象的大。相比而言，Hive隨著數(shù)據(jù)量的增加，系統(tǒng)性能下降的比例最低。這也是有原因的，Impala和Spark SQL對內存依賴大，數(shù)據(jù)量增加會直接影響內存的使用，容易造成這兩個系統(tǒng)的性能瓶頸；而Hive對內存的依賴不強，因此表現(xiàn)好于另外兩個系統(tǒng)。

通過可擴展性實驗，發(fā)現(xiàn)現(xiàn)有SQL on Hadoop系統(tǒng)的穩(wěn)定性還存在很大的問題，當數(shù)據(jù)量變化或者節(jié)點數(shù)量增大時，出現(xiàn)了更多的查詢無法被正確執(zhí)行。Hive相對穩(wěn)定，但其采用的Map-side-join技術，在某些數(shù)據(jù)量和節(jié)點數(shù)配置下，會出現(xiàn)錯誤。說明這些新技術的引入，還存在很多細節(jié)問題沒有得到很好的解決，需要進一步的研究和改進。從Hive、Spark SQL和Impala的對比來看，前兩者由于擁有更好的開放性和更大范圍Hadoop生態(tài)圈的支持，穩(wěn)定性進步比較明顯；相比而言，在開放性方面相對保守的Impala系統(tǒng)存儲的問題比較多，還需更長時間完善。

測試結果說明，SQL on Hadoop系統(tǒng)在查詢優(yōu)化和執(zhí)行的一些細節(jié)方面還存在一些問題，需要時間進一步完善。在這一過程中Hive和Spark SQL由于其有更好的開放性，所存在的細節(jié)問題更容易得到解決。

表3 100 GB-相對8節(jié)點集群的平均加速比

表4 300 GB相對100 GB的平均加速比

3.4 物理機與虛擬機性能對比

為了更好地了解物理機和虛擬機集群在查詢處理性能方面的差別，在8個節(jié)點的虛擬機集群和物理機集群中對3個系統(tǒng)進行性能對比實驗，所選用節(jié)點的內存數(shù)量一樣，CPU個數(shù)和磁盤性能有所不同。其結果見表5。

表5 8節(jié)點-100GB-物理機與虛擬機性能對比

可以明顯看出，在大多數(shù)查詢上，物理機的性能要明顯好于虛擬機。原因可能是多方面的，虛擬機環(huán)境存在同一物理節(jié)點上不同虛擬機爭搶資源的情況（如I/O通道）。物理機與虛擬機的性能差別，一定程度上也體現(xiàn)了硬件差異對數(shù)據(jù)分析性能的影響，但scale-up不是大數(shù)據(jù)技術合理的發(fā)展方向，依賴更多的普通機器的scaleout技術方案才有更大的發(fā)展前景。

SQL on Hadoop系統(tǒng)的潛力巨大，隨著普通機器硬件性能的提升，同時借鑒MPP并行數(shù)據(jù)庫技術，其終將在低成本的大數(shù)據(jù)OLAP市場中占據(jù)重要的位置。

4 結束語

OLAP是傳統(tǒng)商業(yè)智能中最重要的一類分析任務。盡管MPP并行數(shù)據(jù)庫提供了高性能的OLAP技術，但從近些年大數(shù)據(jù)分析系統(tǒng)的發(fā)展趨勢來看，SQL on Hadoop系統(tǒng)在未來的OLAP市場中將占有重要的位置，是值得關注的方向。除了體系結構與生俱來的優(yōu)勢（如容錯、可擴展、開源、低成本），制約其實用性的最大困難——性能在過去數(shù)年中已經(jīng)有了長足的進步。技術的滲透和融合在這個過程中起到了主導的作用。Stonebraker與Hadoop社區(qū)的爭論似乎還在耳邊，傳統(tǒng)數(shù)據(jù)庫技術與Hadoop技術的融合早就悄悄地在進行，完善SQL on Hadoop系統(tǒng)今后還要更多地從數(shù)據(jù)庫技術中汲取養(yǎng)分。

此外，依賴Hadoop的數(shù)據(jù)分析系統(tǒng)還要在數(shù)據(jù)存儲的透明性上做出犧牲，以換取更高的OLAP性能。從測試結果分析來看，目前SQL on Hadoop系統(tǒng)還存在不少問題，如何根據(jù)資源情況和數(shù)據(jù)分布更好地進行查詢優(yōu)化，如何進一步提高系統(tǒng)的頑健性，如何增加對SQL更全面的支持，都給有志于此的科技工作者提供了很大的探索空間。

致謝

中國人民大學信息學院數(shù)據(jù)庫與智能信息檢索實驗室的研究生卞昊穹、陳峻、李帥、劉捷思、張慧杰參與了系統(tǒng)評測工作。此項研究在中國人民大學“人大行云”平臺上完成。

[1] Codd E F, Codd S B, Salley C T. Providing OLAP (online analytical processing) to user-analysts: an IT mandate. E f codd & Associates, 1998

[2] Thomsen E. OLAP Solutions: Building Multidimensional Information Systems, 2nd Edition. Hoboken: John Wiley & Sons, 2002

[3] Daniel M S, Abadi D J, Batkin A, et al. C-store: a column-oriented DBMS. Proceedings of the 31st Very Large Data Bases (VLDB) Conference, Trondheim, Norway, 2005: 553～564

[4] Kaufmann M, Manjili A A, Vagenas P, et al. Timeline index: a unified data structure for processing queries on temporal data in SAP HANA. Proceedings of Acm Special Interest Group on Management of Data (SIGMOD) International Conference on Management of Data, New York, USA, 2013: 1173～1184

[5] Dean J, Ghemawat S. MapReduce: simplified data processing on large clusters. Proceedings of Operating Systems Design and Implementation (OSDI), San Francisco, CA, USA, 2004: 137～150

[6] Pavlo A, Paulson E, Rasin A, et al. A comparison of approaches to large-scaledata analysis. Proceedings of the ACM Special Interest Group on Management of Data (SIGMOD) International Conference on Management of Data, Providence, USA, 2009: 165～178

[7] Chen Y G, Qin X P, Bian H Q, et al. A study of SQL-on-hadoop systems. Lecture Notes in Computer Science, 2014(8807): 154～166

[8] Hive cost based optimization. https:// cwiki.apache.org/confluence/display/Hive/ Cost-based +optimization+in+Hive, 2015

[9] Ion Stoica. Berkeley data analytics stack (BDAS) overview. http:// ampcamp.berkeley.edu/wp-content/ uploads/2013/02/Berkeley-Data-Analytics-Stack-BDAS-Overview-Ion-Stoica-Strata-2013.pdf, 2013

杜小勇，男，博士，中國人民大學信息學院教授、博士生導師，中國計算機學會會士，數(shù)據(jù)庫專家委員會委員、大數(shù)據(jù)專家委員會委員，人民郵電出版社《大數(shù)據(jù)》期刊編委會副主任，Springer出版社《Communications of Computer and Information Systems》系列編委，主要研究方向為智能信息檢索、高性能數(shù)據(jù)庫、知識工程。主持和參與多項國家核高基（核心電子器件、高端通用芯片及基礎軟件產(chǎn)品）、“973”計劃、“863”計劃、國家自然科學基金項目，近年來在SIGMOD、VLDB、AAAI、IEEE TKDE等國際重要期刊和會議上發(fā)表論文百余篇。

陳躍國，男，博士，中國人民大學信息學院副教授、碩士生導師，中國計算機學會高級會員，大數(shù)據(jù)專家委員會通信委員，F(xiàn)rontiers of Computer Science青年編委，主要研究方向為大數(shù)據(jù)分析系統(tǒng)和語義搜索。主持國家自然科學基金項目2項，參與多項國家核高基（核心電子器件、高端通用芯片及基礎軟件產(chǎn)品）、“973”計劃、“863”計劃項目，近年來在ICDE、AAAI、IEEE TKDE等國際重要期刊和會議上發(fā)表論文30余篇。

覃雄派，男，博士，中國人民大學信息學院講師、碩士生導師，目前主要從事高性能數(shù)據(jù)庫、大數(shù)據(jù)分析、信息檢索等方面的研究工作，主持1項國家自然科學基金面上項目，參與多項國家“863”計劃、“973”計劃及國家自然科學基金項目，在國內外期刊和會議上發(fā)表論文20余篇。

Du X Y, Chen Y G, Qin X P. Big data and OLAP systems. Big Data Research, 2015005

Big Data and OLAP Systems

Du Xiaoyong, Chen Yueguo, Qin Xiongpai
Key Laboratory of Data Engineering and Knowledge Engineering, School of Information, Renmin University of China, Beijing 100872, China

OLAP (online analytical processing) is a key technology of business intelligence based on relational data. In big data era, people want to achieve high performance OLAP using a large cluster of ordinary nodes. However, the performance of such systems is a big challenge. Recently, many SQL on Hadoop systems have been proposed to address this challenge. We have seen a significant performance improvement of such systems. A survey of technology development of OLAP technologies was first provided. Then, a study of the performance of three representatives SQL on Hadoop systems was focused on. Based on the results, it is expected that such systems will play an very important role in the market of low cost OLAP analysis.

big data, online analytical processing, SQL analysis, SQL on Hadoop

2015-04-30；

2015-05-10

國家自然科學基金面上項目“高度可擴展的數(shù)據(jù)倉庫數(shù)據(jù)編碼方法及查詢處理新技術研究”（No.61170013），中國人民大學科學研究基金（中央高校基本科研業(yè)務費專項資金）資助項目（No.14XNLQ06），國家社會科學基金重大項目“云計算環(huán)境下的信息資源集成與服務研究”（No.12&ZD220）

Foundation Items:The National Science Foundation of China Under Grant (No.61170013)，The Fundamental Research Funds for the Central Universities, the Research Funds of Renmin University of China(No.14XNLQ06)，The National Social Science Foundation of China : Major Research Project(No.12&ZD220)

杜小勇，陳躍國，覃雄派. 大數(shù)據(jù)與OLAP系統(tǒng). 大數(shù)據(jù), 2015005