Databend 特性系列（1）｜Databend 数据生命周期

Databend 是一个使用 Rust 研发、开源、完全面向云架构的新式数仓，提供极速的弹性扩展能力，致力于打造按需、按量的 Data Cloud 产品体验。具备以下特点：

开源 Cloud Data Warehouse 明星项目
Vectorized Execution 和 Pull&Push-Based Processor Model
真正的存储、计算分离架构，高性能、低成本，按需按量使用
完整的数据库支持，兼容 MySQL ，Clickhouse 协议
完善的事务性，支持 Time Travel, Database Clone， Data Share 等功能
支持基于同一份数据的多租户读写、共享操作

现在使用 Databend 的用户越来越多后，大家面临一个问题，使用 Databend 如何备份呢？是不是需要如同 MySQL 一样每天做一个物理备份或是逻辑备份呢？答案是：可能还有更好的办法。这篇文章和大家聊一下 Databend 中数据的生命周期，然后再来看 Databend 如何做备份管理。

首先我们来看一下 Databend 的架构

Databend 的写入操作是有事务性保证，基于事务隔离 RR 实现的，底层的数据存储是基于对象存储，实质上数据的持久化安全也是依赖于底层的对象存储，所以选择云厂商的 S3, OSS, COS 也是不错的选择，如果是自建的 minio, ceph 一定要做集群保证。因为是基于对象存储写入，所以任务的写入都可以理解为是一个增量操作，这也让 Databend 省掉了日志管理，更多的需要把表和对应的 snapshot 关联起来就可以让数据恢复到任意的时间点。接下来分 4 个方面看看 Databend 如何利用对象存储实现一个无须备份，但数据永远不丢失的方案。

Databend 数据生命周期核心：Snapshot

在讲 Databend snapshot 之前，抛出来一个问题：

如果想访问一个表 5 分钟前的数据怎么处理，
一个 delete from tb ; 没有 where 条件怎么恢复？

如果在别的数据库这两个需求，基本都是灾难。但在 Databend 中，这些是非常轻松可以完成的。演示如下：


MySQL [default]> create table d_tb1(c1 int, c2 varchar);
 
Query OK, 0 rows affected (0.011 sec)
 
MySQL [default]> insert into d_tb1 values(1,'databend');
Query OK, 0 rows affected (0.018 sec)
 
MySQL [default]> insert into d_tb1 values(2,'MySQL');
 
Query OK, 0 rows affected (0.016 sec)
 
MySQL [default]> insert into d_tb1 values(3,'Hive');
 
Query OK, 0 rows affected (0.016 sec)
 
MySQL [default]> insert into d_tb1 values(4,'Hbase');
 
Query OK, 0 rows affected (0.016 sec)
MySQL [default]> select * from d_tb1;
+------+----------+
| c1   | c2       |
+------+----------+
|    1 | databend |
|    3 | Hive     |
|    2 | MySQL    |
|    4 | Hbase    |
+------+----------+
4 rows in set (0.018 sec)

基于 snapshot 读取数据

总共写入了 4 行数据，我们来看一下对应的 snapshot 相关的数据：


MySQL [default]> select snapshot_id,previous_snapshot_id, timestamp from fuse_snapshot('default','d_tb1');
+----------------------------------+----------------------------------+----------------------------+
| snapshot_id                      | previous_snapshot_id             | timestamp                  |
+----------------------------------+----------------------------------+----------------------------+
| b031e57aa06443cc9d3ffadb3023dec6 | 34b8df220edc4d8cb9e3e76118788686 | 2022-08-30 01:19:06.367120 |
| 34b8df220edc4d8cb9e3e76118788686 | 4bb479751b7144d8aa2b53e5b281453f | 2022-08-30 01:18:53.202724 |
| 4bb479751b7144d8aa2b53e5b281453f | a2801ed9656d42c9812f2921214f0795 | 2022-08-30 01:18:35.597615 |
| a2801ed9656d42c9812f2921214f0795 | NULL                             | 2022-08-30 01:18:21.750208 |
+----------------------------------+----------------------------------+----------------------------+
4 rows in set (0.007 sec)

我们看到 previouse_snapshot_id 为 NULL 是第一次写入的操作。对应的数据是：insert into d_tb1 values(1,'databend');如果想读取这个 snapshot 的数据方法：


MySQL [default]> select * from d_tb1 at(SNAPSHOT=>'a2801ed9656d42c9812f2921214f0795');
+------+----------+
| c1   | c2       |
+------+----------+
|    1 | databend |
+------+----------+
1 row in set (0.010 sec)

看到这里是不是觉得这里充满了魔法了。同样也可以使用时间来访问历史的数据：


MySQL [default]> select * from d_tb1 at(timestamp=>'2022-08-30 01:18:21.750208'::timestamp);
+------+----------+
| c1   | c2       |
+------+----------+
|    1 | databend |
+------+----------+
1 row in set (0.010 sec)

这个时间不用精确值，只用比当行对应的 timestamp 值大，小于上面一行的 timestamp 就可以获取对应的精确数据。

再来看一下 delete 没有 where 条件的操作:


MySQL [default]> delete from d_tb1;
Query OK, 0 rows affected (0.012 sec)
 
MySQL [default]> select * from d_tb1;
Empty set (0.010 sec)
MySQL [default]> select snapshot_id,previous_snapshot_id, timestamp from fuse_snapshot('default','d_tb1');
+----------------------------------+----------------------------------+----------------------------+
| snapshot_id                      | previous_snapshot_id             | timestamp                  |
+----------------------------------+----------------------------------+----------------------------+
| ec52197b4c344f8d8a353eff8a812de7 | b031e57aa06443cc9d3ffadb3023dec6 | 2022-08-30 01:32:03.227960 |
| b031e57aa06443cc9d3ffadb3023dec6 | 34b8df220edc4d8cb9e3e76118788686 | 2022-08-30 01:19:06.367120 |
| 34b8df220edc4d8cb9e3e76118788686 | 4bb479751b7144d8aa2b53e5b281453f | 2022-08-30 01:18:53.202724 |
| 4bb479751b7144d8aa2b53e5b281453f | a2801ed9656d42c9812f2921214f0795 | 2022-08-30 01:18:35.597615 |
| a2801ed9656d42c9812f2921214f0795 | NULL                             | 2022-08-30 01:18:21.750208 |
+----------------------------------+----------------------------------+----------------------------+
5 rows in set (0.007 sec)

从上面的 snapshot 来看，增加一个新的 snapshot，所以我们为了访问 delete 的数据，就可以利用 at 语句访问前一个 snapshot 就可以，如下：


MySQL [default]> select * from d_tb1 at(snapshot=>'ec52197b4c344f8d8a353eff8a812de7');
Empty set (0.010 sec)
MySQL [default]> select * from d_tb1 at(snapshot=>'b031e57aa06443cc9d3ffadb3023dec6');
+------+----------+
| c1   | c2       |
+------+----------+
|    3 | Hive     |
|    4 | Hbase    |
|    2 | MySQL    |
|    1 | databend |
+------+----------+
4 rows in set (0.011 sec)

恢复这个表，也可以考虑:

create table d_tb1_new as select * from d_tb1 at(snapshot=>'b031e57aa06443cc9d3ffadb3023dec6');

再进行 rename 操作即可。关于 at 语法参考：https://databend.rs/doc/reference/sql/query-syntax/dml-at这些特性也是依赖于 Databend 使用底层时使用的对象存储，所有的写入都是增量写入。例如：对于 Delete 也只是操作的 meta 并没有真正的删除数据。这也是 Databend 的一个特性：Time travle。

Snapshot 终极大招

在上面的演示中，我们看到利用 Databend 的 at 语句加上 snapshot 和 timestamp 实现对表任意时间点和操作前的访问。在最后恢复数据时，我们还需要借助于建一个新表，然后 Select 出来数据，然后对外访问。那有没有更快的方法呢？Databend 永远不会让你失望，当然更快的方法。接下来给你演示一下。首先我们来一下 d_tb1 和 snapshot_location 对应关系：


MySQL [default]> select snapshot_id, snapshot_location from fuse_snapshot('default','d_tb1');
+----------------------------------+------------------------------------------------------+
| snapshot_id                      | snapshot_location                                    |
+----------------------------------+------------------------------------------------------+
| ec52197b4c344f8d8a353eff8a812de7 | 1/15967/_ss/ec52197b4c344f8d8a353eff8a812de7_v1.json |
| b031e57aa06443cc9d3ffadb3023dec6 | 1/15967/_ss/b031e57aa06443cc9d3ffadb3023dec6_v1.json |
| 34b8df220edc4d8cb9e3e76118788686 | 1/15967/_ss/34b8df220edc4d8cb9e3e76118788686_v1.json |
| 4bb479751b7144d8aa2b53e5b281453f | 1/15967/_ss/4bb479751b7144d8aa2b53e5b281453f_v1.json |
| a2801ed9656d42c9812f2921214f0795 | 1/15967/_ss/a2801ed9656d42c9812f2921214f0795_v1.json |
+----------------------------------+------------------------------------------------------+
5 rows in set (0.007 sec)
 
MySQL [default]> show create table d_tb1;
+-------+------------------------------------------------------------------------------------------------------------------------------------------+
| Table | Create Table                                                                                                                             |
+-------+------------------------------------------------------------------------------------------------------------------------------------------+
| d_tb1 | CREATE TABLE `d_tb1` (
  `c1` INT,
  `c2` VARCHAR
) ENGINE=FUSE SNAPSHOT_LOCATION='1/15967/_ss/ec52197b4c344f8d8a353eff8a812de7_v1.json' |
+-------+------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.006 sec)

从上面的信息中可以看来，每个表后面通过 SNAPSHOT_LOCATION 的对应的版本对应起来。那么如果我们创建一个基于前面 snapshot_id 对应的 snapshot_location 对应的位置，会怎么样呢？来操作一下：


MySQL [default]> CREATE TABLE `d_tb2` (
    ->   `c1` INT,
    ->   `c2` VARCHAR
    -> ) ENGINE=FUSE SNAPSHOT_LOCATION='1/15967/_ss/b031e57aa06443cc9d3ffadb3023dec6_v1.json';
Query OK, 0 rows affected (0.013 sec)
 
MySQL [default]> select * from d_tb2;
+------+----------+
| c1   | c2       |
+------+----------+
|    3 | Hive     |
|    1 | databend |
|    2 | MySQL    |
|    4 | Hbase    |
+------+----------+
4 rows in set (0.010 sec)

可以看到数据又回来了。这样也可以通过 rename 的方式直接对外，提供服务。是不是感觉到更神奇。基于 Snapshot 的引用创建表，也是我们 Databend 数据 Share 的一个核心。Snapshot 方式的数据管理，也让 Databend 天然具备了 RR 事务隔离级的读写操作。

总结

在上面的文章中我们演示了 snapshot 在 Databend 对于数据生命周期的访问控制。这里有一个核心就是云对象存储不能炸了。在这个前题下，如果备份 Databend 的数据可以有以下几种方法：

每天备份一下对应的表结构。
每天备份一下对应表的 fuse_snapshot 对应输出。
如果是自建的存储可以增加副本数来增加安全性。

关于 Databend

Databend 是一款开源、弹性、低成本，基于对象存储也可以做实时分析的新式数仓。期待您的关注，一起探索云原生数仓解决方案，打造新一代开源 Data Cloud。

Databend 文档：Databend - Activate your Object Storage for real-time analytics | Databend
Twitter：https://twitter.com/Datafuse_Labs
Slack：Slack
Wechat：Databend
GitHub ：GitHub - datafuselabs/databend: A modern Elasticity and Performance cloud data warehouse, activate your object storage for real-time analytics. Databend Serverless at https://app.databend.com/

文章首发于公众号：Databend

相关阅读:
Postman 如何获取请求结果并设置到请求头中
 24.Ubuntu新磁盘挂载
 Spring Webflux DispatcherHandler源码整理
 边缘检测算法
 HTTP 代理服务器的设计与实现（C++）
vivado产生报告阅读分析5-时序报告1
（二十）大数据实战——Flume数据采集的基本案例实战
 每天 20 题吃透这份将近 500 页的“Java 工程师八股文”，成功入职阿里
 安全防御——防火墙二
 uniapp 高德地图与百度地图精准定位,高德地图定位报错
原文地址：https://blog.csdn.net/Databend/article/details/126868053