TDengine在同花顺组合管理业务中的优化实践数据库金融科技大数据物联网

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，以达到最好的性能表现。
同花顺行情根据时间频度的不同，数据特性分别如下。
通用特性:

数据格式固定，自带时间戳；
数据极少需要更新或删除；
数据标签列不多，而且比较固定；
单条数据数据量较小，字段较少。

【TDengine在同花顺组合管理业务中的优化实践】tick快照数据特性如下:

每天数据量大，超过2000W；
需保留近几年数据。

daily数据特性如下:

子表很多，约20W张表；
每天数据20W；
需保留近30年数据。

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

以品种类型作为超级表，方便对同一类型的数据进行聚合分析计算；
标的本身包括标的信息，直接将标签信息作为超级表的标签列，每个品种作为子表。

库结构如下：

文章图片

超级表结构:

文章图片

文章图片

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

数据写入：由于历史行情数据会存在大量的历史数据，不是只接收当前新增的数据，这对历史数据的迁移有很大的挑战。当前TDengine数据库对于现有数据的导入，通过insert语句达到批量更新，会导致历史数据迁移耗时很大。为了解决该问题，我们在本地建立缓存，将现有csv文件修改为可执行导入的形式，直接通过csv导入，大大提升了写入速度。在这个过程中，我们还发现了一个问题：通过csv导入的时候，如果采用自动创建表的方式，会在几个版本内出现崩溃。通过询问官方，他们不建议在导入csv的时候创建表，后来我们就拆解为先创建表结构再进行csv导入，问题得到了解决。
查询问题：查询单点问题。TDengine原生HTTP查询是直接查询特定服务端完成的。这个在生产环境是存在风险的。首先，所有的查询都集中在一台服务端，容易导致单台机器过载；另外，无法保证查询服务的高可用。基于以上两点，我们在TDengine集群使用过程中，在应用使用创建链接的时候会配置多台Http的接口来解决单点问题。
容量规划：数据类型、数据规模对TDengine的性能影响比较大，每个场景最好根据自己的特性进行容量规划，影响因素包括表数量、数据长度、副本数和表活跃度等。根据这些因素调整配置参数，确保最佳性能，例如blocks、caches和ratioOfQueryCores等。根据与涛思数据工程师的沟通，我们确定了TDengine的容量规划计算模型。TDengine容量规划的难点在于内存的规划。

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

文章图片

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

	Restful-JDBC	JNI-JDBC	改造前
单股票单天	9ms	5ms	117ms
单股票段时间1年，5年	32ms，83ms	9ms，29ms	258ms，700ms
多股票单天（8只股）	11ms	7ms	116ms
多股票段时间（8只股）1年，5年	120ms，532ms	60ms，225ms	1081ms，2492ms

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

在使用TDengine的过程中，我们遇到了一些小问题。比如在通过Restful接口使用TDengine的时候，获取数据超过10240行会有限制。经过沟通，我们了解到在启动服务端时，参数restfulRowLimit 可以控制返回结果集的最大条数。
其他一些在使用过程中不清楚的地方，在涛思数据的物联网大数据微信交流群都能很快得到反馈和解答。一些小bug也可以通过版本升级解决。
总结目前从大数据监控这个场景看，TDengine在成本、性能和使用便利性方面都有非常大的优势，尤其是在节省成本方面给我们带来了很大惊喜。
在预研和项目落地过程中，涛思数据的工程师提供了专业、及时的帮助，在此表示感谢。
希望TDengine能够不断提升性能和稳定性，开发新特性，我们也会根据自身需求进行二次开发，向社区贡献代码。祝TDengine越来越好。对于TDengine，我们也有一些期待改进的功能点：