報表工具是一個歷史比較悠久的軟件類產品了，已經有 20 年以上的發展歷史了，在這 20 多年中，產品在不斷的更新迭代，不斷的隨著需求的改變而進步完善，持續發揮著自己的價值在這無數次的更新迭代中，又有兩次比較大的變革，極具重要意義，可以算作是工具發展史上的兩大里程碑式的革命，對軟件的發展走向起到了決定性的作用。

先回顧第一次革命

第一次革命發生在報表工具誕生的初期，當時基礎類，工具類軟件，基本都是國外軟件的天下，報表工具似乎也不例外，外國人帶著他們的報表工具進入中國，也想像數據庫一樣，占領和收割國內的龐大軟件市場，但是這一次他們折戟了，國外的報表工具不僅沒有成功，反而是被國產的工具打的落花流水，甚至連開源免費的也被打趴下了為什么一向厲害的國外軟件在報表領域卻沒有打敗國產的呢？剛進入國內的國外報表軟件，其實在前期也打開了一定的市場，形成了一定的規模，知名度也挺高，比如水晶報表，但是很快就漏出疲態，由于產品處于初期階段，而且歐美人的表格可能也比較簡單，這些國外報表工具，使用上很不方便，只能做簡單的表格可以看看下面這倆，看著就有點蒙圈，不知道該怎么弄了，完全和我們平時看到的表格不一樣，增加學習成本不說，即使學會了也不用，做不了復雜的表格這時候，報表工具的第一次革命就來了面對這些國外工具解決不了的難題，國內報表工具的代表廠商，潤乾報表，在研究了無數復雜表樣后，開發出了全新一代的類 EXCEL 的工具，創造出了獨一無二的非線性報表模型，不僅學習簡單，操作方便，而且可以輕松做出各類中國式復雜報表這次革新，不僅讓國產軟件打敗了國外軟件，而且國產廠商也重新定義了報表軟件的標準，此后的工具，就全都是好用的 EXCEL 方式的操作，和模仿非線性報表的復雜報表模型了

再來說第二次革命

一次革命后，復雜報表的制表方面的難題就基本都解決了但隨著行業的發展，我們又慢慢發現，雖然報表工具已經很牛，什么復雜表格都能做，但有些時候，報表開發還是很讓人頭疼，因為給報表準備數據有時候是一件更困難的事情做過實際項目開發的工程師都知道，應用中的報表，有 80% 的數據來源和計算都比較簡單，很多一個簡單的 SQL 語句就搞定了，但還有 20% 的情況中，數據準備工作就沒有那么好做了，一些過程式的多步驟復雜計算，常常要寫很長的多層嵌套的 SQL 或者存儲過程才能搞定，如果數據來源再復雜一些，要對各類數據源混算，一些非關系數據庫或者文本數據源都不支持 SQL 了，那還得用 JAVA 等語言來寫，SQL 10 幾行能寫完的，JAVA 恨不得寫出幾百行來，編碼難度和效率就更糟糕了然而恰恰是這僅占 20% 的需要硬編碼來做復雜數據準備的工作，卻占了我們 80% 的工作量而且，隨著系統不斷的開發使用，這些存儲過程，中間表，JAVA 程序，也都會慢慢的累積起來，越來越多，導致應用高度耦合，維護困難另外，隨著大數據時代的到來，報表的性能問題也變的格外突出，單純通過報表工具的運算能力來解決性能問題已經有點捉襟見肘怎么解決這些新的難題呢，這就喚起了報表工具的二次革命雖然數據準備、優化應用這些事已經不完全算是報表工具能力應該覆蓋的范疇，工程師們也都非常理解，但只要是和報表相關的難題，作為一個報表廠商，急用戶之所急，我們就得想辦法去去克服這個難題第二次革命，是提升數據準備能力，優化應用結構和提升性能的革命集算器，SPL，就是潤乾發起二次革命，解決上面這些新問題的利器，而且是開源免費的，不僅在國內有很多開發商在用，國外也有龐大的用戶基礎，不僅潤乾報表可以用，也可以配合其他報表工具來用

集算器 SPL

SPL 是一個中間計算層，類似于數據中臺，它可以輕松解決項目中的數據準備開發難題，可以優化應用結構，提升運算性能下面我們就來具體看下 SPL 是怎么解決這三個方面的難題的

降低報表數據準備開發難度

比 JAVA 和 SQL 更易寫 當前復雜報表的數據準備工作一般是采用 JAVA 或 SQL 完成的，存儲過程以及中間表也可以看作是 SQL。SPLSPL 的語法比 JAVA 和 SQL 更為簡單易懂，采用 SPL 能在很大程度上簡化這些開發量JAVA 等語言沒有提供批量數據計算的類庫，寫個簡單的 SUM 也要好幾行，更何況分組、連接等運算，而對于過濾、匯總用到的通用表達式計算，基本上是大多數應用程序員無法完成的任務了SPL 則提供了大量與結構化計算相關的基礎對象和方法，分組匯總這些只要一句，而且是解析執行的動態語言，可以進行隨意的表達式計算。使用 SPL 完成報表數據準備工作要比 JAVA 容易得多，代碼也要短小很多，這一點很好理解，就不具體舉例了代碼短小不僅是寫得更快，而且還能容易理解算法和排錯，絕大多數報表的數據準備算法可以在一個屏幕內顯示出來，可以更直觀地理解代碼的整體含義。而使用 JAVA 時，一個完整的業務邏輯常常需要幾百行代碼，翻看到后面時已經忘了前面的了有經驗的程序員都知道，SQL 用來實現很零碎的多步運算很不方便，特別是與次序相關的運算，程序員常常要把數據從數據庫中取出來用 JAVA 等完成。而 SPL 則正好在這方面做了強化，在分步計算、集合化、有序計算和對象引用等幾方面做了完善，對于常用的日期和字串等運算，也比大部分 SQL 提供了更豐富的方法舉個例子，我們要算某支股票最長連續漲了多少交易日SQL 的寫法 select?max(continuousDays)-1?from?(select?count(*)?continuousDays?from?(select?sum(changeSign)?over(order?by?tradeDate)?unRiseDays?from?(select?tradeDate,?case?when?closePrice>lag(closePrice)?over(order?by?tradeDate)?then??else?1?end?changeSign?from?stock)?) group by unRiseDays)

SPL 的寫法

	A
1	=stock.sort(tradeDate)
2	=0
3	=A1.max(A2=if(closePrice>closePrice[-1],A2+1,0))

許多情況用 SQL 也不是寫不出來，但不能直接按自然思維實現，很費腦筋，這種代碼放時間長了程序員自己都會忘了是怎么寫出來的，給將來的維護也造成麻煩。SPL 代碼則符合自然思維習慣，即使是與 SQL 相同的思路也能更清晰地表達，更容易理解和維護

SPL 簡化 SQL 編碼的例子很多，有興趣可以去參考: 4 SPL 方案與案例（http://c.raqsoft.com.cn/article/1647044867607）

不過，需要說明的是，SPL 雖然在大多數情況下的語法要比 SQL 更簡單易寫，但并不能完全取代 SQL。數據從數據庫讀出的 IO 成本相當高，有些涉及數據量太大的簡單運算，數據讀出的耗時遠遠超過運算本身，這種情況還是放在數據庫中運算更合適比報表中計算更廣泛 報表工具都可以完成計算列、分組排序等運算，潤乾報表還提供了跨行組運算和相對格與集合的引用方案，可以完成更復雜一些的運算報表工具中的運算是一種狀態式的計算，也就是把所有計算表達式寫在報表布局上，由報表工具根據依賴關系決定計算次序。這種方法好處是很直觀，在依賴關系不太復雜時能一目了然地了解各單元格的運算目標但是，在依賴關系較為復雜，數據準備計算需要分成多步時，狀態式計算就困難了，要實施過程式計算，經常需要借用隱藏格，隱藏格不僅將破壞狀態式運算的直觀性，由于狀態式計算一般需要全內存處理依賴關系，還會占用更多不必要的內存。而且還有許多運算即使用隱藏格也難以完成比如統計各地區前五的銷售業績，第六名以后全部歸并為其他如果不借助數據準備環節，就要在報表中使用隱藏行列手段將不該列出來的條目隱藏，而不能直接過濾掉單純報表工具實現：SPL 做好數據準備后 + 報表工具實現再比如帶明細的分組報表要按匯總值排序，需要先分組后排序，許多報表工具無法控制這個次序，報表就無法完成了還有個典型例子是舍位平衡，明細值四舍五入后再合計，可能會與合計值的四舍五入值不相等，會造成了報表上明細與合計數值不一致，這時需要根據合計的舍入值倒推明細的舍入值，這不是報表工具能搞定的事了這幾個運算的邏輯都很簡單，但在報表工具中卻很難實現，單句的 SQL 也很難寫，而為了這種簡單且無復用價值的運算寫一段 JAVA 程序或存儲過程顯得很無聊，況且也不是很輕松。但是，如果采用 SPL 就會容易得多，在數據準備階段完成計算，報表只負責呈現少量的直觀計算，能有效地保持狀態式計算的優勢。過程多了一步，但結構更為清晰SPL 還能輕松實現動態數據源和數據集報表工具使用的數據源一般事先配置好了，不能根據參數動態選擇，而使用 SPL 數據源時則可以用腳本控制連接不同的數據源另外 SPL 還能協助處理格式比如許多報表工具都支持縱向分欄，但很少有報表工具支持橫向分欄。而用 SPL 可以將原數據集變換成橫向拼接過的數據集，報表工作只要用普通的模板呈現列數更多的數據集即可一致的多樣性數據源支持 現代報表的數據源并不只是數據庫，還可能是文本文件或 json、XML 等。這些非數據庫數據源沒有再計算能力，但出報表時總還是需要再進行一些過濾分組甚至多表連接等運算，報表工具本身的計算能力不足，一般都不能很好地處理 json 和 XML 數據，即使針對能進行簡單處理的結構化文本，由報表工具運算也也會造成容量負擔過重的問題。因此，我們經常會有一個過程把這些非數據庫數據導入到數據庫再去生成報表，增加開發工作量如果采用 SPL 準備數據，則可以直接用這些非數據庫數據作為數據源去生成報表，不需要導入數據庫的過程，減少開發工作量比如：json 文件存儲了客戶名單及其銷售額，要找出銷售額累計占到一半的前 n 個大客戶，并按銷售額從大到小排序

	A	B
1	=json(file("d:\\sales.json").read()).sort(amount:-1)	取數并逆序排序
2	=A1.cumulate(amount)	計算累計序列
3	=A2.m(-1)/2	最后的累計值即是總和
4	=A2.pselect(~>=A3)	超過一半的位置
5	=A1(to(A4))	按位置取值

更多例子可以參考：報表工具怎樣使用 Json/XML 的數據（http://c.raqsoft.com.cn/article/1640858385206）

而且一般報表工具使用的數據集都是類似 SQL 返回的那種單層二維表，碰到象 json 或 XML 這類多層數據只能先轉換成多個單層數據集，再在報表模板中關聯運算拼接成多層報表。而 SPL 可以直接支持多層數據集計算，不需要做這個轉換，減少工作量，潤乾報表也可以接受 SPL 返回的多層數據集直接按層次呈現，不需要在報表中再做關聯類似地，MongoDB 也支持多層數據，也可以用 SPL 直接計算并返回給潤乾報表另外數據庫還包括 NoSQL 數據庫、文件包括 HDFS 文件，對于 SPL 來講都是數據源。SPL 自有的計算能力可以使這些計算能力不一的多樣性數據獲得通用一致的計算能力。比如文件幾乎沒有計算能力，MongoDB 對 JOIN 和 GROUP 運算支持不足，各家數據庫對窗口函數的支持程度不同、日期與字串處理能力也普遍不足且風格迥異。采用 SPL 后可以用相對一致的方案來計算，而這將意味著更低的移植成本以及學習難度而且用 SPL 輔助計算后還可以保留非關系數據庫原有的優勢。比如 MongoDB 的對追加型日志數據的吞吐能力就遠遠超過普通關系數據庫，但結構化計算能力較弱，用 SPL 來彌補后，數據可以繼續留在 MongoDB 中，即獲得其高吞吐性能也有了結構化計算能力。

優化報表應用結構

集算器 SPL 的設計初衷是提升數據準備過程的開發效率，但實際應用下來我們發現，SPL 不僅提升了數據準備的效率，同時還優化了應用的結構，這個能力，也非常有意義解釋執行降低應用耦合度 我們知道，JAVA 應用大多數情況是事先編譯并靜態加載的，也就是要把所有模塊一起編譯打包后部署，在運行過程中代碼就不再改變了。其實 JAVA 也有動態編譯和加載的技術，但難度和復雜度都高很多，一般應用程序員很少使用。而且即使采用了動態加載技術，也不能替換已經加載進內存的類，只能不斷新增新的類這種機制下，用 JAVA 編寫的報表數據準備算法就需要和主應用程序一起打包發布，這會導致報表模塊與主應用之間的高耦合性一般來講，報表的業務穩定性要比主應用差得多，報表變動的頻率遠遠高于主應用，一旦報表的數據來源發生變化，整個應用就得跟著重新編譯，無法做到熱切換，這種使用體驗是很糟糕的如果用 SPL 來實現數據準備算法，就能有效地降低主應用程序與報表功能的耦合度了SPL 寫出來的腳本也是類似報表模板的外置文件，不需要和主應用程序一起編譯打包，而且它是解釋執行的動態語言，在修改時不會涉及主應用程序，只要把 SPL 腳本替換就可以，天然就支持熱切換算法外置減少存儲過程 在體系結構方面用存儲過程準備報表數據和用 JAVA 程序是類似的，也會造成耦合度高的問題，只是從報表模塊與主程序之間的耦合變成的報表模塊與數據庫之間的耦合存儲過程存放在數據庫中，報表模板放在文件系統中，保持兩者同步修改依然很麻煩，而且存儲過程修改時需要申請一定級別的管理員權限做重編譯，雖然不象 JAVA 那樣難以做到熱切換，但數據庫高權限的頻繁使用又會帶來安全隱患比 JAVA 更糟糕的是，數據庫及其中的存儲過程可能被多個應用共享，如果管理不善，很容易造成多個應用之間的高耦合，時間長了會搞不清楚某個存儲過程在被哪些應用調用，越來越混亂同樣地，采用 SPL 也可以極大程度地減少數據庫中的存儲過程，算法外置后與報表模板一起存放管理，完全歸屬于報表模塊，不僅降低與應用其它部分的耦合，更不會造成與其它應用的耦合實際上，存儲過程本身編寫難度并不小，遍歷式計算代碼的性能也不佳，而且可移植性很差，原則上在報表業務中應當盡量少用存儲過程數據外置減少中間表 數據量巨大或計算過程太復雜時，我們經常會事先對原始數據做些處理后形成中間結果，再基于這些中間結果開發報表。這些中間結果一般是以數據庫表的形式存在的，也就是這里所謂的中間表一個運行時間較長的系統中，中間表的數量往往會遠遠大于原始表。某些移動公司的數據庫中有上萬個表，即使很復雜的業務用五百個表也基本能描述了，這些上萬的表中絕大多數都是為報表服務的中間表，這肯定是數據庫廠商都沒想到過的情況與存儲過程類似，大量的中間表也會造成數據庫管理的混亂數據庫中的表是以線狀方式存儲的，相當于沒有分類，而數據庫被各個應用共享，中間表都混到一起，很難搞清楚。這需要項目組有很強的管理控制能力才能理清，比如規定中間表的命名規則并保證得到執行，但強化管理常常是以犧牲開發效率為代價的，項目時間一緊張就顧不得這些規矩了管理能力不夠好其實是常態，這就會導致中間表越來越多，積累到上萬可能是有點極端，但總歸不是個小數目。這些中間表可能有相當多已經沒有用了，但因為不清楚有哪些應用還在使用而只能先留著，相應的 ETL 過程也仍然要無意義地浪費計算資源繼續更新數據那么為什么要把這些中間結果存到數據庫中，而不能存放到文件系統中呢？這是因為我們不可能為每個報表的每種參數組合事先計算中間結果，在生成報表時還需要根據參數進行計算，也就是要求這些中間結果仍有計算能力，而目前只有數據庫有這種計算能力，文件是沒有計算能力的，于是中間數據就只能變成中間表中間數據一般都是由不再改變的歷史數據計算出來的，完全不需要數據庫的事務一致性能力，因為都是導出的冗余數據，也不需要很高的穩定要求，數據壞了重算一次就行了，存放在數據庫中僅僅為了獲得計算能力，實在是劃不來的有了 SPL 后，就可以將中間數據外置到文件系統中，由 SPL 提供針對文件的計算能力，可以有效地減少中間表，不必再讓這些冗余數據繼續占用昂貴并且低效的數據庫空間外置的中間數據文件還可以使用文件系統的樹形結構管理，與報表模板及數據準備算法統一存儲。這不僅管理簡單方便，而且，由于不考慮寫入和一致性的需求，文件還會比數據庫有更好的 IO 吞吐性能，整體提高報表的運算速度混合運算實現 T+0 報表 關系數據庫的事務一致性能力目前尚沒有有效的替代者，交易系統仍然有必要使用關系數據庫來建設這種情況下，要實現 T+0 全數據量的實時報表，我們就得把歷史數據繼續存放在當期的交易數據庫中一起計算，歷史數據常常要龐大得多，這會要求我們建設更大容量的數據庫，成本當然會很高。而且即使愿意支付成本，這個數據量也不可能一直增長，太大了會影響到交易業務的性能，這就不可容忍了通常的辦法是把部分歷史數據被移出來做個分數據庫，這樣可以保證交易系統的正常運轉，但要實現 T+0 報表就麻煩得多，會涉及到跨庫運算許多數據庫都支持跨庫運算，但一般都要求同類型的數據庫，但歷史數據和當期交易數據的要求不同，數據量更大但不要求事務一致性，很可能使用另一種數據倉庫來存儲而且，即使是同構的數據庫，數據庫的跨庫運算的方法一般也是將另一個庫中的數據表映射成本庫數據表，實際運算還是一個數據庫在做，而且還多出許多數據傳遞的通訊成本，性能和穩定性都不好使用 SPL 就可以很好地完成這個混合計算任務了SPL 自己有計算引擎，不依賴于數據庫，各個數據庫內的數據計算仍由各庫進行。SPL 可以使用多線程向各數據庫同時發出 SQL 語句，由這些數據庫并行執行，將各自的運算結果返回到 SPL 再匯總處理后傳給報表工具去呈現顯然，這種機制還方便橫向擴展，歷史庫可以有多個，是否同類型的也無所謂而且，SPL 還有服務器方式的集群運行模式，在集算服務器的支持下，歷史數據不必一定存放到數據庫中，還可以存儲在 IO 性能更好的文件系統中，配合集群計算，可以在更低的成本下獲得更好的性能具體 T+0 實例可以參考：開源 SPL 輕松應對 T+0 （http://c.raqsoft.com.cn/article/1649513370929）

提升報表運算性能

報表的呈現周期中，大致可以分為下圖的 4 個環節，4 個環節都有可能造成報表的性能問題，但概率較高的是前兩個環節，數據準備和數據傳輸（圖中黃色電池電量圖，代表了出問題的程度）而恰恰這兩個環節又都是報表工具無能為力的地方提升數據準備的性能 前面我們已經說到，在數據準備方面，很多場景下 SPL 比大段的 SQL，存儲過程以及 JAVA 要寫起來更容易，降低了數據準備的開發難度事實上，SPL 不僅可以降低開發難度，還可以提升數據準備的效率和性能我們通過一個簡單小例來看一下 SPL 比 SQL 的算法高效在哪里比如要在 1 億條數據中取出前 10 名，用 SQL 算就會涉及大排序，大排序就會影響性能， 其實我們是可以想出不用大排序的算法的，但 SQL 無法描述，那就只能指望數據庫優化器了，簡單情況下，很多商用數據庫確實都能優化，使用不必大排序的算法，性能通常也很好，但情況稍微變復雜一些，比如要在每個分組中取前 10 名，要用到窗口函數和子查詢，這時候優化器就又無能為力了，又得乖乖去大排序，慢慢的算了SPL 則不然，SPL 離散數據集中有普遍集合的概念，TopN 這種運算被認為是和 SUM 和 COUNT 一樣的聚合運算，只不過返回值是個集合，用 SPL 去做個這個計算的時候就不需要做大排序了這只是一個簡單的例子，其他的 SPL 比 SQL 性能好的高級函數還有很多除了新的高效的算法以外，數據的存儲對于性能也非常重要，好算法要有合適的存儲機制配合才能生效，SPL 也有自己更高效的存儲方式，高性能二進制文件存儲，相對于普通的數據庫存儲，SPL 的二進制存儲和 SPL 的高效算法配合，性能會更好，使用 SPL 存儲后，可以把原來需要緩存的計算過程變成不需要了，原來要遍歷多遍的運算變成只遍歷一次甚至不用遍歷了，減少硬盤訪問量也是非常有效的性能提升手段報表涉及的數據，基本都是歷史數據，必要的時候，把這些數據換一種更高效的方式存儲，可行性也是很大的下面是幾個用 SPL 來優化數據準備的實際案例，有需要的可以詳細看一下

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

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

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

開源 SPL 提速資產負債表 60 倍提升數據傳輸的性能 報表項目大部分都是 JAVA 應用，基本都得通過 JDBC 來取數、做數據傳輸，有時候我們會發現，SQL 很簡單，數據庫負擔也很輕，但數據傳輸到報表卻需要很長時間，傳輸完成后，報表也算的很快，那就可以判定，就是有些數據庫的 JDBC 取數太慢，導致了性能問題我們動不了廠商的 JDBC，那就只能曲線救國，單線程取的慢，如果數據庫允許，我們可以嘗試多線程并行取，但由于并行取數涉及的數據分段方法和數據庫及取數語法需要較復雜代碼控制，也不容易做成報表功能，所以目前的報表工具基本都不支持并行取數但在 SPL 中，這卻是一個非常普通的功能，下面就是一段 SPL 并行取數的代碼，寫起來還是很簡單的，也容易理解

	A	B
1	=now()	//記錄開始時間
2	=connect("oracle").query@1x("SELECT COUNT(*) FROM CUSTOMER")
3	>n=12	//設置并行數，根據電腦的物理CPU核數決定
4	=n.(range(1,A2+1,~:n))	//按總記錄數和并行數分段，記錄本段開頭和下段開頭數字
5	fork A4	=connect("oracle")
6		=B5.query@x("SELECT * FROM CUSTOMER WHERE C_CUSTKEY>=? AND C_CUSTKEY<?",A5(1),A5(2))
7	=A5.conj()	//合并取數結果
8	=interval@s(A1,now())	//計算運行時間

在數據庫負擔不重時，并行取數幾乎可以讓傳輸效率得到線性的提升

SPL 不僅可以優化前兩個環節，對報表工具本身的計算能力也可以起到輔助提升的作用輔助報表計算提升性能 報表內的計算，主要得依靠報表工具的基本功，基本功好，可以保證大部分表內計算都不出問題，但萬事總有例外，即使是以性能見長的潤乾報表，也會遇到跑不快的情況舉個最簡單的例子，比如要在報表里做多源關聯，我們需要寫一個類似這樣的表達式 ds2.select(ID==ds1.ID)，表達式很簡單，但是計算復雜度卻是平方級的，數據量不大時，都沒問題，數據量稍大時，到幾千行，那性能就會急劇下降了，再好的工具處理這樣的運算也會有問題但如果把這個關聯放到報表外來做，用 SPL 來做，則可以使用低復雜的 HASH 算法（而在報表工具中無法對多個數據源先統一處理，實現不了這種算法），那性能就會大幅度的提升了以下是我們在數據量比較大時，用潤乾報表單獨運算和 SPL+ 潤乾報表協同運算的性能對比，可以看出，報表內的計算性能問題，如果挪到外部計算引擎解決，效果是非常好的（藍色是潤乾報表單獨運算的時間，橙色是 SPL+ 潤乾報表協同運算的時間）另外前面提到的，有時候報表設計中會多出很多用于保存中間結果的隱藏格，這些隱藏格在計算的時候也會占用很多內存，數據量小的時候感覺不到，量一大就卡了使用 SPL 去做這些過程計算，則可以避免這樣的問題還有緩存使用緩存能夠有效地改善報表響應的用戶體驗，高端的報表工具一般都提供緩存功能。但報表工具的緩存機制比較死板，只能針對整個報表，不能只緩存報表的某個部分，兩個報表有共同部分也無法復用緩存，也沒法分別指定不同報表緩存在不同參數下的不同生存周期。因為報表工具采用可視化的配置方案，雖然使用簡單，但很難設置過多復雜的參數用 SPL 準備數據時就可以實現可控緩存的效果，SPL 是程序代碼，可以由開發者靈活決定使用緩存的時刻及范圍的策略，這樣就可以實現報表的部分緩存、多個報表之間緩存復用、以及不同緩存的不同生存周期大數據量報表 報表性能問題們還有一個場景需要注意，就是大清單式報表，比如電信行業，要查看當月所有的充值記錄，這樣的報表，格式簡單，但是數據量極大，有的可達到千萬級以上，這類大數據量的報表呈現時如果等著把這些記錄全部檢索出來再生成報表，那會需要很長時間，用戶體驗自然會非常惡劣，而且報表一般采用內存運算機制，大多數情況下內存里也裝不下這么多數據，所以我們一般都會使用分頁呈現的方式，盡量快速地呈現出第一頁，之后再通過翻頁來加載后面的這種分頁呈現的方式通常是利用數據庫的分頁機制來實現，但數據庫分頁不僅有如下這些弊端，而且程序代碼和對應的數據庫是強耦合的，萬一換了數據源，那還得重新做一遍更好的方式是，取數和呈現做成兩個異步線程，取數線程發出 SQL 后就不斷取出數據后緩存到本地存儲中，呈現線程根據頁數計算出行數到本地緩存中去獲取數據顯示，如下圖所示通過這樣的方式，就可以很好的解決大數據量清單式報表的性能難題了具體如何實現可以參考：大清單報表該怎么做？

總結

報表工具的兩次革命：第一次革命，解決了國外報表工具不好用，做不了復雜報表的難題，重新定義了報表工具的標準，讓用戶張口就能問：能不能做中國式復雜報表，有沒有非線性報表模型，也讓國產軟件在報表這個領域一直以碾壓式的優勢走到現在第二次革命，解決了報表外圍的數據準備過程 SQL、存儲過程、JAVA 難寫以及性能低下的難題，同時還優化了報表應用的結構，再一次重新定義了報表工具的標準，讓業界都認可報表工具要有一個計算層，也讓整個報表的解決方案更完整，有了質的提升。