TDengine 在同花顺组合管理业务中的优化实践

作者：易源博 同花顺高级工程师

前言

同花顺每天需要接收海量交易所行情数据，确保行情数据的数据准确。但由于该部分数据过于庞大，而且使用场景颇多，每天会产生很多的加工数据，而组合管理(PMS)还会使用到历史行情数据。之前虽然采用了 Postgres+LevelDB 作为数据的存储方案，但仍然有不少痛点，所以必须对存储方案进行改造。

通过对 ClickHouse、InfluxDB、TDengine 等时序数据存储方案的调研，最终我们选择了 TDengine。大数据监控平台采用 TDengine 后，在稳定性、查询性能等方面都有较大的提升。

项目背景与问题

同花顺私募之家组合管理是一个集多资产管理、实时监控、绩效分析、风险分析、舆情分控、报表输出等功能于一体的智能投资组合管理平台。为券商、基金、私募等机构客户提供实时准确的投研服务。

数据层面主要依赖实时数据及历史日级别数据，为所支持的股票、基金、债券、美股、港股、期权、期货资产类别的监控和分析提供支持。

其中，实时数据主要用于资产监控，由于使用场景会对数百个不同的标的进行资产监控，数据刷新频率在 1 秒左右。因此，整个系统对实时数据的读写性能及延时有着比较高的要求。

此外，历史日级别数据主要用于投资组合的各种分析。历史分析所涉及的标的数量，相较实时资产监控更多，在时间上的跨度会长至 10 数年。此外在输出分析报告时，还会叠加多种分析指标和分析模型。在整个分析过程中，涉及巨量的数据集。这对历史数据库的读写性能又提出了更高的要求。

由上述架构图可以看到，该服务内需要大量的基础数据支撑，像实时行情、历史行情。

针对历史行情数据支撑，涉及多个证券品种的数据，包括股票、债券、基金、港股、美股、期货、期权。数据跨度周期从数天到数年不等。页面返回的数据是计算结果，而计算依赖的数据是业务层数据和大量历史行情数据。这个计算过程包含了历史行情数据请求。尤其是在展示结果包含多证券标的和长周期的情况下，产生一个分析报告可能达到 5s，而行情获取耗时占比达到 80%以上。而且，输出报告服务面临并发情况，这种情况带来的拥堵会进一步恶化用户的使用体验。

通过对改造前的数据流进行分析，当前行情获取模块的分析， 当前存在以下 2 个需要解决的问题：

• 依赖多，稳定性较差：PMS 作为多品种的投后分析服务, 需要使用到各种日线数据、当天实时行情数据、当天分钟数据等，在数据获取方面需要依赖 Http 以及 Postgres、LevelDB 等数据库。过于多的数据获取链路会导致平台可靠性降低，同时依赖于其他各个服务，导致查询问题过于复杂。

• 性能不能满足需求： PMS 作为多品种投后分析，在算法分析层面需要大量的行情获取，而且对行情获取的性能也有较大的要求，当前所有行情会占据大量分析的性能。

技术选型

为解决上述问题，我们有必要对现有行情模块进行升级改造。在数据库选型方面，我们对如下数据库做了预研和分析：

• ClickHouse：运维成本太高，扩展过于复杂，使用的资源较多。

• InfluxDB： 可以高性能地查询与存储时序型数据，被广泛应用于存储系统的监控数据、IoT 行业的实时数据等场景；但是集群功能没有开源。

• TDengine：性能、成本、运维难度都满足，支持横向扩展，且支持高可用。

通过综合对比，我们初步选定 TDengine 作为行情模块的数据库。

主要由于行情数据是绑定时间戳的形式，所以时序数据库更适用于这个业务场景。而且在同等数据集和硬件环境下，涛思官方的测试结果显示，TDengine 的写入速度远高于 InfluxDB。同时 TDengine 支持多种数据接口，包含 C/C++、Java、Python、Go 和 RESTful 等。

数据接入过程需要进行如下操作：

• 数据清洗，剔除格式不对的数据；

• 由于历史数据过于杂乱，采取脚本生成 csv 形式并直接导入，后续增量数据由 Python 实现脚本导入数据。

数据库建模以及应用场景

TDengine 在接入数据前需要根据数据的特性设计 schema，以达到最好的性能表现。

同花顺行情根据时间频度的不同，数据特性分别如下。

通用特性:

• 数据格式固定，自带时间戳；

• 数据极少需要更新或删除；

• 数据标签列不多，而且比较固定；

• 单条数据数据量较小，字段较少。

tick 快照数据特性如下:

• 每天数据量大，超过 2000W；

• 需保留近几年数据。

daily 数据特性如下:

• 子表很多，约 20W 张表；

• 每天数据 20W；

• 需保留近 30 年数据。

根据上述特点，我们构建了如下的数据模型。

按照 TDengine 建议的数据模型，将每个特性的数据单独创建数据库，根据不同特性数据设置不同的参数，在各个数据库内根据品种去创建超级表，例如股票、指数、债券、基金等，结合我们的数据特点和使用场景，创建数据模型如下：

• 以品种类型作为超级表，方便对同一类型的数据进行聚合分析计算；

• 标的本身包括标的信息，直接将标签信息作为超级表的标签列，每个品种作为子表。

库结构如下：

超级表结构:

落地实施

组合管理主要是需要可以稳定高效地获取到数据，所以在实施的过程中需要考虑查询的性能、线上数据的更新以及运维情况。

实施难点如下。

• 数据写入：由于历史行情数据会存在大量的历史数据，不是只接收当前新增的数据，这对历史数据的迁移有很大的挑战。当前 TDengine 数据库对于现有数据的导入，通过 insert 语句达到批量更新，会导致历史数据迁移耗时很大。为了解决该问题，我们在本地建立缓存，将现有 csv 文件修改为可执行导入的形式，直接通过 csv 导入，大大提升了写入速度。在这个过程中，我们还发现了一个问题：通过 csv 导入的时候，如果采用自动创建表的方式，会在几个版本内出现崩溃。通过询问官方，他们不建议在导入 csv 的时候创建表，后来我们就拆解为先创建表结构再进行 csv 导入，问题得到了解决。

• 查询问题：查询单点问题。TDengine 原生 HTTP 查询是直接查询特定服务端完成的。这个在生产环境是存在风险的。首先，所有的查询都集中在一台服务端，容易导致单台机器过载；另外，无法保证查询服务的高可用。基于以上两点，我们在 TDengine 集群使用过程中，在应用使用创建链接的时候会配置多台 Http 的接口来解决单点问题。

• 容量规划：数据类型、数据规模对 TDengine 的性能影响比较大，每个场景最好根据自己的特性进行容量规划，影响因素包括表数量、数据长度、副本数和表活跃度等。根据这些因素调整配置参数，确保最佳性能，例如 blocks、caches 和 ratioOfQueryCores 等。根据与涛思数据工程师的沟通，我们确定了 TDengine 的容量规划计算模型。TDengine 容量规划的难点在于内存的规划。

改造效果

完成改造后，线上的行情获取性能可以达到预期，目前运行稳定。

• 改造后性能对比情况，可以看到性能提升明显。

• 改造后稳定性对比情况：改造前调用数据情况共 40W 次，共出现异常 0.01%的异常，改造后出现异常降低至 0.001%。

TDengine 问题解决

在使用 TDengine 的过程中，我们遇到了一些小问题。比如在通过 Restful 接口使用 TDengine 的时候，获取数据超过 10240 行会有限制。经过沟通，我们了解到在启动服务端时，参数restfulRowLimit 可以控制返回结果集的最大条数。

其他一些在使用过程中不清楚的地方，在涛思数据的物联网大数据微信交流群都能很快得到反馈和解答。一些小 bug 也可以通过版本升级解决。

总结

目前从大数据监控这个场景看，TDengine 在成本、性能和使用便利性方面都有非常大的优势，尤其是在节省成本方面给我们带来了很大惊喜。

在预研和项目落地过程中，涛思数据的工程师提供了专业、及时的帮助，在此表示感谢。

希望 TDengine 能够不断提升性能和稳定性，开发新特性，我们也会根据自身需求进行二次开发，向社区贡献代码。祝 TDengine 越来越好。对于 TDengine，我们也有一些期待改进的功能点：

• 支持更加丰富的 SQL 语句；

• 灰度平滑升级；

• 可实现自定义聚合方法；

• 更快的数据迁移。

后续我们也将在同花顺的更多场景中尝试应用 TDengine，包括：

• tick、minute 行情数据的迁移以及线上应用；

• 采取自定义聚合方法实现分钟行情、日线行情的聚合计算；

• 当天实时行情的数据的管理。

作者简介：

易源博，同花顺高级工程师，长期从事证券金融相关业务，负责投前回测系统、投后分析系统架构设计、开发与优化。

🌟近期taosAdapter已正式发布，支持从 OpenTSDB 等时序数据库向 TDengine 无缝迁移，欢迎阅读 TDengine 此前发布的技术文章，了解体验 taosAdapter！