作者介绍： 李文杰，网易互娱高级数据库工程师，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 是在 Spark 基础上开发的一个插件，它可以高效地从 TiKV 读取数据。同时支持索引查找和计算下推策略，有很高的查询性能。我们在实践过程发现，使用 TiSpark 读取 TiKV 的方式，5 分钟可以完成 2 亿行数据读取。同时它也有很高的写入性能。有了 TiSpark，我们可以直接通过 Spark 工具访问 TiKV 数据。经过时间证明，TiSpark 读、写 TiKV 都有着非常好的性能表现，通过 TiSpark 我们可以处理比较复杂、数据量比较大的运算。
TiSpark 实践
在实践中，使用 TiSpark 主要有两种方式：
TiSpark + JDBC 写入方式能够自动切分大事务，但不一定能保证事务的原子性和隔离性，且故障恢复时需要人工介入。这种方式写入速度可以达到 180 万行/min，通过 TiDB 处理 SQL 再写入 TiKV，速度一般。
TiSpark 批量写入 TiKV 不会自动切分大事务。通过 TiSpark 直接读写 TiKV，相当于直接通过大事务读写 TiKV 的数据，可以保证事务的原子性和隔离性，同时拥有良好的写入性能，写入速度可以达到 300 万行/min。经过 TiSpark 的应用，解决了我们大数据量批处理任务的问题，但是也存在一定的隐患。TiSpark 在进行读、写 TiKV 的时候，由于 TiKV 是作为整个 TiDB 架构的存储引擎，如果存储引擎层的数据读写压力大，对于线上的其他业务将会产生明显的影响。此外，在 TiSpark 读写 TiKV 时，如果没有对 IO 进行限制，很容引发性能抖动，导致访问延迟上升，也会对其他线上业务产生影响。
怎么样才可以做到有效隔离?或许 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应用：计算更高效
![]()
在网易游戏用户画像的部分指标计算场景中，使用上 TiSpark + TiFlash 后，不同业务内容的 SQL 处理速度相比 TiSpark + TiKV 快了至少 4 倍。所以使用 TiFlash 之后，离线批处理效率有了质的提升。
JSpark：跨源离线计算
随着业务规模和应用场景的增加，不同数据分布存储在不同的存储引擎。比如日志数据存储在 Hive，数据库数据存储在 TiDB，跨数据源访问需要大量数据迁移，耗时且费力。能否直接打通不同数据源，实现跨源互访？针对这个问题网易游戏采用了 JSpark 工具。JSaprk 是为了打通底层不同存储，实现跨源访问目标而实现的一个离线计算工具。这个工具核心是 TiSpark + Spark 组件，Spark 作为桥梁，可以实现不同数据源的访问。
![]()
JSpark 基于 TiSpark 和 JDBC 进行封装，在 TiKV 可以进行数据读写，在 TiFlash 可以进行列式 AP 计算，在 TiDB 可以做常规的 SQL 计算，目前我们已经封装实现了 TiDB 和 Hive 的相互读写功能，后续 JSpark 工具将会支持 TiDB 与 ES 的读写互访，实现 TiDB、Hive、ES 多源数据访问。
目前 JSpark 工具，主要是实现了以下功能：
- 支持 TiSpark+JDBC 方式读写 TiDB 和读写 Hive，这种方式效率一般。
- 应用场景：在 TiDB 宽表中只操作业务需要的部分列。
- 支持读 TiDB 表数据，Spark 计算结果写入 Hive 目标表。读推荐使用 TiSpark 读取 TiKV或 TiFlash 的方式，写推荐使用 TiSpark 写入 TiKV的方式，效率会更高。
- 应用场景：定期轮转 TiDB 分区表过期分区，备份永久保留副本到 Hive，避免TiDB 表过大。
- 支持读 Hive 表数据，Spark 计算结果写入 TiDB 目标表。推荐使用 TiSpark 写入 TiKV 的方式，效率高。
- 应用场景：分析 Hive 数据产出用户画像指标并写入线上 TiDB，提供线上业务 TP 查询。另一个实践场景是恢复 Hive 备份到 TiDB。
- 支持前端 web 或业务发起 http 请求，远程启动 Spark 作业，完成底层 TiDB 和 Hive 的联合查询。
- 应用场景：前端管理平台点击查询按钮，获取某玩家 Hive 链路日志和 TiDB 数据的联合聚合结果，提炼出相关行为数据。
我们在开发和使用 JSpark 相关功能期间，也发现了 TiSpark 的一个可优化点。
![]()
目前 TiSpark 不支持同时访问多个 TiDB 数据源，运行时只能注册一个 TiDB 集群，不能注册多个，这不便于跨 TiDB 集群计算。在未来我们希望 TiSpark 可以支持同时访问多个 TiDB 集群。
TiDB 应用：HTAP 数据体系
JSpark 目前是离线计算的核心框架，除此之外还与 JFlink 实时计算框架相结合，共同组成了大数据处理能力。JSpark 负责离线大数据计算框架，JFlink 负责实时计算框架，两者共同组成了 HTAP 的数据体系。
HTAP 计算能力：JSpark+JFlink
![]()
首先，将线上数据实时同步汇总到 TiDB 集群，再依靠 JSpark + JFlink 在 TiDB 和其他数据源进行离线和实时计算，产出用户画像等指标分析数据，反馈线上业务查询。
TiDB 应用：HTAP 数据体系
![]()
目前，经过 3 年的发展，网易游戏的集群总实例数量 170 个，数据规模达到 100 + TB 级别。我们的业务涵盖用户画像、防沉迷、运营、报表、业务监控等多个方面，并且业务规模和集群规模也在不断发展和扩大中。
以上就是网易游戏在使用 TiDB 的过程中，对于 AP 计算演进的过程，希望今天的分享可以对大家有所启发。
