在设计量化交易框架时，数据频率是最重要的考虑因素之一。它将影响有关数据存储、回测策略和执行算法的每个设计。更高频率的策略可能会导致策略更具统计学意义的分析，但是高频数据需要大量的时间和资金投入来开发必要的软件来实现它们。

低频策略更易于开发和部署，因为它们需要较少的自动化。但是，与高频策略相比，可能会导致分析的统计性较差。

典型数据频率包括：

1、 tick和挂单数据，每秒2次

2、 日内Bars数据，分钟线数据

3、 每日数据

4、 每周、每月数据

附：什么是tick数据：

举例说明：

某天的市场一开始的时候苹果股票的order book（委托挂单）清空（这里不进行auction period的探讨）：

1. 接着来了第一个卖家：1000@100 :

这时候交易所会发给你一个message，告诉你是苹果股票有人想以100块钱卖出1000股，那么这个order就先挂在了order book上，成为卖一。

卖：1000@100

2. 第二个卖家来了，他想卖得更高： 1000@101:

这时候交易所会发给你另一个message，告诉你是苹果股票有人卖的价格比你差，于是排序在更上面，卖二。

卖：1000@101

1000@100

3. 刚才的第一个卖家后悔了，cancel了他的order：1000@100撤消了，那么交易所会有message告诉你，现在只剩一个1000@101（卖一）。但是你可能需要自己编程处理这种remove掉一个tick的情况。

卖：1000@101

4. 终于有买家来了... 500@90 , 这个价格是不会成交的，因为买家低于现在的最佳卖价：101，那么order book里面会继续存着这个order，同时会发送一个tick告诉市场上的其他人，有买单了：

卖：1000@101

买：500@90

5. 继续，接着有一位买家以101块钱买入1000股，等于要把目前的bestoffer 1000@101给match - 撮合了，那么你是不会收到这个最新的bid： 101@1000 的，因为它会进入matching engine的瞬间跟对面的best offer 撮合了，tick table的一个规则： bid offer 永远不会cross，否则要么是数据商的bug，要么是交易所的bug。现在，你只会收到一个告诉你delete the best offer的message，那么tick table长这样：

买：500@90

Tick数据就是这么简单，市场上会重复这个过程。

但是比较麻烦的是：

1.很多时候tick的数据会以UDP发送，想象股市上如果交易非常活跃，那么数据量会非常大，UDP会存在丢包情况，如何处理。曾经遇到过很疯狂的tick update但是还要保持在micro second的更新cache，可能要排序（看交易所protocol），以及发送出去给前端。

2.如何更快的处理实时的tick数据，否则数据量如此大，一旦延迟，以后就再也跟不上“实时”的节奏了，直到你的程序挂掉。

3.如何避免一些特殊情况造成bug，一旦一个tick没有算对，那么后面的tick table全是错的：）

同样，还有对tick的理解问题：不同市场的tick还有不同点，上面所说的是发达国家的股票市场，以实时情况**（有新的order并且在tick的发送level以内，比如东京交易所只发送8个tick level，那么你看不到整个full tick的，因为可能会有100多个level，如果很多人交易的话）。

国内期交所是多少个milli second截取一个快照（snapshot），上交所深交所是3秒，然后发送给你，兴许是国内交易系统已经非常古老，跟不上IT的发展了。那么这个tick数据并不是“real time”的，你只知道“哦！在前100 millisecond和现在的tick 变化是这样的”，可能中间已经成交了数千单。