KaiwuDBkaiwudb logo

活动一览

发布会实录1 | KaiwuDB CTO 魏可伟:1.0 时序数据库技术解读

2023-02-02

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


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


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


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


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


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


答:Yes and no!


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


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


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


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


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


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


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


image.png


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


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


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

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

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

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

image.png


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


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


image.png


说到这里,可能有伙伴想问:今天的市场有那么多的产品,凭什么说自己快呢?这里我就要来介绍一下 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 表现不好的地方。


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


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


image.png


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


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


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


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

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


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


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


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


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


image.png


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


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


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


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


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


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


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

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


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


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


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


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


image.png


免费体验 KaiwuDB 全新功能

立即体验

关于我们
联系我们

KaiwuDB B站

KaiwuDB
B站

KaiwuDB 微信公众号

KaiwuDB
微信公众号

© 上海沄熹科技有限公司 Shanghai Yunxi Technology Co., Ltd.    沪ICP备2023002175号-1
400-870-1188
1V1 方案咨询
marketing@kaiwudb.org.cn