問(wèn)題描述

C保險(xiǎn)公司業(yè)務(wù)系統(tǒng)中，團(tuán)體保險(xiǎn)明細(xì)查詢(xún)速度很慢。查詢(xún)時(shí)輸入保單號(hào)，要返回團(tuán)體保單包含的所有被保險(xiǎn)人的信息。較小的保單，包含1萬(wàn)個(gè)被保險(xiǎn)人，返回頁(yè)面需要等待7.5分鐘。較大的保單，包含100萬(wàn)被保險(xiǎn)人，返回頁(yè)面等待了4個(gè)小時(shí)沒(méi)有出來(lái)。

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

分析解決

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

第三段，根據(jù)被保險(xiǎn)人號(hào)是否改變，判斷是不是一個(gè)被保險(xiǎn)人的第一條數(shù)據(jù)。因?yàn)槊骷?xì)數(shù)據(jù)按照被保險(xiǎn)人和批改次數(shù)有序，所以當(dāng)被保險(xiǎn)人號(hào)改變的時(shí)候，第一條數(shù)據(jù)就是當(dāng)前被保險(xiǎn)人批改次數(shù)的最大值。這樣就起到了，和上面說(shuō)到的窗口函數(shù)一樣的作用。

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

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

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

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

實(shí)際效果

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

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

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

后記

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

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

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

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