2. 数据源分类与特征:交易所数据、第三方数据、内部数据

做金融数据接入,第一件事就是搞清楚:数据到底从哪来?

我个人习惯把数据源分成三大类。这不是教科书上的标准分类,而是我在实战中摸爬滚打总结出来的。你想想看,不同来源的数据,格式、频率、可靠性天差地别。如果不先分清楚,后面接入的时候会踩很多坑。

2.1 交易所数据:行情与交易

交易所数据,说白了就是最硬核的市场数据。这类数据的特点是:高频、结构化、权威性高

2.1.1 行情数据

行情数据包括实时快照、逐笔成交、Level-2 数据等。我在项目中遇到过最头疼的问题——行情数据延迟。毫秒级的延迟,在量化交易里可能就是盈亏的分水岭。

核心特征:
  • 频率高:毫秒甚至微秒级推送
  • 数据量大:单日全市场行情可达 TB 级别
  • 时序性强:必须按时间顺序处理

举个例子,上交所的行情快照是 3 秒一张。但深交所是 1 秒一张。嗯,这里要注意:不同交易所的推送频率不一样,接入时得单独配置。

2.1.2 交易数据

交易数据包括委托、成交、撤单等。这类数据比行情更敏感,因为它涉及资金和持仓。

避坑指南: 我曾经在接入某期货交易所的交易数据时,发现它的委托编号是全局递增的,但上交所的委托编号是按席位重置的。如果不做归一化处理,后续的订单链路追踪会完全乱掉。
数据子类 典型字段 更新频率
实时行情 最新价、涨跌幅、成交量 毫秒级
逐笔成交 成交价、成交量、买卖方向 事件驱动
委托队列 委托价、委托量、委托编号 实时推送

2.2 第三方数据:新闻、舆情与财务

第三方数据,说白了就是「非交易所官方」的数据。这类数据的特点是:非结构化、来源杂、价值密度低

2.2.1 新闻与舆情数据

新闻数据包括财经快讯、公司公告、社交媒体舆情等。我建议做舆情接入时,一定要做去重和时效性校验。为什么?因为同一篇新闻可能会被多个源重复推送,而且有些新闻的发布时间是错的。

我的经验: 接入新闻数据时,最好保留原始时间戳和来源标识。我曾经因为没做时间对齐,导致舆情因子回测结果完全失真——后来才发现是新闻时间戳被中间层篡改了。

2.2.2 财务数据

财务数据包括季报、年报、业绩预告等。这类数据更新频率低,但数据质量参差不齐。有的数据商提供的财务数据已经做了标准化处理,有的则是直接从 PDF 里 OCR 出来的——嗯,你懂的,OCR 出来的数据经常有错。

  • 结构化财务数据:直接可用的表格数据
  • 半结构化财务数据:如 PDF 公告,需要解析
  • 非结构化财务数据:如管理层讨论,需要 NLP 处理

2.3 内部数据:风控与交易记录

内部数据是公司自己产生的数据。这类数据的特点是:隐私性强、格式自定义、与业务深度绑定

2.3.1 风控数据

风控数据包括持仓限额、资金流水、风险指标等。我个人习惯把风控数据单独做一个接入通道,因为它对实时性和准确性要求极高。一旦风控数据延迟,可能导致超额交易。

我曾经踩过的坑: 某次接入风控系统的持仓数据时,发现它的更新机制是「增量推送+全量快照」。但增量推送偶尔会丢包,导致持仓数据不一致。后来我加了一个校验机制:每次收到全量快照时,与本地增量数据做交叉验证。

2.3.2 交易记录

交易记录包括历史委托、成交明细、资金变动等。这类数据通常存储在关系型数据库或日志文件中。

数据子类 存储方式 接入难点
历史委托 MySQL / Oracle 数据量大,查询慢
成交明细 Kafka / 日志文件 顺序一致性
资金流水 核心账务系统 接口协议私有

2.4 数据源分类全景图

下面这张图,是我自己画的数据源分类框架。你可以把它当作一个「数据源接入检查清单」来用。

多源异构数据源 交易所数据 第三方数据 内部数据 行情数据(快照/逐笔) 交易数据(委托/成交) 新闻舆情(文本/社交) 财务数据(季报/年报) 风控数据(限额/流水) 交易记录(历史/日志) 各数据源核心特征 交易所:高频、结构化、权威 第三方:非结构化、来源杂、价值密度低 内部数据:隐私性强、格式自定义、与业务绑定

2.5 小结

数据源分类这件事,看似简单,但做不好后面全是坑。我个人建议:在接入之前,先花一周时间做数据源摸底。搞清楚每个数据源的格式、频率、可靠性、更新机制。这一步做得越细,后面的统一接入方案就越稳。

一个小技巧: 给每个数据源打标签。比如「交易所-行情-实时」、「第三方-新闻-定时」、「内部-风控-实时」。这样在后续做数据路由和优先级调度时,一目了然。

公众号:蓝海数据掘金营,微信deep3321