天天看點

「交易技術前沿」全曆史資料服務系統在信創大資料平台上的實踐

作者:閃念基因

肖鋼、李劍戈、王岐、高森

中信建投證券股份有限公司 資訊技術部 北京

郵箱:[email protected]

在證券行業數字化轉型的大背景下,利用海量曆史資料提升客戶服務價值已經成為頭部券商競相争奪的技術高地。随着中國證券交易客戶規模的不斷增長,交易系統資料成級數增加,傳統解決方案中的資料不全、資料标準不統一、系統性能無法保障等問題成為了曆史資料服務能力的瓶頸。本文從介紹曆史資料的重要性入手,首先對證券行業傳統曆史資料使用現狀進行了分析,進而提出一套基于全國産化技術的大資料平台解決方案。從資料治理、系統架構、國産化硬體選型、國産化軟體選型、全國産化系統的應用效果幾個方面介紹了某全曆史資料服務系統的實作,并提出了對該系統的後續規劃和展望。

1、引言

大資料是推動金融行業發展和證券業進步的重要戰略引擎,是推進券商治理體系和治理能力現代化的重要戰略資源,也是提升行業治理能力和水準的重要創新工具。大資料驅動券商行業治理創新不僅大大節約了券商治理的時間、資源和人力成本,而且建構了券商行業治理的新思路和新模式,實作了從封閉式管理走向開放式治理、從靜态化管理走向流動性治理、從精細化管理走向精準化治理、從網格化管理走向網絡化治理、從單向度管理走向協同化治理的路徑轉向。

「交易技術前沿」全曆史資料服務系統在信創大資料平台上的實踐

圖1 大資料重要作用

證券行業大部分資料來自交易系統,其中有99%以上為曆史資料。根據iiMedia Research資料顯示,中國證券類APP使用者規模穩定增長,從2015年到2020年,每年增長率都超過15%,其中2016年和2017年甚至超過了30%。到2020年,中國證券APP裝機數量已經達到驚人的1.29億。

「交易技術前沿」全曆史資料服務系統在信創大資料平台上的實踐

圖2 中國證券類APP裝機規模

另一方面,根據中國人民銀行資料顯示,2015-2019年大陸股票市場的成交量以及成交額均呈波動變化态勢。其中2019年大陸股票市場成交量達到126624.29億股,成交金額為1274159億元;由于受到2020年全球疫情的影響以及美國股票市場熔斷事件的影響,大陸股票市場也有所動蕩,2020年1-5月,大陸股票市場的成交量為65560.33億股,成交金額為744340億元。在證券行業數字化轉型的大背景下,利用海量曆史資料提升客戶服務價值已經成為頭部券商競相争奪的技術高地。而随着中國證券交易客戶規模的不斷增長,交易系統資料成級數增加,傳統解決方案中的資料不全、資料标準不統一、系統性能無法保障等問題成為了曆史資料服務能力的瓶頸。面對這些傳統解決方案提出的挑戰,公司提出了一套用信創大資料技術實作全曆史資料服務的解決方案。

2、基于信創大資料技術的全曆史資料服務系統實作

目前國際形勢風雲變幻,國家深化改革進入新階段。關鍵技術是創新發展的國之重器,自主可控計算機發展的必要性、重要性和緊迫性不言而喻,自主可控事業仍是任重而道遠。資訊安全、自主可控已上升為國家戰略,在國家政策引導和有關部門的強力推動下,大陸近年來在自主可控計算機基礎軟硬體研發、應用及生态鍊建設等方面已初見成效。作為大型國有頭部券商,公司上司在建構全曆史資料服務系統過程中,充分考慮到國産化需求,要求從硬體到軟體的各技術選型完全國産化。

2.1. 信創基礎軟硬體技術選型依據

國産伺服器主要名額在CPU,從CPU的穩定性、性能、适配性等方面,我們對基于ARM體系架構的鲲鵬、飛騰晶片和基于X86體系架構的海光晶片進行了适配性測試。

表1 ARM和X86體系架構的比較

「交易技術前沿」全曆史資料服務系統在信創大資料平台上的實踐

在硬體方面,我們選擇基于ARM架構的鲲鵬處理器系列伺服器作為大資料平台的基礎環境,這樣能有效利用CPU多核和并行計算的優勢;選擇基于X86架構的海光處理器系列伺服器作為資料庫和中間件應用的基礎環境。

作業系統方面,我們測試了麒麟、統信以及歐拉系統,從各系統的應用特點,最後選擇麒麟V10系統。

2.2. 信創大資料技術的選擇

近年來,大資料和雲計算在金融行業的發展如火如荼,在區塊鍊、高性能計算、人工智能、金融工程等前沿技術領域也在不斷的探索。HADOOP生态經過多年積累,在分布式存儲和分布式計算方面已經非常成熟,在網際網路行業已經有PB級資料存儲和處理場景落地。是以全曆史資料系統着重實作從傳統交易架構系統到大資料架構的轉型,實作多資料源、多類型資料采集、加工、處理最終建設客戶交易全曆史資料倉庫,為後續公司營運以及客戶服務提供便捷的資料支援。

2.2.1. 資料倉庫解決方案

HADOOP是一種開源的分布式檔案存儲解決方案,國内的分布式存儲(HDFS)和分布式計算(MR)具有高可靠性、高擴充性、高容錯性和高效性等特點。高可靠性展現在HDFS會維護多個副本資料,是以對于大于一個或者幾個存儲單元出現故障也不會導緻資料丢失;高擴充性展現在HADOOP天然具備橫向擴充能力,可以很友善的擴充數以千計的節點;高容錯性展現在HADOOP可以自動将失敗的任務重新配置設定或者丢失節點上的資料重新均衡;高效性主要是指HADOOP在MapReduce的思想下,計算是在叢集各節點上并行工作的特點,提升吞吐量和批量計算的效率。

HIVE是基于HADOOP建構的一套分布式資料倉庫系統,它将HADOOP分布式檔案系統(HDFS)中的資料映射成一張資料庫表,并提供完整的SQL功能。HIVE還可以外鍊HBASE和ES生成HIVE外部表,可以通過HIVE SQL對HBASE和ES中的資料進行操作。對于全曆史項目将五大交易系統的資料從傳統關系型資料庫抽取到HDFS,使用HIVE SQL實作資料的清洗轉換,結合自主研發的排程工具實作無人工幹預或者少量人工幹預的自動化客戶全曆史資料倉庫搭建。

2.2.2. 客戶服務解決方案

在客戶全曆史資料倉庫的基礎上選擇對高并發、高效查詢的支援比較好的額元件為客戶提供查詢服務,比如REDIS、ES(ELASTICSEARCH)、HBASE等。由于全曆史資料量大,REDIS這種基于記憶體的KV資料庫被舍棄,HBASE和ES在資料量和查詢效率方面都有不錯的表現。HBASE是基于KV的列式資料庫,它專注于ROWKEY範圍查詢,各類業務設計都要圍繞ROWKEY開展。HBASE使用中業務和ROWKEY具有較高的耦合性,但是對于賬單類、流水類業務有較好的支援,因為這類查詢本質上是一種簡單的ROWKEY範圍查詢。對于複雜的多列查詢HABSE存在明顯不足,為了保證查詢效率,我們選擇了ES。它是基于Lucene反向索引的搜尋和分析引擎,存入ES中的資料預設會為每個字段建立索引,可以輕松實作高性能複雜聚合查詢。ES支援全文檢索,對于中文也有很好的支援,像按照股票名稱這種模糊比對,ES都可以勝任。是以ES可以用在客戶全曆史資料服務查詢,比如成交、委托或者持倉明細等查詢服務中。基于以上分析,全曆史客戶服務采用HBASE+ES的解決方案,ES提供資料的多元度搜尋查詢服務,HBASE提供賬單類相對固定的資料查詢服務。

2.2.3. 信創解決方案

針對開源的HADOOP生态系統的信創解決方案,中信建投選擇騰訊大資料處理套件(Tencent Big Data Suite,TBDS),其内部封裝了HDFS、HIVE、HBASE等元件。TBDS大資料套件在中信建投采用基于ARM架構華為泰山200伺服器的私有化部署方式,為公司内部信創系統提供分布式計算和存儲服務。對于ES的信創解決方案,由于目前國内尚未有類似于ES的成熟商業産品,而ES本身又是開源軟體,滿足信創要求是以被直接使用。在中信建投ES同樣部署在基于ARM的華為泰山200伺服器中,為公司内部信創系統提供搜尋引擎服務。

2.3. 信創資料庫和中間件的選擇

國産資料庫技術近年來蓬勃發展,資料庫産品百花齊放。根據全曆史資料服務系統的應用場景,我們選擇了如下幾個OLTP資料庫進行對比測試。

表2 國産資料庫比較

「交易技術前沿」全曆史資料服務系統在信創大資料平台上的實踐

考慮到相容MySQL文法以及未來上雲及可擴充等方面的需求,我們選擇了騰訊TDSQL for MySQL資料庫。

在中間件方面,全曆史資料服務系統的綜合管理子產品、資料加工引擎和資料服務引擎為JAVA語言實作,采用OpenJDK(GPL許可的Java平台的開源化實作)編譯,并且運作在國産中間件上。東方通和寶蘭德作為兩大國産中間件廠商,都能很好的相容Tomcat上的Java應用,在實作Web接口類的背景調用功能方面表現不相伯仲,隻是在一些實作細節上存在少許差異。目前系統選擇了寶蘭德中間件。

2.4. 全曆史信創技術架構

全曆史整體架構包含交易資料源、自研ETL工具、騰訊大資料平台、開源元件和接口服務五部分組成,除交易資料源外其餘均部署在信創服務上,且滿足信創的标準和要求。架構如圖3所示。

圖3全曆史資料服務系統架構(制勝平台為公司的服務中台)

圖中ETL服務為基于OPENJDK的自研工具,提供任務排程和任務監控等服務;騰訊大資料套件,提供基礎存儲和計算能力;開源元件主要是ES和HBASE,為資料查詢服務提供支援;接口服務,通過寶蘭德中間件對接公司服務中台,為APP提供服務。

2.5. 全曆史資料服務系統實作

為了保證投資者做交易的時效性,交易系統通過分離當日和曆史資料來降低每筆交易的資料計算量。即每天将委托流水、成交流水,登入日志等資料歸檔到曆史資料庫。傳統的曆史資料庫存放到關系型資料庫中,通常會保留一到兩年的資料,為投資者提供曆史交易查詢服務。

随着投資者專業能力的提升,尤其是機構投資者比例的不斷增加,客戶對曆史資料查詢提出新的需求,如希望檢視近十年的交易行為、檢視某隻股票自持倉以來的盈虧情況、檢視曆史上某個時間點的資産情況等,在傳統的系統架構下實作這些需求存在着明顯的不足。利用大資料技術,我們設計了一套全曆史資料服務系統,該系統可以較好的解決這些問題。

全曆史資料服務系統由交易資料源、系統綜合管理子產品、資料存儲引擎、資料加工引擎和資料服務引擎五個部分組成,每個部分通過接口調用實作資料交換,如下圖所示。

「交易技術前沿」全曆史資料服務系統在信創大資料平台上的實踐

圖4 全曆史資料服務系統實作

2.5.1. 交易資料源

交易資料源指AB股、兩融、股票期權、場外交易、貴金屬等交易系統和賬戶系統等,全曆史資料服務系統每日從交易資料源擷取資料。交易資料源通常為傳統資料庫,資料擷取通過ETL作業完成。為了提升ETL效率,可以利用BCP、SQLULDR2、SSIS、SQOOP等工具完成。由于大資料平台的資料導入都是資料塊級的操作,比傳統關系型資料庫的插入操作效率提升50%以上。而利用大資料系統導入資料可以覆寫之前導入的資料的特性,遇到由于日終清算問題導緻的重新清算的情況時,重新導入資料的時間會大大縮短,進而将為客戶提供資料服務的時間點提前。

2.5.2. 系統綜合管理子產品

全曆史資料服務系統一個重要的組成部分是系統綜合管理子產品,它儲存了系統的所有中繼資料,包括ETL資料模型、使用者與鑒權資料、系統基礎配置參數、任務排程資料等。通過維護和管理這些中繼資料,可以確定系統運作的可靠性。

2.5.3. 資料存儲引擎

資料存儲引擎主要是指HIVE分布式資料倉庫系統、ES存儲系統、HBASE資料庫等。首先通過業務資料分析、資料類型整理、資料彙總等方法,把各種業務類型的資料标準化并在HIVE系統中建立相應的表格。這些表格從邏輯上又分為ODS(Operational Data Store)層和DW(Data Warehouse)層。ODS表格中存放當日或近期資料,DW層存放全曆史資料。資料裝載過程是從交易資料源中抽取的資料先導入到HIVE系統的ODS表格中,每日清算成功完成後,做為增量資料複制到DW表格中。由于HIVE系統的分布式存儲和橫向擴充特性,可以在不降低性能的情況下存放海量資料。目前公司交易系統10年的曆史資料上百TB,使用HIVE作為存儲引擎可以支撐未來幾十年的資料增長。

存放到ODS中的資料再根據業務需求,通過邏輯運算,将資料加工并增量加載到ES和HBASE中供使用者查詢調用,由于隻計算當日的業務資料,整個過程可以減少運算壓力,縮短資料提供服務的時間。另外,作為DM(Data Mart)存儲引擎的ES和HBASE可為使用者提供靈活、高并發、低延遲的資料查詢服務。

2.5.4. 資料加工引擎

不管從上述的ODS層導入資料到DW層,還是從ODS層導入到DM層,都需要利用并行排程來提升系統的計算效率。資料加工引擎利用大資料平台分布式并行運算和高吞吐量的特點,使用HIVE SQL等計算語言完成全曆史資料的加工。利用算法和排程,在不影響使用者通路已有資料的情況下完成每日增量資料的處理,通過獨立計算單元實作與交易系統的解耦,進而在交易系統無感覺的情況下高效完成曆史資料的整合。

2.5.5. 資料服務引擎

全曆史資料服務系統通過資料服務引擎和下遊資料使用系統對接。該引擎利用HIVE、ES、HBASE提供的服務接口,根據使用者需求提供比對的業務資料。如使用者的資料挖掘、客戶畫像、因子分析等需求可以直接利用HIVE平台高性能計算的特點擷取結果,而全曆史資料流水查詢等需求可以通過對ES和HBASE調用傳回。通過提供規範的資料結果,資料服務引擎可以友善的對接公司資料中台、服務中台等應用。

3、全曆史資料服務系統階段性成果展示

3.1. 系統上線運作效果

系統上線運作後,各業務系統曆史資料的存儲方式、加工計算、提供服務實作了标準化和統一管理,完成了各類業務曆史資料的整合。曆史資料處理效率和曆史資料查詢效率兩方面都能得到保障。

3.1.1. 曆史資料采集方面

根據交易資料源資料準備就緒的特點,全曆史系統資料采集分為閉市采集、清算後采集兩個階段,每個階段的采集任務基本能在半小時内完成,随即能提供資料查詢服務。對比于傳統曆史資料每日在清算完成後的采集方案,曆史資料提供查詢服務的時間有了明顯提升。其中資料歸檔速度提升了50%,曆史資料每日提供服務準備就緒時點提前了兩個小時。下圖為資料處理效率對比圖。

圖5 全曆史資料系統與傳統曆史資料系統采集資料效率對比

3.1.2. 曆史資料調用方面

全曆史資料調用性能方面的情況比較複雜,ES和HBASE這種解決方案相較于傳統的關系型資料庫,涉及到資料量、時間跨度、伺服器配置、調用方式等因素都不相同。經過生産實際驗證,在查詢資料量較小(通常在伺服器記憶體容量的50%以下)、存在邏輯運算(比如多表關聯)的情況下,傳統關系型資料庫有着性能方面的優勢;當查詢資料量超過單台伺服器記憶體容量的50%後,ES和HBASE的性能優勢就能顯現出來,從并發、吞吐量和響應延遲方面都好于傳統的關系型資料庫。究其原因,是因為ES和HBASE等都是基于多台伺服器的分布式計算解決方案,利用多台伺服器資源提升查詢性能。另外,ES和HBASE的橫向擴充性可以很好的解決資料量不斷增大的問題,根據實際使用情況看,擴容節點對于資料查詢調用的性能基本沒有影響。

3.2. 系統應用效果

全曆史資料服務系統可以提供10年以上的曆史資料的高性能查詢服務,使很多新穎的業務需求得以實作。

3.2.1. 全曆史流水查詢

全曆史資料服務系統最直接的應用就是全曆史流水查詢,傳統曆史資料系統一般隻能提供一到兩年内的流水查詢服務,遠期曆史資料查詢需要到現場臨櫃導出。有了全曆史資料服務系統,使用者可以直接在手機APP等用戶端直接查詢全部委托、成交、打新中簽、登入等流水情況。

「交易技術前沿」全曆史資料服務系統在信創大資料平台上的實踐

圖6 全曆史流水查詢界面舉例

3.2.2. 清倉股票查詢

該功能的靈感來自于投資者的實際需求:如何快速了解自己投資的某隻股票的盈虧情況?有了全曆史交易資料,我們可以從多個角度分析一隻股票。如它的建倉時點,建倉股價;後續的買入和賣出時點及股價;直到清倉的時點和股價。通過整個過程的買入賣出資産運算,還能得出該隻股票從建倉到清倉整個投資生命周期的盈虧情況,進而對後續的投資行為起到指導作用。

「交易技術前沿」全曆史資料服務系統在信創大資料平台上的實踐

圖7 清倉股票應用示例

3.2.3. 行情買賣點查詢

為了友善投資者對其操作進行直覺高效的複盤,可以在日K線圖上添加曆史買賣點的标記,如B代表買入,S代表賣出,T代表既有買入又有賣出。對于某一交易日内的同類操作标注“成交均價”和“成交量”資訊。可以根據交易資料特點設計标記的位置,如買入(賣出)均價小于收盤價時标記在K線下方,買入(賣出)均價大于收盤價時标記在K線上方。當點選次級視窗下方的交易明細時,可以直接跳轉至該股當日交易明細界面,顯示内容包括操作、時間、價格等。應用效果可以參看下圖。

圖8 行情買賣點應用示例

4、總結

“以史為鑒知興替,以史正人明得失,以史化風濁清揚”,我們從曆史資料中獲得的不僅僅是經驗和教訓,更是對未來的預測,進而找到發展的動力和前進的方向。本文從曆史資料重要性出發,介紹了證券行業曆史資料在傳統系統架構下的應用現狀,進而提出一套利用信創大資料技術實作全曆史資料服務系統的解決方案。該方案的特點是全面國産化,包括伺服器、作業系統、資料庫、中間件以及大資料平台各方面。在系統實作方面,本文闡述了如何實作全曆史資料的标準化整合、海量資料存儲、高效資料查詢服務等。通過某證券公司全曆史資料服務系統的實踐,對系統上線後的運作和應用效果進行了說明。

從系統實踐的階段性效果來看,基于信創大資料技術實作的全曆史資料系統是成功的。一方面它解決了傳統系統架構下一些固有的問題,另一方面目前提供的功能都得到了業務人員和投資者的好評。可以預見的是,全國産化的曆史資料查詢服務不但可以滿足很多短期曆史資料服務無法響應的即時查詢需求,而且在一些機器學習的應用方面,如多元度分析、模型驗證、模型優化等起到重要的作用。在證券行業追求精細化服務、個性化服務、創新性服務的時代,全曆史資料服務系統的實作一定能給廣大從業人員提供新思路,帶來新價值。

作者:肖鋼、李劍戈、王岐、高森 中信建投證券股份有限公司 資訊技術部 北京

來源:微信公衆号:上交所技術服務

出處:https://mp.weixin.qq.com/s/YpC0-OofL28L5mivP8yFkw

繼續閱讀