...
- 原生分布式
- 让 IoTDB 各个模块原生支持分布式,分布式或单机实例均通过这些模块组合而成。
- 单机只是分布式的特殊情况。
- 扩展性
- 支持快速(秒级)增加节点,无需迁移数据
- 支持新增节点后实时分担写入负载
- 支持数据读写以及磁盘空间使用的负载均衡
- 高可用
- 客户端可自动切换
- 单节点失效不影响集群服务
- 可观测
- 集群内置监控服务
名词汇总
名词 | 类型 | 对应现有的类 | 解释 |
---|---|---|---|
ConfigNode | 节点角色 | 不对应类 | 集群配置节点,管理集群节点信息、管理分区信息 |
DataNode | 节点角色 | 不对应类 | 数据节点,管理数据、元数据 |
ConfigManager | 模块 | 新加 | 分区节点管理者,处理集群内部请求 |
PartitionTable | 模块 | 新加 | 分区表结构,包含元数据分区信息和数据分区信息 |
StorageEngine | 模块 | StorageEngine | 一个进程内的唯一数据存储引擎(单例) |
DataRegion | 模块 | VirtualStorageGroupProsessor | 管理一部分数据分区 |
SchemaEngine | 模块 | 新加 | 一个进程内的唯一元数据管理引擎(单例) |
SchemaRegion | 模块 | MManager | 管理一部分元数据分区 |
DeviceGroup | 设备管理粒度 | 无 | 每个存储组会对应固定个数的设备组,作为管理设备的基本单元,每个设备都会分配到某一个设备组中。 |
集群角色
ConfigNode:管理数据分区、元数据分区、节点状态信息
...
每个 Node 是一个进程,可将多个进程部署到一台机器上,支持更强的灵活性,可适配云环境部署。
集群架构
主要模块
IoTDB 主要包括以下模块,分布式和单机均可由以下模块组合而成。是原生分布式架构,主要包括以下模块。
- ConfigManager(分区管理器)
- 收集节点状态信息、负责分区表的修改、扩缩容、负载均衡
- PartitionTable(分区信息表)
- 元数据分区表、数据分区表
- StorageEngine(存储引擎)
- 单例结构,内部管理多个 VSG。TsFile 数据文件、数据合并、数据同步
- DataRegion(数据分区)
- 管理一部分数据分区
- SchemaEngine(元数据管理引擎)
- 单例结构,内部管理多个 SchemaRegion
- SchemaRegion
- 管理一部分元数据分区,提供元数据的增、删、查操作
- Protocal(网络协议层)
- 包含 RPC、RestAPI、MQTT 等多种协议的实现,将各种网络协议传来的请求转化为统一的数据处理格式
- ServiceProvider(请求处理层)
- 接收统一格式的数据处理请求,管理线程的并发模型。管理权限。
- Planner(执行计划生成器)
- SQL 解析器、查询计划生成、查询优化,生成 PhysicalPlan
- QueryExecutor(查询执行器)
- 原始数据查询、聚合查询等
- Coordinator(协调器)
- 接收执行计划,并判断此计划是本地执行还是远端执行。对于写入计划,交给共识模块进行多副本写入。对于查询计划,负责执行计划的拆分、分发读写请求、合并结果集。
- Consensus(共识层)
- 管理多个数据副本组,根据一致性级别调度读写请求到对应副本
单机模块
- 网络协议层
- 请求处理层
- 执行计划生成器
- 查询引擎
- 存储引擎
- 元数据管理引擎
分布式模块
- ConfigNode
- 网络协议层
- 请求处理层
- 分区管理引擎
- 共识层
- 分区信息表
- DataNode
- 网络协议层
- 请求处理层
- 执行计划生成器
- 协调器
- 共识模块
- 查询引擎
- 存储引擎
- 元数据管理引擎
DataNode 和 ConfigNode 的模块组成如下图所示,DataNode 的 Coordinator 和 Consensus 模块是可插拔的,启动 Standalone 版本时可不启动。
集群模块分布示例
每个存储组对应 集群总核数/副本数个 DataRegion(V) DataRegion(D) 共识组,并且对应 M 个 SchemaRegion(M) SchemaRegion(S) 共识组
S: SchemaRegion
D: DataRegion
...
- 设备模板的读写流程
- 客户端与数据节点的【分区表缓存】及【读写流程适配】
- 节点的后台线程,SEDA模型
- 心跳,Lease
- 各模块的改造:StorageGroupProsessor,PlanExecutor,MManager,PhysicalPlan
代码修改
开发分支:master
开发方式:不影响现有单机功能,新建包进行开发,最后替代老代码。开发分支:new_cluster
模块结构:
DataNode :单机模块转化为分布式模块(server module → DataNode module)
...
第三阶段:MPP 查询引擎,ConfigManager 负载均衡策略,Consensus 的 sofa-jraft 集成
协作计划
模块(接口) | 内容 | 参与贡献者 | 设计定稿 | 原型开发完成 | 测试调优完成 |
分区管理(ConfigManager) | 元数据分区策略、元数据负载均衡策略(确定元数据从哪迁移到哪) | 陈荣钊 | 3.31 | 4.31 | 5.31 |
数据分区策略、数据负载均衡策略(确定数据从哪迁移到哪) | |||||
共识层(Consensus、Raft) | 集群扩容、启动流程 | 谭新宇 | |||
集群缩容、节点停机 | |||||
数据迁移流程(负载均衡、缩容会触发数据迁移流程) | |||||
Consensus 层读写流程 | |||||
Raft 读写流程 | |||||
元数据操作(MManager) | DDL 执行流程(DataNode 内的元数据缓存更新策略,向 ConfigNode 上报统计信息) | 薛恺丰、江天 | |||
数据写入(Coordinator、StorageEngine、VSG) | 写入流程(内存控制、客户端分区信息缓存管理、DataNode分区信息缓存管理) | 侯昊男、权思屹 | |||
查询引擎(Coordinator) | 查询算子 | 张金瑞、田原、苏宇荣、魏祥威 | |||
基于规则的优化器 | |||||
单机查询适配 | |||||
分布式调度、执行器 | |||||
查询内存控制 | |||||
监控(MetricManager) | 集群监控框架 | 张洪胤 | |||
多租户管理 | 权限管理 | ||||
资源隔离 |