mapreduce數(shù)據(jù)分析-課件

大規(guī)模數(shù)據(jù)分析方法對(duì)比

AComparisonofApproachestoLarge-ScaleDataAnalysis大規(guī)模數(shù)據(jù)分析方法對(duì)比

AComparisonofAp作者1：AndrewPavlo，BrownUniversity1MapReduceandparallelDBMSs:friendsorfoes?

朋友還是冤家2Acomparisonofapproachestolarge-scaledataanalysis

3H-store:ahigh-performance,distributedmainmemorytransactionprocessingsystem

4TheNMIbuild&testlaboratory:continuousintegrationframeworkfordistributedcomputingsoftware5Smoothertransitionsbetweenbreadth-first-spanning-tree-baseddrawings主要做Hadoop(Mapreduce)和并行數(shù)據(jù)庫管理系統(tǒng)比較，用于大規(guī)模數(shù)據(jù)集分析。作者簡(jiǎn)介作者1：AndrewPavlo，BrownUniver作者2ErikPaulson，

UniversityofWisconsin1MapReduceandparallelDBMSs:friendsorfoes?2Acomparisonofapproachestolarge-scaledataanalysis3Clustera:anintegratedcomputationanddatamanagementsystem 和第一作者一樣，主要做Hadoop(Mapreduce)和并行數(shù)據(jù)庫管理系統(tǒng)比較，用于大規(guī)模數(shù)據(jù)集分析。作者2ErikPaulson，University作者3AlexanderRasin，BrownUniversity1CORADD:correlationawaredatabasedesignerformaterializedviewsandindexes2MapReduceandparallelDBMSs:friendsorfoes?3HadoopDB:anarchitecturalhybridofMapReduceandDBMStechnologiesforanalyticalworkloads4Correlationmaps:acompressedaccessmethodforexploitingsoftfunctionaldependencies5Acomparisonofapproachestolarge-scaledataanalysis6H-store:ahigh-performance,distributedmainmemorytransactionprocessingsystem

作者在本文的基礎(chǔ)上，設(shè)計(jì)了HadoopDB系統(tǒng)，一個(gè)Mapreduce和并行數(shù)據(jù)庫管理系統(tǒng)結(jié)合的系統(tǒng)。作者3AlexanderRasin，BrownUni摘要目前有相當(dāng)大的興趣在基于MapReduce（MR）模式的大規(guī)模數(shù)據(jù)分析。雖然這個(gè)框架的基本控制流已經(jīng)存在于并行SQL數(shù)據(jù)庫管理系統(tǒng)超過20年，也有人稱MR為最新的計(jì)算模型。在本文中，我們描述和比較這兩個(gè)模式。此外，我們?cè)u(píng)估兩個(gè)系統(tǒng)的性能和開發(fā)復(fù)雜度。最后，我們定義一個(gè)包含任務(wù)集的基準(zhǔn)運(yùn)行于MR開源平臺(tái)和兩個(gè)并行數(shù)據(jù)庫管理系統(tǒng)上。對(duì)于每個(gè)任務(wù)，我們?cè)?00臺(tái)機(jī)子的集群上衡量每個(gè)系統(tǒng)的各個(gè)方面的并行性能。我們的研究結(jié)果揭示了一些有趣的取舍。雖然加載數(shù)據(jù)和調(diào)整并行數(shù)據(jù)庫管理系統(tǒng)執(zhí)行的過程比MR花費(fèi)更多的時(shí)間，但是觀察到的這些數(shù)據(jù)庫管理系統(tǒng)性能顯著地改善。我們推測(cè)巨大的性能差異的原因，并考慮將來的系統(tǒng)應(yīng)該從這兩種架構(gòu)中吸取優(yōu)勢(shì)。摘要目前有相當(dāng)大的興趣在基于MapReduce（MR）模式的ABSTRACT：ThereiscurrentlyconsiderableenthusiasmaroundtheMapReduce(MR)paradigmforlarge-scaledataanalysis.Althoughthebasiccontrol?owofthisframeworkhasexistedinparallelSQLdatabasemanagementsystems(DBMS)forover20years,somehavecalledMRadramaticallynewcomputingmodel.Inthispaper,wedescribeandcomparebothparadigms.Furthermore,weevaluatebothkindsofsystemsintermsofperformanceanddevelopmentcomplexity.Tothisend,wede?neabenchmarkconsistingofacollectionoftasksthatwehaverunonanopensourceversionofMRaswellasontwoparallelDBMSs.Foreachtask,wemeasureeachsystem’sperformanceforvariousdegreesofparallelismonaclusterof100nodes.Ourresultsrevealsomeinterestingtrade-offs.AlthoughtheprocesstoloaddataintoandtunetheexecutionofparallelDBMSstookmuchlongerthantheMRsystem,theobservedperformanceoftheseDBMSswasstrikinglybetter.Wespeculateaboutthecausesofthedramaticperformancedifferenceandconsiderimplementationconceptsthatfuturesystemsshouldtakefrombothkindsofarchitectures.ABSTRACT：Thereiscurrentlyco1引言本文主要目的是如何在Hadoop、DBMS-X、Vertica中取舍和選擇。第二部分主要介紹大規(guī)模數(shù)據(jù)分析的兩種方法，Mapreduce和并行數(shù)據(jù)庫管理系統(tǒng)。第三部分主要介紹系統(tǒng)架構(gòu)，包括支持的數(shù)據(jù)格式、索引、編程模型等。第四部分主要是基準(zhǔn)測(cè)試，在100個(gè)節(jié)點(diǎn)集群上運(yùn)行幾個(gè)任務(wù)來測(cè)試Mapreduce，DBMS-X，Vertica。對(duì)100個(gè)節(jié)點(diǎn)上測(cè)試有沒有代表性進(jìn)行解釋：eBay的TeraData配置使用72個(gè)節(jié)點(diǎn)（兩個(gè)四核CPU，32GB內(nèi)存，104個(gè)300GB磁盤）管理2.4PB的關(guān)系型數(shù)據(jù)；Fox互動(dòng)媒體倉庫運(yùn)行在40個(gè)節(jié)點(diǎn)的GreenplumDBMS上（SunX4500機(jī)器，兩個(gè)雙核CPU，48個(gè)500GB的硬盤，16GB內(nèi)存，1PB的總磁盤空間）。1引言本文主要目的是如何在Hadoop、DBMS-X、Ver2兩種大規(guī)模數(shù)據(jù)分析方法

兩種方法都是通過把數(shù)據(jù)分塊，分配給不同的節(jié)點(diǎn)實(shí)現(xiàn)并行化處理。本節(jié)概述Mapreduce和并行數(shù)據(jù)庫管理系統(tǒng)。2兩種大規(guī)模數(shù)據(jù)分析方法兩種方法都是通過把數(shù)據(jù)分塊，分配2.1MapreduceMapreduce最吸引人的地方是編程模型簡(jiǎn)單。MR包含兩個(gè)函數(shù)Map和Reduce，用來處理鍵/值數(shù)據(jù)對(duì)。數(shù)據(jù)被分塊存儲(chǔ)在部署在每個(gè)節(jié)點(diǎn)上的分布式文件系統(tǒng)中。程序載入分布式處理框架然后執(zhí)行。具體過程如下：Map函數(shù)從輸入文件中讀入一系列記錄，然后以鍵/值對(duì)的形式輸出一系列中間記錄。Map函數(shù)使這些中間值最終產(chǎn)生R個(gè)輸出鍵/值對(duì)文件，具有相同值的輸出記錄存儲(chǔ)在一個(gè)輸出文件下。Reduce函數(shù)總結(jié)Map階段具有相同值的輸出記錄。最終結(jié)果寫入到新文件。

2.1MapreduceMapreduce最吸引人的地方是編2.2并行數(shù)據(jù)庫管理系統(tǒng)并行數(shù)據(jù)庫執(zhí)行的兩個(gè)關(guān)鍵方面是（1）大部分表分割到集群的節(jié)點(diǎn)上（2）系統(tǒng)使用優(yōu)化器把SQL命令轉(zhuǎn)化成查詢計(jì)劃，使其在多個(gè)節(jié)點(diǎn)上執(zhí)行。因?yàn)槌绦騿T只需用高級(jí)語言中具體化他們的目標(biāo)，所以無需關(guān)注底層存儲(chǔ)細(xì)節(jié)。SQL命令執(zhí)行過程分三步：首先過濾子查詢?cè)诠?jié)點(diǎn)上并行執(zhí)行，如map函數(shù)。接著根據(jù)數(shù)據(jù)表的大小選用一種并行連接算法。最后把每個(gè)節(jié)點(diǎn)的答案聚焦輸出。乍一看，兩種方法的數(shù)據(jù)分析和處理有很多共同點(diǎn)，下一節(jié)講差異。2.2并行數(shù)據(jù)庫管理系統(tǒng)并行數(shù)據(jù)庫執(zhí)行的兩個(gè)關(guān)鍵方面是（1）3架構(gòu)元素Architectureelements3.1架構(gòu)支持SchemasupportMR適合少數(shù)程序員和有限應(yīng)用領(lǐng)域的開發(fā)環(huán)境，由于這種限制，不適合長期的大項(xiàng)目。并行數(shù)據(jù)庫管理系統(tǒng)要求數(shù)據(jù)滿足行和列的關(guān)系范式。而MR對(duì)數(shù)據(jù)的結(jié)構(gòu)無要求。3.2索引Indexing現(xiàn)代數(shù)據(jù)庫系統(tǒng)都使用哈希或二叉樹索引加速訪問數(shù)據(jù)。MR不提供內(nèi)嵌索引，程序員需要在應(yīng)用程序中添加。3架構(gòu)元素Architectureelements3.3.3編程模型關(guān)系型數(shù)據(jù)庫系統(tǒng)，程序用高級(jí)語言寫，容易讀寫和修改。MR使用低級(jí)語言執(zhí)行記錄集操作，引入現(xiàn)象過程語言編程。為減輕執(zhí)行重復(fù)任務(wù)，把高級(jí)語言遷移到當(dāng)前接口，如數(shù)據(jù)倉庫工具Hive和分析大規(guī)模數(shù)據(jù)平臺(tái)Pig。3.4數(shù)據(jù)分發(fā)Datadistribution并行數(shù)據(jù)庫系統(tǒng)使用并行查詢優(yōu)化器平衡計(jì)算工作量，最小化數(shù)據(jù)在網(wǎng)絡(luò)中的傳輸。除了最初決定把Map實(shí)例安排在哪個(gè)節(jié)點(diǎn)，MR程序員需要手動(dòng)執(zhí)行其他的任務(wù)。3.3編程模型3.5執(zhí)行策略MR處理Map和Reducejob之間傳輸有一個(gè)很嚴(yán)重的性能問題。Reduce階段，不可避免的，兩個(gè)或更多的reduce實(shí)例通過文件傳輸協(xié)議pull同時(shí)從一個(gè)map節(jié)點(diǎn)讀取輸入文件，減慢有效的磁盤傳輸速率.并行數(shù)據(jù)庫系統(tǒng)不分塊文件，采用推送方式push代替pull。3.6靈活性由于SQL表達(dá)能力不足，新的應(yīng)用程序框架開始扭轉(zhuǎn)這種局面，通過利用新的編程語言功能來實(shí)現(xiàn)對(duì)象-關(guān)系映射模式。由于數(shù)據(jù)庫管理系統(tǒng)的健壯性，使開發(fā)者減輕寫復(fù)雜SQL的負(fù)擔(dān)。雖然沒有MR完全的一般性，但數(shù)據(jù)庫管理系統(tǒng)現(xiàn)在提供的支持用戶自定義函數(shù)，存儲(chǔ)過程，在SQL中聚合等，也提高了靈活性。3.5執(zhí)行策略3.7容錯(cuò)性MR更善于處理執(zhí)行MR計(jì)算過程中節(jié)點(diǎn)失敗。如果一個(gè)節(jié)點(diǎn)失敗，MR調(diào)度器會(huì)在另外一個(gè)節(jié)點(diǎn)上重啟這個(gè)任務(wù)。如果一個(gè)節(jié)點(diǎn)失敗，數(shù)據(jù)庫管理系統(tǒng)整個(gè)查詢必須完全重新啟動(dòng)。3.7容錯(cuò)性4基準(zhǔn)的性能Performancebenchmarks使用包含5個(gè)任務(wù)的基準(zhǔn)來比較MR和并行數(shù)據(jù)庫系統(tǒng)的性能。第一個(gè)任務(wù)是論文【8】中的文章作者認(rèn)為有代表性的實(shí)驗(yàn)。另外四個(gè)任務(wù)是更復(fù)雜的分析工作負(fù)載。在知名的MR（Hadoop）和兩個(gè)并行數(shù)據(jù)庫管理系統(tǒng)(DBMS-XVwrtica)上執(zhí)行基準(zhǔn)。4基準(zhǔn)的性能Performancebenchmarks4.1基準(zhǔn)環(huán)境Benchmarkenvironment4.1.1測(cè)試系統(tǒng)Hadoop0.19.0Java1.6.0默認(rèn)配置，除了數(shù)據(jù)塊大小改為256M，JVMheapsize1024M（每個(gè)節(jié)點(diǎn)3.5G），每個(gè)節(jié)點(diǎn)上運(yùn)行2個(gè)map實(shí)例和1個(gè)reduce實(shí)例。DBMS-X系統(tǒng)安裝在每個(gè)節(jié)點(diǎn)上，配置4GB內(nèi)存段用于緩沖池和臨時(shí)空間。數(shù)據(jù)以行的格式存儲(chǔ)，每個(gè)表哈希分到各個(gè)節(jié)點(diǎn)，然后根據(jù)不同的屬性排序和索引。Vertica是為大型數(shù)據(jù)倉庫設(shè)計(jì)的，以列的格式存儲(chǔ)，默認(rèn)壓縮數(shù)據(jù)，因?yàn)閳?zhí)行器可直接操作壓縮數(shù)據(jù)，本文的結(jié)果是執(zhí)行壓縮數(shù)據(jù)產(chǎn)生的。4.1基準(zhǔn)環(huán)境Benchmarkenvironment節(jié)點(diǎn)配置三個(gè)系統(tǒng)都部署在100臺(tái)機(jī)子的集群，每個(gè)節(jié)點(diǎn)CPU2.4GHzintelcore2操作系統(tǒng)64位redhatenterpriselinux5內(nèi)存4G硬盤2個(gè)250GSATA-I.交換機(jī)128Gbps50個(gè)節(jié)點(diǎn)一臺(tái)交換機(jī)。4.1.3基準(zhǔn)執(zhí)行每個(gè)系統(tǒng)執(zhí)行基準(zhǔn)任務(wù)三次取平均，先在一個(gè)節(jié)點(diǎn)上執(zhí)行每個(gè)任務(wù)，然后在不同的集群數(shù)量上執(zhí)行不同的數(shù)據(jù)大小。還測(cè)量了每個(gè)系統(tǒng)加載數(shù)據(jù)的時(shí)間。由于MR每個(gè)reduce輸出一個(gè)文件，而數(shù)據(jù)庫管理系統(tǒng)總共輸出一個(gè)文件，在HDFS中執(zhí)行一個(gè)額外的reduce函數(shù)來結(jié)合成一個(gè)文件再輸出。

4.1.2節(jié)點(diǎn)配置4.2原始的MR任務(wù)TheoriginalMRtask第一個(gè)基準(zhǔn)任務(wù)是文獻(xiàn)【8】中的Greptask作者認(rèn)為具有代表性的大數(shù)據(jù)集MR程序，這個(gè)任務(wù)是在100位記錄的數(shù)據(jù)集尋找三個(gè)特征模式，每個(gè)記錄中在前十位中包含一個(gè)唯一的鍵，后90位是隨機(jī)的值。Greptask在1,10,25,50,100個(gè)節(jié)點(diǎn)上分別執(zhí)行。4.2原始的MR任務(wù)TheoriginalMRtask4.2.1數(shù)據(jù)加載加載535M/node和1T/node如下圖，對(duì)于DBMS-X，下半段是執(zhí)行加載命令時(shí)間，上半段是重組過程。Hadoop性能明顯好。4.2.1數(shù)據(jù)加載Hadoop性能明顯好。4.2.2任務(wù)執(zhí)行三個(gè)系統(tǒng)的性能結(jié)果如下。Hadoop上半段是MRjob把輸出文件結(jié)合成一個(gè)的時(shí)間。下半段是執(zhí)行任務(wù)時(shí)間。對(duì)于每個(gè)節(jié)點(diǎn)535M，DBMS-X和Vertica性能差不多；對(duì)于每個(gè)節(jié)點(diǎn)1T，DBMS-X和Hadoop性能差不多。4.2.2任務(wù)執(zhí)行對(duì)于每個(gè)節(jié)點(diǎn)535M，DBMS-X和Ver4.3分析任務(wù)為了探索處理更復(fù)雜的應(yīng)用，開發(fā)四個(gè)關(guān)于HTML文檔處理的任務(wù)。每個(gè)節(jié)點(diǎn)分配6000個(gè)HTML文檔，還自己利用產(chǎn)生器創(chuàng)造2個(gè)數(shù)據(jù)集，1.55億UserVisits記錄，每個(gè)節(jié)點(diǎn)20G，1800萬Ranking記錄，每個(gè)節(jié)點(diǎn)1G。4.3.1數(shù)據(jù)加載由于加載UserVisits與Ranking數(shù)據(jù)集是相似的，只提供數(shù)據(jù)集較大的UserVisits的加載。節(jié)點(diǎn)數(shù)越多，相比較Hadoop性能越好。4.3分析任務(wù)為了探索處理更復(fù)雜的應(yīng)用，開發(fā)四個(gè)關(guān)于HTM4.3.2選擇任務(wù)選擇任務(wù)是輕量級(jí)過濾器在Rinkings表(1G/節(jié)點(diǎn))中尋找pageURLs。設(shè)置臨界參數(shù)為10，每個(gè)節(jié)點(diǎn)上每個(gè)數(shù)據(jù)文件大約產(chǎn)生36000條記錄。結(jié)果如下，隨著數(shù)據(jù)量增大，Hadoop影響最大。Vertica性能較好。4.3.2選擇任務(wù)隨著數(shù)據(jù)量增大，Hadoop影響最大。Ve4.3.3聚集任務(wù)Aggregationtask要求每個(gè)系統(tǒng)計(jì)算在UserVisits表中生成每個(gè)源IP總收益數(shù)（20GB/節(jié)點(diǎn)）。任務(wù)分別產(chǎn)生250萬（53M）和2000(24K)組記錄當(dāng)組數(shù)量大時(shí)，Vertica和DBMS-X性能差不多；當(dāng)組數(shù)量小時(shí)，Vertica性能較好。4.3.3聚集任務(wù)Aggregationtask當(dāng)組數(shù)量大4.3.4聯(lián)合任務(wù)JoinTask加入任務(wù)包括兩個(gè)子任務(wù)來進(jìn)行兩組數(shù)據(jù)的復(fù)雜計(jì)算。首先，每個(gè)系統(tǒng)找出在特定時(shí)間內(nèi)產(chǎn)生最大收益的源IP，一旦這些中間記錄產(chǎn)生時(shí)，系統(tǒng)必須計(jì)算在此間隔期間的所有網(wǎng)頁訪問的平均PageRank。實(shí)驗(yàn)中使用表UserVisits1月15日至22日，2000年，約13.4萬記錄相匹配。Vertica和DBMS-X性能差不多。4.3.4聯(lián)合任務(wù)JoinTask加入任務(wù)包括兩個(gè)子任務(wù)4.3.5UDF的聚集任務(wù)UDFAggregationTask任務(wù)是計(jì)算數(shù)據(jù)集中每個(gè)文檔的inlink，這個(gè)任務(wù)經(jīng)常作為PageRank計(jì)算的一個(gè)組件。具體來說，這項(xiàng)任務(wù)時(shí)，系統(tǒng)必須讀取每個(gè)文件的內(nèi)容和搜索內(nèi)容中出現(xiàn)的所有URL，然后針對(duì)每個(gè)唯一的URL，計(jì)算唯一網(wǎng)頁的數(shù)量。Vertica性能比較好。節(jié)點(diǎn)數(shù)越多，BMS-X查詢的時(shí)間相比較增長更快。Vertica和DBMS-X的下面部分代表執(zhí)行UDF/分析和加載數(shù)據(jù)到表中的時(shí)間，上面部分是執(zhí)行真正查詢的時(shí)間。4.3.5UDF的聚集任務(wù)UDFAggregation結(jié)論平均在100個(gè)節(jié)點(diǎn)上運(yùn)行這5個(gè)任務(wù)，DBMS-X比MR快3.2倍，Vertica比DBMS-X快2.3倍。估計(jì)在1000個(gè)節(jié)點(diǎn)上，性能也差不多。結(jié)論平均在100個(gè)節(jié)點(diǎn)上運(yùn)行這5個(gè)任務(wù)，DBMS-X比MR快謝謝！謝謝！大規(guī)模數(shù)據(jù)分析方法對(duì)比

AComparisonofApproachestoLarge-ScaleDataAnalysis大規(guī)模數(shù)據(jù)分析方法對(duì)比

AComparisonofAp作者1：AndrewPavlo，BrownUniversity1MapReduceandparallelDBMSs:friendsorfoes?

朋友還是冤家2Acomparisonofapproachestolarge-scaledataanalysis

3H-store:ahigh-performance,distributedmainmemorytransactionprocessingsystem

4TheNMIbuild&testlaboratory:continuousintegrationframeworkfordistributedcomputingsoftware5Smoothertransitionsbetweenbreadth-first-spanning-tree-baseddrawings主要做Hadoop(Mapreduce)和并行數(shù)據(jù)庫管理系統(tǒng)比較，用于大規(guī)模數(shù)據(jù)集分析。作者簡(jiǎn)介作者1：AndrewPavlo，BrownUniver作者2ErikPaulson，

UniversityofWisconsin1MapReduceandparallelDBMSs:friendsorfoes?2Acomparisonofapproachestolarge-scaledataanalysis3Clustera:anintegratedcomputationanddatamanagementsystem 和第一作者一樣，主要做Hadoop(Mapreduce)和并行數(shù)據(jù)庫管理系統(tǒng)比較，用于大規(guī)模數(shù)據(jù)集分析。作者2ErikPaulson，University作者3AlexanderRasin，BrownUniversity1CORADD:correlationawaredatabasedesignerformaterializedviewsandindexes2MapReduceandparallelDBMSs:friendsorfoes?3HadoopDB:anarchitecturalhybridofMapReduceandDBMStechnologiesforanalyticalworkloads4Correlationmaps:acompressedaccessmethodforexploitingsoftfunctionaldependencies5Acomparisonofapproachestolarge-scaledataanalysis6H-store:ahigh-performance,distributedmainmemorytransactionprocessingsystem

作者在本文的基礎(chǔ)上，設(shè)計(jì)了HadoopDB系統(tǒng)，一個(gè)Mapreduce和并行數(shù)據(jù)庫管理系統(tǒng)結(jié)合的系統(tǒng)。作者3AlexanderRasin，BrownUni摘要目前有相當(dāng)大的興趣在基于MapReduce（MR）模式的大規(guī)模數(shù)據(jù)分析。雖然這個(gè)框架的基本控制流已經(jīng)存在于并行SQL數(shù)據(jù)庫管理系統(tǒng)超過20年，也有人稱MR為最新的計(jì)算模型。在本文中，我們描述和比較這兩個(gè)模式。此外，我們?cè)u(píng)估兩個(gè)系統(tǒng)的性能和開發(fā)復(fù)雜度。最后，我們定義一個(gè)包含任務(wù)集的基準(zhǔn)運(yùn)行于MR開源平臺(tái)和兩個(gè)并行數(shù)據(jù)庫管理系統(tǒng)上。對(duì)于每個(gè)任務(wù)，我們?cè)?00臺(tái)機(jī)子的集群上衡量每個(gè)系統(tǒng)的各個(gè)方面的并行性能。我們的研究結(jié)果揭示了一些有趣的取舍。雖然加載數(shù)據(jù)和調(diào)整并行數(shù)據(jù)庫管理系統(tǒng)執(zhí)行的過程比MR花費(fèi)更多的時(shí)間，但是觀察到的這些數(shù)據(jù)庫管理系統(tǒng)性能顯著地改善。我們推測(cè)巨大的性能差異的原因，并考慮將來的系統(tǒng)應(yīng)該從這兩種架構(gòu)中吸取優(yōu)勢(shì)。摘要目前有相當(dāng)大的興趣在基于MapReduce（MR）模式的ABSTRACT：ThereiscurrentlyconsiderableenthusiasmaroundtheMapReduce(MR)paradigmforlarge-scaledataanalysis.Althoughthebasiccontrol?owofthisframeworkhasexistedinparallelSQLdatabasemanagementsystems(DBMS)forover20years,somehavecalledMRadramaticallynewcomputingmodel.Inthispaper,wedescribeandcomparebothparadigms.Furthermore,weevaluatebothkindsofsystemsintermsofperformanceanddevelopmentcomplexity.Tothisend,wede?neabenchmarkconsistingofacollectionoftasksthatwehaverunonanopensourceversionofMRaswellasontwoparallelDBMSs.Foreachtask,wemeasureeachsystem’sperformanceforvariousdegreesofparallelismonaclusterof100nodes.Ourresultsrevealsomeinterestingtrade-offs.AlthoughtheprocesstoloaddataintoandtunetheexecutionofparallelDBMSstookmuchlongerthantheMRsystem,theobservedperformanceoftheseDBMSswasstrikinglybetter.Wespeculateaboutthecausesofthedramaticperformancedifferenceandconsiderimplementationconceptsthatfuturesystemsshouldtakefrombothkindsofarchitectures.ABSTRACT：Thereiscurrentlyco1引言本文主要目的是如何在Hadoop、DBMS-X、Vertica中取舍和選擇。第二部分主要介紹大規(guī)模數(shù)據(jù)分析的兩種方法，Mapreduce和并行數(shù)據(jù)庫管理系統(tǒng)。第三部分主要介紹系統(tǒng)架構(gòu)，包括支持的數(shù)據(jù)格式、索引、編程模型等。第四部分主要是基準(zhǔn)測(cè)試，在100個(gè)節(jié)點(diǎn)集群上運(yùn)行幾個(gè)任務(wù)來測(cè)試Mapreduce，DBMS-X，Vertica。對(duì)100個(gè)節(jié)點(diǎn)上測(cè)試有沒有代表性進(jìn)行解釋：eBay的TeraData配置使用72個(gè)節(jié)點(diǎn)（兩個(gè)四核CPU，32GB內(nèi)存，104個(gè)300GB磁盤）管理2.4PB的關(guān)系型數(shù)據(jù)；Fox互動(dòng)媒體倉庫運(yùn)行在40個(gè)節(jié)點(diǎn)的GreenplumDBMS上（SunX4500機(jī)器，兩個(gè)雙核CPU，48個(gè)500GB的硬盤，16GB內(nèi)存，1PB的總磁盤空間）。1引言本文主要目的是如何在Hadoop、DBMS-X、Ver2兩種大規(guī)模數(shù)據(jù)分析方法

兩種方法都是通過把數(shù)據(jù)分塊，分配給不同的節(jié)點(diǎn)實(shí)現(xiàn)并行化處理。本節(jié)概述Mapreduce和并行數(shù)據(jù)庫管理系統(tǒng)。2兩種大規(guī)模數(shù)據(jù)分析方法兩種方法都是通過把數(shù)據(jù)分塊，分配2.1MapreduceMapreduce最吸引人的地方是編程模型簡(jiǎn)單。MR包含兩個(gè)函數(shù)Map和Reduce，用來處理鍵/值數(shù)據(jù)對(duì)。數(shù)據(jù)被分塊存儲(chǔ)在部署在每個(gè)節(jié)點(diǎn)上的分布式文件系統(tǒng)中。程序載入分布式處理框架然后執(zhí)行。具體過程如下：Map函數(shù)從輸入文件中讀入一系列記錄，然后以鍵/值對(duì)的形式輸出一系列中間記錄。Map函數(shù)使這些中間值最終產(chǎn)生R個(gè)輸出鍵/值對(duì)文件，具有相同值的輸出記錄存儲(chǔ)在一個(gè)輸出文件下。Reduce函數(shù)總結(jié)Map階段具有相同值的輸出記錄。最終結(jié)果寫入到新文件。

2.1MapreduceMapreduce最吸引人的地方是編2.2并行數(shù)據(jù)庫管理系統(tǒng)并行數(shù)據(jù)庫執(zhí)行的兩個(gè)關(guān)鍵方面是（1）大部分表分割到集群的節(jié)點(diǎn)上（2）系統(tǒng)使用優(yōu)化器把SQL命令轉(zhuǎn)化成查詢計(jì)劃，使其在多個(gè)節(jié)點(diǎn)上執(zhí)行。因?yàn)槌绦騿T只需用高級(jí)語言中具體化他們的目標(biāo)，所以無需關(guān)注底層存儲(chǔ)細(xì)節(jié)。SQL命令執(zhí)行過程分三步：首先過濾子查詢?cè)诠?jié)點(diǎn)上并行執(zhí)行，如map函數(shù)。接著根據(jù)數(shù)據(jù)表的大小選用一種并行連接算法。最后把每個(gè)節(jié)點(diǎn)的答案聚焦輸出。乍一看，兩種方法的數(shù)據(jù)分析和處理有很多共同點(diǎn)，下一節(jié)講差異。2.2并行數(shù)據(jù)庫管理系統(tǒng)并行數(shù)據(jù)庫執(zhí)行的兩個(gè)關(guān)鍵方面是（1）3架構(gòu)元素Architectureelements3.1架構(gòu)支持SchemasupportMR適合少數(shù)程序員和有限應(yīng)用領(lǐng)域的開發(fā)環(huán)境，由于這種限制，不適合長期的大項(xiàng)目。并行數(shù)據(jù)庫管理系統(tǒng)要求數(shù)據(jù)滿足行和列的關(guān)系范式。而MR對(duì)數(shù)據(jù)的結(jié)構(gòu)無要求。3.2索引Indexing現(xiàn)代數(shù)據(jù)庫系統(tǒng)都使用哈?；蚨鏄渌饕铀僭L問數(shù)據(jù)。MR不提供內(nèi)嵌索引，程序員需要在應(yīng)用程序中添加。3架構(gòu)元素Architectureelements3.3.3編程模型關(guān)系型數(shù)據(jù)庫系統(tǒng)，程序用高級(jí)語言寫，容易讀寫和修改。MR使用低級(jí)語言執(zhí)行記錄集操作，引入現(xiàn)象過程語言編程。為減輕執(zhí)行重復(fù)任務(wù)，把高級(jí)語言遷移到當(dāng)前接口，如數(shù)據(jù)倉庫工具Hive和分析大規(guī)模數(shù)據(jù)平臺(tái)Pig。3.4數(shù)據(jù)分發(fā)Datadistribution并行數(shù)據(jù)庫系統(tǒng)使用并行查詢優(yōu)化器平衡計(jì)算工作量，最小化數(shù)據(jù)在網(wǎng)絡(luò)中的傳輸。除了最初決定把Map實(shí)例安排在哪個(gè)節(jié)點(diǎn)，MR程序員需要手動(dòng)執(zhí)行其他的任務(wù)。3.3編程模型3.5執(zhí)行策略MR處理Map和Reducejob之間傳輸有一個(gè)很嚴(yán)重的性能問題。Reduce階段，不可避免的，兩個(gè)或更多的reduce實(shí)例通過文件傳輸協(xié)議pull同時(shí)從一個(gè)map節(jié)點(diǎn)讀取輸入文件，減慢有效的磁盤傳輸速率.并行數(shù)據(jù)庫系統(tǒng)不分塊文件，采用推送方式push代替pull。3.6靈活性由于SQL表達(dá)能力不足，新的應(yīng)用程序框架開始扭轉(zhuǎn)這種局面，通過利用新的編程語言功能來實(shí)現(xiàn)對(duì)象-關(guān)系映射模式。由于數(shù)據(jù)庫管理系統(tǒng)的健壯性，使開發(fā)者減輕寫復(fù)雜SQL的負(fù)擔(dān)。雖然沒有MR完全的一般性，但數(shù)據(jù)庫管理系統(tǒng)現(xiàn)在提供的支持用戶自定義函數(shù)，存儲(chǔ)過程，在SQL中聚合等，也提高了靈活性。3.5執(zhí)行策略3.7容錯(cuò)性MR更善于處理執(zhí)行MR計(jì)算過程中節(jié)點(diǎn)失敗。如果一個(gè)節(jié)點(diǎn)失敗，MR調(diào)度器會(huì)在另外一個(gè)節(jié)點(diǎn)上重啟這個(gè)任務(wù)。如果一個(gè)節(jié)點(diǎn)失敗，數(shù)據(jù)庫管理系統(tǒng)整個(gè)查詢必須完全重新啟動(dòng)。3.7容錯(cuò)性4基準(zhǔn)的性能Performancebenchmarks使用包含5個(gè)任務(wù)的基準(zhǔn)來比較MR和并行數(shù)據(jù)庫系統(tǒng)的性能。第一個(gè)任務(wù)是論文【8】中的文章作者認(rèn)為有代表性的實(shí)驗(yàn)。另外四個(gè)任務(wù)是更復(fù)雜的分析工作負(fù)載。在知名的MR（Hadoop）和兩個(gè)并行數(shù)據(jù)庫管理系統(tǒng)(DBMS-XVwrtica)上執(zhí)行基準(zhǔn)。4基準(zhǔn)的性能Performancebenchmarks4.1基準(zhǔn)環(huán)境Benchmarkenvironment4.1.1測(cè)試系統(tǒng)Hadoop0.19.0Java1.6.0默認(rèn)配置，除了數(shù)據(jù)塊大小改為256M，JVMheapsize1024M（每個(gè)節(jié)點(diǎn)3.5G），每個(gè)節(jié)點(diǎn)上運(yùn)行2個(gè)map實(shí)例和1個(gè)reduce實(shí)例。DBMS-X系統(tǒng)安裝在每個(gè)節(jié)點(diǎn)上，配置4GB內(nèi)存段用于緩沖池和臨時(shí)空間。數(shù)據(jù)以行的格式存儲(chǔ)，每個(gè)表哈希分到各個(gè)節(jié)點(diǎn)，然后根據(jù)不同的屬性排序和索引。Vertica是為大型數(shù)據(jù)倉庫設(shè)計(jì)的，以列的格式存儲(chǔ)，默認(rèn)壓縮數(shù)據(jù)，因?yàn)閳?zhí)行器可直接操作壓縮數(shù)據(jù)，本文的結(jié)果是執(zhí)行壓縮數(shù)據(jù)產(chǎn)生的。4.1基準(zhǔn)環(huán)境Benchmarkenvironment節(jié)點(diǎn)配置三個(gè)系統(tǒng)都部署在100臺(tái)機(jī)子的集群，每個(gè)節(jié)點(diǎn)CPU2.4GHzintelcore2操作系統(tǒng)64位redhatenterpriselinux5內(nèi)存4G硬盤2個(gè)250GSATA-I.交換機(jī)128Gbps50個(gè)節(jié)點(diǎn)一臺(tái)交換機(jī)。4.1.3基準(zhǔn)執(zhí)行每個(gè)系統(tǒng)執(zhí)行基準(zhǔn)任務(wù)三次取平均，先在一個(gè)節(jié)點(diǎn)上執(zhí)行每個(gè)任務(wù)，然后在不同的集群數(shù)量上執(zhí)行不同的數(shù)據(jù)大小。還測(cè)量了每個(gè)系統(tǒng)加載數(shù)據(jù)的時(shí)間。由于MR每個(gè)reduce輸出一個(gè)文件，而數(shù)據(jù)庫管理系統(tǒng)總共輸出一個(gè)文件，在HDFS中執(zhí)行一個(gè)額外的reduce函數(shù)來結(jié)合成一個(gè)文件再輸出。

4.1.2節(jié)點(diǎn)配置4.2原始的MR任務(wù)TheoriginalMRtask第一個(gè)基準(zhǔn)任務(wù)是文獻(xiàn)【8】中的Greptask作者認(rèn)為具有代表性的大數(shù)據(jù)集MR程序，這個(gè)任務(wù)是在100位記錄的數(shù)據(jù)集尋找三個(gè)特征模式，每個(gè)記錄中在前十位中包含一個(gè)唯一的鍵，后90位是隨機(jī)的值。Greptask在1,10,25,50,100個(gè)節(jié)點(diǎn)上分別執(zhí)行。4.2原始的MR任務(wù)TheoriginalMRtask4.2.1數(shù)據(jù)加載加載535M/node和1T/node如下圖