本文讨论了金融科技（Fintech）行业在数据基础设施建设上所面临的挑战，以及 TiDB 数据库在解决这些挑战方面的天然优势。TiDB 的 HTAP 架构和强大的水平扩展能力，为 Fintech 甚至是 Web3 的企业提供了重要的业务价值。本文将探讨 TiDB 如何应对 Fintech 行业的痛点，以及它为这些企业带来的实际价值。
背景
Fintech 是金融（Finance）和技术（Technology）两个词的结合，主要指能够撕裂传统金融服务方式的高新技术。Fintech 涵盖了大量的细分行业，除了日常生活中经常接触到的移动支付和互联网银行，还包括像区块链、Web3 和 NFT 等新兴细分行业。
Fintech 行业的快速发展提出了一些业务需求。首先，Fintech 是全球经济中规模最大、增长最快的业务之一。其次，新冠疫情加速了整个金融科技的发展趋势，例如非接触支付、在线支付、保险和数字金融等服务的需求急剧增加。此外，由于其行业特性，Fintech 对数据的一致性和服务的可靠性、数据的安全合规以及监管等都有严格要求。因此，在选择相关解决方案时，通常会保持非常谨慎的态度。
除此之外，Fintech 以客户为中心，需要对客户行为进行实时数据洞察，以更好地了解客户行为，量身定制转型、实现个性化营销和为用户提供增值服务。
最后，在 Fintech 这样高度创新的技术背景下，通常在策略调整和产品方向选择上非常灵活、快速。因此，相较于传统金融企业，Fintech 更加敏捷，相关产品推向市场的时间更短。
Fintech 行业面临的技术挑战
随着金融科技行业持续发展，对技术领域也提出了更多挑战，落在数据库方面，当相关数据量或整个业务请求量达到单机限制时，整个数据基础设施建设就会变得非常复杂。基础设施复杂化会带来以下问题：
- 首先，很难在关键核心 OLTP 联机交易场景下，同时保证数据一致性及可靠性；
- 数据架构复杂化会导致数据处理链路和时效性出现相对较差的情况，从而使大规模实时洞察变得非常困难；
- 再者，为了适应基础设施的复杂性，前端业务开发需要不断使用更多的技术栈，并让应用程序依托于多种技术栈来支撑业务访问，这会拉长业务开发时间并使应用程序开发更为复杂，从而导致上市时间变慢；
- 最后，为管理财务数据，还需要满足严格的监管和合规要求。
TiDB 作为企业级分布式数据库，其拥有的天然优势，可以很好地解决 Fintech 行业所面临的痛点。它的 HTAP 架构设计和出色的水平扩展能力，对于 Fintech 甚至是 Web3 的企业来说，都具有非常重要的业务价值。
TiDB的架构设计非常简洁,在一套架构中同时提供了行存和列存两种存储引擎,并统一了SQL入口,简化了整个数据处理链路。这种设计进一步提高了 Fintech 业务的开发敏捷性，无需了解底层数据分布或数据管理这样复杂的工作，只需要通过标准的 SQL 完成业务代码的开发，加速了整个产品的持续迭代能力和速度。
此外，面对越来越大的数据量，TiDB 拥有良好的水平扩展能力，可以自动实现各个集群节点之间的均衡，针对 Fintech 行业的数据业务增量提供了很好的支持，可以促进整个 Fintech 行业的业务发展。同时，它核心的事务特性、高可用性和可靠性也为 Fintech 业务的发展提供了很好的保障。除此之外，TiFlash 这种列存、MPP 并行处理加速的框架设计，也能够帮助 Fintech 相关场景基于实时数据为其用户提供及时的业务决策或增值服务。
TiDB 在 Fintech 行业的应用和实践
TiDB 作为一款高效稳定的开源数据库，在国内外的银行、证券、保险，以及在线支付、金融科技等行业中都得到了非常普遍的应用。它的应用场景非常丰富，包括核心的交易支付、交易支付相关的查询、在线数据服务，以及实时风控、反洗钱、反欺诈、财务对账、清结算等。下面通过四个典型场景案例，来进一步介绍 TiDB 对 Fintech 场景提供的业务价值。
在线数据服务
在线数据服务是 Web3 行业中的典型业务场景。以 Web3 在线数据服务为例，相关业务发展带来了对应的业务挑战。首先是这个行业存在大量的数据倾斜，这与其本身的数据特征相关，这使得水平和垂直分片变得非常困难。此外，像 NFT 这样的在线数据服务场景下，需要高实时、高并发和高吞吐的业务请求响应。同时，它对延时的敏感性也很高，且非常注重用户体验。
以以太坊为例，其数据量已经超过 10TB，每天还以 100 万笔交易的速度在不断增加。因此，对整个 Scale 的要求也非常高。在整个查询行为上，查询类型非常多样且复杂，包括简单的数据过滤、索引查询，以及聚合类查询和多表场景。同时，因为是一个在线的数据服务，其对实时数据分析也有一定的需求，要求系统提供 7×24 小时在线服务。
针对在线数据服务的业务需求，需要数据库具备实时获取数据的能力，满足低延时的诉求，同时要求数据库具有高可用性。在传统解决方案中，数据处理的链路非常长，数据需要经过前端业务存储到关系型数据库，再进行 ETL 存储，最终放到数据服务层，向业务方提供查询。这种传统解决方案架构非常复杂，损失了数据时效性，并且在高并发访问、表关联等方面也存在缺陷。
TiDB 的特性可以很好地解决在线数据服务所面临的这些挑战。一方面，TiDB 的扩展能力非常强大，计算节点和存储节点都可以进行动态扩缩容，能够应对高吞吐、高并发场景。另一方面，TiDB 高可用的架构设计能够最大程度保证前端业务访问的连续性。此外，HTAP 的能力可以在简化技术栈的同时保证数据的新鲜度，使得前端业务在使用 TiDB 时，整个业务数据的新鲜度非常高。
NFTScan 是一家多链 NFT 数据基础设施服务商，为 Web3 用户提供高效简洁的 NFT 资产搜索查询服务，为 Web3 开发者和新一代金融科技公司提供专业的 NFT API 数据服务。NFTScan 使用了全托管 TiDB Cloud ，满足其 Web3 行业的场景需求。在使用 TiDB Cloud 前，NFTScan 的 NFT 数据链路是从链上获取数据，然后对数据进行过滤，并将 NFT 相关的数据分别存储到 RDS 和 ES 中。这两种数据存储产品分别用于提供 C 端、B 端以及内部运营分析等三类业务查询。使用 TiDB Cloud 后，在数据存储这一侧只存储了一份数据，即全部数据都存储在 TiDB 集群中。这意味着，NFTScan 通过 TiDB Cloud 简化了整个技术栈。在进行业务开发迭代时，不需要同时适配 RDS 和 ES，也不需要了解这两种数据存储产品。相应的业务开发只需要通过一种标准的 SQL 语句就可以完成业务迭代。因此，用户在业务的敏捷性和迭代速度上得到了进一步提高。
另外， TiDB Cloud 在高可用方面，天然支持跨 AZ 部署，能够提供跨 AZ 高可用的能力。在云上的场景下，计算和存储节点可以按需扩容，这能够进一步支持客户的业务增长。目前，NFTScan 使用 TiDB 存储了大约 6TB 的业务数据，QPS 达到 5000，平均查询时长 40ms，各种应用在 TiDB 上运行稳定。
多源汇聚+实时对账
目前整个金融科技行业正在向单元化和服务化方向发展。因此，业务数据会根据不同的业务属性进行拆分，这意味着数据是分散且成熟的。为了实时查询和分析这些数据，可以使用 TiDB 作为多源汇聚层，支持对账、收益分配、损益展示等业务。
TiDB 高度兼容 MySQL 生态，官方提供了数据库管理工具 DM，用户可以使用它完成整个上游到下游 TiDB 数据的实时同步。除此之外，TiDB 也提供了多种数据接入方式，可以将上游业务数据（如客户中心、产品中心等）以统一全局维度 1：1 进行入库。同时，如果上游已进行分库分表，TiDB 也可以使用 DM 完成合库合表的操作，将分散的数据在 TiDB 汇聚成一个全局的汇聚库。
在多源汇聚的场景中，TiDB 对汇聚查询也有着天然的优势，用户不需要接入新的技术栈，只需要保持 SQL 技术栈就可以完成复杂的任意维度的分析查询 。这意味着 TiDB 可以在汇聚库上完成跨服务单元的后台数据批量操作，包括复杂的查询和报表类查询。同时，在整个业务中，原来共享的库仍然是以逻辑单独库的形式存在于 TiDB 的大集群中，提供服务。由于存储规模天花板相对较高，TiDB 的存储和计算能够通过不断加入节点进行横向扩容。
在实时数据汇聚场景下，TiDB 有一个 Web3 用户案例。该用户在使用 TiDB 前，由于其业务特性要求，数据分散存储在 RDS 上。随着需求增长，用户需要提供 toC 类的损益分析、查询和内部运营分析。因此，客户使用 TiDB 的 DM 产品通过解析 Binlog，实时将上游业务库的数据汇聚到一套 TiDB 集群中。随着业务规模的不断增长，该集群最终规划的集群大小达 100TB。此外，TiDB 还能够同时支持 C 端和运营分析类查询，保证了数据服务的全面性。整个数据的时效性和新鲜度也非常高，无论是 C 端用户还是内部运营分析人员，看到的数据都是实时展示的。
核心支付
在第三个场景中，TiDB 主要涉及支付领域，例如商业银行的联机交易和第三方支付公司的移动支付等核心业务系统。通过使用 TiDB，可以为用户提供大规模吞吐量、高并发联机交易、多中心、多数据容灾以及弹性扩展机制。此场景的特点在于对安全性、稳定性和可靠性的高要求，需要提供分布式计算、分布式数据库管理和在线扩展的能力，并具备高并发、低延迟和大吞吐量的数据处理能力。由于它是一种类似于联机交易的支付场景，因此对整个事务的要求和数据一致性要求也非常高。
传统方案中，为了解决业务需求，通常会采用分库分表架构。然而，传统 MySQL 分库分表架构也存在一些问题。分布式中间件对应用程序的侵入度较高，这意味着整个应用需要进行较大的改造和调整，相对来说比较复杂。一旦采用分库分表架构，应用模型和数据模型都会变得相对固定，从而牺牲了灵活性。由于支付场景对事务的要求很高，而引入分片这样的中间件解决方案在分布式事务方面的能力相对较低，需要在应用开发方面进行调整和适配。此外，采用分库分表后系统的弹性扩展和在线扩展能力也必然会受到限制，主从模式的高可用架构存在风险。在业务高峰期，无法完全避免主从之间数据同步的延迟。一旦数据库出现延迟，整个高可用架构和容灾能力都会下降。
面对这些问题，通过 HTAP 数据库 TiDB 可以迎刃而解：
首先，TiDB 的使用方式近似于传统单机数据库的访问方式，对整个应用的访问是透明的，无论是应用模型、数据模型还是整个事务的交易模型，无需人为切割。在整个核心交易支付场景中，也无需指定 Sharding key，不会限制后续数据查询的灵活度。
同时，TiDB 的多中心多活容灾机制能简化整个部署的复杂性，无需管理十几套甚至数十套主从模式的集群。它完整地支持了整个分布式联机交易的事务，无需应用提前规避和处理。
此外，TiDB 还提供了一个动态调度机制，使在线扩容节点时完全不会影响业务，后台会自动进行数据均衡。
在该场景中，有一个日本顶尖的支付应用公司将 TiDB 应用在核心支付场景的案例。该客户在 2019 年 10 月上线了第一个 TiDB 集群。截至目前，客户的 TiDB 集群主要应用于支付和钱包等核心业务，涵盖支付查询、支付流水管理、钱包余额和钱包返现等功能。
在使用 TiDB 之前，该用户的架构基本上是使用主从模式的 RDS。这使得其无法随着业务增长在容量和吞吐量方面得到很好的支持。此外，该移动支付客户还需要应对一些大促销带来的动态扩展需求。在这样的核心场景下，不希望出现主从同步延迟和高可用性降级问题。为解决这些问题，客户考虑到 TiDB 首先是兼容 MySQL 的，因此相对于业务改造和迁移，工作量较低。此外，随着数据量的大幅增长，不需要采用分库分表方案，应用逻辑相对简单，且读写均能水平扩展。
在同类业务场景中，TiDB 有许多成功案例。考虑到这一点，该用户决定将支付核心业务迁移到 TiDB 集群。结果显示，在迁移后，整个系统的吞吐量提升了三倍。
实时风控
最后一个场景是实时风控，它在金融科技行业中扮演着重要的角色。实时风控需要整合各种业务提供的能力，包括征信、额度和反欺诈等，以提供企业级的统一风控入口。随着业务的发展，实时风控的要求也不断提高。例如，针对关键应用数据，需要同时具备实时数据分析的能力，以对交易流水、反欺诈和决策分析等实时数据进行批量处理。
在过去，实时风控在数据链路处理这一侧的链路相对较长，涉及到的数据库品类也非常多，限制了其扩展能力。此外，无论是在数据链路还是数据服务这一侧，都存在限制。在数据链路这一侧，由于链路较长，数据处理变得复杂。在数据服务这一侧，数据被存放在多个地方，因此在灵活性和扩展性方面做出了一定的牺牲。在实时风控的场景下，通过将 TiDB 与传统的大数据生态技术栈（如 Flink 和 Kafka）结合使用，可以显著提高数据价值获取的能力，不管是作为单独的实时数据分析处理引擎，还是传统的大数据技术栈，这也意味着整个数据链路处理侧相对简单。通过流式的方式实时接入客户行为和反欺诈等数据，然后利用 TiDB 的 HTAP 能力进行实时的数据分析聚合。最终提供统一的 API 支持高并发查询的能力。
在这个场景中，典型的客户案例是互联网银行。在使用 TiDB 之前，互联网银行客户面临了许多问题。他们的数据分散在不同的数据库中。为了处理风控指标，需要查询不同的数据源，然后进行汇总处理。但随着业务增长和需求变化，原先的技术栈 MySQL 出现了性能瓶颈。此外，MySQL 在实时分析场景的性能相对较差。基于这些考虑，客户在在线风控场景下使用 TiDB 替换原有技术栈。使用 TiDB 后，整个技术架构发生了变化。业务前端的数据，包括交易、用户行为、征信和身份认证等数据，通过 CDC 实时同步到 TiDB 集群中，大数据相关的风控指标则通过 ETL 进行抽取。最终，通过实时获取和分析，使用统一的 TiDB 数据库完成了在线风控和反欺诈业务流程。
总结
本文主要介绍了 TiDB 在在线事务处理（OLTP）场景、实时数据聚合和分析场景下的解决方案。除了在 Fintech 行业得到广泛应用外，TiDB 所具备的能力和价值也在许多互联网客户中也得到了应用。目前，全球已经有近 3000 家企业客户使用 TiDB，覆盖了电商、智能制造、物流和游戏等领域。
京公网安备 11010802035112 号