實時流計算在保險決策系統中的應用*

吳 鋒 陸智卿 趙文洋

（中國石油大學（華東）計算機與通信工程學院 青島 266580）

1 引言

實時和流計算是近期非常熱門的關鍵詞，隨著Spark等專為大數據［1］設計的開源引擎的出現和完善，實時流［2］計算在國內外知名企業中的應用呈現井噴爆發之態勢。實時流計算技術更是為金融保險行業商業智能領域帶來新的契機，采用實時流計算技術能夠解決決策系統信息滯后的痛點，極大提高經營決策效率和準確度［3］。

2 研究現狀

實時流計算已在金融保險行業廣泛應用和實施，成為促進企業經營快速發展的必備技術［4］。而此技術對于數據加工環節的及時性，一般可以分為批處理模式和流式大數據模式，流式大數據模式也會被稱為大數據實時計算，技術體系方面主要還是以Hadoop作為主要生態系統，技術推動涌現出storm、spark等應用于流計算的框架工具，其中以Spark作為主要的流計算處理框架，在世界范圍內應用最為廣泛［5～7］。

在金融保險行業、電商、物流等多個行業中，為了提升對用戶的滿意度、以及公司經營發展的需要，催生出的智能決策分析、決策管理駕駛倉等，都需要在數據加工環節有了不一樣的需求。為了實現業務目標，數據加工必須快速返回數據結果，而傳統的決策加工技術一般都是批作業方式實施，數據要先經過多個環節處理加工、存儲并返回結果，往往都有相當的滯后性，通常都是N+1天，特別是一旦業務數據量急劇膨脹時，傳統的決策加工技術更是無法支撐其更高的業務目標要求。

隨著保險公司業務不斷的擴大發展，其業務數據越來越龐大，而過去所使用的傳統決策系統已無法支撐其更高的要求，為此本文提出開展實時流式處理的技術在決策分析中的應用研究，子課題便是在個險作戰地圖的報表分析實現“個險首年期交保費”的實時流計算應用，用大數據技術實現對該指標數據的實時追蹤。

3 實時計算原理

3.1 決策分析

決策分析［8］通常包括數據收集、數據存儲、數據計算［9～10］和數據分析［11～12］等多個方面，以數據為基礎，借助利用先進的存儲、計算以及可視化等技術，讓更多的數據用于業務經營和管理決策。其具體內容如圖1所示。

圖1 決策分析內容詳解圖

3.2 實時流式計算

流計算［13］的應用場景主要還是面向巨量數據時，能夠秒級返回處理結果。流計算技術就是面向這一應用場景的，能夠實時處理計算并且實時落地數據庫［14～15］。而 Apache Spark 是專為大規模數據處理而設計的快速通用的計算引擎，實時流式計算可以實現數據高速流轉［16］。

4 系統設計與實現

4.1 需求特征

具體的業務場景，是要實現一套掛圖作戰實時指標等實時數據追蹤系統，通過對其業務場景進行需求分析，其需要實現實時的指標加工計算和呈現，而在指標技工過程中，需要對大批量的歷史數據進行一次性加工計算，以及實時能夠加工新的增量數據，同時向地圖應用能夠實時呈現最終結果。實時增量數據主要源于核心業務處理系統，客戶實時購買的業務保單，這部分實時進單保費，具有數據量大，數據價值隨時間流逝而降低的特性，且數據價值密度低，很少需要精細查詢。歷史全量數據則為數據字典等，例如組織架構代碼等，具有數據量小，修改不多的特征；統計結果數據為上述數據的復雜計算結果，例如掛圖作戰中的個險首年期交保費，該指標加工復雜，需配合實時進單保費、歷史存量數據并進行復雜的多列聚合計算而成，而因為增量的進單保費一般數據相對較小，在應用場景中需要實時的進行呈現，因此需要對其進行快速且并發進行加工計算。

4.2 實時決策分析中的指標計算

實時流應用在決策報表中，指標加工計算是其重要的一環。而其加工指標一般要求能夠在秒級能夠完成數據加工，對于大多實時流計算指標而言，其最主要的加工口徑為

WE等于數據加工完畢時間-數據生成時間。

WX等于決策分析指標可延遲的時間。

指標數據加工需要在業務要求范圍內實施，根據公式只有E遠遠高于1，其實時指標加工計算的能力才能夠符合系統的要求。反之，如果無法實現實時加工計算，那么公式中的E將低于1。如果再加工的過程中，計算延遲嚴重，那么WE便會快速放大，最終整個業務場景實時流計算加工指標將無法達成目標。對于保險行業的決策分析應用，目前要求其WX為5min，且未來將逐步減少到1min。

4.3 設計原則

結合保險公司的建立實時掛圖作戰決策系統的應用場景，同時基于其系統中所要求實現的實時追蹤指標的加工方式，將提出需要在設計過程中重點實現4條設計原則。

1）存量數據加工。一次性初始化實現，存量數據加工因為變化小，數據量大，為了保證加工計算的時效性，這部分數據加工處理場景將不會用流計算的模式，將會采用一次性初始化加工抽取完成。考慮到后續內存數據庫技術的逐步完善，未來把會將這部分數據放在內存中進行計算，同樣可以大幅提升其加工效率，同時采用內存和存儲的互相切換，能夠更加理想的提供計算查詢服務。

2）小數據量的增量流式計算服務能力。這部分需要要求實時性高，同時數據量較小，多為業務增量實時產生，對于這部分加工設計，將會根據業務上的需要，在內存中實時加工計算，不落地存儲的方式。

3）混合計算模式。由于實時掛圖作戰決策報表系統需要實時呈現指標的動態變化周期以及體現高速增長時效性，將對其指標采取預先計算處理方式，在存量加工指標的基礎上，實時疊加增量的部分，將結果預先計算好，根據決策系統的查詢報表條件存儲在Hadoop存儲中，這樣也能夠提供高并發查詢的指標級服務，最終體現實時監控的周期性、時效性等特征，動態變化。

4）預計算模式取代實時計算模式。由于實時監控數據具有強烈的周期性特征及時效性特征，故將要計算的指標均采用預先處理的模式，先計算好結果，存入到KV存儲引擎中，將用戶的查詢轉換為按照條件組成Rowkey的KV查詢模式，從而實現快速的高并發查詢Redis服務。考慮到高速并發以及容災措施，將結果集指標定期存儲在redis服務中，一旦出現加工不及時或者數據庫錯誤時，能夠實時切換至redis查詢服務中，給用戶帶來系統更加穩定的感受。

圖2 基于流處理的數據流程圖

因此，基于流處理的數據流程如圖2所示，通過該流程設計，將計算與數據存儲分離，解決傳統架構中計算與存儲混合對系統處理效率的影響。因此，一方面能夠解決傳統決策系統計算存在的問題，也能夠將計算和存儲進行分離、且混合處理。

4.4 技術架構

為了支撐指標的實時追蹤，在技術架構上，將采用“職責分段”的思路，進行了如下幾項設計：

1）使用SharePlex監控Oracel日志文件，捕獲數據庫操作消息，從而獲取業務系統數據庫的增、刪、改的增量數據。

2）使用Kafka記錄SharePlex的數據消息，負責消息隊列分發。將增量數據轉成消息往下游推送和處理加工。

3）使用Spark Streaming對數據進行抽取、過濾。根據指標的業務口徑，將消息增量數據加工成決策系統中的指標數據。

4）使用Redis負責存儲、加工消息數據。將處理后指標數據暫存在Redis內存數據庫中。

5）封裝WebService服務，對外提供數據查詢。封裝后的接口服務，可以提供給任意決策分析應用進行調用，保證數據對外輸出的一致性。

通過以上技術架構的設計，具體的系統架構圖如圖3所示，能夠提供可靠、準確、穩定、實時的保費指標，這些設計使得決策分析系統的價值體現邁向了一個新的臺階。

5 結語

本文從保險行業的特點以及其決策系統的時效性要求出發，提出要建立一種新的流式計算基于混合計算、分離存儲過程的模式，極大地提升了報表的數據及時性，基本滿足更多業務追蹤上的應用場景。技術框架上，采用的是Spark和kafka等開源軟件作為技術核心，具備一定的可擴展性和先進性，同時為了讓該技術方案具備一定的推廣性，提出了基于實時計算平臺的公共JAR包以及簡易SQL的模板支持，可以將該方案快速復制，具有開發周期短、可復用性高等特點。

圖3 系統架構圖

在未來，將會進一步對該技術架構迭代改進，并針對保險行業對于數據質量要求高、重穩定等特點進行針對性優化，使之能夠在更多的數據分析場景中快速推廣，能夠為公司數據存儲、計算、分析的全價值鏈提供數據可視化平臺，迎接更多的大數據挑戰。