spark大数据的学习
（1）spark.rdd的處理
https://spark.apache.org/examples.html
spark.sql非常精辟：
https://github.com/apache/spark/blob/master/examples/src/main/python/sql/basic.py
（2）大數(shù)據(jù)架構(gòu)的一些資料
《前言 ：一個(gè)典型的大數(shù)據(jù)平臺架構(gòu)》
https://my.oschina.net/wangjiankui/blog/661705
頭條的數(shù)據(jù)傳輸以 Kafka 作為數(shù)據(jù)總線，所有實(shí)時(shí)和離線數(shù)據(jù)的接入都要通過 Kafka，包括日志、binlog 等。這里值得注意的是：盡早引入消息隊(duì)列，與業(yè)務(wù)系統(tǒng)解耦。
Kafka 數(shù)據(jù)通過 Dump 落地到 HDFS，供后續(xù)離線處理使用。隨著數(shù)據(jù)規(guī)模的增加，Dump 的實(shí)現(xiàn)也經(jīng)歷了幾個(gè)階段。最初實(shí)現(xiàn)用的是類似 Flume 模式的單機(jī)上傳，很快遇到了瓶頸，實(shí)現(xiàn)改成了通過 Storm 來實(shí)現(xiàn)多機(jī)分布式的上傳，支持的數(shù)據(jù)吞吐量大幅增加。
頭條的數(shù)據(jù)源很復(fù)雜，直接拿來做分析并不方便。但是到數(shù)據(jù)倉庫這一層級，會通過數(shù)據(jù)處理的過程，也就是 ETL，把它建設(shè)成一個(gè)層次完備的適合分析的一個(gè)個(gè)有價(jià)值的數(shù)倉。在數(shù)倉之上，就可以讓數(shù)據(jù)分析師和數(shù)據(jù) RD 通過 SQL 和多維分析等更高效的手段使用數(shù)據(jù)。
數(shù)據(jù)倉庫中數(shù)據(jù)表的元信息都放在 Hivemetastore 里，數(shù)據(jù)表在 HDFS 上的存儲格式以 Parquet 為主，這是一種列式存儲格式，對于嵌套數(shù)據(jù)結(jié)構(gòu)的支持也很好。
頭條有多種 ETL 的實(shí)現(xiàn)模式在并存，對于底層數(shù)據(jù)構(gòu)建，一種選擇是使用 Python 通過 HadoopStreaming 來實(shí)現(xiàn) Map Reduce 的任務(wù)，但現(xiàn)在更傾向于使用 Spark 直接生成 Parquet 數(shù)據(jù)，Spark 相比 MapReduce 有更豐富的處理原語，代碼實(shí)現(xiàn)可以更簡潔，也減少了中間數(shù)據(jù)的落地量。對于高層次的數(shù)據(jù)表，會直接使用 HiveSQL 來描述 ETL 過程。
今日頭條數(shù)據(jù)平臺架構(gòu)師
2014 年加入今日頭條，目前負(fù)責(zé)頭條基礎(chǔ)數(shù)據(jù)平臺的技術(shù)架構(gòu)，解決海量數(shù)據(jù)規(guī)模下推薦系統(tǒng)和用戶產(chǎn)品的統(tǒng)計(jì)分析問題，并見證了頭條數(shù)據(jù)平臺從無到有、從小到大的歷程。加入頭條前，曾就職于豆瓣負(fù)責(zé) Antispam 系統(tǒng)的研發(fā)。
基礎(chǔ)數(shù)據(jù)平臺的建設(shè)理念是通過提供整體解決方案，降低數(shù)據(jù)使用門檻，方便各種業(yè)務(wù)接入?；ヂ?lián)網(wǎng)產(chǎn)品的數(shù)據(jù)分析模式也是相對固定的，比如事件多維分析、留存分析、漏斗分析等，把這些分析模式抽象出工具，也能覆蓋住大部分常用需求。
同時(shí)，期望參與業(yè)務(wù)的人比如 PM 等能更直接的掌握數(shù)據(jù)，通過相關(guān)工具的支持自行實(shí)現(xiàn)數(shù)據(jù)需求，盡量解放業(yè)務(wù)部門工程師的生產(chǎn)力，不至于被各種臨時(shí)跑數(shù)需求困擾。而對于更專業(yè)的數(shù)據(jù)分析師的工作，也會提供更專業(yè)的工具支持。
http://www.infoq.com/cn/articles/qiniu-big-data-platform-evolution-and-analysis
https://zhuanlan.zhihu.com/p/38527834
如何設(shè)計(jì)實(shí)時(shí)數(shù)據(jù)平臺（上篇）
https://juejin.im/post/5b014a756fb9a07ab5092de1
https://blog.csdn.net/np4rHI455vg29y2/article/details/78954866
超級推薦：
https://zhuanlan.zhihu.com/p/26545566
一文讀懂大數(shù)據(jù)平臺——寫給大數(shù)據(jù)開發(fā)初學(xué)者的話!
https://blog.csdn.net/yeruby/article/details/51448188
SparkSQL與Hive on Spark的比較
它主要用于結(jié)構(gòu)化數(shù)據(jù)處理和對Spark數(shù)據(jù)執(zhí)行類SQL的查詢。通過Spark SQL，可以針對不同格式的數(shù)據(jù)執(zhí)行ETL操作（如JSON，Parquet，數(shù)據(jù)庫）然后完成特定的查詢操作。一般來說，Spark每支持一種新的應(yīng)用開發(fā)，都會引入一個(gè)新的Context及相應(yīng)的RDD，對于SQL這一特性來說，引入的就是SQLContext和SchemaRDD。注意：在Spark1.3之后，SchemaRDD已經(jīng)更名為DataFrame，但它本質(zhì)就類似一個(gè)RDD，因?yàn)榭梢詫ataFrame無縫的轉(zhuǎn)換成一個(gè)RDD。
結(jié)構(gòu)上Hive On Spark和SparkSQL都是一個(gè)翻譯層，把一個(gè)SQL翻譯成分布式可執(zhí)行的Spark程序。比如一個(gè)SQL：
SELECT item_type, sum(price)
FROM item
GROUP item_type;
1
2
3
上面這個(gè)SQL腳本交給Hive或者類似的SQL引擎，它會“告訴”計(jì)算引擎做如下兩個(gè)步驟：讀取item表，抽出item_type,price這兩個(gè)字段；對price計(jì)算初始的SUM（其實(shí)就是每個(gè)單獨(dú)的price作為自己的SUM）因?yàn)镚ROUP BY說需要根據(jù)item_type分組，所以設(shè)定shuffle的key為item_type從第一組節(jié)點(diǎn)分組后分發(fā)給聚合節(jié)點(diǎn)，讓相同的item_type匯總到同一個(gè)聚合節(jié)點(diǎn)，然后這些節(jié)點(diǎn)把每個(gè)組的Partial Sum再加在一起，就得到了最后結(jié)果。不管是Hive還是SparkSQL大致上都是做了上面這樣的工作。
需要理解的是，Hive和SparkSQL都不負(fù)責(zé)計(jì)算，它們只是告訴Spark，你需要這樣算那樣算，但是本身并不直接參與計(jì)算。
流式計(jì)算：
https://www.zhihu.com/question/19919196
還有一個(gè)名詞是“大數(shù)據(jù)處理引擎”，那么這個(gè)“引擎”和我們說的“框架”又有什么關(guān)系呢?其實(shí)并沒有區(qū)分他們的權(quán)威的定義，但一般來說，前者是實(shí)際負(fù)責(zé)處理操作的組件，而后者可以理解為用來完成同樣工作的一系列組件。比如Apache Hadoop可以看做是以MapReduce為默認(rèn)處理引擎的處理框架。
大數(shù)據(jù)處理框架的類型、比較和選擇
大數(shù)據(jù)系統(tǒng)的基本需求與傳統(tǒng)系統(tǒng)并沒有本質(zhì)上的不同。但大數(shù)據(jù)系統(tǒng)雖然具有海量的數(shù)據(jù)規(guī)模，但是對數(shù)據(jù)的接入和處理速度上也有較高的要求，而且在每個(gè)階段都要對數(shù)據(jù)進(jìn)行處理。這些特點(diǎn)還是為設(shè)計(jì)解決方案時(shí)提供了新的挑戰(zhàn)。
作者：佚名來源：36大數(shù)據(jù)|2017-09-06 17:05 收藏 分享
9月15日技術(shù)沙龍 | 與東華軟件、AWS、京東金融、餓了么四位大咖探討精準(zhǔn)運(yùn)維！
大數(shù)據(jù)處理框架的類型、比較和選擇
前言
說起大數(shù)據(jù)處理，一切都起源于Google公司的經(jīng)典論文：《MapReduce:Simplied Data Processing on Large Clusters》。在當(dāng)時(shí)(2000年左右)，由于網(wǎng)頁數(shù)量急劇增加，Google公司內(nèi)部平時(shí)要編寫很多的程序來處理大量的原始數(shù)據(jù)：爬蟲爬到的網(wǎng)頁、網(wǎng)頁請求日志;計(jì)算各種類型的派生數(shù)據(jù)：倒排索引、網(wǎng)頁的各種圖結(jié)構(gòu)等等。這些計(jì)算在概念上很容易理解，但由于輸入數(shù)據(jù)量很大，單機(jī)難以處理。所以需要利用分布式的方式完成計(jì)算，并且需要考慮如何進(jìn)行并行計(jì)算、分配數(shù)據(jù)和處理失敗等等問題。
針對這些復(fù)雜的問題，Google決定設(shè)計(jì)一套抽象模型來執(zhí)行這些簡單計(jì)算，并隱藏并發(fā)、容錯(cuò)、數(shù)據(jù)分布和均衡負(fù)載等方面的細(xì)節(jié)。受到Lisp和其它函數(shù)式編程語言map、reduce思想的啟發(fā)，論文的作者意識到許多計(jì)算都涉及對每條數(shù)據(jù)執(zhí)行map操作，得到一批中間key/value對，然后利用reduce操作合并那些key值相同的k-v對。這種模型能很容易實(shí)現(xiàn)大規(guī)模并行計(jì)算。
事實(shí)上，與很多人理解不同的是，MapReduce對大數(shù)據(jù)計(jì)算的最大貢獻(xiàn)，其實(shí)并不是它名字直觀顯示的Map和Reduce思想(正如上文提到的，Map和Reduce思想在Lisp等函數(shù)式編程語言中很早就存在了)，而是這個(gè)計(jì)算框架可以運(yùn)行在一群廉價(jià)的PC機(jī)上。MapReduce的偉大之處在于給大眾們普及了工業(yè)界對于大數(shù)據(jù)計(jì)算的理解：它提供了良好的橫向擴(kuò)展性和容錯(cuò)處理機(jī)制，至此大數(shù)據(jù)計(jì)算由集中式過渡至分布式。以前，想對更多的數(shù)據(jù)進(jìn)行計(jì)算就要造更快的計(jì)算機(jī)，而現(xiàn)在只需要添加計(jì)算節(jié)點(diǎn)。
話說當(dāng)年的Google有三寶：MapReduce、GFS和BigTable。但Google三寶雖好，尋常百姓想用卻用不上，原因很簡單：它們都不開源。于是hadoop應(yīng)運(yùn)而生，初代Hadoop的MapReduce和HDFS即為Google的MapReduce和GFS的開源實(shí)現(xiàn)(另一寶BigTable的開源實(shí)現(xiàn)是同樣大名鼎鼎的HBase)。自此，大數(shù)據(jù)處理框架的歷史大幕正式的緩緩拉開。
一、基礎(chǔ)
“大數(shù)據(jù)”一詞的確切定義其實(shí)是很難給出的，因?yàn)椴煌娜?供應(yīng)商、從業(yè)者、商業(yè)公司等)對它的理解也并不完全一致。通常來講，大數(shù)據(jù)是：
大數(shù)據(jù)集
用于處理大數(shù)據(jù)集的某類技術(shù)
此處的“大數(shù)據(jù)集”是指一個(gè)數(shù)據(jù)集的數(shù)據(jù)量太大以至于無法使用傳統(tǒng)工具或單機(jī)方式來處理和存儲，而處理技術(shù)包括數(shù)據(jù)接入、數(shù)據(jù)持久化存儲、數(shù)據(jù)計(jì)算和分析、數(shù)據(jù)展示(可視化)等等。
大數(shù)據(jù)系統(tǒng)的基本需求與傳統(tǒng)系統(tǒng)并沒有本質(zhì)上的不同。但大數(shù)據(jù)系統(tǒng)雖然具有海量的數(shù)據(jù)規(guī)模，但是對數(shù)據(jù)的接入和處理速度上也有較高的要求，而且在每個(gè)階段都要對數(shù)據(jù)進(jìn)行處理。這些特點(diǎn)還是為設(shè)計(jì)解決方案時(shí)提供了新的挑戰(zhàn)。
在2001年，美國Gartner公司的Doug Laney首先提出了“3V”模型來描述大數(shù)據(jù)處理系統(tǒng)與傳統(tǒng)數(shù)據(jù)處理系統(tǒng)的不同：
Volume
待處理數(shù)據(jù)的規(guī)模在很大程度決定了系統(tǒng)是否為大數(shù)據(jù)系統(tǒng)。大數(shù)據(jù)系統(tǒng)中的數(shù)據(jù)規(guī)?？赡鼙葌鹘y(tǒng)處理系統(tǒng)中的數(shù)據(jù)集大幾個(gè)數(shù)量級，這也為數(shù)據(jù)處理和存儲帶來了更多的挑戰(zhàn)。由于數(shù)據(jù)處理和存儲等工作超出了單臺計(jì)算機(jī)所能達(dá)到的性能極限，所以大數(shù)據(jù)系統(tǒng)通常采用集群方式。集群方式更加考驗(yàn)資源的分配和協(xié)調(diào)，集群管理和任務(wù)分配算法變得越來越重要。
Velocity
大數(shù)據(jù)與其他數(shù)據(jù)系統(tǒng)另一個(gè)顯著的差異體現(xiàn)在數(shù)據(jù)的“流動(dòng)”速度。在大數(shù)據(jù)系統(tǒng)中，數(shù)據(jù)經(jīng)常從多種數(shù)據(jù)源流入系統(tǒng)，并且以一種近實(shí)時(shí)的方式進(jìn)行處理。數(shù)據(jù)被持續(xù)不斷的接入、修改、處理和分析以便能夠跟得上新數(shù)據(jù)的接入速度。由于近實(shí)時(shí)處理可以盡早的提供有價(jià)值的信息，目前很多商業(yè)公司更加青睞于實(shí)時(shí)處理系統(tǒng)而不是傳統(tǒng)的批處理系統(tǒng)。
Variety
大數(shù)據(jù)系統(tǒng)的問題通常是其他系統(tǒng)所不具備的，因?yàn)樗幚淼臄?shù)據(jù)來源廣泛。數(shù)據(jù)源可以是應(yīng)用程序的日志信息，也可以是社交媒體的用戶信息，甚至是物理設(shè)備傳感器的采集數(shù)據(jù)。不論何種數(shù)據(jù)，大數(shù)據(jù)系統(tǒng)的目標(biāo)都是在海量數(shù)據(jù)中尋找有用的數(shù)據(jù)。
那么大數(shù)據(jù)系統(tǒng)實(shí)際上是如何處理數(shù)據(jù)的呢?雖然不同公司的架構(gòu)設(shè)計(jì)不盡相同，但我們可以總結(jié)出一個(gè)基本的流程。下面介紹的流程雖然不是適用于所有情況，但它們確實(shí)被廣泛使用。大數(shù)據(jù)處理的基本流程是：
接入數(shù)據(jù)到系統(tǒng)中
將數(shù)據(jù)持久化到存儲系統(tǒng)
計(jì)算和分析數(shù)據(jù)
展示結(jié)果(可視化)
4. 大數(shù)據(jù)處理框架的定義
說完了大數(shù)據(jù)，我們來說說本文的重點(diǎn)——大數(shù)據(jù)處理框架。大數(shù)據(jù)處理框架負(fù)責(zé)對大數(shù)據(jù)系統(tǒng)中的數(shù)據(jù)進(jìn)行計(jì)算。數(shù)據(jù)包括從持久存儲中讀取的數(shù)據(jù)或通過消息隊(duì)列等方式接入到系統(tǒng)中的數(shù)據(jù)，而計(jì)算則是從數(shù)據(jù)中提取信息的過程。除了大數(shù)據(jù)處理框架，有些同學(xué)可能還聽到過“大數(shù)據(jù)計(jì)算框架”、“大數(shù)據(jù)框架”，這些術(shù)語沒有嚴(yán)格的區(qū)分，但基本可以理解為是一種東西，只不過是對“big data processing framework”不同的翻譯(大數(shù)據(jù)框架是“big data framework”的翻譯)。
還有一個(gè)名詞是“大數(shù)據(jù)處理引擎”，那么這個(gè)“引擎”和我們說的“框架”又有什么關(guān)系呢?其實(shí)并沒有區(qū)分他們的權(quán)威的定義，但一般來說，前者是實(shí)際負(fù)責(zé)處理操作的組件，而后者可以理解為用來完成同樣工作的一系列組件。比如Apache Hadoop可以看做是以MapReduce為默認(rèn)處理引擎的處理框架。
二、數(shù)據(jù)處理框架分類
不論是系統(tǒng)中存在的歷史數(shù)據(jù)，還是持續(xù)不斷接入系統(tǒng)中的實(shí)時(shí)數(shù)據(jù)，只要數(shù)據(jù)是可訪問的，我們就可以對數(shù)據(jù)進(jìn)行處理。按照對所處理的數(shù)據(jù)形式和得到結(jié)果的時(shí)效性分類，數(shù)據(jù)處理框架可以分為兩類：
1、批處理系統(tǒng)
2、流處理系統(tǒng)
批處理是一種用來計(jì)算大規(guī)模數(shù)據(jù)集的方法。批處理的過程包括將任務(wù)分解為較小的任務(wù)，分別在集群中的每個(gè)計(jì)算機(jī)上進(jìn)行計(jì)算，根據(jù)中間結(jié)果重新組合數(shù)據(jù)，然后計(jì)算和組合最終結(jié)果。當(dāng)處理非常巨大的數(shù)據(jù)集時(shí)，批處理系統(tǒng)是最有效的。
典型的批處理系統(tǒng)就是Apache Hadoop。而流處理則對由連續(xù)不斷的單條數(shù)據(jù)項(xiàng)組成的數(shù)據(jù)流進(jìn)行操作，注重?cái)?shù)據(jù)處理結(jié)果的時(shí)效性。典型的流處理系統(tǒng)有Apache Storm，Apache Samza。還有一種系統(tǒng)，同時(shí)具備批處理與流處理的能力，這種稱為混合處理系統(tǒng)，比如Apache Spark，Apache Flink。接下來我們來詳細(xì)介紹這三種處理系統(tǒng)。
三、批處理系統(tǒng)
批處理系統(tǒng)在大數(shù)據(jù)世界中有著悠久的歷史。批處理系統(tǒng)主要操作大量的、靜態(tài)的數(shù)據(jù)，并且等到全部處理完成后才能得到返回的結(jié)果。批處理系統(tǒng)中的數(shù)據(jù)集一般符合以下特征：
有限： 數(shù)據(jù)集中的數(shù)據(jù)必須是有限的(無限的數(shù)據(jù)一批就處理不完了啊。連續(xù)不斷的數(shù)據(jù)一般會使用流處理系統(tǒng)來進(jìn)行處理，我們后面會講到)
持久： 批處理系統(tǒng)處理的數(shù)據(jù)一般存儲在持久存儲系統(tǒng)上(比如硬盤上、數(shù)據(jù)庫中)
海量： 極海量的數(shù)據(jù)通常只能使用批處理系統(tǒng)來處理。批處理系統(tǒng)在設(shè)計(jì)之初就充分的考慮了數(shù)據(jù)量巨大的問題，實(shí)際上批處理系統(tǒng)也是為此而生的。
由于批處理系統(tǒng)在處理海量的持久數(shù)據(jù)方面表現(xiàn)出色，所以它通常被用來處理歷史數(shù)據(jù)，很多OLAP(在線分析處理)系統(tǒng)的底層計(jì)算框架就是使用的批處理系統(tǒng)。但是由于海量數(shù)據(jù)的處理需要耗費(fèi)很多時(shí)間，所以批處理系統(tǒng)一般不適合用于對延時(shí)要求較高的場景。
Apache Hadoop
說起大數(shù)據(jù)處理框架，永遠(yuǎn)也繞不開Hadoop。Hadoop是首個(gè)在開源社區(qū)獲得極大關(guān)注的大數(shù)據(jù)處理框架，在很長一段時(shí)間內(nèi)，它幾乎可以作為大數(shù)據(jù)技術(shù)的代名詞。在2.0版本以后，Hadoop由以下組件組成：
Hadoop分布式文件系統(tǒng)HDFS：HDFS是一種分布式文件系統(tǒng)，它具有很高的容錯(cuò)性，適合部署在廉價(jià)的機(jī)器集群上。HDFS能提供高吞吐量的數(shù)據(jù)訪問，非常適合在大規(guī)模數(shù)據(jù)集上使用。它可以用于存儲數(shù)據(jù)源，也可以存儲計(jì)算的最終結(jié)果。
資源管理器YARN：YARN可以為上層應(yīng)用提供統(tǒng)一的資源管理和調(diào)度，它可以管理服務(wù)器的資源(主要是CPU和內(nèi)存)，并負(fù)責(zé)調(diào)度作業(yè)的運(yùn)行。在Hadoop中，它被設(shè)計(jì)用來管理MapReduce的計(jì)算服務(wù)。但現(xiàn)在很多其他的大數(shù)據(jù)處理框架也可以將YARN作為資源管理器，比如Spark。
MapReduce：即為Hadoop中默認(rèn)的數(shù)據(jù)處理引擎，也是Google的MapReduce論文思想的開源實(shí)現(xiàn)。使用HDFS作為數(shù)據(jù)源，使用YARN進(jìn)行資源管理。
從今天的眼光來看，MapReduce作為Hadoop默認(rèn)的數(shù)據(jù)處理引擎，存在著很多的不足。比如：編程模型抽象程度較低，僅支持Map和Reduce兩種操作，需要手工編寫大量的代碼;Map的中間結(jié)果需要寫入磁盤，多個(gè)MR之間需要使用HDFS交換數(shù)據(jù)，因此不適合迭代計(jì)算(機(jī)器學(xué)習(xí)、圖計(jì)算);任務(wù)的啟動(dòng)和調(diào)度開銷較大等。隨著更多高性能處理引擎的發(fā)展，目前在企業(yè)中使用MapReduce進(jìn)行計(jì)算的應(yīng)用已經(jīng)呈下降趨勢(HDFS及YARN仍然被廣泛使用)，但雖然如此，MapReduce作為最早的大數(shù)據(jù)處理引擎，仍然值得被我們銘記。
四、流處理系統(tǒng)
批處理系統(tǒng)好理解，那什么是流處理系統(tǒng)呢?小學(xué)的時(shí)候我們都做過這么一道數(shù)學(xué)題：一個(gè)水池有一個(gè)進(jìn)水管和一個(gè)出水管，只打開進(jìn)水管8個(gè)小時(shí)充滿水，只打開出水管6個(gè)小時(shí)流光水，那么同時(shí)打開進(jìn)水管和出水管，水池多長時(shí)間充滿水?
好吧，這道題的答案是永遠(yuǎn)也充不滿……因?yàn)槌鏊艹鏊容^快嘛。流處理系統(tǒng)就相當(dāng)于這個(gè)水池，把流進(jìn)來的水(數(shù)據(jù))進(jìn)行加工，比如加鹽讓它變成鹽水，然后再把加工過的水(數(shù)據(jù))從出水管放出去。這樣，數(shù)據(jù)就像水流一樣永不停止，而且在水池中就被處理過了。所以，這種處理永不停止的接入數(shù)據(jù)的系統(tǒng)就叫做流處理系統(tǒng)。
流處理系統(tǒng)與批處理系統(tǒng)所處理的數(shù)據(jù)不同之處在于，流處理系統(tǒng)并不對已經(jīng)存在的數(shù)據(jù)集進(jìn)行操作，而是對從外部系統(tǒng)接入的的數(shù)據(jù)進(jìn)行處理。流處理系統(tǒng)可以分為兩種：
逐項(xiàng)處理： 每次處理一條數(shù)據(jù)，是真正意義上的流處理。
微批處理： 這種處理方式把一小段時(shí)間內(nèi)的數(shù)據(jù)當(dāng)作一個(gè)微批次，對這個(gè)微批次內(nèi)的數(shù)據(jù)進(jìn)行處理。
不論是哪種處理方式，其實(shí)時(shí)性都要遠(yuǎn)遠(yuǎn)好于批處理系統(tǒng)。因此，流處理系統(tǒng)非常適合應(yīng)用于對實(shí)時(shí)性要求較高的場景，比如日志分析，設(shè)備監(jiān)控、網(wǎng)站實(shí)時(shí)流量變化等等。由于很多情況下，我們想要盡快看到計(jì)算結(jié)果，所以近些年流處理系統(tǒng)的應(yīng)用越來越廣泛。下面我們來了解兩種流處理系統(tǒng)。
Apache Storm
Apache Storm是一種側(cè)重于低延遲的流處理框架，它可以處理海量的接入數(shù)據(jù)，以近實(shí)時(shí)方式處理數(shù)據(jù)。Storm延時(shí)可以達(dá)到亞秒級。Storm含有如下關(guān)鍵概念：
Topology：Storm topology中封裝了實(shí)時(shí)應(yīng)用程序的邏輯。Storm topology類似于MapReduce作業(yè)，但區(qū)別是MapReduce最終會完成，而topology則會一直運(yùn)行(除非被強(qiáng)制停止)。Topology是由spouts和bolts組成的DAG(有向無環(huán)圖)。
Stream:Stream是一種不斷被接入Storm中的無界的數(shù)據(jù)序列。
Spout：Spout是topology中Stream的源。Spout從外部數(shù)據(jù)源讀取數(shù)據(jù)并接入到Strom系統(tǒng)中
Bolt：Bolt用于Storm中的數(shù)據(jù)處理，它可以進(jìn)行過濾、聚合、連接等操作。將不同的bolt連接組成完整的數(shù)據(jù)處理鏈條，最后一個(gè)bolt用來輸出(到文件系統(tǒng)或數(shù)據(jù)庫等)。
Storm的基本思想是使用spout拉取stream(數(shù)據(jù))，并使用bolt進(jìn)行處理和輸出。默認(rèn)情況下Storm提供了“at least once”的保證，即每條數(shù)據(jù)被至少消費(fèi)一次。當(dāng)一些特殊情況(比如服務(wù)器故障等)發(fā)生時(shí)，可能會導(dǎo)致重復(fù)消費(fèi)。為了實(shí)現(xiàn)“exactly once”(即有且僅有一次消費(fèi))，Storm引入了Trident。Trident可以將Storm的單條處理方式改變?yōu)槲⑴幚矸绞?#xff0c;但同時(shí)也會對Storm的處理能力產(chǎn)生一定的影響。
值得一提的是，一些國內(nèi)的公司在Storm的基礎(chǔ)上進(jìn)行了改進(jìn)，為推動(dòng)流處理系統(tǒng)的發(fā)展做出了很大貢獻(xiàn)。阿里巴巴的JStorm參考了Storm，并在網(wǎng)絡(luò)IO、線程模型、資源調(diào)度及穩(wěn)定性上做了改進(jìn)。而華為的StreamCQL則為Storm提供了SQL查詢語義。
Apache Samza
提到Apache Samza，就不得不提到當(dāng)前最流行的大數(shù)據(jù)消息中間件：Apache Kafka。Apache Kafka是一個(gè)分布式的消息中間件系統(tǒng)，具有高吞吐、低延時(shí)等特點(diǎn)，并且自帶了容錯(cuò)機(jī)制。以下是Kafka的關(guān)鍵概念：
Broker：由于Kafka是分布式消息中間件，所以需要多個(gè)節(jié)點(diǎn)來存儲數(shù)據(jù)。Broker即為Kafka集群中的單個(gè)節(jié)點(diǎn)。
Topic：用于存儲寫入Kafka的數(shù)據(jù)流。如同它的字面含義——主題，不同主題的數(shù)據(jù)流最好寫入不同的topic，方便后續(xù)的處理。
Partition：每個(gè)topic都有1到多個(gè)partition，便于分散到不同的borker中。多個(gè)partition的數(shù)據(jù)合并在一起組成了topic完整的數(shù)據(jù)。
Producer：消息的生產(chǎn)者，用來將消息寫入到Kafka集群。
Consumer：消息的消費(fèi)者，用來讀取Kafka中的消息并進(jìn)行處理。
雖然Kafka被廣泛應(yīng)用于各種流處理系統(tǒng)做數(shù)據(jù)源，但Samza可以更好的發(fā)揮Kafka架構(gòu)的優(yōu)勢。根據(jù)官網(wǎng)的解釋，Samza由三個(gè)層次組成：
數(shù)據(jù)流層
執(zhí)行層
處理層
支持三個(gè)層次的組件分別為：
Kafka
YARN
Samza API
也就是說，Samza使用Kafka提供了數(shù)據(jù)流，使用YARN進(jìn)行資源管理，自身僅提供了操作數(shù)據(jù)流的API。Samza對Kafka和YARN的依賴在很多方面上與MapReduce對HDFS和YARN的依賴相似。
如果已經(jīng)擁有Hadoop集群和Kafka集群環(huán)境，那么使用Samza作為流處理系統(tǒng)無疑是一個(gè)非常好的選擇。由于可以很方便的將處理過的數(shù)據(jù)再次寫入Kafka，Samza尤其適合不同團(tuán)隊(duì)之間合作開發(fā)，處理不同階段的多個(gè)數(shù)據(jù)流。
五、混合處理系統(tǒng)：批處理和流處理
一些處理框架既可以進(jìn)行批處理，也可以進(jìn)行流處理。這些框架可以使用相同或相關(guān)的API處理歷史和實(shí)時(shí)數(shù)據(jù)。當(dāng)前主流的混合處理框架主要為Spark和Flink。
雖然專注于一種處理方式可能非常適合特定場景，但是混合框架為數(shù)據(jù)處理提供了通用的解決方案。
http://bigdata.51cto.com/art/201709/550663.ht
大數(shù)據(jù)處理框架的類型、比較和選擇
Apache Spark
如果說如今大數(shù)據(jù)處理框架處于一個(gè)群星閃耀的年代，那Spark無疑就是所有星星中最閃亮的那一顆。Spark由加州大學(xué)伯克利分校AMP實(shí)驗(yàn)室開發(fā)，最初的設(shè)計(jì)受到了MapReduce思想的啟發(fā)，但不同于MapReduce的是，Spark通過內(nèi)存計(jì)算模型和執(zhí)行優(yōu)化大幅提高了對數(shù)據(jù)的處理能力(在不同情況下，速度可以達(dá)到MR的10-100倍，甚至更高)。相比于MapReduce，Spark具有如下優(yōu)點(diǎn)：
提供了內(nèi)存計(jì)算模型RDD(Resilient Distributed Dataset，彈性分布式數(shù)據(jù)集)，將數(shù)據(jù)讀入內(nèi)存中生成一個(gè)RDD，再對RDD進(jìn)行計(jì)算。并且每次計(jì)算結(jié)果可以緩存在內(nèi)存中，減少了磁盤IO。因此很適用于迭代計(jì)算。
不同于MapReduce的MR模型，Spark采用了DAG編程模型，將不同步驟的操作串聯(lián)成一個(gè)有向無環(huán)圖，可以有效減少任務(wù)間的數(shù)據(jù)傳遞，提高了性能。
提供了豐富的編程模型，可以輕松實(shí)現(xiàn)過濾、連接、聚合等操作，代碼量相比MapReduce少到令人發(fā)指，因此可以提高開發(fā)人員的生產(chǎn)力。
支持Java、Scala、Python和R四種編程語言，為不同語言的使用者降低了學(xué)習(xí)成本。
而Spark的流處理能力，則是由Spark Streaming模塊提供的。Spark在設(shè)計(jì)之初與MapReduce一樣是用于批處理系統(tǒng)，為了適應(yīng)于流處理模式，Spark提出了微批次(Micro-Batch)的概念，即把一小段時(shí)間內(nèi)的接入數(shù)據(jù)作為一個(gè)微批次來處理。這樣做的優(yōu)點(diǎn)是在設(shè)計(jì)Spark Streaming時(shí)可以很大程度上重用批處理模塊(Spark Core)的代碼，開發(fā)人員也不必學(xué)習(xí)兩套編程模型。但缺點(diǎn)就是，與Storm等原生的流處理系統(tǒng)相比，Spark Streaming的延時(shí)會相對高一些。
除了最初開發(fā)用于批處理的Spark Core和用于流處理的Spark Streaming，Spark還提供了其他編程模型用于支持圖計(jì)算(GraphX)、交互式查詢(Spark SQL)和機(jī)器學(xué)習(xí)(MLlib)。
但Spark也不是沒有缺點(diǎn)。在批處理領(lǐng)域，由于內(nèi)存是比硬盤更昂貴的資源，所以Spark集群的成本比MapReduce集群更高。而在流處理領(lǐng)域，微批次的架構(gòu)使得它的延時(shí)要比Storm等流處理系統(tǒng)略高。不過瑕不掩瑜，Spark依然是如今最炙手可熱的數(shù)據(jù)處理框架。
該架構(gòu)包括以下組件：
?Stream / Event Processing
? Oracle Stream Explorer 持續(xù)處理傳入數(shù)據(jù)、分析和完善模式，并在檢測到情況時(shí)引發(fā)事件。Stream
Explorer 在開放服務(wù)網(wǎng)關(guān) (OSGi) 容器中運(yùn)行，可在任何 Java 運(yùn)行時(shí)環(huán)境中工作。它提供了一個(gè)業(yè)務(wù)級
用戶界面，允許在不掌握底層事件技術(shù)特征的情況下解釋數(shù)據(jù)流。.它可以在內(nèi)部部署，也可以在
Oracle 公有云中部署（物聯(lián)網(wǎng)云服務(wù)）。
總結(jié)
以上是生活随笔為你收集整理的spark大数据的学习的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 算法和数据结构(b站尚硅谷韩老师教程学习
- 下一篇： 5600高流明更清晰 NEC CF660