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

1、大規(guī)模數(shù)據(jù)分析方法對比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ù) 庫 管 理 系 統(tǒng) 比 較 ，用 于 大 規(guī) 模 數(shù) 據(jù) 集 分 析 。作者簡介 作者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ù) 庫 管 理 系 統(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)，一個Mapreduce和并行數(shù)據(jù)庫管理系統(tǒng)結(jié)合的系統(tǒng)。 摘要目前有相當(dāng)大的興趣在基于MapReduce（MR）模式的大規(guī)模數(shù)據(jù)分析。雖然這個框架的基本控制流已經(jīng)存在于并行SQL數(shù)據(jù)庫管理系統(tǒng)超過20年，也有人稱MR為最新的計(jì)算模型。在本文中，我們描述和比較這兩個模式。此外

6、，我們評估兩個系統(tǒng)的性能和開發(fā)復(fù)雜度。最后，我們定義一個包含任務(wù)集的基準(zhǔn)運(yùn)行于MR開源平臺和兩個并行數(shù)據(jù)庫管理系統(tǒng)上。對于每個任務(wù)，我們在100臺機(jī)子的集群上衡量每個系統(tǒng)的各個方面的并行性能。我們的研究結(jié)果揭示了一些有趣的取舍。雖然加載數(shù)據(jù)和調(diào)整并行數(shù)據(jù)庫管理系統(tǒng)執(zhí)行的過程比MR花費(fèi)更多的時間，但是觀察到的這些數(shù)據(jù)庫管理系統(tǒng)性能顯著地改善。我們推測巨大的性能差異的原因，并考慮將來的系統(tǒng)應(yīng)該從這兩種架構(gòu)中吸取優(yōu)勢。 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ù)庫管理系統(tǒng)。第三部分主要介紹系統(tǒng)架構(gòu)，包括支持的數(shù)據(jù)格式、索引、編程模型等。第四部分主要是基準(zhǔn)測試，在100個節(jié)點(diǎn)集群上運(yùn)行幾個任務(wù)來測試Mapreduce，DBMS-X，Vertic

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

12、來處理鍵/值數(shù)據(jù)對。數(shù)據(jù)被分塊存儲在部署在每個節(jié)點(diǎn)上的分布式文件系統(tǒng)中。程序載入分布式處理框架然后執(zhí)行。具體過程如下： Map函數(shù)從輸入文件中讀入一系列記錄，然后以鍵/值對的形式輸出一系列中間記錄。Map函數(shù)使這些中間值最終產(chǎn)生R個輸出鍵/值對文件，具有相同值的輸出記錄存儲在一個輸出文件下。 Reduce函數(shù)總結(jié)Map階段具有相同值的輸出記錄。最終結(jié)果寫入到新文件。 2.2并行數(shù)據(jù)庫管理系統(tǒng)并行數(shù)據(jù)庫執(zhí)行的兩個關(guān)鍵方面是（1）大部分表分割到集群的節(jié)點(diǎn)上（2）系統(tǒng)使用優(yōu)化器把SQL命令轉(zhuǎn)化成查詢計(jì)劃，使其在多個節(jié)點(diǎn)上執(zhí)行。因?yàn)槌绦騿T只需用高級語言中具體化他們的目標(biāo)，所以無需關(guān)注底層存儲細(xì)節(jié)。 S

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

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

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

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

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

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

19、半段是執(zhí)行并行加載命令時間，上半段是重組過程reorganization process。 Hadoop性能明顯好。 4.2.2任務(wù)執(zhí)行三個系統(tǒng)的性能結(jié)果如下。Hadoop上半段是MR job把輸出文件結(jié)合成一個的時間。下半段是執(zhí)行任務(wù)時間。 對于每個節(jié)點(diǎn)535M，DBMS-X和Vertica性能差不多；對于每個節(jié)點(diǎn)1T，DBMS-X和Hadoop性能差不多。 4.3 分析任務(wù)為了探索處理更復(fù)雜的應(yīng)用，開發(fā)四個關(guān)于HTML文檔處理的任務(wù)。每個節(jié)點(diǎn)分配6000個HTML文檔，還自己利用產(chǎn)生器創(chuàng)造2個數(shù)據(jù)集，1.55億UserVisits 記錄，每個節(jié)點(diǎn)20G，1800萬Ranking 記錄，每個

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ù)是輕量級過濾器在Rinkings 表(1G/節(jié)點(diǎn))中尋找pageURLs。設(shè)置臨界參數(shù)為10，每個節(jié)點(diǎn)上每個數(shù)據(jù)文件大約產(chǎn)生36000條記錄。結(jié)果如下， 隨著數(shù)據(jù)量增大，Hadoop影響最大。Vertica性能較好。 4.3.3 聚集任務(wù) Aggregation task要求每個系統(tǒng)計(jì)算在UserVisits表中生成每個源IP總收益數(shù)（20GB/節(jié)點(diǎn)）。任務(wù)分別產(chǎn)生250萬（53M）和2000

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