导读
在当今快速发展的金融科技领域，技术的创新与优化是企业保持竞争力的关键。数禾科技，作为一家以大数据和技术为驱动的智能零售金融解决方案提供商，始终致力于通过技术创新来提升业务效率和服务质量。其主要产品还呗 APP 激活用户已达 1.3 亿，累计交易金额突破 3100 亿元。随着业务的迅速扩展，数禾科技面临着日益复杂的技术栈挑战。如何在确保系统稳定性和数据处理能力的同时，简化技术架构并降低运维成本，成为数禾科技亟需解决的关键问题。
通过引入 TiDB，数禾科技不仅成功简化了技术架构，还显著提升了数据处理能力和业务响应速度。这一举措不仅帮助公司降低了 50% 的资源成本，还为数禾科技在金融科技领域的技术创新积累了丰富的经验。本文将详细分享数禾科技在使用 TiDB 进行技术栈简化过程中的实践与经验。从技术选型的考量、实施过程中的挑战与收获，到运维管理的策略与创新，全方位展示数禾科技如何借助 TiDB 实现技术架构的优化升级，为金融科技行业的技术发展提供有益的借鉴和启示。
TiDB 在数禾的应用场景
数禾科技将 TiDB 应用在多个核心场景，如特征、获客、对账系统等。其中，特征是数禾非常重要的场景。在数禾科技的业务中，特征是指在策略、模型、分析中用到的、与某个主题绑定的数据。特征可以分为离线特征和实时特征。离线特征通常是定时跑批生成的，如用户的属性数据；而实时特征则是实时计算并生成的，具有更高的时效性，能够更好地反映用户的即时状态。特征平台的高效运作对数禾科技的业务决策和风险控制至关重要，与用户体验和交易息息相关。TiDB 在数禾科技特征场景的应用 QPS 达 1.5 w，主要搭了两套大集群，一套承载离线特征，一套承载实时特征。
数禾特征计算使用 TiDB 进行技术栈简化的实践和收益
技术栈简化前的挑战
在引入 TiDB 之前，数禾科技的技术栈包括 MySQL、Kafka、Flink 和 HBase 等多种技术。复杂的技术架构带来了诸多挑战：
- 开发复杂、周期长：数据从 MySQL 通过 DTS 同步到 Kafka，再由 Flink 消费并计算后写入另一个 Kafka，最后应用消费 Kafka 并经过一系列转换后存入 HBase。整个过程不仅开发复杂，而且周期较长；
- 成本高：云上的 Kafka、Flink、HBase 等服务费用较高，增加了企业的运营成本；
- 延时长，用户流失率高：由于数据处理链路较长，特征的平均延时超过 10 秒，在某些场景下导致用户流失率较高。
用 TiDB 实现技术栈简化后的收益
- 开发门槛降低，只需会写关系型 SQL；
- 链路更加清晰，不需要那么多链路数据流转，1s 以内就能返回给用户；
- 运维管理更加方便，只需要管理 TiDB；
- 特征数据时效提升：基于数据源实时计算；
- 开发简单了，交付周期大幅缩减：从 7 天降至 3 天；
- 资源成本降低 50%：资源就只用了 TiDB，所以资源成本也会降低很多。
数禾特征运维实践
数禾特征集群的容灾架构
正因为特征集群的重要性，所以我们需要考虑 TiDB 的容灾方案。在选择容灾方案时，综合考虑了成本、可用性、数据一致性及性能等因素，最终确定了一套既满足业务需求又具备高性价比的方案，即将 TiDB 的 TiKV 和 PD 组件分别部署在三个可用区，利用 TiDB 自身的 Raft 协议实现高可用性。当一个可用区出现故障时，系统能够自动切换到其他可用区，无需人工干预，RPO（恢复点目标）为零，自动恢复时间小于一分钟。同时，三个可用区的资源都能充分利用，避免了资源浪费，也符合公司对成本效益的期望。我们也对特征场景进行了全面的性能测试，选择了复杂的查询场景，涵盖多表 join 等高难度操作，性能表现也比较满意。
数禾 TiDB 资源管控实践
目前，数禾的一些应用都在往 TiDB 上面迁移。在资源管控方面，我们目前也在集群内部，通过连接不同的 SLB（服务器负载均衡器），并在 SLB 上挂载不同的 TiDB 节点，实现了计算资源的隔离。同时，我们还为每个应用配置了不同的资源单元（RU），根据应用的特点进行资源分配。RU 的优势在于，当出现突发流量时，我们能够迅速识别出哪个应用的 RU 上涨，从而为资源管理和账目核对提供了极大的便利。
数禾 TiDB 新特性实践
1. 应用端自动 kill
在当前架构中，特征计算和调用都依赖于 TiDB，这使得两者在资源上存在耦合。如果线上查询中出现复杂查询导致响应变慢，将直接影响客户端调用的响应速度。为了解决这一问题，我们在应用端实施了自动 kill 策略。具体来说，在应用的 URL 中设置了查询超时时间，当 SQL 执行时间超过 300 毫秒时，系统会自动终止查询，从而避免长时间运行的查询对客户端调用造成影响。
2. 熔断功能
我们还引入了熔断机制来进一步保障系统的稳定性。例如，如果在过去五分钟内，某条 SQL 执行了 1000 次，其中有 100 次执行时间超过了预设的阈值，系统会判断这条 SQL 存在问题，并自动将其熔断，直接返回错误信息而不进行计算。这样可以防止因单个特征计算的问题导致其他特征调用受到影响，确保整体系统的稳定运行。
3. 运维平台
我们定期采集 TiDB 集群的相关元数据和血缘关系，并将其统一展示在运维平台上。这为运维人员提供了全面的监控和管理视图。未来，我们计划进一步扩展运维平台的功能，包括实现自动扩缩容和 SQL 熔断功能，以提升运维的自动化和智能化水平，更好地支持业务的高效运行。
数禾对 TiDB 的期待与计划
TiDB v8.5 稳定性提升
TiDB v8.5 在稳定性方面还是下了很大功夫的，对于数禾来说，我们会比较关注以下这些新特性：
- TiKV MVCC 内存引擎：当我们对一张表删除大量数据过后，返回就会很慢，而这个功能对我们的响应时间应该会有很大提升；
- 默认允许将默认允许将 Projection 算子下推到存储引擎；
- 统计信息收集忽略不必要的列；
- 支持为资源管控的后台任务设置资源使用上限：这个对线上的稳定性有很大的提升。
对 TiDB 演进方向的期待
- 支持冷热存储，冷存接入 OSS；
- 数据备份恢复支持到表级别；
- TiCDC 支持同步至 ADB，支持更改库表名；
- SQL 洞察功能。
数禾 TiDB 后续计划
- 超过 50G 的大表，推动开发逐步迁移至 TiDB；
- 尝试使用 TiFlash，将一些偏分析型的业务迁移至 TiDB。
总结：数禾选择 TiDB 的理由
在选择分布式数据库的过程中，除了产品力本身，社区活跃度是一个至关重要的考量因素。数禾科技在打磨自身产品后，具备了获客和风控等多方面的技术优势，我们也希望通过技术输出，让下游客户也能掌握这些能力。因此，我们希望客户对所使用的数据库有一定了解，在遇到问题时能够自主排查和解决。TiDB 社区的活跃氛围为我们提供了这样的支持，丰富的技术交流和分享，使得客户能够更好地理解和使用 TiDB，增强了我们选择它的信心。
与此同时，分布式数据库作为一种先进且复杂的技术，难免会存在一些问题。在使用 TiDB 获得性能提升和功能优化的同时，我们也应以包容的心态面对它带来的挑战，与 TiDB 社区携手共进，积极参与到技术讨论和问题解决中，共同推动 TiDB 的发展和完善。最终，那些敢于拥抱新技术、勇于面对挑战的企业和个人，必将从中获得更大的收益，数禾科技也将持续受益于这种与社区共同成长的历程。