YMatrix CEO & 创始人姚延栋：万物智联时代，超融合数据库是最佳数据库形态

近一段时间内，有一个稍显陌生的技术概念不断被提及，那就是“超融合数据库”。对于大部分开发者而言，如果你是初次听闻这个技术概念，或许会感到疑惑：超融合数据库到底能解决什么问题？它与专用数据库相比，核心优势在哪里？

为了深入探究超融合数据库的概念、应用情况以及未来发展，本期《InfoQ 极客有约》，InfoQ 主编赵钰莹就与 YMatrix CEO & 创始人姚延栋进行了一次对谈。本期栏目的对话内容整理如下，供读者参考回顾。

InfoQ：到底怎么理解超融合数据库这个概念？

姚延栋：为了讲清这个东西，我们先考虑一下数据库到底为什么这么丰富多样。实际上，数据库就做三件事情：第一是接数据；第二是存数据；第三是用数据。

由于两个“多样性”，也导致整个数据库行业百花齐放：第一是底层数据类型的多样性（有时也称为多模），有关系数据、时序数据、图数据等等，这种多样性会让很多数据库专门解决一个数据类型的问题；第二个是数据处理的多样性，因为数据有多种多样用法，它有不同的视角、不同的模式，比如 TP 是小查询，但要去为高吞吐做优化，AP 是大查询，我们优化的目的是低延迟，时序场景则经常查询最新值、明细和持续滑动窗口内的聚合值。

数据库产品多样性本质上是由以上两层引起来的，但这种多样性也会造成一个门槛问题。Gartner 曾经出过一个报告，提到 Hadoop 的大多数项目没有达到预期，其中有一个很重要的原因就是复杂度太高。我们看到未来是一个万物智联的新时代，如果产品形态的复杂度还是这么高，可能也很难达到预期。我们就在想数据库最本质的东西是什么？未来最合理的形态应该是什么样的？

因此，我们就提出了超融合数据库，让用户可以非常简单地使用，有数据的时候可以往里面写，想用的时候就可以随时用。

InfoQ：大部分企业的技术栈可能是不同的数据库、不同的架构混杂在一起的，如果他们想用超融合数据库应该怎么做？

姚延栋：如果是一个新场景就比较简单，我们直接引入一个选型，使用我们的产品就好了；第二种是用户已经用了很多的数据库，如果他没有遇到痛点，让他去替换是很难的。不过随着数据量越来越大，问题也就慢慢地显现出来了，不管是硬件投入、系统复杂度、性能还是稳定性，都会出现一些问题，这个时候是我们最佳的切入时机，先通过单点切入，建立好信任感。

InfoQ：YMatrix 的应用场景主要有哪些？

姚延栋：我们现在分为三大类，智能制造、智能装备以及实时数仓。

首先说智能制造，工厂会涉及订单信息、工单信息、仓储、质检、设备运行数据、图片数据等等，这些数据随着时间推移会不断积累下来，形成数据资产，企业都希望能够挖掘这些历史数据产生价值。但是传统的方案可能选型四五种数据库，最终组装在一起。有的人可能也会选数据中台，但其实揭开中台的外衣之后，内部也就是四五个数据库组合一起，这种方式的复杂度非常高。在智能制造场景之下很难成功，因为整个链条太长了，出了问题之后也不容易诊断，而超融合数据库就可以解决这个场景下的问题。不管什么样的数据类型，还是对数据进行什么样的操作，都可以在一个数据库里面完成，极大地降低了复杂度。像比亚迪、小米等企业，他们就在智能制造工厂里来部署我们的产品，承接了它的时序数据和关系数据，还实现了对历史数据的查询、分析以及机器学习。

第二个场景是智能装备或者是泛物联网，比如智能网联汽车、智慧能源、智慧医疗、智慧地球等等，这个场景的特点就是时序数据量非常大，这个时候就需要强大的时序处理能力。当然了，任何一个场景很难只有一种数据，这种场景也有其他的数据类型，只是量多少而已，比如关系数据、文本数据等等，超融合也非常匹配这种场景。

理想汽车就是在这个场景下的案例，理想汽车的特点是车虽然不多，但是它的采集频率指标数蛮多的；北理新源是国家新能源汽车的大数据平台，我们刚接触的时候也就 600 多万辆车，现在已经超过 1100 万辆了，它的特点是车数虽然多，但它的采集频率比较低，指标数也比较少，叠加起来之后的总规模和理想汽车差不多。在这样的场景之下，就特别考验整个数据库的性能，从 YMatrix 4.0 发布以来，我们做了很多工作去提升时序场景下的性能。

第三个场景就是经典数仓或者实时数仓，前面两个场景比较新，而数仓这个场景最早可以追溯到上世纪 80 年代，随着这个场景的发展，用户对实时性的要求越来越高。我们最近也开始接触一类用户，他们希望直接把 ETL 去掉，因为他觉得增加了复杂度，运维以及交付出了问题还得去解决，投入也很大，能不能用一个数据库搞定，彻底避免导出的过程。在这个场景之下，YMatrix 数据库产品有幸站在了 Greenplum 的肩膀上，改进了性能、高可用等等，使我们在实时数仓的场景上也有比较好的优势。

InfoQ：YMatrix5.0 版本会有哪些新特性？

姚延栋：我们主要在两方面做了一些工作：性能和高可用。

超融合数据库一开始被提出来时，好多人会质疑它的实际价值，第一，到底能不能做出来？第二，即使做出来了，性能怎么样？通常意义上讲，大家觉得做的东西越多，可能很容易造成什么都做不好，这是一个非常直观的认识。在 YMatrix 4.0 版本相当于回答了第一个问题，就是我们把超融合数据库做出来了，YMatrix 5.0 相当于回答了第二个问题。

在高可用这一点，我们集成了 Greenplum，但 Greenplum 有一个明显需要改进的地方，当 Master 结点故障之后，需要人工介入进行激活。这在经典的数仓场景下虽然没有特别大的问题。但在工厂生产等之类的关键场景中，如果 Master 挂了，这个时候还需要打电话让运维人员激活，这中间怎么也得过去一个多小时了，而一个小时可能会让工厂的生产损失上百万。在这样的考虑之下，我们对 YMatrix4.0 的故障检测机制、高可用处理机制进行了全部重构，实现了故障自动检测和自动切换，这样就完全不需要人工参与了，让运维人员也可以放心睡个好觉。

InfoQ：YMatrix 跟市面上其他数据库之间的差异性有哪些？

姚延栋：大多数的时序数据库还是类似当年 NoSQL 这种技术路线，当然有的时序数据库可能外面也包了一个 SQL 的接口，但本质上还是做了一个专用的数据库，解决专用的细分场景，我认为未来的大趋势这可能不是主流。

说到时序数据库的三种数据模型，或者三种建模方式分为：窄表模式、宽表模式以及树型模式。这三种建模方式各有优缺点，这里我简单地说下结论。

窄表模式写入最灵活，当你需要添加一个新指标的时候，不需要创建新的字段，只要往里面写就好了，但它的查询性能不好，只能支持一些比较简单的查询，比如查最新值、短时间的明细；而宽表模式会避免很多冗余的数据，所以性能很好，几乎支持所有类型的查询，但会遇到灵活性的问题，比如要添加一个新的指标，就需要在宽表模式里加个字段；树型模型其实是在以上两者之间进行了折中。

YMatrix 数据库则是窄表模式和宽表模式都支持，用户可以根据场景去选择。同时，为了解决宽表模式不灵活的问题，我们提供了一个专门的数据类型——MXKV，让你可以在里面加各种各样的新指标。

InfoQ：最近一两年，国内基础软件的发展是比较迅猛的，但坦白来讲，我们整体还是与国外有些差距的，您认为当前我们遇到的困境主要集中在哪些方面？如果我们想要去打破这样的困境，我们可以做什么样的事情？

姚延栋：基础软件本质是一个商业的范畴，既然是供需，就要看需求方需要什么样的产品，供应方又能供应什么样的产品。国外的产品确实好，而且价格也合理，我想不到任何理由客户不用，就像咱们的服装鞋帽在海外非常受欢迎是一样的道理。只是基础软件需要长期的积累和沉淀，耗资比较大，耗时也比较久，一旦落后就很难追赶上来。

打破困境还是要需要创新，只是跟着国外，我觉得只能是捡漏，做不大做不强。通过创新做出真正卓越的产品满足我们的场景，这样不仅可以同国内外的产品竞争，还可以去海外参与全球竞争，能参与全球的竞争并胜出的企业才是真正伟大的企业。

InfoQ：数据库行业面临的挑战主要有哪些？

姚延栋：最主要的挑战是商业化，就是别人为什么要买你的产品？要解决这个问题，第一要靠创新，第二要有一定的差异化。另外，国内很多初创数据库公司规模相对都比较小，很难形成生态，所以我们坚定地拥抱 PostgreSQL 和 Greenplum 这两大生态，与其保持兼容。另一方面，我们也要为自己构建合作伙伴生态，在时序和实时数据分析方面，我们也在和很多的合作伙伴共同打造下一代的实时数据分析解决方案。最后就是营销了，酒香也怕巷子深，好东西要让所有人都知道，但是营销是一个非常专业的领域，在这里就不展开探讨了。

InfoQ：基础软件创业是个长跑，前期投入会比较大，姚总以及您的团队会因此感到焦虑吗？

姚延栋：至少在产品大方向上，我们没有什么焦虑的。因为当时出来创业的时候，最容易的就是继续做数仓，因为我们在 Greenplum 做了十几年，不管是产品形态、技术还是客户资源都是最容易的，但为什么我们没有做数仓，而选择了超融合数据库，并且从时序切入，其实是我们对未来的一个判断。

做数据库至少要看 5 年以上，判断 5 年以后会是什么样，我们认为 5 年以后万物智联的时代会来临，最重要的新变量就是时序数据，我们对这个方向还是比较认可的。当然一点不焦虑也不可能，特别是早期我们还没有和客户做验证的时候。现在我们确实经过了很多头部企业的验证，也基于很多数据看到了智能网联汽车等领域的蓬勃发展，我们的心态也会就更平静了。

InfoQ：YMatrix 对于开发者的学习门槛如何？

姚延栋：对于开发者门槛还是比较低的，以前如果用过 MySQL、Oracle、PostgreSQL 这种关系型数据库，学习 YMatrix 基本上可以平移过来，特别是用过 PostgreSQL 的开发者，语法几乎都是一样的，体验也都是一样的。

对于运维人员可能还是有一点门槛，但是这个门槛也会比较低。比如，基于 PostgreSQL 体系的数据库需要定期做 analyze，收集一些统计信息。如果不收集统计信息，可能会导致性能变差，之前我们确实也碰到过几次这样的客户场景，客户突然说当时测的时候很好，但现在为什么突然变慢了。我们派技术人员一看，就是没做 analyze，赶紧给他配置定期的 analyze 等任务，为此我们也总结了一些最佳实践。通过这套最佳实践，我们把它产品化、智能化，再做到数据库里面去，通过数据库能够自动的甄别这种情况，后续我们也希望把这个门槛进一步地去降低。

InfoQ：作为一种新型的技术架构，虽然超融合数据库理念很美好，但是大家对于这种事情多少都会想，你是不是牺牲了某些垂直的特性，或者用了以后是不是会付出其他的一些代价，这些代价是否是符合整个行业发展趋势？

姚延栋：好多人都有类似的顾虑，认为这个东西会不会牺牲其他的东西。最终肯定是有权衡，举个例子，比如 ACID 可以确保数据正确性，能够确保数据不重、不错、不丢，还可以释放这个开发人员的精力。很多时序数据库、分析性数据库是不支持 ACID 的，很多人认为 ACID 会损失性能，但实际上是微乎其微的，和其他的技术优化点相比，ACID 的开销其实是可以忽略的。

我们做超融合数据库到底会付出哪些代价？根据复杂度守恒定律来看，复杂度是不会凭空消失的，它只能是转移，我们降低了用户的复杂度，实际上增加了数据库内部的复杂度。这样一来，我们对数据库人才的要求会更高，相当于我们自己承担了更多的工作，也投入了大量的精力去招聘人才、培养人才，努力去降低复杂度。不过幸运的就是我们做到了这一点，也是一个重要的行业突破，它会慢慢地改变数据库的未来形态以及发展格局。