背景

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

数据链路足够短

同步组件尽量少

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

何为数据仓库，何为数据湖

数据仓库，英文名称为 Data Warehouse，可简写为 DW 或 DWH。数据仓库，是为企业所有级别的决策制定过程，提供所有类型数据支持的战略集合。它是单个数据存储，出于分析性报告和决策支持目的而创建。 为需要业务智能的企业，提供指导业务流程改进、监视时间、成本、质量以及控制。 怎么理解上面这个解释，根据我们遇到的客户的诉求，数据仓库都是干这些事的：

大型企业内有各种各样的内部系统，一般情况下，这些业务系统建设时间不同，建设厂商不同，甚至于底层数据产品都有较大差异。领导要看全局，看大数，看趋势，需要一个架构把数据整合起来，这个架构叫做数据仓库

一个企业内的数据相对比较单一，企业通过各种渠道汇集了多种多样的数据放在一起进行分析，这时候需要一个架构来解决采集数据的存储、计算、服务等多种问题，这个架构叫做数据仓库

以上的需求整合的数据，在整合之前就可以被准确认知，知道整合的目的。 假如企业基于战略目的，先执行收集数据的动作，然后从收集的数据中挖掘价值，此时的架构应该叫做数据湖。

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

业务应用的后端数据库是 TiDB

有分析较久远历史数据的需求

有接入第三方数据综合分析的需求

硬件投资有限，需要合理的架构充分发挥硬件性能

客户的部署环境不确定，需要适配大多数云

这是我们实际遇到的需求，我们也做了一些思考和 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，在我们的应用场景下，数据流转如下图：

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

从数据同步链路上讲：数据在计算完成之后，需要经过 TiKV 写到 TiFlash，这样的做法不是太经济

从硬件成本上讲：为了保证数据写入效率，TiKV 和 TiFlash 的硬件我们都给的比较好，因为各种因素影响，我们并没有在较差的硬件下测试，所以在较差硬件条件下效率差多少，我们没有实际数据，也没太有信心进行测试

从架构设计上来讲：假如要接入第三方数据，完全没必要从 TiKV 走一遍，这些数据仅仅作为分析的需求，没有必要占用 TP 的资源

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

客户的分析需求爆发式增长，通常要求我们在有限的成本下，尽可能的提高效率

数据的采集方式复杂多样，一不小心就对 TP 侧产生影响，我们加了消息队列做消峰处理

基于以上分析，单纯的使用 TiFlash、TiSpark 并不能完全贴合我们的诉求，基于我们多年的技术积累，我们架构了一套跟 TiDB 打通的数据仓库架构，具有低成本、多云适配的特性，下一节做一些分析，给大家参考。

打通 TiDB 与数据仓库的建构设想

先来看看现在通用的大数据架构：

我们在设计数据架构的时候，因数据规模的原因采用了 hadoop 体系作为底座，理论上 TiDB 的数据可以直接接入这一套产品中。我们在推广项目的过程中发现了一些问题：

客户投资不多，hadoop 的云产品太贵，客户没有采购，我们无法迁移

客户投资充裕，被云厂商洗脑，只买了 hadoop serverless 版本，各厂商的 api 和 sql 规范都不一样，造成我们一个项目一套代码

有一些项目前期数据规模并不大，客户对先期投入一套大数据产品十分不理解，我们基于这一套架构也做不到伸缩自由

基于以上原因，我们打算研究了一套替代 hadoop 的架构，对于一些主要环节我们做了一些决策：

存储产品：基于 OSS 在云产品中的地位和性价比，存储采用 OSS

计算环境：我们并不想投入人力管理计算资源的调度，采用事实标准 k8s 做资源的调度

api 形态：我们原来的计算流程需要编程，在这次架构设计中，我们打算提供 JDBC 接口，类似打造一个 serverless 的计算服务

我们设计的架构如下：

与前一个架构相比，我们没有部署任何组件，依托 k8s 实现了计算的调度和数据的访问，k8s 和对象存储也不需要我们管理维护，减掉我们大部分的运维工作。基于 k8s 和对象存储的通用性，我们这套架构在大部分云上都可以无缝迁移；运行时资源也具有较好的弹性，可以随着数据规模做资源规模的伸缩。 这一套架构其实有点小缺点就是必须还要配套一个 kafka，我们把 TiDB 版本升级到 v6.5.0 之后，架构简化如下： 为什么我对存在 kafka 的数据链路叫做一个小缺点，而把直接写对象存储，更感兴趣，或者说 v6.5.0 这么多优秀特性，我却对这一点情有独钟。从长期的运维经验来看，我们有过一些不好的经验：

从部署的角度来讲，多一个组件，就多一套部署脚本、多一分管理成本。 在人员充足的项目，可能是一个不大的问题，但我们很多项目只有一到两个运维人员，从这个角度看，其实组件越少越好，因为他们精力有限，很多组件不会管理，或者说根本不知道有这么多组件存在，这就很尴尬。长此以往，一线说二线不好，二线说一线不行，团队氛围很不好，事情也干不好。

从高可用的角度来讲，维护的环节越多，出错的可能性越大，可靠性越差。 我们曾经在同步的源库和目标库之间设置了三个组件（具体原因不再详述），这样的设计有很高的数据吞吐能力，但是对于高频更新的表，总是感觉少数据。我们用 Otter+TiDB 的链路代替了原有链路之后，问题消失了。事后追查根本原因是我们的配置有问题，导致了同步过程中数据覆盖不全。组件越多，配置越多，即使在人员充足的情况下，也可能有疏漏。

所以，我目前的思路是同步链路越短、配置越简单，数据可靠性越高。

结语

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