TiDB 在 Ping++ 金融聚合支付业务中的实践

Ping++ 介绍

Ping++ 是国内领先的支付解决方案 SaaS 服务商。自 2014 年正式推出聚合支付产品，Ping++ 便凭借“7行代码接入支付”的极致产品体验得到了广大企业客户的承认。

现在，Ping++ 在持续拓展泛支付领域的服务范围，旗下拥有聚合支付、帐户系统、商户系统三大核心产品，已累计为近 25000 家企业客户解决支付难题，遍及零售、电商、企业服务、O2O、游戏、直播、教育、旅游、交通、金融、房产等等 70 多个细分领域。

Ping++ 连续两年入选毕马威中国领先金融科技 50 强，并于 2017 成功上榜 CB Insights 全球 Fintech 250 强。从支付接入、交易处理、业务分析到业务运营，Ping++ 以定制化全流程的解决方案来帮助企业应对在商业变现环节可能面临的诸多问题。

TiDB 在 Ping++ 的应用场景 - 数据仓库整合优化

Ping++ 数据支撑系统主要由流计算类、报表统计类、日志类、数据挖掘类组成。其中报表统计类对应的数据仓库系统，承载着数亿交易数据的实时汇总、分析统计、流水下载等重要业务:

随着业务和需求的扩展，数仓系统历经了屡次发展迭代过程：

1. 因为业务需求中关联维度大部分是灵活多变的，因此起初直接沿用了关系型数据库 RDS 做为数据支撑，数据由自研的数据订阅平台从 OLTP 系统订阅而来。
2. 随着业务扩大，过大的单表已不足以支撑复杂的查询场景，所以引入了两个方案同时提供数据服务：ADS，阿里云的 OLAP 解决方案，用来解决复杂关系型多维分析场景。ES，用分布式解决海量数据的搜索场景。

3. 以上两个方案基本知足业务需求，可是都仍存在一些问题：

   • ADS：一是数据服务稳定性，阿里云官方会不按期进行版本升级，升级过程会致使数据数小时滞后，实时业务根本没法保证。二是扩容成本，ADS 为按计算核数付费，若是扩容就必须购买对应的核数，成本不是那么灵活可控。
   • ES：单业务搜索能力较强，可是不适合对复杂多变的场景查询。且研发运维代价相对较高，没有关系型数据库兼容各种新业务的优点。

因此须要作出进一步的迭代整合，咱们属于金融数据类业务，重要性安全性不能忽视、性能也得要有保障，通过咱们漫长的调研过程，最终，由 PingCAP 研发的 TiDB 数据库成为咱们的目标选型。

TiDB 具有的如下核心特征是咱们选择其做为实时数仓的主要缘由：

• 高度兼容 MySQL 语法；
• 水平弹性扩展能力强；
• 海量数据的处理性能；
• 故障自恢复的高可用服务；
• 金融安全级别的架构体系。

并追踪造成了如下数据支撑系统架构：

新的方案给咱们的业务和管理带来了如下的提高和改变:

• 兼容：整合了现有多个数据源，对新业务上线可快速响应；
• 性能：提供了可靠的交易分析场景性能；
• 稳定：更高的稳定性，方便集群运维；
• 成本：资源成本和运维成本都有所下降。

TiDB 架构解析及上线状况

TiDB 是 PingCAP 公司受 Google Spanner / F1 论文启发而设计的开源分布式 NewSQL 数据库。从下图 Google Spanner 的理念模型能够看出，其设想出数据库系统把数据分片并分布到多个物理 Zone 中、由 Placement Driver 进行数据片调度、借助 TrueTime 服务实现原子模式变动事务，从而对外 Clients 能够提供一致性的事务服务。所以，一个真正全球性的 OLTP & OLAP 数据库系统是能够实现的。

咱们再经过下图分析 TiDB 总体架构：

能够看出 TiDB 是 Spanner 理念的一个完美实践，一个 TiDB 集群由 TiDB、PD、TiKV 三个组件构成。

• TiKV Server：负责数据存储，是一个提供事务的分布式 Key-Value 存储引擎；
• PD Server：负责管理调度，如数据和 TiKV 位置的路由信息维护、TiKV 数据均衡等；
• TiDB Server：负责 SQL 逻辑，经过 PD 寻址到实际数据的 TiKV 位置，进行 SQL 操做。

生产集群部署状况：

现已稳定运行数月，对应的复杂报表分析性能获得了大幅提高，替换 ADS、ES 后下降了大量运维成本。

TiDB 在 Ping++ 的将来规划

1. TiSpark 的体验

TiSpark 是将 Spark SQL 直接运行在分布式存储引擎 TiKV 上的 OLAP 解决方案。下一步将结合 TiSpark 评估更加复杂、更高性能要求的场景中。

1. OLTP 场景

目前数仓 TiDB 的数据是由订阅平台订阅 RDS、DRDS 数据而来，系统复杂度较高。TiDB 具有了出色的分布式事务能力，彻底达到了 HTAP 的级别。

TiKV 基于 Raft 协议作复制，保证多副本数据的一致性，能够秒杀当前主流的 MyCat、DRDS 分布式架构。且数据库的可用性更高，好比咱们对生产 TiDB 集群全部主机升级过磁盘(Case记录），涉及到各个节点的数据迁移、重启，但作到了相关业务零感知，且操做简单，过程可控，这在传统数据库架构里是没法轻易实现的。

咱们计划让 TiDB 逐渐承载一些 OLTP 业务。

对 TiDB 的建议及官方回复

1. DDL 优化：目前 TiDB 实现了无阻塞的 online DDL，但在实际使用中发现，DDL 时生成大量 index KV，会引发当前主机负载上升，会对当前集群增长必定的性能风险。其实大部分状况下对大表 DDL 并非很频繁，且时效要求并非特别强烈，考虑安全性。建议优化点：

   • 是否能够经过将源码中固定数值的 defaultTaskHandleCnt、defaultWorkers 变量作成配置项解决；
   • 是否能够像 pt-osc 工具的同样增长 DDL 过程当中暂停功能。
2. DML 优化：业务端不免会有使用不当的 sql 出现，如致使全表扫描，这种状况可能会使整个集群性能会受到影响，对于这种状况，是否能增长一个自我保护机制，如资源隔离、熔断之类的策略。

针对以上问题，咱们也咨询了 TiDB 官方技术人员，官方的回复以下：

• 正在优化 Add Index 操做的流程，下降 Add Index 操做的优先级，优先保证在线业务的操做稳定进行。
• 计划在 1.2 版本中增长动态调节 Add Index 操做并发度的功能。
• 计划在后续版本中增长 DDL 暂停功能。
• 对于全表扫描，默认采用低优先级，尽可能减小对于点查的影响。后续计划引入 User 级别的优先级，将不一样用户的 Query 的优先级分开，减小离线业务对在线业务的影响。

最后，特此感谢 PingCAP 全部团队成员对 Ping++ 上线 TiDB 各方面的支持！

✎ 做者：宋涛 Ping++ DBA