KWDB 作为一款面向 AIoT 物联网的分布式多模数据库，致力于解决物联网场景下海量异构数据的高效处理问题。物联网场景中，通常会有百万级设备接入，这就要求时序数据要达到每秒数万赫兹的高频写入，同时确保查询的低延迟与高时效性；而在此场景中，业务系统需要快速响应对于关系型数据的增删改查等事务操作，并严格保障数据的强一致性与事务完整性。

这种来自实际业务的多元化的海量数据处理需求，推动 KWDB 就分布式多模数据库的架构进行创新设计的技术演进。本期一文讲透我们将带领大家深入了解 KWDB 如何实现多模数据库的核心“分布式”架构。

KWDB 多模分布式架构设计实现了统一的分布式元数据管理、多模数据管理、分布式执行调度及多层的分布式执行。

整体分布式架构包括了 Master Engine（ME）层和 AGENT Engine（AE）层，ME 层包括了分布式元数据管理负责系统的系统元数据和用户表相关元数据的管理，同时也是分布式执行的调度层。多模数据管理负责分发不同模的数据到不同存储引擎数据分布，目前包含 TS（时序存储）以及后期的列存存储引擎。分布式执行调度根据查询涉及的数据模型，把查询的逻辑计划转换为可执行的物理计划，再分发到 ME 执行层和 AE 的执行层进行计算。其中，AE 层主要负责时序物理计划的创建和实际执行。

多模分布式架构

KWDB 的分布式元数据管理采用的统一的数据管理方式，所有的系统数据统一划分为相同大小的分片 Range，使用两级路由的方式管理元数据，每条路由元数据约为 256B，单个元数据 Range 可存储 256K 条路由信息（64MB/256B），所有 ME 启动就持有 Root Mata Range，通过改 Root Mata Range 可以路由到 Metadata Range 以及 User Range。

元数据管理结构

多模的元数据都整合在这一套管理结构中，区别在于，时序数据使用了设备的 primary tag 的 hash 作为数据分片的 key，关系数据直接使用表的 primary key 左右分片的 key。同时，考虑不同模型的使用特征，关系数据采用了顺序切分的规则，主要使用 primary key 的顺序，数据大小这两个指标进行切分。时序数据主要考虑数据的均衡性，采用了 primary tag 的一致性 hash 方式计算 key，多个设备数据组成一个数据分片。时序数据的分片 hash 上限定为 2000，默认初始化为 5 个大分片，随着分片大小增加，逐渐按照设备拆分出新的分片。

分布式执行调度负责在逻辑计划的分布式改写以及执行计划拆分成执行节点计划片段（FLOWSPEC），同时排列所有片段的顺序和并发度，达到多模分布式的执行结果。

例如：纯时序数据的查询，分布式执行调度层会将所有的计算下推到AE端，进行计算的执行，下图即为FLOWSPEC的创建结构和调度流程。图上ｓｅｌｅｃｔ查询语句经过计划层处理会生成3个FLOWSPEC对应不同节点的执行计划，有FLOWSPEC1进行整个计划的调度。

对于跨模的执行，会涉及 ME 层的关系数据计算以及 AE 层的时序数据的计算，这两个层的计算语言隔离，但在跨模的执行中是需要数据传递的。KWDB 为支持这种跨模的执行，增加 ME 层到 AE 层数据下推通道用以支持不同模之间的数据交互。

跨模数据交互

KWDB 的分布式执行引擎负责实际执行用户输入 SQL 请求的实际计算。分布式执行引擎包括了 FLOWSPEC 的 setup 和 run 等主要操作，整个分布式执行引擎横跨 ME 层和 AE 层。FLOWSPEC 也设定数据模型属性，支持关系和时序计划片段 FLOWSPEC。不同类型的 FLOWSPEC 会有统一的 GATEWAY 节点分拆到不同节点。不同节点在接收到需要执行的 FLOWSPEC 后，会区分不同类型的 FLOWSPEC 到本节点的不同计算引擎中，不同的 FLOWSPEC 之间通过 stream 进行数据流的交换。

多层的分布式执行引擎

最后，为了帮助大家快速无痛上手，KWDB 基于已有场景精心打造了一个示例项目 SampleDB ，内附场景与样例数据，零门槛体验多模数据库 KWDB，欢迎大家使用>>仓库地址：https://gitee.com/kwdb/sampledb