怎樣減少報表后臺的中間表?

許多做數(shù)據(jù)管理，數(shù)據(jù)治理的同學(xué)，經(jīng)常會被數(shù)據(jù)庫（倉庫）中大量繁雜的數(shù)據(jù)表困擾，很多數(shù)據(jù)表并不是存儲必要的基礎(chǔ)數(shù)據(jù)的，而是在計算和查詢中產(chǎn)生的中間表，這些中間表，經(jīng)過長年累月的積累，往往會達(dá)到一個恐怖的數(shù)量級，嚴(yán)重的影響了數(shù)據(jù)庫的管理和性能，而且這些中間表，又不敢隨便刪除，因為有的仍然在用，有的不知道還有沒有用，隨意刪除很有可能就會影響業(yè)務(wù)，這時只能被迫的給數(shù)據(jù)庫擴(kuò)容了 而這些讓人苦惱的中間表，很大一部分就是因為前端的報表業(yè)務(wù)所產(chǎn)生的

報表怎么產(chǎn)生的中間表

數(shù)據(jù)量大

原始數(shù)據(jù)量很大時，報表直接基于原始數(shù)據(jù)計算匯總信息時的性能會很差，用戶體驗惡劣，這時，通常的做法就是先把一些匯總結(jié)果事先計算出來，報表再基于這些中間結(jié)果做呈現(xiàn)，用戶體驗就會好很多，這些中間數(shù)據(jù)就會以中間表的形式存儲

計算復(fù)雜

原始數(shù)據(jù)到最終呈現(xiàn)的數(shù)據(jù)計算過程復(fù)雜時，一個 SQL 算不完，那就得先把中間結(jié)果存一下，然后再繼續(xù)算，這就產(chǎn)生了中間表 或者很多報表都得基于某個復(fù)雜計算的結(jié)果來做，每個報表都各自算一次，很繁瑣，還得頻繁占用數(shù)據(jù)庫資源，那就可以用一個中間表先把結(jié)果存下來，供多個報表來用，這也會產(chǎn)生中間表

庫外數(shù)據(jù)

大數(shù)據(jù)時代，報表的很多數(shù)據(jù)來源都是來自庫外的，比如文本存儲的數(shù)據(jù)，或者其他不太好計算的非關(guān)系數(shù)據(jù)源，常用的做法是把庫外數(shù)據(jù)定時導(dǎo)入到數(shù)據(jù)庫中，然后就能和數(shù)據(jù)庫內(nèi)的數(shù)據(jù)一起運(yùn)算了，這就又產(chǎn)生了中間表，而且，有些多層的 json 或 XML 格式，在關(guān)系數(shù)據(jù)庫中還要建立多個關(guān)聯(lián)的表來存儲，就不是多一個中間表的問題了 這些中間表，都是因為報表而產(chǎn)生的

中間表的危害

從上面中間表產(chǎn)生的原因，我們可以看出，它其實是為了解決數(shù)據(jù)計算本身的難題而誕生的，屬于解決問題的有功之臣，但是當(dāng)它的數(shù)量一旦多起來以后，就把自己也變成了一個難題

容量

大量的中間表，會占用很大數(shù)據(jù)庫容量，甚至有些已經(jīng)不用的中間表還在定時更新數(shù)據(jù)，在不斷的變大，那么多表，我們又不知道哪個有用哪個沒用，不敢亂刪，只能放任其不斷的增多、變大，容量告警時，就只能被迫進(jìn)行數(shù)據(jù)庫的擴(kuò)容，而擴(kuò)容，是需要很大成本的，不管是橫向還是縱向

性能

中間表相關(guān)的運(yùn)算還會占用數(shù)據(jù)庫寶貴的計算資源，影響數(shù)據(jù)庫的性能，每個中間表都涉及計算，重要的不重要的，有用的沒用的，都在搶資源，量大的時候就會影響數(shù)據(jù)庫關(guān)鍵業(yè)務(wù)的計算，帶來嚴(yán)重的性能問題

怎么解決

中間數(shù)據(jù)的思路是沒有大問題，有問題的是把它們存到數(shù)據(jù)庫里這個環(huán)節(jié) 那存到庫外不就可以了嗎？這個想法很好，但之前因為技術(shù)限制，存到庫外后會讓續(xù)的計算變的復(fù)雜，很少有這么做的 中間表是要再計算的，基于中間表查詢的報表還要進(jìn)行數(shù)據(jù)過濾，有的還要再次匯總，還可能涉及關(guān)聯(lián)計算，這些操作在數(shù)據(jù)庫里通過 SQL 完成很簡單，但是文件沒有計算能力，要實施這些計算只能硬編碼，用 JAVA 來做，使用 JAVA 來做集合運(yùn)算又非常麻煩，遠(yuǎn)沒有數(shù)據(jù)庫（SQL）方便，所以很少有人把中間表存在庫外 但現(xiàn)在有新技術(shù)了，集成了 SPL 集算器的潤乾報表，讓這種想法變的可行了 SPL 是一款流行的專業(yè)的數(shù)據(jù)計算處理工具，很多項目開發(fā)商都在用，因為它不僅好用，而且還免費，開源，是常年做項目，總需要做數(shù)據(jù)處理的工程師的好幫手

用文件存儲中間數(shù)據(jù)

集成了 SPL 以后，潤乾報表就有了計算文件數(shù)據(jù)的能力，這樣數(shù)據(jù)庫的大量中間表就可以都移到了庫外了，用普通的 TXT 或者其他方式存儲都可以，也可以用 SPL 獨有的更高性能的二進(jìn)制文件，報表直接可以對接他們來算 比如要查詢 2012 年銷售總額超過 800 萬的地區(qū)及銷售金額
就可以提前匯總數(shù)據(jù)，并把中間結(jié)果用文件存儲的方式存儲，而不需要放到數(shù)據(jù)庫中 然后報表直接針對文件數(shù)據(jù)查詢計算就可以

	A
1	=file(“order_year_area_person.txt”).import@t()	// 讀取文件數(shù)據(jù)（以文本為例）
2	=A1.select(dyear==y_date)	// 根據(jù)年份參數(shù)過濾數(shù)據(jù)
3	=A2.groups(area;count(name):pnum,sum(amount):amount)	// 按照地區(qū)分組匯總?cè)藬?shù)和銷售額
4	=A3.select(amount>8000)	// 選出銷售額大于 8000 的記錄

可以用 SPL 的腳本直接計算，如上圖，也可以用 SQL 來計算，如下圖

	A
1	=connect()	// 連接文件系統(tǒng)
2	=A1.query(“select area,count(name) pnum,sum(amount) amount from order_year_area_person.txt where dyear=? group by area having sum(amount)>8000”.y_date)	// 執(zhí)行標(biāo)準(zhǔn) SQL 查詢文本

SPL 具有完整的計算能力，高效又簡單，文件存儲數(shù)據(jù)不好計算的困擾就這么解決了

而且文件存儲還易于管理，性能更好 文件存儲易于管理 中間結(jié)果存到庫外后，數(shù)據(jù)庫就僅需要存儲少量原始數(shù)據(jù)表就可以，數(shù)據(jù)庫自身的管理壓力就會變小，都轉(zhuǎn)移到了庫外文件上了 而庫外的文件，就是普通的計算機(jī)文件，天然就便于管理，可以通過系統(tǒng)的樹狀目錄進(jìn)行存儲，文件都跟著應(yīng)用走，目錄清晰，使用和管理都很方便，不會出現(xiàn)交叉引用相互耦合的情況，報表棄用或者應(yīng)用下線，相應(yīng)的中間存儲文件就可以刪除，再也沒有想刪不敢刪的苦惱了 文件存儲性能更好 文件系統(tǒng)更靠近底層，更接近磁盤，IO 性能本身就好于數(shù)據(jù)庫 如果用 SPL 的二進(jìn)制存儲方式，效果會更明顯，因為 SPL 的文件格式更緊湊，對于只讀的中間數(shù)據(jù)，使用文件存儲時不需要考慮再改寫，可以更為緊致并采用一定的壓縮手段，而且在訪問時也不必考慮事務(wù)一致性，機(jī)制大為簡化，這樣就能獲得更好的吞吐性能了

多源混算減少不必要的中間表

對于數(shù)據(jù)量大和計算復(fù)雜導(dǎo)致的中間表，可以用文件來解決掉了，而對于多樣性數(shù)據(jù)源帶來的中間表又該怎么辦呢？ 也沒問題，SPL 還支持多樣性數(shù)據(jù)源，可以直接連接各類數(shù)據(jù)源進(jìn)行多源混算，不管你存在哪里，有沒有計算能力等，都不需要再把難算的數(shù)據(jù)導(dǎo)入到關(guān)系庫中了形成中間表了

總結(jié)

對于報表應(yīng)用而言，中間數(shù)據(jù)的存在是有價值的，中間數(shù)據(jù)的思路也是正確的，但它多起來后的弊端也是顯而易見的，潤乾 SPL 方案并沒有讓中間數(shù)據(jù)消失，只是把中間表移到了庫外，然后再利用自己的計算能力來完成計算，這樣既能發(fā)揮中間數(shù)據(jù)的價值，又避免了它存到庫內(nèi)的麻煩，就讓整個中間數(shù)據(jù)的方案更加完善通暢了 一套 1W 的報表工具，既可以解決報表需求，還能優(yōu)化數(shù)據(jù)庫架構(gòu)，也可以算是一件 Unbelievable 的事情了，有需要的同學(xué)，可以去試用驗證一下了

感興趣的小伙伴，請識別右側(cè)二維碼與我們聯(lián)系

微信號｜RUNQIAN_RAQSOFT