前面用Pandas做数据准备的文章中提高了金融行业的高频数据的问题，因为比较复杂，所以但开一篇文章来解释一下。
以下内容都是针对数据分析入门的小白们的，金融大咖们请该干嘛干嘛去，不用往下看。
目前，国内金融高频数据的几个特点：
- 切片数据，非实时Order Book
- 增量数据
不过，不久后中金所会开始推送Order Book了，慢慢的商品期货也会普及，但是这种特点的数据别的领域也会遇到，所以不妨拿来做个案例。
注意：本文章不涉及任何策略开发方面的内容，想了解策略开发的同学请绕道吧。
首先，介绍一下高频数据的生命周期：
- 为了避免高并发带来的服务器端压力，交易所的高频数据通常会采用UDP广播方式进行推送，而不是非高频接口的TCP客户端请求响应的这种模式。
- 高频数据都是交易方向交易所付费购买的数据，所以这些数据与传统数据不同，是不经过经济商的柜台的。想要接收高频数据，需要与交易所指定的网络联通，通常都采用服务器托管到交易所指定的机房的方式。因此，高频数据会由一台我们自己的服务器进行接收。
- 为了保证策略的效率，因此在接收数据的时候也是分秒必争，通常采用直接从网卡对数据包直接进行解析，将解析出来的数据直接转发给应用层供策略使用。所以，策略层实际上不可能真正拿到完整的切片数据，每次拿到的都是一条一条单独的行情。
- 购买的高频数据不光用语高频交易，对后期的策略开发、研究都非常有用，所以这部分数据是需要进行存储的，通常会设计一个数据结构，其中会包括交易所的时间切片信息和本地服务器接收到每条行情数据的微秒时间信息。
- 由于是高频数据，每天的数据量都巨大，如果dump成csv格式，以郑商所为例，每天的数据接近1GB，这还只是增量数据。而且根据交易所的协议，这些数据是不允许出机房的，而且机房的托管成本非常高，资源也非常有限，我们不可能在托管机房搭建一个大规模的计算集群，数据的存储和计算都要尽量的高效，我建议这部分数据我们用一个时序数据库进行存储。
为什么选择时序数据库？
- 我们的交易数据全部都是时间序列相关的，后期的分析也通常会以时间为基础维度。
- 时序数据库对时间序列类的数据存储有底层的优化，会比较节省存储空间。
- 时序数据库对于基于时间序列的查询和聚合计算有着非常非常大的优势。（前提是你做了恰当的索引）
接下来，我们会遇到那些问题：
- 任何一个合约的数据理论上都是不连续的，因为交易所为我们推送的是增量行情，只有在时间切片内发生过交易的合约才会有数据，否则就没有。
- 时序数据库的默认索引是时间戳，交易所因为提供的是切片数据，所以按照交易所的数据时间，每一个时间点需要存储多个合约行情，这种数据存储的结构不利于分析。
首先，解决不连续的问题，很自然想到的就是数据补齐。根据业务场景，如果在当前的t时间下没有我们需要的A合约的数据，那么说明此时A合约的价格没有发生任何变化，我们应该继承上一个时间切片的数据。实际上，在高频数据中，如果是成交量不大的合约，也许连续很多个tick你都看不到数据，那么就为我们的数据补全带来了非常大的挑战。这里我提供两个实现补全的思路：
- 在自己的程序中进行补全，利用简单的for循环嵌套，本地模拟一个order book出来，每次收到新的行情都去更新这个order book。然后再用另一个程序去读这个order book，把请求到的数据储存起来。这样实际上是用推送的行情数据本地模拟成了主动请求的方式，进一步实现了数据的补全。这种方式适合在真正的策略中使用。
- 利用时序数据库的内置函数。以InfluxDB为例，可以在查询语句中加入fill(previous)函数来解决这个问题。
数据不连续其实在物联网场景中更为普遍，因此fill函数会经常用到，它还有以下的集中填充方法：
- 固定值
- linear 意思就是根据前后的值填充一个符合线性变化的值，比较高级。
- none
- null
- previous
时序数据库选型，如果是个人或者小团队自己研究用，强烈推荐InfluxDB的免费版，大规模如果不差钱的话当然推荐InfluxDB的商业版，原因很简单——不折腾！
好了，由于时间关系，要赶日更的时间，没有配代码，如果后面有时间且有需要的话，我可以把一些关键代码分享出来。
最后，按照国际惯例，看没看懂都点个赞再走呗：）⬇️
网友评论