最近手上堆積了不少跟數據相關的需求，在跟客戶和同事交流的過程中，發(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è)務和架構服務的。
