現在的湖倉一體像是個偽命題？

從一體機、超融合到雲端計算、HTAP，我們不斷嘗試將多種應用場景融合在一起並試圖透過一種技術來解決一類問題，藉以達到使用簡單高效的目標。現在很熱的湖倉一體(Lakehouse)也一樣，如果能將資料湖和資料倉儲融合在一起就可以同時發揮二者的價值。

資料湖和資料倉儲一直以來都有十分密切的聯絡但同時存在顯著的差異。資料湖更注重原始資訊的保留，將原始資料“原汁原味”地儲存下來是資料湖的首要目標。但原始資料中有很多垃圾資料，原樣保留就意味著垃圾資料都要存進資料湖?沒錯，資料湖就是這樣一個資料垃圾場，不管什麼樣的資料一股腦存進去再說。所以，資料湖面臨的第一個問題是海量(垃圾)資料儲存問題。

得益於現代儲存技術的長足進步，現在海量資料儲存的成本很低(如分散式檔案系統)完全可以滿足資料湖儲存的需要。但資料光存起來還不行，還要使用也就是計算才能發揮價值。資料湖資料五花八門，各種型別的資料處理方式也不一樣。其中最核心也最重要的是結構化資料處理，無論是歷史沉澱還是業務新增，結構化資料處理仍然是重中之重，很多半結構化和非結構化資料計算最後也會轉到結構化資料計算上。不過很遺憾，由於資料湖的儲存(檔案系統)本身沒有計算能力，沒法在資料湖上直接處理資料，想要處理這些資料還需要藉助其他技術(如資料倉儲)，“能存不能算”是目前資料湖面臨的主要問題。

資料倉儲就剛好相反了，資料倉儲基於 SQL 體系往往具備很強的結構化資料計算能力，但原始資料需要經過一系列清洗轉換、深度組織滿足資料庫約束才能入倉，這個過程會伴隨大量原始資訊丟失甚至資料粒度變粗無法獲得更低粒度的資料價值，而且資料倉儲是高度面向主題的，為一個或某幾個主題服務，主題外的資料並非資料倉儲關注的目標，這會導致資料利用範圍相對狹小，無法像資料湖一樣探索全量、未知的資料價值，更無法像資料湖一樣儲存海量原始資料，相對資料湖來說資料倉儲“能算不能存”。

就資料流向來看，資料倉儲的資料可以基於資料湖整理，那麼一個很自然的想法就是將資料湖和資料倉儲的融合在一起，實現“既能存又能算”，也就是所謂的“湖倉一體”。

那麼現在實現的咋樣呢?

簡單粗暴的辦法是在資料湖上開放資料訪問許可權供資料倉儲實時呼叫(所謂的實時是相對以前需要定時將資料湖中資料批次 ETL 到資料倉儲來說的，實際操作中仍然有一定延時)，二者物理上仍分存兩處，透過高速網路進行資料互動，由於具備了一定的“實時”資料湖資料處理能力，因此現在把這種實現(更多是架構上的)稱為湖倉一體。

就這樣?這也能叫湖倉一體?

那你看看，只要你(喊的)不尷尬，尷尬的就是別人(聽的)。

那資料倉儲咋讀資料湖的資料呢?常見的做法是在資料倉儲中建立外部表 /schema 對映 RDB 的表或 schema，或者 hive 的 metastore，這個過程與傳統的關聯式資料庫透過外部表方式訪問外部資料的方式是一樣的，雖然保留了後設資料資訊，但缺點卻十分明顯。這要求資料湖有相應關係模型下的表和 schema 對映，資料仍需要整理才能使用，而且可利用的資料來源種類減少(如無法直接基於 NoSQL、文字、Webservice 做對映)。同時即使資料湖中有其他可供計算的資料來源(如 RDB)資料倉儲在計算(如分組彙總)時通常還會將資料拉到本地才能計算，產生了大量的資料傳輸成本導致效能下降，問題多多。

現在的湖倉一體除了能“實時”資料互動以外，原來批次定時整理資料的通道仍然保留，這樣可以將資料湖資料整理好存入數倉實施本地計算，當然這已經跟湖倉一體沒太大關係了，沒有“一體”之前也是這麼做的。

不管怎樣，無論透過傳統的 ETL 將資料由湖到倉，還是透過外部對映“實時”資料由湖到倉，資料湖和資料倉儲幾乎沒有任何變化(只是提升了由湖到倉的資料傳輸頻率，還要符合很多條件)，物理仍然上分存兩處，湖是湖，倉是倉， 二者根本沒有一體! 不僅資料多樣性和效率問題沒得到根本解決(靈活性不足)，資料湖的“髒亂差”資料也還需要整理入倉才能使用(時效性很差)。透過這種方式實現的“湖倉一體”想要在資料湖上構建實時高效地資料處理能力恐怕是個笑話。

為什麼會出現這種情況?

如果我們稍加思考就會發現，問題出現在資料倉儲上。資料庫體系過於封閉缺乏開放性，資料只有入庫(包括外部資料對映)才能計算。不僅如此，由於資料庫上的約束，資料必須經過深度整理符合規範後才能入庫，而資料湖的原始資料本身就充斥著大量“垃圾”，整理這些資料本身無可厚非，但很難響應資料湖上的實時計算需求。如果資料庫具備足夠的開放性，可以直接計算資料湖上未經整理的資料，甚至可以基於多種不同型別的資料來源混合計算，同時提供高效能機制保證計算效率那湖倉一體就可以很好實現了。不過很遺憾，資料庫沒法完成這個目標。

但開源集算器 SPL 可以。

開放的計算引擎 SPL 助力湖倉一體

開源 SPL 就是這樣一個可應用在資料湖中提供開放計算能力的結構化資料計算引擎。可以針對資料湖的原始資料直接計算，沒有約束，無需“入庫”。同時 SPL 還提供了多樣性資料來源混合計算的能力，無論資料湖使用統一檔案系統構建，還是基於多樣性資料來源(RDB、NoSQL、LocalFile、Webservice)使用 SPL 都可以直接混合計算，快速輸出資料湖價值。此外，SPL 還提供了高效能檔案儲存(數倉的儲存功能)，在 SPL 實施計算的同時，整理資料可以從容不迫地進行，將原始資料整理到 SPL 儲存中可以獲得更高效能。這裡尤其注意的是，使用 SPL 儲存整理後資料仍然存放在檔案系統中，理論上可以與資料湖存放一處，這樣可以實現真正意義的湖倉一體。

在整個結構中，SPL 可以直接基於資料湖統一儲存計算，也可以對接資料湖中的多樣性資料來源，甚至可以直接讀取外部的生產資料來源，這樣不僅實現了資料湖上的實時計算，在某些資料時效性要求高的場景(當資料還沒入湖的時候就要使用)，透過 SPL 還可以對接實時資料來源計算，資料時效性更高。

原來將從資料湖整理到資料倉儲的工作仍可進行，將原始資料 ETL 到 SPL 高效能儲存中可以獲得更高的計算效率，同時採用檔案系統儲存，資料可以分佈在 SPL 伺服器(儲存)上，也可以繼續使用資料湖的統一檔案儲存，即透過 SPL 完全接管原來資料倉儲的工作，這樣在一個體系內就實現了湖倉一體。

下面我們具體來看一下 SPL 的這些能力。

開放且完善的計算能力

多資料來源混合計算

SPL 支援多種資料來源，RDB、NoSQL、JSON/XML、CSV、Webservice 等都可以連線，並進行混合計算。這樣資料湖儲存的各類原始資料就可以直接利用起來，無需整理就可以發揮資料價值，節省“入庫”動作，保證資料使用的靈活與高效性，可以覆蓋更廣泛的業務需求。

有了這個能力以後，資料湖構建之初就能為應用提供資料服務，而不用等原來資料整理、入庫、建模等一系列長鏈路長週期過程完成後才能服務。而且這種方式更加靈活，可以根據業務需要提供實時響應。

檔案計算支援

特別地，SPL 對檔案的很好支援使得檔案也擁有強計算能力，這樣將資料湖資料儲存在檔案系統中也可以獲得與資料庫接近甚至超越的計算能力。SPL 不僅能計算文字，還支援 JSON 等多層資料格式處理，這樣 NoSQL 以及 RESTful 等資料不用轉換就可以直接使用，非常方便。

完善的計算能力

SPL 提供了完善的計算能力，基於離散資料集(而非關係代數)模型可以獲得與 SQL 一樣的完備計算性，同時在 SPL 敏捷語法與過程計算支援下資料處理比 SQL 更簡單。

SPL 豐富的計算類庫

這樣資料湖就完全擁有了資料倉儲的計算能力，實現了湖中有倉的第一步。

直接訪問源資料

再將 SPL 的開放能力延伸一下。如果資料來源與資料湖的資料同步沒完成但還需要使用這部分資料怎麼辦?原來就只能等著了，現在有了 SPL 我們甚至可以直接對接資料來源進行計算，或者與資料湖中已有資料進行混合計算都可以。邏輯上可以把資料來源作為資料湖的一部分使用，這樣可以獲得更高的靈活性。

資料整理後的高效能運算

SPL 除了自身擁有完善的強計算能力，同時還提供了基於檔案的高效能儲存。將原始資料 ETL 後儲存在 SPL 儲存中可以獲得更高的計算效能，同時檔案系統具備使用靈活、易於並行等特性。提供了資料儲存能力後，就完成了湖中有倉的第二步，形成新的開放靈活的資料倉儲形式。

目前 SPL 提供了兩種高效能檔案儲存型別：集檔案和組表。集檔案採用了壓縮技術(佔用空間更小讀取更快)，儲存了資料型別(無需解析資料型別讀取更快)，支援可追加資料的倍增分段機制，利用分段策略很容易實現平行計算，保證計算效能。組表支援列式儲存，在參與計算的列數(欄位)較少時會有巨大優勢。組表上還實現了 minmax 索引，同時支援倍增分段，這樣不僅能享受到列存的優勢，也更容易並行提升計算效能。

SPL 也很容易實施平行計算，發揮多 CPU 的優勢。SPL 有很多計算函式都提供並行機制，如檔案讀取、過濾、排序只要增加一個 @m 選項就可以自動實施平行計算，同時也可以顯示編寫並行程式，透過多執行緒並行提升計算效能。

特別地，SPL 能支援很多 SQL 無法支援的高效能演算法。比如常見的 TopN 運算，在 SPL 中 TopN 被理解為聚合運算，這樣可以將高複雜度的排序轉換成低複雜度的聚合運算，而且很還能擴充套件應用範圍。

這裡的語句中沒有排序字樣，也不會產生大排序的動作，在全集還是分組中計算 TopN 的語法基本一致，而且都會有較高的效能，類似的演算法在 SPL 中還有很多。

透過這些機制，SPL 可以跑出超過傳統資料倉儲數量級的計算效能。在資料湖中全面實現一體化數倉可不是說說而已。

更進一步，使用 SPL 還可以針對整理好的資料和未整理原始資料進行混合計算充分發揮各種型別的資料價值，而不用等所有資料整理好才能計算使用，不僅資料湖的靈活性得以充分擴充套件，還具備實時資料倉儲的功能，這就完成了湖中有倉的第三步，兼顧了靈活性與高效能。

透過以上三步不僅可以改善資料湖的建設路徑(原來需要先匯入、再整理、再使用)，資料整理與資料使用可以同時進行，循序漸進地建設資料湖，還在建設資料湖的過程中就完善了資料倉儲，讓資料湖也擁有強計算能力，實現真正意義的湖倉一體，這才是解鎖 Lakehouse 的正確姿勢。