元数据驱动架构的官方数据空间设计(上)

本文涉及的产品
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云数据库 RDS PostgreSQL,高可用系列 2核4GB
云数据库 RDS MySQL,高可用系列 2核4GB
简介: 元数据驱动架构的官方数据空间设计(上)




淘宝开放平台是阿里与外部生态互联互通的重要开放途径,通过开放的产品技术把阿里经济体一系列基础服务,像水、电、煤一样输送给我们的商家、开发者、社区媒体以及其他合作伙伴,推动行业的定制、创新、进化, 并最终促成新商业文明生态圈。开放业务场景常常跟随内部业务的变化,在数据层面上会频繁发生变更。传统数据库在成本、易用性方面无法很好满足生态异变场景的需求。数据空间的探索,是为了在生态场景中支撑业务快速增长的基础上,提供一个可存储海量数据、单表可自动扩容、字段可无限扩充、查询效率不低于 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协议。

对外接口

说明

优点

缺点

数据空间SDK

MySQL语句简版描述

可以通过代码实现数据访问,适合java编程习惯

  1. 可扩展性差
  2. 复杂SQL描述难
  3. 类型转换复杂
  4. 通用型不强,对接业界查询引擎困难

MySQL协议

提供MySQL代理,对外适配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

相关实践学习
每个IT人都想学的“Web应用上云经典架构”实战
本实验从Web应用上云这个最基本的、最普遍的需求出发,帮助IT从业者们通过“阿里云Web应用上云解决方案”,了解一个企业级Web应用上云的常见架构,了解如何构建一个高可用、可扩展的企业级应用架构。
MySQL数据库入门学习
本课程通过最流行的开源数据库MySQL带你了解数据库的世界。   相关的阿里云产品:云数据库RDS MySQL 版 阿里云关系型数据库RDS(Relational Database Service)是一种稳定可靠、可弹性伸缩的在线数据库服务,提供容灾、备份、恢复、迁移等方面的全套解决方案,彻底解决数据库运维的烦恼。 了解产品详情: https://www.aliyun.com/product/rds/mysql 
相关文章
|
8天前
|
人工智能 运维 安全
配置驱动的动态 Agent 架构网络:实现高效编排、动态更新与智能治理
本文所阐述的配置驱动智能 Agent 架构,其核心价值在于为 Agent 开发领域提供了一套通用的、可落地的标准化范式。
|
3月前
|
存储 BI Shell
Doris基础-架构、数据模型、数据划分
Apache Doris 是一款高性能、实时分析型数据库,基于MPP架构,支持高并发查询与复杂分析。其前身是百度的Palo项目,现为Apache顶级项目。Doris适用于报表分析、数据仓库构建、日志检索等场景,具备存算一体与存算分离两种架构,灵活适应不同业务需求。它提供主键、明细和聚合三种数据模型,便于高效处理更新、存储与统计汇总操作,广泛应用于大数据分析领域。
375 2
|
6天前
|
人工智能 安全 数据可视化
配置驱动的动态Agent架构网络:实现高效编排、动态更新与智能治理
本文系统性地提出并阐述了一种配置驱动的独立运行时Agent架构,旨在解决当前低代码/平台化Agent方案在企业级落地时面临困难,为Agent开发领域提供了一套通用的、可落地的标准化范式。
配置驱动的动态Agent架构网络:实现高效编排、动态更新与智能治理
|
2月前
|
数据采集 缓存 前端开发
如何开发门店业绩上报管理系统中的商品数据板块?(附架构图+流程图+代码参考)
本文深入讲解门店业绩上报系统中商品数据板块的设计与实现,涵盖商品类别、信息、档案等内容,详细阐述技术架构、业务流程、数据库设计及开发技巧,并提供完整代码示例,助力企业构建稳定、可扩展的商品数据系统。
|
11天前
|
数据采集 机器学习/深度学习 搜索推荐
MIT新论文:数据即上限,扩散模型的关键能力来自图像统计规律,而非复杂架构
MIT与丰田研究院研究发现,扩散模型的“局部性”并非源于网络架构的精巧设计,而是自然图像统计规律的产物。通过线性模型仅学习像素相关性,即可复现U-Net般的局部敏感模式,揭示数据本身蕴含生成“魔法”。
68 3
MIT新论文:数据即上限,扩散模型的关键能力来自图像统计规律,而非复杂架构
|
3月前
|
SQL 缓存 前端开发
如何开发进销存系统中的基础数据板块?(附架构图+流程图+代码参考)
进销存系统是企业管理采购、销售与库存的核心工具,能有效提升运营效率。其中,“基础数据板块”作为系统基石,决定了后续业务的准确性与扩展性。本文详解产品与仓库模块的设计实现,涵盖功能概述、表结构设计、前后端代码示例及数据流架构,助力企业构建高效稳定的数字化管理体系。
|
21天前
|
JSON 供应链 监控
1688商品详情API技术深度解析:从接口架构到数据融合实战
1688商品详情API(item_get接口)可通过商品ID获取标题、价格、库存、SKU等核心数据,适用于价格监控、供应链管理等场景。支持JSON格式返回,需企业认证。Python示例展示如何调用接口获取商品信息。
|
2月前
|
数据采集 监控 数据可视化
数据量暴涨时,抓取架构该如何应对?——豆瓣电影案例调研
本案例讲述了在豆瓣电影数据采集过程中,面对数据量激增和限制机制带来的挑战,如何通过引入爬虫代理、分布式架构与异步IO等技术手段,实现采集系统的优化与扩展,最终支撑起百万级请求的稳定抓取。
数据量暴涨时,抓取架构该如何应对?——豆瓣电影案例调研
|
3月前
|
数据可视化 IDE Java
OneCode图生代码技术深度解析:从可视化设计到注解驱动实现的全链路架构
OneCode图生代码技术通过可视化设计与Java注解驱动,实现UI到代码的高效转换,支持设计即开发、组件复用与动态加载,提升企业应用开发效率与协作能力。
OneCode图生代码技术深度解析:从可视化设计到注解驱动实现的全链路架构
|
2月前
|
缓存 前端开发 BI
如何开发门店业绩上报管理系统中的门店数据板块?(附架构图+流程图+代码参考)
门店业绩上报管理是将门店营业、动销、人效等数据按标准化流程上报至企业中台或BI系统,用于考核、分析和决策。其核心在于构建“数据底座”,涵盖门店信息管理、数据采集、校验、汇总与对接。实现时需解决数据脏、上报慢、分析无据等问题。本文详解了实现路径,包括系统架构、数据模型、业务流程、开发要点、三大代码块(数据库、后端、前端)及FAQ,助你构建高效门店数据管理体系。