港交所OMD-C对接笔记

工作中需要对接港交所OMD-C的Standard版行情，现在把一些知识点和踩过的坑记录下来，供大家参考。文中部分图片因为缩小看不清，请【右键-在新窗口/标签打开图片】查看清晰版本。

• 「香港交易所领航星」巿场数据平台—证券市场(HKEX Orion Market Data Platform – Securities Market, OMD-C), Technical Documents

1. 概述

OMD-C数据服务分为实时服务、重传服务、刷新服务三部分。

• 实时服务：UDP多播。提供挂单、成交、指数、市场状态等实时数据，以及最高价、最低价、最后成交价、成交量、等统计数据。实时服务以UDP为载体，通过多播推给接收端。消息被归类到若干通道（Channel），每个通道包含若干消息类型，比如成交消息和挂单消息都是在通道10。每个Channel的报文有唯一Sequence，Sequence总是从1开始。不同Channel之间的Sequence没有关联。为了减少丢包影响，报文都通过两个独立通道多播，比如Channel 10和Channel 510是一对，接收端根据Sequence做好去重工作。
• 重传服务：TCP请求应答。缓存每个Channel最近50,000个报文，多播丢包时，接收端指定Sequence区间，向重传服务请求丢失的报文。重传是有限制的：

  • 单Channel缓存最近消息数量：50,000

  • 单次请求Sequence范围：10,000

  • 单用户一天重传次数限制：1,000

• 刷新服务：UDP多播。定期把当前市场状态以多播方式推送给接收端，当接收端在盘中启动时，以此恢复当前全部状态，但逐笔交易等历史信息无法恢复。 

 

2. 网络拓扑

client可通过SDNet/2和HKEX机房托管（co-location at HKEX Host Data Centre (HDC)）两种方式访问OMD-C，一般选取SDNet/2方式连接。通过SDNet/2连接一般要在HKEX指定合作机房租用专线连接，路由器开启IGMPv2，并且接口速度达到1Gbps以避免突发性丢包。

SNNet/2: https://www.hkex.com.hk/chi/market/sec_tradinfra/sdnet2_c.htm

HKEX提供了一冷一热两套站点，每套站点又包含两个独立多播源和一个重传服务器，每个实时数据，都会经两个多播源各发送一次，接收端根据序列号去重。重复多播极大减少了偶然丢包的影响，经过实际运行测量，为期1年的运行周期中，访问重传服务以恢复丢包的次数为0. 

(图片来源: OMD Connectivity Guide for Securities Market & Index Datafeed Products)

3. 交易时间段

　　

随机收市是一个比较特殊的状况，HKEX可能在不同时间点发送收市指令。

　　

4. 消息序列

OMD-C Standard版推送的消息比较多，我们关心的消息如下。

4.1 参考数据 (Reference Data)

• 市场定义, Market Definiton(10)。 系统开机后会把主板、创业板、纳斯达克、连续交易市场的信息发送一遍。
• 证券定义, Security Definition(11)。 系统开机后会把所有证券信息发送一遍，包括调整后的昨日收盘价、证券类型、名字、每手多少股（LotSize），是否参与收市竞价等，如果是衍生产品，还有换股比、行权价格、到期日等信息。

4.2 状态数据 (Status Data) 

• 交易会话状态, Trading Session Status(20)。 开机、开市、休市、收市，都有相应通知，具体请参考交易状态一节。
• 个股状态, Security Status(21)。 系统开机后，会发送一遍当日所有停牌证券的信息，没有发送的就是正常。

4.3 挂单数据(Order Book Data)

• 挂单聚合更新, Aggregate Order Book Update(53)。 OMDC采用增量更新的方式把聚合后的挂单信息推送下来，这里的聚合，是指按照相同价位聚合，比如：价格$100，有3个挂单，数量分别是100股，200股，300股，OMDC会发送一个 600@100的消息，告诉接收端$100价位总共有600股挂单。 OMD-C提供买卖10档价位的挂单信息。
• 经纪队列, Broker Queue(54)。 提供了单方（买或者卖）最多40个最佳报价的经纪人ID。

4.4 交易和报价数据(Trade and Price Data) 

• 交易报价, Trade Ticker(52)。标准版数据不会把每笔交易都通知，而是把一小段时间内相同证券的连续几个相同价位成交的事件聚合为单一事件通知。比如在0.1秒之内，分别达成如下成交：
  1. 00700 200元 成交100股
  2. 00700 200元 成交200股
  3. 00100 100元 成交100股
  4. 00100 101元 成交200股
  5. 00700 200元 成交100股

那么最后输出的Trade Ticker类似于：

• 1. 00700 200元 成交300股
  2. 00100 100元 成交100股
  3. 00100 101元 成交200股
  4. 00700 200元 成交100股

交易报价只在09:00-16:10之间发送，DayClose之后不会有Trade Ticker消息。其中，09:00-09:20之间是开市前交易，包括前一个交易日达成后来不及输入系统的交易。

注意，港股成交有多种类型，其中自动对盘交易和竞价交易是最重要的，决定了一个证券的开高低收四个价格属性，其他成交只会影响成交量和成交额。

• 按盘价, Nominal Price(40)。 按盘价是根据成交价、挂单价格总和计算得到，挂单变化、成交达成、成交取消时，按盘价都可能会变化。在第一个按盘价发出之前，按盘价等于昨日收盘价。部分股票整日无交易无挂单，其按盘价就是昨日收盘价。Trade Ticker(52) 事件、Aggregate Order Book Update（52）事件、Nominal Price（40）三者的顺序是： (Nominal -> OrderBook) -> ... -> (TradeTicker -> Nominal) -> ... -> (Nominal -> OrderBook)。也就是说，如果挂单变化引起按盘价变化，HKEX总是先发送新的按盘价过来，再发送挂单事件。如果是交易达成、交易取消引起的按盘价变化，总是先发送交易事件，再发送新的按盘价。
• 收盘价, Closing Price(62)。 为了防止收盘价被操纵，收盘价并不是最后一笔成交的价格。如果证券参与了收市竞价，收盘价是收市竞价的成交价，如果没有，计算规则如下：

正常情况下，股份的收市价会按一天交易活动时段最后一分钟内五个按盘价的中位数计算。系统会由下午15:59正开始每隔十五秒记录一次股份的按盘价， 一共记录五个按盘价。
如：

五个时段的按盘价由最低至最高顺序如下：39.35，39.40，39.40，39.45，39.45，中位数（即中间的价格）是39 .40，所以收市价定于39.40 。

请特别注意：每个股票都会发送Closing Price，并且是在交易会话切换到DayClose之后才发送的。

4.5 增值数据(Value Added Data)

• 统计数据, Statistics(60)。统计报文记录了某个证券当前的成交量、成交额和权重股均价，同时可能还有最高最低和最后成交价。但是，最高最低和最后成交价也可能为0。比如，9:00，收到了Late Trade消息，此时会发送Statistics包，成交量非0，但最后成交价却是0。由于开盘价一旦产生不再变化，Statistics包不携带该字段。接收端应该处理Trade Ticker，把第一个竞价交易或者自动对盘交易的成交价作为开盘价。
• 市场成交量, Market Turnover(61)。记录了某个市场（主板、创业板、纳斯达克、持续交易）的总成交额，其中，主板的成交额最常用，我们一般不显示HSI（恒生指数）自身的成交额，而是显示主板成交额。DayClose之后，还会有Market Turnover消息到达。

4.6 指数和市场信息(Index Data and Market Information)

• 指数定义, Index Definition(70)。定义了指数的数据源，货币代码等。
• 指数数据, Index Data(71)。比如恒生指数、红筹指数，每隔2秒钟发布一次开高低收价格、成交额、涨跌幅、涨跌额。请注意：交易状态切换到DayClose后，还有Index Data发送。

4.7 消息序列图

5. 数据量

5.1 证券数量和活跃度

以5月19日为例，港交所有将近一万个证券，总市值30万亿港币， 大约分类如下：

• 2024 正股，其中主板1740，创业板284
• 6500 衍生产品，包括涡轮和牛熊证
• 1000 债券
• 180 ETF

当天共成交663,896笔， 成交额700亿港币。与此相对，A股数量大约3000只，总市值53万亿（人民币），流通市值40万亿，当日成交3500亿，比港股活跃很多。

5.2 消息类型分布及处理速度

 以5月19日数据为例，一个交易日有1650万个报文，累计1.5GB数据量。一个交易日的数据，20分钟之内可以处理完。

 

5.3  成交分布

一个交易日，共成交663,896笔， 50%以上证券一天成交不到100笔，只有不到200个证券日成交超过1000笔，其中腾讯控股（00700）最为活跃，成交16,000笔。

  

从时间分布上看，开盘后半小时和收盘前半小时较为活跃，其中又以收盘前最为活跃，1分钟完成10,863笔交易。

 

 6. 系统结构

这个项目是从零开始的，开发人员此前完全没有证券行情相关的经验，所以走了不少弯路，这里就不一一列举了。行情服务分为几大块：生产子系统、推送子系统和查询子系统。生产系统只需要开市及开市前后一段时间运行，接收OMD-C数据并整理成合适格式写入存储。推送系统和生产系统生命期相同，行情变化时推送给Client，保证实时性。查询系统要24小时可用，随时响应查询请求。

6.1 生产子系统

• Adapter：数据适配层，对接OMD-C，对UDP进行排序去重，然后以TCP流发给下游，同时做好数据DUMP。对可靠性要求非常高，承担责任比较少，只关心消息格式，不关心消息内容。
• Importer：行情导入层，对接Adapter，解析流式数据包，根据消息内容组织基本的行情逻辑，屏蔽数据源的差异性，构造一直输出给下游使用。项目后来逐渐对接了美股和A股，每个数据源都有独立的Importer，并且要求这些Importer输出逻辑一致的消息给下游，这样下游的模块可以不区分来源统一处理，简化编码和运维负担。
• 板块指数：对接不同Importer，根据深成指数规范，对行业板块、概念板块进行指数化，计算并发布。
• 实时行情：对接不同Importer和板块指数，处理港股、美股、A股等不同来源的数据并做更复杂的处理，进行数据入库，并把行情写入消息队列。
• 历史行情： 对接不同Importer和板块指数，根据挂单、成交、按盘价等信息构建分时K线、日周月K，计算MA/MACD/SAR等技术指标，入库，并写入消息队列。
• 存储：选用MySQL存储今日之前的日周月分时K之类的冷数据，Redis全内存存储实时行情和当日分时K，收市后DUMP到MySQL进行持久化。两路生产子系统，两套独立存储，可以同时对外提供查询。

6.2 推送子系统

• 实时推送：从消息队列得到行情数据，通过长连接推给订阅了相关证券的Client。
• 股价提醒：从消息队列得到行情数据，通过长连接或者离线方式推给Client。推送通道有腾讯信鸽、小米、华为、APNs几种。

6.3  查询子系统

• 查询系统目前做的比较简单，多实例提供服务，LVS负载均衡。

6.4 容灾

• 生产子系统：有独立两套，包括运算和存储都是分离的，只要有一套正常就可以。收市之后，把当天的数据用导数据方式从正常环境复制到异常环境即可。在最坏的情况下，两套生产环境都出现故障，只要最初的数据适配层正常，可以临时停服，回放数据+接收实时数据来离线重建当日行情，20分钟之内就可以追上实时行情进度。为了避免错误数据误导用户决策，重建期间是不提供服务的，直到重建完成才继续提供服务。
• 查询子系统：本身就是分布式，没有单点。需要注意的是，当某路生产系统故障时，查询系统要禁用该路存储，恢复后继续启用。
• 推送系统：和查询系统类似，稍微注意的是，它要同时消费两个生产系统的消息，所以在一个系统正常时，只用一个系统的，另一个系统的消息直接丢弃，避免重复推送。

本文为skylerjiang原创作品，转载请联系作者。