都強調實時性,偶數科技實時湖倉一體有啥不同?
面對越來越複雜多變的市場,為了能在激烈競爭中保持優勢,企業需要更及時的資料洞察和快速的反應能力,構建實時基礎設施成為數字化時代的企業必修課,現代技術棧正加速轉向支援實時化。
比如,Uber的實時基礎設施每天產生多個PB級的資料和數萬億條資訊,這些資料持續不斷從Uber司機、乘客和其他使用者那裡收集而來。Uber的移動應用、內部儀表盤、機器學習模型和臨時資料探索工具都有實時用例。而Netflix的實時基礎設施每天基本處理數十萬億次的事件。
伴隨著企業實時需求增多,新的資料技術概念也如雨後春筍般長了出來。比如近兩年火熱的實時數倉,豐富了實時資料處理的應用場景,未來資料棧將會向著怎樣的趨勢發展?
IT168&ITPUB策劃了實時數倉系列選題,與業內專家共同探討新技術、新趨勢、新應用。本文為其中一篇,採訪嘉賓:偶數科技解決方案部總監張立群。
實時分析三大場景
技術的變革往往是因為業務的需求推動,反過來,變革後的技術也將促進業務創新增長。
目前,實時業務場景越來越多,比如運營層面的實時營銷,當日分時業務分析,千人千面的實時推薦頁面,金融領域的實時風控,生產層面的實時系統監控等。而隨著5G等新技術發展,未來海量的實時資料處理需求只會更多。
張立群介紹,其實從技術角度來看,參照去年年底Gartner給出的定義,按照事件發生的時間先後順序,實時資料處理的需求可以分為實時流處理、實時按需分析、離線分析三類。
實時分析處理三大場景
其中,實時流處理,可以理解為連續實時處理,24小時不停採集資料和處理實時流資料。按需實時則是根據使用者不定時提出需求,能夠做到及時響應。“簡單概括來說,實時數倉必須具備實時計算的能力。這裡在數倉中進行的實時計算指的是面向實時流資料和歷史資料相結合的按需實時處理,而非僅進行連續的實時處理。”張立群強調,實際上,當使用者在業務中提出按需的實時資料處理需求時,不僅需要實時資料處理,也需要實時資料與歷史資料結合的實時處理,即需要按需的實時+離線分析,客戶要的不僅是T+0,而是T+X,這裡的X包括從實時到幾秒,幾分鐘,幾個小時,幾天等。
張立群介紹,目前,單純的流計算引擎如Flink、Spark Streaming受限於處理的資料規模,只能做到連續的實時流處理,不具備按需實時處理的能力,按需實時只能在數倉中進行,這就要求實時數倉除了儲存Flink、Spark Streaming實時處理的結果資料,還需要自身具備高效能的按需實時處理能力。
實際上偶數科技的實時數倉並非單獨的數倉產品,而是一體化的雲資料平臺——Skylab,該平臺擁有四大產品元件,包括雲原生資料庫OushuDB、機器學習平臺LittleBoy、資料管理平臺Lava和資料分析與應用平臺Kepler。透過ANCHOR六大特性比較,偶數Skylab具備了 All Data Types( 支援多型別資料)、 Native on Cloud( 雲原生)、 Consistency( 資料一致性)、 High Concurrency( 超高併發)、 One Copy of Data( 一份資料)、 Real-Time( 實時 T+0)。
對外服務時,可以根據使用者需求以新一代全實時資料處理架構Omega組合應用,比如將OushuDB與Lava結合起來就可以構成一個基礎的實時湖倉方案,具有實時數倉能力。其中資料管理平臺Lava會整合Flink、Spark Streaming引擎。
據悉,Omega架構融合了Lambda架構和Kappa架構處理流資料的優勢,增加了實時按需智慧和離線按需智慧資料處理的能力,以及高效處理業務應用系統獲取的可變更資料實時快照的能力。這使得偶數科技的實時數倉方案可以實現按需實時計算與按需離線批處理相結合。
張立群介紹,由於企業的IT系統都是分階段建設,比如某企業先有了數倉,然後建設了大資料平臺,為了實時處理可能又在Hadoop基礎上建設了Flink計算引擎。目前大部分企業的技術棧還沒有形成體系化,依然處於割裂的狀態。不同的系統有各自的計算與儲存,傳統架構下MPP橫向擴充套件能力弱,且計算與儲存不分離,Hadoop橫向擴充套件能力強,但是計算不支援橫向擴充套件,這些不足會成為海量資料爆發下實時分析處理的掣肘。OushuDB採用存算分離架構,並支援虛擬計算叢集技術,具有多租戶能力,由此打造的實時數倉方案可以實現彈性擴充套件,提高資源利用效率。
未來資料技術融合的原則
面對複雜多變的新業務場景,隨著資料技術不斷成熟,新的實時技術棧會出現,資料技術也會經歷分離與融合。目前,融合的趨勢比較明顯。如湖倉一體、實時數倉,將實時處理能力融入資料倉儲中。
那麼湖倉一體與實時數倉有什麼異同?
張立群介紹,原來的資料倉儲計算引擎的優勢與資料湖的分散式儲存優勢結合形成了新一代湖倉一體的資料平臺技術,基於這種技術研發的產品同時具備了湖的分散式可擴充套件儲存能力和資料倉儲的高效能分析處理能力,而在湖倉一體的基礎上,新增流計算處理能力便形成了實時湖倉一體,實時湖倉一體本質上還是湖倉一體,同時具備了實時計算能力,能更好的滿足業務應用對海量資料高效能實時資料分析的需求。
天下大勢分久必合合久必分,張立群認為,資料平臺技術棧的建設應該遵循三條基本原則:
一是,架構層面要保持靈活開放,支援多種技術相容性並存。目前,企業已經部署了多個系統,有自己的一套架構體系,技術融合落地時需要最大化利用企業原有IT資產,保護客戶投資。
二是,有效利用資源,降本增效。原來傳統的技術棧,所有資源參與計算,造成IT資源浪費。比如,雲原生資源池化,可以實現資源隔離與動態管理,便於最大化利用資源。
三是,滿足更高的使用者體驗。從使用者角度來看,在技術條件具備的前提下,比如高效能、高併發、實時性更強,便具備了更強的資訊加工能力,能夠在很短的時間內滿足使用者各種各樣的資料服務需求,提升使用者體驗。
隨著實時分析場景日益增多,實時數倉等具備實時處理能力的產品與解決方案將會得到更廣泛的應用。IT168&ITPUB將會推出更多關於實時數倉建設落地的內容,敬請期待。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/69925873/viewspace-2909448/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 對話偶數科技常雷:如何開啟實時湖倉一體時代?
- 農業銀行湖倉一體實時數倉建設探索實踐
- 重新思考 | 實時數倉、湖倉一體、流批一體,它們都在說什麼
- 直播預約丨《實時湖倉實踐五講》第三講:實時湖倉在袋鼠雲的落地實踐之路
- 直播預約丨《實時湖倉實踐五講》第五講:實時湖倉領域的最/佳實踐解析
- 基於 Paimon 的袋鼠雲實時湖倉入湖實戰剖析AI
- 直播預約丨《實時湖倉實踐五講》第四講:實時湖倉架構與技術選型架構
- 離線實時一體化數倉與湖倉一體—雲原生大資料平臺的持續演進大資料
- 為什麼說湖倉是實時數倉的重要演進方向?
- 直播預約丨《實時湖倉實踐五講》第二講:實時湖倉功能架構設計與落地實戰架構
- 位元組跳動資料湖在實時數倉中的實踐
- 快手實時數倉保障體系研發實踐
- 網易基於 Iceberg 的實時湖倉一體系統構建經驗
- 從離線到實時資料生產,網易湖倉一體設計與實踐
- 滴普科技馮森 FastData DLink 實時湖倉引擎架構設計與落地實踐AST架構
- 滴普科技馮森:FastData DLink實時湖倉引擎架構設計與落地實踐AST架構
- 通用資料湖倉一體架構正當時架構
- 實時數倉混沌演練實踐
- 實時數倉-持續更新
- 實時數倉:Kappa架構APP架構
- Clickhouse實時數倉建設
- 企業如何借實時湖倉贏在“資料制勝”時代?
- 分鐘級實時資料分析的背後——實時湖倉產品解決方案
- Doris和Flink在實時數倉實踐
- 流批一體的近實時數倉的思考與設計
- 如何構建準實時數倉?
- 阿里云云原生實時數倉升級釋出,助力企業快速構建一站式實時數倉阿里
- 實時數倉在滴滴的實踐和落地
- 微信ClickHouse實時數倉的最佳實踐
- 應用實踐——新東方實時數倉實踐
- 亞馬遜雲科技潘超:雲原生無伺服器數倉最佳實踐與實時數倉架構亞馬遜伺服器架構
- 基於 Flink 的實時數倉生產實踐
- 網易數帆實時資料湖 Arctic 的探索和實踐
- 快狗叫車實時數倉演進之路
- B站基於Iceberg的湖倉一體架構實踐架構
- 數倉調優實戰:GUC引數調優
- 上海久耶基於HBase實時數倉探索實踐
- 易點天下基於 StarRocks 構建實時離線一體的數倉方案