记一次TiDB的临时救场

【是否原创】是

【首发渠道】TiDB 社区,谢绝转载

第一次在社区写文章,文笔不行,只是想分享一些经验,功力不到之处,还望海涵。

【背景描述】

我是一个数据工程师,我司维护了一个互联网在线销售系统。因用户规模和数据量的原因,数据链路采用如下架构设计:

image

数据从业务库(多组Mysql集群-MHA方案)通过binlog实时同步到kv数据库中,每日定时抽取数据到hadoop中,加工后,在同步到汇总库(Mysql,多实例,类似主题库)中。

【问题分析】

年中时,某项目现场同事向我反馈了一个问题,用户发现日汇总数据不对,在使用明细数据查询(业务库)和日汇总(汇总库)核对时,发现差异,因某原因此种情况与用户本身利益密切相关,用户反应强烈。

此功能相关表,在千万级别,是频繁更新的表。客户反应多集中在月初或者月末,受影响的客户小于2‰,基本无法跟踪。经过几周的排查,问题排查到mysql到hadoop之间的同步环节上,但发现不了最终问题,此时情况严重,影响到项目结项。

经过团队的讨论,解决问题的思路转换到替换组件上,既然发现不了问题,能否在再增加一个同步链路,每日同步后,对两份数据求合集,进一步缩小受影响的范围。

image

对冗余链路有几个要求:

  1. 仍然坚持binlog同步,影响最小。

  2. 同步稳定,同步并发能力要高。

  3. 方案成熟,是公司内部已经用过,至少预研测试过的方案。

  4. 同步到Hive时,吞吐能力大,能够在合理的时间,同步完所有数据。

首先想到的是TiDB,因为TiDB本身是个分布式的关系数据库,数据一致性能得到保障。

公司内部有用过otter做mysql之间的数据同步,otter架构如下:

项目参考:https://github.com/alibaba/otter/

虽然此项目很久没人维护,但从使用反馈来看比较好。

【方案测试】

由于时间紧,可用资源有限,我们对尽可能利用闲置资源做了一些测试。

我们对TiDB做了tpcc测试,测试过程参考:https://docs.pingcap.com/zh/tidb/stable/benchmark-tidb-using-tpcc

我们的测试环境是

  • 1TiDB 8C32G SSD

  • 3TiKV 8C32G SSD

  • 128并发线程

数据仓库300个单位,30个分区,其中各表数据量:

表名 数据量
customer 9000000
district 3000
history 9052121
item 100000
new_order 2705417
order_line 90615072
orders 9069285
stock 30000000
warehouse 300

测试结果如下:

image

我们也对TiDB做了Spark读取写入测试,使用方式参考:https://docs.pingcap.com/zh/tidb/stable/get-started-with-tispark

代码很简单:

写入代码:

image

读取代码:

测试结果如下:

写:16台8C16G机器,SSD磁盘,2000万数据,平均7分钟(预写:1.5分钟,提交:2.3分钟)。

读:16台8C16G机器,SSD磁盘,2亿5千万,平均3.3分钟。

【问题解决】

结合以上的测试结果,TiDB的写入速度与TiSpark的读写速度都可以满足要求。本着死马当活马医的精神,拍脑袋决定,方案如下:

image

增加此链路之后,跟踪发现TiDB同步出来的数据比kv链路同步出来数据要完整,也依靠对比TiDB的数据,发现了kv中数据同步的问题,篇幅所限不再详述。

【总结】

此问题解决过程中,时间非常紧迫,方案讨论、测试、上线在3天之内完成,可以说是完全凭着对p厂的信赖,硬着头皮上的。结果不错,自从冗余链路上线后,基本没有了数据问题,老板们和项目的同事也都比较满意。

7赞