分布式計算技術在交通一卡通清分管理系統中的應用研究

方秋水　陳衛國　何建兵　徐　鋒

(廣東嶺南通股份有限公司　廣東 廣州 510110)

0　引　言

自城市交通一卡通系統建設以來，經歷了20多年的發展，承擔著廣大民眾在公交、輪渡、地鐵、輕軌、出租汽車等公共交通工具的電子支付服務功能，為人們日常生活、出行提供了便利環境。城市交通一卡通已經成為人們生活中快捷、便利的支付手段與途徑，同時也積累了龐大的數據資源。以廣東嶺南通為例，舊有的清算系統已經運行了多年，存儲了數百億條歷史交易數據，隨著交通一卡通應用規模的擴大，數據量將呈現快速的上升趨勢。對海量數據的交易與處理很大程度上增加了原有清分系統運算負荷，降低了運行性能和處理速度。通過對一卡通業務發展分析可知，從目前城市交通一卡通交易數據的變化趨勢來看，交易數據量逐日增加，可以預見的是，未來接受處理的歷史交易數據量將以百億計，日均處理的交易數據量將達千萬級別，現有的系統硬件及清算系統顯然是無法滿足未來龐大的清算業務量需求。

另一方面，隨著交通運輸部全國交通一卡通互聯互通工程的開展和《城市公共交通IC卡技術規范》的頒布實施，旨在統一全國范圍內的交通一卡通標準體系，進一步規范交通行業支付領域的業務管理系統、信息接口、安全技術、讀寫終端、卡片產品以及設備認證檢測等技術標準，為新一代城市一卡通提供技術標準與指引，從而推進全國交通一卡通互聯互通工作。但研究發現，大部分省市現有的交通一卡通清分系統均不滿足交通部頒布的新技術規范，如果在原有清算系統的基礎上進行升級改造，不僅工作量巨大且技術風險較高，難以確保與交通部清算系統的正常對接[1-3]。

在此背景下，為滿足未來數據量劇增的系統處理需求及全國統一標準的接入要求，本文提出一種基于分布式計算技術的交通一卡通清分結算管理系統。該系統采用目前流行的Storm平臺模式，為行業企業提供彈性計算、存儲及實時業務處理，適用于一卡通行業大數據分析與應用。

1　建設需求分析

隨著城市一卡通業務的發展和數據規模的擴展，對交易數據清分管理功能及性能提出了更高的要求，在滿足日益增加的交易數據量情況下，新系統應能高效、準確地對交易數據進行統計分析，針對多場景化應用數據的多樣性，滿足其清分的需求。

該系統在設計上充分考慮了其性能水平的可擴展性，即隨著交易數據的增加，在不中斷服務的情況下，系統可通過添加資源，讓服務在更多的進程以及服務器之間并行處理，在提高其處理性能同時，不影響清分功能的穩定性、健壯性，使得系統具有海量數據的處理能力。

針對交通一卡通目前及未來將要開展的信用支付業務、電子票證業務、小額理財業務等互聯網增值應用的發展需求，該系統在保障基本清分功能的基礎上，進一步滿足各種不同業務類型數據需求，并隨著業務數據種類的不斷增加，系統能方便進行擴展并屏蔽數據之間的差異性，為企業提供可靠的數據處理。

另外，該系統還需具有可持續計算，對數據實時分析的能力，最大限度地降低交易延遲。一旦有數據流入系統就即刻處理并及時生成清分結果。在系統出現故障的時候，仍能對外正常提供清分服務，具有良好的容錯能力。

2　系統平臺構建

分布式計算是一門計算機科學，主要研究分布式系統。分布式應用系統主要包括若干臺通過網絡實現互聯的計算機，這些計算機互相配合以完成一個共同的應用目標或服務目標。具體的過程是：將需要進行大量計算的項目數據分割成小塊，由多臺計算機分別計算，再上傳運算結果后統一合并得出數據結論。在分布式系統上運行的計算機程序稱為分布式計算程序；分布式編程就是編寫上述程序的過程。

Storm是一個分布式的、可靠的、容錯的數據流處理平臺，目前由Apache軟件基金會進行維護。Storm項目License遵循Apache License，Version2.0協議。Apache License協議是對商業應用友好的許可，使用者也可以在需要的時候修改代碼來滿足需求并作為開源或者商業用途。Storm的使用案例廣泛，國內如支付寶、淘寶、百度等公司用其進行大數據的實時計算分析處理。大數據計算主要包括批量計算和實時計算，解決了批量計算處理歷史數據而不能實現低延遲高響應的缺點[4]。由于數據增長永不停息，伴隨著這種巨大的業務增長潛力,需要深入思考不同的數據處理方式。

與Hadoop相比，Storm技術具有更大的優勢，將成為下一代云計算、大數據的核心技術[5]。Storm技術可使持續不斷的流計算變得容易，彌補了Hadoop批處理所不能滿足的實時要求。Storm經常用于實時分析、在線機器學習、持續計算、分布式遠程調用和ETL等領域。Storm的部署管理非常簡單，在同類的流式計算工具中其性能是非常出眾的。

針對一卡通清分管理系統的各種特性要求，經研究分析，提出一種基于Storm的新型大數據處理解決方案，旨在使大數據處理功能更穩定、高效,并對通過對本方案進行相關性能測試 ,結果表明這種新型架構是高效、穩定、可行的[6]。

在設計上采用Storm作為清分處理的基礎平臺。該平臺具有以下特性：

(1) 廣泛的適用場景基于分布式計算系統提供的基礎原語之上可以構建滿足多應用場景的實時計算應用。如實時分析、持續計算等。

(2) 高可伸縮性資源管理節點來配置進程管理，使得分布式計算系統的集群擴展十分方便，通過增加資源可相應提高性能。

(3) 高性能使用高性能的序列化工具和消息隊列，且因為消息是無狀態的，數據流不需要持久化，因此有著非常優秀的性能。

(4) 高可靠性高效可靠的消息確認機制，保證每一條消息都會被處理。

(5) 異常健壯更容易進行集群管理，其節點的無狀態性和fail-over的設計使得它并不存在單點故障問題。

(6) 容錯性保證一個拓撲計算節點一直運行，數據在處理過程中發生異常，分布式計算系統能夠重新發現異常的場景。

3　系統架構設計

3.1　架構設計

構建面向全省的交通一卡通清分管理系統，利用基于Storm的分布式計算技術實現對全省各地市交通一卡通的交易數據進行統一化、標準化管理，并推動清分服務與全國交通一卡通互聯互通系統進行業務對接。鑒于未來發展的應用需求，該應用研究對系統整體架構進行合理有效的設計，系統架構自下而上可劃分為4個層次，分別是接口層、系統功能層、集成層、視窗層，如圖所示。

圖1　系統架構圖

(1) 接口層接口層是指該系統與所有外部系統的接口，負責對接的系統包括密鑰管理系統、結算中心系統、部級清分結算平臺等，接口根據業務類型可分為4類接口數據采集接口、校驗接口、數據下發接口、公用服務接口。

(2) 系統功能層系統功能層包括了系統功能子系統，集中、直觀地體現一卡通清分管理系統的各項業務功能。

(3) 集成層基于系統功能層規劃出集成各個子系統所需的系統功能，主要分為頁面集成和數據處理集成。

(4) 視窗層面向用戶交互，用于顯示數據和接收用戶輸入的數據，為用戶提供一種交互式操作的界面。

3.2　技術架構

圖2　技術架構圖

客戶端使用Web瀏覽器(IE/Firefox/chrome)、手機、數據下發系統等三種途徑進行系統交互。表現層與業務邏輯層通過HTTP HTML進行交互。移動端和后臺服務器端可通過socket接口進行數據獲取；數據采集部分可通過FTP/SOCKET/HTTP等協議進行上傳和下載業務數據。

業務邏輯層即應用服務器層，既包含使用JSP/Servlet、FineReport、socket/ws接口、JDBC等持久化技術的J2ee Web應用，也包含數據接口服務組件。

核心組件層即數據處理層，核心處理組件為基于Storm計算框架的數據處理引擎。為匹配其高速處理的性能，需要配備高速緩存Redis作為緩存中間件，其中保留處理監控信息以及處理配置數據。同時配備高速穩定的消息隊列中間件Kafka作為數據處理入口，以處理高吞吐的海量數據。配備Zookeeper作為管理配置服務器，為Storm做負載均衡的調節。同時在數據核查中使用分布式存儲數據庫MongDB作為核查數據的存儲，并配有數據核查程序進行各種數據核查。使用Oracle客戶端程序SQLLoader作為數據入庫程序，可以滿足該系統數據庫入庫速率要求。

3.3　Storm架構

圖3　Storm架構圖

如圖3所示，當一個流計算拓撲定義好后被提交，首先會由分布式計算系統提供的方法把編寫好的程序包上傳到任務調度節點(Nimbus)，接著對分布式計算系統本身和拓撲計算節點進行校驗，主要檢查分布式計算系統的狀態是否為在線以及拓撲計算節點是否有同名的實例在運行。下一步，任務調度節點(Nimbus)對每個拓撲計算節點都會做出詳細的預算，如工作量，它會根據拓撲計算節點中定義的parallelism hint參數，來給計算節點設定工作量(Task)數目，并且分配與其對應的Task-id，再把分配好的工作量信息寫入資源管理節點(Zookeeper)上的/tasks目錄下。然后任務調度節點(Nimbus)會給管理進程(Supervisor)分配工作，方法是把任務信息寫在資源管理節點(Zookeeper)的管理目錄下。管理進程(Supervisor)每隔一定時間都會查看管理目錄，檢查任務調度節點(Nimbus)是否有新任務分配，當有新提交的任務時，將先下載代碼，然后根據任務信息安排計算節點(Worker)執行這些任務。每個計算節點(Worker)都是一個JVM實例，工作量(Task)會被分配到具體的計算節點中執行，計算節點(Worker)與工作量(Task)支持并行度的配置。

圖4為Storm中運行的一個實時應用程序，由于各組件間的消息流動形成邏輯上的一個拓撲結構。一個Topology是Spout和Bolt組成的圖，通過Stream Groupings將圖中的Spout和Bolt連接起來。消息源Spout是Storm里面一個Topology里面的消息生產者，Spout從來源處讀取數據并放入Topology。Topology中所有的處理都由Bolt完成。即所有的消息處理邏輯被封裝在Bolt里面。Bolt負責完成具體的事項，比如連接的過濾、聚合、訪問文件、數據庫等。圖4描述的是一個Topology在設計上的結構模型，具體的task的設置可由以下代碼完成，其中Spout的task數量為2，Bolt A的task數量為4，Bolt B與Bolt C的task數量為3。Bolt A與Bolt B從Spout處訂閱消息，Bolt C從Bolt A處訂閱消息。

圖4　Topology結構圖

3.4　系統拓撲結構

該系統中拓撲的設計嚴格遵循Storm平臺關于松耦合、高內聚的原則，支持業務數據的多樣性，具有優秀的橫向擴展能力。系統的整體拓撲結構圖5所示。

圖5　系統總體拓撲關系圖

從數據采集階段開始，數據被流轉到文件處理的拓撲中，不同類型的數據(如城市一卡通數據、國標卡數據、信用管理數據、電子票證數據等)將被系統歸類并交給不同的拓撲進行文件處理。當新增業務數據類型的時候，只需新增對應的拓撲進行處理即可，不影響現有的拓撲。文件處理拓撲與數據存儲服務層密切交互，獲取執行期間所需的基礎數據(如票卡信息、黑名單等)，并保存執行的結果數據(有效數據、掛起數據等)。各種類型的業務數據經過文件處理階段之后，統一進入到數據檢查、異常處理、掛起數據核查等拓撲，此類拓撲以數據存儲服務層作為數據的源頭，進行相應的數據處理，處理的結果通過數據接口服務進行數據下發。系統的所有拓撲均處于系統監控模塊的監視之下，該模塊將及時對數據處理執行的過程進行反饋。

以下就系統中的地標卡數據處理拓撲進行說明，其他拓撲的設計過程與此類似。如圖6所示。

圖6　系統文件檢查拓撲圖

圖6描述的是關于某城市一卡通數據的文件檢查的拓撲，具體處理流程如下：

數據從數據接口采集然后流入到ZIP Spout，ZIP Spout獲取數據后發送給節點ZIP Check Bolt。

ZIP Check Bolt進行文件包基礎檢查，包括文件包標示符、命名長度等。檢查合法之后，將數據流轉到下一節點Audit File Check Bolt進行審計檢查。

審計檢查節點Audit File Check Bolt在比對文件包文件數據，數據條數，總交易金額等信息與審計文件所描述的一致之后，繼續將數據發送到下一節點File Base Check Bolt進行數據包內文件的檢查。

File Base Check Bolt節點對文件的標示符、命名長度等檢查通過之后，將交易數據流轉到File Record Relipcation Check Bolt進行文件內數據重復的檢查。將非交易數據發送到Other File Handle Bolt進行處理。

文件內數據重復檢查節點在檢查過程中會剔除掉重復數據，將非重復數據發送給File Prev And Next Trade Check Bolt進行文件內上下筆的檢查。

非交易數據處理節點Other File Handle Bolt對數據進行校驗之后，將數據入庫。

數據檢查節點出現數據校驗不通過的情況下，將數據流轉到Invalid Handls Bolt進行處理。

如數據通過所有文件檢查的節點，將被放置進分布式消息隊列Kafka，以便其他Topology或者計算節點從中獲取數據繼續執行任務，同時將檢查過程中產生的配置或結果數據緩存進Redis。文件檢查Topology在執行過程中還與數據庫進行交互，獲取基礎配置數據。

以上整個流程受系統監控模塊的監控，對各節點出現數據校驗不通過的情況進行預警，及時將任務執行過程進行反映。

4　結　語

隨著城市智能交通應用體系的不斷發展與健全,交通信息化應用服務功能的不斷擴展,以及交通一卡通大數據應用技術的不斷深入發展，越來越多的復雜系統將成為定量分析的對象，如何打造合適的數據分析技術是未來企業發展的重要支撐點[7]。本文所研究的城市交通一卡通清分管理系統是基于一卡通業務發展、交通大數據分析服務以及未來智慧城市發展需求而建設，構筑以云平臺為基礎設施，以主流的分布式計算技術為核心，具備高效性、高安全性、高可靠性的數據清分管理系統。實驗證明，基于Storm的云計算適用于清分系統處理的實時數據業務和非實時數據業務[8]。另外，在滿足現有清分系統功能需求的同時，根據未來業務拓展的需求開發全新的清分系統，極大提升了通卡企業的清分業務功能，為構建諸如電子票證、信用支付、金融服務等增值業務打下堅實的基礎。通過本研究所提出的數據清分系統設計方案，不僅能有效實現一卡通在大數據環境下的清分結算，也能為企業、商戶等單位提供有價值的數據分析服務。

[1] 中華人民共和國交通運輸部. 城市公共交通IC卡技術規范: Technical specification on IC card for urban public transport[S]. 人民交通出版社股份有限公司, 2015.

[2] 吳金成, 謝振東, 伍冠樺,等. 基于交通一卡通數據的交通狀態分析及動態控制研究[J]. 廣東工業大學學報, 2017, 34(3):77-82.

[3] 劉強, 何建兵, 張景奎,等. 基于云計算的公共交通大數據處理機制研究[J]. 科技致富向導, 2014(20):192-192.

[4] 趙菲, 林穗, 高西剛. 面向大數據的Storm框架研究與應用[J]. 微型機與應用, 2016, 35(6):12-14.

[5] 靳永超, 吳懷谷. 基于Storm和Hadoop的大數據處理架構的研究[J]. 現代計算機, 2015(3):9-12.

[6] 王利卿, 張華敏. 分布式計算框架的研究[J]. 信息技術與信息化, 2015(10):199-200.

[7] 劉聰, 許莉娟. 基于Java的分布式高性能計算架構[J]. 鹽城工學院學報(自然科學版), 2013, 26(3):10-13.

[8] 胡宇舟, 范濱, 顧學道,等. 基于Hadoop的云計算在清分系統中的應用[J]. 電子世界, 2014(13):16-17.