《ANCHOR：區(qū)分 “湖倉一體” 和 “湖倉分體” 的錨》
引言：隨著企業(yè)數字化轉型進入深水區(qū)，越來越多的企業(yè)視湖倉一體為數字變革的重要契機，湖倉一體也受到了前所未有的關注。當然，關注度越高市場上的聲音也就越嘈雜，很多過時甚至錯誤的湖倉一體技術和理念不脛而走，很有可能將轉型中的企業(yè)引入歧途，推高數據孤島，造成資源浪費甚至錯過數字化轉型的戰(zhàn)略時機。
偽湖倉一體自然是我們不愿看到的，而想要理解什么是真正的湖倉一體，則需要對技術背景及其演進歷程有清晰的認知，當然這對多數讀者都很挑戰(zhàn)，因此筆者嘗試從技術背景和發(fā)展脈絡的角度給出湖倉一體的終極答案。
一、從數據倉庫說起
1、發(fā)展背景
業(yè)務增長源源不斷的產生數據，這些數據存儲在業(yè)務數據庫中，也就是我們常說的 OLTP 數據庫。當積壓的歷史數據越來越多，對業(yè)務數據庫產生負載，導致業(yè)務系統(tǒng)運行速度降低；同時，在日益激烈的市場競爭中，企業(yè)需要對積累的數據進行分析，獲取更加準確的決策信息來完成市場推廣、運營管理等工作。由此，提出將歷史數據存儲到數據倉庫 (OLAP)，改善業(yè)務系統(tǒng)數據庫性能的同時，可以更專注的提升數據分析效率，輔助企業(yè)決策。2、技術演進
傳統(tǒng)關系型數據庫的技術架構，尤其是 OLTP 數據庫無法有效滿足大量歷史數據的存儲、查閱以及數據分析需求。隨著數據倉庫技術進一步發(fā)展，分布式數據庫產生，出現了以 Teradata 為代表的MPP 一體機 數據庫產品，此后又出現了 Greenplum 和 Vertica 等基于標準 x86 服務器的 MPP 數據庫，他們采用無共享架構 (Share-nothing) 以支持數據倉庫的建設。這個階段主要建設 OLAP 類型的系統(tǒng)，如數據倉庫、ODS、數據集市、應用數據庫、歷史數據庫以及報表、分析報告、數據挖掘、客戶標簽畫像等。
在數據模型方面，以銀行業(yè)為例，很多銀行建立主題模型都選用 Teradata FS-LDM (Financial Services Logical Data Model) 和 IBM BDWM (Banking Data Warehouse Model)。不同行業(yè)有不同的數據模型。
3、階段特點
該階段早期，不少企業(yè)直接采用了共享存儲架構的 Oracle 和 Db2，也有不少客戶采用了 MPP 無共享 Share-nothing 架構的產品。早期 MPP 采用軟硬一體的專有服務器和昂貴的存儲，比如 Teradata，后期 MPP 大多采用標準 x86 服務器，架構依然是無共享 Share-nothing 架構，數據以結構化為主，集群的擴展能力有限?；诠蚕泶鎯軜嫷臄祿旒阂?guī)模通常在幾十節(jié)點，MPP 基本在百節(jié)點級別，支持數據體量有限，很難超過 PB 級別。
二、大數據平臺逐漸流行
時間來到 2012 年，國內一些技術發(fā)展較快的行業(yè)，如電信和頭部銀行（國有大行和股份制銀行）基本都完成了數據倉庫的建設。彼時 Hadoop 技術快速普及，大數據平臺開始受到關注，尤其受互聯網行業(yè)迅速發(fā)展的影響，大數據平臺迎來歷史的高光時刻。
1、發(fā)展背景
互聯網以及很多行業(yè)線上業(yè)務的快速發(fā)展，讓數據體量以前所未有的速度增長，企業(yè)對海量數據的處理有了更高要求，如非結構化數據處理、快速批處理、實時數據處理、全量數據挖掘。由于傳統(tǒng)數據倉庫側重結構化數據，建模路徑較長，面對大規(guī)模數據處理力有未逮，而企業(yè)亟需提升大數據處理時效，以更經濟的方式發(fā)掘數據價值。2、技術演進
企業(yè)開始使用 Hadoop 分布式大數據計算和存儲，同時 Hive，Spark、Impala 等數據處理技術進一步發(fā)展，Spark Streaming、Flink 等實時數據處理技術也讓大數據平臺具備了實時數據處理能力。Hadoop 一般使用 HDFS 存儲數據，其計算引擎使用 MapReduce，Spark 等實現。雖然 Hadoop 邏輯上實現了計算和存儲分離，但是其物理部署架構依然強調在每一個節(jié)點同時部署計算節(jié)點和存儲節(jié)點，通過將計算置于存儲所在的位置，利用數據本地性提升計算性能。3、階段特點
Hadoop 得到了廣泛的認可，大數據熱讓人們對 Hadoop 抱有更高的期待，認為既然 Hadoop 平臺能解決很多數據處理和分析問題，自然可以替代傳統(tǒng)的數據倉庫。但是，隨著 Hadoop 大數據平臺建設逐步推廣，企業(yè)嘗試將 Hadoop 用于一些非核心場景（如銀行的三方數據平臺）之后，發(fā)現 Hadoop 不僅性能和并發(fā)支持有限，而且事務支持弱，交付、運維成本高，企業(yè)最終意識到基于 Hadoop 的大數據平臺終究無法替代核心數倉。投身 Hadoop 技術的兩家頭部企業(yè) Cloudera 和 Hortonworks 經歷了上市的高光時刻，最終在合并后退市了。三、無奈之舉，湖倉分體
1、發(fā)展背景
無法替代數據倉庫，但是 Hadoop 逐漸形成了自身特殊的定位——數據湖。Gartner 曾指出，數據湖存儲著各種數據資產，這些資產使用與源數據類似或者相同的格式。數據湖對全量的、各種類型的數據進行存儲和挖掘，為數據科學家提供基于任意原始數據開發(fā)應用的敏捷性，而不必局限于數倉的數據，這是數據湖優(yōu)于傳統(tǒng)數倉之處。但數據湖卻始終無法滿足用戶在性能、事務等方面的要求，所以企業(yè)的 IT 建設通常先讓所有數據入湖，便于自由靈活的數據分析和探索，在某個分析逐步成熟時，將其轉移到數據倉庫，這樣就形成了數據湖和數據倉庫互補的方式（如下圖所示）。
除了技術特性互補，數據湖和數據倉庫在項目投入成本方面也有互補性。由于湖和倉的架構不同，長期項目投入的“性價比”差異很大。數據湖起步成本低，但隨著數據體量增大，項目成本快速上升；數據倉庫則恰恰相反，前期建設投入大，后期管理成本較低。
2、技術演進
湖和倉相互協(xié)作的前提是各自的技術都相對穩(wěn)定成熟，在此階段，湖和倉都出現了一些典型產品，既有 Greenplum、Vertica、GaussDB 等 MPP 數據庫，也有 Cloudera、AWS、阿里云、騰訊云等廠商基于 Hadoop 的數據湖解決方案。企業(yè)在構建數據湖的同時，也使用MPP，即湖+倉模式，湖是湖，倉是倉，湖倉各自獨立部署，數據通過ETL的方式打通，這就是業(yè)內常說的 Hadoop+MPP 模式，我們稱之為湖倉分體模式。3、階段特點
這個階段最大的特點和問題就是數據孤島。造成數據孤島的原因有幾個方面：1）湖倉分體方案基本上是以湖、倉和其他組件構成，邏輯上為用戶提供統(tǒng)一的數據管理，但物理層面湖和倉仍然是分離的，同一份數據在多個集群冗余存儲，導致分體模式下的湖和倉各自形成數據孤島。2）除了技術架構原生造成的數據孤島，集群規(guī)模受限又進一步造成數據孤島。多數的湖通過 Hadoop 構建，數倉是 MPP 數據庫，當數據達到 PB 級別，由于 Hadoop 和 MPP 集群規(guī)模受限，企業(yè)往往會部署和使用多個 Hadoop 集群和多個 MPP 集群，事實上進一步造成了數據孤島。目前業(yè)界的實踐確實也是多集群同步進行，例如字節(jié)跳動有多達幾十個 Hadoop 集群，很多國有大行有多達幾十個 MPP 集群。3）越來越多的分析應用場景導致了逐漸高漲的并發(fā)查詢需求，面對動輒就查詢數百 TB 的業(yè)務場景，無論是Hadoop 還是 MPP 都法支撐這種復雜查詢的并發(fā)需求。MPP 數據庫單一集群支持的并發(fā)數僅達到幾十左右，而 Hadoop 支持的并發(fā)則更低，一個復雜查詢可能會遍歷數百 TB 數據，使整個系統(tǒng)的性能受到很大影響。此外，SQL 的編寫問題也可能會影響到系統(tǒng)其它用戶，很多 DBA 都經歷過每次應用上線時的膽戰(zhàn)心驚，生怕新應用導致既有業(yè)務應用崩潰。為了滿足高并發(fā)，企業(yè)不得不把業(yè)務分割到更多的集群中，造成更嚴重的數據孤島。技術層面無法實現湖倉一體化，自然要通過打通湖倉疏解數據孤島，這個過程又催生了一系列復雜的實施和運維問題，如 ETL 邏輯復雜，數據變更困難，數據不一致，數據治理困難。此外，湖倉分體模式在前文提到的項目成本方面，也無法發(fā)揮湖和倉的成本互補性。四、技術崛起，湖倉一體
1、發(fā)展背景
湖倉分體模式持續(xù)筑高數據孤島并引發(fā)一系列實施、運維和成本問題，那么湖倉一體能否徹底解決這些問題？應該從哪些方面入手？湖倉一體有何標準？Gartner 認為湖倉一體是將數據湖的靈活性和數倉的易用性、規(guī)范性、高性能結合起來的融合架構，無數據孤島。前文總結的造成數據孤島的三點主要原因：(1) 異構技術架構、(2) 集群規(guī)模受限、(3) 集群高并發(fā)受限，都應該在湖倉一體架構中得以解決。除此之外，近年來數字化轉型帶來的業(yè)務需求和技術難點也應該在新一代的湖倉一體架構中得到關注和解決，具體包括如下四個方面：1）隨著線上業(yè)務迅猛發(fā)展，摸著“數據”過河，小步快跑推動了企業(yè)“實時”需求的升級。在很多線上場景中，實時性成為了提升企業(yè)競爭力的核心手段。但是目前的湖、倉、或者湖倉分體都是基于 T+1 設計的，面對 T+0 的實時按需分析，即便引入流處理引擎實現了部分固定模式的實時分析，仍無達到 T+0 全實時水平。2）從 Snowflake 在資本市場賺足眼球，到 Databricks 和 Snowflake 因 TPC-DS 測試結果在湖倉戰(zhàn)場正面對決，我們發(fā)現云原生數據庫已經逐漸成熟，成為了湖倉一體落地的重要法門。3）為釋放數據價值提升企業(yè)智能化水平，數據科學家等用戶角色必須通過多種類型數據進行全域數據挖掘，包括但不限于歷史的、實時的、在線的、離線的、內部的、外部的、結構化的、非結構化數據。4）傳統(tǒng) Hadoop 在事務支持等方面的不足被大家詬病，在高速發(fā)展之后未能延續(xù)熱度，持續(xù)引領數據管理，因此事務支持在湖倉一體架構中應得到改善和提升。2、ANCHOR 定義湖倉一體
理解了上文湖倉一體應該關注的重點，湖倉一體的本質和要求也就呼之欲出——真正的在數據和查詢層面形成一體化架構，徹底解決實時性和并發(fā)度，以及集群規(guī)模受限、非結構化數據無法整合、建模路徑冗長、數據一致性弱、性能瓶頸等問題，有效降低 IT 運維成本和數據管理的技術門檻。為此我們總結出湖倉一體 ANCHOR 標準，ANCHOR 中文譯為錨點、頂梁柱，或將成為湖倉一體浪潮下的定海神針。ANCHOR 具有六大特性，其 6 個字母分別代表：All Data Types（支持多類型數據）、Native on Cloud（云原生）、Consistency（數據一致性）、High Concurrency（超高并發(fā)）、One Copy of Data（一份數據）、Real-Time（實時T+0）。使用 ANCHOR 六大特性很容易判斷出某一系統(tǒng)設計是否真正滿足湖倉一體。
3、ANCHOR 的業(yè)務價值
滿足 ANCHOR 定義的湖倉一體將在哪些方面為企業(yè)帶來價值？可以概括為以下六個方面。
1）實時 T+0（Real-Time）：通過全量數據 T+0 的流處理和實時按需查詢，滿足基于數據的事前預測、事中判斷和事后分析。2）一份數據（One Copy of Data）：所有用戶（BI 用戶、數據科學家等）可以共享同一份數據，避免數據孤島。3）超高并發(fā)（High Concurrency）：支持數十萬用戶使用復雜分析查詢并發(fā)訪問同一份數據。4）數據一致性（Consistency）：通過支持完善的事務機制，保障不同用戶同時查詢和更新同一份數據時的一致性。5）云原生（Native on Cloud）：適合云環(huán)境，自由增減計算和存儲資源，按用量計費，節(jié)約成本。6）支持多類型數據（All Data Types, Structured & Unstructured）：支持關系表、文本、圖像、視頻等結構化數據和非結構化數據存儲。接下來，我們展開分析下滿足 ANCHOR 的湖倉一體為企業(yè)帶來的價值。1）實時 T+0（Real-Time）
通過全量數據 T+0 的流處理和實時按需查詢，滿足基于數據的事前預測、事中判斷和事后分析。當下，瞬息萬變的商業(yè)社會要求企業(yè)更快的做出商業(yè)決策。從“雙十一 ”和春晚直播實時大屏、銀行和稅務的風險實時阻斷、機器學習建模逐步在線化等趨勢中，我們可以發(fā)現，企業(yè)除了離線數據分析還有大量的實時數據分析需求。運營層面：實時業(yè)務變化，實時營銷效果，當日分時業(yè)務趨勢分析等；
C 端用戶層面：搜索推薦排序，實時行為等特征變量的生產，為用戶推薦更精準的內容；
風控層面：實時風險識別、反欺詐、異常交易等都是廣泛應用實時數據的場景；
生產層面：實時監(jiān)控系統(tǒng)的穩(wěn)定性和健康狀況等。
某一產品 5 分鐘的點擊量；
某一頁面 1 周的訪問量；
某一用戶 30 天內查詢征信報告的次數。
2）一份數據（One Copy of Data）
所有用戶（BI 用戶、數據科學家等）可以共享同一份數據，避免數據孤島。不同的用戶在不同的應用場景會使用很多同樣的數據，比如銀行做反洗錢應用需要使用交易數據，做營銷用戶畫像也需要使用交易數據。在傳統(tǒng)的湖倉分體架構中，同樣的數據會有多個副本，不同用戶使用各自的副本并更新其副本，這樣就產生了數據冗余存儲以及數據更新引發(fā)的數據不一致等問題，因此，基于不同數據得出的相關分析結論可能會有較大出入，各個應用基于同樣的定義計算出的指標也可能不一致，這當然是企業(yè)管理層和決策者不愿看到的。ANCHOR 標準保障所有用戶可以共享同一份數據，避免數據孤島，這樣的優(yōu)勢對業(yè)務管理和發(fā)展有非常大的幫助，極大降低了業(yè)務人員和技術用戶使用和運營數據的難度。當然，這也在技術層面向基礎數據平臺提出了更高的要求。
3）超高并發(fā)（High Concurrency）
支持數十萬用戶使用復雜分析查詢并發(fā)訪問同一份數據。正如前文所提到的小步快跑，我們依靠數據進行決策的頻率越來越高，智能應用場景越來越多，企業(yè)內部的數據科學家和分析團隊的規(guī)模、用戶數也越來越大。比如一個大型國有銀行，并發(fā)進行分析查詢的作業(yè)和用戶數可達到上萬。如果單集群實現不了高并發(fā)，就只能分庫分表使用多個集群，數據在不同集群內部重復存儲，不可避免的形成數據孤島。如何實現分析類復雜查詢的高并發(fā)呢？有必要了解下分析型數據庫（OLAP）的現狀。幾乎每個中國網民都對“雙十一在線剁手”和“12306 春運搶票”都有深刻體會，似乎百萬用戶同時在線訪問同一應用已不是難題，但是，人們可能不清楚傳統(tǒng)的交易型數據庫（OLTP）中的查詢基本只訪問單行數據，可通過索引實現毫秒級操作，因此 OLTP 支持百萬用戶在線訪問數據庫并不難。然而，在分析型場景中很多查詢都是復雜查詢，有時甚至會掃描幾百 TB 的數據，單個查詢可能達到分鐘乃至小時級，當分析型的 MPP 或者 Hadoop 進行復雜查詢達到幾十并發(fā)的時候，其吞吐量就會下降，如前文所述，一個涉及海量的復雜查詢可能會影響到整個系統(tǒng)的性能。ANCHOR 要求的超高并發(fā)在新技術的迭代中成為可能，進而支持百萬用戶同時在線查詢分析。4）數據一致性（Consistency）
通過支持完善的事務機制，保障不同用戶同時查詢和更新同一份數據時的一致性。何為事務？其本質是一組單元化操作，這些操作要么都執(zhí)行，要么都不執(zhí)行，是一個不可分割的工作單位。事務（Transaction）所應該具有的四個要素：原子性（Atomicity）、一致性（Consistency）、隔離性（Isolation）、持久性（Durability），這四個基本要素被稱為 ACID 特性。以最為常見的銀行轉賬為例，我向張三轉 1 萬元，在毫秒內要完成：第 1 步：將我的余額減去 1 萬第 2 步：將我的余額更新到數據庫第 3 步：將張三的余額加上 1 萬第 4 步：將張三的余額更新到數據庫。假設在執(zhí)行第 2 步驟之后，服務器忽然宕機，就會發(fā)生一件詭異的事情——我的賬戶少了 1 萬，但是錢并沒有到張三的賬戶上，這 1 萬憑空消失了！要解決這個問題，就要保證轉賬過程所有數據庫的操作是不可分割的，要么全部執(zhí)行成功，要么全部失敗，不允許出現中間狀態(tài)的數據。因此湖倉一體 ANCHOR 完善的事務尤為重要。想象一下，企業(yè)的數據分析師和數據科學家等眾多用戶同時進行數據查詢和更新，數據一致性無法保證對數據分析工作將造成怎樣的影響，嚴重的話可能會影響到企業(yè)關鍵的管理決策。5）云原生（Native on Cloud）
適合云環(huán)境，自由增減計算和存儲資源，按用量計費，節(jié)約成本。云原生架構的本質是存算分離技術，基于云原生架構的數據云平臺會為企業(yè)帶來哪些價值？可以概括為四個方面：降低技術門檻、減少維護成本、提升用戶體驗、節(jié)省資源費用。降低技術門檻：無論是自建機房還是使用公有云，都離不開底層大數據技術，大數據技術儼然成為了企業(yè)的標配技能，然而并不是每個企業(yè)都能組建專業(yè)的人才團隊，尤其是一些傳統(tǒng)行業(yè)和中小企業(yè)。像集群性能調優(yōu)等較為硬核的能力，更是很多已經搭建數據平臺的企業(yè)所缺失的。云原生技術使得 dbPaaS 為企業(yè)提供更好的數據平臺服務，正如 Snowflake 所倡導的：用戶不需要調優(yōu)，只要按需設置性能參數。減少維護成本：即便勉強跨過技術門檻，全方位的運維也是需要企業(yè)投入大量精力和資源的。技術運維主要包括但不限于：集群搭建
集群擴縮容
日常運維
監(jiān)控告警等
數據不斷增長讓技術負責人不得不為今后的數據管理留出資源冗余，在數據規(guī)模接近資源邊界之前，企業(yè)的資源都一直處于未完全利用的狀態(tài)，這就造成了早期投資的浪費，而當企業(yè)數據規(guī)?；蛘邞脠鼍霸龆?，往往是計算資源提前耗盡而無法有效支持業(yè)務場景；
另一方面，即便在一段時間內數據規(guī)模和應用場景變化不大，不同時段的資源利用水平和需求也不一樣，比如白天和夜晚、工作日和休息日，平臺資源都處于不同程度的閑置狀態(tài)。
6）支持多類型數據（All Data Types, Structured & Unstructured）
支持關系表、文本、圖像、視頻等結構化數據和非結構化數據存儲。任何企業(yè)的全量數據都會包含多樣的數據類型，這些數據可能來自歷史的、實時的、在線的、離線的、內部的、外部的、結構化的、非結構化，因此支持多類型數據也是湖倉一體 ANCHOR 的基本要求。傳統(tǒng)數據庫通常利用數據查詢及可視化報表來分析業(yè)務成因，而機器學習可以超越關系歸納自動找出數據模型與關系的特征，這已然超越了我們經驗、知識和想象力，比如著名的“超市中尿布和啤酒常被同時購買”的案例。但是，很多關系特性隱藏于我們不常關注的非結構化數據中，數據科學家等相關用戶角色只有通過多種類型的全域數據進行挖掘，才能真正發(fā)揮數據價值進而提升企業(yè)在數據智能領域的競爭水平。五、湖倉一體技術分析
1、技術演進
公有云和私有云的普及讓一切軟件上云成為趨勢，為了保證存儲和計算可以獨立的彈性擴展和伸縮，數據平臺的設計出現了一個嶄新的架構，即存算分離架構。顯然，傳統(tǒng) MPP 和 Hadoop 都不適應云平臺的要求。MPP 數據庫存算耦合，而 Hadoop 不得不通過計算和存儲部署在同一物理集群拉近計算與數據的距離，僅在同一集群下構成存算分離。在此階段，Snowflake 和 OushuDB 突破了傳統(tǒng) MPP 和 Hadoop 的局限性，率先實現了存算完全分離，計算和存儲可部署在不同物理集群，并通過虛擬計算集群技術實現了高并發(fā)，同時保障事務支持，成為湖倉一體實現的關鍵技術。以 OushuDB 為例，實現了存算分離的云原生架構，并通過虛擬計算集群技術在數十萬節(jié)點的超大規(guī)模集群上實現了高并發(fā)，保障事務支持，提供實時能力，一份數據再無數據孤島。同時，偶數科技通過首創(chuàng)的 Omega 架構保障了湖倉一體 ANCHOR 的實時性，形成了具備全實時能力的實時湖倉一體。關于實時處理技術架構的發(fā)展，會在下文單獨討論。
在 Hadoop 近期的生態(tài)發(fā)展中，Iceberg，Hudi 以及 Delta Lake 通過存儲層的設計，基于 HDFS/S3 實現數據更新的事務一致性。為了使用支持事務的存儲層，上層計算引擎不得不繼續(xù)使用 Spark 或 Flink 等。由于 Spark 和 Flink 在并發(fā)和實時查詢等方面的局限性，Iceberg，Hudi 等的創(chuàng)新還未能在 Hadoop 基礎上產生更深遠的影響。
2、方案比較
目前常見的湖倉一體方案主要基于 Hudi、Iceberg、Delta Lake、Snowflake、OushuDB。從下表分析可以看出來，湖倉一體解決方案大致可以分為兩大類：1）基于 Hadoop 的改造方案（Hudi、Iceberg、Delta Lake 方案）2）基于新一代云原生數據倉庫架構的方案（Snowflake、OushuDB 方案）基于 Hadoop 改造方案主要從事務特性出發(fā)做優(yōu)化，比如 Iceberg 和 Hudi 等基于 HDFS 或 S3 實現一個支持事務的存儲層，其他方面與 Hadoop 區(qū)別不大。而從新的基礎架構發(fā)展出的云原生數據倉庫，其存算分離特性更具有技術前瞻性，該架構將是未來的發(fā)展趨勢。
下表給出了主要湖倉一體解決方案的特性，并結合 ANCHOR 六要素進行對比，我們可以發(fā)現并非所有湖倉一體的方案都完全滿足 ANCHOR，尤其在 T+0 實時特性方面。
六、Omega 保障 ANCHOR 實時特性
前文我們列舉了湖倉一體實時特性的典型應用場景，如運營層面的實時營銷效果、C 端用戶層面的實時行為等特征、風控層面的實時風險識別、生產層面的實時系統(tǒng)監(jiān)控。這些都是基于業(yè)務場景的，而站在技術角度可以將實時需求分為三類：實時流處理、實時按需分析、離線分析。為什么是這三類需求？Gartner 給出過明確的分析：通過下圖，以一個事件發(fā)生的前后作為時間軸，可以將時間線分為三個階段，分別是事件發(fā)生的同時、事件發(fā)生后短時間內、事件發(fā)生后較長時間，對應的實時要求分別是實時流處理、實時按需分析、離線分析。
1、Lambda架構
1）Lambda產生背景
當運行大量數據時，Hadoop 所耗費的時間也會變得越來越多，無法滿足一些需要實時分析處理的場景（比如抖音、淘寶的動態(tài)推薦），因此新的流式計算引擎如 Spark Streaming、Flink、Storm 等開始出現。流處理、批處理配合使用才能滿足絕大部分應用場景，因此Lambda 架構被提出。2）Lambda實現原理
Lambda 架構通過把數據分解為服務層（Serving Layer）、速度層（Speed Layer，亦即流處理層）、批處理層（Batch Layer）三層來解決不同數據集的數據需求。在批處理層主要對離線數據進行處理，將接入的數據進行預處理和存儲，查詢直接在預處理結果上進行，不需再進行完整的計算，最后以批視圖的形式提供給業(yè)務應用。
3）Lambda 優(yōu)勢與不足
優(yōu)點：是將流處理和批處理分開，很好的結合了批處理和實時流計算的優(yōu)點，架構穩(wěn)定，實時計算成本可控，提高了整個系統(tǒng)的容錯性。缺點：(1) 由多個引擎和系統(tǒng)組合而成，批處理 (Batch)、流處理 (Streaming) 以及合并查詢 (Merged Query) 的實現需要使用不同的開發(fā)語言，造成開發(fā)、維護和學習成本較高；(2) 數據在不同的視圖 (View) 中存儲多份，浪費存儲空間，數據一致性的問題難以解決。2、Kappa 架構
1）Kappa 產生背景
既然 Lambda 架構難保證數據一致性，雙倍維護系統(tǒng)成本，那么一套系統(tǒng)解決批處理和流處理的訴求就產生了，對應的解決方案便是 Kappa 架構（即批流一體）。2）Kappa 實現原理
Kappa 架構在 Lambda 架構的基礎上移除了批處理層，利用流計算的分布式特征，加大流數據的時間窗口，統(tǒng)一批處理和流處理，處理后的數據可以直接給到業(yè)務層使用。因為在 Kappa 架構下，作業(yè)處理的是所有歷史數據和當前數據，其產生的結果我們稱之為實時批視圖（Realtime_Batch_View）。
3）Kappa 優(yōu)勢與不足
優(yōu)點：由于所有數據都通過流處理計算，開發(fā)人員只需要維護實時處理模塊，不需要離線實時數據合并，運維簡單，生產統(tǒng)一。缺點：(1) 依賴 Kafka 等消息隊列來保存所有歷史，而 Kafka 難以實現數據的更新和糾錯，發(fā)生故障或者升級時需要重做所有歷史，周期較長；(2) Kappa 依然是針對不可變更數據，無法實時匯集多個可變數據源形成的數據集快照，不適合即席查詢。Kappa 架構實際應用起來有較大的局限性，因此 Kappa 架構在業(yè)內生產落地的案例不多見，且場景比較單一。3、Omega 架構
1）Omega 產生背景
既然 Kappa 架構實際落地困難，Lambda 架構又很難保障數據的一致性，兩個架構又都很難處理可變更數據（如關系數據庫中不停變化的實時數據），那么自然需要一種新的架構滿足企業(yè)實時分析的全部需求，這就是 Omega 全實時架構。Omega 架構由偶數科技于 2021 年初提出，同時滿足實時流處理、實時按需分析和離線分析。2）Omega 實現原理
Omega 架構由流數據處理系統(tǒng)和實時數倉構成。相比 Lambda 和 Kappa，Omega 架構新引入了實時數倉和快照視圖 (Snapshot View) 的概念，快照視圖是歸集了可變更數據源和不可變更數據源后形成的 T+0 實時快照，可以理解為所有數據源在實時數倉中的鏡像和歷史，隨著源庫的變化實時變化。因此，實時查詢可以通過存儲于實時數倉的快照視圖得以實現。實時快照提供的場景可以分為兩大類：一類是多個源庫匯集后的跨庫查詢，比如一個保險用戶的權益視圖；另一類是任意時間粒度的分析查詢，比如最近 5 分鐘的交易量、最近 10 分鐘的信用卡開卡量等等。另外，任意時間點的歷史數據都可以通過 T+0 快照得到（為了節(jié)省存儲，T+0 快照可以拉鏈形式存儲在實時數倉 ODS 中，所以快照視圖可以理解為實時拉鏈），這樣離線查詢可以在實時數倉中完成，離線查詢結果可以包含最新的實時數據，完全不再需要通過 MPP+Hadoop 組合來處理離線跑批及分析查詢。
七、湖倉一體典型案例
1、建設銀行湖倉一體
案例背景：為滿足建設銀行及其客戶的大數據建設需求，建行和偶數科技成立了高性能大數據聯合實驗室，結合金融、政府、互聯網等行業(yè)的業(yè)務特征，合作開發(fā)出基于云原生數據庫技術的湖倉一體方案，滿足 ANCHOR 特性，支持存算分離、分布式事務處理、SQL 兼容性、云化彈性供給、Hadoop 生態(tài)、性能優(yōu)化等關鍵特性，有效助力企業(yè)實現降成本、提性能、全融合的大數據建設目標。案例價值：支持將機構全量數據（結構化/半結構化/非結構化數據）清洗轉換后統(tǒng)一存儲于分布式存儲 HDFS 和對象存儲，支持對數據進行如數據切片、拉鏈處理等預處理，對外部提供近源數據的發(fā)布訂閱功能，解決數據存儲規(guī)模小、數據種類少、時間周期短等問題。支持標準 SQL 語法，能夠將數據整合為一套數據，減少重復存儲，重復加工，通過建立統(tǒng)一數據指標與模型，提供一致的數據供應，提供多樣的數據服務，讓不同類型用戶便捷使用數據。建行通過湖倉一體技術的理論研究與工程實現，不僅能夠使用同一套技術棧、統(tǒng)一存儲進行數據湖及數據倉庫的雙重能力建設，有效解決集群規(guī)模擴展受限、大數據資源利用率低、一致性難保障、集群管理復雜等痛點。2、美國第一資本 (Capital One)
案例背景：據 CNBC 報道，美國是世界上信用卡欺詐最易發(fā)生的國家。對于金融機構來說，信用卡欺詐的威脅是長期存在的。
Capital One 基于長期實踐的方法論 6W (What, Who, When, Where, Why, What-if) 總結出信用卡信息被泄露的各種情況，以及通過數據進行異常檢測和識別欺詐的應對手段。例如遠離實際位置用卡，地理空間檢測被盜卡信息，以及確定欺詐行為的時間邏輯。但由于當下信用卡欺詐的攻擊、響應和策略變化非常迅速，新的挑戰(zhàn)不斷出現。1）欺詐行為更隱秘：檢測欺詐最有效的方法是查看最終用戶的全部行為。只看交易或訂單是不夠的，需要跟蹤交易前后的事件。這最終會產生大量結構化和非結構化數據。2）欺詐行為發(fā)生得更快：當下的欺詐實施和響應更快，利用機器學習系統(tǒng)實時更新可以在幾毫秒內更新欺詐檢測模型并預防攻擊。3）欺詐策略不斷迭代：欺詐策略的調整更加迅速，憑人力難以察覺，而靜態(tài)的規(guī)則引擎系統(tǒng)較難及時更新，需要利用機器學習適應不斷變化的行為。案例價值：Capital One 使用 Databricks 湖倉一體，同時利用機器學習算法，在數據集上訓練機器學習模型（包括信用卡交易數據、持卡人的卡信息和人口統(tǒng)計信息等），先于欺詐者動態(tài)地檢測欺詐交易。利用 Capital One 存儲在 Amazon S3 中的原始數據，用戶可以通過 Databricks 快速無縫集成 S3 及其框架之間的交互，并通過 MLflow 大規(guī)模擴展機器學習模型訓練、驗證和部署。在 AWS 中的自定義集群上訓練和驗證模型，并使用 MLflow API 直接通過 SageMaker 部署。
寫在最后：
通過理清歷史發(fā)展的脈絡，我們理解了湖倉一體的真正內涵，也注意到湖倉分體不但沒有從數據平臺層面消除數據孤島，反而催生了更為復雜的基礎架構。每個新概念的誕生都離不開業(yè)務場景和技術的雙重驅動，在概念落地時，難免會出現一些認知上的偏差和技術上的彎路。作為 2020 年出現的新技術，湖倉一體也才剛剛走過一年多的時間，探索者的不斷嘗試和試錯正推動市場形成共識。本文的初衷是讓更多的人了解湖倉一體、讀懂湖倉一體、實踐湖倉一體，讓更多的企業(yè)理解湖倉一體的價值與本質。隨著企業(yè)數字化轉型進入深水區(qū)，越來越多的企業(yè)視湖倉一體為數字變革的重要契機，希望企業(yè)和用戶能夠從嘈雜的市場環(huán)境中找到真正有利于自己的技術方案。
微信公眾號后臺回復 ANCHOR， 領取報告PDF
標簽：
