后Hadoop時代的大數(shù)據(jù)架構(gòu)_第1頁
后Hadoop時代的大數(shù)據(jù)架構(gòu)_第2頁
后Hadoop時代的大數(shù)據(jù)架構(gòu)_第3頁
后Hadoop時代的大數(shù)據(jù)架構(gòu)_第4頁
后Hadoop時代的大數(shù)據(jù)架構(gòu)_第5頁
已閱讀5頁,還剩6頁未讀, 繼續(xù)免費(fèi)閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進(jìn)行舉報(bào)或認(rèn)領(lǐng)

文檔簡介

后Hadoop時代的大數(shù)據(jù)架構(gòu)背景篇Hadoop:開源的數(shù)據(jù)分析平臺,解決了大數(shù)據(jù)(大到一臺計(jì)算機(jī)無法進(jìn)行存儲,一臺計(jì)算機(jī)無法在要求的時間內(nèi)進(jìn)行處理)的可靠存儲和處理。適合處理非結(jié)構(gòu)化數(shù)據(jù),包括HDFS,MapReduce基本組件。HDFS:提供了一種跨服務(wù)器的彈性數(shù)據(jù)存儲系統(tǒng)。MapReduce:技術(shù)提供了感知數(shù)據(jù)位置的標(biāo)準(zhǔn)化處理流程:讀取數(shù)據(jù),對數(shù)據(jù)進(jìn)行映射(Map),使用某個鍵值對數(shù)據(jù)進(jìn)行重排,然后對數(shù)據(jù)進(jìn)行化簡(Reduce)得到最終的輸出。AmazonElasticMapReduce(EMR):托管的解決方案,運(yùn)行在由AmazonElasticComputeCloud(EC2)和SimpleStrorageService(S3)組成的網(wǎng)絡(luò)規(guī)模的基礎(chǔ)設(shè)施之上。如果你需要一次性的或不常見的大數(shù)據(jù)處理,EMR可能會為你節(jié)省開支。但EMR是高度優(yōu)化成與S3中的數(shù)據(jù)一起工作,會有較高的延時。Hadoop還包含了一系列技術(shù)的擴(kuò)展系統(tǒng),這些技術(shù)主要包括了Sqoop、Flume、Hive、Pig、Mahout、Datafu和HUE等。Pig:分析大數(shù)據(jù)集的一個平臺,該平臺由一種表達(dá)數(shù)據(jù)分析程序的高級語言和對這些程序進(jìn)行評估的基礎(chǔ)設(shè)施一起組成。Hive:用于Hadoop的一個數(shù)據(jù)倉庫系統(tǒng),它提供了類似于SQL的查詢語言,通過使用該語言,可以方便地進(jìn)行數(shù)據(jù)匯總,特定查詢以及分析。Hbase:一種分布的、可伸縮的、大數(shù)據(jù)儲存庫,支持隨機(jī)、實(shí)時讀/寫訪問。Sqoop:為高效傳輸批量數(shù)據(jù)而設(shè)計(jì)的一種工具,其用于ApacheHadoop和結(jié)構(gòu)化數(shù)據(jù)儲存庫如關(guān)系數(shù)據(jù)庫之間的數(shù)據(jù)傳輸。Flume:一種分布式的、可靠的、可用的服務(wù),其用于高效地搜集、匯總、移動大量日志數(shù)據(jù)。ZooKeeper:一種集中服務(wù),其用于維護(hù)配置信息,命名,提供分布式同步,以及提供分組服務(wù)。Cloudera:最成型的Hadoop發(fā)行版本,擁有最多的部署案例。提供強(qiáng)大的部署、管理和監(jiān)控工具。開發(fā)并貢獻(xiàn)了可實(shí)時處理大數(shù)據(jù)的Impala項(xiàng)目。Hortonworks:使用了100%開源ApacheHadoop提供商。開發(fā)了很多增強(qiáng)特性并提交至核心主干,這使得Hadoop能夠在包括WindowsServer和Azure在內(nèi)平臺上本地運(yùn)行。MapR:獲取更好的性能和易用性而支持本地Unix文件系統(tǒng)而不是HDFS。提供諸如快照、鏡像或有狀態(tài)的故障恢復(fù)等高可用性特性。領(lǐng)導(dǎo)著ApacheDrill項(xiàng)目,是Google的Dremel的開源實(shí)現(xiàn),目的是執(zhí)行類似SQL的查詢以提供實(shí)時處理。原理篇數(shù)據(jù)存儲我們的目標(biāo)是做一個可靠的,支持大規(guī)模擴(kuò)展和容易維護(hù)的系統(tǒng)。計(jì)算機(jī)里面有個locality(局部性定律),如圖所示。從下到上訪問速度越來越快,但存儲代價更大。相對內(nèi)存,磁盤和SSD就需要考慮數(shù)據(jù)的擺放,因?yàn)樾阅軙町惡艽?。磁盤好處是持久化,單位成本便宜,容易備份。但隨著內(nèi)存便宜,很多數(shù)據(jù)集合可以考慮直接放入內(nèi)存并分布到各機(jī)器上,有些基于key-value,Memcached用在緩存上。內(nèi)存的持久化可以通過(帶電池的RAM),提前寫入日志再定期做Snapshot或者在其他機(jī)器內(nèi)存中復(fù)制。當(dāng)重啟時需要從磁盤或網(wǎng)絡(luò)載入之前狀態(tài)。其實(shí)寫入磁盤就用在追加日志上面,讀的話就直接從內(nèi)存。像VoltDB,MemSQL,RAMCloud關(guān)系型又基于內(nèi)存數(shù)據(jù)庫,可以提供高性能,解決之前磁盤管理的麻煩。HyperLogLog&BloomFilter&CountMinSketch都是是應(yīng)用于大數(shù)據(jù)的算法,大致思路是用一組相互獨(dú)立的哈希函數(shù)依次處理輸入。HyperLogLog用來計(jì)算一個很大集合的基數(shù)(即合理總共有多少不相同的元素),對哈希值分塊計(jì)數(shù):對高位統(tǒng)計(jì)有多少連續(xù)的0;用低位的值當(dāng)做數(shù)據(jù)塊。BloomFilter,在預(yù)處理階段對輸入算出所有哈希函數(shù)的值并做出標(biāo)記。當(dāng)查找一個特定的輸入是否出現(xiàn)過,只需查找這一系列的哈希函數(shù)對應(yīng)值上有沒有標(biāo)記。對于BloomFilter,可能有FalsePositive,但不可能有FalseNegative。BloomFilter可看做查找一個數(shù)據(jù)有或者沒有的數(shù)據(jù)結(jié)構(gòu)(數(shù)據(jù)的頻率是否大于1)。CountMinSketch在BloomFilter的基礎(chǔ)上更進(jìn)一步,它可用來估算某一個輸入的頻率(不局限于大于1)。CAPTheorem簡單說是三個特性:一致性,可用性和網(wǎng)絡(luò)分區(qū),最多只能取其二。設(shè)計(jì)不同類型系統(tǒng)要多去權(quán)衡。分布式系統(tǒng)還有很多算法和高深理論,比如:Paxos算法(paxos分布式一致性算法–講述諸葛亮的反穿越),Gossip協(xié)議(Cassandra學(xué)習(xí)筆記之Gossip協(xié)議),Quorum(分布式系統(tǒng)),時間邏輯,向量時鐘(一致性算法之四:時間戳和向量圖),拜占庭將軍問題,二階段提交等,需要耐心研究。技術(shù)篇來自:/leading_big_data_technologies/big-data-reference-architecture/根據(jù)不同的延遲要求(SLA),數(shù)據(jù)量存儲大小,更新量多少,分析需求,大數(shù)據(jù)處理的架構(gòu)也需要做靈活的設(shè)計(jì)。上圖就描述了在不同領(lǐng)域中大數(shù)據(jù)組件。說大數(shù)據(jù)的技術(shù)還是要先提Google,Google新三輛馬車,Spanner,F1,DremelSpanner:高可擴(kuò)展、多版本、全球分布式外加同步復(fù)制特性的谷歌內(nèi)部數(shù)據(jù)庫,支持外部一致性的分布式事務(wù);設(shè)計(jì)目標(biāo)是橫跨全球上百個數(shù)據(jù)中心,覆蓋百萬臺服務(wù)器,包含萬億條行記錄!(Google就是這么霸氣^-^)F1:構(gòu)建于Spanner之上,在利用Spanner的豐富特性基礎(chǔ)之上,還提供分布式SQL、事務(wù)一致性的二級索引等功能,在AdWords廣告業(yè)務(wù)上成功代替了之前老舊的手工MySQLShard方案。Dremel:一種用來分析信息的方法,它可以在數(shù)以千計(jì)的服務(wù)器上運(yùn)行,類似使用SQL語言,能以極快的速度處理網(wǎng)絡(luò)規(guī)模的海量數(shù)據(jù)(PB數(shù)量級),只需幾秒鐘時間就能完成。Spark2014年最火的大數(shù)據(jù)技術(shù)Spark,有什么關(guān)于Spark的書推薦?–董飛的回答做了介紹。主要意圖是基于內(nèi)存計(jì)算做更快的數(shù)據(jù)分析。同時支持圖計(jì)算,流式計(jì)算和批處理。BerkeleyAMPLab的核心成員出來成立公司Databricks開發(fā)Cloud產(chǎn)品。Flink使用了一種類似于SQL數(shù)據(jù)庫查詢優(yōu)化的方法,這也是它與當(dāng)前版本的ApacheSpark的主要區(qū)別。它可以將全局優(yōu)化方案應(yīng)用于某個查詢之上以獲得更佳的性能。KafkaAnnouncingtheConfluentPlatform1.0Kafka描述為LinkedIn的“中樞神經(jīng)系統(tǒng)”,管理從各個應(yīng)用程序匯聚到此的信息流,這些數(shù)據(jù)經(jīng)過處理后再被分發(fā)到各處。不同于傳統(tǒng)的企業(yè)信息列隊(duì)系統(tǒng),Kafka是以近乎實(shí)時的方式處理流經(jīng)一個公司的所有數(shù)據(jù),目前已經(jīng)為LinkedIn,Netflix,Uber和Verizon建立了實(shí)時信息處理平臺。Kafka的優(yōu)勢就在于近乎實(shí)時性。StormHandleFiveBillionSessionsaDayinRealTime,Twitter的實(shí)時計(jì)算框架。所謂流處理框架,就是一種分布式、高容錯的實(shí)時計(jì)算系統(tǒng)。Storm令持續(xù)不斷的流計(jì)算變得容易。經(jīng)常用于在實(shí)時分析、在線機(jī)器學(xué)習(xí)、持續(xù)計(jì)算、分布式遠(yuǎn)程調(diào)用和ETL等領(lǐng)域。SamzaLinkedIn主推的流式計(jì)算框架。與其他類似的Spark,Storm做了幾個比較。跟Kafka集成良好,作為主要的存儲節(jié)點(diǎn)和中介。LambdaarchitectureNathan寫了文章《如何去打敗CAP理論》HowtobeattheCAPtheorem,提出LambdaArchitecture,主要思想是對一些延遲高但數(shù)據(jù)量大的還是采用批處理架構(gòu),但對于即時性實(shí)時數(shù)據(jù)使用流式處理框架,然后在之上搭建一個服務(wù)層去合并兩邊的數(shù)據(jù)流,這種系統(tǒng)能夠平衡實(shí)時的高效和批處理的Scale,看了覺得腦洞大開,確實(shí)很有效,被很多公司采用在生產(chǎn)系統(tǒng)中。SummingbirdLambda架構(gòu)的問題要維護(hù)兩套系統(tǒng),Twitter開發(fā)了Summingbird來做到一次編程,多處運(yùn)行。將批處理和流處理無縫連接,通過整合批處理與流處理來減少它們之間的轉(zhuǎn)換開銷。下圖就解釋了系統(tǒng)運(yùn)行時。NoSQL數(shù)據(jù)傳統(tǒng)上是用樹形結(jié)構(gòu)存儲(層次結(jié)構(gòu)),但很難表示多對多的關(guān)系,關(guān)系型數(shù)據(jù)庫就是解決這個難題,最近幾年發(fā)現(xiàn)關(guān)系型數(shù)據(jù)庫也不靈了,新型NoSQL出現(xiàn)如Cassandra,MongoDB,Couchbase。NoSQL里面也分成這幾類,文檔型,圖運(yùn)算型,列存儲,key-value型,不同系統(tǒng)解決不同問題。沒一個one-size-fits-all的方案。Cassandra大數(shù)據(jù)架構(gòu)中,Cassandra的主要作用就是存儲結(jié)構(gòu)化數(shù)據(jù)。DataStax的Cassandra是一種面向列的數(shù)據(jù)庫,它通過分布式架構(gòu)提供高可用性及耐用性的服務(wù)。它實(shí)現(xiàn)了超大規(guī)模的集群,并提供一種稱作“最終一致性”的一致性類型,這意味著在任何時刻,在不同服務(wù)器中的相同數(shù)據(jù)庫條目可以有不同的值。SQLonHadoop開源社區(qū)業(yè)出現(xiàn)了很多SQL-on-Hadoop的項(xiàng)目,著眼跟一些商業(yè)的數(shù)據(jù)倉庫系統(tǒng)競爭。包括ApacheHive,SparkSQL,ClouderaImpala,HortonworksStinger,FacebookPresto,ApacheTajo,ApacheDrill。有些是基于GoogleDremel設(shè)計(jì)。ImpalaCloudera公司主導(dǎo)開發(fā)的新型查詢系統(tǒng),它提供SQL語義,能夠查詢存儲在Hadoop的HDFS和HBase中的PB級大數(shù)據(jù),號稱比Hive快5-10倍,但最近被Spark的風(fēng)頭給罩住了,大家還是更傾向于后者。DrillApache社區(qū)類似于Dremel的開源版本—Drill。一個專為互動分析大型數(shù)據(jù)集的分布式系統(tǒng)。Druid在大數(shù)據(jù)集之上做實(shí)時統(tǒng)計(jì)分析而設(shè)計(jì)的開源數(shù)據(jù)存儲。這個系統(tǒng)集合了一個面向列存儲的層,一個分布式、shared-nothing的架構(gòu),和一個高級的索引結(jié)構(gòu),來達(dá)成在秒級以內(nèi)對十億行級別的表進(jìn)行任意的探索分析。BerkeleyDataAnalyticsStack上面說道Spark,在BerkeleyAMPlab中有個更宏偉的藍(lán)圖,就是BDAS,里面有很多明星項(xiàng)目,除了Spark,還包括:Mesos:一個分布式環(huán)境的資源管理平臺,它使得Hadoop、MPI、Spark作業(yè)在統(tǒng)一資源管理環(huán)境下執(zhí)行。它對Hadoop2.0支持很好。Twitter,Coursera都在使用。Tachyon:是一個高容錯的分布式文件系統(tǒng),允許文件以內(nèi)存的速度在集群框架中進(jìn)行可靠的共享,就像Spark和MapReduce那樣。項(xiàng)目發(fā)起人李浩源說目前發(fā)展非???,甚至比Spark當(dāng)時還要驚人,已經(jīng)成立創(chuàng)業(yè)公司TachyonNexus.BlinkDB:也很有意思,在海量數(shù)據(jù)上運(yùn)行交互式SQL查詢的大規(guī)模并行查詢引擎。它允許用戶通過權(quán)衡數(shù)據(jù)精度來提升查詢響應(yīng)時間,其數(shù)據(jù)的精度被控制在允許的誤差范圍內(nèi)。ClouderaHadoop老大哥提出的經(jīng)典解決方案。HDP(HadoopDataPlatform)Hortonworks提出的架構(gòu)選型。RedshiftAmazonRedShift是ParAccel一個版本。它是一種(massivelyparallelcomputer)架構(gòu),是非常方便的數(shù)據(jù)倉庫解決方案,SQL接口,跟各個云服務(wù)無縫連接,最大特點(diǎn)就是快,在TB到PB級別非常好的性能,我在工作中也是直接使用,它還支持不同的硬件平臺,如果想速度更快,可以使用SSD。Netflix完全基于AWS的數(shù)據(jù)處理解決方案。Intel參考鏈接TheHadoop

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護(hù)處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負(fù)責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時也不承擔(dān)用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論