今天是一篇架構分享內容。
1.概述
以Flink爲主的計算引擎配合OLAP查詢分析引擎組合進而構建實時數倉，其技術方案的選擇是我們在技術選型過程中最常見的問題之一。也是很多公司和業務支持過程中會實實在在遇到的問題。
很多人一提起實時數倉，就直接大談特談Hudi，Flink的流批一體等，但實際上，實時數倉包括任何架構體系的構建如果我們拋開成本和穩定性談技術，那都是有耍流氓的嫌疑。
本文主要給大家進行實時數倉構建的技術選型提供一些經驗與思考，面試中如果被問及，也可以談談。
2.實時數倉的現狀
目前大多數公司的實時數倉業務完全基於Flink計算引擎來搭建實時數據鏈路，尤其是大多數具有中大流量，或者業務背景較爲複雜以及對數據要求強時效性的場景中，無論是做數據關聯，還是做業務指標分析，都具有明顯的優勢，Flink在這些場景中不可或缺。
但是在一些場景中，實時數倉也存在很多問題：
2.1複雜的多表關聯分析
在Flink中實現較爲完美的多源關聯或者說多維度關聯比較困難，在多源或者說大規模數據情況下做實時任務，要考慮的問題很多：比如大家經常遇到的join key熱點問題，TTL問題，維表本身也會遇到查詢的瓶頸，所以又會帶來緩存解決方案以及限流問題等。
2.2指標口徑的頻繁變更
相信大家都遇到過類似的問題，不管是在離線場景還是在實時場景，都會面臨頻繁的指標口徑變更。而在Flink中直接生產多個指標，那麼這個任務會變得尤爲敏感。每一次的口徑變更都會讓你痛不欲生。例如狀態不兼容的問題，數據需要回溯，主備任務的測試切換問題等等，這個時候可能會想，我爲什麼要用Flink做實時開發。
2.3小規模非核心場景
Flink本身是需要通過代碼開發平臺來實現數據處理，這樣其整個開發流程就會變得比較重。而在Flink側做一些小規模非核心場景的任務，開發，測試，預上線，上線。開發耗時長，計算成本高。整個投入產出比很低。而且後期維護也需要耗費大量人力，且運維要求高，需要Flink代碼能力。
3.Flink+OLAP查詢分析優劣勢
所以如果公司的業務場景是完全基於Flink爲主+OLAP查詢分析爲輔助的場景，這種架構在數據處理和分析領域具有顯著的優勢，但同時也存在一些劣勢。
3.1優勢：
-
實時處理能力：Flink作爲一個流處理框架，具有強大的實時數據處理能力。它能夠實時攝入數據流，並進行近實時的計算和分析，滿足對數據時效性要求較高的場景。
-
低延遲：Flink能夠保證數據的低延遲處理，快速響應業務需求，這對於需要快速決策的場景非常重要。
-
靈活的窗口機制：Flink支持各種窗口機制，可以根據業務需求靈活定義時間窗口，實現對歷史數據的聚合和分析。
-
批流統一：Flink支持批處理和流處理的統一，可以方便地處理批量數據和實時數據，提高數據處理效率。
-
OLAP查詢輔助：結合OLAP查詢，Flink可以處理複雜的數據分析需求。OLAP查詢具有強大的多維分析能力和快速的數據查詢速度，能夠爲決策提供有力支持。
-
容錯性：Flink提供了精確一次的處理語義，保證了數據處理的可靠性。即使在系統故障的情況下，也能夠保證數據的一致性。
3.2劣勢：
-
複雜性：Flink作爲一個通用的流處理框架，其使用和維護具有一定的複雜性。需要具備一定的編程和數據處理解能力纔能有效地使用Flink。
-
硬件資源要求較高：爲了支持實時數據處理和複雜分析，需要較高的硬件資源，包括計算資源、存儲資源和網絡資源等。這會增加系統的建設和維護成本。
-
數據一致性挑戰：在實時數據處理場景中，如何保證數據的一致性是一個挑戰。雖然Flink提供了精確一次的處理語義，但在某些複雜場景下，仍然需要額外的機制來保證數據的一致性。
-
生態系統不夠完善：雖然Flink是一個成熟的流處理框架，但其生態系統相比一些其他大數據處理框架可能還不夠完善。可能需要依賴其他工具和組件來完善功能。
-
對歷史數據支持不足：相比傳統的OLAP系統，Flink在處理歷史數據方面可能存在不足。雖然可以通過存儲歷史數據來解決這個問題，但會增加系統的複雜性和成本。
綜上所述，Flink爲主+OLAP查詢爲輔助的場景具有實時處理能力、低延遲、靈活的窗口機制等優勢，但也存在複雜性、硬件資源要求較高、數據一致性挑戰等劣勢。
4.解決思路構想
在上面的一系列問題中，我們提出的解決方案必然是要避免其缺點，發揚其優點。可以換個思路，我們將計算和存儲完全下移到OLAP引擎側，利用Clickhouse/Doris等數據庫的能力，降低數倉鏈路的開發和維護成本。
事實上，目前各大公司都有或多或少這方面的嘗試與應用。
我們以Clickhouse作爲核心存儲和計算平臺，主要是面向近實時的場景。
那麼基於這個平臺，我們需要做哪些功能來完善它呢？
4.1.開發和測試平臺
需要實現一個可以寫Clickhouse Sql任務的平臺，能夠提供從表到表的數據轉化鏈路。包括但不限於提供接入數據，開發SQL，測試任務，提供查詢，導出數據的功能。
4.2.數據建模工具
基於Clickhouse Sql構建一個表元數據管理，數據倉庫管理，集市管理，以及任務管理的功能。
4.3.數據質量
需要提供數據質量監測能力。
4.4.數據治理
提供完整的血緣上報，進行全鏈路追蹤。
表的熱度分析，慢SQL的監測，結合表熱度進行存儲分層處理，以及權限和成本問題等。
5.方案總結
基於上面解決思路，可以想象，我們的解決方案已經很清晰了，主要有兩大模塊。
1.一個實時性支持良好的數據傳輸通道
2.一個OLAP分析引擎。
例如
可以開發Flink生成自動化模板化的接入數據任務，包括但不限於客戶端日誌，服務端日誌，數據庫日誌等。解析完成寫入kafka.
通過Clickhouse物化視圖的方案讀取kafka數據，進而構建出近實時的數倉。
以上兩個步驟我們完全可以靈活選擇，例如第一步我可以通過模板化的FlinkSql來實現。或者使用FlinkCDC功能等。
而Clickhouse還可以用市面上相近的數據庫來替代，如Doris或者StarRocks等。
以上，爲本次分享內容。
感謝閱讀。
按例，歡迎點擊此處關注我的個人公衆號，交流更多知識。