問題描述

C保險公司業(yè)務(wù)系統(tǒng)中，團體保險明細查詢速度很慢。查詢時輸入保單號，要返回團體保單包含的所有被保險人的信息。較小的保單，包含1萬個被保險人，返回頁面需要等待7.5分鐘。較大的保單，包含100萬被保險人，返回頁面等待了4個小時沒有出來。

團體保險明細比較大，分兩個數(shù)據(jù)庫保存。每個團體保單的數(shù)據(jù)，在兩個庫中都有可能出現(xiàn)。數(shù)據(jù)庫是Oracle，SQL語句共163行，如下圖：

分析解決

面對性能問題，需要仔細分析數(shù)據(jù)和計算的特征，定位性能關(guān)鍵點，通過改變數(shù)據(jù)的存儲方式和計算方法逐步優(yōu)化。

第一步，確認需求前提。團體保險明細查詢是應(yīng)用系統(tǒng)中的一個功能，需要查詢最新數(shù)據(jù)。如果采用ETL定時將數(shù)據(jù)導(dǎo)出計算的方式，不能滿足這個要求。因此，還是要想辦法從數(shù)據(jù)庫取數(shù)、庫外計算，來優(yōu)化性能。

第二步，了解業(yè)務(wù)需求特征。團體保險明細數(shù)據(jù)存放在兩個數(shù)據(jù)庫db1、db2，每個數(shù)據(jù)庫都有兩個表m1、m2。這四個表在查詢時要合并查詢結(jié)果，我們統(tǒng)一稱為團體保險明細表。

四個團體保險明細表有所不同，但是都可以查詢出主要字段：保單號、保險成員號、批改次數(shù)、業(yè)務(wù)編號1、業(yè)務(wù)編號2、業(yè)務(wù)標(biāo)志，還有姓名、性別年齡等個人信息

“批改”是針對保險合同的調(diào)整，系統(tǒng)將調(diào)整后的最新保險明細也保存在團體保險明細表中，不會修改原保險明細，保留軌跡。在數(shù)據(jù)中通過“批改次數(shù)”字段體現(xiàn)。查詢時，要查詢批改次數(shù)最大的一次，也就是最新的數(shù)據(jù)。

明細數(shù)據(jù)中還有一部分是無效數(shù)據(jù)。要看業(yè)務(wù)編號1和業(yè)務(wù)標(biāo)志連接成的字符串是否在無效集合中。無效集合是指：同一個保單號的數(shù)據(jù)中，批改次數(shù)小于9，并且業(yè)務(wù)標(biāo)志為D或者U時，業(yè)務(wù)編號2和字母A連接成的字符串形成的集合。如果業(yè)務(wù)編號1和業(yè)務(wù)標(biāo)志連接成的字符串出現(xiàn)在無效集合中，這條記錄就是無效的記錄，要舍棄掉。

第三步，梳理研究計算過程。SQL雖然比較長，但是可以分成幾個部分。第一部分是兩個數(shù)據(jù)庫的4個團體保險明細表，各自按照保單號查詢需要的數(shù)據(jù)，再用union合并在一起。第二部分是條件過濾，包括去掉無效數(shù)據(jù)和另外幾個簡單的條件。第三部分是用窗口函數(shù)row_number() OVER(PARTITION BY 保險成員號 ORDER BY 批改次數(shù) desc)，查找批改次數(shù)最大的明細記錄。

第一部分單獨執(zhí)行時，返回的結(jié)果數(shù)據(jù)量是幾萬到幾百萬，全部返回的時間比較長。如果用數(shù)據(jù)庫JDBC游標(biāo)的話，很快就能返回部分?jǐn)?shù)據(jù)，比如幾秒就可以返回幾千條。

第二部分，單獨從數(shù)據(jù)庫中取得無效集合只需要幾秒，而且返回結(jié)果數(shù)據(jù)量不大，可以全內(nèi)存。

但是，第一部分和第二部分合并執(zhí)行的時候，速度就變得很慢，即使是游標(biāo)方式分批返回，也還是很慢。如果再加上第三部分，就更慢了。

第四步，設(shè)計呈現(xiàn)方案。根據(jù)SQL分段執(zhí)行的情況，確定采用流式大報表的方式實現(xiàn)提速，原理如下圖：

從數(shù)據(jù)庫取數(shù)和呈現(xiàn)采用兩個異步線程，取數(shù)線程發(fā)出 SQL 后不斷取出數(shù)據(jù)經(jīng)過復(fù)雜計算后，緩存到本地。再由呈現(xiàn)線程從本地緩存中獲取數(shù)據(jù)進行顯示。這樣，已經(jīng)取出并緩存的數(shù)據(jù)就能快速呈現(xiàn)，不再有等待感。

第五步，設(shè)計計算過程優(yōu)化方案。我們考慮將取數(shù)和計算分三段實現(xiàn)。

第一段，上面說的第一部分SQL加上按照保險成員號和批改次數(shù)降序排序之后，用數(shù)據(jù)庫JDBC游標(biāo)依然能夠快速分批取出部分?jǐn)?shù)據(jù)。加上排序，可以在分批取出數(shù)據(jù)時，保證一個保險成員的數(shù)據(jù)相鄰取出，在后續(xù)第三段中，就能夠快速找到批改次數(shù)最大的最新數(shù)據(jù)。

第二段，我們將這個保單的無效集合一次性取出到內(nèi)存中，對第一段分批取出的數(shù)據(jù)進行過濾，計算出符合條件的有效明細。無效數(shù)據(jù)并不多，不會過濾掉太多的明細數(shù)據(jù)。

第三段，根據(jù)被保險人號是否改變，判斷是不是一個被保險人的第一條數(shù)據(jù)。因為明細數(shù)據(jù)按照被保險人和批改次數(shù)有序，所以當(dāng)被保險人號改變的時候，第一條數(shù)據(jù)就是當(dāng)前被保險人批改次數(shù)的最大值。這樣就起到了，和上面說到的窗口函數(shù)一樣的作用。

由于每個保險成員的數(shù)據(jù)量都不大，一般是最多十幾條數(shù)據(jù)（對應(yīng)幾次到十幾次批改），而且無效數(shù)據(jù)并不多。所以第一部分分批取出的數(shù)據(jù)量不需要很多，就可以向前端批量返回數(shù)據(jù)了。這是流式大報表能夠快速展現(xiàn)的必要條件。

第六步，設(shè)計代碼實現(xiàn)方案。使用延遲游標(biāo)的方法實現(xiàn)上述三個分段。延遲游標(biāo)的原理是，先依次定義三個分段的游標(biāo)計算，定義的時候并不真的執(zhí)行計算，而是在三個分段都定義好之后再執(zhí)行。延遲計算的好處是可以一次遍歷完成三個分段計算，不必生成中間結(jié)果占用空間，可以把查詢結(jié)果分批提交給前端去展現(xiàn)。

第三段游標(biāo)計算比較復(fù)雜，需要用程序游標(biāo)來實現(xiàn)。原理如下圖：

程序游標(biāo)要做到被調(diào)用的時候，邊計算邊返回結(jié)果，這樣才能達到流式大報表的要求。

實際效果

根據(jù)計算特征擬定了優(yōu)化方案后，需要選擇合適的工具來實現(xiàn)計算和展現(xiàn)的性能優(yōu)化。直接使用Java當(dāng)然可以實現(xiàn)，但編碼量過大，實現(xiàn)周期過長，容易出現(xiàn)代碼錯誤隱患，也很難調(diào)試和維護。而開源的集算器SPL語言提供上述所有的算法支持，包括延遲游標(biāo)、游標(biāo)有序分段取出、程序游標(biāo)等機制，能夠讓我們用較少的代碼量快速實現(xiàn)這種個性化的計算。前端呈現(xiàn)需要支持流式大報表機制的報表工具，我們選擇了潤乾報表來實現(xiàn)。

僅僅經(jīng)過1天時間的編程、調(diào)試和測試，就完成了性能優(yōu)化的驗證，而且查詢的響應(yīng)速度非?？?。較小的保單，包含1萬個被保險人，原來返回頁面需要等待7.5分鐘，優(yōu)化后的報表首頁只需要3秒即可展現(xiàn)出來。較大的保單，包含100萬被保險人，原來返回頁面等待了4個小時沒有出來，優(yōu)化后的報表首頁僅7秒即可展現(xiàn)出來，響應(yīng)速度提高了2000倍還多。

在編程難度方面，SPL做了大量封裝，提供了豐富的函數(shù)，內(nèi)置了上述優(yōu)化方案需要的基本算法和存儲機制。實際編寫的代碼很短，開發(fā)效率很高。上述取數(shù)的三段代碼只有這么幾行：

后記

解決性能優(yōu)化難題，最重要的是設(shè)計出高性能的計算方案，有效降低計算復(fù)雜度，最終把速度提上去。因此，一方面要充分理解計算和數(shù)據(jù)的特征，另一方面也要熟知常見的高性能算法，才能因地制宜地設(shè)計出合理的優(yōu)化方案。本次工作中用到的基本高性能算法，都可以從下面這門課程中找到：點擊這里學(xué)習(xí)性能優(yōu)化課程（底部原文中可點擊鏈接），有興趣的同學(xué)可以參考。

很遺憾的是，當(dāng)前業(yè)界主流大數(shù)據(jù)體系仍以關(guān)系數(shù)據(jù)庫為基礎(chǔ)，無論是傳統(tǒng)的MPP還是HADOOP體系以及新的一些技術(shù)，都在努力將編程接口向SQL靠攏。兼容SQL確實能讓用戶更容易上手，但受制于理論限制的SQL卻無法實現(xiàn)大多數(shù)高性能算法，眼睜睜地看著硬件資源被浪費，還沒有辦法改進。SQL不應(yīng)是大數(shù)據(jù)計算的未來。

有了優(yōu)化方案后，還要用好的程序語言來高效地實現(xiàn)這個算法。雖然常見的高級語言能夠?qū)崿F(xiàn)大多數(shù)優(yōu)化算法，但代碼過于冗長，開發(fā)效率過低，會嚴(yán)重影響程序的可維護性。開源SPL是個很好的選擇，它有足夠的算法底層支持，代碼能做到很簡潔，還提供了友好的可視化調(diào)試機制，能有效提高開發(fā)效率，以及降低維護成本。

對于本例中的報表呈現(xiàn)，還需要有能支持流式呈現(xiàn)的報表工具，這方面潤乾報表有獨特的優(yōu)勢，不需要全部取出數(shù)據(jù)就可以開始呈現(xiàn)，也不依賴于數(shù)據(jù)庫分頁機制（這種方法可能造成數(shù)據(jù)不一致）就可以支持高速前后翻頁。這樣才能獲得業(yè)務(wù)用戶的良好體驗。