中間表的由來
中間表是數(shù)據(jù)庫中專門存放中間計算結(jié)果的數(shù)據(jù)表。報表系統(tǒng)中的中間表是普遍存在的。那么，這些中間表是如何出現(xiàn)的？為什么中間表會越來越多？中間表會給項目組帶來什么樣的困擾，如何解決這些困擾？這里我們就嘗試探討一下這個問題。
中間表出現(xiàn)的典型場景主要有三個：
一步算不出來
。數(shù)據(jù)庫中的原始數(shù)據(jù)表要經(jīng)過復(fù)雜計算，才能在報表上展現(xiàn)出來。一個 SQL 很難實現(xiàn)這樣的復(fù)雜計算。要連續(xù)多個 SQL 實現(xiàn)，前面的生成中間表給后邊的 SQL 使用。
實時計算等待時間過長
。因為數(shù)據(jù)量大或者計算復(fù)雜，報表用戶等待時間太長。所以要每天晚上跑批量任務(wù)，把數(shù)據(jù)計算好之后存入中間表。報表用戶基于中間表查詢就會快很多。
多樣性數(shù)據(jù)源參加計算
。來自于文件、NOSQL、Web service 等的外部數(shù)據(jù)，需要與數(shù)據(jù)庫內(nèi)數(shù)據(jù)進(jìn)行混合計算時，傳統(tǒng)辦法只能導(dǎo)入數(shù)據(jù)庫形成中間表。
中間表帶來的問題
在一個運營商的報表系統(tǒng)中，我們發(fā)現(xiàn)了一個讓人吃驚的現(xiàn)象。在 DB2 數(shù)據(jù)倉庫中，有兩萬多個數(shù)據(jù)庫表！經(jīng)過深入了解發(fā)現(xiàn)，真正的原始數(shù)據(jù)表只有幾百張，剩下的大量的數(shù)據(jù)庫表都是為查詢和報表服務(wù)的中間表。
經(jīng)過幾年乃至十幾年的運行，數(shù)據(jù)庫中的中間表越來越多，甚至出現(xiàn)這個項目中上萬個的情況。大量中間表帶來的直接困擾是數(shù)據(jù)庫存儲空間不夠用，面臨頻繁的擴(kuò)容需求。中間表對應(yīng)的存儲過程、觸發(fā)器等等需要占用數(shù)據(jù)庫的計算資源，也會造成數(shù)據(jù)庫的擴(kuò)容壓力。
那么，是不是可以清理掉一些不用的中間表？一般的結(jié)論都是：搞不動。數(shù)據(jù)庫中的中間表是不同程序員制作的，有的是綜合查詢系統(tǒng)使用，有的是報表系統(tǒng)使用。中間表之間還存在交叉引用，有些程序員看到有別人生成的中間表就直接使用了。有時候一些查詢報表已經(jīng)廢棄不用了，但是對應(yīng)的中間表沒人敢刪，因為不知道刪掉之后會影響其他什么查詢或者報表。
很多情況下，項目組只好為了越來越多的中間表去擴(kuò)容數(shù)據(jù)庫。但是數(shù)據(jù)庫的擴(kuò)容成本太昂貴了：不管是換更強(qiáng)的服務(wù)器（縱向擴(kuò)容），還是增加數(shù)據(jù)庫服務(wù)器的節(jié)點（橫向擴(kuò)容），都不便宜。過于頻繁的擴(kuò)容讓項目組非常頭疼。
那么，能不能把中間表導(dǎo)出到文件中，從而減輕數(shù)據(jù)庫的壓力呢？這個辦法初看挺好，但是有個問題始終無法解決。例如：每天晚上把經(jīng)營分析表數(shù)據(jù)生成好之后放到文件中，第二天上班的時候發(fā)現(xiàn)，業(yè)務(wù)人員還要對經(jīng)營分析表按照各種條件過濾，或者按照各種維度分組。因為文件本身是沒有計算能力的，一旦把中間表從數(shù)據(jù)庫中導(dǎo)出成文件就很難進(jìn)一步計算了。不得已，只能把中間表繼續(xù)留在數(shù)據(jù)庫中。
解決問題的辦法
采用潤乾集算器實現(xiàn)文件計算，就可以把中間表從庫中遷移到文件系統(tǒng)中了。采用集算器的前后對比圖如下：
在集算器結(jié)構(gòu)中，數(shù)據(jù)庫的大量中間表都移到了庫外，數(shù)據(jù)庫僅僅存儲少量原始數(shù)據(jù)表，壓力就小了很多。針對這些中間表實現(xiàn)的多個 ETL 存儲過程、觸發(fā)器、復(fù)雜 SQL 也都由集算器來實現(xiàn)，數(shù)據(jù)庫的計算壓力也變小了很多。雖然計算和存儲壓力由應(yīng)用服務(wù)器來承擔(dān)，但是成本還是要比數(shù)據(jù)庫服務(wù)器低很多。項目組不用再每隔一段時間就申請數(shù)據(jù)庫服務(wù)器擴(kuò)容了。
同時，集算器可以讀取多樣性數(shù)據(jù)源，直接參與混合計算。無需再導(dǎo)入數(shù)據(jù)庫，成為中間表。
集算器編程很容易
移到庫外的數(shù)據(jù)文件不能再使用 SQL 計算了，換成集算器會不會增加編寫的難度呢？實際上，集算器編寫簡單計算腳本的時候和 SQL 差不多，復(fù)雜多步驟計算還要比 SQL 容易。例如：
讀取文件
實現(xiàn)過濾
分組匯總
從上述例子來看，采用集算器實現(xiàn)數(shù)據(jù)文件庫外計算，學(xué)習(xí)成本很低，很容易掌握。
新方案的價值
新方案的價值還不僅僅是降低數(shù)據(jù)庫的壓力。
對于報表應(yīng)用而言，中間數(shù)據(jù)的存在是有價值的：有些中間表是報表業(yè)務(wù)決定的，有些是為了彌補現(xiàn)有技術(shù)的不足。也就是說，中間數(shù)據(jù)和報表模板一樣，都是報表系統(tǒng)的一部分。所以，集算器的方案并沒有讓中間數(shù)據(jù)消失，只是移到了庫外，保存在報表應(yīng)用的文件目錄中，使得中間表在物理上也成為了報表應(yīng)用系統(tǒng)的一部分。這樣既能發(fā)揮中間數(shù)據(jù)的價值，還可以讓中間數(shù)據(jù)和報表系統(tǒng)的其他部分一起管理。顯然，文件系統(tǒng)的樹形目錄結(jié)構(gòu)比數(shù)據(jù)庫混在一起的幾萬個表要更容易維護(hù)。
在實際項目中，可以給中間數(shù)據(jù)文件建立多層文件夾存儲。例如：第一層目錄是財務(wù)管理、人力資源、ERP 等等。人力資源又有子目錄：工資管理，基本信息，黨員信息等等。目錄可以細(xì)化到某個報表，如果該報表發(fā)生了變化，只需要調(diào)整這個目錄中的報表模板或者數(shù)據(jù)文件即可。如果該報表廢棄不用，那么刪掉或者移走報表所在目錄，就可以快速的釋放硬盤空間。
從計算速度來說，由于文件更底層，更接近于磁盤，IO 性能要好于數(shù)據(jù)庫。所以集算器的方案可以為報表系統(tǒng)帶來更快的性能。
報表數(shù)據(jù)來自于多樣性數(shù)據(jù)源時，還可以有更好的實時性，不像傳統(tǒng)手段時只能定期入庫。
