門 威，王 輝

（河南廣播電視大學 信息技術中心，河南 鄭州 450008）

大數(shù)據(jù)環(huán)境下基于MapReduce和并行數(shù)據(jù)庫的混合模式探究

門 威，王 輝

（河南廣播電視大學 信息技術中心，河南 鄭州 450008）

基于MapReduce編程模式的數(shù)據(jù)倉庫技術和并行數(shù)據(jù)庫技術是解決大數(shù)據(jù)分析問題的兩種重要途徑。MapReduce是一種基于并行運算的編程模型，其優(yōu)點在于處理大規(guī)模非結(jié)構化、松散的數(shù)據(jù)集，但在性能，特別是連接操作的性能上存在很大的缺陷；并行數(shù)據(jù)庫是建立在集群計算環(huán)境和MPP的高性能數(shù)據(jù)庫，其優(yōu)點是具有高效的結(jié)構化數(shù)據(jù)查詢處理能力，但其容錯能力和擴展能力薄弱。因此，兩者都不能成為大數(shù)據(jù)分析的理想解決方案。本文在綜合分析的基礎上，結(jié)合二者優(yōu)點，探索基于MapReduce和并行數(shù)據(jù)庫的混合架構，并對多種架構方案進行詳細分析，最后對各研究方向進行分析、歸納和展望。

大數(shù)據(jù)分析；并行數(shù)據(jù)庫；MapReduce

一、引言

在大數(shù)據(jù)分析過程中，需要處理PB級甚至更高級別的數(shù)據(jù)，查詢分析復雜、數(shù)據(jù)量大已成為其基本特點。數(shù)據(jù)處理能力的不足和日益增長的數(shù)據(jù)分析處理需求之間的矛盾需亟待解決。構建適合于大數(shù)據(jù)分析的數(shù)據(jù)倉庫架構是解決大數(shù)據(jù)分析問題的關鍵途徑之一。下面分別從大數(shù)據(jù)發(fā)展趨勢、數(shù)據(jù)倉庫面臨的問題及其特性需求三個方面進行論述。

（一）發(fā)展趨勢

隨著大數(shù)據(jù)存儲、分析技術的發(fā)展及其應用領域的不斷擴大，數(shù)據(jù)本身及應用、處理環(huán)境發(fā)生了一系列變化，這些變化主要表現(xiàn)在以下幾個方面。

1.數(shù)據(jù)量爆炸式增長。據(jù)權威數(shù)據(jù)顯示，當前時期，數(shù)據(jù)量每兩年增加約3倍，年均增長約17%（超過摩爾定律），部分大型數(shù)據(jù)倉庫的數(shù)據(jù)量近100PB。［1］

2.數(shù)據(jù)分析需求的轉(zhuǎn)變。數(shù)據(jù)分析的需求從常規(guī)化分析逐步轉(zhuǎn)變到深度化（Deep Analytics）、精細化分析。大數(shù)據(jù)分析已成為企業(yè)決策的重要來源，但逐漸不能滿足企業(yè)對數(shù)據(jù)和檢測的需求。數(shù)據(jù)關聯(lián)度分析、移動平均線分析、回歸分析等復雜分析技術不斷涌向，它們統(tǒng)稱為深度分析，能為企業(yè)提供更多的分析手段和預測結(jié)果以提高企業(yè)競爭力。

3.部分硬件平臺從高端服務器遷移到大規(guī)模中低檔機群平臺。隨著數(shù)據(jù)量不斷膨脹，數(shù)據(jù)存儲成本不斷上升，同時大規(guī)模集群和分布式處理技術也在不斷進步，很多企業(yè)選擇將數(shù)據(jù)從高端平臺遷移到大規(guī)模機群平臺。

（二）典型模型下的數(shù)據(jù)倉庫所面臨的問題

當前典型模型下的數(shù)據(jù)倉庫的實現(xiàn)包含4個層次：數(shù)據(jù)源、數(shù)據(jù)倉庫（集市）、OLAP服務和前端展示，如圖1所示。［2］

圖1 數(shù)據(jù)倉庫架構簡化圖

數(shù)據(jù)源中的數(shù)據(jù)首先被ETL工具抽取到數(shù)據(jù)倉庫進行集中存儲，按照雪花模型、星型模型等組織建模，然后利用OLAP讀取數(shù)據(jù)并生成MOLAP（數(shù)據(jù)立方）或直接在數(shù)據(jù)倉庫中進行分析（ROLAP）。但是這種計算模式存在兩個問題：

1.數(shù)據(jù)遷移代價較高。數(shù)據(jù)管理層（數(shù)據(jù)集市）可以提升待分析數(shù)據(jù)質(zhì)量、提高查詢效率，同時為數(shù)據(jù)轉(zhuǎn)存付出時間代價，它首先通過耗時且復雜的ETL方法從數(shù)據(jù)源抽取數(shù)據(jù)，然后轉(zhuǎn)化成雪花模型或者星型模型等，在執(zhí)行分析時需要從數(shù)據(jù)庫中再次抽取部分數(shù)據(jù)。這種數(shù)據(jù)遷移方式難以滿足PB級數(shù)據(jù)的處理。

2.難以適應變化頻繁的場合。傳統(tǒng)的數(shù)據(jù)分析技術適用于主題固定的場合，對數(shù)據(jù)質(zhì)量的要求較高，不考慮預處理代價，但這不能滿足大數(shù)據(jù)時代的需求，即是在時刻變化的環(huán)境中進行數(shù)據(jù)分析。數(shù)據(jù)集市可通過舍棄冗余數(shù)據(jù)的方式緩解數(shù)據(jù)處理壓力，但只是權宜之計，被舍棄數(shù)據(jù)可能被將來用到卻難以找回。因此需要探索更加有效的解決方案。

（三）大數(shù)據(jù)技術對數(shù)據(jù)倉庫特性要求

為滿足大數(shù)據(jù)處理分析的要求，數(shù)據(jù)倉庫必須具備以下幾種特性：

1.較強的環(huán)境適應能力。企業(yè)或單位在信息化發(fā)展過程中，已經(jīng)建設很多信息化基礎設施。這些設施的建設時間不一、型號配置復雜。為能有效利用已有資源（閑置資源），數(shù)據(jù)倉庫必須要有較強的環(huán)境適應能力，滿足不同的環(huán)境需要，同時還需要有較高的容錯能力和兼容性。

2.可擴展性強。數(shù)據(jù)倉庫建立在大規(guī)模計算機集群上，并隨著數(shù)據(jù)規(guī)模的不斷增大而不斷擴展，因此，數(shù)據(jù)倉庫需要有一定的橫向擴張能力。

3.高性能、低延遲。為更好地處理不斷增長的數(shù)據(jù)，提高數(shù)據(jù)處理并行化、高性能化是必需途徑，同時也要壓縮數(shù)據(jù)準備時間，降低數(shù)據(jù)分析延遲，以滿足動態(tài)數(shù)據(jù)分析需求。

二、MapReduce和并行數(shù)據(jù)庫的混合架構

基于MapReduce編程模式的數(shù)據(jù)倉庫技術和并行數(shù)據(jù)庫技術是解決大數(shù)據(jù)分析問題的兩種重要途徑，但都不是最佳解決方案。MapReduce是一種基于并行運算的編程模型，善于處理大規(guī)模非結(jié)構化、松散的數(shù)據(jù)集，但在性能，特別是連接操作性能上受限；并行數(shù)據(jù)庫是在集群計算環(huán)境和MPP上建立的高性能數(shù)據(jù)庫，其對結(jié)構化數(shù)據(jù)有較高的查詢能力，但在容錯能力和擴展能力上受限。可以將二者結(jié)合起來，設計出兼有兩者優(yōu)點的數(shù)據(jù)分析架構。［3］根據(jù)二者結(jié)合方式不同，混合架構可以分為3類：MapReduce主導型架構、并行數(shù)據(jù)庫主導型架構和兼顧型（集成型）架構。表1是3種架構的簡要對比分析。

（一）MapReduce主導型架構

MapReduce主導型架構主要是在MapReduce編程模型中增加對SQL接口的支持，從而增強其易用性，比較典型的系統(tǒng)有Pig Latin和Hive［4］等。其中Pig Latin是雅虎提出的大數(shù)據(jù)分析方案，它提供一種帶有操作符的數(shù)據(jù)流操作接口，如圖2所示。

表1 3種混合架構對比分析

圖2 Pig Latin查詢示例

圖2用于查詢計算機學院的學生最喜歡借閱的10本專業(yè)書。從圖中我們可以看出：Pig Latin的操作接口相當于關系數(shù)據(jù)庫（RDBMS）里面的操作符（如圖中右側(cè)部分所示）?？梢园裀ig Latin理解成Hadoop的操作符形式的封裝。［5］

Hive是基于 Hadoop架構的大型的數(shù)據(jù)倉庫，其目的是簡化Hadoop的大數(shù)據(jù)集分析、adhoc查詢、數(shù)據(jù)聚集等操作，它擁有類似于SQL的數(shù)據(jù)操作語言HiveQL，模仿關系數(shù)據(jù)庫的管理模式，把數(shù)據(jù)文件（結(jié)構化）轉(zhuǎn)化成數(shù)據(jù)表，最終把HiveQL查詢語言轉(zhuǎn)化成MapReduce任務執(zhí)行，同時也支持自定義的Map或Reduce函數(shù)。Hive可以理解為用類SQL語句對Hadoop進行封裝。

（二）并行數(shù)據(jù)主導型架構

并行數(shù)據(jù)庫型架構的設計目標是利用 MapReduce提高并行數(shù)據(jù)庫的處理能力。典型案例如Aster Data［6］系統(tǒng)和Greenplum系統(tǒng)等。其中Greenplum可以同時處理 MapReduce job和 SQL查詢，相當于在SQL中加入了 MapReduce處理工具：SQL既可以將查詢結(jié)果直接輸入到MapReduce中，也可以直接使用MapReduce的執(zhí)行結(jié)果。這種整合發(fā)生代碼級。

Aster Data基于 SQL/MapReduce架構，將SQL和 MapReduce二者整合，它可以利用Python、Java等編寫MapReduce函數(shù)，然后把該函數(shù)當成SQL的子查詢使用，這便結(jié)合了MapReduce的開放性和SQL的易用性，從而提高了數(shù)據(jù)分析的能力。

總之，這兩種模型都是利用MapReduce改善并行數(shù)據(jù)庫的數(shù)據(jù)處理能力，但容錯能力和擴展能力沒有提升。

（三）兼顧型（集成型）架構

MapReduce和并行數(shù)據(jù)庫集成型架構的典型代表是Vertica數(shù)據(jù)庫［7］、Hadapt（也稱為HadoopDB）［8］以及Teradata數(shù)據(jù)庫等。其中Vertica善于處理結(jié)構化數(shù)據(jù)、提供高性能交互查詢，它支持在MapReduce的task中直接存取Vertica數(shù)據(jù)庫數(shù)據(jù)，但在面臨大規(guī)模數(shù)據(jù)時，擴展能力受限。HadoopDB與之相反，它善于處理非結(jié)構化數(shù)據(jù)和復雜的批處理任務，但是性能上滯后，其原因在于以下幾點：

1.維護成本高。Hadoop系統(tǒng)存在大量數(shù)據(jù)節(jié)點，需要較高的維護成本。

2.預處理代價高。每次操作都要包含一次數(shù)據(jù)庫加載和兩次任務分解，較為繁瑣。

3.動態(tài)劃分能力差，大部分任務需要手動將數(shù)據(jù)劃分。

4.在處理復雜的多表連接查詢時，難以按照固有模式進行表空間劃分?？傊?，HadoopDB以犧牲MapReduce的低預處理代價，換取關系數(shù)據(jù)庫的高性能，但在有些情況下可同時實現(xiàn)MapReduce的擴展性和關系數(shù)據(jù)庫的高性能。

Teradata數(shù)據(jù)庫基于存儲層整合，相對簡單。它可從Hadoop分布式文件系統(tǒng)中讀取數(shù)據(jù)，也支持MapReduce從Teradata數(shù)據(jù)庫中直接讀取數(shù)據(jù)，但沒有解決本身和Hadoop的根本問題。

三、總結(jié)、分析與展望

MapReduce的問題在于性能受限，而并行數(shù)據(jù)庫的問題是擴展能力和容錯能力不足，二者各有優(yōu)缺點。本文重點研究了MapReduce和并行數(shù)據(jù)庫相融合的三種混合架構，并對每一種架構的多個案例進行詳細的分析。混合架構的目標是將MapReduce的高擴展性和并行數(shù)據(jù)庫的高性能有機結(jié)合，以實現(xiàn)更高效的大數(shù)據(jù)處理分析。下文就改善混合架構的相關問題及研究進行歸納分析：

（一）最大化地將數(shù)據(jù)處理植入數(shù)據(jù)庫層面

在連接優(yōu)化方面，Hadoop提出兩種策略［9］：第一種策略是通過數(shù)據(jù)分解，將待處理數(shù)據(jù)按數(shù)據(jù)庫進行劃分，盡量使每次處理的數(shù)據(jù)分布在一個數(shù)據(jù)庫內(nèi)，從而實現(xiàn)庫內(nèi)連接操作，但是其應用場合很有限（只用于鏈式連接）。第二種策略是在廣播式連接前，先在某一庫內(nèi)創(chuàng)建每張表的副本（臨時表），從而使連接操作壓縮到該庫中執(zhí)行，但是該策略增加了磁盤讀寫和網(wǎng)絡傳輸負擔。

（二）提高并行數(shù)據(jù)庫容錯性和擴展性

在該方面改進效果較好的是Osprey系統(tǒng)。它采用實際表橫向切分、各節(jié)點完全復制的冗余備份策略，把星型查詢分解成多個子查詢，且在每個子查詢失敗時，都能在備份節(jié)點上重新加載執(zhí)行，不用重復執(zhí)行整個查詢，從而提高了數(shù)據(jù)倉庫的容錯能力。

（三）優(yōu)化提高MapReduce性能

MapReduce性能優(yōu)化的一個重要方法是借鑒移植關系數(shù)據(jù)庫的計算模式。美國俄亥俄州立大學研究并提出了RCFile存儲模式，將關系數(shù)據(jù)庫模型應用到Hadoop平臺，使得Hadoop系統(tǒng)獲得數(shù)據(jù)庫索引和分區(qū)能力，從而提高性能。

總之，基于MapReduce和并行數(shù)據(jù)庫的混合架構雖然能在一定程度上提高大數(shù)據(jù)分析和處理的能力，但和理想目標還有一定距離，需要通過技術研究和創(chuàng)新，使二者有機結(jié)合起來，各取優(yōu)點，最終形成更加高效的大數(shù)據(jù)分析處理架構。

［1］王珊，王會舉，覃雄派，周烜.架構大數(shù)據(jù)：挑戰(zhàn)、現(xiàn)狀與展望［J］.計算機學報，2011，34（10）：1741-1752.

［2］Chaudhuri S，Dayal U.An overview of data warehousing and OLAP technology［J］.SIGMOD Record，1997，（26）：65-74.

［3］Stonebraker M，Abadi D J，DeWitt D J，Madden S，Paulson E，Pavlo A，Rasin A.MapReduce and parallelDBMSsFriends orfoes［J］. Communications of the ACM，2010，53（1）：64-71.

［4］覃雄派，王會舉，杜小勇，王珊.大數(shù)據(jù)分析——RDBMS與Map Reduce的競爭與共生［J］.軟件學報，2012，23（1）：32-45.

［5］史英杰，孟小峰.云數(shù)據(jù)管理系統(tǒng)中查詢技術研究綜述［J］.計算機學報，2013，36（2）：209-226.

［6］曾耀國.Aster Data——快速處理大型數(shù)據(jù)的佼佼者［J］.電腦與電信，2010，（3）.

［7］崔躍生，張勇，曾春，馮建華，邢春曉.數(shù)據(jù)庫物理結(jié)構優(yōu)化技術［J］.軟件學報，2013，24（4）：761-766.

［8］White T.Hadoop權威指南［M］.南京：東南大學出版社，2011.

［9］周品.云時代的大數(shù)據(jù)［M］.北京：電子工業(yè)出版社，2013.

TP311.13

A

1671-2862（2017）01-0109-04

2016-11-25

本文系2016年度河南省教育廳高等學校重點科研項目“基于云計算解決方案的河南省志愿服務信息云平臺的研究設計與構建”（項目編號：16B520008）和2016年度國家開放大學科研項目（青年項目）“基于Hadoop云計算解決方案的開放教育數(shù)字化教學資源云平臺的研究與設計”（項目編號：G16F2406Q）的研究成果。

門威，男，河南永城人，碩士研究生，河南廣播電視大學助教，研究方向：云計算、軟件工程；王輝，男，河南鄭州人，碩士研究生，河南廣播電視大學講師，研究方向：計算機技術應用、軟件系統(tǒng)設計與維護、數(shù)字資源在教育中的應用。