5
2
1
1
专栏/.../

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

 数据小黑  发表于  2023-01-03

背景

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

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

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

  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,在我们的应用场景下,数据流转如下图: image.png

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

  1. 从数据同步链路上讲:数据在计算完成之后,需要经过 TiKV 写到 TiFlash,这样的做法不是太经济
  2. 从硬件成本上讲:为了保证数据写入效率,TiKV 和 TiFlash 的硬件我们都给的比较好,因为各种因素影响,我们并没有在较差的硬件下测试,所以在较差硬件条件下效率差多少,我们没有实际数据,也没太有信心进行测试
  3. 从架构设计上来讲:假如要接入第三方数据,完全没必要从 TiKV 走一遍,这些数据仅仅作为分析的需求,没有必要占用 TP 的资源

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

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

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

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

先来看看现在通用的大数据架构: image.png

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

  1. 客户投资不多,hadoop 的云产品太贵,客户没有采购,我们无法迁移
  2. 客户投资充裕,被云厂商洗脑,只买了 hadoop serverless 版本,各厂商的 api 和 sql 规范都不一样,造成我们一个项目一套代码
  3. 有一些项目前期数据规模并不大,客户对先期投入一套大数据产品十分不理解,我们基于这一套架构也做不到伸缩自由

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

  1. 存储产品:基于 OSS 在云产品中的地位和性价比,存储采用 OSS
  2. 计算环境:我们并不想投入人力管理计算资源的调度,采用事实标准 k8s 做资源的调度
  3. api 形态:我们原来的计算流程需要编程,在这次架构设计中,我们打算提供 JDBC 接口,类似打造一个 serverless 的计算服务

我们设计的架构如下: image.png

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

  1. 从部署的角度来讲,多一个组件,就多一套部署脚本、多一分管理成本。 在人员充足的项目,可能是一个不大的问题,但我们很多项目只有一到两个运维人员,从这个角度看,其实组件越少越好,因为他们精力有限,很多组件不会管理,或者说根本不知道有这么多组件存在,这就很尴尬。长此以往,一线说二线不好,二线说一线不行,团队氛围很不好,事情也干不好。
  2. 从高可用的角度来讲,维护的环节越多,出错的可能性越大,可靠性越差。 我们曾经在同步的源库和目标库之间设置了三个组件(具体原因不再详述),这样的设计有很高的数据吞吐能力,但是对于高频更新的表,总是感觉少数据。我们用 Otter+TiDB 的链路代替了原有链路之后,问题消失了。事后追查根本原因是我们的配置有问题,导致了同步过程中数据覆盖不全。组件越多,配置越多,即使在人员充足的情况下,也可能有疏漏。

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

结语

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

5
2
1
1

版权声明:本文为 TiDB 社区用户原创文章,遵循 CC BY-NC-SA 4.0 版权协议,转载请附上原文出处链接和本声明。

评论
暂无评论