如何来存储比较大的业务数据

如何来存储比较大的业务数据

前言

如何来存储比较大的业务数据,例如比较大系统的报表数据,这些数据通过大数据的ETL转换之后,输出到一个地方供业务查询,数据特点是生成之后一般不会改变(除非数据产出错误,重新计算)。

前几篇文章都是说了,大数据的存储和计算方式,经过一系列的计算,输出的数据都是精华数据了。但是对大的平台来说,这个数据量也是非常大的。

一个 比较大的业务数据。例如 大型电商的用户数据。还有平台用户的报表数据。

我们的使用场景也是用在了平台用户的报表数据这块,实现了很大级别的用户的广告报表数据。这个数据量特别的大,并且还有一个特点就是分步不均,比较大的用户,数据量占用非常的多。

这些数据都比较大、非常多。

今天来说一个解决方案,这就是 腾讯云的 Tbase,

Tbase 是腾讯开发,已经开源:

https://github.com/Tencent/TBase

介绍

TBase is an advanced enterprise-level database management system based on prior work of Postgres-XL project. It supports an extended subset of the SQL standard, including transactions, foreign keys, user-defined types and functions. Additional, it adds parallel computing, security, management, audit and other functions.

image.png

在腾讯云上也有相应的服务:

TDSQL PostgreSQL 版(TDSQL for PostgreSQL, 原 TBase)是腾讯自主研发的分布式数据库系统,具备高 SQL 兼容度、完整分布式事务、高安全、高扩展、多级容灾等能力,成功应用在金融、政府、电信等行业核心业务中。同时提供完善的容灾、备份、监控、审计等全套方案,适用于GB~PB级海量 HTAP 场景。

image.png

一 Tbase 是如何解决大数据存储的问题呢 ?

先从Tbase的架构说起,其中GTM负责分布式事务管理,DataNode负责存储数据,Coordinator负责对数据进行分发、聚合等操作,Coordinator本身不负责保存业务数据。Coordinator通过将分布Key上值进行Hash路由到各个DataNode上。

如下图所示:

Tbase架构

二、防数据倾斜,这个是为了解决平台有用户占用数据量特别大的情况

数据分布不均衡和负载分布不均衡在分布式系统中天然存在,数据倾斜导致负载和数据集中在少数节点,进而严重影响集群的扩展甚至正常运行。解决数据倾斜,如何保证集群内各个节点负载尽量均衡从而降低成本,是数据治理的最主要目标之一。

通过分析,我们发现数据倾斜的两个原因:

1、 分片方案导致的倾斜:例如我们按(月份)时间进行分片,很明显某些做活动的月份,数据量会特别大,进而导致某个正好承载该月数据的DataNode负载和数据特别大。

2、 拆分列(Distribute Key)本身引入的倾斜:因为业务数据本身的特征,导致在某个分布Key值的记录数特别多,例如交易类业务,以账户ID作为关键字,然而某账户ID交易量特别大,也会导致数据倾斜。

首先,Tbase的分片策略是基于Hash,Hash后的数据分布被打散,而通过管理shardmap,也可以让数据均匀的写入DataNode。

同时,通过shardmap的动态管理, PGXZ可以动态将部分数据从负载较高的节点迁移到负载较低的节点,进而保证进一步的均衡。当然,这里的分片策略不仅仅是来解决倾斜

针对第二种关键字(Distribute Key)本身引入的倾斜,如系统中有一个比较大的账户,采用动态迁移数据本身已经无法解决数据倾斜的问题了,

因为大账户的数据量和负载要求甚至超出一个DataNode物理上限。我们分析,大多数业务都存在2/8原则,即前20%账户可能产生超过80%的数据,

这是所有比较大的业务系统都会遇到的问题,例如包括银行业务、社保业务、电商业务都存在类似情况。

Tbase为了解决这种问题,引入了虚拟节点组技术,即由多个DataNode组成一个(或多个)虚拟的DataNode(组),来承载那仅有20%商户产生的80%的交易和数据(如下图Huge Key Group)。

三、冷热数据分离,这个是为了解决数据时效性的问题

在数据治理过程中,成本一直是我们关注的地方。在大部分数据库系统中,数据有明显的冷热特征。显然当前的订单被访问的概率比半年前的订单要高的多。报表数据对一个用户来说,两年前的数据参考意义可能就不大了。

根据经验来讲,越是数据量增长快的系统,这种冷热特征越明显。将冷数据存储到带有大容量磁盘的服务器上,将热数据放在价格更昂贵的ssd上明显更合理。传统方案是通过拆解系统,

但Tbase通过将冷热数据分布存储到Cold Group/Hot Group来大幅度降低硬件成本。

以下图架构是一套完整的架构举例,Tbase将DataNode从冷/热、大Key/小Key 两个维度分成四个

Group:Small Key Group(Hot):存储小Key、热数据;

Small Key Group(Cold):存储小Key、冷数据;

Huge Key Group(Hot):存储大Key、热数据;

Huge Key Group(Cold):存储大Key、冷数据

每一个DataNode Group都有独立的ShardMap空间(shard到datanode的映射表);

每一个DataNode Group都有不同的Hash策略。比如,对于每一个record,Coodinator(CN)首先会根据DistributedKey和create time判断该record路由到哪一个group。

然后采用这个group内的hash策略、并查找这个group的shardmap进一步路由到某一个DataNode。

通过这几个方法就可以解决大的业务数据存储和查询的问题。

原创文章,作者:carmelaweatherly,如若转载,请注明出处:https://blog.ytso.com/212286.html

(0)
上一篇 2021年12月16日
下一篇 2021年12月16日

相关推荐

发表回复

登录后才能评论