关于数据库: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，以达到最好的性能体现。

同花顺行情依据工夫频度的不同，数据个性别离如下。

通用个性:

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

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 的过程中，咱们遇到了一些小问题。比方在通过 Restful 接口应用 TDengine 的时候，获取数据超过 10240 行会有限度。通过沟通，咱们理解到在启动服务端时，参数restfulRowLimit 能够管制返回后果集的最大条数。

其余一些在应用过程中不分明的中央，在涛思数据的物联网大数据微信交换群都能很快失去反馈和解答。一些小 bug 也能够通过版本升级解决。

总结

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

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

心愿 TDengine 可能一直晋升性能和稳定性，开发新个性，咱们也会依据本身需要进行二次开发，向社区奉献代码。祝 TDengine 越来越好。对于 TDengine，咱们也有一些期待改良的性能点：

• 反对更加丰盛的 SQL 语句；
• 灰度平滑降级；
• 可实现自定义聚合办法；
• 更快的数据迁徙。

后续咱们也将在同花顺的更多场景中尝试利用 TDengine，包含：

• tick、minute 行情数据的迁徙以及线上利用；
• 采取自定义聚合办法实现分钟行情、日线行情的聚合计算；
• 当天实时行情的数据的治理。