随手科技是国内领先的个人理财应用服务提供商,旗下拥有随手记、卡牛、随管家等多款明星产品,目前用户规模已超过三亿。
在随手科技的发展过程中,业务遇到的一些痛点包括:开发面对的数据库分库分表的问题,数据冷热分离相关的问题等。
在随手科技的大数据业务建设过程中,一些痛点有:数据落地过程流程长,OLTP/OLAP 分散于多个组件。
接下来随手科技看到了 TiDB,调研了 TiDB 及相关的工具和目前应用情况,了解到 TiDB 的特点:
基于此,随手科技最终选择了使用 TiDB。
目前随手科技使用 2.1.10 版本的 TiDB,采用三中心部署方案,部署了 6 台 TiDB 机器和 8 台 TiKV 机器,部署架构图如下。
随手记使用 TiDB 有两个典型场景。
用户回滚账本到指定时间点,场景量级达到 20+表,10 TB+数据,百亿级数据量,千万级 OPS。
即时流量关联实时更新的存量数据。
业务:实时标签
场景:及时流量关联实时更新的存量数据
方案对比:
在使用 TiDB 的过程中,随手科技总结了一些遇到了问题及其解决方案,主要问题有:主键冲突,数据热点,Kafka, DM工具,Task 相关问题等。
对于未来 TiDB 的使用,随手科技有一些相应的规划:
随手科技的 TiDB 实践分享完之后,现场也有很多小伙伴们积极提出了一些问题。
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 的小伙伴。
作者介绍:
韩超,随手科技大数据工程师,TiDB User Group (TUG) 大使。
本文转载自 AskTUG。
原文链接:
领取专属 10元无门槛券
私享最新 技术干货