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

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

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

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

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

物联网数据不正是时序数据么？

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

答：Yes and no！

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

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

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

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

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

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

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

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

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

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

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

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

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

“快”可以说是 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 表现不好的地方。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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