#頭條創作挑戰賽#
項目背景和架構介紹
一、項目背景介紹
湖倉一體實時電商項目是基于某寶商城電商項目的電商資料分析平台，本項目在技術方面涉及大資料技術元件搭建，湖倉一體分層數倉設計、實時到離線資料名額分析及資料大屏可視化，項目所用到的技術元件都從基礎搭建開始，目的在于湖倉一體架構中資料倉庫與資料湖融合打通，實作企業級項目離線與實時資料名額分析。在業務方面目前暫時涉及到會員主題與商品主題，分析名額有使用者實時登入資訊分析、實時浏覽pv/uv分析、實時商品浏覽資訊分析、使用者積分名額分析，後續還會繼續增加業務名額和完善架構設計。
二、項目架構
1、實時數倉現狀
目前基于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的實時資料鍊路，通常資料都是直接走實時鍊路處理，而離線鍊路則更多的應用于資料修正等非正常場景。這樣的架構要成為一個可以落地的實時數倉方案、可以做到實時報表産生。
2、項目架構及資料分層
此項目中我們使用的資料湖技術是Iceberg建構“湖倉一體”架構來實時和離線分析電商業務名額。項目整體架構圖如下圖所示：
項目中的資料來源有兩類，一是MySQL業務庫資料，另一類是使用者日志資料，我們通過對應的方式将兩類資料首先采集到Kafka各自topic中，通過Flink處理将業務和日志資料存儲在Iceberg-ODS層中，由于目前Flink基于Iceberg處理實時資料不能很好儲存資料消費位置資訊，是以這裡同時将資料存儲在Kafka中，利用Flink消費Kafka資料自動維護offset的特性來保證程式停止重新開機後消費資料的正确性。
整個架構是基于Iceberg建構資料倉庫分層，經過Kafka處理資料都實時存儲在對應的Iceberg分層中，實時資料結果經過最後分析存儲在Clickhouse中，離線資料分析結果直接從Iceberg-DWS層中擷取資料分析，分析結果存入MySQL中，Iceberg其它層供臨時性業務分析，最終Clickhouse和MySQL中的結果通過可視化工具展示出來。
3、項目可視化效果