3.1.1 Lambda架構

來自Apache Flink 中文學習網站 ververica.cn 侵權告知立刪

3.1.2 Kappa架構

來自Apache Flink 中文學習網站 ververica.cn 侵權告知立刪

3.1.3 實時olap變體架構

來自Apache Flink 中文學習網站 ververica.cn 侵權告知立刪

3.1.4 常見架構對比

來自Apache Flink 中文學習網站 ververica.cn 侵權告知立刪

ps:lambda架構

開發割裂感：

? 表結構不同

? sql語法不同

資源浪費：

? 重復計算

? 重復存儲

集群維護：

? 組件不同

? 計算引擎不同

數據一致性

3.2 實時數倉架構

3.2.1 方案一

優點：

? 便于數據回溯、重算和數據質量驗證。

缺點：

? 通過批處理重算，需要維護兩套代碼，開發和維護成本高。

? 需要兩套計算資源

適用場景：

? 超大規模歷史數據計算，且這種場景比較頻繁。

? 對數據質量要求極高，需要比對實時和離線的計算結果，甚至利用離線去修正實時的計算結果。

3.2.2 方案二

優點：

? 無需維護兩套代碼，開發迭代速度快。

? 數據回溯和重算方便，重算時間根據需求回溯的時間范圍定。

? 只需流計算資源，資源占用小

缺點：

? ODS\DWD部分數據“不可見”，原始數據和中間數據不便于查詢（解決方案：可通過重新消費指定時間范圍的數據查詢，或導入需要的數據到olap引擎）

? 依賴業務端反饋問題（解決方案：設計數據質量監控指標，實時監控報警）

適用場景：

ODS\DWD查詢不頻繁等

3.2.3 方案三

相對于方案二：

? 增加ODS層落地hive，排查分析原始數據比較方便，恢復歷史數據的時候可獲取hive數據寫入kafka，然后按原流處理的邏輯重新處理即可，只需修改數據源為歷史數據對應的topic。

? 需新增kafka寫入hive邏輯

? 需新增從hive讀取數據寫入kafka

? 需新增整條鏈路歷史數據對應的topic