一文看懂HTAP数据库TiDB

一文看懂HTAP数据库TiDB简介首先我们来看下TiDB官方的介绍:TiDB 是 PingCAP 公司自主设计、研发的开源分布式关系型数据库,是一款同时支持在线事务处理与在线分析处理 (Hybrid Transactional and Analytical Proces

欢迎大家来到IT世界,在知识的湖畔探索吧!

简介

首先我们来看下TiDB官方的介绍:TiDBPingCAP 公司自主设计、研发的开源分布式关系型数据库,是一款同时支持在线事务处理与在线分析处理 (Hybrid Transactional and Analytical Processing, HTAP) 的融合型分布式数据库产品,具备水平扩容或者缩容、金融级高可用、实时 HTAP、云原生的分布式数据库、兼容 MySQL 5.7 协议和 MySQL 生态等重要特性。

简单来说,HTAP数据库是同时支持联机事务处理 – OLTP(on-line transaction processing)和联机分析处理 – OLAP(On-Line Analytical Processing)场景的混合数据库。

为什么会出现HTAP数据库

在大数据时代,数字化进入场景大爆发,开源技术体系(例如:Hadoop体系)为大数据处理提供技术支撑,OLAP数据库对AP场景进行技术支撑。让我们来看下传统数据中台机构。

一文看懂HTAP数据库TiDB

传统数据中台架构

如图所示,可以看到TP业务数据会先进入数据中台,在传统数仓进行数据加工后再进入到OLTP数据库或者OLAP数据库中,对上提供业务技术支撑。随着数字化场景大爆发,业务的在线交易和在线分析一体化场景越来越多,包括“湖仓一体”、“流批一体”等场景都是用户在追求简化、融合的技术栈体验。而在传统的数据中台架构下,需要采用复杂的流式计算 + 批计算的架构来满足这些场景,不仅运维成本高,且扩展性、研发效能、时延都受到了限制。

在这种背景下,基于云原生的HTAP数据库就孕育而生了。下图是基于HTAP数据库的数据中台架构:

一文看懂HTAP数据库TiDB

HTAP数据中台

一文看懂HTAP数据库TiDB

统一实时数据平台架构

从架构变化上,我们可以看到整个架构变得更加清晰、简捷。且基于HTAP的特性,相对与传统的离线数仓,实时数据分析的时延大幅降低(从T+1 减低到 秒级);相对于流式计算,HTAP的研发效能大幅提升、运维成本大幅较低;相对于基于Hadoop体系的数据中台,新架构运维成本大幅降低,实时数据业务研发效能大幅提升。那HTAP数据库是怎么做到这些的呢?以下我们一起分析下TiDB。

TiDB的架构

TiDB本质上是双系统、双拷贝的HTAP系统。她有两种存储节点:TiKV和TiFlash。

  1. TiKV采用了行式存储,所谓的行式存储就是一行的数据会连续存放在相邻的位置,更适合OLTP场景。
  2. TiFlash采用了列式存储,含义就是不同行中不同列的数据会相邻存储在一起,更适合OLAP场景。

一文看懂HTAP数据库TiDB

TiDB HTAP架构图

从上图可见,实际TiDB有两套引擎,但是TiDB对用户侧提供的是一套查询入口,统一的权限和使用体验。让用户感觉起来是一套引擎。业务数据落到TiKV的同时,TiFlash会通过Raft协议同步数据,对TiDB集群的OLTP交易几乎没有影响,提供和TiDB保持强一致的数据读取,是真正的内核级HTAP分布式混合负载数据处理平台。

2021年4月,TiDBv5.0版本引入了MPP模式,使得TiFlash从存储节点升级成为一个全功能的分析引擎,OLTP和OLAP由优化器提供自动选择,大幅度缩短了分析查询的执行时间。

一文看懂HTAP数据库TiDB

TiDB MPP模式架构图

一文看懂HTAP数据库TiDB

未来一栈式实时数据服务平台

当小编看到TiDB构想的未来一栈式实时数据服务平台架构时,脑中的一个声音是:左边的传统OLTP还有存在的必要性吗?如果未来有基于HTAP的实时数仓系统,那右边的Hadoop体系技术栈还有必要出现在这图中吗?

再来看主流数据技术栈对比:

一文看懂HTAP数据库TiDB

主流数据技术栈能力象限

一文看懂HTAP数据库TiDB

主流数据技术栈表能力对比

四大核心场景

最后我们来看下TiDB官网的四大核心场景:

  • 对数据一致性及高可靠、系统高可用、可扩展性、容灾要求较高的金融行业属性的场景

众所周知,金融行业对数据一致性及高可靠、系统高可用、可扩展性、容灾要求较高。传统的解决方案是同城两个机房提供服务、异地一个机房提供数据容灾能力但不提供服务,此解决方案存在以下缺点:资源利用率低、维护成本高、RTO (Recovery Time Objective) 及 RPO (Recovery Point Objective) 无法真实达到企业所期望的值。TiDB 采用多副本 + Multi-Raft 协议的方式将数据调度到不同的机房、机架、机器,当部分机器出现故障时系统可自动进行切换,确保系统的 RTO <= 30s 及 RPO = 0。

  • 对存储容量、可扩展性、并发要求较高的海量数据及高并发的 OLTP 场景

随着业务的高速发展,数据呈现爆炸性的增长,传统的单机数据库无法满足因数据爆炸性的增长对数据库的容量要求,可行方案是采用分库分表的中间件产品或者 NewSQL 数据库替代、采用高端的存储设备等,其中性价比最大的是 NewSQL 数据库,例如:TiDB。TiDB 采用计算、存储分离的架构,可对计算、存储分别进行扩容和缩容,计算最大支持 512 节点,每个节点最大支持 1000 并发,集群容量最大支持 PB 级别。

  • Real-time HTAP 场景

随着 5G、物联网、人工智能的高速发展,企业所生产的数据会越来越多,其规模可能达到数百 TB 甚至 PB 级别,传统的解决方案是通过 OLTP 型数据库处理在线联机交易业务,通过 ETL 工具将数据同步到 OLAP 型数据库进行数据分析,这种处理方案存在存储成本高、实时性差等多方面的问题。TiDB 在 4.0 版本中引入列存储引擎 TiFlash 结合行存储引擎 TiKV 构建真正的 HTAP 数据库,在增加少量存储成本的情况下,可以同一个系统中做联机交易处理、实时数据分析,极大地节省企业的成本。

  • 数据汇聚、二次加工处理的场景

当前绝大部分企业的业务数据都分散在不同的系统中,没有一个统一的汇总,随着业务的发展,企业的决策层需要了解整个公司的业务状况以便及时做出决策,故需要将分散在各个系统的数据汇聚在同一个系统并进行二次加工处理生成 T+0 或 T+1 的报表。传统常见的解决方案是采用 ETL + Hadoop 来完成,但 Hadoop 体系太复杂,运维、存储成本太高无法满足用户的需求。与 Hadoop 相比,TiDB 就简单得多,业务通过 ETL 工具或者 TiDB 的同步工具将数据同步到 TiDB,在 TiDB 中可通过 SQL 直接生成报表。

免责声明:本站所有文章内容,图片,视频等均是来源于用户投稿和互联网及文摘转载整编而成,不代表本站观点,不承担相关法律责任。其著作权各归其原作者或其出版社所有。如发现本站有涉嫌抄袭侵权/违法违规的内容,侵犯到您的权益,请在线联系站长,一经查实,本站将立刻删除。 本文来自网络,若有侵权,请联系删除,如若转载,请注明出处:https://itzsg.com/79070.html

(0)

相关推荐

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注

联系我们YX

mu99908888

在线咨询: 微信交谈

邮件:itzsgw@126.com

工作时间:时刻准备着!

关注微信