0
0
0
0
专栏/.../

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

 张鱼小丸子-PingCAP  发表于  2020-04-14
原创

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

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

%E5%9B%BE%E7%89%87%201

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

%E5%9B%BE%E7%89%87%202

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

%E5%9B%BE%E7%89%87%203

%E5%9B%BE%E7%89%87%204

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

  • 高度兼容 MySQL;
  • 能水平弹性扩展;
  • 支持分布式事物;
  • 是真正金融级的高可用;
  • 拥有一站式 HTAP 解决方案;
  • 是云原生 SQL 数据库。

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

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

%E5%9B%BE%E7%89%87%206

随手记使用 TiDB 的具体场景

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

场景1

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

  • 前方案:使用的是 Hive及 HBase 两个方案,问题是入库合并时间长(Hive),校验及修复成本耗时高。
  • 现有方案:TiDB,通过调整快照时间,直接 SQL 查询,数据过程简单,修复及校验成本相对较低。

%E5%9B%BE%E7%89%87%207

场景二

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

业务:实时标签

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

方案对比:

  • Hive: 满足不了实时性要求。
  • HBase、ES: 需要将流数据拆开请求得到结果,有一定开发成本,效率不高且对组件性能造成影响。
  • TiDB:使用 TiSpark,将 Kafka 的数据转换成结构化的临时表,跟 TiDB 实时同步的表进行关联。

%E5%9B%BE%E7%89%87%208

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

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

%E5%9B%BE%E7%89%87%209

%E5%9B%BE%E7%89%87%2010

展望未来

对于未来 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 的小伙伴。

0
0
0
0

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

评论
暂无评论