面向HSAP架構(gòu)的Flink流批一體實時數(shù)倉設(shè)計與研究

關(guān)鍵詞：HSAP；Flink；實時數(shù)倉；流批一體；Iceberg

1 HSAP 架構(gòu)適用場景

在企業(yè)數(shù)據(jù)量相對較小時，傳統(tǒng)的在線事務(wù)處理（OLTP） 數(shù)據(jù)庫可以滿足基本的分析需求。然而，隨著數(shù)據(jù)量的爆炸式增長以及分析需求的日益復(fù)雜，OLTP 數(shù)據(jù)庫在處理海量數(shù)據(jù)和復(fù)雜查詢時顯得力不從心。為了解決這一問題，離線分析處理（OLAP） 和數(shù)據(jù)倉庫等技術(shù)應(yīng)運而生。數(shù)據(jù)倉庫作為一種面向分析的數(shù)據(jù)庫系統(tǒng)，旨在解決數(shù)據(jù)冗余、查詢效率和數(shù)據(jù)一致性等問題，為企業(yè)提供高效的數(shù)據(jù)分析和決策支持。

混合服務(wù)分析處理（HSAP） 架構(gòu)應(yīng)運而生，旨在滿足企業(yè)對實時數(shù)據(jù)分析日益增長的需求。HSAP架構(gòu)能夠處理更大規(guī)模的數(shù)據(jù)，包括來自機器學(xué)習(xí)、深度學(xué)習(xí)和日志等非事務(wù)型數(shù)據(jù)，并支持實時數(shù)據(jù)攝取、毫秒級查詢延遲以及流批一體的數(shù)據(jù)處理能力，無須進行傳統(tǒng)的離線ETL過程。

與混合事務(wù)分析處理（HTAP） 架構(gòu)相比，HSAP架構(gòu)更加注重分析性能和吞吐量，在處理海量非事務(wù)型數(shù)據(jù)時具有顯著優(yōu)勢。HSAP架構(gòu)通常采用多種開源組件構(gòu)建，例如Kafka、Flink、HBase、Hive、Druid和ClickHouse 等，以解決數(shù)據(jù)孤島、數(shù)據(jù)一致性和彈性伸縮等問題。這種架構(gòu)能夠有效避免數(shù)據(jù)冗余，降低成本，并提供秒級甚至亞秒級的查詢延遲，為實時決策提供支持。

HSAP和HTAP都是現(xiàn)代數(shù)據(jù)架構(gòu)的重要組成部分，它們分別適用于不同的應(yīng)用場景。隨著企業(yè)互聯(lián)網(wǎng)、物聯(lián)網(wǎng)和人工智能應(yīng)用的快速發(fā)展，HSAP架構(gòu)在處理海量數(shù)據(jù)、提供實時分析能力方面將發(fā)揮越來越重要的作用。

2 海量數(shù)據(jù)查詢效率的痛點和困境

隨著數(shù)字化轉(zhuǎn)型的不斷深入，企業(yè)對實時數(shù)據(jù)分析的需求日益迫切。實時分析、實時推薦、實時營銷和實時風(fēng)控等場景的興起，對數(shù)據(jù)處理的實時性提出了更高的要求。然而，在海量數(shù)據(jù)的背景下，從數(shù)據(jù)產(chǎn)生到最終消費的整個鏈路中，許多因素都可能導(dǎo)致查詢效率的下降。

2.1 多樣化的實時業(yè)務(wù)場景和復(fù)雜的分析鏈路

實時大屏、BI報表、用戶畫像、預(yù)警監(jiān)控和實時風(fēng)控等實時應(yīng)用場景對數(shù)據(jù)的實時性提出了很高的要求KfJ/Acws6j2j44fBTfKV3g==。這些場景通常需要從多個數(shù)據(jù)源讀取數(shù)據(jù)并進行復(fù)雜分析，這給數(shù)據(jù)源帶來了巨大的讀寫壓力。同時，由于分析鏈路難以復(fù)用，容易導(dǎo)致重復(fù)開發(fā)和“煙囪式”系統(tǒng)架構(gòu)，增加開發(fā)、運維成本和數(shù)據(jù)一致性維護的難度。

2.2 海量數(shù)據(jù)分析場景效率低下

企業(yè)通常使用MySQL、PostgreSQL、Oracle 等OLTP數(shù)據(jù)庫來存儲交易流水等結(jié)構(gòu)化數(shù)據(jù)。OLTP 數(shù)據(jù)庫在處理高并發(fā)事務(wù)方面表現(xiàn)出色，但在面對復(fù)雜的分析查詢（如聚合、窗口函數(shù)和分組等）時效率較低，且對流式數(shù)據(jù)的支持有限。此外，海量數(shù)據(jù)的持續(xù)涌入也給OLTP數(shù)據(jù)庫帶來了巨大的壓力，影響了實時業(yè)務(wù)的穩(wěn)定性。

2.3 數(shù)據(jù)孤島和數(shù)據(jù)格式多樣性

企業(yè)數(shù)據(jù)來源多樣化，包括來自應(yīng)用程序的點擊流數(shù)據(jù)、存儲在KV數(shù)據(jù)庫中的維度信息以及關(guān)系型數(shù)據(jù)庫中的交易記錄等。這些數(shù)據(jù)格式各異，存儲位置分散，形成了一個個“數(shù)據(jù)孤島”。如何將這些數(shù)據(jù)進行整合、清洗、轉(zhuǎn)換并加載到數(shù)倉中，是構(gòu)建實時數(shù)倉面臨的一大挑戰(zhàn)。

數(shù)據(jù)孤島、數(shù)據(jù)格式不統(tǒng)一和數(shù)據(jù)分析效率低下等問題嚴(yán)重制約了企業(yè)實時數(shù)據(jù)分析能力的提升。為了解決這些問題，需要構(gòu)建一個系統(tǒng)化的實時數(shù)倉架構(gòu)，并選擇合適的工具和技術(shù)來應(yīng)對海量數(shù)據(jù)的挑戰(zhàn)。

3 流批一體實時數(shù)倉的優(yōu)勢

為了滿足企業(yè)對數(shù)據(jù)實時性的需求，數(shù)據(jù)倉庫架構(gòu)經(jīng)歷了從離線數(shù)倉到實時數(shù)倉的演變過程。Lambda架構(gòu)作為早期實時數(shù)倉的代表，通過同時維護實時和離線兩條數(shù)據(jù)處理路徑來滿足實時和批處理需求，但存在開發(fā)和運維復(fù)雜度高的問題。為了克服Lambda架構(gòu)的缺點，Kappa架構(gòu)應(yīng)運而生，它只保留一條實時數(shù)據(jù)處理路徑，簡化了系統(tǒng)架構(gòu)。然而，Kappa架構(gòu)在處理歷史數(shù)據(jù)回溯和數(shù)據(jù)修正等方面存在不足。為了進一步彌補Kappa架構(gòu)的不足，流批一體的實時數(shù)倉架構(gòu)逐漸成為主流，它結(jié)合了Lambda 和Kappa架構(gòu)的優(yōu)點，采用統(tǒng)一的存儲格式和處理引擎，實現(xiàn)了真正的流批一體。

流批一體的實時數(shù)倉架構(gòu)融合了傳統(tǒng)離線數(shù)據(jù)倉庫和實時數(shù)據(jù)倉庫的優(yōu)勢，兼具高吞吐、低延遲和數(shù)據(jù)一致性等特點。通過采用統(tǒng)一的數(shù)據(jù)處理引擎和存儲格式，流批一體架構(gòu)能夠有效避免數(shù)據(jù)冗余，簡化數(shù)據(jù)處理流程，降低開發(fā)和運維成本，為企業(yè)提供更加高效、靈活的數(shù)據(jù)分析能力。

實時數(shù)倉是指將實時數(shù)據(jù)和批量數(shù)據(jù)的處理過程統(tǒng)一起來，以便更高效地處理和分析數(shù)據(jù)。這種方法可以幫助企業(yè)更好地理解其數(shù)據(jù)，并做出更明智的決策。實時數(shù)倉可以對接很多外部應(yīng)用，例如：用戶畫像、精準(zhǔn)推薦系統(tǒng)可針對性地推送營銷活動，做到“千人千面”；BI實時大屏可將企業(yè)總體交易數(shù)據(jù)圖表化；實時監(jiān)控能讓運維及時感知服務(wù)和主機運行的風(fēng)險；風(fēng)控反欺詐可對業(yè)務(wù)運行數(shù)據(jù)做展示，配合告警閾值系統(tǒng)，實時監(jiān)控用戶行為和訂單量異常等風(fēng)險因子；即席查詢可應(yīng)對分析師靈光一現(xiàn)的突發(fā)查詢需求。數(shù)據(jù)處理系統(tǒng)在邏輯上采用實時數(shù)倉的邏輯分層來實現(xiàn)數(shù)據(jù)的逐級深入處理和數(shù)據(jù)的高復(fù)用性。實時數(shù)倉基于一定的數(shù)據(jù)倉庫理念，對數(shù)據(jù)處理流程進行規(guī)劃、分層，目的是提高數(shù)據(jù)的復(fù)用性和復(fù)雜分析的可拆分[1]。

在實時數(shù)倉基礎(chǔ)平臺，為了更好地利用數(shù)據(jù)，需要將其劃分為原始數(shù)據(jù)層（ODS） 、數(shù)據(jù)明細層（DWD） 、數(shù)據(jù)匯總層（Data Warehouse Middle，DWM） 、數(shù)據(jù)統(tǒng)計層（Data Statistics Layer，DSL） 以及用來存放維度信息的維度層 （DIM）[2]。ODS層負責(zé)從各種數(shù)據(jù)源實時接收原始數(shù)據(jù)，進行初步的格式轉(zhuǎn)換與存儲，通過完整性檢查和監(jiān)控機制來保障數(shù)據(jù)質(zhì)量。DWD層在ODS 之上，對原始數(shù)據(jù)進行清洗、整合和事件建模，以滿足更細粒度的分析需求，采用ETL流程監(jiān)控和數(shù)據(jù)審計確保數(shù)據(jù)的準(zhǔn)確性。DWM 層專注于匯總和聚合DWD層的數(shù)據(jù)，支持多維分析和實時更新，利用一致性校驗和定期健康檢查來維護數(shù)據(jù)的可靠性。ADS 層面向具體應(yīng)用，提供定制化的數(shù)據(jù)服務(wù)，幫助業(yè)務(wù)決策，它通過API接口與用戶交互，同時借助用戶反饋和數(shù)據(jù)版本管理不斷優(yōu)化服務(wù)。

在HSAP架構(gòu)中，ODS原始層是對各類數(shù)據(jù)源的接入映射，例如業(yè)務(wù)方寫入Kafka的各類主題、MySQL 等數(shù)據(jù)庫的Binlog原始數(shù)據(jù)。ODS主要側(cè)重數(shù)據(jù)攝取和簡單存儲，是上層的數(shù)據(jù)來源。由于Flink等流計算平臺具有豐富的連接器可以適配各種外部系統(tǒng)，且提供了豐富的自定義接口，各類異構(gòu)的數(shù)據(jù)源接入變得輕而易舉。DWD明細層通常是經(jīng)過清洗過濾等規(guī)范化操作后的各類主題的事實表，例如訂單交易數(shù)據(jù)、瀏覽數(shù)據(jù)等，而DIM維度表則保存了數(shù)據(jù)中ID與實際字段的映射關(guān)系，以及其他變化緩慢但可以用來補充寬表的數(shù)據(jù)。

如圖3所示，DWS匯總層的數(shù)據(jù)是從明細層和維度層關(guān)聯(lián)而來的。由于ClickHouse等OLAP工具對關(guān)聯(lián)（JOIN） 的性能較弱，因此可以采用Flink來實現(xiàn)流式數(shù)據(jù)的高效動態(tài)JOIN，并將實時的關(guān)聯(lián)數(shù)據(jù)定義為寬表并寫入Click?House以供應(yīng)用層后續(xù)分析查詢。由于ClickHouse等OLAP引擎的強勁性能，海量數(shù)據(jù)的分析效率低下等問題也可以得到一定程度的解決。

ADS 應(yīng)用層承擔(dān)了各類數(shù)據(jù)應(yīng)用的基礎(chǔ)設(shè)施，例如KV存儲、數(shù)據(jù)庫服務(wù)、搜索服務(wù)、實時大屏、用戶畫像等，為外部應(yīng)用服務(wù)提供支持。實時數(shù)倉的應(yīng)用層的數(shù)據(jù)來源于匯總層的各類多維主題寬表和匯總表，例如營銷匯總表、活動匯總表、商品匯總表等。這樣，業(yè)務(wù)方只需要從不同的主題匯總表中讀取數(shù)據(jù)，無須再單獨對各類數(shù)據(jù)源做一整套分析鏈路。如果寬表字段設(shè)計合理，內(nèi)容足夠豐富的話，可以大大緩解開發(fā)慢的問題。

這個架構(gòu)在初期應(yīng)用時較為順利，在大多數(shù)公司中約90%的場景下采用此架構(gòu)。但是隨著業(yè)務(wù)越來越多，越來越復(fù)雜，每天都有新的報表，每天都有新的業(yè)務(wù)場景，就會發(fā)現(xiàn)每一個業(yè)務(wù)調(diào)整的時候，都要從源頭一步步調(diào)整，包括表結(jié)構(gòu)、加工腳本、歷史數(shù)據(jù)重刷等，最后造成整個數(shù)據(jù)加工的鏈路會變得數(shù)據(jù)冗余、成本高、開發(fā)周期長甚至數(shù)據(jù)不一致。其缺點明顯：ETL邏輯復(fù)雜，存儲、時間成本過高；數(shù)據(jù)處理鏈路非常長；無法支持實時或近實時的數(shù)據(jù)，只能處理T+1的數(shù)據(jù)。

4 Flink 流批一體實時數(shù)倉架構(gòu)設(shè)計

在實時數(shù)倉應(yīng)對負載均衡時，Kafka可以用來削峰，當(dāng)在數(shù)據(jù)產(chǎn)生的峰值時刻，用Kafka暫存數(shù)據(jù)積壓消息，等到峰值過去再對Kafka中的數(shù)據(jù)進行消費，防止峰值并發(fā)導(dǎo)致消費端系統(tǒng)過載[3]。

實時數(shù)據(jù)倉庫通過流處理引擎實現(xiàn)實時數(shù)據(jù)的預(yù)處理過程，通過對輸入的數(shù)據(jù)進行過濾、聚合、關(guān)聯(lián)或其他自定義操作減少了上層業(yè)務(wù)數(shù)據(jù)面對分析型任務(wù)時的數(shù)據(jù)處理時間，F(xiàn)link是目前最流行的流處理引擎之一，被廣泛應(yīng)用于各大企業(yè)的實時數(shù)據(jù)倉庫中[4]。

Flink與Iceberg的結(jié)合使得實時流處理與高效數(shù)據(jù)存儲形成有機協(xié)同，共同提升數(shù)據(jù)處理效率與可用性。Flink的狀態(tài)管理與Ice?berg的ACID支持共同確保數(shù)據(jù)在流轉(zhuǎn)過程中的一致性與可靠性，滿足現(xiàn)代數(shù)據(jù)應(yīng)用對質(zhì)量的高要求。兩者的組合減少了系統(tǒng)復(fù)雜性，實現(xiàn)了數(shù)據(jù)處理流程的簡化，降低了開發(fā)與運維成本，提高了團隊的工作效率。Flink與Iceberg的結(jié)合不僅能處理傳統(tǒng)的流和批場景；還適用于實時分析、機器學(xué)習(xí)等復(fù)雜應(yīng)用，為企業(yè)帶來更大的數(shù)據(jù)價值。

在通用架構(gòu)中引入Iceberg，可以實現(xiàn)流式讀寫和批量讀寫。對于實時鏈路而言，可以在一定程度上代替Kafka 等傳統(tǒng)流式數(shù)據(jù)管道；對于需要讀取中間層的數(shù)據(jù)等特殊需求，又可以便捷使用常見的批處理分析工具來直接分析Ice?berg 數(shù)據(jù)文件。Iceberg 高效的歷史數(shù)據(jù)回溯能力，可以快速從特定的時間點開始重新消費數(shù)據(jù)，解決了數(shù)據(jù)保存期過短、歷史數(shù)據(jù)被清理而難以回溯等傳統(tǒng)數(shù)據(jù)管道面臨的挑戰(zhàn)。Flink 實時計算服務(wù)主要為Kafka 集群中存儲的電商平臺數(shù)據(jù)提供層間轉(zhuǎn)換應(yīng)用程序[5]。

Iceberg支持Flink SQL流式寫入和增量拉取，有效解決了小文件過多的問題。Flink（Spark） 上層引擎可以周期性地調(diào)用接口進行小文件合并。流計算和批計算的存儲進行了統(tǒng)一，也就是統(tǒng)一到Iceberg/HDFS上。數(shù)據(jù)中間的各層數(shù)據(jù)，都支持OLAP的實時查詢。Iceberg 還支持較為完整的OLAP生態(tài)。例如支持Hive、Spark、Presto、Impala等OLAP查詢引擎，提供高效的多維聚合查詢性能。ClickHouse、Kafka、Hbase等各個組件相互結(jié)合，滿足了企業(yè)中所有數(shù)據(jù)的分發(fā)和存儲需求，企業(yè)運營部門能夠根據(jù)這些數(shù)據(jù)調(diào)整營銷策略方向，為企業(yè)的戰(zhàn)略制定和角色指導(dǎo)提供相應(yīng)的數(shù)據(jù)分析和存儲能力[6]。

基于HSAP架構(gòu)的Flink流批一體的實時數(shù)倉仍是一個新興技術(shù)，整個過程還沒有完全經(jīng)過時間和業(yè)務(wù)的考驗，可能還存在設(shè)計上的不足[7]。數(shù)據(jù)倉庫的云化趨勢將會持續(xù)發(fā)展，越來越多的企業(yè)將選擇將數(shù)據(jù)倉庫遷移到云平臺，以降低成本、提高靈活性和擴展性；同時，大數(shù)據(jù)技術(shù)的發(fā)展將為數(shù)據(jù)倉庫帶來更多的創(chuàng)新和可能性，例如實時分析、機器學(xué)習(xí)等；隨著人工智能和機器學(xué)習(xí)技術(shù)的不斷成熟，數(shù)據(jù)倉庫將朝著智能化和自動化的方向發(fā)展，通過智能化的數(shù)據(jù)分析和自動化的數(shù)據(jù)處理，企業(yè)可以更快地發(fā)現(xiàn)商業(yè)洞察，并提高決策的準(zhǔn)確性和效率；數(shù)據(jù)湖的概念和技術(shù)將逐漸成熟，并與數(shù)據(jù)倉庫相互融合，實現(xiàn)結(jié)構(gòu)化數(shù)據(jù)和非結(jié)構(gòu)化數(shù)據(jù)的統(tǒng)一管理和分析；多模式分析技術(shù)的發(fā)展將使數(shù)據(jù)倉庫具備更多樣化的分析能力，滿足企業(yè)不同層次和不同類型的分析需求。

5 結(jié)束語

HSAP架構(gòu)的Flink流批一體實時數(shù)倉憑借其低延遲、高吞吐量的特點，正在成為大數(shù)據(jù)處理領(lǐng)域的重要解決方案。它通過統(tǒng)一流處理和批處理模型，不僅簡化了數(shù)據(jù)操作流程，還提升了實時決策支持的能力，使企業(yè)能夠迅速響應(yīng)市場變化。這一架構(gòu)在金融、電商、智能制造等行業(yè)展現(xiàn)出了強大的數(shù)據(jù)應(yīng)用價值，通過精準(zhǔn)營銷和故障檢測等手段，推動業(yè)務(wù)增長與效率提升。

實時數(shù)倉將與人工智能、機器學(xué)習(xí)等先進技術(shù)深度融合，推動自動化分析和智能決策。隨著邊緣計算的發(fā)展，將進一步增強實時數(shù)據(jù)處理的能力，特別是在物聯(lián)網(wǎng)場景下。此外，自適應(yīng)資源管理和多模態(tài)數(shù)據(jù)處理能力的提升，將為數(shù)據(jù)驅(qū)動的創(chuàng)新提供更廣泛的可能性。HSAP架構(gòu)的Flink流批一體實時數(shù)倉不僅是當(dāng)前的應(yīng)用趨勢，未來必將重塑大數(shù)據(jù)生態(tài)系統(tǒng)的核心。