随手科技是国内领先的个人理财应用服务提供商,旗下拥有随手记、卡牛、随管家等多款明星产品,目前用户规模已超过三亿。
在随手科技的发展过程中,业务遇到的一些痛点包括:开发面对的数据库分库分表的问题,数据冷热分离相关的问题等。
在随手科技的大数据业务建设过程中,一些痛点有:数据落地过程流程长,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 的小伙伴。
作者介绍:
韩超,随手科技大数据工程师,TiDB User Group (TUG) 大使。
本文转载自 AskTUG。
原文链接:
https://asktug.com/t/tidb/1058
评论