偷偷摘套内射激情视频,久久精品99国产国产精,中文字幕无线乱码人妻,中文在线中文a,性爽19p

換個姿勢入門大數(shù)據(jù)

大數(shù)據(jù)
然而,大數(shù)據(jù)雖然很火,但其實(shí)是個概念沒那么清晰的東西,不同的人可能有不同的理解。首先第一個問題,大數(shù)據(jù),大數(shù)據(jù),多大叫大?或者換一個角度,什么時候需要用到大數(shù)據(jù)相關(guān)的技術(shù)?

這篇文章是我近期準(zhǔn)備在公司做大數(shù)據(jù)分享的內(nèi)容。因?yàn)榱?xí)慣了全英文的 keynote,所以本來標(biāo)題叫《Introduction to bigdata》,但微信的英文標(biāo)題字體總覺得有些別扭,所以還是取了這么個中文名。

這篇文章的目的是帶那些對大數(shù)據(jù)不了解又有興趣的人入門。如果你是老手可以忽略,或者想看看有沒有不一樣的東西也行。

我們學(xué)習(xí)一個新知識,***步應(yīng)該是給它個明確的定義。這樣才能知道你學(xué)的是什么,哪些該學(xué),哪些又可以先不用管。

然而,大數(shù)據(jù)雖然很火,但其實(shí)是個概念沒那么清晰的東西,不同的人可能有不同的理解。

這次我們不去糾結(jié)具體的定義,也忽略那些 4 個 V、6 個 C 之類傳統(tǒng)說教的東西,甚至不想聊架構(gòu)演進(jìn)以及各種調(diào)優(yōu)的方法,這些東西講了大家也不一定懂,懂了也記不住,記住了也用不起來。

我們也不去關(guān)注 AI、Machine Learning 那些炫酷的應(yīng)用層面的東西,而是去看看大數(shù)據(jù)這棟房子的地基是什么模樣。限于篇幅,很多技術(shù)細(xì)節(jié)點(diǎn)到即止,有興趣的同學(xué)可以再按需了解,這也正是入門的含義所在。

首先***個問題,大數(shù)據(jù),大數(shù)據(jù),多大叫大?或者換一個角度,什么時候需要用到大數(shù)據(jù)相關(guān)的技術(shù)?

這依然是個沒有標(biāo)準(zhǔn)答案的問題,有些人可能覺得幾十 G 就夠大了,也有人覺得幾十 T 也還好。當(dāng)你不知道多大叫大,或者當(dāng)你不知道該不該用大數(shù)據(jù)技術(shù)的時候,通常你就還不需要它。

而當(dāng)你的數(shù)據(jù)多到單機(jī)或者幾臺機(jī)器存不下,即使存得下也不好管理和使用的時候;當(dāng)你發(fā)現(xiàn)用傳統(tǒng)的編程方式,哪怕多進(jìn)程多線程協(xié)程全用上,數(shù)據(jù)處理速度依然很不理想的時候;當(dāng)你碰到其他由于數(shù)據(jù)量太大導(dǎo)致的實(shí)際問題的時候,可能你需要考慮下是不是該嘗試下大數(shù)據(jù)相關(guān)的技術(shù)。

從剛才的例子很容易能抽象出大數(shù)據(jù)的兩類典型應(yīng)用場景:

  • 大量數(shù)據(jù)的存儲,解決裝不下的問題。
  • 大量數(shù)據(jù)的計算,解決算得慢的問題。

因此,大數(shù)據(jù)的地基也就由存儲和計算兩部分組成。

我們在單機(jī),或者說數(shù)據(jù)量沒那么大的時候,對于存儲有兩種需求:

  • 文件形式的存儲
  • 數(shù)據(jù)庫形式的存儲

文件形式的存儲是最基本的需求,比如各個服務(wù)產(chǎn)生的日志、爬蟲爬來的數(shù)據(jù)、圖片音頻等多媒體文件等等。對應(yīng)的是最原始的數(shù)據(jù)。

數(shù)據(jù)庫形式的存儲則通常是處理之后可以直接供業(yè)務(wù)程序化使用的數(shù)據(jù),比如從訪問日志文件里處理得到訪問者 ip、ua 等信息保存到關(guān)系數(shù)據(jù)庫,這樣就能直接由一個 web 程序展示在頁面上。對應(yīng)的是處理后方便使用的數(shù)據(jù)。

大數(shù)據(jù)也只是數(shù)據(jù)量大而已,這兩種需求也一樣。雖然不一定嚴(yán)謹(jǐn),但前者我們可以叫做離線(offline)存儲,后者可以叫做在線(online)存儲。

離線存儲這塊 HDFS(Hadoop Distributed File System) 基本上是事實(shí)上的標(biāo)準(zhǔn)。從名字可以看出,這是個分布式的文件系統(tǒng)。實(shí)際上,「分布式」也是解決大數(shù)據(jù)問題的通用方法,只有支持***橫向擴(kuò)展的分布式系統(tǒng)才能在理論上有解決***增長的數(shù)據(jù)量帶來的問題的可能性。當(dāng)然這里的***要打個引號。 

這是 HDFS 的簡易架構(gòu)圖,看起來仍然不太直觀,其實(shí)要點(diǎn)只有幾句話:

  • 文件被以 block 為單位拆分后存放在不同的服務(wù)器上,每個 block 都在不同機(jī)器上做了多份冗余。
  • 有 NameNode 和 DataNode 兩種角色,前者存放元數(shù)據(jù)也就是每個 block 保存在哪里,后者負(fù)責(zé)存放實(shí)際數(shù)據(jù)。
  • 讀和寫數(shù)據(jù)都要先向 NameNode 拿到對應(yīng)文件的元數(shù)據(jù),然后再找對應(yīng)的 DataNode 拿實(shí)際的數(shù)據(jù)。

可以看到,HDFS 通過集中記錄元數(shù)據(jù)的方式實(shí)現(xiàn)了分布式的效果,數(shù)據(jù)量增長只需要添加一些新的 DataNode 就可以了,單機(jī)容量不再是限制。

而為了保證數(shù)據(jù)的高可用,比如某臺服務(wù)器突然壞了再也起不來了,HDFS 通過冗余的方式(通常是 3 副本)來解決這個問題。這也是分布式系統(tǒng)里最常用的高可用方式,雖然成本可能很高。

系統(tǒng)級別的高可用才有意義,所以除了數(shù)據(jù)的高可用,元數(shù)據(jù)的高可用也至關(guān)重要。思路一樣 -- 備份。HDFS 提供了 Secondary NameNode 來提供元數(shù)據(jù)的冗余。當(dāng)然更好的方式是使用 NameNode HA 的方式,通過 active/standby 一組 NameNode 來保證不間斷的元數(shù)據(jù)讀寫服務(wù)。

同樣,擴(kuò)展性剛才也只考慮到數(shù)據(jù)的橫向擴(kuò)展,元數(shù)據(jù)呢?當(dāng)數(shù)據(jù)量大到一定程度,元數(shù)據(jù)也會非常大,類似我們在傳統(tǒng)關(guān)系數(shù)據(jù)庫里碰到的索引膨脹的問題。解決的思路是 NameNode Federation。簡單講就是把原來的一組 active/standy NameNode 拆分成多組,每組只管理一部分元數(shù)據(jù)。拆分后以類似我們在 Linux 系統(tǒng)里掛載(mount)硬盤的方法對外作為整體提供服務(wù)。這些 NameNode 組之間相互獨(dú)立,2.x 版本的 HDFS 通過 ViewFS 這個抽象在客戶端通過配置的方式實(shí)現(xiàn)對多組 NameNode 的透明訪問,3.x 版本的 HDFS 則實(shí)現(xiàn)了全新的 Router Federation 來在服務(wù)端保證對多組 NameNode 的透明訪問。

可以看到,元數(shù)據(jù)的橫向擴(kuò)展和實(shí)際數(shù)據(jù)的橫向擴(kuò)展思路完全一樣,都是拆分然后做成分布式。

和離線存儲對應(yīng)的是在線存儲,可以參照傳統(tǒng)的 MySQL、Oracle 等數(shù)據(jù)庫來理解。在大數(shù)據(jù)領(lǐng)域最常用的是 HBase。

數(shù)據(jù)分類的標(biāo)準(zhǔn)很多,HBase 可能被歸類為 NoSQL 數(shù)據(jù)庫、列式數(shù)據(jù)庫、分布式數(shù)據(jù)庫等等。

說它是 NoSQL 數(shù)據(jù)庫,是因?yàn)?HBase 沒有提供傳統(tǒng)關(guān)系型數(shù)據(jù)庫的很多特性。比如不支持通過 SQL 的形式讀寫數(shù)據(jù),雖然可以集成 Apache Phoenix 等第三方方案,但畢竟原生不支持;不支持二級索引(Secondary Index),只有順序排列的 rowkey 作為主鍵,雖然通過內(nèi)置的 Coprocessor 能實(shí)現(xiàn),第三方的 Apache Phoenix 也提供了 SQL 語句創(chuàng)建二級索引的功能,但畢竟原生不支持;Schema 不那么結(jié)構(gòu)化和確定,只提供了列族來對列分類管理,每個列族內(nèi)的列的數(shù)量、類型都沒有限制,完全在數(shù)據(jù)寫入時確定,甚至只能通過全表掃描確定一共有哪些列。從這些角度看,HBase 甚至都不像是個 DataBase,而更像是個 DataStore。

說它是列式數(shù)據(jù)庫,是因?yàn)榈讓哟鎯σ粤凶鍨閱挝唤M織。不同行的相同列族放在一起,同一行的不同列族反而不在一起。這也就使得基于列(族)的過濾等變得更加容易。

說它是分布式數(shù)據(jù)庫,是因?yàn)樗峁┝藦?qiáng)大的橫向擴(kuò)展的能力。這也是 HBase 能成為大數(shù)據(jù)在線存儲領(lǐng)域主流方案的主要原因。

HBase 能提供超大數(shù)據(jù)量存儲和訪問的根本在于,它是基于 HDFS 的,所有的數(shù)據(jù)都以文件的形式保存在 HDFS 上。這樣就天然擁有了橫向擴(kuò)展的能力,以及高可用等特性。

解決了數(shù)據(jù)存儲的問題,剩下就需要在這個基礎(chǔ)上提供一套類似數(shù)據(jù)庫的 API 服務(wù),并保證這套 API 服務(wù)也是可以很容易橫向擴(kuò)展的。 

上線這個架構(gòu)圖已經(jīng)足夠簡單,我們羅列幾個關(guān)鍵點(diǎn):

  • 每個節(jié)點(diǎn)上都有一個叫 RegionServer 的程序來提供對數(shù)據(jù)的讀寫服務(wù)
  • 每個表被拆分成很多個 Region,然后均衡地分散在各個 RegionServer 上

另外有個 HMaster 的服務(wù),負(fù)責(zé)對表的創(chuàng)建、修改、刪除已經(jīng) Region 相關(guān)的各種管理操作。

很容易看出,HBase 的分布式和 HDFS 非常像,RegionServer 類似于 DataNode,HMaster 類似于 NameNode,Region 類似于 Block。

只要在 HDFS 層擴(kuò)容 DataNode,在 HBase 層擴(kuò)容 RegionServer,就很容易實(shí)現(xiàn) HBase 的橫向擴(kuò)展,來滿足更多數(shù)據(jù)的讀寫需求。

細(xì)心的人應(yīng)該發(fā)現(xiàn)了,圖里沒有體現(xiàn)元數(shù)據(jù)。在 HDFS 里元數(shù)據(jù)是由 NameNode 掌控的,類似的,HBase 里的元數(shù)據(jù)由 HMaster 來掌控。HBase 里的元數(shù)據(jù)保存的是一張表有哪些 Region,又各由哪個 RegionServer 提供服務(wù)。

這些元數(shù)據(jù),HBase 采用了很巧妙的方法保存 -- 像應(yīng)用數(shù)據(jù)那些以 HBase table 的形式保存,這樣就能像操作一張普通表一樣操作元數(shù)據(jù)了,實(shí)現(xiàn)上無疑簡單了很多。

而由于 HBase 的元數(shù)據(jù)以 Region 為粒度,遠(yuǎn)遠(yuǎn)比 HDFS 里的 block 粒度大多了,因此元數(shù)據(jù)的數(shù)據(jù)量一般也就不會成為性能瓶頸,也就不太需要再考慮元數(shù)據(jù)的橫向擴(kuò)展了。

至于高可用,存儲層面已經(jīng)有 HDFS 保障,服務(wù)層面只要提供多個 HMaster 做主備就行了。

存儲的話題聊到這里。下面來看看計算這塊。

和存儲類似,無論數(shù)據(jù)大小,我們可以把計算分為兩種類型:

  • 離線(offline)計算,或者叫批量(batch)計算/處理
  • 在線(online)計算,或者叫實(shí)時(realtime)計算、流(stream)計算/處理

區(qū)分批處理和流處理的另一個角度是處理數(shù)據(jù)的邊界。批處理對應(yīng) bounded 數(shù)據(jù),數(shù)據(jù)量的大小有限且確定,而流處理的數(shù)據(jù)是 unbounded 的,數(shù)據(jù)量沒有邊界,程序永遠(yuǎn)執(zhí)行下去不會停止。

在大數(shù)據(jù)領(lǐng)域,批量計算一般用于用于對響應(yīng)時間和延遲不敏感的場景。有些是業(yè)務(wù)邏輯本身就不敏感,比如天級別的報表,有些則是由于數(shù)據(jù)量特別大等原因而被迫犧牲了響應(yīng)時間和延遲。而相反,流計算則用于對響應(yīng)時間和延遲敏感的場景,如實(shí)時的 PV 計算等。

批量計算的延遲一般較大,在分鐘、小時甚至天級。流處理則一般要求在毫秒或秒級完成數(shù)據(jù)處理。值得一提的是,介于兩者之間,還有準(zhǔn)實(shí)時計算的說法,延遲通常在數(shù)秒到數(shù)十秒。準(zhǔn)實(shí)時計算很自然能想到是為了在延遲和處理數(shù)據(jù)量之間達(dá)到一個可以接受的平衡。

批量計算在大數(shù)據(jù)領(lǐng)域最老資歷的就是 MapReduce。MapReduce 和前面提到的 HDFS 合在一起就組成了 Hadoop。而 Hadoop 多年來一直是大數(shù)據(jù)領(lǐng)域事實(shí)上的標(biāo)準(zhǔn)基礎(chǔ)設(shè)施。從這一點(diǎn)也可以看出,我們按存儲和計算來對大數(shù)據(jù)技術(shù)做分類也是最基本的一種辦法。

MapReduce 作為一個分布式的計算框架(回想下前面說的分布式是解決大數(shù)據(jù)問題的默認(rèn)思路),編程模型起源于函數(shù)式編程語言里的 map 和 reduce 函數(shù)。

得益于 HDFS 已經(jīng)將數(shù)據(jù)以 block 為單位切割,MapReduce 框架也就可以很輕松地將數(shù)據(jù)的初步處理以多個 map 函數(shù)的形式分發(fā)到不同的服務(wù)器上并行執(zhí)行。map 階段處理的結(jié)果又以同樣的思路分布到不同的服務(wù)器上并行做第二階段的 reduce 操作,以得到想要的結(jié)果。

以大數(shù)據(jù)領(lǐng)域的「Hello World」-- 「Word Count」為例,要計算 100 個文件共 10 T 數(shù)據(jù)里每個單詞出現(xiàn)的次數(shù),在 map 階段可能就會有 100 個 mapper 并行去對自己分配到的數(shù)據(jù)做分詞,然后把同樣的單詞「shuffle」到同樣的 reducer 做聚合求和的操作,這些 reducer 同樣也是并行執(zhí)行,***獨(dú)立輸出各自的執(zhí)行結(jié)果,合在一起就是最終完整的結(jié)果。 

從上圖可以看到,shuffle 操作處理 map 階段的輸出以作為 reduce 階段的輸入,是個承上啟下的關(guān)鍵過程。這個過程雖然是 MapReduce 框架自動完成的,但由于涉及非常多的 IO 操作,而 IO 往往是數(shù)據(jù)處理流程中最消耗性能的部分,因此 shuffle 也就成了性能調(diào)優(yōu)的重點(diǎn)。

可以看到,正是采用了分布式計算的思想,利用了多臺服務(wù)器多核并行處理的方法,才使得我們能以足夠快的速度完成對海量數(shù)據(jù)的處理。

MapReduce 框架作為一個分布式計算框架,提供了基礎(chǔ)的大數(shù)據(jù)計算能力。但隨著使用場景越來越豐富,也慢慢暴露出一些問題。

資源協(xié)調(diào)

前面我們講分布式存儲的時候提到了 NameNode 這么一個統(tǒng)一管理的角色,類似的,分布式計算也需要有這么一個統(tǒng)一管理和協(xié)調(diào)的角色。更具體的說,這個角色需要承擔(dān)計算資源的協(xié)調(diào)、計算任務(wù)的分配、任務(wù)進(jìn)度和狀態(tài)的監(jiān)控、失敗任務(wù)的重跑等職責(zé)。

早期 MapReduce -- 即 MR1 -- 完整地實(shí)現(xiàn)了這些功能,居中統(tǒng)一協(xié)調(diào)的角色叫做 JobTracker,另外每個節(jié)點(diǎn)上會有一個 TaskTracker 負(fù)責(zé)收集本機(jī)資源使用情況并匯報給 JobTracker 作為分配資源的依據(jù)。

這個架構(gòu)的主要問題是 JobTracker 的職責(zé)太多了,在集群達(dá)到一定規(guī)模,任務(wù)多到一定地步后,很容易成為整個系統(tǒng)的瓶頸。

于是有了重構(gòu)之后的第二代 MapReduce -- MR2,并給它取了個新名字 YARN(Yet-Another-Resource-Negotiator)。 

JobTracker 的兩個核心功能 -- 資源管理和任務(wù)的調(diào)度/監(jiān)控被拆分開,分別由 ResourceManager 和 ApplicationMaster 來承擔(dān)。ResouerceManager 主要負(fù)責(zé)分配計算資源(其實(shí)還包括初始化和監(jiān)控 ApplicationMaster),工作變的很簡單,不再容易成為瓶頸,部署多個實(shí)例后也很容易實(shí)現(xiàn)高可用。而 ApplicationMaster 則是每個 App 各分配一個,所有 Job 的資源申請、調(diào)度執(zhí)行、狀態(tài)監(jiān)控、重跑等都由它來組織。這樣,負(fù)擔(dān)最重的工作分散到了各個 AM 中去了,瓶頸也就不存在了。

開發(fā)成本

為了使用 MapReduce 框架,你需要寫一個 Mapper 類,這個類要繼承一些父類,然后再寫一個 map 方法來做具體的數(shù)據(jù)處理。reduce 也類似??梢钥吹竭@個開發(fā)和調(diào)試成本還是不低的,尤其對于數(shù)據(jù)分析師等編程能力不那么突出的職位來說。

很自然的思路就是 SQL 化,要實(shí)現(xiàn)基本的數(shù)據(jù)處理,恐怕沒有比 SQL 更通用的語言了。

早期對 MapReduce 的 SQL 化主要有兩個框架實(shí)現(xiàn)。一個是 Apache Pig,一個是 Apache Hive。前者相對小眾,后者是絕大部分公司的選擇。

Hive 實(shí)現(xiàn)的基本功能就是把你的 SQL 語句解釋成一個個 MapReduce 任務(wù)去執(zhí)行。

比如我們現(xiàn)在創(chuàng)建這么一張測試表:

  1. create table test2018(id intname string, province string); 

然后通過 explain 命令來查看下面這條 select 語句的執(zhí)行計劃:

  1. explain select province, count(*) from test2018 group by province; 

 

可以看到,Hive 把剛才的 SQL 語句解析成了 MapReduce 任務(wù)。這條 SQL 很簡單,如果是復(fù)雜的 SQL,可能會被解析成很多個連續(xù)依賴執(zhí)行的 MapReduce 任務(wù)。

另外,既然是 SQL,很自然的,Hive 還提供了庫、表這類抽象,讓你來更好的組織你的數(shù)據(jù)。甚至傳統(tǒng)的數(shù)據(jù)倉庫技術(shù)也能很好地以 Hive 為基礎(chǔ)開展。這又是另一個很大的話題,這里不再展開。

計算速度

MapReduce 每個階段的結(jié)果都需要落磁盤,然后再讀出來給下一階段處理。由于是分布式系統(tǒng),所以也有很多需要網(wǎng)絡(luò)傳輸數(shù)據(jù)的情況。而磁盤 IO 和網(wǎng)絡(luò) IO 都是非常消耗時間的操作。后者可以通過數(shù)據(jù)本地性(locality)解決 -- 把任務(wù)分配到數(shù)據(jù)所在的機(jī)器上執(zhí)行,前者就很大程度地拖慢了程序執(zhí)行的速度。

在這個問題上解決的比較好的是 Apache Spark。 Spark 號稱基于內(nèi)存的分布式計算框架,所有計算都在內(nèi)存中進(jìn)行,只要當(dāng)內(nèi)存不夠時才會 spill 到磁盤。因此能盡可能地減少磁盤操作。

同時,Spark 基于 DAG(Directed Acyclic Graph)來組織執(zhí)行過程,知道了整個執(zhí)行步驟的先后依賴關(guān)系,也就有了優(yōu)化物理執(zhí)行計劃的可能,很多無謂和重復(fù)的 IO 操作也就被省略了。

另外一個不得不提的點(diǎn)是,MapReduce 編程模型太過簡單,導(dǎo)致很多情況下一些并不復(fù)雜的運(yùn)算卻需要好幾個 MapReduce 任務(wù)才能完成,這也嚴(yán)重拖累了性能。而 Spark 提供了類型非常豐富的操作,也很大程度上提升了性能。

編程模型

上一段提到 Spark 類型豐富的操作提升了性能,另一個好處就是開發(fā)復(fù)雜度也變低了很多。相比較之下,MapReduce 編程模型的表達(dá)能力就顯得非常羸弱了,畢竟很多操作硬要去套用先 map 再 reduce 會非常麻煩。

以分組求平均值為例,在 MapReduce 框架下,需要像前面說的那樣寫兩個類,甚至有人會寫成兩個 MapReduce 任務(wù)。

而在 Spark 里面,只要一句 ds.groupby(key).avg() 就搞定了。 真的是沒有對比就沒有傷害。

毫無疑問,每個人都希望數(shù)據(jù)越早算出來越好,所以實(shí)時計算或者叫流計算一直是研究和使用的熱點(diǎn)。

前面提到,Hadoop 是大數(shù)據(jù)領(lǐng)域的標(biāo)準(zhǔn)基礎(chǔ)設(shè)施,提供了 HDFS 作為存儲系統(tǒng),以及 MapReduce 作為計算引擎,但卻并沒有提供對流處理的支持。因此,流處理這個領(lǐng)域也就出現(xiàn)了很多競爭者,沒有形成早些年 MapReduce 那樣一統(tǒng)江湖的局面。

這里我們簡單看下目前流行度***的三個流處理框架:Spark Streaming、Storm 和 Flink。

既然能各自鼎立天下,這些框架肯定也都各有優(yōu)缺點(diǎn)。篇幅有限,這里我們挑選幾個典型的維度來做對比。

編程范式

常規(guī)來說,可以把編程范式或者通俗點(diǎn)說程序的寫法分為兩類:命令式(Imperative)和聲明式(Declarative)。前者需要一步步寫清楚「怎么做」,更接近機(jī)器,后者只用寫需要「做什么」,更接近人。前文提到 WordCount 的例子,MapReduce 的版本就屬于命令式,Spark 的版本就屬于聲明式。

不難看出,命令式更繁瑣但也賦予了程序員更強(qiáng)的控制力,聲明式更簡潔但也可能會失去一定的控制力。

延遲(latency)

延遲的概念很簡單,就是一條數(shù)據(jù)從產(chǎn)生到被處理完經(jīng)歷的時間。注意這里的時間是實(shí)際經(jīng)歷的時間,而不一定是真正處理的時間。

吞吐量(throughput)

吞吐量就是單位時間內(nèi)處理數(shù)據(jù)的數(shù)量。和上面的延遲一起通常被認(rèn)為是流處理系統(tǒng)在性能上最為重要的兩個指標(biāo)。

下面我們就從這幾個維度來看看這三個流處理框架。

Spark Streaming

Spark Streaming 和我們前面提到的用于離線批處理的 Spark 基于同樣的計算引擎,本質(zhì)上是所謂的 mirco-batch,只是這個 batch 可以設(shè)置的很小,也就有了近似實(shí)時的效果。

編程范式

和離線批處理的 Spark 一樣,屬于聲明式,提供了非常豐富的操作,代碼非常簡潔。

延遲

由于是 micro-batch,延遲相對來一條處理一條的實(shí)時處理引擎會差一些,通常在秒級。當(dāng)然可以把 batch 設(shè)的更小以減小延遲,但代價是吞吐量會降低。

由于是基于批處理做的流處理,所以就決定了 Spark Streaming 延遲再怎么調(diào)優(yōu)也達(dá)不到有些場景的要求。為了解決這個問題,目前尚未正式發(fā)布的 Spark 2.3 將會支持 continuous processing,提供不遜于 native streaming 的延遲。continuous processing 顧名思義摒棄了 mirco-batch 的偽流處理,使用和 native streaming 一樣的 long-running task 來處理數(shù)據(jù)。到時候?qū)⒁耘渲玫姆绞阶層脩糇约哼x擇 micro-batch 還是 continuous processing 來做流式處理。

吞吐量

由于是 micro-batch,吞吐量比嚴(yán)格意義上的實(shí)時處理引擎高不少。從這里也可以看到,micro-batch 是個有利有弊的選擇。

Storm

Storm 的編程模型某種程度上說和 MapReduce 很像,定義了 Spout 用來處理輸入,Bolt 用來做處理邏輯。多個 Spout 和 Bolt 互相連接、依賴組成 Topology。Spout 和 Bolt 都需要像 MR 那樣定義一些類再實(shí)現(xiàn)一些具體的方法。

編程范式

很顯然屬于命令式。

延遲

Storm 是嚴(yán)格意義上的實(shí)時處理系統(tǒng)(native streaming),來一條數(shù)據(jù)處理一條,所以延遲很低,一般在毫秒級別。

吞吐量

同樣,由于來一條數(shù)據(jù)處理一條,為了保證容錯(falt tolerance) 采用了逐條消息 ACK 的方式,吞吐量相對 Spark Streaming 這樣的 mirco-batch 引擎就差了不少。

需要補(bǔ)充說明的是,Storm 的升級版 Trident 做了非常大的改動,采用了類似 Spark Streaming 的 mirco-batch 模式,因此延遲比 Storm 高(變差了),吞吐量比 Storm 高(變好了),而編程范式也變成了開發(fā)成本更低的聲明式。

Flink

Flink 其實(shí)和 Spark 一樣都想做通用的計算引擎,這點(diǎn)上比 Storm 的野心要大。但 Flink 采用了和 Spark 完全相反的方式來支持自己本來不擅長的領(lǐng)域。Flink 作為 native streaming 框架,把批處理看做流處理的特殊情況來達(dá)到邏輯抽象上的統(tǒng)一。

  • 編程范式

典型的聲明式。

  • 延遲

和 Storm 一樣,F(xiàn)link 也是來一條處理一條,保證了很低的延遲。

  • 吞吐量

實(shí)時處理系統(tǒng)中,往往低延遲帶來的就是低吞吐量(Storm),高吞吐量又會導(dǎo)致高延遲(Spark Streaming)。這兩個性能指標(biāo)也是常見的 trade-off 了,通常都需要做取舍。

但 Flink 卻做到了低延遲和高吞吐兼得。關(guān)鍵就在于相比 Storm 每條消息都 ACK 的方式,F(xiàn)link 采取了 checkpoint 的方式來容錯,這樣也就盡可能地減小了對吞吐量的影響。

到此為止,批處理和流處理我們都有了大致的了解。不同的應(yīng)用場景總能二選一找到適合的方案。

然而,卻也有些情況使得我們不得不在同一個業(yè)務(wù)中同時實(shí)現(xiàn)批處理和流處理兩套方案:

  • 流處理程序故障,恢復(fù)時間超過了流數(shù)據(jù)的保存時間,導(dǎo)致數(shù)據(jù)丟失。
  • 類似多維度月活計算,精確計算需要保存所有用戶 id 來做去重,由此帶來的存儲開銷太大,因此只能使用 hyperloglog 等近似算法。
  • ...

這些場景下,往往會采用流處理保證實(shí)時性,再加批處理校正來保證數(shù)據(jù)正確性。由此還專門產(chǎn)生了一個叫 Lambda Architecture 的架構(gòu)。 

流處理層和批處理層各自獨(dú)立運(yùn)行輸出結(jié)果,查詢層根據(jù)時間選擇用哪份結(jié)果展示給用戶。比如最近一天用流處理的實(shí)時但不一定精確的結(jié)果,超過一天就用批處理不實(shí)時但精確的結(jié)果。

Lambda Architecture 確實(shí)能解決問題,但流處理和批處理兩套程序,再加上頂在前面的查詢服務(wù),帶來的開發(fā)和維護(hù)成本也不小。

因此,近年來也有人提出了 Kappa Architecture,帶來了另一種統(tǒng)一的思路,但也有明顯的缺點(diǎn)。限于篇幅這里不再贅述。

十一

計算框架是大數(shù)據(jù)領(lǐng)域競爭最激烈的方向之一,除了前面提到的方案,還有 Impla、Tez、 Presto、Samza 等等。很多公司都喜歡造輪子,并且都聲稱自己的輪子比別人的好。而從各個框架的發(fā)展歷程來看,又有很明顯的互相借鑒的意思。

在眾多選擇中,Spark 作為通用型分布式計算框架的野心和能力已經(jīng)得到充分的展示和證實(shí),并且仍然在快速地進(jìn)化: Spark SQL 支持了類 Hive 的純 SQL 數(shù)據(jù)處理,Spark Streaming 支持了實(shí)時計算,Spark MLlib 支持了機(jī)器學(xué)習(xí),Spark GraphX 支持了圖計算。而流處理和批處理底層執(zhí)行引擎的統(tǒng)一,也讓 Spark 在 Lambda Architecture 下的開發(fā)和維護(hù)成本低到可以接受。

所以,出于技術(shù)風(fēng)險、使用和維護(hù)成本的考慮,Spark 是我們做大數(shù)據(jù)計算的***。當(dāng)然,如果有些實(shí)際應(yīng)用場景 Spark 不能很好的滿足,也可以選擇其他計算框架作為補(bǔ)充。比如如果對延遲(latency) 非常敏感,那 Storm 和 Flink 就值得考慮了。

十二

如開篇所說,大數(shù)據(jù)是個非常廣的領(lǐng)域,初學(xué)者很容易迷失。希望通過這篇文章,能讓大家對大數(shù)據(jù)的基礎(chǔ)有個大概的了解。限于篇幅,很多概念和技術(shù)都點(diǎn)到即止,有興趣的同學(xué)可以再擴(kuò)展去學(xué)習(xí)。相信,打好了這個基礎(chǔ),再去學(xué)大數(shù)據(jù)領(lǐng)域的其他技術(shù)也會輕松一些。

責(zé)任編輯:未麗燕 來源: 漫談大數(shù)據(jù)
相關(guān)推薦

2016-12-12 08:48:24

2019-12-27 15:58:57

大數(shù)據(jù)IT互聯(lián)網(wǎng)

2024-06-07 08:47:00

2020-09-03 08:05:34

設(shè)計模式編程界

2020-05-12 10:20:39

K8s kubernetes中間件

2016-04-05 10:21:25

大數(shù)據(jù)元數(shù)據(jù)數(shù)據(jù)分析

2020-07-23 07:24:40

Kubernetes大數(shù)據(jù)開發(fā)

2021-04-14 09:04:03

大數(shù)據(jù)HDFS大數(shù)據(jù)開發(fā)

2021-03-15 14:02:21

大數(shù)據(jù)數(shù)據(jù)開發(fā)Spark

2018-07-11 13:33:43

大數(shù)據(jù)人工智能Hadoop

2017-01-22 21:30:39

大數(shù)據(jù)Kaggle函數(shù)

2016-12-02 19:19:35

大數(shù)據(jù)Hadoop

2020-09-04 15:38:19

Web前端開發(fā)項(xiàng)目

2017-11-20 16:17:50

智慧城市

2016-08-29 23:00:29

大數(shù)據(jù)數(shù)據(jù)分析

2013-05-06 09:14:26

BigQuery大數(shù)據(jù)分析大數(shù)據(jù)分析入門

2019-03-25 21:15:39

大數(shù)據(jù)數(shù)據(jù)科學(xué)書單

2015-11-13 10:06:27

數(shù)據(jù)科學(xué)大數(shù)據(jù)入門

2021-05-14 23:31:50

大數(shù)據(jù)計算機(jī)開發(fā)

2022-07-29 11:06:47

架構(gòu)開發(fā)
點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號