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

下載本文檔

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

文檔簡(jiǎn)介

Hadoop2023-04-29HadoopHadoop10也從0.x進(jìn)化到目前的2.6版本。我把2023年后定義成后HadoopHadoopLOnlySQL〕那樣,有其他的選型補(bǔ)充。背景篇Hadoop:〔大到一臺(tái)計(jì)算機(jī)無法進(jìn)展存儲(chǔ),一臺(tái)計(jì)算機(jī)無法在要求的時(shí)間內(nèi)進(jìn)行處理〕的牢靠存儲(chǔ)和處理。適合處理非構(gòu)造化數(shù)據(jù),包括HDFS,MapReduceHDFS:供給了一種跨效勞器的彈性數(shù)據(jù)存儲(chǔ)系統(tǒng)。MapReduce:技術(shù)供給了感知數(shù)據(jù)位臵的標(biāo)準(zhǔn)化處理流程:讀取數(shù)據(jù),對(duì)數(shù)據(jù)進(jìn)展映射〔Map據(jù)進(jìn)展重排,然后對(duì)數(shù)據(jù)進(jìn)展化簡(jiǎn)〔Reduce〕得到最終的輸出。AmazonElasticMapReduce(EMR)AmazonElasticComputeCloud〔EC2〕和SimpleStrorageService〔S3〕組成的網(wǎng)絡(luò)規(guī)模的根底設(shè)施之上。假設(shè)你需要一次性的或不常見的大數(shù)據(jù)處理,EMREMR是高度優(yōu)化成與S3中的數(shù)據(jù)一起工作,會(huì)有較高的延時(shí)。Hadoop包括了Sqoop、Flume、Hive、Pig、Mahout、Datafu和HUE等。Pig:分析大數(shù)據(jù)集的一個(gè)平臺(tái),該平臺(tái)由一種表達(dá)數(shù)據(jù)分析程序的高級(jí)語言和對(duì)這些程序進(jìn)展評(píng)估的根底設(shè)施一起組成。HiveHadoop似于SQL的查詢語言,通過使用該語言,可以便利地進(jìn)展數(shù)據(jù)匯總,特定查詢以及分析。Hbase:一種分布的、可伸縮的、大數(shù)據(jù)儲(chǔ)存庫(kù),支持隨機(jī)、實(shí)時(shí)讀/寫訪問。Sqoop:為高效傳輸批量數(shù)據(jù)而設(shè)計(jì)的一種工具,其用于ApacheHadoop和構(gòu)造化數(shù)據(jù)儲(chǔ)存庫(kù)如關(guān)系數(shù)據(jù)庫(kù)之間的數(shù)據(jù)傳輸。Flume:一種分布式的、牢靠的、可用的效勞,其用于高效地搜集、匯總、移動(dòng)大量日志數(shù)據(jù)。ZooKeeper:一種集中效勞,其用于維護(hù)配臵信息,命名,供給分布式同步,以及供給分組效勞。ClouderaHadoop署案例。供給強(qiáng)大的部署、治理和監(jiān)控工具。開發(fā)并奉獻(xiàn)了ImpalaHortonworks100%開源ApacheHadoopHadoopWindowsServerAzureMapRUnix系統(tǒng)而不是HDFS等高可用性特性。領(lǐng)導(dǎo)著ApacheDrillGoogleDremel的開源實(shí)現(xiàn),目的是執(zhí)行類似SQL的查詢以供給實(shí)時(shí)處理。原理篇數(shù)據(jù)存儲(chǔ)我們的目標(biāo)是做一個(gè)牢靠的,支持大規(guī)模擴(kuò)展和簡(jiǎn)潔維護(hù)的系統(tǒng)。計(jì)算機(jī)里面有個(gè)locality〔局部性定律。從下到問速度越來越快,但存儲(chǔ)代價(jià)更大。SSD性能會(huì)差異很大。磁盤好處是長(zhǎng)久化,單位本錢廉價(jià),簡(jiǎn)潔備份。但隨著內(nèi)存廉價(jià),很多數(shù)據(jù)集合可以考慮直接放入內(nèi)存并分布到各機(jī)器上,有些基于key-value,Memcached(帶電池的RAM),提前寫Snapshot重啟時(shí)需要從磁盤或網(wǎng)絡(luò)載入之前狀態(tài)。其實(shí)寫入磁盤就用VoltDB,MemSQL,RAMCloud關(guān)系型又基于內(nèi)存數(shù)據(jù)庫(kù),可以供給高性能,解決之前磁盤治理的麻煩。HyperLogLog&BloomFilter&CountMinSketch都是是應(yīng)用于大數(shù)據(jù)的算法,大致思路是用一組相互獨(dú)立的哈希函數(shù)依次處理輸入。HyperLogLog0;用低位的值當(dāng)做數(shù)據(jù)塊。BloomFilter,在預(yù)處理階段對(duì)輸入算出全部哈希函數(shù)的值并做出標(biāo)記。當(dāng)查找一個(gè)特定的輸入是否消滅過,只需查找這一系列的哈希函數(shù)對(duì)應(yīng)值上有沒有標(biāo)記。對(duì)于BloomFilterFalsePositive,但不行能有FalseNegative。BloomFilter數(shù)據(jù)構(gòu)造〔數(shù)據(jù)的頻率是否大于1。CountMinSketchBloomFilter的頻率〔不局限于大于1。CAPTheorem簡(jiǎn)潔說是三個(gè)特性:全都性,可用性和網(wǎng)絡(luò)分區(qū),最多只能取其二。設(shè)計(jì)不同類型系統(tǒng)要多去權(quán)衡。分布式系統(tǒng)還有很多算法和高深理論,比方:Paxos〔paxos全都性算法--表達(dá)諸葛亮的反穿越Gossip協(xié)議〔Cassandra學(xué)習(xí)筆記之Gossip協(xié)議,Quorum統(tǒng)),時(shí)間規(guī)律,向量時(shí)鐘〔全都性算法之四:時(shí)間戳和向量圖,拜占庭將軍問題,二階段提交等,需要急躁?duì)幷?。技術(shù)篇Google,Google車,Spanner,F1,DremelSpanner:高可擴(kuò)展、多版本、全球分布式外加同步復(fù)設(shè)計(jì)目標(biāo)是橫跨全球上百個(gè)數(shù)據(jù)中心,掩蓋百萬臺(tái)效勞器,包含萬億條行記錄!(Google^-^)F1:構(gòu)建于Spanner之上,在利用Spanner的豐富特性根底之上,還供給分布式SQL在AdWords廣告業(yè)務(wù)上成功代替了之前老舊的手工MySQLShardDremel:的效勞器上運(yùn)行,類似使用SQL語言,能以極快的速度處理網(wǎng)絡(luò)規(guī)模的海量數(shù)據(jù)(PB數(shù)量級(jí)),只需幾秒鐘時(shí)間就能完成。Spark:主要意圖是基于內(nèi)存計(jì)算做更快的數(shù)據(jù)分析。同時(shí)支持圖計(jì)算,流式計(jì)算和批處理。BerkeleyAMPLab的核心成員DatabricksCloudFlink:使用了一種類似于SQL數(shù)據(jù)庫(kù)查詢優(yōu)化的方法,這也是ApacheSpark優(yōu)化方案應(yīng)用于某個(gè)查詢之上以獲得更佳的性能。AnnouncingtheConfluentPlatform1.0Kafka描述為L(zhǎng)inkedIn到此的信息流,這些數(shù)據(jù)經(jīng)過處理后再被分發(fā)到各處。不同于傳統(tǒng)的企業(yè)信息列隊(duì)系統(tǒng),Kafka是以近乎實(shí)時(shí)的方式處理流經(jīng)一個(gè)公司的全部數(shù)據(jù),目前已經(jīng)為 LinkedIn,Netflix,Uber和Verizon建立了實(shí)時(shí)信息處理平臺(tái)。Kafka的優(yōu)勢(shì)就在于近乎實(shí)時(shí)性。Storm:HandleFiveBillionSessionsaDayinRealTwitter式、高容錯(cuò)的實(shí)時(shí)計(jì)算系統(tǒng)。Storm得簡(jiǎn)潔。常常用于在實(shí)時(shí)分析、在線機(jī)器學(xué)習(xí)、持續(xù)計(jì)算、ETLSamza:LinkedInSpark,Storm做了幾個(gè)比較。跟Kafka集成良好,作為主要的存儲(chǔ)節(jié)點(diǎn)和中介。Lambdaarchitecture:NathanCAPHowtobeattheCAPtheorem,提出LambdaArchitecture,主要思想是對(duì)一些延遲高但數(shù)據(jù)量大的還是承受批處理架構(gòu),但對(duì)于即時(shí)性實(shí)時(shí)數(shù)據(jù)使用流式處理框架,然后在之上搭建一個(gè)效勞層去合并兩邊的數(shù)據(jù)流,這種系統(tǒng)能夠平衡實(shí)時(shí)的高效和批處理Scale,看了覺得腦洞大開,確實(shí)很有效,被很多公司承受在生產(chǎn)系統(tǒng)中。Summingbird:LambdaTwitter開發(fā)了Summingbird理無縫連接,通過整合批處理與流處理來削減它們之間的轉(zhuǎn)換開銷。以下圖就解釋了系統(tǒng)運(yùn)行時(shí)。NoSQL:數(shù)據(jù)傳統(tǒng)上是用樹形構(gòu)造存儲(chǔ)〔層次構(gòu)造〕,但很難表示多對(duì)多的關(guān)系,關(guān)系型數(shù)據(jù)庫(kù)就是解決這個(gè)難題,最近幾NoSQL消滅如Cassandra,MongoDB,Couchbase。NoSQL里面也分成這幾類,文檔型,key-valueone-size-fits-all的方案。Cassandra:大數(shù)據(jù)架構(gòu)中,CassandraDataStax的Cassandra過分布式架構(gòu)供給高可用性及耐用性的效勞。它實(shí)現(xiàn)了超大這意味著在任何時(shí)刻,在不同效勞器中的一樣數(shù)據(jù)庫(kù)條目可以有不同的值。SQLonHadoop:開源社區(qū)業(yè)消滅了很多SQL-on-HadoopApacheHive,SparkSQL,ClouderaImpala,HortonworksStinger,FacebookPresto,ApacheTajo,ApacheDrill。有些是基于GoogleDremel設(shè)計(jì)。Impala:ClouderaSQL語HadoopHDFSHBasePB數(shù)據(jù),號(hào)稱比Hive快5-10倍,但最近被Spark的風(fēng)頭給罩住了,大家還是更傾向于后者。Drill:Apache社區(qū)類似于Dremel的開源版本—Drill為互動(dòng)分析大型數(shù)據(jù)集的分布式系統(tǒng)。Druid:在大數(shù)據(jù)集之上做實(shí)時(shí)統(tǒng)計(jì)分析而設(shè)計(jì)的開源數(shù)據(jù)存儲(chǔ)。這個(gè)系統(tǒng)集合了一個(gè)面對(duì)列存儲(chǔ)的層,一個(gè)分布式、shared-nothing的架構(gòu),和一個(gè)高級(jí)的索引構(gòu)造,來達(dá)成在秒級(jí)以內(nèi)對(duì)十億行級(jí)別的表進(jìn)展任意的探究分析。BerkeleyDataAnalyticsStack:SparkBerkeleyAMPlab中有個(gè)更雄偉的藍(lán)圖,就是BDAS,里面有很多明星工程,除了Spark,還包括:Mesos:HadoopMPI、Spark作業(yè)在統(tǒng)一資源治理環(huán)境下執(zhí)行。它對(duì)Hadoop2.0支持很好。Twitter,CourseraTachyon:是一個(gè)高容錯(cuò)的分布式文件系統(tǒng),允許文件以內(nèi)存的速度在集群框架中進(jìn)展牢靠的共享,就像Spark和MapReduceSparkTachyonNexus.BlinkDB:也很有意思,在海量數(shù)據(jù)上運(yùn)行交互式SQL查詢的大規(guī)模并行查詢引擎。它允許用戶通過權(quán)衡數(shù)據(jù)精度來提升

溫馨提示

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

最新文檔

評(píng)論

0/150

提交評(píng)論