历时一年，我们把 IoTDB 分布式献给你

 

本文字数：3524字

阅读时间：9分钟

今年 12 月 3 号 Apache IoTDB 完成了 1.0 版本的发布，这个版本最大的变化是从一个单机形态，完成了向全新分布式的蜕变，今天记录一下这次大事记。

蓄势待发

近两年，单机版 IoTDB 通过高性能和轻量化受到越来越多用户的青睐和使用，爱之深、责之切，大家也在关心一个问题，那就是 IoTDB 什么时候支持分布式。不只是用户，每一位社区开发者也在关心社区什么时候启动分布式的研发。

虽然大方向很清晰，就是分布式，但这三个字要想变成一个真正可以部署的系统，需要考虑如何协调来自不同团队的几十名活跃贡献者、选择哪些技术路线、大家如何分工协作，都需要细化成可执行的方案，大家才能行动起来。

在单机版逐渐完善、社区也逐渐壮大（汇聚了一批优秀的开发者）的情况下，我们感觉是时候开始了。

于是，在21年底，社区各个团队负责人和核心研发人员，开了一次战前启动会，主要讨论两件事：

（1）明确目标。大家一起参与，肯定要做一个大家都满意的成果出来。因此，我们先讨论希望做成什么样。其实，IoTDB 对分布式的探索，在 0.12 版本就开始了，在两年多的实践中，也发现了一些痛点问题。大家针对这些问题和我们希望的目标，都达成了共识。

（2）人力投入。开源社区本身是自由的，不限制贡献者每天的工作时间和投入程度，但是分布式是一个需要有人长期投入的事情。因此，我们首先确定了一下各个团队能参与的人员名单。可以看到，开源社区的自由和承诺并不矛盾。

当参与的开发者多样化、目标明确、并且足够投入，所有问题就都能解。因此，这次分布式的一个特点就是社区共创，集百家所长。

“好，开干！”

于是，一场战役就此拉开帷幕。

分布式的目标

当用户说希望上分布式的时候，他们究竟期望分布式解决什么问题？除了高可用、高性能、线性比等常见分布式相对于单机版的特点外，我们主要目标是以下几点：

大容量：可管理的设备、测点等元数据能随着集群规模的增加而增长，没有上限。同时，能管理的数据条数也随集群规模增加而无上限。

很多数据库在设计时，都在说数据分片，很少说元数据分片。为什么我们把元数据单独拎出来说呢，在未来的物联网场景里，测点数量可能很大，而且每个测点都可能有其独特的属性，因此，这些测点的路径和描述信息就会非常多。10亿测点就会有100G+信息需要存储，跟关系数据库的表 schema 信息完全不是一个量级。

而且，对此类数据的查询需求也比表结构要丰富，比如统计一个设备的测点数，查询拥有某一标签的所有测点信息，都是对元数据的分析查询。

可以说，对元数据的管理和分析需求，已经达到和数据相当的程度，我们需要把元数据看成另一种数据。

高可扩展：集群可以随着负载动态扩缩容，而且要非常方便。

在过去的一些场景里，我们遇到一些用户，用了其他的分布式数据库，开始扩容后，后台就有大量数据迁移，而且经常出错，因此大家对于扩容这个事情就非常谨慎小心，但是这又是一个强需求，就非常难受。

因此，我们希望减轻用户扩容的心理压力，不只是云上系统才能平滑扩容，用户也能在工厂里一键搞定扩容。

多模式：在物联网场景里，数据从设备端侧收集，优先服务工厂本地应用，之后继续上传到云侧，数据需要在多个地方被管理起来，这些不同位置的资源也不一样，有的位置就只能支持单节点，有的环境可以支持分布式。

所以数据库也要有单机和分布式多种模式，能够在资源有限场景下运行，也能在资源重组环境部署，上得厅堂下得厨房。

从单机到分布式

国内有不少团队在基于 Influxdb 进行分布式的改造，一种常见的方案就是在上层做中间件，由中间件负责数据的路由和计算汇总，底下接多个单机的 Influxdb，把一个完整的数据库当做存储引擎来用，上层完成一致性、查询引擎的工作。

这种方案见效快，能用 6 分的精力达到及格，但是要想达到优秀，就要再付出12分的精力向下做彻底改造。

另一种方案是，把数据库的各个模块进行拆解和改造，原生支持分布式架构。

对于我们来说，短平快不是我们追求的目标，我们希望一次性打好基础，为未来十年的演化打好地基，所以无疑原生分布式更适合。

核心特性

我们在调研了市面上众多的数据库系统后，选择了如下技术方向：

集群架构：分布式系统有主从架构，有P2P架构。主从架构的优势就是系统集中控制所有资源分配和任务调度，能够做到比较强的统一，但是缺点就是主节点的单点故障，所以有部分系统会做双主来缓解，但还是需要人来及时操作。P2P架构比较灵活，完全没有单点故障问题，缺点也是反过来，任务的协调和一致性难以达到。

为了彻底避免单点瓶颈，同时提供比较强的一致性和集群资源利用，我们选择了主从和P2P相结合的架构。集群从整体概念上分为两层，管理节点（ConfigNode）和数据节点（DataNode），每一层内大家都是平等的，能够容忍单点瓶颈。由数据节点对外提供读写服务，管理节点作为内部服务。

分区键：为了让元数据和数据都能利用到多节点的存储和计算资源，我们用设备号作为元数据的分区键，用设备号+时间段作为数据的分区键，将元数据和数据都切成小片，足够系统横向扩展时进行分配。

分配策略：将数据分成一个一个小分片后，就是怎么将数据分配到节点上了，这是分配策略做的事情。现有的比较常见的有一致性哈希和查找表两种。一致性哈希适合纯 P2P 架构，每个节点都通过计算去找数据，读写较方便，但集群扩缩容会比较复杂，无法避免数据迁移。

而查找表则是系统主节点维护分区信息，精准控制每一个数据、元数据分片的位置。

为了实现秒级扩容，我们选择了查找表作为默认实现，增加节点时不进行数据迁移。

查询引擎：从单机到分布式，最大的改动应该属于查询引擎了，所有操作要能实现分布式规划，并且能交给多节点执行，最终再汇总返回给客户端。单机版，为了简单高效，我们甚至可以裸调存储引擎接口，但分布式就不是这么玩的了。

在参考现在查询引擎的前沿系统，我们决定实现一套时序数据库的 MPP 大规模并行处理架构。将所有操作算子化，搭积木的方式组合算子，并实现数据的批量按列迭代。

这套架构从特殊的时序算子，到读写执行器，都为时序数据场景进行了设计和优化。

共识协议框架：现在一提到共识协议，大家都能想到 Paxos 和 Raft，这两类在任何场景能保证数据强一致性。但是这类协议是否过于重了？

物联网场景的写写冲突远没有互联网场景频繁，甚至可以说，大部分场景几乎没有，由于我们数据的主键是时间序列+时间戳，可以说一条数据，从一个设备产生到入库，基本不可能有同一主键不同值的数据从另一套链路进到数据库，去和它产生冲突。

没有物物冲突，就只剩人物冲突了，只有人会去修改数据，但前提也是发现数据存在偏差采取修改删除，要能先看到数据。在此前提下，我们设计了 IoTConsensus 协议，来提供更高的数据入库效率。同时，为了支持元数据和系统数据的强一致，我们也支持 Raft 协议，并且支持单副本空协议 SimpleConsensus。

这三类协议通过同一套共识框架进行管理，我们可以给元数据、数据配置不同的协议。

在数据库内实践成功一套共识协议框架，IoTDB 应该是第一个。

宝剑锋从磨砺出

当骨架方向定好后，就是热火朝天的开动了。我们成立了指挥部，集群管理组、查询引擎组、共识框架组、存储引擎组、元数据组、白盒测试组、质量保障组。每个组的负责人都是社区 PMC 和 Committer，社区不同公司的团队分别参与到各自熟悉的方向进行贡献。

大家一方面与不同模块对接接口，一方面在各自模块内部完善细节。整个过程中社区所有活跃贡献者基本都参与了进来。现在大家看到的每一个功能，背后可能都有不同的贡献者参与，小到一个元数据查询功能，大到一整个查询框架。小到一个SQL解析，大到执行全流程。

这个过程中，需要大家一起协调的地方也很多，如果有上帝视角，就会看到社区贡献者，通过不同的腾讯会议链接紧密联系在一起，形成一张张隐形的保护网，为新版本的诞生保驾护航。

从跑通冒烟测试，到发布第一个预览版，再到第三个预览版，系统从只有骨架到羽翼丰满，从步履蹒跚到性能起飞。我们也准备好将其交到用户的手中，并且赋予了他一个名字：1.0。

最终，在经历了 5 个 RC 版后，1.0 终于在官网和大家见面了。

总结

可以说，这次 IoTDB 分布式的研发，标志着 IoTDB 从此彻底拥有分布式，为后续产品快速发展奠定了良好基础，也是社区的一次大事记，衷心感谢所有参与到此次 1.0 发布的贡献者。不一一点名了，大家可以在评论区留下自己和 IoTDB 1.0 的故事~

也欢迎大家到仓库和官网进行体验：

https://github.com/apache/iotdb

https://iotdb.apache.org/

长

按

关

注

铁头乔

生命，永不低头。