交易技术前沿全历史数据服务系统在信创大数据平台上的实践

　　肖钢、李剑戈、王岐、高森
　　中信建投证券股份有限公司 信息技术部 北京
　　邮箱：wangqixx@csc.com.cn
　　在证券行业数字化转型的大背景下，利用海量历史数据提升客户服务价值已经成为头部券商竞相争夺的技术高地。随着中国证券交易客户规模的不断增长，交易系统数据成级数增加，传统解决方案中的数据不全、数据标准不统一、系统性能无法保障等问题成为了历史数据服务能力的瓶颈。本文从介绍历史数据的重要性入手，首先对证券行业传统历史数据使用现状进行了分析，进而提出一套基于全国产化技术的大数据平台解决方案。从数据治理、系统架构、国产化硬件选型、国产化软件选型、全国产化系统的应用效果几个方面介绍了某全历史数据服务系统的实现，并提出了对该系统的后续规划和展望。
　　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