資料批處理速度慢？不妨試試這個

業務系統產生的明細資料通常要經過加工處理，按照一定邏輯計算成需要的結果，用以支持企業的經營活動，這類資料加工任務一般會有很多個，需要批量完成計算，在銀行和保險行業常常被稱為跑批，其它像石油、電力等行業也經常會有跑批的需求，

大部分業務統計都會要求以某日作為截止點，而且為了不影響生產系統的運行，跑批任務一般會在夜間進行，這時候才能將生產系統當天產生的新明細資料匯出來，送到專門的資料庫或資料倉庫完成跑批計算，第二天早上，跑批結果就可以提供給業務人員使用了，

和在線查詢不同，跑批計算是定時自動執行的離線任務，不會出現多人同時訪問一個任務的情況，所以沒有并發問題，也不必實時回傳結果，但是，跑批必須在規定的視窗時間內完成，比如某銀行的跑批視窗時間是晚上8:00到第二天早上7:00，如果到了早上7:00跑批任務還沒有完成，就會造成業務人員無法正常作業的嚴重后果，

跑批任務涉及的資料量非常大，很可能用到所有的歷史資料，而且計算邏輯復雜、步驟眾多，所以跑批時間經常是以小時計的，一個任務兩三小時是家常便飯，跑到十個小時也不足為奇，隨著業務的發展，資料量還在不斷增加，跑批資料庫的負擔快速增長，就會發生整晚都跑不完的情況，嚴重影響用戶的業務，這是無法接受的，

問題分析

要解決跑批時間過長的問題，必須仔細分析現有的系統架構中的問題，

跑批系統比較典型的架構大致如下圖：

從圖上看，資料要從生產資料庫取出，存入跑批資料庫，跑批資料庫通常是關系型的，撰寫存盤程序代碼完成跑批計算，跑批的結果一般不會直接使用，而是再從跑批資料庫中匯出，采用介面檔案的方式提供給其他系統，或者再匯入其他系統資料庫，這是比較典型的架構，圖中的生產資料庫也可能是某個中央資料倉庫或者Hadoop等，一般情況下，生產庫和跑批庫不會是同一種資料庫，它們之間往往通過檔案的方式傳遞資料，這樣也比較有利于降低耦合度，跑批計算完成后，結果要給多個應用系統使用，一般也都是以檔案方式傳遞，

跑批很慢的第一個原因，是用來完成跑批任務的關系資料庫入庫、出庫太慢，由于關系資料庫的存盤和計算能力具有封閉性，資料的進出要做過多的約束檢查和安全處理，當資料量較大時，寫入讀出的效率非常低，耗時會非常長，所以，跑批資料庫匯入檔案資料的程序，以及跑批計算結果再匯出檔案的程序都會很慢，

跑批很慢的第二個原因，是存盤程序性能差，由于SQL的語法體系過于陳舊，存在諸多限制，很多高效的演算法無法實施，所以存盤程序中的SQL陳述句計算性能很不理想，而且，業務邏輯比較復雜的時候很難用一個SQL實作，經常要分成多個步驟，用十幾甚至幾十個SQL陳述句才能完成，每個SQL的中間結果，都要存入臨時表給后續步驟的SQL使用，臨時表資料量較大時就必須落地，會造成大量的資料寫出，而資料庫的寫出要比讀入性能差很多，會嚴重拖慢整個存盤程序，

對于更復雜的計算，甚至很難用SQL陳述句直接實作，需要用資料庫游標遍歷取出資料，回圈計算，但資料庫游標遍歷計算性能又要比SQL陳述句差很多，一般也都不直接支持多執行緒并行計算，很難利用多CPU核的計算能力，會讓計算性能更加糟糕，

那么，是否可以考慮用分布式資料庫來代替傳統關系資料庫，通過增加節點數量的辦法，來提高跑批任務的速度呢？

答案仍然是不可行，主要原因是跑批計算的邏輯相當復雜，即使是用傳統資料庫的存盤程序，也常常要寫幾千甚至上萬行代碼，而分布式資料庫的存盤程序計算能力還比較弱，很難實作這么復雜的跑批計算，

而且，當復雜計算任務不得不分成多個步驟時，分布式資料庫也面臨中間結果落地的問題，由于資料可能在不同的節點上，所以前序步驟將中間結果落地，后續步驟再讀取的時候，都會造成大量跨網路的讀寫操作，性能很不可控，

這時，也不能采用分布式資料庫依靠資料冗余來提升查詢速度的辦法，這是因為，查詢之前可以預先準備好多份冗余資料，但是，跑批的中間結果是臨時生成的，如果冗余的話就要臨時生成多份，整體的性能只會變得更慢，

所以，現實的跑批業務通常仍然是使用大型單體資料庫進行，計算強度太大時會采用類似ExaData這樣的一體機（ExaData是多資料庫，但被Oracle專門優化過，可以看成是個超大型單體資料庫），雖然很慢，但是暫時找不到更好的選擇，只有這類大型資料庫有足夠的計算能力，所以只能用它來完成跑批任務了，

SPL用于跑批

開源的專業計算引擎SPL提供了不依賴資料庫的計算能力，直接利用檔案系統計算，可以解決關系資料庫出庫入庫太慢的問題，而且SPL實作了更優演算法，性能遠遠超過存盤程序，能顯著提高單機計算效率，非常適合跑批計算，

利用SPL實作的跑批系統新架構是下面這樣的：

在新架構中，SPL解決了造成跑批慢的兩大瓶頸問題，

首先來看資料的入庫、出庫問題，SPL可以直接基于生產庫匯出的檔案計算，不必再將資料匯入到關系資料庫中，完成跑批計算后，SPL還能將最終結果直接存盤成文本檔案等通用格式，傳遞給其他應用系統，避免了原有跑批資料庫的出庫操作，這樣一來，SPL就省去了關系資料庫緩慢的入庫、出庫程序，

下面再來看計算的程序，SPL提供了更優的演算法（有許多是業界首創），計算性能遠遠超過存盤程序和SQL陳述句，這些高性能演算法包括：

這些高性能演算法可以應用于跑批任務中的常見JOIN計算、遍歷、分組匯總等，能有效提升計算速度，例如，跑批任務常常要遍歷整個歷史表，有些情況下，對一個歷史表還要遍歷好多次，來完成多種業務邏輯的計算，歷史表資料量一般都很大，每次遍歷都要消耗很多的時間，此時我們可以應用SPL的遍歷復用機制，僅對大表遍歷一次，就可以同時完成多種計算，可以節省大量時間，

SPL的多路游標能做到資料的并行讀取和計算，即使是很復雜的跑批邏輯，也可以利用多CPU核實作多執行緒并行運算，而資料庫游標是很難并行的，這樣一來，SPL的計算速度常常可以達到存盤程序的數倍，

SPL的延遲游標機制，可以在一個游標上定義多個計算步驟，之后讓資料流按順序依次完成這些步驟，實作鏈式計算，能夠有效減少中間結果落地的次數，在資料必須落地的情況下，SPL也可以將中間結果存成內置的高性能資料格式，供下一個步驟使用，SPL高性能存盤基于檔案，采用有序壓縮存盤、自由列式存盤、倍增分段、自有壓縮編碼等技術，減少了硬碟占用，讀寫速度要遠遠好于資料庫，

應用效果

SPL在技術架構上打破了關系型跑批資料庫存在的兩大瓶頸，在實際應用中也取得了非常好的效果，

L 銀行跑批任務采用傳統架構，以關系資料庫作為跑批資料庫，用存盤程序編程實作跑批邏輯，其中，貸款協議存盤程序需要執行 2 個小時，而且是很多其他跑批任務的前序任務，耗時這么久，對整個跑批任務造成了嚴重影響，

采用SPL后，使用高性能列存、檔案游標、多執行緒并行、小結果記憶體分組、游標復用等高性能演算法和存盤機制，將原來2個小時的計算時間縮短為10分鐘，性能提高12倍，

而且，SPL代碼更簡潔，原存盤程序3300多行，改為SPL后，僅有500格陳述句，代碼量減少了6倍多，大大提高了開發效率，

P保險公司的車險業務中，需要用往年歷史保單來關聯新的保單，在跑批中稱為歷史保單關聯任務，原來也采用關系資料庫完成跑批，存盤程序計算10天的新增保單關聯歷史保單，運行時間47分鐘；30天則需要112分鐘，接近2小時；如果日期跨度更大，運行時間就會長的無法忍受，基本就變成不可能完成的任務了，

采用SPL后，應用了高性能檔案存盤、檔案游標、有序歸并分段取出、記憶體關聯和遍歷復用等技術，計算10天新增保單僅需13分鐘；30天新增保單只需要17分鐘，速度提高了近7倍，而且，新演算法執行的時間隨著保單天數的增長并不是很大，并沒有像存盤程序那樣成正比的增長，

從代碼總量來看，原來存盤程序有2000行代碼，去掉注釋后還有1800多行，而SPL的全部代碼只有不到500格，不到原來的1/3，

T銀行通過互聯網渠道發放貸款的明細資料，需要每天執行跑批任務，統計匯總指定日期之前的所有歷史資料，跑批任務采用關系資料庫的SQL陳述句實作，運行總時間7.8小時，占用了過多的跑批時間，甚至影響了其他的跑批任務，必須優化，

采用SPL后，應用了高性能檔案、檔案游標、有序分組、有序關聯、延遲游標、二分法等技術，原來需要7.8小時的跑批任務，單執行緒僅需180秒，2執行緒僅需137秒，速度提高了204倍，

SPL資料

• SPL下載
• SPL源代碼
  歡迎關注我的公告號：字母哥雜談，回復003贈送作者專欄《docker修煉之道》的PDF版本，30余篇精品docker文章，字母哥博客：zimug.com

標籤：其他

上一篇：執行緒池底層原理詳解與原始碼分析

下一篇：資料批處理速度慢？不妨試試這個