跑在檔案系統上的資料倉儲

封閉的傳統資料倉儲

我們知道資料倉儲是晚於資料庫出現的，當 TP 資料庫無法滿足日益增長的資料分析需要時，人們便透過架設單獨的資料庫把 AP 業務獨立出來就形成了資料倉儲(邏輯概念)。後續出現了專門的資料倉儲產品為 AP 業務服務，由於資料倉儲在技術上本身也是個資料庫，因此繼承了資料庫的諸多特性，比如後設資料和資料約束，這使得從 TP 資料庫過渡到 AP 資料倉儲較為平滑。

但是，TP 和 AP 的目標並不一致，有些 TP 業務中有意義的特性在 AP 業務中並無好處，甚至還有很多壞處，比如封閉性。

所謂封閉性，是指要被資料庫計算和處理的資料，必須事先裝入資料庫之內，由資料庫統一管理，資料在資料庫內部還是外部是很明確的。

那麼封閉性會帶來什麼問題呢?

一個典型的現象就是 ETL 經常被做成 ELT 甚至 LET。ETL 中的 E 和 T 這兩步事實上也是某種計算，如果計算能力被封閉到資料庫之內的話，我們就只能先把資料裝入庫中才能計算了，因為無法計算庫外的資料。然而 ETL 過程中的原始資料常常並不在庫內，或者至少不在資料倉儲中，也可能存在於多個資料庫。總之，都需要先做個同庫動作之後才能再計算，費時費力。

當代應用中多樣性的資料來源越來越普遍，經常有來自外部服務的資料。如果為了計算這些資料而先把它們轉入資料庫中，也是非常累贅的。臨時轉入的效率很低(因為資料庫的 IO 成本高)，很可能跟不上訪問需求，而定時批次轉入又很難獲得最新的資料，同樣影響計算結果的實時性。

封閉性的壞處還不止於此。

封閉性還會導致實時資料使用困難。當代應用的資料來源種類很多，每種資料來源都在特定場景下單獨發揮作用，但對於 OLAP 業務經常要統計全域性資料，這就涉及跨多資料來源計算。如果每次都要先把其他資料來源資料匯入再使用很低效，還會導致無法使用實時資料，因為這要求能夠跨資料來源進行實時計算，但當前資料倉儲卻沒有這個能力。

封閉性還有一個表現是對資料有約束，資料符合要求才能進來，這在一定程度能保證資料質量，但從另一面也導致有些不太合規的資料很難進來參與計算，這對於分析某些原始資料並無好處，不利於資料湖的建設。

相關的另一個特徵是整體性，庫內的資料庫邏輯上是的整體，不可拆分。如果資料種類(資料表)太多時，又會造成後設資料資訊臃腫、運維管理困難和耦合性高等問題。實際業務中的資料倉儲中表數量通常也真地都很多，有的會高達幾萬張表。為什麼會出現這種情況?

這些表大部分是為了查詢效率採用空間換時間的辦法後事先加工出來的中間表。這種表一旦產生就很難刪除(表被共用，刪除會影響其他部分)，最後越積越多達到成千上萬。

中間表要消耗資料庫計算資源定時更新資料，中間表越來越多，資源消耗就越來越大，其中很多表不用還刪不掉白白浪費資源。儲存和計算壓力會讓資料倉儲面臨擴容壓力，導致成本升高。

表被多個應用共用就會造成應用間的緊耦合問題，這與中間表越來越多互為因果。耦合性太高會導致應用擴充套件困難，運維也十分不便。

分庫分表也是資料量較大的資料倉儲中十分常見的手段，大量的分表會進一步增加表的數量，分庫則面臨跨庫計算的問題。

我們知道資料庫的結構是線性的，表的數量太多就會導致難以管理，運維複雜。雖然資料庫有模式的輔助，但最多也只能分成兩層，與很多樹狀結構(如檔案系統)的方便程度不可同日而語。

單就“資料倉儲”的名字來看，給人的感覺作用主要是儲存，但其實資料倉儲主要的任務是計算，資料光存起來並沒有意義，只有使用才能發揮價值。資料庫的封閉性，相當於城市有個城牆，資料要進出也必須透過資料庫的城門，過程中還要進行一些檢查。對於 OLTP 業務，為了保證一致性，這些檢查是有必要的，但也會損失資料庫的 IO 效率，而這對於 OLAP 這類以計算為主的業務幾乎沒有意義，只是浪費時間浪費資源而已。現代城市(資料倉儲)並不需要城牆。

在檔案系統上構建資料倉儲

如果我們採用開放的儲存體系來構建資料倉儲，比如直接採用檔案來儲存，上述很多問題都能有效地解決。

檔案使用沒有任何約束，沒有了“城牆”的限制，什麼樣資料都能進來(甚至就沒有“進來”這樣概念)，這樣更能保持“原汁原味”也更符合資料湖的初衷。檔案的使用更加靈活高效，採用樹狀目錄的結構可以分類管理資料表(檔案)，這樣既不會造成應用間的耦合性問題，管理和使用也很方便，表數量再多也不怕。

同時，檔案儲存的成本也很低廉，低成本是大資料建設不可忽略的關鍵因素。

當然，檔案相對資料庫來說改寫能力較弱，但資料倉儲中歷史資料通常不再改變，犧牲代價較小的資料更新(更新意味著重寫)能力可以換來更高的計算效率(採用壓縮編碼、列存)通常是值得的，基於檔案的計算效能會更高，而且檔案系統相對資料庫也具備更高的 IO 效能。

使用檔案的另外一個好處是容易實現存算分離。原來資料庫經常是打穿檔案系統直接訪問硬碟的，要改造成存算分離的機制，使用網路檔案系統以及雲上的物件儲存時，就要從底層重構，這是個複雜的任務，也就會帶來不少實施風險。使用檔案做儲存天然支援存算分離(專業儲存保證資料安全性，專業計算引擎保證效能)，上雲也更容易。

檔案儲存的確好處多多，但卻缺失一個關鍵能力：計算。如前所述，資料存起來是要使用的，檔案儲存什麼都好，但如果沒有計算能力，那對於資料倉儲的目標來講就還是個零。

檔案型資料倉儲 esProc SPL

在 esProc SPL 協助下，可以讓檔案擁有計算能力，從而實現開放靈活高效的檔案型資料倉儲。

esProc 是專門面向結構化資料的計算引擎，與資料庫一樣具備完備的計算能力。與資料庫不同的是，esProc 直接基於檔案計算，支援 CSV、Excel、JSON 等檔案格式，同時還提供了自有的高效能檔案格式。esProc 具備良好的開放性，資料來源種類不僅侷限於檔案，還支援多種資料來源型別(RDB/NoSQL/RESTful)的同時進行跨資料來源混合計算。

檔案計算

將資料儲存在檔案中可以獲得更低廉的成本、靈活的使用和方便的管理，這些前面我們已經說過。而且直接使用檔案(系統)還可以獲得更高的效率，不管是寫入還是讀取都要遠高於資料庫。esProc 直接基於檔案計算就能實現完整的資料倉儲功能(儲存 + 計算)。

不過，直接使用如文字這類開放檔案格式效率仍然不高。esProc 為此設計了專有的二進位制檔案格式，提供了壓縮、列存、有序、並行分段等機制來充分保證計算效能。

在高效能檔案儲存的基礎上，esProc 還設計了諸多高效能演算法(要知道有些演算法需要儲存的配合才能應用)，其中有序遊標、遍歷複用、外來鍵指標、單邊分堆、倍增分段並行等都是 esProc 的獨創發明。

esProc 提供的部分高效能演算法

有了高效能檔案儲存和演算法的保證，esProc 在實際應用中相對傳統資料倉儲經常獲得數量級的效能提升。比如在計算使用者流失率的電商漏斗分析場景中，使用者使用 Snowflake 的 Medium 伺服器(相當於 4*8=32 核)3 分鐘沒有跑出來;而 esProc 在一個 12 核 1.7G 的低端伺服器上僅用不到10 秒就跑出來了。還有國家天文臺的天體聚類任務中 esProc 的效能相較其他實現(某分散式資料庫)快了2000 倍。

跨源計算

esProc 還具備良好的開放性，天然支援跨源計算。

esProc 作為開放計算引擎支援幾十種資料來源，不同資料來源只要 esProc 能訪問到都能參與運算，無非只是訪問效能上的差異(使用 esProc 提供的二進位制檔案格式效率最高)。這些資料來源不僅能單獨訪問，還可以進行混合計算，即跨源計算。原來資料庫實施跨源計算需要先 ETL 帶來的諸多問題使用 esProc 都可以完全解決，不僅具備更強的資料實時資料，還可以充分保留各類資料來源自身的優勢。

有了檔案儲存、高效能和跨源計算的保證以後，esProc 還很容易實現 HTAP。HTAP 需求本質上是由於資料量大分庫後無法進行 T+0 查詢產生的。esProc 支援多樣性資料來源混合計算，天然可以進行 T+0 分析。更多內容：HTAP 資料庫搞不定 HTAP 需求

這種機制下還易於實現真正的湖倉一體。湖倉一體要求能存能算，既能充分保留原始資料又具備強計算能力可以充分發揮資料價值。但使用資料庫實現湖倉一體會面臨只能算不能存(只能 House 不能 Lake)的處境，這是由其封閉性、強約束導致的。檔案儲存天然是湖，不合規不符合約束的資料儲存在湖內，再在上面增加 esProc 提供強計算能力，無論什麼樣的資料都能計算，需要高效能再進行整理，這自然實現了可逐步完善的湖倉一體。更多內容：現在的湖倉一體像是個偽命題

總結

資料倉儲與資料庫的應用目標大不相同，再使用資料庫建設資料倉儲勢必會造成很多不適，像本文提到的封閉性有如一道城牆橫亙在計算體系內外，不僅浪費時間空間，一些新時代的應用需求(如資料實時性、存算分離等)也很難滿足。而基於檔案的資料倉儲具備更強的開放性，沒有了“城牆”的限制使用上更加靈活、高效，同時基於 esProc 的強計算能力，在使用方便的同時還能提供更高效的計算效率，這才是現代資料倉儲該有的樣子。