在 8 月 13 日的 TDengine 开发者大会上，涛思数据创始人陶建辉进行了题为《高性能、云原生的极简时序数据处理平台》的主题演讲。在本次演讲中，他不仅分享了时序数据库现阶段的技术痛点，还深刻阐释了打造 TDengine 3.0 的起因以及实际思路。本文依据演讲内容整顿而成。
在 2017 年刚开始做时序数据库（Time Series Database，TSDB）时，学物理的我想当然地认为做好数据库没有大家说的那么难，但做了 5 年后才发现，这真的不是一件很容易的事。上面我具体说说难在哪里：
- 程度扩展性（Scalability）问题。 在 TDengine 刚开发没多久时，我用一台 128 核的机器对 TDengine 进行了测试，后果性能远远没有达到预期，这件事件也让我分明地意识到，现实的程度扩大能力很难实现。
- 没有真正的云原生化。 我集体特地深信云是将来，数据库也肯定要走向云原生（Cloud Native），但在深度钻研市面上的数据库产品后，我发现大部分数据库都不是云原生，而仅仅是“云就绪”（Cloud Ready），即数据库服务提供商在转售云平台。真正的云原生数据库应该具备存算拆散、计算和存储能力弹性扩张、可能在云上部署、自动化部署等特点。
- 复杂性（Complex）问题。2016 年我看到很多人在解决一些简略的时序数据时，要把整个 Hadoop 零碎搬过去，要加 HBase 层，还要把 Flink、Spark 等等全副加上，这对于研发人员来讲就是个劫难。但时至今日，这个复杂性也并没有随着时序数据库的倒退失去充沛的解决，只有打造一个集 Kafka、Flink、Spark、Redis 等第三方工具性能于一体的极简时序数据处理平台，这一问题才无望充沛解决。
- 数据分析能力跟不上。 诸如 InfluxDB、Prometheus 等较为风行的 Time-Series Database，因为不反对 SQL，导致很多失常的数据服务、数据仓库的分析方法都用不上。联合我过往一直跨界的教训，我发现了这个问题，所以 TDengine 早就反对了 SQL，不过依然须要优化和增强。
发现并解决上述的问题，便是咱们打造 TDengine 3.0 的初衷。从去年 6 月开始，在 40 多个研发一年多的致力下，TDengine 3.0 终于在明天正式和大家见面了。
上面咱们就一起看看 TDengine 3.0 是什么样子的。
云原生时序数据库
程度扩大
TDengine 的新分布式架构
打造云原生时序数据库，第一个因素就是必须是分布式架构。其实 TDengine 以前也是分布式架构，但为了实现云原生的种种个性，咱们在此架构根底上引入了一个新的节点——计算节点 Qnode。
通过云原生如何解决可扩展性问题？还是通过分片分区来解决，数据切分的办法咱们没有做太多改变，TDengine 一开始就是这么做的，在时间轴上以天或周为单位对数据进行切分，同时将定量设施的数据调配给每个区（Vnode）进行解决。
跟 2.x 相比，3.0 最大的不同就是元数据的治理也变成了齐全分布式的。 这也是我在此前版本中汲取了一个教训而做出的扭转，最开始我没想到元数据的治理如此之难。
有一次咱们和涂鸦聊单干，他们要测五千万个设施的数据，TDengine 2.0 在测试中就呈现了高基数问题。在 2.x 的设计中，咱们的元数据对立寄存在 mnode 中，这在此次测试中就成为了一个瓶颈——在进行聚合操作时，光是把五千万个设施中的标签数据拉进去就须要很长时间，聚合速度可想而知。也因而， 高基数成为了咱们在 3.0 版本中解决的首要问题。
当初的 TDengine 治理节点不再存储每个设施或每张表的元数据了，而是把这些元数据还有时序数据齐全存储在 vnode 里，之后会用 B+ 树、一致性哈希来解决。这样一来，咱们在插入一个数据到任何一个片或者一个区时都不再须要通过任何两头节点，彻底解决了高基数的问题。
通过测试，TDengine 3.0 齐全可能反对 10 亿个设施、100 台服务器节点， 同时整个启动工夫也很快，不到一分钟整个集群就能启动。只管此前的 2.6 也能反对五千万的设施数，但启动工夫就大略要三四十分钟，设施数量多的时候不太给力。
中国智能电表至多要有十亿台，给十亿台电表做聚合操作能够说相当不容易，解决高基数问题是很重要的，TDengine 倒退到 3.0 版本才算是真正把这个问题解决了。
弹性
云原生外面一个很重要的货色就是弹性，它跟程度扩大的弹性还略有不同，首先肯定要把计算和存储拆散，我下面说 3.0 新增了一个计算节点 Qnode，它是专门用来做计算的，但简略查问 Vnode 就能够间接操作了，如果牵扯到 group by、order by 等简单查问，就须要在 Qnode 上进行了。
Qnode 的长处就是操作者能够动静地启动、进行，也就是说它的计算资源能够动静地进行操控，这样就实现了存算拆散。同时 Vnode 也能够进行拆分或合并，保障存储也能够弹性伸缩。
如果零碎不能做到真正的弹性伸缩，就肯定不是云原生的，很多企业打着云原生的幌子，但实际上连云原生是什么都说不清楚。在我看来，云原生就是要充分利用云平台的劣势，即计算资源、存储资源、网络资源，且要齐全弹性，你想要就马上给你，不想要就马上开释，这样能力真正实现老本的节约。
韧性
云原生里还有一个重要概念叫韧性，简略来讲就是高牢靠、高可用。TDengine 在设计之初就思考到了这一点，其高可用就是用多个副原本实现，但前面发现以前的同步算法还是存在破绽，因而 3.0 就齐全采纳了规范 RAFT 协定来实现数据复制，以此保证数据一致性。
除了高可用，合格的韧性还要保证系统的高牢靠，保障机器即便宕机了仍然还能重启，且还能持续工作，数据也不会失落。
部署、保护
咱们以前都是倡议用户到 Kubernetes 上部署，但并没有出具体的自动化流程，3.0 版本给出了具体的 Kubernetes 部署文档，只需批改两个配置文件，马上就能部署整个集群，极其简略。
除了更加了解云原生，3.0 给我带来的另一个播种就是对于可观测性的了解，可观测性其实远远不只是监控，它包含了 logging、tracing、metrics，咱们在 3.0 上实现了整个架构，让用户对 TDengine 所有集群的运行状态都能真正监测到，让系统维护变得更加简略。在保护上，还有要害一点就是要做到自动化，所有都要脚本化，缩小人工手动操作的老本。
极简的时序数据处理平台
在 TDengine 创立之初，打造一款极简的时序数据处理平台就是我的初衷。要晓得，一个通用的架构往往是要先把采集数据送到 Kafka 或者各种音讯队列里，生产之后一部分数据再送到 Spark 或者 Flink 里做流计算解决，一部分数据送到数据库做间接存储，还有一部分则会传输到 Redis 做缓存，这样一个数据处理平台，外面要集成很多软件，保护起来相当艰难。
要打造一款极简的时序数据处理平台，首先要解决的问题就是缓存，因为缓存对于物联网、车联网来讲都是极其要害的，TDengine 早就具备了缓存性能，这个也是很多用户特地喜爱的性能，十分不便。
TDengine 的数据订阅实现机制
对于 TDengine 3.0 来说，还有一个很大的改良是重构并优化了数据订阅性能。TDengine 是用 WAL 来做的订阅，技术人员应该都晓得，WAL 自身就能够看作一个队列，齐全依照数据达到程序来追加写入。在 TDengine 3.0 中，既能够订阅一个数据库，也能够订阅一个自带标签的“超级表”，间接实现过滤，比方只想订阅功率超过多少的智能电表数据，间接就能实现。订阅实现后无需再拿到利用端去过滤，极大晋升了数据传输的效率。
咱们做产品的目标就是要让大家用起来简略，因而在做音讯队列性能时，API 全副对标的都是 Kafka，当初不光是初始化和每条命令，连测试都齐全一样。以前常常有友商会对标 TDengine，提出性能要超出 TDengine 一百倍之类的观点，但规范就是本人定义的，甚至都没有公开。但咱们只采纳国内通用的测试规范来测，包含音讯队列，间接用 Kafka 公开的 benchmark 进行测试，咱们认为这样才有说服力，才是主观的。欢送大家体验。
TDengine 3.0 还有一个很大的改良就是持续优化了流计算性能。 之前 TDengine 就曾经反对一个间断查问的流计算，这种周期性的查问流计算还是很有用的，然而性能笼罩却还不够。在 IoT 场景下做数据荡涤、过滤时，要做一些实时的触发，必须应用事件驱动的流计算，通过一年多的致力，TDengine 3.0 终于降级了这一流计算性能。
全新优化的流计算性能
TDengine 3.0 所反对的流计算性能是十分典型的，如下面的架构图所示，数据源要先进入 Input Queue，再进入流计算的 Task，再输入到另外一个列。而且流计算能够嵌套，一层一层造成一个数据的 pipeline。从不便用户应用的角度登程，TDengine 的流计算语法就是 SQL，外面做了 windows 等扩大，能够在数据写入时触发，也能够在窗口完结触发。
此外，TDengine 3.0 对 UDF 的反对也进行了优化。3.0 对 UDF 进行了从新实现，加上工夫驱动的流计算，我感觉至多在时序数据的场景下，TDengine 曾经可能齐全代替 Spark 和 Flink。
极简的时序数据处理平台
但在此我须要再重申一下，咱们优化 TDengine 的缓存、音讯队列、流计算等性能，并不是想代替 Flink、Spark、Kafka 这类通用型的音讯队列软件、流计算软件，只是想简化这款基于时序数据场景做的数据库软件，更加便于大家应用，通过升高零碎复杂度来真正升高运维和存储老本，这也是咱们搭建极简时序数据处理平台的起因。
便捷的数据分析
从新构建查问引擎
TDengine 3.0 还有一个较大的扭转就是从新设计了计算引擎 ，当初像 Planner、优化器、执行器等都具备了。对于数据来说，查问是十分重要的，数据存储好之后，用户最重要的就是要从中开掘数据价值，TDengine 对 SQL 的反对曾经做的很好了。
然而 SQL 这个概念也很简单，咱们不可能像 Oracle 一样反对那么多具体的简单查问，3.0 的查问对标的是 Hive，Hive 能做的所有的剖析 TDengine 曾经都能做了。此外，TDengine 也有很多针对时序数据的特有函数，比如说挪动均匀、工夫加权均匀等等。
重构查问引擎的 TDengine 3.0 曾经成为了一个很好的查问工具，再辅以上面的这些伎俩，足以让查问变得更无效：
- 超级表适宜做多维度剖析
- 计算与存储拆散
- 数据分片、分区
- 流解决
- 历史数据和实时数据对立剖析
- 来自控制台的长期查问
- Python Pandas，数据框反对
- Grafana，用于可视化的谷歌数据工作室
TDengine 3.0 的最初一个更新性能叫作 taosX，它充分利用了 TDengine 的数据订阅性能来解决增量备份、异地容灾， 即把一个集群的数据复制到另外一个中央去，以实现边云协同。家喻户晓，边云协同在物联网外面很重要，如果说工厂的数据想要同步到团体，就须要一个边云的盒子一层接一层做同步，而这个需要，在 TDengine 中就靠 taosX 解决了。
此外除了技术上的种种提高外，明天我还要给大家同步一个好消息。为了不便工业场景下大量的 Windows 客户，TDengine 3.0 的 Windows 版本也正式公布了，包含客户端和服务器。 同时，大略在 10 月 1 日，TDengine 的 Mac 版本也将正式对外公布，大家敬请期待。
目前 TDengine 3.0 的代码曾经在 GitHub（https://github.com/taosdata/T…）上公开，大家能够齐全参照咱们的 readme 文件来编译，也能够到 TDengine 的官网去下载。如果你是一个开发者，感觉 TDengine 这个我的项目有意思，能够抉择退出咱们的开发者社区，学习源代码，甚至是奉献代码。如果你是一个物联网或者工业互联网利用的开发者，那欢送你把 TDengine 利用起来，你能够退出咱们的用户群，咱们很乐意答复你的问题。如果你是个 DBA，那欢送你马上下载，去体验我方才讲的各种性能。
中国的开源软件特地须要大家的反对和应用，我常常跟销售团队起争执，比方在决定哪些性能必须放在企业版时，我就示意所有的外围性能都必须同步在开源版本上，而绝不能只放在企业版里。为什么？因为想要做好开源就肯定要给用户带来价值，我心愿有越来越多的人可能成为 TDengine 的布道者。
结语
我特地喜爱丘吉尔的这段名言，翻译成中文就是“胜利不是起点，失败不是终结，唯有你持续前行的勇气最为要害”。从创立 TDengine 到当初，咱们曾经走过了 5 个年头，开源也曾经走过了 3 年，在这个过程中获得了一些小小的胜利，然而咱们后面的路还很漫长，我曾经做好了再战 5 年、10 年的筹备。心愿我在七八十岁的时候还能持续写代码，和大家一起探讨问题，度过真正有价值的毕生。
想理解更多 TDengine Database 的具体细节，欢送大家在 GitHub 上查看相干源代码。