隨著信息時代的興起，數(shù)據已成為推動業(yè)務決策和創(chuàng)新的核心要素；結構化、半結構化等多種類型的數(shù)據呈現(xiàn)爆炸式增長，如何高效處理和分析海量數(shù)據已經成為關鍵挑戰(zhàn)。

當前業(yè)界構建數(shù)據分析的技術棧，有兩條典型的路線，一個是數(shù)倉路線，一個是數(shù)據湖的路線。 數(shù)據倉庫的路線，數(shù)據先通過 ETL 統(tǒng)一寫入到數(shù)倉進行管理，然后構建數(shù)據集市來滿足 BI 分析的各種需求；優(yōu)勢是數(shù)據質量高、查詢性能高、具備實時分析的能力、數(shù)據治理功能完善等。 而數(shù)據湖的路線，通常是未經加工的數(shù)據先統(tǒng)一存儲在數(shù)據湖，作為企業(yè)數(shù)據的 single sourth of truth，然后按需的使用數(shù)據，構建數(shù)據應用；優(yōu)勢是通開放生態(tài)、擴展性強，性價比高。 數(shù)據倉庫

數(shù)據倉庫是一種將來自不同源的數(shù)據聚合到單個集中式一致數(shù)據存儲中的系統(tǒng)，以支持企業(yè)報表、數(shù)據分析、數(shù)據挖掘、人工智能和機器學習等應用。數(shù)據倉庫技術經過幾十年的發(fā)展，產品架構已經經過了多輪的迭代：

1.早期分析場景比較簡單，業(yè)務采用 Oracle/MySQL 為代表的關系型數(shù)據庫，在線處理與數(shù)據分析在一套系統(tǒng)里完成；但隨著數(shù)據分析場景的越來越復雜多樣化，這種方案的挑戰(zhàn)非常大，一是兩種負載會相互影響，同時數(shù)據分析的性能也不能滿足需求。

2.以 Teradata 、Oracle EDW 為代表的商用數(shù)據倉庫應運而生，專門針對大規(guī)模數(shù)據的管理與價值挖掘，這類數(shù)倉產品功能強大，但其商業(yè)成本太高，導致技術無法普及使用。

3.以 Hadoop（ Hive） 為代表的開源數(shù)倉，基于開源組件構建大數(shù)據平臺；Hadoop 生態(tài)讓大數(shù)據變成普惠技術，企業(yè)能夠低成本的基于開源 Hadoop 生態(tài)，構建企業(yè)級數(shù)倉平臺。

4.Hadoop 生態(tài)使用門檻低，但因為組件繁多，維護代價非常高，隨著新技術的發(fā)展，Hadoop 生態(tài)各組件的技術競爭力也在持續(xù)下降，以 Snowflake、Redshift、Bigquery 為代表云原生數(shù)倉，幫助企業(yè)構建一體化的數(shù)據處理與分析平臺。 數(shù)據湖

數(shù)據湖是以原始格式存儲數(shù)據的存儲庫或系統(tǒng)，它按原樣存儲數(shù)據，無需事先對數(shù)據進行結構化處理。

?數(shù)據湖通常采用 S3 對象存儲或 HDFS 分布式文件系統(tǒng)作為底層統(tǒng)一存儲，并作為 Single source of truth。 ?數(shù)據湖通常采用開放的數(shù)據格式，同時滿足結構化、半結構化等數(shù)據等存儲需求，并 ACID、Upsert、Time travle 等高級特性，滿足企業(yè)數(shù)據管理方面的各種訴求。 ?業(yè)界常見的數(shù)據湖包括 Apache Iceberg、Apache Hudi、Delta、Apache Paimon 等，業(yè)務采用 Trino、Presto、Impala 等引擎按需分析數(shù)據湖上的數(shù)據。 企業(yè)未來數(shù)據架構應該是建倉，還是建湖？ 其實，大家之所以有現(xiàn)在的糾結，是因為數(shù)據倉庫和數(shù)據湖各有優(yōu)劣，如果能將優(yōu)勢兼具，IT 架構工程師們也不必一定要選擇是湖還是倉。

目前在業(yè)界，很多企業(yè)正在不斷探索湖倉融合的路徑。 ?湖上建倉：企業(yè)的數(shù)據先進入到數(shù)據湖統(tǒng)一存儲，湖上直接性能不足，此時可以采用湖上建倉的方案，將查詢性能要求高的部分通過 ETL 導入到新的數(shù)據倉庫提供服務。 ?倉外掛湖：部分數(shù)據倉庫產品，例如 Redshift、Bigquery 等，開始擴展查詢外部數(shù)據湖（Hive、Iceberg 等）的能力，實現(xiàn)計算層的統(tǒng)一。 不管是湖上建倉、還是倉外掛湖的方案，本質上數(shù)據都是分開存儲，可能還會通過不同的引擎服務不同場景的查詢，更好的方案是實現(xiàn)湖倉一體化，讓數(shù)據分析的架構更加簡單。那到底什么是湖倉一體？

湖倉一體 當互聯(lián)網規(guī)模發(fā)展至一定程度后，企業(yè)數(shù)據的使用場景發(fā)生巨大變化，需求開始從離線轉而要求實時的數(shù)據分析，同時隨著企業(yè)數(shù)據規(guī)模極速增長，企業(yè)對于實時數(shù)據治理提出更高的要求，要求業(yè)務端數(shù)據能夠實時處理，進一步滿足基于數(shù)據的實時分析和決策。 湖倉一體是通過一套架構，滿足所有的分析需求，抽象化的描述，要能實現(xiàn) One Data、All Analytics 的業(yè)務價值。

1.統(tǒng)一數(shù)據存儲：在湖倉一體架構下，數(shù)據要統(tǒng)一存儲管理，一份數(shù)據作為 Single source of truth，避免導來導去，造成數(shù)據冗余，分析口徑不一致等問題；存儲層通常采用 S3/HDFS 作為數(shù)據存儲底層，并采用開放數(shù)據湖或者私有的數(shù)據格式去管理數(shù)據。

2.極速查詢引擎：基于統(tǒng)一的數(shù)據存儲，湖倉一體架構要能滿足所有的業(yè)務分析場景的訴求，包括 BI 報表、交互式分析、實時分析、ETL 數(shù)據加工等場景，這就要求必須要有一個足夠強大的分析引擎，能同時滿足這些場景的查詢需求。

3.按需查詢加速：對于部分業(yè)務場景特別復雜的查詢，數(shù)據源數(shù)據組織未針對分析優(yōu)化，直接分析不一定能滿足查詢延時的需求，湖倉一體架構要具備通用的數(shù)據查詢加速的能力，并且不破壞 Single source of truth 的原則。

目前， StarRocks 3.x 推出了存算分離、湖倉分析、物化視圖等重量級特性，能夠很好的幫助企業(yè)構建湖倉一體平臺，微信、攜程、小紅書等數(shù)十家大型企業(yè)進行實踐后，收獲極大的簡化數(shù)據平臺的技術棧，同時提升的服務性能。

那么，如何構建湖倉一體平臺？ 用戶可以將 StarRocks 當作一站式湖倉，數(shù)據統(tǒng)一導入到 StarRocks ，借助存算分離的架構，實現(xiàn)低成本的數(shù)據存儲，然后利用 StarRocks 查詢引擎來服務全場景的數(shù)據分析應用； 如果用戶的數(shù)據已經在開放數(shù)據湖（Hive、Hudi、Iceberg、Paimon），就可以通過 StarRocks 直接分析數(shù)據湖，同樣能獲得極高的查詢性能。 不管數(shù)據統(tǒng)一存儲在開放數(shù)據湖里還是 StarRocks 里，當查詢性能不足時，都可以利用物化視圖加速查詢性能。

基于此，用戶可以方便地構建湖倉一體平臺，實現(xiàn) One Data、All Analytics 的業(yè)務價值。 當然，對于有數(shù)據的安全、權限管理需要的企業(yè)，可以選擇基于 StarRocks 開發(fā)的企業(yè)級產品鏡舟湖倉分析引擎。 鏡舟湖倉分析引擎能夠兼容并加速企業(yè)已有的大數(shù)據架構如Hive、Iceberg、Hudi、Deltalake、MySQL 和 Oracle 等，有效幫助企業(yè)節(jié)省傳統(tǒng)架構中數(shù)據搬運的時間與成本， 通過簡化數(shù)據鏈路，實現(xiàn)數(shù)據分析性能指數(shù)級提升。同時，鏡舟湖倉分析引擎部署簡單、運維便捷，在為企業(yè)提速的同時降低系統(tǒng)及人力成本。 企業(yè)可以通過鏡舟湖倉分析引擎，支撐不同團隊和角色的數(shù)據使用訴求，在報表查詢、用戶畫像與行為分析、自助指標分析、實時風控等業(yè)務場景實現(xiàn)加速，給業(yè)務團隊帶來極速查詢、分析體驗，快速響應市場變化，為解決企業(yè)數(shù)據治理需求和數(shù)據集成提供更優(yōu)解。

審核編輯：黃飛