在大數(shù)據(jù)時代，數(shù)據(jù)分析技術不斷演進，從數(shù)據(jù)倉庫到數(shù)據(jù)湖，再到數(shù)據(jù)湖倉，企業(yè)如何選擇合適的數(shù)據(jù)分析架構?本文將深入探討數(shù)據(jù)湖倉(Lakehouse)的概念，以及StarRocks 3.0如何引領這一創(chuàng)新架構，實現(xiàn)數(shù)據(jù)的高效分析與決策支持。
一、數(shù)據(jù)倉庫的演進與挑戰(zhàn)
數(shù)據(jù)倉庫自1980年代以來一直是企業(yè)數(shù)據(jù)分析的核心。關系型數(shù)據(jù)庫、日志文件等數(shù)據(jù)源的數(shù)據(jù)經(jīng)過 ETL 處理，統(tǒng)一存儲到數(shù)據(jù)倉庫，用于服務 BI 報表、數(shù)據(jù)挖掘等分析場景。
數(shù)據(jù)倉庫在數(shù)據(jù)質(zhì)量、事務處理、查詢性能、數(shù)據(jù)治理等方面有明顯的優(yōu)勢，但隨著數(shù)據(jù)分析的需求越來越大，數(shù)據(jù)倉庫的方案也面臨一些挑戰(zhàn)。
1.數(shù)據(jù)多樣化：除了結構化的數(shù)據(jù)，半結構化、非結構化的數(shù)據(jù)越來越多。
2.數(shù)據(jù)孤島問題：數(shù)據(jù)倉庫面向主題管理，導致數(shù)據(jù)分散形成孤島，難以形成全局統(tǒng)一的數(shù)據(jù)分析。
3.成本與擴展性：大數(shù)據(jù)量增長帶來數(shù)據(jù)存儲成本與橫向擴展的問題。
4.高級數(shù)據(jù)分析支持：數(shù)據(jù)倉庫能很好的支持 BI 相關應用，但隨著 AI 的發(fā)展，AI 應用與數(shù)據(jù)倉庫的數(shù)據(jù)交互效率不高，制約了 AI 應用的發(fā)展。
二、數(shù)據(jù)湖的創(chuàng)新與發(fā)展
2010年，數(shù)據(jù)湖概念的提出為企業(yè)提供了一種新的數(shù)據(jù)存儲與分析方式。
如果把數(shù)據(jù)倉庫/集市類比為瓶裝水，數(shù)據(jù)湖則是以更加原生態(tài)方式存儲數(shù)據(jù)的大池子。數(shù)據(jù)湖的核心優(yōu)勢是統(tǒng)一與開放，數(shù)據(jù)基于對象存儲、HDFS 等系統(tǒng)實現(xiàn)低成本、可擴展的 數(shù)據(jù)存儲，并作為企業(yè)數(shù)據(jù)的 Single Source of Truth(SSOT);同時數(shù)據(jù)的數(shù)據(jù)格式是開放的，便于不同的應用靈活訪問。
數(shù)據(jù)湖解決了數(shù)據(jù)成本與擴展性、數(shù)據(jù)多樣性、數(shù)據(jù)孤島等問題，并同時滿足 BI 與 AI 應用對數(shù)據(jù)分析的訴求;但數(shù)據(jù)湖在數(shù)據(jù)分析性能、數(shù)據(jù)管理與治理方面仍然存在較大的挑戰(zhàn)。
三、湖倉分層架構的融合與應用
業(yè)界探索數(shù)據(jù)倉庫與數(shù)據(jù)湖的融合，湖倉分層架構應運而生。
數(shù)據(jù)倉庫與數(shù)據(jù)湖各有長處，業(yè)界持續(xù)在探索兩者如何更好的融合，在過去幾年湖倉分層的架構的到廣泛的應用。企業(yè)數(shù)據(jù)統(tǒng)一寫到數(shù)據(jù)湖，作為統(tǒng)一存儲，湖上開放的數(shù)據(jù)可以服務 AI、ML 等應用場景;數(shù)據(jù)湖上部分數(shù)據(jù)經(jīng)過 ETL 處理導入到數(shù)據(jù)倉庫服務 BI 等 OLAP 分析場景。
湖倉分層架構融合了數(shù)據(jù)湖與數(shù)據(jù)倉庫的優(yōu)勢，但面臨一些問題與挑戰(zhàn)。部分數(shù)據(jù)從數(shù)據(jù)湖導入到數(shù)據(jù)倉庫，數(shù)據(jù)鏈路的增長影響數(shù)據(jù)分析的時效性，兩份數(shù)據(jù)也會帶來冗余存儲、數(shù)據(jù)口徑不一致的問題;另外，對于數(shù)據(jù)倉庫里加工產(chǎn)生的數(shù)據(jù)，仍然很難高效的服務 AI 場景。
四、數(shù)據(jù)湖倉的興起
數(shù)據(jù)湖倉作為新一代數(shù)據(jù)分析架構，兼具數(shù)據(jù)倉庫與數(shù)據(jù)湖的優(yōu)勢。
新興的數(shù)據(jù)倉庫如 Snowflake、Redshift、BigQuery 均采用云原生存算分離架構演進，并且支持直接查詢開放數(shù)據(jù)湖的能力。數(shù)據(jù)湖在事務支持、查詢性能等方面的能力不如數(shù)據(jù)倉庫，近年來隨著新興數(shù)據(jù)湖格式如 Iceberg、Hudi、Delta Lake 等的發(fā)展，事務支持能力得到提升。
另外，在查詢性能上，通過不斷優(yōu)化數(shù)據(jù)湖上的數(shù)據(jù)分布以及增加緩存機制等技術的演進，數(shù)據(jù)湖上的數(shù)據(jù)分析性能已經(jīng)大幅提升，達到接近數(shù)據(jù)倉庫的水平。
從數(shù)據(jù)湖和數(shù)據(jù)倉庫的演進來看，兩者在不斷的融合，并逐步往數(shù)據(jù)湖倉的方向演進，兼具數(shù)據(jù)湖與數(shù)據(jù)倉庫的優(yōu)勢。數(shù)據(jù)湖倉作為一種新的數(shù)據(jù)分析架構，用戶采用湖倉就能方便將數(shù)據(jù)源和數(shù)據(jù)應用連接在一起。
數(shù)據(jù)湖倉兼具數(shù)據(jù)倉庫與數(shù)據(jù)湖的優(yōu)勢，湖倉具備開放統(tǒng)一的數(shù)據(jù)存儲能力，并基于統(tǒng)一存儲直接服務批處理、流處理、交互式分析等多種分析場景，實現(xiàn)湖倉 One data，all analytics 的業(yè)務價值。
五、StarRocks3.0：湖倉技術創(chuàng)新
StarRocks 2.0 版本憑借其優(yōu)異的查詢性能在業(yè)界得到廣泛應用，很多用戶采用湖倉分層架構，并將 Hive、Iceberg 等數(shù)據(jù)湖里的數(shù)據(jù)部分導入到 StarRocks 服務 OLAP 分析場景。
StarRocks 3.0的存算分離架構、極速湖倉分析和物化視圖技術，為用戶提供了高效、靈活的數(shù)據(jù)分析解決方案。
特性1：存算分離架構
StarRocks 存算分離 2023年4月正式發(fā)布，目前已有上百家用戶上線存算分離架構。與存算一體架構相比，保持了原有簡潔的架構;同時極大的降低數(shù)據(jù)存儲成本，提升計算的彈性能力。
訪問遠端對象存儲的延時相比本地存儲有數(shù)量級的提升，StarRocks 通過 Data Cache 機制提升數(shù)據(jù)訪問性能，確保熱數(shù)據(jù)與存算一體架構接近。根據(jù)實際測試，存算分離緩存命中的情況與存算一體架構相比性能完全相同;在完全冷查詢時，性能大概是存算一體的30-50%。
在存算分離架構下，StarRocks 可以方便的支持 Multi-warehouse 的能力;多個 Warehouse 共享一份數(shù)據(jù)，不同 Warehouse 應用在不同的 Workload，計算資源可以進行物理隔離，并且可以按需獨立彈性伸縮。
特性2：極速湖倉分析
StarRocks 3.0 提供統(tǒng)一 Catalog 管理的能力，用戶不僅能高效分析導入到 StarRocks 的數(shù)據(jù)，同時也支持直接分析開放數(shù)據(jù)湖 Apache Hive、Apache Iceberg、Apache Hudi、Apache Paimon 的數(shù)據(jù)，分析性能相比業(yè)界同類產(chǎn)品快3-5倍。
StarRocks 在查詢層 CBO、向量化、Runtime filter 等技術可以無縫應用到開放數(shù)據(jù)湖分析，但湖上數(shù)據(jù)分析還面臨一些其他挑戰(zhàn)。湖上數(shù)據(jù)一般以原始格式存儲，數(shù)據(jù)組織上沒有針對查詢優(yōu)化，同時訪問遠端對象存儲/HDFS 的延時相比本地盤更高。StarRocks 通過 I/O 合并、延遲物化、Data cache 等一系列關鍵技術加速湖上數(shù)據(jù)分析。另外，為了讓用戶平滑的獲得 StarRocks 極速湖倉分析性能，StarRocks 實現(xiàn)了 Trino 方言的兼容，用戶可以采用 StarRocks 無縫直替 Trino。
特性3：物化視圖
StarRocks 物化視圖提供了一種從預建模到后建模的方法，大大縮短業(yè)務建模以及上線時間。業(yè)務可以直接查詢原始數(shù)據(jù)，借助 StarRocks 極致的查詢性能，已經(jīng)能滿足絕大部分場景的需求;如果直接查詢性能不滿足，則可以按需構建物化視圖來加速查詢，StarRocks 支持物化視圖的透明查詢改寫，實現(xiàn)業(yè)務無感的情況下實現(xiàn)查詢加速。
湖倉應用：基于StarRocks構建Lakehouse
基于 StarRocks，用戶可以高效的構建 Lakehouse 數(shù)據(jù)分析架構，用戶可以選擇 StarRocks 內(nèi)表或開放數(shù)據(jù)湖 Apache Iceberg、Apache Hudi、Apache Paimon 做為統(tǒng)一的數(shù)據(jù)存儲，基于 StarRocks 服務BI報表、Ad-hoc 等多樣化的分析場景，對于業(yè)務性能要求高的查詢，通過物化視圖技術實現(xiàn)按需透明加速。
六、互聯(lián)網(wǎng)用戶的湖倉最佳實踐案例
本段落分析了騰訊微信、攜程旅行等企業(yè)如何利用StarRocks實現(xiàn)數(shù)據(jù)的準實時分析和查詢性能的顯著提升。
1.騰訊微信：數(shù)據(jù)寫入到 Iceberg，基于StarRocks實現(xiàn)準實時分析，數(shù)據(jù)新鮮度從小時/天到分鐘即，查詢性能提升3-6倍。
2.攜程旅行：數(shù)據(jù)統(tǒng)一存儲在Hive，通過 StarRocks直接服務BI報表，交互式分析。重點業(yè)務場景按需創(chuàng)建物化視圖查詢加速，查詢性能提升10+倍
結語
Lakehouse 兼具數(shù)據(jù)倉庫與數(shù)據(jù)湖的優(yōu)勢，是下一代數(shù)據(jù)分析架構的演進趨勢;StarRocks 是構建 Lakehouse 的最佳選擇，已在微信、小紅書、攜程、平安銀行等數(shù)十個大型企業(yè)落地實踐，幫助企業(yè)實現(xiàn) One data、all analytics 的業(yè)務價值。
（免責聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準確性及可靠性，但不保證有關資料的準確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負責。本網(wǎng)站對有關資料所引致的錯誤、不確或遺漏，概不負任何法律責任。
任何單位或個人認為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識產(chǎn)權或存在不實內(nèi)容時，應及時向本網(wǎng)站提出書面權利通知或不實情況說明，并提供身份證明、權屬證明及詳細侵權或不實情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關文章源頭核實，溝通刪除相關內(nèi)容或斷開相關鏈接。 ）
