近十余年，移動互聯網的高速發展給互聯網用戶提供了更便捷的服務途徑，不管是在地鐵、飯店還是室外，用戶都可以隨時通過手機、pad等移動設備連接到高速的移動網絡，實現購物、社交、商務會議等各種網絡服務。與此同時，用戶源源不斷的產生和獲取大量的數據，使得數據流量呈現爆炸式的增長，不論是互聯網巨頭、零售、政府、金融等行業，在海量數據的存儲、查詢和分析場景，都需要一個能承載多種數據，支持超高并發、易擴容、易維護的實時湖倉。

那么，最近熱議的湖倉一體究竟是怎樣的技術？什么又是實時分析處理？實時湖倉一體技術的逐步成熟，能給我們帶來怎樣的想象空間呢？

大勢所趨，云原生實時湖倉一體

傳統關系型數據庫的技術架構，尤其是 OLTP 數據庫在海量數據的存儲、查閱以及分析方面出現了明顯的性能瓶頸。隨著分布式技術的產生和發展，出現了以 Teradata 為代表的基于專有硬件的MPP數據庫，以及 Greenplum 和 Vertica 等基于普通服務器的 MPP 數據庫。

在21世紀的前十年，大量企業開始采用MPP驅動的新型數據庫系統，MPP解決了單個SQL數據庫不能存放海量數據的問題，分析型MPP數據庫的激增和成本下降也為數據驅動型組織提供了巨大的機會來運營和分析比以往更大的數據集，但與此同時，數據的快速增長也為固有體系帶來額外的復雜性，MPP數據庫在集群規模上是有限制的，它所支持的應用主要還是適合小集群、低并發的場景。

2010年前后，大數據熱推動 Hadoop 技術快速普及，逐步形成了以Hadoop作為數據湖，MPP作為數據倉庫的協作模式。這個階段的 Hadoop+MPP 協作模式，也是“湖倉分體”模式。它讓湖和倉有很好的技術特性互補，但是它也會產生嚴重的數據孤島問題：同一份數據在多個集群冗余存儲，分體模式下的湖和倉各自形成數據孤島；數據達到PB 級別時， Hadoop 和 MPP 集群規模受限，Hadoop和MPP本身也需要拆成多個集群；在面對高并發數據查詢時，易造成業務應用崩潰。另外，湖+倉帶來的復雜的實施和運維問題更讓從業者頭疼不已。

為了保證存儲和計算可以獨立的彈性擴展和伸縮，數據平臺的設計出現了一個嶄新的架構，即存算分離架構。顯然，傳統 MPP 和 Hadoop 都不適應這樣的要求。MPP 數據庫存算耦合，而 Hadoop 不得不通過計算和存儲部署在同一物理集群拉近計算與數據的距離提高性能，僅在同一集群下構成邏輯存算分離。要真正的解決業務的痛點，選擇企業適合的湖倉產品，我們可以參考ANCHOR 標準來選型。ANCHOR 中文譯為錨點、頂梁柱，或將成為湖倉一體浪潮下的定海神針。ANCHOR 具有六大特性，其 6 個字母分別代表：All Data Types（支持多類型數據）、Native  on Cloud（云原生）、Consistency（數據一致性）、High Concurrency （超高并發）、One Copy of Data（一份數據）、Real-Time（實時 T+0）。通過使用 ANCHOR 六大特性，很容易判斷出某一系統設計是否真正滿足湖倉一體。

OushuDB與美國 Snowflake，Databricks這一代產品突破了傳統 MPP 和 Hadoop 的局限性，率先實現了存算完全分離，計算和存儲可部署在不同物理集群，并通過虛擬計算集群技術實現了高并發，同時保障事務支持，成為湖倉一體實現的關鍵技術。

全新框架，Omega全實時框架實現T+0

目前，實時處理有兩種典型的架構：Lambda 和 Kappa 架構。出于歷史原因，這兩種架構的產生和發展都具有一定局限性。

其中， Lambda 架構由于實時數據和T+1數據走不同計算和存儲，難保障數據的一致性，Kappa 依賴 Kafka 等消息隊列來保存所有歷史，難以實現更新、糾錯，故障升級周期長，并且不具備即席查詢數據，架構實際落地困難。同時兩個架構又都很難處理可變更數據（如關系數據庫中不停變化的實時數據），即便引入流處理引擎實現了部分固定模式的實時流處理分析，仍無達到 T+0 全實時水平（此處全實時包含實時流處理和實時按需查詢）。因此，我們需要一種新的架構滿足企業實時分析的全部需求，這就是基于偶數科技自主研發的云原生數據庫OushuDB的Omega 全實時架構。

Omega 架構由流數據處理系統和實時數倉構成。相比 Lambda 和 Kappa，Omega 架構新引入了實時數倉和快照視圖 (Snapshot View) 的概念，快照視圖是歸集了可變更數據源和不可變更數據源后形成的 T+0 實時快照，可以理解為所有數據源在實時數倉中的鏡像和歷史，隨著源庫的變化實時變化。因此，實時查詢可以通過存儲于實時數倉的快照視圖得以實現。另外，任意時間點的歷史數據都可以通過 T+0 快照得到，這樣離線查詢可以在實時數倉中完成，離線查詢結果可以包含最新的實時數據，完全不再需要通過 MPP+Hadoop 組合來處理離線跑批及分析查詢。

Omega 架構邏輯圖

偶數流處理系統WASP既可以實現實時連續的流處理，也可以實現 Kappa 架構中的批流一體，但與 Kappa 架構不同的是，OushuDB 實時數倉存儲來自 Kafka 的全部歷史數據，而在 Kappa 架構中源端采集后通常存儲在 Kafka 中。

因此，當需要流處理版本變更的時候，流處理引擎不再需要訪問 Kafka，而是訪問實時數倉 OushuDB 獲得所有歷史數據，規避了 Kafka 難以實現數據更新和糾錯的問題，大幅提高效率。此外，整個服務層也可以在實時數倉中實現，而無需額外引入 MySQL、HBase 等組件，極大簡化了數據架構。

在 Omega 全實時架構的加持下，偶數率先實現了具備實時能力的湖倉一體，即實時湖倉。實時湖倉統一了湖倉市（數據湖、數倉、集市），避免數據孤島的同時，極大提升了企業實時數據分析能力，讓企業在快速更迭的商業環境中立于不敗之地。

Lambda、Kappa 與 Omega 架構比較

數據說話，高性能OushuDB為企業保駕護航

一個新的Omega架構來實現實時湖倉，確實會令整個行業眼前一亮，但其性能究竟如何，與市面常見數據庫產品的性能相比，是否能交出滿意的答卷呢？

為了更直觀的比較OushuDB的查詢能力，我們用標準TPC-H來對OushuDB和其他知名的MPP數據庫產品Greenplum、ClickHouse進行測試。TPC-H是美國交易處理效能委員會組織制定的用來模擬決策支持類應用的一個測試集，目前在學術界和工業界普遍采用它來評價數據查詢處理能力。我們主要的評價指標是TPC-H包的22 個查詢(Q1~Q22)各個查詢的響應時間，即從提交查詢到結果返回所需時間，我們分別對不同平臺進行單節點使用Scale為100的數據集進行測試。測試結果顯示，OushuDB和Greenplum支持全面支持 TPC-H 的 22 條查詢語句，ClickHouse 只支持其中的部分語句；在性能方面，OushuDB表現優秀，總體性能在ClickHouse和Greenplum的5倍左右，很多查詢時間快一個數量級以上。

用戶信賴，新銳準獨角獸脫穎而出

盡管OushuDB只是一個誕生5年的云數據庫，但OushuDB卻是由國內頂尖工程師自主開發，其研發團隊曾主導國際頂級的數據庫開源項目，符合國家信創標準。偶數科技作為一家新興的數據庫公司，自2017年誕生以來，作為微軟加速器和騰訊加速器成員企業，已經獲得世界頂級投資機構紅杉中國、騰訊、紅點中國與金山云的四輪投資，并入選福布斯中國企業科技 50 強以及美國著名商業雜志《快公司》中國最佳創新公司 50 強。除了OushuDB，偶數科技的實時湖倉一體解決方案還包含自動化機器學習平臺 LittleBoy 、數據分析與應用平臺Kepler以及數據管理平臺 Lava等多個產品， 深厚的研發實力和優秀的產品性能吸引了廣泛的知名用戶群，目前已在金融、電信、制造、公安、能源和互聯網等行業得到廣泛的部署和應用。