實時存盤引擎和實時計算引擎
一 實時存盤引擎 Kafka
SSD 快取架構解決延遲消費污染快取空間問題
二 實時計算引擎 Flink
簡介和系統架構
相當于mapreduce/spark + 實時計算
在實時處理框架中，不會持久化，而是寫入記憶體的一個state，通過寫入記憶體替代持久化，增加處理速度，
最近兩年使用streaming，Flink，生態比較好，
native 單條
micro-batch 微批
實時計算平臺實際就是作業管理平臺，提供了上面四種功能，
為了規范開發程序，在平臺上完成所有作業，集中化管理作業，平臺操作取代客戶端，
以下是應用場景：
反爬蟲：實時 一分鐘之內一個IP訪問某網站多少次
實時流量分析： 節榷訓動的效果
B 端：面向商家的應用
Flink 具體的作業
source從 kafka 資料源讀資料，然后中間兩個 Transform ，讀過來的每一行的 id 進行分發，分發的時間視窗是 10s 中，每個視窗進行 sum，如果把 id 當作 ip , 就和上面的 爬蟲案例 相同了，最后寫到檔案中，
上面是邏輯流程，我們看上面的流程是如何被編譯成一段作業，一個 job 圖，被分配到物理節點上去的，
中間的點呢都是操作（function），箭頭是一個streaming ，是一個資料流，source、map分布在多個組件上（分布式化），sink 可以是單一的或者分布式的，只有 keyby / apply的時候才需要進行 shuffle ，
source 和 map 都是分布式，合并后可以減少網路代價，
所以把進行了合并，合并后的節點就在同一個機器上進行運行，
這些節點最終被分配到用 YARN 做資源調度的模型當中，這個模型就是物理模型，這個物理模型就是 Flink 的 program 通過 Client 提交到 YARN 集群上去運行，YARN 集群上也有 Job Manager 和 Task Manager，Job Manager是用來控制整個系統的，Task Manager 是我們上面講的五個節點，
(可能這里少了一部分qaq)
在寫spark的時候關心它的狀態嗎？是沒有這個概念的，在實時處理的時候是非常關心狀態，是否資料丟失或者重復，這涉及到準確性語意保證，離線作業資料丟失或者重復可以重新再來一遍，但是實時處理不行，想做到重復消費需要非常麻煩的機制，這里不講，所以流式處理的語意保證就有幾種情況：
- 最多消費一次
- 至少消費一次
- 準確一次
這里說完了 state，再說說視窗（視窗就是比如統計過去10秒的資料中的10秒就是視窗），有很多種，如滑動視窗等，這里不細講，同學們下去拓展延伸開來和spark進行對比，理解的就比較透徹了，
Flink HA 新架構
這是一個基于YARN的Flink架構，
YRAN 申請資源；
job M和Task M通過 HDFS 和 ZK 進行互動；
有監控程式監控 Job Manager，監控程式輪詢檢測時間周期太長，怎么辦呢？我們看看社區的解決方案，
社區的解決方案
Leader 的選舉和發布 通過zk管理；類似分布式鎖
當然這樣也有問題
保證系統只有一個app master
沒有必要選舉，所以去掉選舉程序，最終方案如下：
QA
A：消費kafka不能保證一次性消費
A：日志不保證順序，多行程 多執行緒不保證順序性
Q：水位預估？
一般設定更大的閾值，一般是測驗程序中拿到的資料比對去設定水位值
Q：Kafka 的擴容需要磁區重新分配，代價比較大，美團再在Kafka擴容方面有做什么優化嗎？
如果擴充磁區，可以讓新資料寫新磁區
代價大的是遷移資料，當我們發現不均衡的時候會啟動遷移，選擇壓力比較小的時間（如晚上）進行
Q：實時資料和批資料怎么對齊，如果批資料和實時資料計算結果不一樣？
當兩種資料放到同一個表的時候，從業務上進行區分，分開寫或者根據時間判斷是由實時覆寫或者批資料進行覆寫，
Q：美團Flink cep 應用場景多么嗎？大流量下的準確性怎么驗證呢？
將實時處理結果和離線結果進行比對，將測驗階段和實時階段進行對比
Q：業務資料進入大資料平臺后做離線分析前，需要檢查 T+ 1 業務資料是否完整進入大資料平臺嗎？需要的話，會做哪些檢查呢？
怎么保證進來的是完整的資料？完整性是需要檢查的，但是這種檢查是只是否全部收集，而不考慮資料的正確性，有兩種策略，對于昨天進來的資料； check down （沒太聽清），
注：
內容來自美團技術團隊10.13大資料課程，侵刪，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/184836.html
標籤：其他