重新定義湖倉一體化:偶數科技嶄露國產資料庫領導力

語言: CN / TW / HK

湖倉一體化到底應該怎麼“跑出來”?

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架構難以保證資料一致性的問題,並極大簡化了資料架構。

Omega架構邏輯圖

滿足使用者“既要也要”的要求,偶數科技的突破性技術和前瞻性觀點並非空中樓閣,而是以多年的行業實踐和使用者洞察為基礎支點形成的經驗沉澱。偶數科技正在賦能使用者的過程中不斷完成自我迭代,探索最佳實踐。

探索最佳實踐路徑,偶數科技“方法論”落地

銀行業是所有行業中對應用的自主可控、高可用、高可靠性的要求最高的領域之一,偶數科技解決方案在銀行業的落地正是其技術實力和對使用者痛點理解力的明證。

作為企業數字化轉型的先鋒行業,銀行業自80-90年代起就已經開始了資訊化探索,在自手工統計到資訊化再到數智化的較長技術發展過程中,大多數的銀行形成了較為複雜的技術體系。

在資料分析場景下,銀行早已採用甲骨文、Db2等廠商的OLTP資料庫構建了成熟資料倉庫以滿足對標準化資料的離線分析需求。隨著近年來活動營銷、交易風險監控等實時性資料應用場景的出現,因而又引入了資料湖。

因此在銀行的IT體系中,往往資料倉庫與資料湖並存,二者各自服務於不同應用負載,並未形成“合力”,也因此銀行在資料層面並沒有形成一體化的視角。同時,不同的技術接入必然帶來系統架構的複雜性,從而使得銀行整體的研發成本和運維難度增大。

偶數科技率先洞察到了銀行面對大資料時代的湖倉一體化需求,早在2020年就與建設銀行成立了高效能大資料聯合實驗室,共同探索湖倉一體化的實施路徑。

經過持續的技術探討與應用驗證,二者合作開發的基於雲原生資料庫技術的全實時湖倉一體方案,採用了一套技術棧、統一儲存進行湖倉雙重能力建設,已具備極速效能、彈性伸縮、計算資源按需分配、全量資料單一儲存、無須頻繁導數、混合負載等相關能力,能夠充分建設銀行及其客戶的實時應用場景,幫助建行提升了實時需求響應效能、增強了系統彈性,同時節約運維成本。

除了銀行業以外,截至目前,偶數科技的產品和解決方案已在非銀金融、電信、政府、能源、製造和網際網路等行業中被廣泛的部署和應用。同時,其商業模式的可行性與成長性也得到了資本的認可,連續獲得了國內頂級投資機構紅杉中國、騰訊、紅點中國與金山雲的四輪投資。

2022年,偶數科技正式入選國家級專精特新(專業化、精細化、特色化、新穎化)“小巨人”企業名單。作為助力國家突破關鍵技術領域“卡脖子”難題的創新企業,偶數科技在國產資料庫領域的硬實力和影響力再次得到國家的肯定。

而隨著未來物聯網、工業網際網路的逐步建立,大資料領域將面臨越來越廣的資料來源、越來越大的資料量、越來越多的非結構化資料、越來越豐富的應用場景和越來越複雜的技術棧,大資料處理和分析的難度將進一步提升。偶數科技作為湖倉一體化領域的領導者,也將持續優化技術,為使用者帶來更高效能、更穩健的解決方案,支撐更多行業使用者將資料轉化為生產力。