KaiwuDB CTO 魏可伟：1.0 时序数据库技术解读

大家好首先非常感谢大家参与本次 KaiwuDB 1.0 系列产品发布会。作为国内数据库新生品牌力量KaiwuDB 是浪潮集团控股的数据库企业我们聚焦在工业物联网、数字能源、交通车联网、智慧产业等快速发展的重要领域希望为各大行业客户提供完整的数据服务解决方案。

01

为什么我们关注上述提到的几大领域

首先当然是市场本身的的力量物联网现有规模已经以百亿美元来衡量同时还在不断生长其次从政策上看数字能源、工业互联网都是国家重点发展的行业和领域是未来国家经济发展的重要驱动力。分享一组基于 IDC 等权威机构综合得出的数据

当前全球已接入的互联网设备高达 130 亿且这个数字预计 4 年后翻番预计到 2030 年全球 3/4 的设备都将是物联网设备。

物联网设备需要接入互联网并需要具备一定的数据采集和传输能力预计直到 2025 年物联网设备产生的数据会达到 79.4 ZB同时这个数字还在以每年 60% 的速度增长这是真正的数据爆炸。这样量级的数据给 IT 基础设施特别是数据基础设施带来的挑战是前所未有的。

02

物联网数据不正是时序数据么这些挑战不正是时序数据库已解决或正在解决的问题么

答Yes and no

时序数据是物联网数据中占比最大的部分所以物联网数据面临的挑战也是时序数据库要解决的问题比如海量时序数据写入、大规模数据聚合等。值得注意的是传统数据库的技术方式是很难应对如此大量级的数据。

好在时序数据也具备某些特点比如它的写入基本上以追加写入为主更新和删除操作较少它的查询通常是以时间范围作为条件等。针对这些特性我们可以有方向地优化引擎这也正是为什么会出现时序数据库这一大研究方向。

时序数据的体量一般是比较庞大的而且增速较快。大量数据会带来非常强的水平扩展需求所以弹性伸缩是一个基本的管理需求。时序数据还具备一个独有特点物联网设备规模非常庞大假设把这些数据设备看成数据对象传统数据库是无法管理的。

如果仍旧采用传统方式管理设备势必将带来严重的性能问题。所以海量时序数据、水平扩展等这些确实是时序数据库所要解决的核心的问题。

但是物联网应用要处理的数据又不仅仅是时序数据。比如数字能源场景下存在用电量、发电量等时序数据另一方面也会涉及很多关系性的数据比如在能源计价缴费能源交易等场景下存在的高价值关系型数据。这就意味着需要把时序数据和关系数据进行深度融合才能更加全面地满足客户需求。

此外大量物联网数据势必也会带来高昂的管理成本用户会希望把数据价值最大化进而覆盖管理成本。换言之我们数据库厂商需要用数据帮助企业判断趋势辅助决策甚至实现自动快速响应助力企业打造核心竞争力。

但是很显然这些都不是今天的时序数据库的强项。所以说物联网场景下一定是需要一款很强大的时序计算引擎但又不止于时序数据库。

03

那针对当下现状KaiwuDB 1.0 时序数据库具备哪些核心优势

这里我们对 KaiwuDB 1.0 时序数据库的技术优势做了一个总结“快人一步”

• 时序数据库最大的挑战—处理海量数据所以“快”是至关重要的

• 产品最终是服务于“人”也就是我们的用户。一款产品好不好最终一定是用户说了算

• 数据库是物联网应用的重要基础设施但它也只是物联网应用中的一环提供“一”站式整体解决方案才能更好地解决用户业务难点

• 对于物联网来说分“布”式不是一个可选项而是一个必选项。

04

“快”可以说是 KaiwuDB 最闪亮的一点

我们一起来看看如下几组数据KaiwuDB 可支持每秒 100 万记录入库操作千万记录复杂查询毫秒内可完成20 亿记录数据探索 1 秒内完成500 万记录数据可实现 15 层下钻。上述数据都已在先前与用户的合作中得到验证。

说到这里可能有伙伴想问今天的市场有那么多的产品凭什么说自己快呢这里我就要来介绍一下 KaiwuDB 的核心专利技术—实时就地计算。

传统计算机在处理数据时需要把数据读取到内存上再进行组织处理磁盘上的数据其实是被组织成页的形式配置在内存中。我们需要把页 Page 还原成记录 Record 后数据库才能进行处理。

这里就会发生多次转换这种转换对于传统数据库来说是非常必要。但是从性能角度看如果应用上没有大量的并发更新比如时序数据这种模式那这样的操作方式其实是会带来的额外开销简单来说就是不够快

随着硬件的发展我们可以有内存数据库把数据都放在内存里计算。但是当出现时序数据后它还是会受内存限制无法高效地处理这种需求并且在扩展性上也有一定的问题。

上述现状也促使我们推出就地实时计算这一专利技术我们不再沿袭传统的从磁盘到内存多种转换处理的模式而是把磁盘和内存融为一体把磁盘映射成内存让计算引擎直接面对数据。换言之我们把计算推向数据而不是把数据移向计算。

其中我们采用的映射的方式是 Memory-mapped I/O 技术。我们把文件映射到内存地址上和传统的 IO 方式相比Memory-mapped I/O 在很多的场景下具有性能优势。比如传统的 IO 在读取数据时需要把数据从系统的缓冲区复制到用户空间的缓冲区Memory-mapped I/O 是不需要这步操作的所以它会更快。

当然可能也有懂 Memory-mapped I/O 技术伙伴会表示这不是一项很新的技术并且它也存在局限性为什么 KaiwuDB 就地实时计算可以让它在时序数据上表现的这么好原因是我们在 Memory-mapped I/O 的基础上又进一步开展了各项优化工作

第一点我们抓住就地计算适合时序数据这一特点进行重点优化。时序数据写入量虽然非常大但基本上都是追加写入 Append 操作比较少有更新和删除的操作也不会对已有的数据做出改动。所以我们可以对 Memory-mapped I/O 扬长避短通过系统调度去规避 Memory-mapped I/O 表现不好的地方。

第二点我们优化了数据存储格式。在设计时序数据存储格式时我们基本上把数据记录做成定场这样不管是从写入还是查询我们都可以非常迅速的计算并记录在文件上。这样带来的益处是在写入时我们可以比较好地做空间预分配并且让不同的进程去负责不同的数据的插入。在查询时我们可以非常快地定位到指定数据的偏移量也能定位到我们需要的数据大幅提升查询效率。

第三点我们具有比较独特的数据编码技术—把变长的字段通过编码变成等长的字段。在数据记录里我们只存等长的编码数据原始数据存在编码的字典中。不仅保证了数据等长可以帮助我们快速定位而且由于使用了编码数据众多过滤条件在编码数据时即可应用进而在查询、条件过滤时的性能也更高。此外基于数据定长的特性我们可以做到非常高效地并发每个任务都可以很容易地知晓要处理的数据的起点和终点。

05

刚刚谈完了“快”现在我们来谈谈“人”

数据库作为 IT 的基础设施具有很强的专业性如果把软件比喻成“车”数据库软件可以说是“F1” 需要受过专业训练的人才可以驾驭。这也是让很多用户频繁头疼的一大问题因为人才不好找特别是时序数据库这样一个细分领域存在很多自己的特性使用门槛会更高。

所以我们希望通过低学习成本让用户快速上手 KaiwuDB 产品。这里我们做出的选择—融入数据库 SQL 大生态。数据库已经是一款应用了几十年的产品 SQL 的大生态中包含了很多开发者和管理者都非常熟悉操作方式。

所以我们支持开发者运用类 SQL 的语言来完成时序数据操作包括建表、删表、数据插入、数据查询等兼容 PostgreSQL 数据类型和语法支持几十种时间、数学、字符串、聚合等内置函数及自定义函数支持命令行的工具支持 DBeaver 等主流数据库管理工具等。

我们的宗旨大幅度降低用户学习成本帮助懂数据库的伙伴数天内就能上手操作 KaiwuDB 1.0。

06

除兼容外我们也尽量简化了用户的管理和维护成本

这里举两个例子1生命周期管理2智能预计算。

1、生命周期管理。众所周知时序数据具有一个特点—不同时间范围内的数据使用频率不同。最近数据往往是最常被使用到的因此会产生时序数据的生命周期管理问题。比如最近的数据即最热的数据我们希望能够用最快的速度去访问它把它缓存在内存里。针对热数据我们会将其存放在高性能存储中与之对应的称为冷数据它的应用频率较低所以从成本上考虑可以把它放在性能差一点同时也是更便宜的存储上。

在生命周期管理中我们把数据按时间维度切开存储。把最新的数据缓存在内存里落盘的数据则是按照用户的时间定义放在不同的文件中新旧数据可按需放在不同的介质上。此外我们还支持 TimeBound SQL 关键字它定义数据的有效期如果过期我们就会自动执行删除从而节省用户空间。

2、智能预计算。时序数据在查询时存在另一个特点—查询是按照时间去做聚合的。为优化这部分性能我们采取了智能预计算方式提前把数据按照小时或天用户可以定义范围来做预计算。

如果发现用户所做的查询是可以利用到预计算结果时我们就会选择相应的预计算结果来处理查询。由于预计算是提前做的而且预计算表的结果比原始的数据会小很多所以预计算的查询会节省很多时间。而且一次的预计算其实是可以服务很多的查询所以预计算对整体的性能的提升是非常大的。

在 KaiwuDB 1.0 里面预计算对用户来说是无感知的。也就是说用户侧的查询无需任何改动我们会根据查询内容来判断是否存在对应的预计算结果从而支持它处理查询自动选择用原始数据或预计算结果。

07

一站式服务是一个很大的话题因为数据服务包含的内容很丰富

数据服务包含数据摄入、数据治理、数据安全、数据目录等。所以坦诚地说KaiwuDB 一站式目标并不是要做到如此面面俱到的一站式。

我们更多关注以 KaiwuDB 为核心用户可能需要的相关服务。我们的目标是希望用户使用 KaiwuDB 后可以在最短的时间内创造价值。总结下来我们的服务主要落地在两点一个是入口一个是出口。

• 入口数据的生产者把数据生产出来后怎么把数据接入到 KaiwuDB 中

• 出口数据消费者当他要用 KaiwuDB 中的数据时怎么能用得更顺手

先说入口这里我们提供了一项很重要的数据摄入服务。我们所要处理的物联网数据大多是异构的—他们分别从不同的设备经过不同的系统按照不同的标准产生出来。所以数据摄入一定要能够匹配多种不同的数据源。由于物联网采集的数据质量通常来说是无法保证可用性的后期会存在大量数据治理的工作。

如果能把数据验证、数据转换等数据治理工作前置无疑可以帮助后期节省大量资源并且能够让数据更快地被利用起来。针对此KaiwuDB 推出了两款组件Streamer 和 Streamer x。它们的作用是能够接入不同格式的数据包括 CSV 文件、 JSON 文件、 MQTT 导出的数据、其他数据库导出的数据等。并且我们还支持用户自定义 ETL 脚本辅助用户在数据摄入过程即能完成数据验证、数据转换等治理工作。

从性能方面考虑我们采用了 C++ 来实现 Streamer针对特定场景做了性能优化所以即使和市面上主流的流处理工具对比我们的 Streamer 表现也是非常好的。此外我们还提供了快照点恢复功能保证数据在摄入过程中目标端和源端的数据一致性。

接着我们来看出口端。我们根据时序数据常见场景开放了比较容易消费的接口。对于应用开发者特别是微服务开发者我们提供了“数据即服务”的方式。并且我们还有对图形化开发者工具的支持可实现通过 API 进行开发测试。总之我们希望数据消费可以更轻松、更便捷。