感谢光普老师给我们带来了优质的分享 @guangpu
虽然是刚刚发现的内容，虽到但迟！
PPT 预览
本次分享的主要内容：
- 为什么选择 Databend 归档 TiDB
- 归档工具，归档的流程，实践效果
- 归档实践总结，对 Databend 未来的展望
为什么选择 Databend 归档 TiDB
TiDB 在多点 DMALL 使用的非常好。可以实现透明扩展， 研发无感，数据增加，架构不变；TiDB 在使用中给人的感觉是没有容量限制，支持更多的数据；在 TiDB 中扩容更便捷，加节点即扩容，自动 Rebalance。基于以上优点，TiDB 越用越舒服，但成本也就越来越高。
上图多点 DMALL TiDB 某集群现在跑在腾讯云上总共 24 个节点，每个节点近 3 T+ 空间（NVME 磁盘)，现在总数据量 60 T 了， QPS 接近 10 万 。数据还在不断的上升中，所以考虑需要对 TiDB 进行归档存储。
在选择归档时，分 4 个方面做了对比：
- 存储成本：对象存储和 HDD, SSD 的成本，其中对象存储是 HDD 的1/10, 是 SSD 的 1/30,
- 在线查询能力：但数据又不能直接放到对象存储中，还需要提供对外的查询能力，
- 支持大表持续备份：这块也调研了 MariaDB on S3，需要先写入 InnoDB，然后在转成只读的 s3 engine ,这样备份 10 TB 的表，本地也要有 10 TB 的空间， Databend 是直接写入对象存储。
- 兼容 MySQL 协议：可以保持 TiDB 的使用习惯。
基于以上条件的对比，最终多点 DMALL 选择了 Databend 。多点 Databend 的部署架构如下：
其中 Databend-query 有点类似于 MySQL server 直接连接对象存储，对于用户管理，权限，meta 信息存储在 Databend-meta 中，这个节点可以单点部署，生产中也可以部署成集群模式。
归档工具、归档流程、实践效果
DMALL 研发一个新的归档工具，工作流程如下：
- 先做归档表结构到 Databend 创建
- 基于小批量读取源端到 Channel 中，同时检测源端压力，如果源端压力大，降低读取速度，如果压力小，就可以加大读取
- Databend 端写入时，可以合并写入，实现更大的 batch
- 在 Databend 写入成功后，再去源端删除，保证数据安全
归档任务，由开发人员发起，DBA 审核，自动化归档，数据永久保留。基于上面的方法，可以实现开发人员，查询 2,3 年前的数据，也可以自助完成。
多点采用的单表按 10 M 每个 Batch 写入，评估一天单表可以归档 1.3 T 数据，单集群对于表没有限制，可以根据任务去并发写 Databend 集群，这样一天的量基本非常可观。另外这块，多点 DMALL 也对比了 MySQL，TiDB，Databend 数据压缩能力：
在 MySQL 中占用 150 G 数据，导入 TiDB 中占用：25 G， 在 Databend 中占用：18 G（只有一个副本，数据可用性靠对象存储保证)。
基于成本方面的考查：数据从 TiDB 到 Databend 从 3 副本到 1 份数据（对象存储帮搞定副本），对象存储不需要预留，按实际付费，单价仅是 HDD，SSD 成本的 1/10-1/30 。DMALL 这边使用 Databend 做 TiDB 的归档后，存储成本仅仅是原来存储成本的 2%。
归档实践总结，对 Databend 未来的展望
在归档场景下 Databend 优势：
- 降本显著：基于对象存储，冷数据存储成本除低 98%，如果你是 SSD 到对象存储，基可以达到 99% 以上的降本。
- 云中立：支持 AWS， Azure，GCP，阿里云，腾讯云，华为云，青云，火山引擎，minio，ceph 等
- 研发友好：MySQL 协议兼容，可在线查询，统计分析性能好
- 运维无忧：无限空间，高可靠性，免维护，迁移便捷
最后冯光普提出希望 Databend 生态方面更加的完善，例如，可以更加完善 TP 到 Databend 的数据同步据，进一步的融合 TP + AP 的能力。
视频回放：
PPT 下载
基于Databend的TiDB数据归档实践-V2.pdf (1.3 MB)
来源：多点《基于 Databend 的 TiDB 数据归档实践》 | Data Infra 分享第 4 期总结 - 知乎
