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

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

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

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

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

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

所以解決報表的性能問題，就得首先重點看前兩個環(huán)節(jié)，雖然說這倆環(huán)節(jié)嚴(yán)格意義上講其實并不屬于報表的功能范疇，而是數(shù)據(jù)源本身的問題，但是用戶不會去管，也分不清楚是誰的原因?qū)е聢蟊砺模圆还苁菍嵤┓竭€是報表工具本身，得在這兩方面有優(yōu)化的能力才能解決這倆問題

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

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

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

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

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

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

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

我們通過一個簡單小例來看一下 SPL 比 SQL 的算法高效在哪里

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

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

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

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

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

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

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

開源 SPL 提速銀行資金頭寸報表 20+ 倍

開源 SPL 提速銀行 POS 機交易報表 30+ 倍

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

報表內(nèi)計算和呈現(xiàn)

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

先看計算

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

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

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

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

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

（藍(lán)色是潤乾報表單獨運算的時間，橙色是 SPL+ 潤乾報表協(xié)同運算的時間）

再看呈現(xiàn)

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

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

怎樣評測對比報表工具的性能？

大報表

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

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

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

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

總結(jié)

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

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

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

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

微信號｜RUNQIAN_RAQSOFT

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