写点什么

基于 TiDB 场景式技术架构过程 - 理论篇

  • 2022 年 7 月 11 日
  • 本文字数:4997 字

    阅读完需:约 16 分钟

原文来源:https://tidb.net/blog/cfb0408d

背景

从事数据架构多年,一直被问到一些问题,例如:what、why。


  • what:产品的数据架构是怎样的

  • why:为什么是怎样的,选型依据是怎么样的


我一直回答不好这个问题,一是因为从研发转向数据架构规划,自己一直处在学习中,二是解决的问题,在问题发生时都没有可参考的大厂经验,也是处在摸索阶段。最近数据架构逐渐稳定,从 TiDB 社区活动中也受益颇多,做了很多数据架构的思考,借着 6.0 的发布,谈一下自己总结的数据技术架构方法,通过一个案例,场景式展现整个设计过程。通过本文的一些描述,希望能够给初步踏上架构选型之路上的同学们一些帮助。

声明

数据架构的选型需要参考的因素很多,因能力有限,本文所述只是基于作者视角做的一些总结、分享,如有常识性错误,请及时通知作者修改。本文是从整体架构过程中,抽取数据架构有关的过程做分析,作为企业级架构过程参考可能有所不足。本文是一个架构理论总结,其 POC 过程尽量还原真实情况,可能存在疏漏,仅供参考。

数据架构的一般过程

总结我司多年的经验,数据架构的一般过程如下:


  1. 架构需求分析

  2. 技术产品选型

  3. POC 设计与测试

  4. 整体架构设计


各阶段输入 / 输出如下:



本文遵从上述数据架构设计的一般过程,从实际项目抽象一个典型的项目作为模板,叙述上述过程的具体实践。

架构需求分析

架构需求分析一般从系统需求说明书入手,本节抽取系统需求说明书中的一分部内容说明,最后形成技术需求矩阵、架构权衡点。

企业组织架构


组织说明:


  • 总公司:管理主体,对系统的主要诉求是浏览器端的各层级管理报表,实时大屏需求。

  • 分公司:实际的经营主体,对系统的主要诉求是浏览器端的实时管理报表,实时大屏,模型分析需求、标签。通过模型分析评价专卖店的运行情况,发现风险,通过标签分析本省或者本地区消费者的消费偏好,管理本省或者本地区营销活动。

  • 零售:分为店长端和店员端应用,店长端主要通过微信小程序浏览本店实时交易报表、管理库存、管理活动 / 折扣,店员端主要通过桌面端完成商品销售。

  • 消费者:消费者通过微信小程序完成附件店铺寻找、商品预览、活动预览等功能。

组件规划与特性分析

抽象上述各组织产品需求,设计模块如下:



应用模块技术需求分析:


  • 交易型应用:管理、交易、活动;强事务、高并发,活动开展时存在热点商品问题,此类功能相对固定,需求变更不多,但稳定性要求极高

  • 分析型应用:报表、大屏、标签、模型分析;低延迟、实时在线分析、海量离线计算,此类功能需求多,需求变更多,工作量占比在 80%,要求极度灵活的报表组织能力和数据分析能力

  • 接口型应用:应对第三方交易对接,接受或者输出实时、批量销售库存信息,此类功能遵循一个稳定的接口规范,变更较少,但要考虑流量消峰、数据审计、传输补偿等安全问题,技术比较复杂


根据咨询公司数据反馈,专卖店日均销售笔数为 60 笔,专卖店中的旗舰店,日均交易超过 1200 笔。单日估计最大订单数量 1000 万,即订单表单日存储数据量约 1000 万,一年的订单表数据 36 亿,按照以前的项目经验,仅估算交易数据,项目整体数据量一年约 72 亿。


非功能性约束:


  • 交易功能响应时间小于 1 秒,针对网络短暂不稳定的情况,需提供解决方案。管理应用响应时间小于 3 秒,分析型应用小于 3 秒

  • 需符合当前主流安全标准(非本文描述范围,也较为敏感,简单处理)

  • 实时分析需能查询三年以内的交易明细数据,3 年之外的交易数据可以做归档处理。归档数据需能够再次读取

  • 兼容目前主流云平台部署,可以实现基于云的弹性伸缩


硬件采购约束:


  • 硬件部署在自建机房

  • 硬件设备需按需投入,分阶段投入

  • 本次建设暂不考虑多中心设计

  • 基于成本原因,优先采用开源产品

技术需求矩阵

根据组织需求和产品模块设计,转化为对技术组件的需求:


客户背景分析

客户方属于成本敏感性一般的企业,对高端硬件的投入以实际需求为主,年初预算、年中采购、年末审计。客户方有独立的信息部门,但技术能力较弱,没有技术储备,信息部门的负责人思路较为超前,对新技术有较多了解,愿意采用较为先进的技术解决问题。

研发团队背景分析

研发团队有前端研发、后端研发、数据研发、运维四组人组成,前端研发与数据架构关系较小,不做介绍,其他三组人背景如下:


  • 后端研发:java 语言背景,以 28 岁以下年轻人为主,占比 80%,具有基本 java 研发能力与基本的 SQL 基础,剩余 20% 为 java 技术专家,负责封装基础组件,与中间件的交互,平台级组件

  • 数据研发:python 语言背景,spark 实践经验,SQL 较为熟练,以固化离线汇总需求、利用 python 建模、客户实时数据查询需求为主要工作内容

  • 运维:人数很少,多年 mysql 数据库运维经验,多团队共享一个运维团队,兼职 DBA 工作


研发团队最严重的问题是 DBA 与研发配置不合理,SQL 审核工作可能不到位,有线上 SQL 性能风险;运维为多个研发团队共享,运维工作需要高度工具化,减少、减轻运维工作量,才能保证项目正常开展。

权衡点矩阵

结合技术需求矩阵、客户背景分析、研发团队背景分析,跟相关技术架构决策者沟通后,总结架构权衡点如下:



设计此表格的目的是在架构选型时做评估用,类似于招标文件中的技术要求,各个数据库产品需要应标。表中的架构决策是指架构师和相关决策者根据经验增加的要求。

数据库架构选型

先画个图表看看我们到底需要哪种类型的数据库:


| | 分布式 | 集群 | 单机 | 云部署 | 本地部署 || —- | — | – | :- | :– | :— || OLTP | ✅ | ✅ | | | ✅ || OLAP | ✅ | ✅ | | | ✅ || HTAP | ✅ | ✅ | | | ✅ || KV | | | | | || 文档 | | | | | || 图数据库 | | | | | || 列簇 | | | | | || 时序 | | | | | || 空间 | | | | | || 内存 | ✅ | ✅ | | | ✅ || 搜索引擎 | ✅ | ✅ | | | ✅ |


内存数据库、搜索引擎因我司技术平台技术集成的原因,没有什么可选择性,采用 Redis、Elasticsearch,其他类型在这次规划中,可以重新选择。

OLTP 架构选型

目前 OLTP 类型的数据库,分为单体数据库和分布式数据库,基于本项目的数据量估算和成本原因,不采用开源单体数据库,采用开源分布式数据库,目前开源分布式数据库有三种架构方式:


  • 分库分表 + 中间件


说明:此种架构,在成熟的单体数据库与应用之间加数据代理层,在数据代理层中配置放置规则,实现数据分库分表、读写分离。优势:底层数据库较为成熟,成本低,稳定性好劣势:随着数据量的增大,分片规则、扩缩容等方面的工作面对较多挑战;如果做了读写分离,强一致性读很难保障,都需要加注解;集群可观测性不友好。


  • 去中心化的分布式数据库


说明:此种架构目前作为分布式的架构最为常见,也就是大家经常说的 Shared-nothing 架构。此架构节点之间不共享数据,可以平滑的扩缩容,通过共识算法保证多副本的可用性。优势:高内聚、低耦合;有较为广泛的应用;可以动态水平扩展;可保证强一致性。


  • 共享存储分布式数据库


说明:此架构多个计算节点共享一个存储集群,多个节点之间无需日志复制,用物理文件复制代替。优势:此种架构依赖于底层硬件的创新,例如非易失存储、远程直接数据存取等技术,我认为是未来分布式数据库发现的方向之一,由于减少了主从之间日志复制的环节,系统的稳定性有了更可靠的保障。劣势:目前类似技术被大厂绑定,常规采购很难低成本获得类似硬件,而且此类技术也不算成熟。

ETL 与 OLAP 架构选型

OLAP 的数据一般来源于 OLTP,可能会有第三方数据补充,ETL 一般伴随着 TP 和 AP 选型的不同而改变从 OLTP 同步数据到 OLAP,存在四种方式:


  • 定时抽取


说明:此架构通过设置每日定时任务,根据 timestamp 等字段,抽取每日增量到分析库,基于分析库做离线计算与在线分析。优势:实现简单,工具成熟劣势:实时性不足;抽取过程容易干扰 TP 正常业务;抽取一般在凌晨,一旦抽取失败,工作时间发现并修复,会严重干扰 TP 业务。


  • 实时同步


说明:此架构通过 TP 数据库的 CDC 技术同步数据到流处理平台,AP 数据库主动或者被动从流处理平台获取增量数据,批量回放到库表中。优势:数据相对实时;对 TP 干扰小;随时进行数据回放修复同步错误。劣势:无法保证强一致性;一般需要在应用端建立两个数据源,应用开发人员需要分清楚 TP 和 AP 业务。


  • 日志同步


说明:此架构常见于 HTAP 数据库,数据库内建 TP 和 AP 两个存储模型,TP 和 AP 之间通过日志同步,应用通过一个统一入口访问,访问入口根据 SQL 代价或者其他评估方案自动采用不同引擎提供服务,不必感知底层实现。优势:TP 和 AP 之间可以保证强一致性;应用无需过多关心底层实现,通过一个入口访问。劣势:对硬件有较高要求


  • 共享存储


说明:此架构的 TP 和 AP 引擎公用一个共享存储,数据不存在复制过程。优势:没有日志的逻辑复制过程,用物理文件复制代替(共享存储特性),实时性好,系统负担小。劣势:技术不太成熟,依赖于新的硬件,例如非易失存储、远程直接数据存取等技术。

模型、标签架构选型

受研发团队背景和模块复用要求的限制,模型、标签复用 python(Jupyter Notebook)、spark(SparkSQL) 等已经实现的组件,不再过多考虑其他方案。

备选产品圈定

首先参考一下,墨天伦的排名,筛选开源、关系型数据库,选取 TOP5 如下:



根据架构权衡点的要求,所选定数据库要求本地部署、兼容 MySQL 协议,排除 PolarDB、GaussDB、openGauss,只剩下 TiDB、OceanBase,根据权衡点,绘制对组件情况如下:



在社区方面的表现见下表(数据截止到 20220601):



OceanBase 盛名已久,但因为开源时间晚于 TiDB,数据上并不好看,但 OceanBase 的发版方式,让开源版本与商业版本的核心特性有较大差距,TiDB 的开源版本与商业版本是同一套代码,开源用户完全可以跟随版本发布使用到最新的特性和 BUG 修复,在这一点上 TiDB 比 OceanBase 更具有优势。可观测性对数据库的运维十分重要,TiDB 的流量可视化可以更直观的观测到读写热点,Clinic 可以一键打通本地环境与社区专家的沟通渠道,这两方面也具有一定优势。根据以上分析,本次架构设计中 TiDB 列为 POC 测试产品,OceanBase 列为备选产品。

POC 设计与测试

POC 设计一般考虑几个方面的功能:


  1. 核心业务场景:核心业务场景是指数据库上线之后需要解决的关键场景,核心业务场景支持不好,可以一票否决数据库选型。

  2. 典型性能场景:典型性能场景是指系统可能会遇到的高并发、热点读写场景,是数据库选型在本项目中的能力上线,通常类似场景也会涉及到内存数据库与关系型数据库的配合,需要根据场景,提出合理解决方案,并尝试靠近设计目标。

  3. 价值导向场景:价值导向场景一般指项目甲方的关键人员所使用的功能场景,如果保障此类场景的稳定,需要通过架构设、资源隔离等多种手段达到目标。根据前文功能设计,选取 POC 场景如下:

  4. 压力测试 - 登录:测试登录性能瓶颈

  5. 压力测试 - 订单提交:测试订单提交性能瓶颈

  6. 压力测试 - 商品信息查询:测试商品信息查询瓶颈,由于存在多级缓存,最终测试结果并不能表达关系型数据库的能力。

  7. 压力测试 - 三表关联性能测试:选取典型的报表查询 SQL,至少是三表关联的查询

  8. 稳定性测试 - 登录:由于客户场景存在持续性压力高峰,对登录做超过 6 小时的稳压测试

  9. 稳定性测试 - 热点混合场景:由于客户场景存在持续性压力高峰,对 1、2、3 三个场景做混合负载稳压测试

  10. 稳定性测试 -HTAP 混合场景:由于客户场景存在持续性压力高峰,2、4 两个场景做混合负载稳压测试


我们一般使用 metesphere 或者 jmeter 测试。metesphere 一般用于正式环境压力测试,有很多优秀的特性,部署时需要有一定的资源保障,jmeter 即开即用,兼容多种测试场景,本文截取 jmeter 的部分截图做一些展示和说明。jmeter 截图:



grafana 截图:



其实简言之,就是在 average 合理的范围区间里(一般是非功能性需求,订单提交 1 秒之内,查询 3 秒之内),当 cpu、内存、磁盘 IO 达到 100% 时,Throughput 稳定在哪个值,这个值就是并发。经过多轮参数调整和回归测试,最后得到的最大值就是最优并发。

总体数据架构设计

总体架构设计由于牵扯到很多本文不涉及的内容,这里就不详述了。

总结

本文虽然基于 TiDB 6.0 进行选型,但并不详述 TiDB 6.0 的新特性,也不是实践类文章,鉴于在有限的篇幅中想要描述一个很复杂的事情,行文稍显啰嗦,请各位海涵,并多多指导,帮助作者改进。


发布于: 刚刚阅读数: 3
用户头像

TiDB 社区官网:https://tidb.net/ 2021.12.15 加入

TiDB 社区干货传送门是由 TiDB 社区中布道师组委会自发组织的 TiDB 社区优质内容对外宣布的栏目,旨在加深 TiDBer 之间的交流和学习。一起构建有爱、互助、共创共建的 TiDB 社区 https://tidb.net/

评论

发布
暂无评论
基于 TiDB 场景式技术架构过程 - 理论篇_数据库架构选型_TiDB 社区干货传送门_InfoQ写作社区