乐趣区

关于数据库: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 容量布局的难点在于内存的布局。

革新成果

实现革新后,线上的行情获取性能能够达到预期,目前运行稳固。

  • 革新后性能比照状况,能够看到性能晋升显著。
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,咱们也有一些期待改良的性能点:

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

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

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