关于 TiDB 对接数据仓库的一些思考

作者： 数据小黑

背景

最近 TiDB V6.5.0 发版(详见:release-6.5.0)作为一个沉浸在数据中多年的老同志，我对一个特点特别感兴趣: 从 v6.5.0 开始，TiCDC 支持将行变事件保存到存储服务中，例如 Amazon S3、Azure Blob Storage 和 NFS。参考：使用指南 简而言之，这个特性可以通过 TiCDC 这个组件可以保存 CDC 这一特性满足了我对数据架构的一些想象，例如：

1. 数据链路足够短
2. 尽可能少的同步组件

结合这一特点，基于最近的一些实际需求和 POC 我想谈谈结果 TiDB 搭配的数据仓库应该是什么样的，能否有一个足够简单的架构来搭建一个适合大多数云的数据仓库。

什么是数据仓库，什么是数据湖？

数据仓库，英文名称 Data Warehouse，可简写为 DW 或 DWH。数据仓库是为企业各级决策过程提供各类数据支持的战略集合。它是为了分析报告和决策支持而创建的单个数据存储。 为需要业务智能的企业提供指导业务流程改进、监控时间、成本、质量和控制。 如何理解上述解释，数据仓库根据我们遇到的客户需求做这些事情：

1. 大型企业有各种各样的内部系统。一般来说，这些业务系统的建设时间、制造商甚至底层数据产品都有很大的差异。领导者需要一个架构来整合数据，这取决于整体情况、大数字和趋势。这个架构被称为数据仓库
2. 企业数据相对单一，企业通过各种渠道收集各种数据进行分析，此时需要一个架构来解决数据收集存储、计算、服务等问题，该架构称为数据仓库

在整合之前，可以准确认识上述需求整合的数据，了解整合的目的。

假设企业基于战略目的，先实施数据收集动作，再从收集的数据中挖掘价值，此时的架构应称为数据湖。

这篇文章不纠结于这两个概念，只是想讨论一个场景:

1. 业务应用的后端数据库是 TiDB
2. 对长期历史数据进行分析的需求
3. 需要接入第三方数据综合分析
4. 硬件投资有限，需要合理的架构来充分发挥硬件性能
5. 客户的部署环境不确定，需要适应大多数云

这是我们实际遇到的需求，我们也做了一些思考和思考 POC 测试。

TiDB 与数据仓库共建的必要性

对 TiDB 了解更多的人会知道 TiDB 有两个组件可以解决 AP 侧的问题： 1.TiFlash：TiFlash 是 TiDB HTAP 形态的关键组件，它是形态的关键组件 TiKV 列存扩展不仅提供了良好的隔离性，而且兼顾了强一致性。列存副本通过 Raft Learner 协议异步复制，但读取时通过 Raft 校对索引配合 MVCC 的方式获得 Snapshot Isolation 一致性隔离等级。这种结构得到了很好的解决 HTAP 场景的隔离和同步列存的问题。 2.TiSpark：TiSpark 是 PingCAP 为了解决用户的复杂性 OLAP 需求推出的产品。它借助 Spark 同时整合平台 TiKV 分布式集群的优势和 TiDB 为用户提供一站式解决方案 HTAP (Hybrid Transactional/Analytical Processing) 的需求。 TiFlash 和 TiSpark 允许使用多个主机 OLTP 数据上执行 OLAP 查询。TiFlash 列式存储提供了更有效的分析和查询。TiFlash 和 TiSpark 可同时使用。 我们已经在多个场景中组合使用了它 TiFlash 和 TiSpark，在我们的应用场景中，数据流通如下图所示：

这种结构解决了我们的问题，但有一个小缺点，那就是成本相对较高。

1. 从数据同步链路来看，数据需要在计算完成后通过 TiKV 写到 TiFlash，这种做法不太经济
2. 在硬件成本方面，为了保证数据写入效率，TiKV 和 TiFlash 我们给的硬件都比较好。由于各种因素的影响，我们没有在较差的硬件下进行测试。因此，在较差的硬件条件下，我们没有实际数据或信心进行测试
3. 就架构设计而言：如果要访问第三方数据，则完全没有必要访问第三方数据 TiKV 再走一遍，这些数据只是作为分析的需要，没有必要占用 TP 的资源

随着客户的发展，我们现在遇到了一些问题：

1. 客户分析需求的爆炸性增长通常要求我们在有限的成本下尽可能提高效率
2. 数据采集方法复杂多样，一不小心就对了 TP 侧面产生影响，我们增加了消息队列进行峰值处理

基于以上分析，简单使用 TiFlash、TiSpark 它不能完全满足我们的需求。基于我们多年的技术积累，我们建立了一套跟踪 TiDB 通过数据仓库架构，具有成本低、多云适应的特点，下一节做一些分析，供您参考。

打通 TiDB 以及数据仓库的建设理念

让我们来看看当前通用的大数据架构：

在设计数据架构时，由于数据规模的原因采用了数据架构 hadoop 理论上，以系统为基础， TiDB 在推广项目的过程中，我们发现了一些问题：

1. 客户投资不多，hadoop 云产品太贵了，客户没有购买，我们不能迁移
2. 客户投资充裕，被云厂商洗脑，只买了 hadoop serverless 各厂家的版本 api 和 sql 规范不同，导致我们一个项目有一套代码
3. 有些项目前期数据规模不大，客户对提前投入一套大数据产品不太了解。基于这个架构，我们无法实现伸缩自由

基于上述原因，我们计划研究一套替代品 hadoop 对于一些主要环节，我们做出了一些决定：

1. 存储产品：基础 OSS 存储在云产品中的地位和性价比 OSS
2. 计算环境：采用事实标准，我们不想投资人力管理计算资源的调度 k8s 调度资源
3. api 形式：我们原来的计算过程需要编程，我们计划在这个架构设计中提供 JDBC 接口，类似于创建一个 serverless 的计算服务

我们设计的架构如下：

与之前的架构相比，我们没有部署任何组件 k8s k8实现了计算调度和数据访问s 和对大象存储不需要我们的管理和维护，减少了我们的大部分操作和维护工作。基于 k8s 以及对象存储的通用性，我们的架构可以在大多数云上无缝迁移；资源在运行过程中也具有良好的弹性，可以根据数据规模扩展资源规模。 事实上，这个架构的一个小缺点是它必须支持一个 kafka，我们把 TiDB 版本升级到 v6.5.0 之后，结构简化如下：

为什么我存在？ kafka 数据链路称为小缺点，直接写对象存储更感兴趣，或者 v6.5.0 我特别喜欢这么多优秀的特点。从长期的操作和维护经验来看，我们有一些不好的经验：

1. 从部署的角度来看，多一个组件，多一套部署脚本，多一点管理成本。 在人员充足的项目中，这可能是一个小问题，但我们的许多项目只有一两个操作和维护人员。从这个角度来看，组件越少越好，因为它们的能量有限，许多组件无法管理，或者根本不知道有这么多组件，这是非常尴尬的。从长远来看，一线说二线不好，二线说一线不好，团队氛围很差，事情做不好。
2. 从高可用性的角度来看，维护环节越多，出错的可能性越大，可靠性越差。 我们曾经在同步源库和目标库之间设置了三个组件（具体原因不再详细说明）。这种设计具有很高的数据吞吐量，但对于高频更新的表，我们总是觉得数据很少。我们用 Otter+TiDB 在取代原始链路后，问题消失了。追查的根本原因是我们的配置存在问题，导致同步过程中数据覆盖不完整。组件越多，配置越多，即使人员充足，也可能有疏漏。

因此，我目前的想法是同步链路越短，配置越简单，数据可靠性越高。

结语

综上所述，v6.5.0TiCDC发布 基于这一特点，我们还改进了同步链路的架构设计，支持将行变事件保存到存储服务中。我们做了很多上述架构 POC 测试还需要在下一步的实践中总结更多的经验。我希望我们的思维过程能与您分享一些有用的内容。