HTAP,一个为满足实时性业务分析场景而存在的数据库。
从 2005 年被 Gartner 首次提出以来,HTAP 已经历经数十年的发展期。在当下,如果再次提起 HTAP,不免让人觉得它是个既“友好”又“矛盾”的存在。
“友好”在于,HTAP 数据库能够同时支撑业务系统和在离线数据分析系统运行,避免在传统架构中,在线与离线数据库之间大量的数据交互,对简化企业的数据系统的复杂度将起到至关重要的作用;但“矛盾”在于,用户在 AP 场景和 TP 场景负载模型差异很大,对数据库的诉求也完全不同,如何通过技术手段来平衡他们之间的矛盾成为了 HTAP 数据库的核心问题,因此,一定要有东西在这两者之间做桥梁。
至此,问题也就显露出来了。用户如何能在 TP 还是 AP 负载下,随心所欲地去创建各种表,也可以随心所欲地用一个流呢?在超融合趋势的推动之下,HSTAP 的概念呼之欲出,多出来的“S”格外让人好奇到底是不是在造概念。为了深入了解 HSTAP 的技术架构与产品特性,InfoQ 特别采访了矩阵起源技术 VP 秦姝琦。
要知道,一个技术概念之所以被提出,究其根本还是为了解决某一类痛点问题。比如,近几年 IoT 产业以及 AI 行业的兴起,产生了大量的时序数据以及图数据,在底层数据类型愈发多样的前提下,直接催生出了一批时序数据库和图数据库。
那么,HSTAP 为何会被提出呢?若想真正理解 HSTAP 的内核,不妨先看看它到底要解决业界的哪些问题。
拿一个典型的融合型场景为例,一款股票 APP 本身是交易系统,所以它需要一个 OLTP 数据库做支撑,但是用户又希望其提供股市的预测和分析,这里自然就出现了对 OLAP 系统的需求,即在做大规模交易的同时,还需要基于交易数据和用户行为数据进行分析建模。
要想解决上述问题,常规的技术方案是怎样的呢?如下图所示,企业需要用到非常多的中间件来搭建一个复杂的数据系统,其中包括 OLTP 数据库、OLAP 数据库,消息队列、流引擎、ETL 工具等等,这样一来,会导致系统变得非常复杂,难以保证稳定性;其次,数据流转的链路也变得很长,实时性无法保证,数据血缘管理难度很大,这种基于“缝合”方式搭建的系统,在稳定性、实时性以及运维管理成本和开发成本上存在很多痛点。
在刚刚结束的 2022 re:Invent 大会中,亚马逊云科技提出了一个新的名词——“Zero-ETL”,其本质也是识别到了数据流转已经成为企业很大的痛点。不难看出,简化复杂架构,降低运维使用成本的需求正在不断增长。为了让企业只用一款数据库,就能把最基础的业务中台和数据中台以最低的成本建设好,矩阵起源对 HTAP 进行了重新定义,融入了串联 AP 和 TP 的 Streaming 能力。因此,在秦姝琦看来,HSTAP 的出现便是为了简化数据系统的复杂性,提供极简的用户体验,降低数据使用的难度,让企业可以将精力从繁杂的技术细节中释放出来,专注于数据价值的挖掘,最终达到降本增效的目标。
在数据库的起步阶段,选择一些现成的数据库进行改写往往是一种较为容易的方案,但如果再做深入定制便会比较痛苦。为了避免不受历史包袱的影响,MatrixOne 从设计之初便放弃了一条相对容易的路,选择从 0 开始自研,用时七个月将 Share Nothing 迁移到云原生架构,从 AOE(Append Optimized Engine)存储切换到 TAE(Transactional Analytical Engine),重写了计算引擎(Parser,执行计划,优化器等),并且完成了分布式事务框架和高性能日志服务的研发,累计删除代码 30 万行,新增 20 万行。
这背后的工作量与执行力足以让我们叹为观止,但回忆起 MatrixOne 的起步期,秦姝琦提到:“在真正设计开发这样一款云原生 HSTAP 数据库的时候,我们面临非常多的艰难选择。”
具体来说,用户对于 TP 和 AP 数据库系统的需求基本可以归纳为以下五点:ACID,并发性能,吞吐,成本和数据新鲜度。HSTAP 数据库若想兼容以上能力,实现起来却没那么容易,由于高并发、短时延的 OLTP 负载与带宽密集型、高时延的 OLAP 负载的访问模式不同且它们互相干扰,把他们融合到一个系统里存在很多的冲突点。
谈及如何平衡上述矛盾,秦姝琦以通信领域中两个耳熟能详的概念为例:频分复用和时分复用,即当突破资源粒度划分得足够小,资源隔离做得足够好,调度能力足够强时,就可以把一些看似矛盾的功能平衡起来。“因此,在设计 HSTAP 数据库时,我们不会追求以上提到的五点在同一时间都做到 100 分,而是基于统一存储引擎,对象存储,自适应计算优化,计算存储独立扩缩容,全局的资源调度和资源隔离策略动态平衡这五个看似矛盾的特性,来适应不同的负载场景需求。”
基于这样的设计理念,MatrixOne 引擎的顶层设计架构,可以大致分为三层:计算层、分布式事务层和共享存储层。
其中,计算层是由多组计算资源组成的,其中计算单元我们称之为 CN,每个 CN 可以承担不同的任务,但无论 CN 用于何种用途它本身是不保存任何状态的,以保证计算层是可以任意扩缩容的;再往下面一层是 Transaction Layer,这一层承担了分布式事务处理的相关工作。分布式事务层选择了 share-nothing 的模式,由于每个 DN 之间需要处理的数据范围各不相关,这样做的好处在于,每个 DN 只需要负责自己这部分数据的冲突检测,从设计上简化了 DN 的实现复杂度和扩缩容的难度;再往下是两个服务,一个是 Log service,为 DN 提供高性能的分布式高可用的日志读写服务,它直接决定事务写性能的关键;另外一个是共享存储,这里不仅支持 S3 这类对象存储,还支持 NFS 以及 HDFS。
此外,为了让 MatrixOne 在云上和私有化场景能够保持统一的架构和接口,还在底层架构中抽象了一层 fileservice 接口,它会将底层不同的共享存储实现细节屏蔽掉。比如,在云上选择S3作为底层共享存储,那么在私有化场景不一定有 S3,客户如果能提供 HDFS 集群,就可以通过 fileservice 在保持引擎接口一致的前提下,支持多种的共享存储。
除此之外,MatrixOneGA版本将会有一个重要的特性——实现了Streaming的方案,即HSTAP中的“S”。秦姝琦坦言,目前的 Streaming 还处于早期阶段,团队关注的核心问题还是 framework 的设计、有界数据和无界数据的处理以及增量计算的优化等等。
有了上述方案以后,MatrixOne 是否就可以为用户带来简单、易用的最终体验呢?显然还不够,一个普遍的现象是,当云逐渐变成新的基础设施以后,开发者几乎不会触碰到云服务下层的基础设施,这对于数据库厂商而言,也需要思考如何利用云服务作为底座来构建数据库。因此,在此基础上,MatrixOne 也计划上线全托管 MatrixOne 服务 -MO Cloud,目前已经处于开发阶段,目标支持多个国内外公有云如 AWS、GCP、华为云、阿里云等等,其具备的主要特点是 SaaS 化的使用体验,免部署、自动化运维、按量计费、成本低。
为了实现自动化运维的特性,MO Cloud 也选择拥抱了 Kubernetes 生态,然而 MatrixOne 作为一个有状态的系统,它具有自己独有的状态编排的领域知识,如果 Kubernetes 没有这些领域知识,便无法很好地对 MatrixOne 进行编排和调度。因此,MatirxOne 还上线了专属的 MO-Operator,它封装了编排调度 MatrixOne 所需要的全部领域知识,再利用 Kubernetes API 添加自定义 API 类型的能力,来保证运行中的集群状态永远向用户定义的期望状态转移。目前,MO-Operator 已经实现了创建集群、资源伸缩调度,故障转移,滚动更新等功能。“MO-Operator 就像一个经验丰富的运维同学时刻监控 MatrixOne 集群的状态,而且一切按规则执行永不休息。” 秦姝琦比喻道。
实际上,上述所提到的 MO-Operator 只是 MOCloud 的冰山一角,下图展示了 MOCloud 的架构图,包含平台(Platform)和编排( COS) 两套系统以及旁路观测系统。架构图的上半部分是 MOCloud 的控制面,Platform 包含了一组微服务,比如用户管理,集群管理,计费等,是整个 MOCloud 中唯一需要跟用户进行交互的部分,中间的 Global API Server 是 COS 的核心,也是 Platform 跟 COS 之间的纽带,架构图的下半部分是 MOCloud 的数据面,也就是真正运行工作负载的地方。
值得一提的是,自 Serverless 被认为是新一代云计算发展方向以来,业内就开始关注、推进 Serverless 化,试图从资源视角转换为服务视角。在今年的阿里云栖大会上,阿里云宣布将坚定推进核心产品全面 Serverless 化;在 2022 re: Invent 大会上,亚马逊云科技宣布将数据分析服务全面 Serverless 化. MOCloud 也开始了对于 Serverless 的探索。
秦姝琦认为实现 Serverless 化有两方面好处:一方面,Serverless 对于很多中小型企业很友好,注册即可使用,无需关心任何底层资源,当企业不使用数据库时,也不用付出任何成本;另一方面,站在数据库厂商的角度来看,虽然 Serverless 在前期的投入成本相对较高,但后期可以带来更大的商业回报,是提升收益的一种技术手段。
尽管 Serverless 对于供需双方的价值已经趋向清晰,但是数据库 Serverless 化的实现难度却很高,在秦姝琦看来,主要技术挑战大致可以分为三个部分:第一是安全性,即多租户的资源隔离;第二点资源调度,如何让系统负载达到最优;第三点是整个系统的弹性、高可用。
在采访过程中,秦姝琦主要为我们介绍了 MOCloud 在资源隔离方面的实现进展。在数据的可见性上,MOCloud 可以保证逻辑上的隔离,一个 Session 只能看到这个租户权限范围内的数据,在资源隔离上,还计划用 Proxy+rule engine+CN 来完成一个全局的流控和资源调度,CN 支持独占 Set 来满足更多元化的要求。此外,针对大家关注的安全问题,MOCloud 也会保证持久化的数据是加密的,未来将支持“ bring your own key”的模式,支持租户维度的数据加密。
数据库从来都不会单独被使用,尤其对于初创的数据库厂商而言,完善生态也是非常重要的工作。秦姝琦透露,在更完整的生态对接方面,MatirxOne 将在明年陆续在开源项目上开展对接,还计划针对制造业、能源、新兴互联网等行业,制定相应的解决方案,为此也会在 MatirxOne 中接入相应的生态。
与此同时,她还介绍了 MatirxOne 在未来的产品规划。预计在明年,MatirxOne 将会推出第一个 GA 版本,接下来还将继续融入流的能力,力争通过一个 HSTAP 数据库满足通用场景的需求。虽然实现起来还需要一定的开发周期,但我们也很乐于看到,未来有更多的数据库厂商能够通过创新的架构实践、极简的设计理念,来不断降低企业使用数据系统的复杂度和门槛。