2021年底，大數據領域最「吸睛」的事件莫過於Databricks和Snowflake關於TPC-DS測試結果的「恩怨情仇」了。
2021年11月，Databricks發布了《Databricks Sets Official Data Warehousing Performance Record》一文，在體現Databricks數倉高性能的同時，矛頭直指雲數倉「當紅炸子雞」Snowflake，雙方隨即在就TPC-DS測試結果展開爭論，數據湖與數據倉庫在跑分競賽中狹路相逢。
事實上，作為大數據分析賽道的代表性廠商，不論是具備數據倉庫功能的數據湖工具Databricks，還是借鑑數據湖範式的可擴展數據倉庫Snowflakes，其發展路線都說明「湖倉一體化」已成為了目前市場主流的技術發展方向。
從一筆銀行轉帳談起
如果單單提到「湖倉一體化」，對大數據分析技術不那麼了解的讀者來說感受可能並不真切。那麼我們就從最貼近生活的銀行轉帳場景談起。
在用戶通過銀行向某個特點商家完成線上交易轉帳的背後，銀行在數據層面需要經過怎樣的流程呢？
首先，幾乎在用戶轉帳行為的同時，為了更好保障用戶轉帳資金的安全性，銀行需要將本次用戶轉帳的時間、金額、位置等數據進行加工，形成衍生特徵提供給反欺詐應用系統並迅速完成對交易性質的判斷，若轉帳存在欺詐風險則需要及時完成預警與交易阻斷。在這個流程中，就需要銀行對數據進行實時流處理。當大量用戶轉帳行為同時發生時，伴隨著大量數據的同時湧入，如何分配計算和存儲資源以保障流處理的及時性是考驗數據分析體系的關鍵。
在用戶轉帳行為完成的短時間內，交易雙方均可能產生對特定時間段內轉帳信息的查詢需求，如商家會查詢近10分鐘內新增的大額交易的合計金額。在數據處理層面，這就要求銀行能夠立即將本次用戶的轉帳數據反映到實時的報表和統計分析中。而由於實時報表和統計分析的需求千變萬化，需要的數據維度、數據時間範圍各有差異，流處理系統難以滿足，因此需要銀行構建起實時按需分析的能力。
最後，在用戶轉帳行為完成的較長時間內，該筆轉帳的數據將會被銀行通過報表統計、數據挖掘等技術用於銀行業務流水分析、用戶消費行為畫像等場景中，以支持銀行的業務決策，這即是銀行最為傳統的離線分析需求。這種離線分析對數據的實時性要求不高，圍繞銀行特定的決策支持場景展開，對銀行的日常運營具有重要意義。
而面對從實時流處理，到實時按需分析、再到離線分析的複雜需求，單一的靠數據倉庫還是數據湖都難以流暢的實現支持。
大數據分析的三大場景
一方面，數據倉庫作為銀行進行傳統離線分析的數據工具，應用已經相對成熟，但是數據倉庫需要嚴格定義schema，選取哪些數據維度、如何構建分析表單，需要進行審慎的數據建模，這個過長往往涉及對銀行諸多部門的需求分析與驗證，還需要進行跨部門協作，因此數據建模路徑長、時間久，難以滿足實時性的數據分析需求。
另一方面，數據湖是在大數據時代中成長起來的數據工具，在多種數據類型、海量數據的存儲，及數據的取用規則上具有更強的靈活性，因此能夠更好支持對數據的實時分析。但是其在性能、事務、管理運維效率等方面均無法與核心數倉相比。
事實上，隨著移動網際網路、5G等技術的不斷進步，不僅僅是銀行的交易轉帳，在企業營銷、智能製造、智慧交通等多個應用場景下，均同時存在以上三種數據分析需求。結合數據倉庫和數據湖各自的優勢，實現二者融合協作已成為多個行業大數據應用的共識。只有湖倉一體化，才能幫助企業撬動更大的數據潛能，助力企業數智化轉型。
重塑湖倉一體化標準，1+1如何>2
而對湖倉一體化趨勢的統一認知並不必然導向正確的技術實現路徑。
在企業進行湖倉一體化探索時，可能對原有的IT系統和平台產生路徑依賴，從而選擇採用湖倉分體的技術模式，即湖是湖，倉是倉，而這個各自獨立部署，數據通過ETL的方式打通，即業內常常提到的Hadoop+MPP模式。
這種方式儘管在邏輯上可以為用戶提供統一的數據管理能力，但在物理層面數據湖和數據倉庫仍然是分離的，同一份數據可能分別存在於多個存儲集群中，從而不可避免的形成數據孤島。
同時，隨著數據分析和應用場景的複雜化，並發查詢的需求凸顯。而面對動輒數百TB的數據查詢，不論是基於Hadoop構建的數據湖，還是基於MPP資料庫構建的數據倉庫都無法支撐，從而影響整個系統的性能。為了滿足高並發場景需求，企業往往會把數據更細化分割到更多的集群中，從而造成更嚴重的數據孤島效應，不利於企業對數據的統一管理。
而在企業克服湖倉分體模式帶來的種種弊端的過程中，又可能進一步催生ETL邏輯複雜、數據變更困難、數據不一致等一系列實施與運維問題，最終不僅無法最大化湖倉性能，還極大增加了管理運維成本。
那麼，究竟怎樣的湖倉一體化才能更好發揮數據倉庫和數據湖在功能上的互補性，以真正實現對豐富的用戶數據分析場景的支持呢？
面對用戶對數據分析實時性和並發度的要求，以及湖倉分體模式集群規模受限、非結構化數據無法整合、數據一致性弱、性能瓶頸突出等問題，作為國內湖倉一體化領域最早的探索者和實踐者，偶數科技提出了ANCHOR標準，即All Data Types（支持多類型數據）、Native on Cloud（雲原生）、Consistency（數據一致性）、High Concurrency （超高並發）、One Copy of Data（一份數據）、Real-Time（實時 T+0）。
而正是在技術上的不斷突破與創新使偶數科技有底氣提出ANCHOR標準、滿足ANCHOR標準。
偶數科技湖倉一體化解決方案
偶數科技研發的全球最快的雲資料庫OushuDB創新性的採用了存算分離的雲原生架構，突破了傳統MPP和Hadoop的局限，將計算和存儲部署在不同的物理集群中，使得計算和存儲資源可以獨立的彈性伸縮；通過構建虛擬計算集群，OushuDB可以在數十萬節點的超大規模集群上滿足高並發需求，形成了統一的數據體系，不僅使得湖倉更適應雲環境，還降低了用戶的成本；通過支持分布式表存儲Magma，OushuDB的計算引擎便於實現快照視圖，能夠高效實現實時查詢需求，從而在性能和事務方面的支持更加完善。
為了同時滿足實時流處理、實時按需分析和離線分析需求，偶數科技獨創性的探索出了Omega全實時數據處理架構。Omega架構通過流處理系統WASP實現實時連續的流處理或批流一提處理，並通過存儲於實時數倉的快照視圖完成實時查詢，從而解決了傳統Kappa架構落地困難、Lambda架構難以保證數據一致性的問題，並極大簡化了數據架構。
滿足用戶「既要也要」的要求，偶數科技的突破性技術和前瞻性觀點並非空中樓閣，而是以多年的行業實踐和用戶洞察為基礎支點形成的經驗沉澱。偶數科技正在賦能用戶的過程中不斷完成自我疊代，探索最佳實踐。
探索最佳實踐路徑，偶數科技「方法論」落地
銀行業是所有行業中對應用的自主可控、高可用、高可靠性的要求最高的領域之一，偶數科技解決方案在銀行業的落地正是其技術實力和對用戶痛點理解力的明證。
作為企業數位化轉型的先鋒行業，銀行業自80-90年代起就已經開始了信息化探索，在自手工統計到信息化再到數智化的較長技術發展過程中，大多數的銀行形成了較為複雜的技術體系。
在數據分析場景下，銀行早已採用甲骨文、Db2等廠商的OLTP資料庫構建了成熟數據倉庫以滿足對標準化數據的離線分析需求。隨著近年來活動營銷、交易風險監控等實時性數據應用場景的出現，因而又引入了數據湖。
因此在銀行的IT體系中，往往數據倉庫與數據湖並存，二者各自服務於不同應用負載，並未形成「合力」，也因此銀行在數據層面並沒有形成一體化的視角。同時，不同的技術接入必然帶來系統架構的複雜性，從而使得銀行整體的研發成本和運維難度增大。
偶數科技率先洞察到了銀行面對大數據時代的湖倉一體化需求，早在2020年就與建設銀行成立了高性能大數據聯合實驗室，共同探索湖倉一體化的實施路徑。
經過持續的技術探討與應用驗證，二者合作開發的基於雲原生資料庫技術的全實時湖倉一體方案，採用了一套技術棧、統一存儲進行湖倉雙重能力建設，已具備極速性能、彈性伸縮、計算資源按需分配、全量數據單一存儲、無須頻繁導數、混合負載等相關能力，能夠充分建設銀行及其客戶的實時應用場景，幫助建行提升了實時需求響應性能、增強了系統彈性，同時節約運維成本。
除了銀行業以外，截至目前，偶數科技的產品和解決方案已在非銀金融、電信、政府、能源、製造和網際網路等行業中被廣泛的部署和應用。同時，其商業模式的可行性與成長性也得到了資本的認可，連續獲得了國內頂級投資機構紅杉中國、騰訊、紅點中國與金山雲的四輪投資。
2022年，偶數科技正式入選國家級專精特新（專業化、精細化、特色化、新穎化）「小巨人」企業名單。作為助力國家突破關鍵技術領域「卡脖子」難題的創新企業，偶數科技在國產資料庫領域的硬實力和影響力再次得到國家的肯定。
而隨著未來物聯網、工業網際網路的逐步建立，大數據領域將面臨越來越廣的數據來源、越來越大的數據量、越來越多的非結構化數據、越來越豐富的應用場景和越來越複雜的技術棧，大數據處理和分析的難度將進一步提升。偶數科技作為湖倉一體化領域的領導者，也將持續優化技術，為用戶帶來更高性能、更穩健的解決方案，支撐更多行業用戶將數據轉化為生產力。