《《數(shù)據(jù)分析》PPT課件》由會(huì)員分享，可在線閱讀，更多相關(guān)《《數(shù)據(jù)分析》PPT課件（27頁(yè)珍藏版）》請(qǐng)?jiān)谘b配圖網(wǎng)上搜索。

1、大規(guī)模數(shù)據(jù)分析方法對(duì)比A Comparison of Approaches to Large-Scale Data Analysis 作者1：Andrew Pavlo ，Brown University 1 MapReduce and parallel DBMSs: friends or foes? 朋友還是冤家 2 A comparison of approaches to large-scale data analysis 3 H-store: a high-performance, distributed main memory transaction processing system

2、 4 The NMI build & test laboratory: continuous integration framework for distributed computing software 5 Smoother transitions between breadth-first-spanning-tree-based drawings主 要 做 Hadoop(Mapreduce)和 并 行 數(shù) 據(jù) 庫(kù) 管 理 系 統(tǒng) 比 較 ，用 于 大 規(guī) 模 數(shù) 據(jù) 集 分 析 。作者簡(jiǎn)介 作者2 Erik Paulson， University of Wisconsin 1 MapRe

3、duce and parallel DBMSs: friends or foes? 2 A comparison of approaches to large-scale data analysis 3 Clustera: an integrated computation and data management system和第一作者一樣，主 要 做 Hadoop(Mapreduce)和 并 行 數(shù) 據(jù) 庫(kù) 管 理 系 統(tǒng)比 較 ， 用 于 大 規(guī) 模 數(shù) 據(jù) 集 分 析 。 作者3 Alexander Rasin ，Brown University 1 CORADD: correlatio

4、n aware database designer for materialized views and indexes 2 MapReduce and parallel DBMSs: friends or foes? 3 HadoopDB: an architectural hybrid of MapReduce and DBMS technologies for analytical workloads 4 Correlation maps: a compressed access method for exploiting soft functional dependencies 5 A

5、 comparison of approaches to large-scale data analysis 6 H-store: a high-performance, distributed main memory transaction processing system 作者在本文的基礎(chǔ)上，設(shè)計(jì)了HadoopDB系統(tǒng)，一個(gè)Mapreduce和并行數(shù)據(jù)庫(kù)管理系統(tǒng)結(jié)合的系統(tǒng)。 摘要目前有相當(dāng)大的興趣在基于MapReduce（MR）模式的大規(guī)模數(shù)據(jù)分析。雖然這個(gè)框架的基本控制流已經(jīng)存在于并行SQL數(shù)據(jù)庫(kù)管理系統(tǒng)超過(guò)20年，也有人稱MR為最新的計(jì)算模型。在本文中，我們描述和比較這兩個(gè)模式。此外

6、，我們?cè)u(píng)估兩個(gè)系統(tǒng)的性能和開(kāi)發(fā)復(fù)雜度。最后，我們定義一個(gè)包含任務(wù)集的基準(zhǔn)運(yùn)行于MR開(kāi)源平臺(tái)和兩個(gè)并行數(shù)據(jù)庫(kù)管理系統(tǒng)上。對(duì)于每個(gè)任務(wù)，我們?cè)?00臺(tái)機(jī)子的集群上衡量每個(gè)系統(tǒng)的各個(gè)方面的并行性能。我們的研究結(jié)果揭示了一些有趣的取舍。雖然加載數(shù)據(jù)和調(diào)整并行數(shù)據(jù)庫(kù)管理系統(tǒng)執(zhí)行的過(guò)程比MR花費(fèi)更多的時(shí)間，但是觀察到的這些數(shù)據(jù)庫(kù)管理系統(tǒng)性能顯著地改善。我們推測(cè)巨大的性能差異的原因，并考慮將來(lái)的系統(tǒng)應(yīng)該從這兩種架構(gòu)中吸取優(yōu)勢(shì)。 ABSTRACT：There is currently considerable enthusiasm around the MapReduce (MR) paradigm for

7、large-scale data analysis. Although the basic control ow of this framework has existed in parallel SQL database management systems (DBMS) for over 20 years, some have called MR a dramatically new computing model. In this paper, we describe and compare both paradigms. Furthermore, we evaluate both ki

8、nds of systems in terms of performance and development complexity. To this end, we dene a benchmark consisting of a collection of tasks that we have run on an open source version of MR as well as on two parallel DBMSs. For each task, we measure each systems performance for various degrees of paralle

9、lism on a cluster of 100 nodes. Our results reveal some interesting trade-offs. Although the process to load data into and tune the execution of parallel DBMSs took much longer than the MR system, the observed performance of these DBMSs was strikingly better. We speculate about the causes of the dra

10、matic performance difference and consider implementation concepts that future systems should take from both kinds of architectures. 1引言本文主要目的是如何在Hadoop、DBMS-X、Vertica中取舍和選擇。第二部分主要介紹大規(guī)模數(shù)據(jù)分析的兩種方法，Mapreduce和并行數(shù)據(jù)庫(kù)管理系統(tǒng)。第三部分主要介紹系統(tǒng)架構(gòu)，包括支持的數(shù)據(jù)格式、索引、編程模型等。第四部分主要是基準(zhǔn)測(cè)試，在100個(gè)節(jié)點(diǎn)集群上運(yùn)行幾個(gè)任務(wù)來(lái)測(cè)試Mapreduce，DBMS-X，Vertic

11、a。對(duì)100個(gè)節(jié)點(diǎn)上測(cè)試有沒(méi)有代表性進(jìn)行解釋：eBay 的TeraData配置使用72個(gè)節(jié)點(diǎn)（兩個(gè)四核CPU，32GB內(nèi)存，104個(gè)300GB磁盤(pán)）管理2.4PB的關(guān)系型數(shù)據(jù)；Fox互動(dòng)媒體倉(cāng)庫(kù)運(yùn)行在40個(gè)節(jié)點(diǎn)的Greenplum DBMS上（Sun X4500機(jī)器，兩個(gè)雙核CPU，48個(gè)500GB的硬盤(pán)，16 GB內(nèi)存，1PB的總磁盤(pán)空間）。 2 兩種大規(guī)模數(shù)據(jù)分析方法 兩種方法都是通過(guò)把數(shù)據(jù)分塊，分配給不同的節(jié)點(diǎn)實(shí)現(xiàn)并行化處理。本節(jié)概述Mapreduce和并行數(shù)據(jù)庫(kù)管理系統(tǒng)。 2.1Mapreduce Mapreduce最吸引人的地方是編程模型簡(jiǎn)單。MR包含兩個(gè)函數(shù)Map和Reduce，用

12、來(lái)處理鍵/值數(shù)據(jù)對(duì)。數(shù)據(jù)被分塊存儲(chǔ)在部署在每個(gè)節(jié)點(diǎn)上的分布式文件系統(tǒng)中。程序載入分布式處理框架然后執(zhí)行。具體過(guò)程如下： Map函數(shù)從輸入文件中讀入一系列記錄，然后以鍵/值對(duì)的形式輸出一系列中間記錄。Map函數(shù)使這些中間值最終產(chǎn)生R個(gè)輸出鍵/值對(duì)文件，具有相同值的輸出記錄存儲(chǔ)在一個(gè)輸出文件下。 Reduce函數(shù)總結(jié)Map階段具有相同值的輸出記錄。最終結(jié)果寫(xiě)入到新文件。 2.2并行數(shù)據(jù)庫(kù)管理系統(tǒng)并行數(shù)據(jù)庫(kù)執(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í)語(yǔ)言中具體化他們的目標(biāo)，所以無(wú)需關(guān)注底層存儲(chǔ)細(xì)節(jié)。 S

13、QL命令執(zhí)行過(guò)程分三步：首先過(guò)濾子查詢?cè)诠?jié)點(diǎn)上并行執(zhí)行，如map函數(shù)。接著根據(jù)數(shù)據(jù)表的大小選用一種并行連接算法。最后把每個(gè)節(jié)點(diǎn)的答案聚焦輸出。乍一看，兩種方法的數(shù)據(jù)分析和處理有很多共同點(diǎn)，下一節(jié)講差異。 3 架構(gòu)元素 Architecture elements3.1架構(gòu)支持Schema support MR適合少數(shù)程序員和有限應(yīng)用領(lǐng)域的開(kāi)發(fā)環(huán)境，由于這種限制，不適合長(zhǎng)期的大項(xiàng)目。并行數(shù)據(jù)庫(kù)管理系統(tǒng)要求數(shù)據(jù)滿足行和列的關(guān)系范式。而MR對(duì)數(shù)據(jù)的結(jié)構(gòu)無(wú)要求。3.2索引Indexing現(xiàn)代數(shù)據(jù)庫(kù)系統(tǒng)都使用哈?；蚨鏄?shù)索引加速訪問(wèn)數(shù)據(jù)。 MR不提供內(nèi)嵌索引，程序員需要在應(yīng)用程序中添加。 3.3編程模型關(guān)

14、系型數(shù)據(jù)庫(kù)系統(tǒng)，程序用高級(jí)語(yǔ)言寫(xiě)，容易讀寫(xiě)和修改。 MR 使用低級(jí)語(yǔ)言執(zhí)行記錄集操作，引入現(xiàn)象過(guò)程語(yǔ)言編程。為減輕執(zhí)行重復(fù)任務(wù)，把高級(jí)語(yǔ)言遷移到當(dāng)前接口，如數(shù)據(jù)倉(cāng)庫(kù)工具Hive和分析大規(guī)模數(shù)據(jù)平臺(tái)Pig。 3.4數(shù)據(jù)分發(fā)Data distribution并行數(shù)據(jù)庫(kù)系統(tǒng) 使用并行查詢優(yōu)化器平衡計(jì)算工作量，最小化數(shù)據(jù)在網(wǎng)絡(luò)中的傳輸。除了最初決定把Map實(shí)例安排在哪個(gè)節(jié)點(diǎn)，MR程序員需要手動(dòng)執(zhí)行其他的任務(wù)。 3.5執(zhí)行策略 MR處理Map和Reduce job之間傳輸有一個(gè)很?chē)?yán)重的性能問(wèn)題。Reduce階段，不可避免的，兩個(gè)或更多的reduce實(shí)例通過(guò)文件傳輸協(xié)議pull同時(shí)從一個(gè)map節(jié)點(diǎn)讀取輸入

15、文件，減慢有效的磁盤(pán)傳輸速率.并行數(shù)據(jù)庫(kù)系統(tǒng)不分塊文件，采用推送方式push代替pull。3.6靈活性由于SQL表達(dá)能力不足，新的應(yīng)用程序框架開(kāi)始扭轉(zhuǎn)這種局面，通過(guò)利用新的編程語(yǔ)言功能來(lái)實(shí)現(xiàn)對(duì)象-關(guān)系映射模式。由于數(shù)據(jù)庫(kù)管理系統(tǒng)的健壯性，使開(kāi)發(fā)者減輕寫(xiě)復(fù)雜SQL的負(fù)擔(dān)。雖然沒(méi)有MR完全的一般性，但數(shù)據(jù)庫(kù)管理系統(tǒng)現(xiàn)在提供的支持用戶自定義函數(shù)，存儲(chǔ)過(guò)程，在SQL中聚合等，也提高了靈活性。 3.7容錯(cuò)性 MR更善于處理執(zhí)行MR計(jì)算過(guò)程中節(jié)點(diǎn)失敗。如果一個(gè)節(jié)點(diǎn)失敗，MR調(diào)度器會(huì)在另外一個(gè)節(jié)點(diǎn)上重啟這個(gè)任務(wù)。如果一個(gè)節(jié)點(diǎn)失敗，數(shù)據(jù)庫(kù)管理系統(tǒng)整個(gè)查詢必須完全重新啟動(dòng)。 4 基準(zhǔn)的性能 Performanc

16、e benchmarks使用包含5個(gè)任務(wù)的基準(zhǔn)來(lái)比較MR和并行數(shù)據(jù)庫(kù)系統(tǒng)的性能。第一個(gè)任務(wù)是論文【8】中的文章作者認(rèn)為有代表性的實(shí)驗(yàn)。另外四個(gè)任務(wù)是更復(fù)雜的分析工作負(fù)載。在知名的MR（Hadoop）和兩個(gè)并行數(shù)據(jù)庫(kù)管理系統(tǒng)(DBMS-X Vertica)上執(zhí)行基準(zhǔn)。 4.1基準(zhǔn)環(huán)境Benchmark environment4.1.1測(cè)試系統(tǒng) Hadoop 0.19.0 Java 1.6.0 默認(rèn)配置，除了數(shù)據(jù)塊大小改為256M，JVM heap size 1024M（每個(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)存段用

17、于緩沖池和臨時(shí)空間。數(shù)據(jù)以行的格式存儲(chǔ)，每個(gè)表哈希分到各個(gè)節(jié)點(diǎn)，然后根據(jù)不同的屬性排序和索引。 Vertica 是為大型數(shù)據(jù)倉(cāng)庫(kù)設(shè)計(jì)的，以列的格式存儲(chǔ)，默認(rèn)壓縮數(shù)據(jù)，因?yàn)閳?zhí)行器可直接操作壓縮數(shù)據(jù)，本文的結(jié)果是執(zhí)行壓縮數(shù)據(jù)產(chǎn)生的。 4.1.2節(jié)點(diǎn)配置三個(gè)系統(tǒng)都部署在100臺(tái)機(jī)子的集群，每個(gè)節(jié)點(diǎn)CPU 2.4GHz intel core 2 操作系統(tǒng)64位red hat enterprise linux 5 內(nèi)存4G 硬盤(pán) 2個(gè)250GSATA-I. 交換機(jī) 128Gbps 50個(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í)

18、行不同的數(shù)據(jù)大小。還測(cè)量了每個(gè)系統(tǒng)加載數(shù)據(jù)的時(shí)間。由于MR每個(gè)reduce輸出一個(gè)文件，而數(shù)據(jù)庫(kù)管理系統(tǒng)總共輸出一個(gè)文件，在HDFS中執(zhí)行一個(gè)額外的reduce函數(shù)來(lái)結(jié)合成一個(gè)文件再輸出。 4.2原始的MR任務(wù)The original MR task第一個(gè)基準(zhǔn)任務(wù)是文獻(xiàn)【8】中的Grep task 作者認(rèn)為具有代表性的大數(shù)據(jù)集MR程序，這個(gè)任務(wù)是在100位記錄的數(shù)據(jù)集尋找三個(gè)特征模式，每個(gè)記錄中在前十位中包含一個(gè)唯一的鍵，后90位是隨機(jī)的值。 Grep task在1,10,25,50,100個(gè)節(jié)點(diǎn)上分別執(zhí)行。 4.2.1數(shù)據(jù)加載加載535M/node和1T/node如下圖，對(duì)于DBMS-X，下

19、半段是執(zhí)行并行加載命令時(shí)間，上半段是重組過(guò)程reorganization process。 Hadoop性能明顯好。 4.2.2任務(wù)執(zhí)行三個(gè)系統(tǒng)的性能結(jié)果如下。Hadoop上半段是MR job把輸出文件結(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.3 分析任務(wù)為了探索處理更復(fù)雜的應(yīng)用，開(kāi)發(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萬(wàn)Ranking 記錄，每個(gè)

20、節(jié)點(diǎn)1G。4.3.1數(shù)據(jù)加載 由于加載UserVisits與Ranking數(shù)據(jù)集是相似的，只提供數(shù)據(jù)集較大的UserVisits的加載。節(jié)點(diǎn)數(shù)越多，相比較Hadoop性能越好。 4.3.2選擇任務(wù)選擇任務(wù)是輕量級(jí)過(guò)濾器在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.3 聚集任務(wù) Aggregation task要求每個(gè)系統(tǒng)計(jì)算在UserVisits表中生成每個(gè)源IP總收益數(shù)（20GB/節(jié)點(diǎn)）。任務(wù)分別產(chǎn)生250萬(wàn)（53M）和2000

21、(24K)組記錄當(dāng)組數(shù)量大時(shí)，Vertica和DBMS-X性能差不多； 當(dāng)組數(shù)量小時(shí)，Vertica性能較好。 4.3.4 聯(lián)合查詢?nèi)蝿?wù)Join Task加入任務(wù)包括兩個(gè)子任務(wù)來(lái)進(jìn)行兩組數(shù)據(jù)的復(fù)雜計(jì)算。首先，每個(gè)系統(tǒng)找出在特定時(shí)間內(nèi)產(chǎn)生最大收益的源IP，一旦這些中間記錄產(chǎn)生時(shí)，系統(tǒng)必須計(jì)算在此間隔期間的所有網(wǎng)頁(yè)訪問(wèn)的平均PageRank。實(shí)驗(yàn)中使用表UserVisits 1月15日至22日，2000年，約13.4萬(wàn)記錄相匹配。 Vertica和DBMS-X性能差不多。 4.3.5 UDF的聚集任務(wù)UDF Aggregation Task任務(wù)是計(jì)算數(shù)據(jù)集中每個(gè)文檔的inlink，這個(gè)任務(wù)經(jīng)常作為PageRank計(jì)算的一個(gè)組件。具體來(lái)說(shuō)，這項(xiàng)任務(wù)時(shí)，系統(tǒng)必須讀取每個(gè)文件的內(nèi)容和搜索內(nèi)容中出現(xiàn)的所有URL，然后針對(duì)每個(gè)唯一的URL，計(jì)算唯一網(wǎng)頁(yè)的數(shù)量。 Vertica性能比較好。節(jié)點(diǎn)數(shù)越多，BMS-X查詢的時(shí)間相比較增長(zhǎng)更快。Vertica和DBMS-X的下面部分代表執(zhí)行UDF/分析和加載數(shù)據(jù)到表中的時(shí)間，上面部分是執(zhí)行真正查詢的時(shí)間。 結(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)上，性能差別也差不多。 謝謝！