很多用戶誤以為湖+倉=湖倉一體，可能是因?yàn)楹}一體整合了湖和倉各自的優(yōu)勢，所以誤認(rèn)為湖倉一體就是原有湖和倉的簡單整合而已。

站在技術(shù)架構(gòu)的角度就會更容易理解這個(gè)問題，過往建設(shè)數(shù)據(jù)湖采用 Hadoop，建設(shè)數(shù)倉采用 MPP 數(shù)據(jù)庫，很難想象 Hadoop+MPP=湖倉一體 會是怎樣詭異的架構(gòu)，因?yàn)?Hadoop 和 MPP 本身是無法兼容的，只能通過 Hadoop+MPP+統(tǒng)一管理組件 進(jìn)行邏輯整合，這其實(shí)是我們常說的“邏輯湖倉一體”、“湖倉分體”。

所以，就像西紅柿+雞蛋≠西紅柿炒雞蛋，湖+倉≠湖倉一體，本質(zhì)上是三種不同的事物，湖倉一體的架構(gòu)與現(xiàn)有的湖和倉都不一樣。湖倉一體的流行架構(gòu)是存算分離，一份數(shù)據(jù)，多個(gè)計(jì)算引擎可以共享同一份數(shù)據(jù)。這種架構(gòu)解決了 Hadoop+MPP 湖倉分體形成的數(shù)據(jù)孤島。

價(jià)值篇

確實(shí)，新技術(shù)的優(yōu)勢不僅體現(xiàn)在技術(shù)架構(gòu)上，必須在業(yè)務(wù)價(jià)值上形成創(chuàng)新點(diǎn)。為此我們經(jīng)過多個(gè)項(xiàng)目實(shí)踐和長期調(diào)研，總結(jié)出湖倉一體的六大創(chuàng)新點(diǎn) ANCHOR，同時(shí) ANCHOR 也可以作為檢驗(yàn)湖倉一體的金標(biāo)準(zhǔn)。

All Disparate Data（多源異構(gòu)數(shù)據(jù)）：支持關(guān)系表、文本、圖像、視頻等結(jié)構(gòu)化數(shù)據(jù)和非結(jié)構(gòu)化數(shù)據(jù)存儲。

Native on Cloud（云原生）：適合云環(huán)境，自由增減計(jì)算和存儲資源，按用量計(jì)費(fèi)，節(jié)約成本。

Consistency（數(shù)據(jù)一致性）：通過完善的事務(wù)機(jī)制，保障不同用戶同時(shí)查詢和更新同 一份數(shù)據(jù)時(shí)的一致性。

High Concurrency （超高并發(fā)）：支持?jǐn)?shù)十萬用戶使用復(fù)雜分析 查詢并發(fā)訪問同一份數(shù)據(jù)。

One Copy of Data（一份數(shù)據(jù)）：所有用戶（BI 用戶、數(shù)據(jù)科學(xué)家 等）可以共享同一份數(shù)據(jù)，避免數(shù)據(jù)孤島，實(shí)現(xiàn)一份數(shù)據(jù)，就必須采用開放的格式。

Real-Time（實(shí)時(shí)T+0）：通過全量數(shù)據(jù) T+0 的流處理和實(shí)時(shí)按需查詢，滿足基于數(shù)據(jù)的事前預(yù)測、事中判斷和事后分析。

• 平臺共享一份數(shù)據(jù)，存儲成本降低 2 倍
• 保障數(shù)據(jù)一致性，數(shù)據(jù)治理變得簡單，治理工作量降低 3 倍
• 平臺開發(fā)工作量降低 1 倍
• 平臺維護(hù)成本降低 2 倍

  
  

建設(shè)完湖倉一體之后，湖在哪里倉在哪里？
從概念上理解，湖倉一體架構(gòu)不再區(qū)分湖和倉。從數(shù)據(jù)存儲的角度，其數(shù)據(jù)存儲在低成本的存儲架構(gòu)之上，既擁有數(shù)據(jù)湖數(shù)據(jù)格式的開放靈活性，又繼承了數(shù)據(jù)倉庫的高性能、易用性和規(guī)范性。過往，構(gòu)建湖只能用 Hadoop 技術(shù)棧，否則存不下，做數(shù)倉就得用 MPP 數(shù)據(jù)庫，這本來就是割裂的，而現(xiàn)階的湖倉一體就不再有這樣的問題，所以湖和倉都在新的一體化平臺中，是架構(gòu)上的統(tǒng)一。

問題十一做湖倉一體是為了提升查詢性能，湖倉一體的數(shù)據(jù)量會越來越大，如何保障性能？
數(shù)據(jù)量越來越大恰恰是我們專注做湖倉一體的重要背景之一，也是湖倉一體重點(diǎn)要解決的問題。一個(gè)好的的湖倉一體架構(gòu)本質(zhì)上是存算分離的，因此，即便數(shù)據(jù)量越來越多，存儲和計(jì)算資源也可以有針對性的擴(kuò)展，保證平臺在面對數(shù)據(jù)快速膨脹的情況下仍然能夠高效執(zhí)行復(fù)雜查詢，此外，針對短時(shí)間內(nèi)大量的查詢需求，湖倉一體平臺可以通過彈性資源臨時(shí)增加計(jì)算資源來提升查詢效率。
需要注意的是，查詢性能不完全依賴環(huán)境資源，數(shù)據(jù)分區(qū)分片、索引優(yōu)化、查詢優(yōu)化、存儲優(yōu)化、緩存優(yōu)化等數(shù)據(jù)庫調(diào)優(yōu)策略都可以提升平臺性能。

實(shí)施篇

問題十二已經(jīng)有數(shù)據(jù)倉庫，將數(shù)據(jù)倉庫改造成湖倉一體容易嗎？
目前的數(shù)據(jù)倉庫基本都是基于 MPP 數(shù)據(jù)庫構(gòu)建的（當(dāng)然也有用 Oracle 做數(shù)倉的情況)，MPP 存算耦合，擴(kuò)展能力有限，而湖倉一體架構(gòu)的本質(zhì)要求是存算分離，因此要用支持存算分離、多計(jì)算集群架構(gòu)的分布式數(shù)據(jù)庫替換原來的 MPP，并和其他引擎（如 Spark/Flink 等）共享同一份數(shù)據(jù)。因此基于數(shù)倉的湖倉一體改造路徑是進(jìn)行傳統(tǒng)MPP產(chǎn)品替換，并對既有模型和應(yīng)用進(jìn)行改造。

問題十三已經(jīng)有數(shù)據(jù)湖，是否可以將數(shù)據(jù)湖改造成湖倉一體？
數(shù)據(jù)湖基本都是基于 Hadoop 構(gòu)建的，底層存儲是 HDFS，因此將數(shù)據(jù)湖改造成湖倉一體理論上是可行的，但是需要注意的是，數(shù)據(jù)要采用①開放的格式，以及②存算分離改造。之所以對 Hadoop 平臺進(jìn)行存算分離改造，是因?yàn)榇蠖鄶?shù)的 Hadoop 部署都是存算耦合的，存算分離改造的最佳方式就是引入存支持存算分離、多計(jì)算集群架構(gòu)的分布式數(shù)據(jù)庫，讓多個(gè)引擎（如 Spark/Flink 等）可以共享同一份數(shù)據(jù)。

問題十四你提到讓DB、 Spark 和 Flink 等多個(gè)引擎共享一份數(shù)據(jù)，引擎之間如果進(jìn)行分工？
引擎的分工方法和原則就是讓不同引擎做它最擅長的事情。傳統(tǒng)的數(shù)據(jù)湖和數(shù)據(jù)倉庫主要處理三大類數(shù)據(jù)：結(jié)構(gòu)化數(shù)據(jù)、非結(jié)構(gòu)化數(shù)據(jù)、流式數(shù)據(jù)，因此可以有針對性采用不同引擎進(jìn)行數(shù)據(jù)的處理。比如，針對流數(shù)據(jù)處理，建議使用應(yīng)用廣泛的 Flink；針對非結(jié)構(gòu)化數(shù)據(jù)和機(jī)器學(xué)習(xí)等場景，建議使用 Spark；針對結(jié)構(gòu)化數(shù)據(jù)的查詢和跑批等核心場景，建議采用支持存算分離、多計(jì)算集群架構(gòu)的分布式數(shù)據(jù)庫，比如 OushuDB。

湖倉一體虛擬計(jì)算集群示意圖

問題十五目前我們企業(yè)既有湖也有倉，應(yīng)該新建湖倉一體，還是基于湖和倉改造升級比較好？升級改造的話，是從湖到湖倉一體還是從倉到湖倉一體？
對于有湖有倉的用戶，可以考慮從湖到湖倉一體的改造路線，并使用支持存算分離、多計(jì)算集群架構(gòu)的分布式數(shù)據(jù)庫替換傳統(tǒng)的數(shù)倉，請參考上一個(gè)回答的詳細(xì)內(nèi)容。當(dāng)然也可以考慮新建。

問題十六基于原有的湖進(jìn)行湖倉一體改造，改造工作量大嗎？
改造的工作量有些是基于需求而變化的，這里我們可以討論下一些必須的改造工作。
首先要看客戶是不是有數(shù)據(jù)倉庫。如果有數(shù)據(jù)倉庫，就需要進(jìn)行數(shù)倉的遷移，要理清數(shù)據(jù)倉庫的模型情況，實(shí)施過程還涉及到數(shù)據(jù)遷移，模型遷移，腳本遷移，還有做應(yīng)用接口改造，遷移過程中需要有自動化遷移工具。如果沒有數(shù)倉，遷移的工作就可以省去，但湖倉一體平臺建設(shè)就要覆蓋數(shù)據(jù)建模等工作，從0到1實(shí)現(xiàn)數(shù)據(jù)建模也是不小的工程。此外，原數(shù)據(jù)湖與新湖倉一體雖然可以共用底層存儲，比如 HDFS，S3 等，但仍涉及到腳本和應(yīng)用遷移。

這里還要分享一點(diǎn)，就是我們不要畏懼平臺改造，平臺改造過程中可以重新梳理數(shù)據(jù)脈絡(luò)，找出數(shù)據(jù)隱藏的暗病。解決了既有的數(shù)據(jù)問題，落地的湖倉一體平臺才會是一個(gè)高效的平臺。

問題十七管理數(shù)據(jù)湖和管理數(shù)倉是兩個(gè)團(tuán)隊(duì)，實(shí)現(xiàn)湖倉一體后組織架構(gòu)需要什么變化嗎？
對于業(yè)務(wù)側(cè)，湖倉一體的實(shí)現(xiàn)會直接影響企業(yè)的數(shù)字化轉(zhuǎn)型戰(zhàn)略，業(yè)務(wù)側(cè)的組織架構(gòu)的變化應(yīng)該根據(jù)企業(yè)數(shù)字化轉(zhuǎn)型戰(zhàn)略進(jìn)行調(diào)整。對于技術(shù)側(cè)，IT 體系比較龐大的企業(yè)組織內(nèi)部很可能會區(qū)分?jǐn)?shù)據(jù)湖團(tuán)隊(duì)和數(shù)據(jù)倉庫團(tuán)隊(duì)，兩個(gè)團(tuán)隊(duì)之間一般是平行關(guān)系，這也是由于以往技術(shù)架構(gòu)割裂和業(yè)務(wù)歸口造成的歷史原因。湖倉一體實(shí)現(xiàn)后，生態(tài)整合了，技術(shù)可擴(kuò)展性更強(qiáng)了，易用性更高了，湖倉一體平臺依然包括多個(gè)組件，比如數(shù)據(jù)庫，不同的計(jì)算引擎，存儲，調(diào)度，ETL 工具，數(shù)據(jù)資產(chǎn)管理，BI 工具等，根據(jù)用戶的具體情況，依然需要多人或者多個(gè)團(tuán)隊(duì)合作。但這本質(zhì)上是管理問題，不是技術(shù)問題，管理問題首先還是應(yīng)該理清企業(yè)自身的管理訴求和數(shù)字化轉(zhuǎn)型戰(zhàn)略。

標(biāo)簽：OushuDB國產(chǎn)數(shù)據(jù)庫偶數(shù)科技湖倉一體