#頭條創作挑戰賽#

湖倉一體實時電商項目是基于某寶商城電商項目的電商數據分析平台，本項目在技術方面涉及大數據技術組件搭建，湖倉一體分層數倉設計、實時到離線數據指标分析及數據大屏可視化，項目所用到的技術組件都從基礎搭建開始，目的在于湖倉一體架構中數據倉庫與數據湖融合打通，實現企業級項目離線與實時數據指标分析。在業務方面目前暫時涉及到會員主題與商品主題，分析指标有用戶實時登錄信息分析、實時浏覽pv/uv分析、實時商品浏覽信息分析、用戶積分指标分析，後續還會繼續增加業務指标和完善架構設計。

當前基于Hive的離線數據倉庫已經非常成熟，随着實時計算引擎的不斷發展以及業務對于實時報表的産出需求不斷膨脹，業界最近幾年就一直聚焦并探索于實時數倉建設。根據數倉架構演變過程，在Lambda架構中含有離線處理與實時處理兩條鍊路，其架構圖如下：

正是由于兩條鍊路處理數據導緻數據不一緻等一些列問題所以才有了Kappa架構，Kappa架構如下：

Kappa架構可以稱為真正的實時數倉，目前在業界最常用實現就是Flink Kafka，然而基于Kafka Flink的實時數倉方案也有幾個非常明顯的缺陷，所以在目前很多企業中實時數倉構建中經常使用混合架構，沒有實現所有業務都采用Kappa架構中實時處理實現。Kappa架構缺陷如下：

• Kafka無法支持海量數據存儲。對于海量數據量的業務線來說，Kafka一般隻能存儲非常短時間的數據，比如最近一周，甚至最近一天。
• Kafka無法支持高效的OLAP查詢，大多數業務都希望能在DWD\DWS層支持即席查詢的，但是Kafka無法非常友好地支持這樣的需求。
• 無法複用目前已經非常成熟的基于離線數倉的數據血緣、數據質量管理體系。需要重新實現一套數據血緣、數據質量管理體系。
• Kafka不支持update/upsert，目前Kafka僅支持append。實際場景中在DWS輕度彙聚層很多時候是需要更新的，DWD明細層到DWS輕度彙聚層一般會根據時間粒度以及維度進行一定的聚合，用于減少數據量，提升查詢性能。假如原始數據是秒級數據，聚合窗口是1分鐘，那就有可能産生某些延遲的數據經過時間窗口聚合之後需要更新之前數據的需求。這部分更新需求無法使用Kafka實現。

所以實時數倉發展到現在的架構，一定程度上解決了數據報表時效性問題，但是這樣的架構依然存在不少問題，Kappa架構除了以上所說的問題之外，實時業務需求多的公司在選擇Kappa架構後，也避免不了一些離線數據統一計算的場景，針對Kappa架構往往需要再針對某層Kafka數據重新編寫實時程序進行統一計算，非常不方便。

随着數據湖技術的出現，使Kappa架構實現批量數據和實時數據統一計算成為可能。這就是我們今天聽到的“批流一體”,在業界中很多人認為批和流在開發層面上都統一到相同的SQL上處理是批流一體，也有一些人認為在計算引擎層面上批和流可以集成在同一個計算引擎是批流一體，比如：Spark/SparkStreaming/Structured Streaming/Flink框架在計算引擎層面上實現了批處理和流處理集成。

以上無論是在業務SQL使用上統一還是計算引擎上的統一，都是批流一體的一個方面，除此之外，批流一體還有一個最核心的方面就是存儲層面上的統一。數據湖技術可以實現将批數據和實時數據統一存儲，統一處理計算。我們可以将離線數倉中的數倉和實時數倉中的數倉數據存儲統一合并到數據湖上，可以将Kappa架構中的數倉分層Kafka存儲替換成數據湖技術存儲，這樣做到“湖倉一體”的構建。

“湖倉一體”架構構建也是目前各大公司針對離線場景和實時場景統一處理計算的方式。例如：一些大型公司使用Iceberg作為存儲，那麼Kappa架構中很多問題都可以得到解決，Kappa架構将變成個如下模樣：

這條架構中無論是流處理還是批處理，數據存儲都統一到數據湖Iceberg上，這一套結構将存儲統一後，解決了Kappa架構很多痛點，解決方面如下：

• 可以解決Kafka存儲數據量少的問題。目前所有數據湖基本思路都是基于HDFS之上實現的一個文件管理系統，所以數據體量可以很大。
• DW層數據依然可以支持OLAP查詢。同樣數據湖基于HDFS之上實現，隻需要當前的OLAP查詢引擎做一些适配就可以進行OLAP查詢。
• 批流存儲都基于Iceberg/HDFS存儲之後，就完全可以複用一套相同的數據血緣、數據質量管理體系。
• 實時數據的更新。

上述架構也可以認為是Kappa架構的變種，也有兩條數據鍊路，一條是基于Spark的離線數據鍊路，一條是基于Flink的實時數據鍊路，通常數據都是直接走實時鍊路處理，而離線鍊路則更多的應用于數據修正等非常規場景。這樣的架構要成為一個可以落地的實時數倉方案、可以做到實時報表産生。

此項目中我們使用的數據湖技術是Iceberg構建“湖倉一體”架構來實時和離線分析電商業務指标。項目整體架構圖如下圖所示：

項目中的數據來源有兩類，一是MySQL業務庫數據，另一類是用戶日志數據，我們通過對應的方式将兩類數據首先采集到Kafka各自topic中，通過Flink處理将業務和日志數據存儲在Iceberg-ODS層中，由于目前Flink基于Iceberg處理實時數據不能很好保存數據消費位置信息，所以這裡同時将數據存儲在Kafka中，利用Flink消費Kafka數據自動維護offset的特性來保證程序停止重啟後消費數據的正确性。

整個架構是基于Iceberg構建數據倉庫分層，經過Kafka處理數據都實時存儲在對應的Iceberg分層中，實時數據結果經過最後分析存儲在Clickhouse中，離線數據分析結果直接從Iceberg-DWS層中獲取數據分析，分析結果存入MySQL中，Iceberg其它層供臨時性業務分析，最終Clickhouse和MySQL中的結果通過可視化工具展示出來。

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!