写点什么

【精选实践】随手科技在 TiDB 的探索之路

  • 2022 年 7 月 11 日
  • 本文字数:1725 字

    阅读完需:约 6 分钟

作者: 张鱼小丸子 -PingCAP 原文来源:https://tidb.net/blog/d0c3b551

本文整理自 TUG 大使、随手科技大数据工程师韩超在 8 月 25 日 TUG 华南区首次线下活动分享。


随手科技是国内领先的个人理财应用服务提供商,旗下拥有随手记、卡牛、随管家等多款明星产品,目前用户规模已超过三亿。



在随手科技的发展过程中,业务遇到的一些痛点包括:开发面对的数据库分库分表的问题,数据冷热分离相关的问题等。



在随手科技的大数据业务建设过程中,一些痛点有:数据落地过程流程长,OLTP/OLAP 分散于多个组件。




接下来随手科技看到了 TiDB,调研了 TiDB 及相关的工具和目前应用情况,了解到 TiDB 的特点:


  • 高度兼容 MySQL;

  • 能水平弹性扩展;

  • 支持分布式事物;

  • 是真正金融级的高可用;

  • 拥有一站式 HTAP 解决方案;

  • 是云原生 SQL 数据库。


基于此,随手科技最终选择了使用 TiDB。


目前随手科技使用 2.1.10 版本的 TiDB,采用三中心部署方案,部署了 6 台 TiDB 机器和 8 台 TiKV 机器,部署架构图如下。


随手记使用 TiDB 的具体场景

随手记使用 TiDB 有两个典型场景。

场景 1

用户回滚账本到指定时间点,场景量级达到 20+ 表,10 TB+ 数据,百亿级数据量,千万级 OPS。


  • 前方案:使用的是 Hive 及 HBase 两个方案,问题是入库合并时间长(Hive),校验及修复成本耗时高。

  • 现有方案:TiDB,通过调整快照时间,直接 SQL 查询,数据过程简单,修复及校验成本相对较低。


场景二

即时流量关联实时更新的存量数据。


业务:实时标签


场景:及时流量关联实时更新的存量数据


方案对比:


  • Hive: 满足不了实时性要求。

  • HBase、ES: 需要将流数据拆开请求得到结果,有一定开发成本,效率不高且对组件性能造成影响。

  • TiDB:使用 TiSpark,将 Kafka 的数据转换成结构化的临时表,跟 TiDB 实时同步的表进行关联。


遇到的问题及相应的解决方案

在使用 TiDB 的过程中,随手科技总结了一些遇到了问题及其解决方案,主要问题有:主键冲突,数据热点,Kafka, DM 工具,Task 相关问题等。



展望未来

对于未来 TiDB 的使用,随手科技有一些相应的规划:


  • 积极推广 TiDB,从边缘到核心逐渐渗透,挖掘更多 TiDB 场景。

  • 贴近社区,提升能力,回馈社区。

  • 评估测试 TiDB 升级 3.0+ 版本。


随手科技的 TiDB 实践分享完之后,现场也有很多小伙伴们积极提出了一些问题。

Q&A

Q: 从开始调研到第一个集群上线大概多长时间?


A: 这个跟很多东西有关,我们其实今年三四月份才正式往下推。一开始是测试,测试的时候集群规模小,但其实更能暴露出来集群到了瓶颈点的问题,我们也做了很多可用性的测试以及暴力的测试,结果基本符合预期,然后我们选择符合场景的现有业务,迁移上去做试点,整个到上线时间大概花了几个月。


Q : 因为 to B 这一块,其实需要上层做决定,要去推业务,我们需要去说服老大去采纳技术,随手科技这边有没有什么样的杀手锏或者方案,可以分享一下这方面的故事或者一些经验?


A: 这个要分情况,我们老大本身就对 TiDB 有所了解,所以本身就很支持这个事情。


Q : 我想问一下,刚刚那个图表里面不是有排查嘛,排查过程是怎么样的,或者让同事他们首先可以去找,要不然找 issue 的话可能 contributor 会去做,如果想找问题的话要去哪找比较快或者更好上手?刚那个表那个里面有些排查还是非常重。


A: 因为有问题的话,其实我们首先反复进行了验证,确认不是因为我们误操作造成的。比如 DM 同步,我们做了挺多遍,首先确认我们没有误操作,第二确认数据在什么情况丢,在哪个阶段丢,丢的时候是哪个组件引发的。


我们的场景是分库分表合库,而且是几十个分库,量也大。这个过程是同步结束后,我们数据校验时发现一部分数据损失,并且是挺老的数据,我们重复同步了几次,均会有相同情况。接着丢失的数据都会在 DM 第一步 dump 下来的 SQL 文件出现。所以我们确认是在 Load 阶段发生的。丢失会丢掉整条 insert sql,里面可能有几千行数据。然后 DM 会有一些报错,比如 server busy,连接丢失等。我们也试过把一个 task 分批,几个 worker 跑完再起几个来降低 TiDB 压力,这种情况下不会丢失。所以我们把问题确定时 load 时发生异常的情况下 savepoint 应该有问题,然后我们将问题整理并反馈 TiDB 的同事,他们很重视并很积极的帮助我们,安排专人对接并排期解决,在此也非常感谢 TiDB 的小伙伴。


发布于: 刚刚阅读数: 2
用户头像

TiDB 社区官网:https://tidb.net/ 2021.12.15 加入

TiDB 社区干货传送门是由 TiDB 社区中布道师组委会自发组织的 TiDB 社区优质内容对外宣布的栏目,旨在加深 TiDBer 之间的交流和学习。一起构建有爱、互助、共创共建的 TiDB 社区 https://tidb.net/

评论

发布
暂无评论
【精选实践】随手科技在 TiDB 的探索之路_TiDB 社区干货传送门_InfoQ写作社区