作者:
必备知识 – 必须对什么是实时 Streaming 数据有基本了解。
关于如何使用实时 Streaming 数据,Refinitiv 提供了若干选择:从最低级的超高性能传输层 API 到以 Python 和 C# 的形式提供的最高级的帮助程序库(即将在 TypeScript 中提供)。
使用下面的决策树结合在此包含的备注,将有助于您逐步确定符合您要求的最佳候选项。
Primary Factor (首要决定因素)
基于我自己与各种客户单位开发人员打交道的经验,首要决定因素通常是如下的一个因素:
- Performance (性能) – 实现要达到的性能高/非常高,如要求每秒进行数以千计(十万计)的实时更新,或对于算法交易要求可能达到的延迟最低
- Language (语言) – 开发团队受他们能够使用的语言所限
Performance (性能)
由上图可见,因素之间不一定互相冲突,例如:您要求最高的性能,且能够用 Java/C++ 或 C 进行编码,则所有路径都将指向构成 Refinitiv 实时 SDK (RT-SDK) 的 Enterprise API。
相反,对于像算法交易这样的专用情形(要求可能达到的延迟最低) ,路径将指向唯一的选择:Enterprise Transport API (ETA)
- 开源、性能最高、延迟最低,是 Refinitiv 实时 SDK 的基石
- 生成的应用吞吐量最高、延迟最低、内存占用率低、CPU 占用率低
- 提供了 C 和 Java 版
Language (语言)
如果绝对性能不是首要考虑因素,则在语言和API/库选择方面您可进行多种选择。
如果您能够用 Java 或 C++ 进行编码,则 Enterprise Message API (EMA) 可能是最佳选择,因为:
- 开源、数据中性化, 多线程、API 易于使用(用作 ETA 的 wrapper)
- 提供的高性能可适用于 95% 的使用情形
但如果您选择的语言是 .NET、Python 或 Typescript,则您可进行如下选择:
- Websocket API – 基于标准的原始 Websocket 接口访问实时数据
- Refinitiv Data (RD) Library –适用于 Websocket API 的高级易用 wrapper
相比原始 Websocket,RD Library 能够处理包括登录、身份验证和连接管理在内的各种管理任务。
注 关于 RD Library:
- RD Library 由 RDP Library 重新设计并重命名 而来,Alpha 版本的 RDP Library 仍然支持 Python 和 .NET 语言
- Beta 版本的 RD Library 目前支持 Python 和 .NET 语言
- 支持 Typescript 语言的 RD Library 预计在 2022 年 1 季度末推出
对于其他任何支持标准 Websocket 创建和 JSON 数据解析的语言,可使用上述原始 Websocket API。
尽管使用 Websocket API 需要开发人员处理如登录、连接管理及项恢复等任务,我们会提供以若干语言处理这些任务的基本示例。
与旧式 API 的性能比较
API | 线程安全性 | 吞吐量 | 延迟 | 内存占用率 |
---|---|---|---|---|
Transport API | Thread-Safe 且 Thread-Aware | 非常高 | 最低 | 最低 |
Message API | Thread-Safe 且 Thread-Aware | 高 | 低 | 低 |
RFA | Thread-Safe 且 Thread-Aware | 高 | 低 | 中等 |
SFC C++ SFC Java (JSFC) |
无 | 中等 | 高 | 中~高 |
WebSocket API | * | * | * | * |
* 使用 Websocket API 获得的性能如何,在相当程度上取决于使用的编程语言、Websocket Library 等因素。
数据格式
Enterprise Transport API 和 Enterprise Message API 在应用层都使用我们的 Open Message Model (开放消息模型,OMM) ,在传输层使用二进制 Refinitiv Wire Format (RWF)。
OMM 提供的数据构建块有点像‘乐高积木’ ,但对于数据您可使用这种‘乐高积木’ 构建丰富的数据模型,来表示像完整深度的挂盘册或收益率曲线等数据。这与我们的旧式 API 使用的扁平‘字段-值’对表示形成了鲜明对比。
RWF 使用二进制编码优化了网络分发 – 缩小的消息尺寸使总吞吐量得到提升,总延迟得到改善。这又一次与旧式 MarketFeed 格式使用的带分隔符的基于 ASCII 的表示形成对比。
Websocket API 和 RDP Library 使用肉眼可读的 JSON 格式发出传出请求和传入响应消息。
连接性
API/Library |
部署的服务器 (RTDS) |
云 |
Desktop |
---|---|---|---|
Transport API |
X |
X |
|
Message API |
X |
X | |
RD Library |
X |
X | X |
WebSocket API |
X |
X |
至于连接性,所有上述 API/Library 都可处理来自我们基于云的实时服务(如 Real-Time Optimized) 和来自您部署的 Refinitiv Real-Time Distribution System (Refinitiv 实时分发系统,以前称为 TREP) 的实时数据。
此外,RD Library 还可连接到同一计算机上运行的 Eikon 或 Refinitiv Workspace 应用的实例。
数据提供
如果您希望用您的应用执行 Contribution (报价/数据提供,也称为Inserting/Posting) ,则我们提供了以下选择:
API | 部署的服务器 (ADS) | 云 (Refinitiv Contribution Channel) |
Transport API | X | X |
Message API | X | X |
WebSocket API | X | X |
上述三种 API 都可通过您部署的 ADS 服务器或直接安全地通过 Internet 向 Refinitiv Contribution Channel 提供数据。
数据发布
API | 交互式提供商 (托管发布商) | 非交互式提供商 (非托管发布商) |
Transport API | X | X |
Message API | X | X |
WebSocket API | X* |
*即将支持
后续步骤 / 延伸阅读
您大致清楚了选择哪种 API 之后,请参阅本文 右上角 提供的其他教程的文章链接。
如果您担心性能特征及某一 API 是否符合您的要求,则最佳选择是使用自己的典型数据域、以自己的环境运行一些性能测试,从而获得有关可以预期何种实际性能的提示。
RT-SDK 包含了适用于 ETA 和 EMA 的性能测试实用工具的源代码 - 位于相应 API 各自的 PerfTools 文件夹。以这些示例作为基础,编写您希望执行的任何测试实用工具,会使编写任务轻松一些。
至于 Websocket API,您可能会认为我的 Python Websocket TestClient 示例有帮助 – 它可用作您希望创建的任何测试脚本的起点。还有一个类似的 RDP Python Library 示例。
使用 Docker Image / AWS EC2 测试
您可能从上面的链接区域注意到,我们已经提供了适用于 RT-SDK 和 Websocket API 的 Docker Image。此外,我们还提供了包含 RT-SDK 和 Websocket API 的 AWS AMI。希望这可使您在尝试各种 API 时更加轻松。
结论
如本文所述,我们提供的各种 API 可用于处理实时 Streaming 数据,您具体选择哪种将取决于各种因素 – 我希望在本文中已进行了很好的剖析。但是,如果您的确需要得到进一步指导,请尽管在我们的 开发者论坛 中提出您的质询/关切,或与您的 Refinitiv 客户代表联系,以为您安排进一步的讨论。