最近手上堆積了不少跟數據相關的需求,在跟客戶和同事交流的過程中,發(fā)現一個問題,那就是大家對數據的底層處理邏輯好像沒有一個統一的認知。仔細思考一番,覺得還是有必要梳理一下。其實從去年開始,在數據領域有一個新概念悄悄興起,開始在實際項目和產品中落地,各方勢力也紛紛響應。那就是,湖倉一體化。大家可能又要感慨,數據倉庫還沒涼,數據湖也還沒搞明白,這咋就又來了湖倉一體化。對,這就是這個時代IT的典型特征,悲哀+悲催......
一、數據湖與數據倉庫的紛爭
數據湖是近幾年熱度比較高的一個數據域的一個概念,熱度和認知度幾乎超過了前些年的數據倉庫。其實數據湖和數據倉庫不完全一個層面的概念。數據湖和數據倉庫代表了數據架構設計的兩種取向。
1、數據湖
數據湖的根本理念是通過開放底層存儲,給數據入湖帶來最大的靈活性,入湖數據可以是結構化的,也可以是非結構化的,甚至可以是原始的日志型數據。從本質上來講,數據湖不是一個產品,也不應該是一個產品,而是一種架構模式,是由“數據存儲架構+數據處理工具”組成的解決方案。
數據存儲架構,要有足夠的擴展性和可靠性,要滿足企業(yè)能把所有原始數據都“囤”起來,存得下、存得久。比如AWS數據湖服務底層存儲架構用的就是S3。
數據處理工具,又可以分成兩大類,一類是數據移動、管理和治理工具,主要包括采集、編目、訪問控制等等,這類工具其實是數據質量的保障,也保持了數據湖的活性;第二類是數據分析、挖掘和利用工具,這類工具是連接數據和應用場景的重要手段。
由此可見,數據湖不只是一個囤積數據的水坑,而是由數據入湖、數據出湖、數據應用等工具共同組成的一個解決方案。
2、數據倉庫
數據倉庫,更關注數據的使用效率、大規(guī)模下的數據管理和安全合規(guī)這類的企業(yè)級成長性需求。數倉一般采用內置的存儲系統,數據通常會經過事先的schema(當然也可以入倉后進行),然后經過統一的接口進入數倉。數據的抽取和Schema的設計,都有非常強的針對性,便于業(yè)務分析師迅速獲取洞察結果,用與決策支持。
與數據湖不同的是,數倉的通常需要采用進行信息和轉化,強調建模和數據管理。通常來講,數據倉庫里面的數據含金量會高于甚至遠高于數據湖,數據湖給人感覺更像是兜底,不管什么數據好賴都要,兼容并包,講究原汁原味。從產品形態(tài)看,數倉一般是一個獨立的產品和平臺,數據湖則不是,沒有那個產品會直接叫數據湖,一般都是一系列數據工具的集合。
近幾年,數據湖和數據倉庫的應用場景和分界還是很清晰的。數據倉庫擅長的BI、數據洞察離業(yè)務更近、價值更大,而數據湖里的數據,更多的是為了遠景畫餅。
但是隨著數據處理技術的發(fā)展以及AI的廣泛應用,原來為畫餅準備的數據湖里的數據得以重見天日,其價值被重新定義。這就是湖倉一體化。
二、為全域數據賦能,湖倉一體化
在數字化轉型的推動下,數據作為重要的生產要素,其價值被重新定義,數據開始從一種無實際意義的資源變成有價值的資產。對數據價值的深度挖掘成了行業(yè)客戶普遍關注的熱點,所以很多人就行能不能把數據倉庫和數據湖的價值進行疊加,讓數據流動起來,減少重復建設。比如,讓“數倉”在進行數據分析的時候,可以直接訪問數據湖里的數據。再比如,讓數據湖在架構設計上,就“原生”支持數倉能力。
正是這些想法和需求,推動了數倉和數據湖的打通和融合,也就是當下炙手可熱的概念:Lake House,現在也叫智慧湖倉。好玩吧,IT行業(yè)就是善于創(chuàng)造概念。
智慧湖倉架構最重要的一點,是實現“湖里”和“倉里”的數據/元數據能夠無縫打通,并且“自由”流動。湖里的“新鮮”數據可以流到倉里,甚至可以直接被數倉使用,而倉里的“不新鮮”數據,也可以流到湖里,低成本長久保存,供未來的數據挖掘使用。
在湖倉一體化架構下,以下場景得以實現:
可以將數據湖中最近幾個月的“熱數據”抽取到數倉中;
可以輕松將大量冷門歷史數據從數倉轉移至成本更低廉的數據湖內,同時這些移到湖里的數據,仍然可以被數倉查詢使用;
處理數倉內的熱數據與數據湖中的歷史數據,生成豐富的數據集,全程無需執(zhí)行任何數據移動操作;
生成的新數據集可以插入到數倉中的表內,或者直接插入由數據湖托管的外部表中。
在實際業(yè)務場景中,數據的移動不只是存在于數據湖和數據倉庫之間,可以簡單歸納為三種,一種是由外向內的數據入湖,第二種是由內向外的數據出湖,第三鐘是圍繞數據湖數據在數據服務組件之間流動。數據越多,管理和治理起來就約困難,就會形成所謂的“數據重力”現象。湖倉一體化不僅需要把數倉和數據湖集成起來,還要克服數據重力,讓數據在服務之間按需流動。
湖倉一體化也好,智能湖倉也好,并非單一產品,它描述的是一種架構。這套架構,以數據湖為中心,把數據湖作為中央存儲庫,再圍繞數據湖建立專用“數據服務環(huán)”,環(huán)上的服務包括了數倉、機器學習、大數據處理、日志分析,甚至RDS和NOSQL服務等等。
我們真正的目的是,從數據源定義、數據抽取和入湖入倉,到湖倉打通與集成,再到數據出湖、數據處理和數據消費,一氣呵成,各種云上數據服務無縫集成在一起。數據從各種源頭“流入”到智能湖倉存儲中,又按需流出,被處理、被消費。
在“智能湖倉”架構下,企業(yè)可以輕松匯集和保存海量業(yè)務數據,并隨心所欲地調用各種數據服務,用于BI、可視化分析、搜索、建模、特征提取、流處理等等,未來新的數據源、新的分析方法,也可以快速應對。
其實,真的不要被這些概念困擾,無論概念怎么變,我們都應該堅持對需求的正確理解和引導,構建完整的需求管理機制,以需求管理為基礎,以架構規(guī)劃為核心,以業(yè)務發(fā)展為導向,至于技術、產品都是為業(yè)務和架構服務的。