YMatrix 架构

本文档介绍了 YMatrix 架构的以下内容：

全局架构
- 超融合架构
- 数据库架构
局部架构
- 高可用架构

概述

YMatrix 为降低数据生态的复杂性，设计了具有超融合基因的简洁架构，将计算、存储和网络资源整合在一个统一系统中。其基于大规模并行处理（MPP）系统构建，符合微内核架构特点。

此架构可灵活、融合适应多个场景，不仅对于物联网时序场景友好，也支持传统分析型数据仓库环境及商业智能（BI）工作。

优势

使用超融合架构替换传统数据技术栈看似是一项艰巨的任务。那么，为什么我们一定要这样做？

实际上，无论在哪种情况下，全面使用超融合架构对于许多企业都能带来助益，为企业庞杂的 IT 系统提供统一的数据基座，包括智能网联汽车、工业互联网、智能制造、智慧城市、能源、金融、制药等。

相比于如 Hadoop 生态等复杂数据技术栈，YMatrix 架构有以下优势：

超融合
- 健壮性：一个复杂技术栈通常由 N 个单独的数据处理系统组成。假设任何一个组件出现故障的概率为 P，那么整个系统的稳定性可以近似看成是 (1-P)^N，即每多一个组件，稳定性都会大打折扣。超融合架构由于只有一个系统，自然最为稳定、健壮。
- 经济性：因其超融合特性，YMatrix 可在单个系统中消费与管理数据，而无需在多个分布式系统间传递，避免了一份数据的多系统存储。物理硬件如磁盘等需求小，存储开销低。
- 时效性：超融合架构中数据无需在多个系统间传递，延迟低，时效性高。
- 简化管理：超融合方案使整个数据生态更容易管理，无需精通多种产品技术和程序语言，懂 SQL 即可操作。
高可用
- 在少数节点失效的情况下，YMatrix 的状态数据管理服务可以自动完成节点故障转移，无需人工参与，对业务透明。减少你的人工成本，降低人工风险。
丰富的工具链生态
- 兼容 Postgres / Greenplum 生态。覆盖数据迁移、写入、性能测试、备份、恢复等多种场景。
支持标准 SQL
- 支持 SQL：2016 标准，内容涵盖数据类型、标量表达式、查询表达式、字符集、数据分配规则、集合运算符等。
完整支持 ACID 事务
- 保证数据不重、不丢，保持数据一致，避免用户层复杂的错误检查处理，减少你的操作负担。

超融合架构

概述

与其他架构的数据库相比，YMatrix 的超融合体现在融合了多种数据类型与数据操作，从而在一个数据库内实现多种数据类型 + 多场景的高性能支持；就 YMatrix 内部架构而言，其具有微内核特征。在公共基础组件之上，为不同业务场景需求提供不同的存储、执行引擎组合，实现不同的微内核，以得到针对性的写入、存储、查询性能提升。

图解

下图描述了 YMatrix 内部的超融合架构组成及其功用：

以下部分详细介绍了 YMatrix 超融合架构的组成。

公共基础组件主要指数据库内部的公共资源，如内存管理、网络通讯包、基础数据结构等。
存储引擎与执行引擎指不同场景下 YMatrix 建表时可选用的存储引擎与执行引擎组合，每种组合可成为一个微内核。
优化器将 SQL 字符串转变为一个查询计划，根据选择的底层存储引擎提供的能力生成最好的计划。
日志、事务、并发、锁管理、快照
指 YMatrix 内核中提供并发控制，事务机制，故障恢复等通用功能的标准组件。
SQL 指 YMatrix 与客户端的标准 SQL 接口。
认证、角色、审计、加密、监控、备份、恢复、高可用指 YMatrix 支持的一些其他常见的数据库功能。

数据库架构

概述

YMatrix 的高层数据库架构在经典的 MPP（大规模并行处理）数据库技术架构基础上有所发展。

图解

下图描述了组成一个 YMatrix 数据库系统的核心组件以及它们如何一起工作：

以下部分详细介绍了 YMatrix 数据库系统中的各个组件及其功能。

主节点（Master）
- 负责建立与管理同客户端的会话连接。
- 负责解析 SQL 语句并形成查询计划（Query Plan）。
- 向 Segment 分发查询计划，监控查询执行过程，并收集反馈结果返回到客户端。
- Master 不存储业务数据，只存储数据字典，即系统中使用的所有数据元素的定义及属性集合。
- 在一个集群中，Master 只被允许有一个，可以采用一主一备，备用节点称为 Standby。
数据节点（Segment）
- 负责存储与分布式执行查询 SQL 语句。
- 从 YMatrix 获得最佳性能的关键在于在大量能力相同的 Segment 之间平均地分布数据和工作负载，这样所有的 Segment 可以同时开始为一个任务工作并且同时完成它们的工作。
客户端（Client）
- 在此为泛称，泛指一切可以接入数据库的设备、客户端、应用程序等。
MatrixGate
- MatrixGate 简称 mxgate，是 YMatrix 的高速流式数据写入工具，更多信息请见 mxgate。
网络层（Interconnect）
- 指数据库架构中的网络层，是 Segment 之间的进程间通信以及这种通信所依赖的网络基础设施。
状态数据管理服务（Cluster Service）
- Cluster Service 通过对节点状态信息的管理保证了数据库的高可用。YMatrix 使用 ETCD 集群实现这一服务：当有一个数据库节点宕机时，ETCD 调用自身存储的节点状态数据信息，确认当前健康节点成为新的主节点，从而通过提升此节点来保障整个集群可用。
  例如，如果是 Master 宕机，则其 Standby 提升为 Master；如果是 Standby 宕机，则对整体集群无影响。同理，如果 Primary 宕机，则其 Mirror 提升为 Primary；Mirror 自身宕机对整体集群无影响。更多信息请见故障恢复。

高可用架构

概述

YMatrix 使用自研的 ALOHA（Advanced least Operation High Availability）技术来保障集群的高可用性。当集群出现实例单点故障时，其对应的备用实例将发生角色切换，代替故障实例提供服务，从而保障了集群服务不中断。

故障节点实例	影响	时间
Mirror	当 Mirror 故障，不会影响用户对于相应 Primary 中数据的查询，但需手动恢复故障的 Mirror	网络通畅的情况下可达秒级别
Standby	当 Standby 故障，不会影响用户集群数据的查询，但需手动恢复故障的 Standby
Primary	当 Primary 故障，用户无法查询相应数据，需要等待系统自动提升对应的 Mirror 为 Primary 后再进行查询
Master	当 Master 故障，集群不可用，用户无法查询相应数据，需要等待系统自动提升对应的 Standby 为 Master 后再进行查询

注意！
故障恢复详细操作步骤详见故障恢复。

原理

ALOHA 服务采用了基于 ETCD 集群的高可用架构。该架构可以解决故障自动转移（Failover）的问题，本质上来说即是实现自动选举主节点（Master）机制，并保持数据强一致性。

该机制包括以下环节：

状态数据采集
数据集群上报给 ETCD 的数据有两个来源：
- 无论集群是否存在故障，均定时检测上报
- 集群故障，服务进程感知到后上报
状态数据存储
状态数据存储在 ETCD 集群中。ETCD 是基于 Raft 协议实现的，成熟的分布式存储解决方案。其作为状态存储层，能够在集群出现故障的情况下，为进程的管理控制提供可靠、唯一的集群状态信息。

注意！
ETCD 集群在存储状态时会有较多的磁盘操作，因此理想状况下，应有单独的几个物理机用于部署 ETCD 集群，这样可以充分保证 ETCD 的性能。但实际应用中，物理机的数量可能是不足以支撑 ETCD 独立部署的，因此奇数个 ETCD 实例会随机部署于数据集群的部分或全部物理机上，用以保存节点、实例的状态数据。

进程控制
在 ETCD 提供的具备分布式强一致性存储的基础上，API 层包含的服务的 postmaster 进程就会实时获取各个实例状态。如此，当故障发生时，不同的主、备实例的角色就会被即时地调度，从而最小化故障影响。

原理图如下：

可以看到：

管理工具或 MatrixUI 等客户端发送请求到 API 层；
API 层下发请求到数据集群，数据集群为 API 层提供状态数据；
API 层上报集群状态数据到 ETCD 集群，也可以从 ETCD 集群读取集群状态和服务数据。

附录

ETCD

ETCD 是一个分布式的键值存储集群，用于在分布式系统中存储和检索数据。ETCD 使用 Raft 一致性算法来确保数据的一致性和可靠性。它被设计为高度可用的，具有强大的故障恢复能力。ETCD 提供了简单的 RESTful API 接口，使得应用程序可以方便地访问和操作存储在其上的键值对。

重要概念：

Leader：ETCD 集群的管理者，通过选举产生，具有唯一性。
Follower：跟随者，同步从 leader 收到的日志，ETCD 启动的时候默认为此状态。
Candidate：竞选者，可以发起 leader 选举。