clickhouse 大表数据归档处理解决办法

clickhouse 大表数据归档处理解决办法

一、需求场景

基于目前项目在各个应用上的数据采集，尤其是性能监控上的采集，数据量越来越大，例如pv数据的采集表三个月的数据量已经在6000w左右，数据量小的也有几百万，但是目前的常用的查询需求只用查询最近30内的数据，故此，考虑设计一种方案，可以将表中的数据维持在最近1个月上（视为热数据），之前的数据（视为冷数据）做归档处理，但是偶尔可能也会用来查询分析。

二、常见的大表数据处理办法

数据表分区：大多数数据库支持表分区，可以将大表分成多个小表（分区），每个分区在物理上可以作为一个独立的表进行处理。你可以根据数据的访问频率将数据分配到不同的分区，例如，将最近的数据放在一个高性能的存储设备上，将旧的数据放在一个低成本的存储设备上。

为什么要分区：表分区可以在区间内查询对应的数据，降低查询范围 并且索引分区 也可以进一步提高命中率，提升查询效率

分区是指将一个表的数据按照条件分布到不同的文件上面，未分区前都是存放在一个文件上面的，但是它还是指向的同一张表，只是把数据分散到了不同文件而已。

我们首先看一下分区有什么优缺点：

表分区有什么好处？

1. 与单个磁盘或文件系统分区相比，可以存储更多的数据。
2. 对于那些已经失去保存意义的数据，通常可以通过删除与那些数据有关的分区，很容易地删除那些数据。相反地，在某些情况下，添加新数据的过程又可以通过为那些新数据专门增加一个新的分区，来很方便地实现。
3. 一些查询可以得到极大的优化，这主要是借助于满足一个给定WHERE语句的数据可以只保存在一个或多个分区内，这样在查找时就不用查找其他剩余的分区。因为分区可以在创建了分区表后进行修改，所以在第一次配置分区方案时还不曾这么做时，可以重新组织数据，来提高那些常用查询的效率。
4. 涉及到例如SUM()和COUNT()这样聚合函数的查询，可以很容易地进行并行处理。这种查询的一个简单例子如 "SELECT salesperson_id, COUNT (orders) as order_total FROM sales GROUP BY salesperson_id；"。通过"并行"，这意味着该查询可以在每个分区上同时进行，最终结果只需通过总计所有分区得到的结果。
5. 通过跨多个磁盘来分散数据查询，来获得更大的查询吞吐量。

数据库分表

为什么要分表：分表后，显而易见，单表数据量降低，树的高度变低，查询经历的磁盘io变少，则可以提高效率

分表分为两种 水平分表和垂直分表

分库分表就是为了解决由于数据量过大而导致数据库性能降低的问题，将原来独立的数据库拆分成若干数据库组成 ，将数据大表拆分成若干数据表组成，使得单一数据库、单一数据表的数据量变小，从而达到提升数据库性能的目的。

水平分表

定义：数据表行的拆分，通俗点就是把数据按照某些规则拆分成多张表或者多个库来存放。分为库内分表和分库。 比如一个表有4000万数据，查询很慢，可以分到四个表，每个表有1000万数据

垂直分表

定义：列的拆分，根据表之间的相关性进行拆分。常见的就是一个表把不常用的字段和常用的字段就行拆分，然后利用主键关联。或者一个数据库里面有订单表和用户表，数据量都很大，进行垂直拆分，用户库存用户表的数据，订单库存订单表的数据

缺点：垂直分隔的缺点比较明显，数据不在一张表中，会增加join 或 union之类的操作

知道了两个知识后，我们来看一下分库分表的方案

1.取模方案：

拆分之前，先预估一下数据量。比如用户表有4000w数据，现在要把这些数据分到4个表user1 user2 uesr3 user4。 比如id = 17，17对4取模为1，加上 ，所以这条数据存到user2表。

注意：进行水平拆分后的表要去掉auto_increment自增长。这时候的id可以用一个id 自增长临时表获得，或者使用 redis incr的方法。

优点： 数据均匀的分到各个表中，出现热点问题的概率很低。

缺点：以后的数据扩容迁移比较困难难，当数据量变大之后，以前分到4个表现在要分到8个表，取模的值就变了，需要重新进行数据迁移。

2.range 范围方案

以范围进行拆分数据，就是在某个范围内的订单，存放到某个表中。比如id=12存放到user1表，id=1300万的存放到user2 表。

优点：有利于将来对数据的扩容

缺点：如果热点数据都存在一个表中，则压力都在一个表中，其他表没有压力。

我们看到以上两种方案 都存在缺点 但是却又是互补的，那么我们将这两个方案结合会怎样呢？

3.hash取模和range方案结合

如下图 我们可以看到 group 组存放id 为0~4000万的数据，然后有三个数据库 DB0 DB1 DB2，DB0里面有四个数据库，DB1 和DB2 有三个数据库

假如id为15000 然后对10取模（为啥对10 取模 因为有10个表），取0 然后 落在DB_0,然后在根据range 范围，落在Table_0 里面。 总结：采用hash取模和range方案结合 既可以避免热点数据的问题，也有利于将来对数据的扩容

方案三：冷热归档

为什么要冷热归档：其实原因和方案二类似，都是降低单表数据量，树的高度变低，查询经历的磁盘io变少，则可以提高效率 如果大家的业务数据，有明显的冷热区分，比如：只需要展示近一周或一个月的数据。那么这种情况这一周喝一个月的数据我们称之为热数据，其余数据为冷数据。那么我们可以将冷数据归档在其他的库表中，提高我们热数据的操作效率。

接下来讲一下归档的过程

1. 创建归档表 创建的归档表 原则上要与原表保持一致

2. 归档表数据的初始化

3. 新产生的数据也可以按照定时任务同步

4. 热数据读取DB1库

以上三种方案我们如何选型

三、制订适合的解决方案

根据上面三种处理方案，目前年轮适合第三种冷热归档分库的方案

综合考虑之后，选择了一个适合clickhouse的一个方案

热数据保持不变，还在default库中，同时各个分片使用复制表引擎，查询和新增数据操作一个分片就行，数据量只保留1个月的量，原先业务代码不用改变。

冷数据一迁移到archive库中，因为不是常操作数据，为节省空间及提高查询效率，故此采用clickhouse分布式表，查询统一经过分布式表聚合，冷数据平均的分布到各个节点上