在刚刚结束的第十五届中国数据库技术大会（DTCC 2024）期间，KaiwuDB CTO 魏可伟受邀接受知乎数据库负责人代晓磊的采访。以下为采访观点实录 🙆
三个“wu”，走出一条新路
在开始研发 KaiwuDB 前，我们曾向自己提出过一个问题：究竟“想要”做出一款怎样的数据库？又有多少人是真正“需要”这样的数据库呢？毕竟，面向传统的关系数据库应用，已有 100 多家数据库厂商在做。如果我们也做关系型数据库，意义到底在哪？
最终，我们得出的结论是：轮子不能重复造，我们需要选定一个方向、行业或者领域，实现创新升级和行业引领。
结合数智化转型背景，不难发现：传统的金融、保险、政务等是 IT 投入较大的行业，他们也确实在数字化道路上保持前沿，这也意味着在这些领域的创新机会相对有限。对比之下，在如今的中国经济结构里，“新三样”等行业催生了一系列全新的数字化需求，同时传统制造业的数字化转型需求还有待满足，这些都成为了我们的机会点。
这也是我们 KaiwuDB 名字的由来。Kaiwu（开务），取自易经中的“开物成务”，意为：通晓万物之理，从而对事务做出正确的判定并取得成功。其中：
👉“wu”亦指“物联网”。物联网有着庞大的数据量和爆炸式的数据增长，我们希望扎根物联网，为亟需转型的传统制造业以及新兴的物联网行业提供更贴合业务的数据库产品与解决方案。
👉“wu”又为“服务”，我们希望通过吃透客户的场景需求，为客户提供更加优质到位的服务，真正有效解决用户的问题。
👉“wu“还为“悟”，我们希望借由 AI 等各种创新能力帮助用户深层次挖掘数据，悟出数据中隐藏的价值。
在这三”wu“之下，便有了我们 KaiwuDB。说到物联网，很多伙伴的第一反应是，这不是时序数据库的赛道么? 其实不尽然。在实际业务场景中，没有任何一位客户，即使是物联网行业的客户，单纯依靠一套时序库完成全部业务闭环。但凡用户需要数字化转型，就一定涉及到整个底层数据基座的焕新升级。
在此过程中，除涉及到大部分的时序数据，也不可避免地需要处理来自管理、业务等方面的流程数据。而只有将不同类型的数据融会贯通，并通过 AI 提供更好的数据分析能力，才能打通整个基座的“任督二脉”，应对用户多维度的业务和数据管理需求。这就是为什么我们率先提出”分布式多模数据库“这一概念。
高质量的多模，“装备战略”缺一不可
如今，市面上不少厂商都围绕”多模“在做一些事情。比如：将不同类型的数据模型处理能力通过简单的”粘合“集中在一套数据库中提供给客户。但这样是否真的可以满足我们的客户，还需要打个问号。
恰巧最近我在回顾历史书籍时看到“洋务运动”，给我启发很大。在印象中大家普遍认为，当时我们的武器装备很落后。但事实是，我们购置了不少国际一流的武器装备，却还是输了战争。究其原因，是因为我们没有一套系统的方法论，没有明确的战略来组织不同武器及兵种间的协调配合，这其中有很多地方，和多模是非常类似的。
比如，如果我们只是将不同的数据处理能力打包在一个库里交付客户，那结果可能和洋务运动那场战争一样，注定失败。因为通过简单的打包交付，我们的客户依然不清楚如何更好地处理关系与时序数据、如何进行更智能更有策略的数据分析等。
所以我们在思考多模时，背后是有立体化战略做支撑。针对客户的“每一场战役”，我们都会给出“最优的武器装备组合”。我们想做的多模，绝不是单纯给用户“一筐子武器”自行发挥，而是帮助用户有机地打包组合，并提供适合用户场景的打法战略，攻下数据价值挖掘的“高地”。
用“多模”实现对行业的“One size best fits”
One size fits all 是一个业界频繁探讨的话题。首先，我个人并不是 One size fits all 的信徒。回顾数据库整体的发展历程，从最开始的通用型数据库，到后来逐渐细分出不同类型的专用数据库，不难发现真正要实现“One size fits all”并不容易。而多模数据库也不意味着就一定是笼统的“One size fits all"。
- “克制”地做多模
我们在做多模时，其实是很“克制”的。所谓克制，可以理解为行业不需要我们不给，客户用着累赘我们不放。比如，我们现在针对 AIoT 的用户，重点开放了时序处理能力、关系处理能力（包括事务和分析能力）以及 AI 的能力等。
向量数据库的能力我们也有做，但并没开放出来。因为我们需要先在实际场景中去验证向量数据库能力究竟能在物联网场景为用户做哪些有价值的事情。只有在充分验证有效的前提下，我们才会将这部分能力开放给用户。我们的“克制”，是想要做到对用户负责。
- ”有机“地做多模
克制的同时，我们还在寻求如何让多模实现有机的结合。融合是多模的核心，但我们清楚多模是一个相对较新的赛道，想要在一夜之间将所有模型的融合做到完美并非易事。
所以，我们坚持选择面向重点行业，贴近场景去打磨我们的多模优化器、多模执行器、多模调度等。同时，我们非常清楚，就物联网赛道而言，我们最关键的武器一定是时序引擎。所以针对时序能力，我们通过自有的就地计算、内存映射等创新技术，逐步开发我们的存储引擎、计算引擎，以实现更优的性能，更好的扩展性等。
总结来说，KaiwuDB 面向行业的多模设计原则，与市场上的其他厂商还是有明显的差异化的。虽然我并不觉得 One size fits all ，但是我们相信，通过捕捉特定业务场景和行业底层的共性，配合更多融合性、针对性的战略打法，至少可以实现对行业的 best fits。
坚信 AI，但绝不上头
我们始终认为，在谈 IoT 时， AI 应该放在前头，这也呼应了我们 KaiwuDB 为什么要取自“开物成务”，即要通晓万物之理。我们坚信，AI 和数据库融合是非常有必要的。
回看物联网整体趋势，特别是在过去的十几年里，随着数据量的激增，数据的单位价值在不断下降。“数据库的价值，取决于数据库里数据的价值”，这是我当年刚入行的时候，我的首席架构师分享给我一句记忆犹新的话。这也正是我们现在的思路——通过不断激发出数据新价值，数据库本身才会更具价值。AI 就是实现这个价值的一个很好的加持。
我从事 AI 和数据库的融合研究近 10 年，过程中发现大家对 AI 和数据库融合这块可能会存在一些误区：
👉预期误区，总觉得 AI 无所不能。但往往最终融合的结果可能不尽如人意，这导致最后对 AI 的看法非常两极分化；
👉但凡有新热点，就一定要用上。在我看来，大模型也并非绝对的灵丹妙药。即便是在 AI 领域，也应该遵循“开什么锁，用什么钥匙”的原则。
看清 AI 背后的逻辑后，我们给自己定了一个原则：要务实，不跟风。在面对一些抉择时，我们坚持“要选对的，不选贵的”。也就是说，但凡我们开放的功能，就是奔着实实在在解决客户问题去的。如果经典的模型比大模型在某一问题上效果更佳，那我们就会尊重效果，选择经典。
比如我们之前在做自治能力时，有一个自治框架，我们会用到一些时间预测方法，而不是全然大模型。当然，如果在某些问题上大模型效果好且成本合适，我们也定然会去选择。
我们是拥趸创新的，但我们也要保持清醒的头脑，做出理智的探索，“大而无当”的方法也许不会出错，但“小而得当”的设计兴许可以一招制敌。因此，我们的最终评判标准，就是用户收到的价值与效果。
拥抱开源——开放、开拓、开创
从做 KaiwuDB 的第一天起，我们就在规划开源。最前面有提到，我们其实是有一个非常强烈的初心——帮助有需要的用户去做更有价值的事情。如果我们想把这件事做好，我认为一定需要有开放的心态，跟大家共创。
同时，我们也意识到每个行业都有很多新兴的环节与参与方。比如物联网，或是传统制造业的转型，这其中有很多事情，包括智能终端、实时操作系统、以及上层应用等，是一条很长的产业链。我们希望通过开源，能够联合产业链上各位友商、上下游的伙伴以及研究机构等打造“朋友圈”，共同协作把行业做起来，实现开拓共赢。
我们也希望通过开源去开创一个新的赛道。我们有很多的构想和规划，比如时序引擎优化、多模架构的进一步融合等，还等待着我们去实现。未来，我们希望与广大开源伙伴以及数据库的专家们一起共创，碰撞出更多思维的火花，在这个赛道上去落地更多的创新与畅想。
最后和大家分享下，KaiwuDB 2.0 近期已正式开源，社区版本名字叫 KWDB。欢迎大家去 Gitee 检索“KWDB”了解我们项目，包括安装包、代码、文档等在内的资料一应俱全。喜欢我们记得给个 Star & Fork，欢迎分享给你身边的伙伴🙆
