【Spark深入學習 -10】基於spark構建企業級流處理系統
----本節內容-------
1.流式處理系統背景
1.1 技術背景
1.2 Spark技術很火
2.流式處理技術介紹
2.1流式處理技術概念
2.2流式處理應用場景
2.3流式處理系統分類
3.流式處理技術關鍵技術
3.1流式處理系統管道構建
3.2流式處理系統關鍵技術
3.3用戶行為分析系統介紹
4.問題答疑
5.參考資料
---------------------
1、流式處理技術
1.1 技術背景
業務驅動技術發展，脫了了業務的技術，最多就是一個研究性的東西，流式處理技術的火爆源於業內對計算速度的需求。目前互聯網公司、運營商、物聯網公司等對流式處理技術的需求來源是多方面的，一是企業確實每分每秒都在產生海量數據，二是管理層對數據的價值有更高的認識，三是技術的發展，尤其是Hadoop等技術，讓數據變現成為可能【個人想法：關於大數據如何變現，其實是一個大大的課題】。
通過大數據技術，分析挖掘，產生有價值的結論，或者支撐公司日常運營，或者賣個用戶或者第三方，完成數據到信息到利潤的轉變，而流式處理技術是大數據技術的一個非常重要的技術方向。流式處理技術被越來越多的企業應用到實踐中，根據行業的不同，流式數據的來源也不一樣，有如下幾大類：
· 用戶點擊日誌
在App或者網頁中嵌入日誌采集程序，埋點，跟蹤用戶的點擊行為，這種以互聯網公司為典型代表，有BAT等，比如京東購買東西，點擊搜索的時候就產生一條日誌，ip，瀏覽器，關鍵字等。
·機器日誌
機器產生的日誌信息，如CPU、內存日誌等，（個人想法：這個也只有巨無霸公司才有這樣的需求，一般的公司服務器不會產生如此多的數據，要用到Hadoop技術，一個不大不小的集群硬件、人才、運維也是不小的投資）
· 終端設備產生的數據
比如物聯網和攝像頭，確實物聯網傳感設備是能夠產生海量數據的，尤其是做智慧城市項目的物聯網公司，在各個城市部署窄帶基站，通過傳感設備，每分每秒都在產生數據，確實驚人。但是對於攝像頭這塊，還是有很多問題的，傳統的攝像頭采集到的數據都是非結構化數據，想利用大數據技術做分析，難度和成本都非常大，新型攝像頭能采集結構化數據，比較容易做數據分析，但是成本昂貴。
1.2 Spark技術很火
1）Spark技術非常火
Spark火起來，第一是發展越來越成熟，並且不僅僅局限於做計算框架，第二是有一幫人在推Spark，時不時的去推，去組織峰會，舉辦論壇，好的技術很多，但是能被大家廣泛知道的好技術並不多，背後有一只手在引導大家去認識他，認識之後發現確實還可以，那麽久火了。火不火用數據說話，下面是谷歌12年至今關於spark和hadoop關鍵字的搜所量。
2）Spark組件誰更火
這個排名可以，董給出的這個可以調整自己的學習精力，先學哪個後學哪個，有個側重，搜索量
saprk sql >spark streaming >mllib，而對於SparkR，GraphX這些就相對小眾一些。
3）大數據人才的需求
這個就沒有啥說的，鬼知道是神馬行情，而且薪資和能力有關，招聘行情和季節有關，想切身了解，海投一輪簡歷就知道水深水淺了。下面的數據僅供參考。
2.流式處理應用場景
2.1流式處理技術概念
董先生將主要介紹是關於流式處理技術概念性的東西，不做介紹具體技術細節，用最簡單的話將抽象、專業的東西表達出來。根據我的筆記，大意如下：
企業都有海量的數據，數據是怎麽來的，如何形成海量的數據的？其實和流水是一樣，都是通過日積月累，將數據慢慢積累，一點點跟流水一樣積少成多，跟流水一樣流進企業的數據庫。
學院派一點描述流式數據：流式數據是大數據環境下的一種數據形態，其理論誕生於20世紀末，並在雲計算和物聯網發展下逐步成為當前的研究熱點。流式數據與傳統的數據是相對的。與靜態、批處理和持久化的數據庫相比，流式計算以連續、無邊界和瞬時性為特征，適合高速並發和大規模數據實時處理的場景。
大數據環境下，流式數據作為一種新型的數據類型，是實時數據處理所面向的數據類型，其相關研究發展迅速。這種實時的流式數據，存在如下幾個特征：
-
實時、高速：數據能以高並發的方式迅速到達，業務計算要求快速連續相應。數據處理的速度至少能夠匹配數據到達的速度。
-
無邊界：數據到達、處理和向後傳遞均是持續不斷的。
-
瞬時性和有限持久性：通常情況下，原始數據在單遍掃描，處理後丟棄，並不進行保存；只有計算結果和部分中間數據在有限時間內被保存和向後傳遞。
-
價值的時間偏倚性：隨著時間的流逝，數據中所蘊含的知識價值往往也在衰減，也即流中數據項的重要程度是不同的，最近到達的數據往往比早先到達的數據更有價值。
2.2 流式處理應用場景
在實際生產中，有 哪些場景帶來實際價值，董先生介紹了以下幾個方面：
1）. 社交網絡趨勢追蹤
趨勢追中，微信、微博數據，搜索量，點擊量的追蹤，某個時間段達到了頂峰，達到熱門 ->新聞搞
2）.實時推薦系統
淘寶購買的時候的推薦，優酷土豆等中看完視頻後，會列出視頻中還有哪些人瀏覽了這個視頻，哪些視頻和你觀看的視頻相似等等，
3）網絡指標實時統計
4）廣告系統
5）信用卡欺詐
2.3 流式處理系統分類
我覺的這個圖非常好，簡單明了，結合董先生講的東西，加上我自己的理解進一步闡述一下。流式處理系統主要分為三類：1）批處理，2）微批處理，3)流式處理
1).批處理
一次性處理，一批一批，高吞吐量，犧牲延遲，面向靜態數據集，分鐘或者小時級別，MR,SPARK都是批處理。
2).流式處理
面向行的和面向微批處理的 ,來一條處理一條，面向行級別，延遲低，毫秒級，如storm(毫秒級),Apache samza（亞秒級）.
3).微處理
介於1和2之間，處理每一批都足夠快，模式上將批處理改成流處理，但是處理數據的粒度沒有流處理那麽小，流處理是行級別，微處理，是多行，一系列行積攢起來後處理，以spark streaming做為典型代表。link也是，來一條積攢一會再來處理。
其實對於實時性能要求非常非常高的需求場景，應該有但是不多，董先生介紹微處理，既能解決批處理解決的問題，又能解決流式處理的問題，在大部分企業就已經足夠用了。所以融合了批處理和流式計算的引擎逐漸流行，充分結合批處理和流式計算殷勤的優勢，而且更容易構建Lambda 架構。這種混合類型的計算引擎比較流行的有Apache Spark，Apache Flink，Apache Apex，後面2個不甚了解。
3.流式處理技術關鍵技術
3.1 流式處理系統管道構建
1) 流式處理思想
數據源：源源不斷的產生數據。
數據緩存：數據源寫數據到緩存系統，數據緩存作為緩沖層，完成數據初步匯聚。
流式引擎：引擎從緩存系統取數據 ，流式引擎實時分析。
結果存儲：數據被引擎處理之後，存入特定數據庫。
整個過程就是：數據源->數據緩存->流式引擎->結果存儲。
為什麽不直接寫流式引擎呢？
原因數據源產生的數據量非常大，直接寫入，流式引擎可能扛不住，若果數據源同時10萬條數據，如果引擎只處理10條，分分鐘沖跨掉，而有了數據緩存，先接納數據，後處理，會比較靠譜。
這是一個偉大的指導思想，而這種指導思想從古到今被人廣泛使用。軍事上戰略緩沖區就是這個指導思想，非接觸作戰。
上面這張圖是從具體實現的角度來描述的。
數據源：數據的生產者，主要有APP，網站和物聯網設備。這裏想說一下我對物聯網大數據的理解，因為物聯網和手機終端設備不一樣，終端通訊有專門的物聯網通訊協議，並且會充分考要耗能問題、數據傳輸、窄帶網絡、設備與網關通訊等問題，因此需要有專門的物聯網平臺來處理高並發的設備連接和消息通訊，並且實際業務場景中，還有大量的設備相關指令的上報和下發，這種專門的物聯網平臺目前業內也有很多公司在做，但是成熟度，比如華為，浙江天地人科技等等，他們都有經過多年生產的物聯網消息透傳平臺。因此，僅僅只用kafka這類的消息隊列組件是有局限性的，通常在這之前還有一層物聯網數據和消息接入平臺來做預處理和解析，處理之後再交給kafka。（個人觀點，僅供參考）
kafka：分布式消息隊列，不斷從消息隊列取數據，根據數量的不同，選擇不同的數據存儲數據，關系型，內存，分布式的kv數據庫等等。
Spark Streaming：微處理技術組件，介於流處理和批處理之間的組件。
Mysql/hbase/redis:數據結果存放，什麽場景下選什麽數據庫，根據業務場景來選擇。
mysql：不會很多的，要做進一步聚集
hbase：數據量非常大的，指標數據，僅僅做直觀展示。
redis：少量的結果，使用內存，大內存就放不小，可以高效獲取，如推薦系統，給其他模塊獲取
3.2 流式處理系統關鍵技術
1.流式處理管道的構建
1)流式數據收集
實時手機數據、網站數據、客戶端生產數據，kafka集群做大數據的緩存，用戶使用各種產品產生數據，各種視頻產生的日誌數據發到loadbalance(負載均衡器，軟件或者硬件實現) ，負載均衡器將數據發到httpserver，簡單的匯總，寫入到kafka的匯總。
2）KAFKA
Kafka有三個組件produce、roker，consumer，采用生產者和消費者模式，是一款分布式數據緩存隊列，可通過zk協調，以主題的方式組織在broker上（一般文件系統時采用目錄或文件進行組織）
以topic來組織，consumer讀完就刪掉（也可以設置緩存幾天），broker可以有多個副本
HttpServer相當於kafak的produecer,而Spark streaming相當於consumer，從broker上存放數據
3) Spark Streaming
將流式計算轉為一批很小的、確定的批處理作業，以秒為單位將數據流切分成離散的作業，將每批數據看作RDD，使用RDD操作符處理，最終結果以RDD為單位返回，寫入HDFS或者其他系統。
SparkStreaming將流式計算轉為批處理問題，每一批都足夠小，看上去像流式處理，將數據流切分成一段一段，切分成秒級，足夠小，小到幾秒鐘就計算完了。另外Spark Streming優勢提供了豐富的函數，表達豐富的表達算法。安裝窗口10秒規約一次，還有帶有狀態的算子，非常多的算子，實現比storm要好很多很多，storm表達，groupbykey，reducebykey非常復雜。
4）數據存儲
Mysql/hbase/redis:數據結果存放，什麽場景下選什麽數據庫，根據業務場景來選擇。
mysql：不會很多的，要做進一步聚集
hbase：數據量非常大的，指標數據，僅僅做直觀展示。
redis：少量的結果，使用內存，大內存就放不小，可以高效獲取，如推薦系統，給其他模塊獲取
3.3流式處理系統關鍵技術
1）.計算方式
關鍵技術，面試常用到，有幾種計算方式和計算類型
（1） 固定窗口
每隔一分鐘統計一次，1分鐘內最火的關鍵字
（2） 滑動窗口
每隔5分鐘統計一次，窗口之間有交叉，窗口內部的指標
（3） 會話計算
董先生舉例說明什麽是會話：app，ofo，首先打開app，從輸入到使用自行車，到結束，這就是一個會話，在會話中進行一系列的動作，登錄，搜索，購買，評論，退出，一段時間沒訪問，就自動退出。用會話為單位，進行分析，一系列的行為，行為有先後關系，按時序進行分析。
新版本的spark全都支持。
2）一致性語義
有且僅有一次：發一條接收一條，不多接收，也不少接收，假設有問題，spark streaming 任務掛掉了，重算，那也是保存了2次，推測執行，2個任務計算同一次結果，空間換時間，結果累加2次，會產生副作用。
最多一次： 發一條，最多一次，發了，就不發了
最少一次：發一條，收到了2次，有冗余數據發過去，比較容易實現，kafka，可能寫2次，消息保留2次，主鍵允許沖虛，如銀行的，有些被處理2次，後果嚴重，
監控和報警：至少一次，保證所有實現的函數都是無狀態的，冪等的（執行1,2,3次結果都是一樣的，累加就不是冪等的）。有些操作是，kv結果的存儲，給定的主鍵唯一，將結果保存，key相同，後面會覆蓋前面的計算結果。
累加轉為冪等，將batch做一個和，在外部寫一個sql，對某時間內的進行累加
3）亂序和延遲到達
亂序和延遲到達：各種日誌數據到達系統的時間不一樣，網絡問題導致，到達的順序都是不一樣的，流式計算統計某段時間內訪問量，亂序，延遲等，（1）延遲到達：5點半的，10點多到達，這就是延遲到達，（2）亂序問題：相同的時間，訪問的服務到達順序不一樣，就是亂序問題。1點可能晚於1:05，產生的問題，這個問題就不好解決。
Spark2.0新版本，對此作了很好的解決。Apache beam，也作了很好的解決，亂序和到達的問題
3.4 用戶行為分析系統
每個時間段，用戶產生付費的量，營收等實時看到
1.嵌入代碼，收集用戶行為，放入kafka
2.spark streaming收集
3.寫入redis
4.可視化
為什麽用spark streaming和kafka來做，
· 如果數據量很大，分布式資源做高並發計算
· 如果目前數據量不大，但將來很大，提前上，可擴展性好
4.問題答疑總結
記錄了一些具有參考價值的問題和回答
1）.先學習scala，是一個趨勢，java是入行大數據的基本語言
2）.flume優勢提供了各種嵌入式的數據源，kafka看做是消息總線
3）傳統的.OLAP,spark sql可以做
4).spark R也比較小眾，grahx比較小眾，
5).實時去重如何做？
只能做某個時間窗口內的去重，實時去重還是比較難做的，把歷史數據都放到kv庫裏面，來一條查一條。
6).hbase替代方案，嘗試Cassandra
7).kafka如何做有序處理，
8)spark語言基礎:java，提倡多謝scala
9)Spark2.0穩定版？
企業生產可以用 2.1.0
10).flink 比較小眾
11)學習spark，只會python也可以，不會java的人，還是學習下
12).Spark立足於hdfs，spark只是計算引擎，比如說kafaka，hdfs等等
13）datafrme,dataset用的最多，spark core，rdd簡單，效率高
14).隨機存取修改，可用mongdb之類的
15）Spark sql調優，比較簡單，暴露的東西並不多，Spark sql就是為簡化用戶調優而實現
16）內存越來越少原因？內存一直增長，可能資源有泄露，如插入到map一直不釋放
17）關系型到spark sql的關鍵問題是什麽？將關系型數據庫遷移到 SparkSQL 的關鍵是什麽？
sql重寫，特殊的語法，寫法要變動
18）.如果在spark streaming實時計算中需要讀取關系型數據庫中的歷史數據，如何實現？
jdbc之類的東西，單機程序並行化來，odbc
19）kafka數據持久化到哪兒？hdfs?
會寫到本地磁盤，自己處理分布式容錯
20)spark支持四種語言： java，scala，python和r
21）kafka會存在磁盤上，kafka一般設計個副本，kafka 2個，一般保留1~3天的數據
22）hadoop生產集群搭建如何考慮磁盤raid，raid0和jbod如何選擇，Hadoop生產集群系統盤分區如何規劃的，以及周邊配套服務器角色都有哪些，如何規劃？【我的問題，董先生可能沒看到，沒有回答】
23）yarn：2.6.2.7,2.3.2.4都可以，spark都支持，
24）spark stream read kafka 如何存儲offset，使用checkpoint？還是用額外的ZK或者RDB？那種比較好？，大部分在zookeeper裏面
25）spark和hadoop哪個代碼更好
spark更簡潔，hadoop冗余
26）spark不一定非要運行在yarn，也可以mesos
27）streaming 是否必須要設置checkpoint？什麽時候應該強制設置？
mapv的states時，就必須要，看場景，checkpoint大大降低性能
28）Druid在企業中應用的多麽？應用的一般
29）kafka的partition怎麽調優，kafka的partition會影響spark streaming的數據讀取
會影響，盡可能的，調優也沒有很多方法，將並發度提高，
30）不適合spark處理的嘗盡
OLAP，sql在線實時分析，sparksql不是很適合，
31）apache上下載可以用與生產環境麽？
可以，Spark用2.1.0
5.參考資料
1.http://blog.csdn.net/tagst/article/details/49642787-流式計算的理論與技術
2.http://blog.csdn.net/zhangzhaokun/article/details/8821385
實時計算、流式處理系統簡介與簡單分析
3.http://www.cnblogs.com/panfeng412/archive/2011/10/28/2227195.html對互聯網海量數據實時計算的理解
4.https://wenku.baidu.com/view/fd91e734cd7931b765ce0508763231126fdb775f.html流式處理框架storm-spark和samza的對比
5.董西成ppt
【Spark深入學習 -10】基於spark構建企業級流處理系統