為了讓大家進一步瞭解Spark Streaming架構及實踐,飛馬網於10月30日晚，邀請到某知名電商大數據平臺團隊異構數據交換及流式計算平臺的研發工程師韓老師為大家分享該領域的內容。
以下是這次線上直播的分享實錄：
今天給大家帶來的主題分享是Spark Streaming架構及實踐。
一、流式計算的特點
如何定義流式數據？數據隨著時間的推移而動態變化並且不斷有新的數據產生，這樣的數據就是流式數據，絕大多數的數據都是流式數據，靜態數據是相對較少的。
特點：
1、實時性：整體上要求較低的處理延時，絕大多數要求秒級別，甚至毫秒級別。
2、數據無邊界： 數據不會停，對於數據的計算也不會停。
3、容錯要求：對driver和executor的要求
4、處理次數：針對每一條數據,主要分為三種。如圖。
5、數據洪峰：特別重要的事情，特別是對於電商行業來說。預估、壓測、合理分配、參數調優。
6、數據源複雜性：實際上，絕大多數都是如下的架構。
二、Spark Streaming的運行模式及架構解析
運行模式分為四種：
1、Local:就是本地模式，經常用於本地開發測試。
2、Standalone：集群由Master（負責資源管理和調度，存在單點故障）和Worker（執行業務邏輯）節點組成。
3、Yam/Mesos：前者在生產環境中最常用的；後者在國內並沒有火起來，以前者為例。優點如下：生態足夠好；分佈式資源調度的框架可以做到資源隔離，適度調度等。
Cluster和client的區別：
4、Kubemetes：新模式，社區還在探索階段，是未來的趨勢。
好處是：版本很靈活；擴容十分簡單
未來趨勢——容器化；彈性化的優點；節省資源；
Spark Streaming架構解析
三、Spark Streaming實踐tips
Checkpoint
為什麼需要Checkpoint？
1、7*24小時的應用是需要抵禦意外或者恢復計算能力的；
2、依賴關係過於長，成本大
3、功能有限，容錯性不高
什麼時候做Checkpoint？
1、希望能從意外中恢復driver
2、存儲中間數據狀態
兩種類型的Checkpoint
1、metadata元數據，定義了計算邏輯的不要信息
2、Data類型的Checkpoint
Checkpoint有什麼侷限性？
如果應用掛了，發現應用程序有問題，可能之前的數據難以恢復
應用場景
Spark+kafka是通用的場景。
Direct方式的優點：
1、簡化並行讀取
2、高效
3、恰好一次語義
關於消費kafka並行：
通過擴上游的partition數量來提高消費並行度是可以的，但是利好程度有限。
在生產過程中往往會開背壓機制（系統具備了根據系統的實際處理能力來進行自我調節的能力）和限速，這兩個特性是結合起來用的，特別重要。
Foreach RDD
輸出操作裡最常用的一個編程範式
需要注意的點：把跟外部系統創建連接這樣的實例的極點 ，否則容易出現異常。
四、Spark Streaming應用分類以及示例
1、實時計算及展現類
對用戶的行為或者其他行為進行是實時化的分析，並且結合可視化的展現，換句話說就是實時報表類的應用。比如說，每年電商618、雙十一都會有大屏類的展現。
後臺架構圖
SLB、ECS左邊是線上的web系統，用來埋點，直接到RDS 。
DTS是阿里做數據傳輸的一個東西，實時高效的抓取操作往下游發。
datahub理解成kafka，是一個消息隊列。
下游是熟悉的模塊，一個計算引擎，最後輸入到數據庫裡。
下面這個例子，是後臺登錄系統的截圖。典型的實時報表場景，描點的圖實際上就是流計算。
2、實時監測及推薦類
對用戶、業務、系統做實時監控。
應用在全棧交易檢測、大促實時監控、實時欺詐檢測（風控）、實施推薦或廣告系統
兩個例子；
典型的推薦系統架構。
風控系統
3、streaming ETL
ETL就是抽取、轉化、夾帶，數據倉庫裡面的一個概念。
做數據過濾，數據轉化，甚至數據清洗。
對數據做分區，提高效率。
源端和目標端一般都會掛kafka
五、流式計算引擎技術選型
常見的：storm、spark、samza、flink、heron……
對比三種引擎
Storm、spark、flink，總的來說，後兩個都是不錯的選擇。
如何選？
1、適用性最好。
2、沒有差武器，只有用不好武器的人。選一個引擎去深入瞭解。
3、歷史包袱。初創公司不需要包袱就可以選擇最流行的。發展很久的話，就需要考慮歷史的原因。
以上就是本次線上直播的主要內容，相信你對其有了一定的認識。想了解更多更詳細內容的小夥伴們，可以關注服務號：FMI飛馬網，點擊菜單欄飛馬直播，即可進行學習。
閱讀更多 飛馬網FMI 的文章
