今天是一篇架構分享內容。
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等。
以上，為本次分享內容。
感謝閱讀。
按例，歡迎點選此處關注我的個人公眾號，交流更多知識。