淘宝开放平台是阿里与外部生态互联互通的重要开放途径，通过开放的产品技术把阿里经济体一系列基础服务，像水、电、煤一样输送给我们的商家、开发者、社区媒体以及其他合作伙伴，推动行业的定制、创新、进化, 并最终促成新商业文明生态圈。开放业务场景常常跟随内部业务的变化，在数据层面上会频繁发生变更。传统数据库在成本、易用性方面无法很好满足生态异变场景的需求。数据空间的探索，是为了在生态场景中支撑业务快速增长的基础上，提供一个可存储海量数据、单表可自动扩容、字段可无限扩充、查询效率不低于 MySQL 数据库的产品。如何以一套统一的数据架构，支持不同用户按需自定义数据模型，保证数据定义层面的扩展和变更不会影响自身和其他租户业务功能的可用性，将数据和能力集成在平台自身。为此我们打造官方弹性存储空间，在安全可控的情况下沉淀数据支撑更多业务场景标准化开放集成。

本文为此系列第二篇文章，前一篇见——

第一篇：开放网关架构演进

多租户数据模型

我们先站在巨人的肩膀上来看看业界有哪些通用的多租户存储模型。

数据空间采用类似Salesforce的大宽表模型设计，通过SAAS化的方式开放给开放业务使用。元数据对于平台而言，存储的是所有租户的数据。对于租户而言，每个租户/组织只能看到和定义按照自己租户OrgID隔离的它自己版本的元数据和数据， 而且只能执行自己租户OrgID所授权的行为，这样每个租户就拥有各自版本的SAAS方案。

▐  元数据驱动的多租户数据架构

数据空间通过业务场景&租户维度隔离每个租户下自己版本的元数据和数据，整个架构分为以下5个逻辑层次。

1. 1 底层数据存储层：存储了租户底层数据结构以及对底层数据的对象和字段定义信息，支持多种存储类型
2. 2 存储引擎路由层：根据业务场景及租户定制，路由到不同的存储产品中执行
3. 3 元数据层：元数据模型主要由对象、字段以及底层数据表组成。元数据执行引擎是将业务逻辑模型映射到统一的元数据存储模型最核心的能力，我们常说的ORM功能也是其核心功能，但比其复杂的多
4. 4 平台接口层：对外提供数据空间SDK和标准MySQL协议两种调用方式。数据空间SDK中包含对象模型的创建、简化版的SQL执行等操作。标准MySQL协议通过自建MySQL代理层对外提供数据库服务
5. 5 业务场景层：数据空间对外服务的特色业务场景

▐  元数据存储模型

数据空间整个存储采用了与业务无关的宽表设计，可扩展性非常好。底层数据使用动态列存储，加以额外的元数据描述信息。数据模型设计包含以下几部分：

1. 1 对象元数据表：存放用户自定义和定制化的对象
2. 2 字段元数据表：对象下字段的定义，包括字段类型、字段映射在真实存储中的位置、是否需要索引、字段校验规则等
3. 3 数据表：存放用户真实业务数据，由灵活可扩展的弹性列组成，通过对象和字段的元数据定义映射到真实的存储

与Salesforces不同是，这里并没有维护索引表，索引的维护非常复杂，针对ADB有全列索引，并不需要建索引。针对关系型数据库，不使用共享宽表模式的情况下，DDL独立建索引会更为灵活。

基于这个设计可以实现数据空间的弹性列无感DDL，当增加一个数据列时，仅需要选取Data表中相同值类型的数据列，加入到逻辑表字段模型中即可，无需进行显式DDL。

▐  元数据执行引擎

元数据执行引擎由元数据映射、构建语句、组装SQL、执行语句、反元数据映射五个部分组成。用户业务SQL经过引擎执行后映射成与业务无关的元数据存储模型SQL，路由到相应的逻辑租户数据库执行，执行成功后再反元数据映射成用户真实的对象数据。通过元数据执行引擎，就可以实现在统一的多租户元数据存储模型上承载多租户自定义的数据需求。

下面是一个简单的例子。

通用存储协议支持

为了方便用户使用习惯，数据空间除了自身提供SDK调用方式外，还需要适配标准MySQL协议。

▐  MySQL Proxy

在抽象的多租户元数据模型下，协议层开发的技术成本以及难度还是非常大的。数据空间选用开源中间件Sharing-Proxy作为MySQL代理对外提供数据库服务，隐藏底层元数据存储模型，用户不需要感知底层数据存储。Sharding-Proxy的定位是透明化的数据库代理，它封装了数据库二进制协议，用于完成对异构语言的支持，我们先来看下它原始的架构图。

Frontend层实现了MySQL协议的编解码。原始Sharing-Proxy 得到解码的MySQL命令后，开始调用Sharding-Core对SQL进行解析、路由、改写、结果归并等核心功能，在Backend层与真实数据库的交互。

数据空间由于有一套自定义的元数据模型，解耦了用户逻辑模型和底层物理模型，需要对Sharing-Proxy进行改造。

1. Frontend层：MySQL协议层编码/解码保持不变
   
2. Backend层：与真实数据库的交互并不需要，根据存储路由，存储到相应的物理库即可
   
3. Core-module层：得到解码的SQL命令后，需要解析语法树，对元数据进行映射，调用执行引擎执行
   

改造中最核心的部分在于Core Module层。在Sharding-Proxy的线程模型中，Frontend层使用IO多路复用处理客户端请求，后端使用HiKari连接池同步请求数据库，User Executor Group用于执行MySQL命令。

核心层（Core-module）的执行过程委托给CommandExecuteEngine完成，流程如下：

Sharding-Proxy获取SQL命令执行器的流程保持不变，我们主要对解析Statement语句和SQL解析执行引擎进行修改。

▐  SQL解析执行引擎

在数据空间中，我们把SQL执行的整体结构划分为以下几部分。

1. 1 解析器。ShardingSphere采用完全自研的antlr进行解析，通过测试发现非常耗时，数据空间改成Druid解析后性能提升5倍
2. 2 提取器。这里需要将AST节点进行深入解析，封装成数据空间简版SDK
3. 3 构建器。这里指构建查询请求包需要的字段定义信息，包含字段名、表名、字段类型、字段长度等基础参数，由元数据获取。
4. 4 执行器。交由数据空间元数据执行引擎执行

▐  引擎升级

在上述解析执行过程中，SQL协议层需要将SQL解析成数据空间规定的协议格式再执行，存在着以下问题。

1. 1 可扩展性差。每次适配新的SQL语句都需要修改提取器和底层元数据执行引擎，改造成本较大
2. 2 复杂SQL描述难。数据空间规定的协议格式对于简单SQL描述起来比较容易，但对于子查询、多表查询等复杂类SQL描述起来较为困难
3. 3 类型转换复杂。在执行参数准备以及结果返回参数过程中，都需要进行类型的转换，负担还是比较大的。对于MySQL支持的标准查询语法，转换逻辑需要考虑的非常全面

基于以上考量，为了保证代理层的稳定性，对上述SQL解析执行引擎进行了整体升级改造。解析、构建过程不变，增加了改写引擎，并将改写后的SQL语句经过执行引擎处理。

SQL改写在元数据存储模型下需要将用户真实字段改写为底层真实存储的弹性列，详细改写规则如下。

• 标识符改写
  

由于元数据底层真实存储其实是弹性列，业务侧表名和字段名都是逻辑上的概念，需要改写的标识符包括表名称、字段名称等。表名称改写是指解析AST，获取逻辑表名，并找到元数据定义，将其改写为真实表的过程。字段名称改写是指解析抽象语法树，将所有的字段列改写为真实字段列的过程。

• 补列

在多租户数据架构下，租户之间数据依赖业务类型&租户ID进行逻辑隔离，需要补列的唯一情况就是所有语句都需要增加租户查询条件（租户+业务类型+表模型）。

▐  标准协议层适配

对于协议层SQL需要进行单独适配。包括：

1. information_schema库
   
2. MySQL系统变量
   
3. set/commit语句等
   

比如，对于information_schema元数据库中的库表和字段元数据信息，我们需要查询元数据定义信息，并封装返回结果包返回，这里就不一一赘述。

更多精彩内容，欢迎观看：

元数据驱动架构的官方数据空间设计（下）：

https://developer.aliyun.com/article/1263243?groupCode=taobaotech