作者介绍 李文杰,网易互娱高级数据库工程师,TUG 2019 年度和 2020 年度 MVA。主要负责大数据研发和数据分析工作,为产品提供精细化运营指导;同时在部门内推广使用 TiDB,为业务上云及数据库分布式化积累经验和探索最优方案,目前是 TiDB 管理小组负责人。 本文整理自 TUG 网易线上企业行活动,由网易游戏高级数据库工程师李文杰老师分享,主要介绍分布式数据库 TiDB 在网易游戏的应用实践经验。 网易游戏最开始引入 TiDB 是从 AP 的角度来进行使用的。在第一次使用 TiDB 时,我们把跑批业务这种计算量比较大的任务迁移到 TiDB 上面。在迁移过程中,如果跑的任务量比较大,相信很多人会遇到 “transaction too large” 报错这个问题。 TiDB 事务限制 经过一番排查发现,由于分布式事务要做两阶段提交,并且底层还需要做 Raft 复制,如果一个事务非常大,会使得提交过程非常慢,并且会卡住下面的 Raft 复制流程。为了避免系统出现被卡住的情况,TiDB 对事务的大小做了限制,具体限制的内容有单事务的 SQL 语句数、KV 键值对数目和大小、单 KV 键值对大小等。 知道这个限制后,我们就可以找到了解决办法,即把大的事务按业务的需求切分为多个小事务分批执行,这样之前跑失败的 SQL 就能成功运行了,而且在 MySQL/Oracle 中的跑批程序,也都成功迁移到了 TiDB。 同时,我们不得不思考,在没有问题的时候,程序可以跑得非常顺畅,但是当机房中出现网络问题,或是出现其他的故障时,就会出现一部分数据写入到了 TiDB 中,而另外一部分数据是没有写入的。在场景中的表现是一个事务的执行没有能够保证其原子性,只执行了其中一部分,有一部分成功,有一部分失败了。 经排查发现,这是因为我们手动开启了事务切分,这种情况下大事务的原子性就无法保证,只能保证每个批次的小事务原子性,从整个任务的全局角度来看,数据出现了不一致。 那么该如何解决这个问题呢? TiDB 大事务优化 通过向官方反馈问题之后,TiDB 4.0 对大事务进行了深度优化,不仅取消了一些限制,而且将单事务大小从 100MB 直接放宽限制到 10GB,直接优化了100 倍。但与此同时也带来了另一个问题,在进行 t 1 的跑批业务时,前一天可能会有几百甚至上千万的数据量,如果用程序 JDBC TiDB 方式处理,效率其实不高,处理时长往往需要持续数小时,甚至几十小时以上。 那么该如何提高计算任务的整体吞吐量?答案是 TiSpark。 TiSpark: 高效处理复杂 OLAP 计算 TiSpark 实践
怎么样才可以做到有效隔离?或许 TiFlash 列式存储引擎能提供答案。 TiFlash:列式存储引擎 TiFlash 作为 TiKV 行式存储引擎的补充,它是 TiKV 数据的 raft 副本,TiFlash 作为在 TiKV 基础上的列式副本,经过 raft 协议保证数据同步的一致性和完整性。这样同样的一份数据就可以存储在两个存储引擎里面。TiKV 保存的是行存数据,TiFlash 保存的是列式数据。 在做 Spark 的计算分析时,我们可以直接从 TiFlash 集群进行读取,计算效率会非常高。用列式数据做 AP 分析,对于行式数据来说,简直就是降维打击。 TiFlash:TPC-H 性能分析 TiSpark TiFlash 的结合应用使计算效率取得了量与质的提升。TPC-H 性能分析显示,在与 TiKV 的横向对比中,几乎全部 query 场景下 TiFlash 执行效率都高于 TiKV,且部分场景的效率远高于 TiKV 。用了 TiFlash 以后,既不影响 TiKV 的集群性能,也不影响线下的集群业务,而且在做离线大数据分析时,依然能够保持很好的性能与吞吐量。 经过实践证明,TiFlash 可以解决我们的诸多问题,是非常棒的一个工具。 TiFlash应用:计算更高效 JSpark:跨源离线计算 JSpark 基于 TiSpark 和 JDBC 进行封装,在 TiKV 可以进行数据读写,在 TiFlash 可以进行列式 AP 计算,在 TiDB 可以做常规的 SQL 计算,目前我们已经封装实现了 TiDB 和 Hive 的相互读写功能,后续 JSpark 工具将会支持 TiDB 与 ES 的读写互访,实现 TiDB、Hive、ES 多源数据访问。 目前 JSpark 工具,主要是实现了以下功能:
我们在开发和使用 JSpark 相关功能期间,也发现了 TiSpark 的一个可优化点。 TiDB 应用:HTAP 数据体系 HTAP 计算能力:JSpark JFlink TiDB 应用:HTAP 数据体系 目前,经过 3 年的发展,网易游戏的集群总实例数量 170 个,数据规模达到 100 TB 级别。我们的业务涵盖用户画像、防沉迷、运营、报表、业务监控等多个方面,并且业务规模和集群规模也在不断发展和扩大中。 以上就是网易游戏在使用 TiDB 的过程中,对于 AP 计算演进的过程,希望今天的分享可以对大家有所启发。 关于 TUG TUG(TiDB User Group) 是由 TiDB 用户自发组织、管理的独立社区,PingCAP 官方提供赞助与支持。目前共有华北、华东、华南(广州、深圳)、西南(成都、重庆)、TUG APEC(新加坡)小组。TUG 成立的初衷是“连接用户,共建社区”,汇聚了全球数据库、大数据技术从业者,是一个独立、自发、不以盈利为目的的组织。 如果你对数据库、大数据感兴趣,如果你也想跟业界大咖们一起交流最前沿的数据库与大数据知识,欢迎加入 TUG,和 TUG 一起成长! |
|
来自: 刘振东 > 《PingCap实战》