怎樣提高報(bào)表呈現(xiàn)的性能

報(bào)表的性能很重要，是一個(gè)總被談及的問題，跑的慢的報(bào)表用戶體驗(yàn)惡劣，無法忍受。解決這些慢的性能問題，也成了項(xiàng)目方和工程師頭疼的事情。一出狀況，就得安排技術(shù)好的，能力強(qiáng)的工程師去救火，本來利潤(rùn)就薄，還得不斷的追加人工成本，而且工程師有時(shí)候也無能為力，并不是所有的性能問題都能靠程序員能力解決的

這個(gè)總會(huì)讓人頭疼的問題沒辦法解決嗎？沒有好的方法去提升性能了嗎？

解決這個(gè)問題之前，我們得先理清楚問題的根源，是什么導(dǎo)致了報(bào)表的性能問題，找到根源，我們才能對(duì)癥下藥，才能治本

報(bào)表性能問題出在什么環(huán)節(jié)？

報(bào)表的呈現(xiàn)周期中，大致可以分為下圖的 4 個(gè)環(huán)節(jié)，4 個(gè)環(huán)節(jié)都有可能造成報(bào)表的性能問題，但概率較高的是前兩個(gè)環(huán)節(jié)，數(shù)據(jù)準(zhǔn)備和數(shù)據(jù)傳輸（圖中黃色電池電量圖，代表了出問題的程度）

所以解決報(bào)表的性能問題，就得首先重點(diǎn)看前兩個(gè)環(huán)節(jié)，雖然說這倆環(huán)節(jié)嚴(yán)格意義上講其實(shí)并不屬于報(bào)表的功能范疇，而是數(shù)據(jù)源本身的問題，但是用戶不會(huì)去管，也分不清楚是誰的原因?qū)е聢?bào)表慢的，所以不管是實(shí)施方還是報(bào)表工具本身，得在這兩方面有優(yōu)化的能力才能解決這倆問題

數(shù)據(jù)準(zhǔn)備的問題和優(yōu)化

報(bào)表中展現(xiàn)的數(shù)據(jù)大部分情況下并不是從數(shù)據(jù)來源中直接取就可以，大都需要經(jīng)過計(jì)算處理加工，準(zhǔn)備好以后，才能被報(bào)表工具來使用

這些數(shù)據(jù)準(zhǔn)備，多數(shù)是用 SQL 或存儲(chǔ)過程來做的，一些涉及庫外數(shù)據(jù)來源和計(jì)算的，可能會(huì)用其他的高級(jí)語言去處理

當(dāng)這個(gè)過程出現(xiàn)性能問題時(shí)，首先要做的是去優(yōu)化這些數(shù)據(jù)準(zhǔn)備的代碼，比如優(yōu)化 SQL 或存儲(chǔ)過程，完成同樣運(yùn)算的 SQL 可能有不同的寫法，有可能會(huì)有相當(dāng)大的性能差異（比如把 EXISTS 換成 JOIN 就能快得多）。但仍然有不少時(shí)候，即使 SQL 已經(jīng)做了幾輪優(yōu)化，性能仍然起不來，這時(shí)候通常就要考慮升級(jí)硬件了，擴(kuò)容數(shù)據(jù)庫做集群或者升級(jí)服務(wù)器配置等，不過這又會(huì)帶來額外高昂的成本

還有個(gè)辦法是使用開源的 SPL 來替代 SQL 做數(shù)據(jù)準(zhǔn)備

上面說到的，有時(shí)候經(jīng)過多輪優(yōu)化的 SQL 仍然跑不快，這是因?yàn)?SQL 本身有局限性，缺乏很多數(shù)據(jù)類型和基礎(chǔ)運(yùn)算，很多高性能算法都無法描述，結(jié)果只能使用較慢的算法，用了這么多年，雖然很多數(shù)據(jù)庫和大數(shù)據(jù)平臺(tái)都在工程上對(duì)這些慢的算法有所優(yōu)化，但也只能針對(duì)簡(jiǎn)單的場(chǎng)景，情況復(fù)雜之后數(shù)據(jù)庫的優(yōu)化器依舊會(huì)“暈”掉，并沒有從根本上解決 SQL 局限性的問題

而 SPL 是一種擁有全新高效算法的計(jì)算語言，可以從根本上解決各類 SQL 局限性導(dǎo)致的性能難題

我們通過一個(gè)簡(jiǎn)單小例來看一下 SPL 比 SQL 的算法高效在哪里

比如要在 1 億條數(shù)據(jù)中取出前 10 名，用 SQL 算就會(huì)涉及大排序，大排序就會(huì)影響性能， 其實(shí)我們是可以想出不用大排序的算法的，但 SQL 無法描述，那就只能指望數(shù)據(jù)庫優(yōu)化器了，簡(jiǎn)單情況下，很多商用數(shù)據(jù)庫確實(shí)都能優(yōu)化，使用不必大排序的算法，性能通常也很好，但情況稍微變復(fù)雜一些，比如要在每個(gè)分組中取前 10 名，要用到窗口函數(shù)和子查詢，這時(shí)候優(yōu)化器就又無能為力了，又得乖乖去大排序，慢慢的算了

SPL 則不然，SPL 離散數(shù)據(jù)集中有普遍集合的概念，TopN 這種運(yùn)算被認(rèn)為是和 SUM 和 COUNT 一樣的聚合運(yùn)算，只不過返回值是個(gè)集合，用 SPL 去做個(gè)這個(gè)計(jì)算的時(shí)候就不需要做大排序了

有了這樣更高效的算法，那速度自然就快了，性能自然也就好了

除了新的高效的算法以外，數(shù)據(jù)的存儲(chǔ)對(duì)于性能也非常重要，好算法要有合適的存儲(chǔ)機(jī)制配合才能生效，SPL 也有自己更高效的存儲(chǔ)方式，高性能二進(jìn)制文件存儲(chǔ)，相對(duì)于普通的數(shù)據(jù)庫存儲(chǔ)，SPL 的二進(jìn)制存儲(chǔ)和 SPL 的高效算法配合，性能會(huì)更好，使用 SPL 存儲(chǔ)后，可以把原來需要緩存的計(jì)算過程變成不需要了，原來要遍歷多遍的運(yùn)算變成只遍歷一次甚至不用遍歷了，減少硬盤訪問量也是非常有效的性能提升手段

報(bào)表涉及的數(shù)據(jù)，基本都是歷史數(shù)據(jù)，必要的時(shí)候，把這些數(shù)據(jù)換一種更高效的方式存儲(chǔ)，可行性也是很大的

下面是幾個(gè)用 SPL 來優(yōu)化數(shù)據(jù)準(zhǔn)備的實(shí)際案例，有需要的可以詳細(xì)看一下

開源 SPL 提速保險(xiǎn)公司團(tuán)保明細(xì)單查詢 2000+ 倍

開源 SPL 提速銀行資金頭寸報(bào)表 20+ 倍

開源 SPL 提速銀行 POS 機(jī)交易報(bào)表 30+ 倍

開源 SPL 提速資產(chǎn)負(fù)債表 60 倍

通過這些實(shí)際案例可以看出，使用 SPL 實(shí)現(xiàn)了高效的算法后，在 SQL 無法解決的性能問題中，可能獲得數(shù)倍以至數(shù)十甚至上百倍的性能提升

到這里我們可能會(huì)想，解決個(gè)性能問題還得把原先的 SQL 甚至是存儲(chǔ)方式都舍棄，全部用新的 SPL 重新做, 這也太費(fèi)勁了，代價(jià)太大了吧

是的，小問題是沒這個(gè)必要折騰，但是遇上重病那就只能用猛藥來醫(yī)了，當(dāng)現(xiàn)有的 SQL 已經(jīng)無法再繼續(xù)優(yōu)化，性能問題已經(jīng)沒辦法解決時(shí)，那就只能嘗試用新的辦法來解決了

而且體會(huì)過更高效的算法以后，使用新技術(shù)估計(jì)也不會(huì)再是一種迫不得已的選擇了，而是會(huì)變成更主動(dòng)自愿的擁抱了

另外一些報(bào)表工具已經(jīng)集成了開源的 SPL 了，比如潤(rùn)乾報(bào)表，直接用這樣的工具來做報(bào)表，解決起問題來也更直接方便一些

數(shù)據(jù)傳輸?shù)膯栴}和優(yōu)化

報(bào)表項(xiàng)目大部分都是 JAVA 應(yīng)用，基本都得通過 JDBC 來取數(shù)、做數(shù)據(jù)傳輸，有時(shí)候我們會(huì)發(fā)現(xiàn)，SQL 很簡(jiǎn)單，數(shù)據(jù)庫負(fù)擔(dān)也很輕，但數(shù)據(jù)傳輸?shù)綀?bào)表卻需要很長(zhǎng)時(shí)間，傳輸完成后，報(bào)表也算的很快，那就可以判定，就是有些數(shù)據(jù)庫的 JDBC 取數(shù)太慢，導(dǎo)致了性能問題

這是 DB 本身的問題，怎么優(yōu)化？

我們動(dòng)不了廠商的 JDBC，那就只能曲線救國(guó)，單線程取的慢，如果數(shù)據(jù)庫允許，我們可以嘗試多線程并行取，如果報(bào)表工具有并行取數(shù)的功能，那問題就迎刃而解了，但由于并行取數(shù)涉及的數(shù)據(jù)分段方法和數(shù)據(jù)庫及取數(shù)語法需要較復(fù)雜代碼控制，也不容易做成報(bào)表功能，所以目前的報(bào)表工具基本都不支持并行取數(shù)，那就又得再外圍實(shí)現(xiàn)了

外圍實(shí)現(xiàn)，可以是自己用 java 等高級(jí)語言去寫，但是會(huì)復(fù)雜一些，工作量也不小，也可以用現(xiàn)成的計(jì)算工具去做，比如前面提到的 SPL 就可以輕松支持并行計(jì)算，下圖就是 SPL 并行取數(shù)的代碼，寫起來還是很簡(jiǎn)單的，也容易理解

在數(shù)據(jù)庫負(fù)擔(dān)不重時(shí)，并行取數(shù)幾乎可以讓傳輸效率得到線性的提升

附上一個(gè)并行取數(shù)和單線程取數(shù)的性能測(cè)試對(duì)比，感興趣的同學(xué)可以去看看

JDBC 取數(shù)到底有多慢

同樣的，如果報(bào)表工具中集成了 SPL，那也就可以通過并行取數(shù)來提升性能了

其他環(huán)節(jié)的問題和優(yōu)化

報(bào)表內(nèi)計(jì)算和呈現(xiàn)

前兩個(gè)重點(diǎn)的環(huán)節(jié)看完了，大頭已經(jīng)解決了，不過還是有些報(bào)表的性能問題出在后面的環(huán)節(jié)中，我們來看下，后兩個(gè)環(huán)節(jié)是報(bào)表內(nèi)的計(jì)算和呈現(xiàn)

先看計(jì)算

報(bào)表內(nèi)的計(jì)算，首先要看報(bào)表工具的基本功，另一方面也要看外圍計(jì)算引擎，基本功好，可以保證大部分表內(nèi)計(jì)算都不出問題，有外部計(jì)算引擎，可以保證特殊情況也運(yùn)行無恙

我們以業(yè)界性能口碑比較好的潤(rùn)乾報(bào)表為例，即使它在相同條件下各類報(bào)表，各種計(jì)算的性能都優(yōu)于同類產(chǎn)品，但由于報(bào)表工具本身定位的局限性，再好的工具也不可能任何情況下都跑的快，遇到跑不快的情況，工具本身沒有優(yōu)化空間時(shí)，那就還得借助外部計(jì)算引擎的能力才行

舉個(gè)最簡(jiǎn)單的例子，比如要在報(bào)表里做多源關(guān)聯(lián)，我們需要寫一個(gè)類似這樣的表達(dá)式 ds2.select(ID==ds1.ID)，表達(dá)式很簡(jiǎn)單，但是計(jì)算復(fù)雜度卻是平方級(jí)的，數(shù)據(jù)量不大時(shí)，都沒問題，數(shù)據(jù)量稍大時(shí)，到幾千行，那性能就會(huì)急劇下降了，再好的工具處理這樣的運(yùn)算也會(huì)有問題

但如果把這個(gè)關(guān)聯(lián)放到報(bào)表外來做，利用外部的計(jì)算引擎計(jì)算能力，可以使用低復(fù)雜的 HASH 算法（而在報(bào)表工具中無法對(duì)多個(gè)數(shù)據(jù)源先統(tǒng)一處理，實(shí)現(xiàn)不了這種算法），那性能就會(huì)大幅度的提升了

以下是我們?cè)跀?shù)據(jù)量比較大時(shí)，用潤(rùn)乾報(bào)表單獨(dú)運(yùn)算和 SPL+ 潤(rùn)乾報(bào)表協(xié)同運(yùn)算的性能對(duì)比，可以看出，報(bào)表內(nèi)的計(jì)算性能問題，如果挪到外部計(jì)算引擎解決，效果是非常好的

（藍(lán)色是潤(rùn)乾報(bào)表單獨(dú)運(yùn)算的時(shí)間，橙色是 SPL+ 潤(rùn)乾報(bào)表協(xié)同運(yùn)算的時(shí)間）

再看呈現(xiàn)

這個(gè)就完全看報(bào)表本身的能力了，沒有其他外圍方式可以協(xié)助和利用了，如果呈現(xiàn)環(huán)節(jié)總出問題，那就得考慮換工具了

附上一個(gè)如何考察報(bào)表工具本身計(jì)算和呈現(xiàn)性能的帖子，有需要的可以參考：

怎樣評(píng)測(cè)對(duì)比報(bào)表工具的性能？

大報(bào)表

報(bào)表性能問題們還有一個(gè)場(chǎng)景需要注意，就是大清單式報(bào)表，比如電信行業(yè)，要查看當(dāng)月所有的充值記錄，這樣的報(bào)表，格式簡(jiǎn)單，但是數(shù)據(jù)量極大，有的可達(dá)到千萬級(jí)以上，這類大數(shù)據(jù)量的報(bào)表呈現(xiàn)時(shí)如果等著把這些記錄全部檢索出來再生成報(bào)表，那會(huì)需要很長(zhǎng)時(shí)間，用戶體驗(yàn)自然會(huì)非常惡劣，而且報(bào)表一般采用內(nèi)存運(yùn)算機(jī)制，大多數(shù)情況下內(nèi)存里也裝不下這么多數(shù)據(jù)，所以我們一般都會(huì)使用分頁呈現(xiàn)的方式，盡量快速地呈現(xiàn)出第一頁，之后再通過翻頁來加載后面的

這種分頁呈現(xiàn)的方式通常是利用數(shù)據(jù)庫的分頁機(jī)制來實(shí)現(xiàn)，但數(shù)據(jù)庫分頁不僅有如下這些弊端，而且程序代碼和對(duì)應(yīng)的數(shù)據(jù)庫是強(qiáng)耦合的，萬一換了數(shù)據(jù)源，那還得重新做一遍

更好的方式是，取數(shù)和呈現(xiàn)做成兩個(gè)異步線程，取數(shù)線程發(fā)出 SQL 后就不斷取出數(shù)據(jù)后緩存到本地存儲(chǔ)中，呈現(xiàn)線程根據(jù)頁數(shù)計(jì)算出行數(shù)到本地緩存中去獲取數(shù)據(jù)顯示，如下圖所示

通過這樣的方式，就可以很好的解決大數(shù)據(jù)量清單式報(bào)表的性能難題了具體如何實(shí)現(xiàn)可以參考：大清單報(bào)表該怎么做？

總結(jié)

從前面所述的幾個(gè)優(yōu)化過程中可以看出，大部分性能問題，都是在報(bào)表工具外做的優(yōu)化，數(shù)據(jù)準(zhǔn)備在報(bào)表外，數(shù)據(jù)傳輸在報(bào)表外，表內(nèi)計(jì)算慢時(shí)，大部分也可以挪到報(bào)表外，只有呈現(xiàn)這一個(gè)環(huán)節(jié)是報(bào)表內(nèi)的

所以單憑一個(gè)報(bào)表工具想完全解決報(bào)表的性能問題是不太可能的，要真正徹底的解決性能難題，除了看報(bào)表本身的性能外，更需要重點(diǎn)看工具有沒有外圍的計(jì)算引擎來協(xié)助，報(bào)表本身能力強(qiáng)，又有計(jì)算引擎幫忙（類似內(nèi)置了開源 SPL 的潤(rùn)乾報(bào)表），一套組合拳打下來，報(bào)表性能問題才能真正解決

如果報(bào)表工具本身性能就很普通，還沒有其他計(jì)算引擎輔助，那是誰也不可能把老爺車的發(fā)動(dòng)機(jī)優(yōu)化到 F1 賽車的馬力的

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

微信號(hào)｜RUNQIAN_RAQSOFT

歡迎來【乾學(xué)院】的原文中留言，發(fā)表您的觀點(diǎn)！