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

前言

如何来存储比较大的业务数据，例如比较大系统的报表数据，这些数据通过大数据的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.

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

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

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

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

如下图所示：

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

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

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

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。

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