當(dāng)談到數(shù)據(jù)湖的時(shí)候，大家都在說，可以把所有數(shù)據(jù)（結(jié)構(gòu)化/半結(jié)構(gòu)化/非結(jié)構(gòu)化）一股腦都丟進(jìn)去，進(jìn)行統(tǒng)一的元數(shù)據(jù)管理。然后上層計(jì)算對接，進(jìn)行流批計(jì)算/OLAP 分析/算法分析。

這個(gè)沒問題，數(shù)據(jù)湖確實(shí)能承接底層的這部分能力，但是同時(shí)出現(xiàn)的問題也是不容忽視的。

本文將關(guān)注討論，利用湖倉架構(gòu)，統(tǒng)一結(jié)構(gòu)化/半結(jié)構(gòu)化數(shù)據(jù)的流批計(jì)算，和大家聊聊為什么企業(yè)需要實(shí)時(shí)湖倉。非結(jié)構(gòu)化的視頻/圖片/文本等數(shù)據(jù)的存儲和計(jì)算不在本文的討論范圍內(nèi)。

當(dāng)前的企業(yè)困境

下圖是一個(gè)經(jīng)典的 Lambda 架構(gòu)，雖然這套架構(gòu)的優(yōu)點(diǎn)很明顯：技術(shù)方案成熟、應(yīng)用實(shí)踐廣泛，適用于企業(yè)發(fā)展過程中各階段、各場景下的大數(shù)據(jù)開發(fā)需求。

但是，隨著業(yè)務(wù)對數(shù)據(jù)時(shí)效性要求的提高，許多企業(yè)的實(shí)時(shí)任務(wù)體量，正在逐步接近存量離線任務(wù)。在數(shù)據(jù)開發(fā)和運(yùn)維資源有限的情況下，這套架構(gòu)的問題正在逐漸暴露出來：

· 離線開發(fā)鏈路中的數(shù)據(jù)更新問題，在當(dāng)前技術(shù)環(huán)境下顯得越來越難以容忍

· 實(shí)時(shí)開發(fā)鏈路中的數(shù)據(jù)不落地問題，無法支持歷史數(shù)據(jù)回溯、查詢分析等場景

· 多種計(jì)算引擎，造成數(shù)據(jù)開發(fā)學(xué)習(xí)成本和運(yùn)維管理成本的居高不下

· 多種存儲介質(zhì)，造成數(shù)據(jù)存儲冗余、批/流數(shù)據(jù)不一致

· ……

解決之道：實(shí)時(shí)湖倉

下圖是一種實(shí)時(shí)湖倉解決方案，利用湖存儲的特性和 Flink 的流批計(jì)算能力，統(tǒng)一存儲和計(jì)算，解決 Lambda 架構(gòu)的問題。

本文以 Paimon 為例，Paimon 是 Flink 內(nèi)部基于 Flink Tablestore 孵化的一款湖存儲產(chǎn)品。和 Hudi/Iceberg 相比，Paimon 和 Flink 引擎有著更完整的兼容能力。

下面將就袋鼠云的實(shí)踐經(jīng)驗(yàn)，展開說說如何使用“Flink+數(shù)據(jù)湖”三步構(gòu)建實(shí)時(shí)湖倉。

● Step1：搭建實(shí)時(shí) ODS 層

不管是通過 Flink 消費(fèi) Kafka，還是通過 FlinkCDC 采集日志，都可以將源庫數(shù)據(jù)實(shí)時(shí)同步至 Paimon 中。

這樣，無論上層是要做批計(jì)算還是流計(jì)算，都有份統(tǒng)一的實(shí)時(shí) ODS 數(shù)據(jù)做基礎(chǔ)，避免了數(shù)據(jù)不一致和存儲冗余的問題。

● Step2：加工湖倉中間層

關(guān)于實(shí)時(shí)湖倉的層級設(shè)計(jì)，可以參考成熟的離線數(shù)倉劃分方案。

從上面的架構(gòu)圖中可以看出，Paimon 存儲將文件分為 DataFile 和 LogFile：

· DataFile 用于存量數(shù)據(jù)的批計(jì)算

· LogFile 用于增量數(shù)據(jù)的流計(jì)算，但畢竟是一種文件存儲格式，其實(shí)時(shí)性只能做到分鐘級別。如果業(yè)務(wù)場景對實(shí)時(shí)性有秒級/毫秒級要求，Paimon 也支持將 Kafka 外掛為 LogFile 使用，同時(shí)對上層應(yīng)用暴露的，仍然只有一張 Paimon 表。

基于上面的特性，如何在實(shí)際應(yīng)用體現(xiàn)出流/批一體能力，可以參考如下幾種開發(fā)場景：

01 流、批獨(dú)立任務(wù)

根據(jù)實(shí)際業(yè)務(wù)場景需要，使用 Flink+Paimon 的統(tǒng)一技術(shù)棧，進(jìn)行離線任務(wù)和實(shí)時(shí)任務(wù)的獨(dú)立開發(fā)。

02 批流一體任務(wù)

在很多實(shí)時(shí)統(tǒng)計(jì)類的數(shù)據(jù)開發(fā)場景下，往往需要在完成存量數(shù)據(jù)統(tǒng)計(jì)的基礎(chǔ)上，再銜接實(shí)時(shí)增量計(jì)算。傳統(tǒng)的 Lambda 架構(gòu)要完成這種場景，實(shí)現(xiàn)上相對比較復(fù)雜，而使用 Flink+Paimon，一個(gè)任務(wù)即可滿足。

03 流批一體任務(wù)

傳統(tǒng)的 Lambda 架構(gòu)中，為了保障 Flink+Kafka 實(shí)時(shí)計(jì)算的準(zhǔn)確性，往往需要將 Kafka 數(shù)據(jù)雙寫一份到離線存儲中，然后通過離線定時(shí)任務(wù)對實(shí)時(shí)計(jì)算結(jié)果做一次覆蓋修正。而使用 Flink+Paimon，一個(gè)任務(wù)即可滿足。

● Step3：湖倉分析應(yīng)用層

這層有兩種不同的落地方案，可以根據(jù)企業(yè)技術(shù)棧自由選型：

· ADS 層數(shù)據(jù)也在數(shù)據(jù)湖加工落地，然后使用 OLAP 引擎如 Trino、StarRocks 直接對接數(shù)據(jù)湖，向上層提供數(shù)據(jù)分析能力。這樣做可以實(shí)現(xiàn)存儲的完全統(tǒng)一，但是在查詢分析性能上會有一定的犧牲。

· 將 DWS 層數(shù)據(jù)加工后打入 StarRocks 或者 ClickHouse 這類存儲+分析的統(tǒng)一引擎。該方案可以充分利用這類引擎的查詢加速能力，對于 OLAP 場景有較高要求的企業(yè)，是個(gè)比較合適的方案。

企業(yè)的其他選擇？

目前業(yè)內(nèi)比較熱門的探索實(shí)踐，不依賴 Hadoop 體系，僅利用 StarRocks/Doris 構(gòu)建實(shí)時(shí)數(shù)倉的方式，大致的架構(gòu)圖如下：

理論上，該方案確實(shí)可行。StarRocks/Doris 本身作為計(jì)算+存儲一體的引擎，具備向量化、MPP 架構(gòu)、CBO、智能物化視圖、可實(shí)時(shí)更新等能力，在一定程度上可以滿足構(gòu)建實(shí)時(shí)數(shù)倉的要求。

但是，在我們接觸過的一些金融客戶的實(shí)際應(yīng)用中發(fā)現(xiàn)，當(dāng)數(shù)據(jù)體量較大、視圖邏輯較復(fù)雜時(shí)，該方案存在明顯的性能瓶頸。

而根據(jù) StarRocks/Doris 官網(wǎng)對自己高性能分析型數(shù)倉的定位，將它作為企業(yè) OLAP 的選型，完全沒有問題，但是寄希望于它承擔(dān)全鏈路的大數(shù)據(jù)計(jì)算，目前來看還有很長的路要走。

所以，將實(shí)時(shí)湖倉部分層級的計(jì)算，前移至“Flink+數(shù)據(jù)湖”的架構(gòu)中，仍然是當(dāng)前技術(shù)方案中最優(yōu)的選擇。

本文根據(jù)《實(shí)時(shí)湖倉實(shí)踐五講第一期》直播內(nèi)容總結(jié)而來，感興趣的朋友們可免費(fèi)獲取直播課件：

直播課件：

https://www.dtstack.com/resources/1050?src=szsm

《數(shù)據(jù)治理行業(yè)實(shí)踐白皮書》下載地址：https://fs80.cn/l134d5?

《數(shù)棧V6.0產(chǎn)品白皮書》下載地址：https://fs80.cn/cw0iw1

想了解或咨詢更多有關(guān)袋鼠云大數(shù)據(jù)產(chǎn)品、行業(yè)解決方案、客戶案例的朋友，瀏覽袋鼠云官網(wǎng)：https://www.dtstack.com/?src=szbzhan

同時(shí)，歡迎對大數(shù)據(jù)開源項(xiàng)目有興趣的同學(xué)加入「袋鼠云開源框架釘釘技術(shù) qun」，交流最新開源技術(shù)信息，qun 號碼：30537511，項(xiàng)目地址：https://github.com/DTStack