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