文章来源：InfoQ 数字化经纬
作者 | 赵钰莹
嘉宾 | 伍春兰 中欧财富技术总监
导读
本文采访了中欧财富技术总监伍春兰，探讨了财富管理行业数字化转型面临的挑战，包括人才、安全和技术基础架构。在数据库迁移中，中欧财富通过采用分布式数据库 TiDB 解决了 MySQL 的旧有问题，强调了 HTAP 融合架构在性能和资源管理方面的重要性。文章指出，数字化转型需要跨足思维、组织、流程和平台等层面，以适应日益高效和创新的需求。阅读全文约需 12 分钟。
本文要点
- 财富管理领域近几年受内外部环境的变化，对技术底座能力提出敏捷高效、及时创新等较高要求；
- 数字化转型不是一个技术问题，涉及思维、组织、流程、平台四大层面；
- 财富管理领域企业数字化转型主要面临人才，安全、基础架构（技术）三方面的挑战；人工智能技术在财富管理领域企业内部大规模落地还需要时间；
- 在数据库选型之前，企业需要先定位清楚需求；
- 数据库迁移前，旧有的 MySQL 体系主要遇到的问题是大表 DDL 耗时、分库分表耗费大量人力、单节点写入易出现瓶颈等问题，最后通过分布式数据库 TiDB 解决了上述问题；
- 在评价数据库迁移前后的效果时注意运维、资源等隐形层面的成本；
- HTAP 融合架构在性能、资源精准消耗等层面都起到了重要作用。
中欧财富数字化转型升级的思路、难点及实践
InfoQ：财务管理公司和基金公司这几年节奏明显变快，其背后的推动力到底是什么？财务管理行业的数字化转型存在哪些痛点？
伍春兰：最近几年，基金公司内外部环境都发生了比较大的变化。自 2013 年伴随着余额宝的兴起，整个互联网业务快速发展，这对市场带来了几个明显的变化：第一个变化是用户基本盘迅速扩大，要想服务好用户，技术迭代速度需要更快。举例来说，一些互联网属性的公司数据刷新较快，中欧财富为了达到这个效果，整个公司做了比较大的投入和配合，包括引入人工智能技术做一些自动化的事情；第二个变化是互联网业务比较有特点且信息较为透明，用户可以迅速看到市场上出现了哪些新的业务与渠道，这要求团队时刻保持敏捷和高效，包括与上下游业务的打通；第三个变化是业内开始出现新的营销形式，比如通过直播的方式进行营销，或者运营新的平台，比如抖音等，这需要企业打通内部的运营流程和数据，这对技术团队提出的要求同样是及时创新、敏捷高效。
综上，公司需要抓住机会，迅速做出决策，以应对这些变化。比如，打破原来的数据孤岛，形成统一的、智能的数据中台，基于这个中台可以更好地挖掘客户特性、绘制用户画像，从而让产品更好地满足客户需求；与上下游的机构和企业合作时需要具备强大的研发能力，包括模型、算法、定制化能力等都必须与互联网大厂的研发实力相匹配。
纵观内部和外部，难点主要在于：一是人才方面，并不是每一家金融企业都匹配了强大的且对技术趋势敏锐的研发团队；二是资源投入能力，比如产品层面的投入是否跟得上；三是数据安全，在适配互联网快节奏的业务更新和及时响应的前提下保证公司内部、与上下游企业合作全链路的数据安全是非常重要的；四是在旧有基础架构上做敏态升级，包括基础设施、运维、研发、产品等。
InfoQ：第二大变化中的“打通上下游”具体指什么？
伍春兰：数字化转型一是思维、二是组织、三是流程、四是平台。思维上，数字化转型不是某个部门的事情，过程中涉及组织及流程上的变化，需要保证大家思维统一；组织和流程上，数据打通就涉及跨部门共享，思维对齐的情况下还需要保证组织层面可以尽可能流程化，快速推动相关决策。比如新业务上线，可能涉及运营、产品、研发等多个部门，大家是否可以透明地了解整个执行链路，清楚了解公司的决策背景，只有每个部门都参与其中才能真正做到流程提效，而不仅是完成工作。平台上，数据打通之后能否真正用起来，数据质量需要达到什么程度都是平台要重点优化的事情。
InfoQ：针对人才，安全、基础架构三大难题，中欧财富是如何解决的？
伍春兰：在人才方面，中欧财富于 2014 年左右开始筹备，招聘的大多数员工背景偏互联网和核心金融机构方向，这些员工不仅了解金融的业务形态，同时具备较高的技术能力和敏锐度，整个架构起初就适配了互联网时代的特点；安全层面，除了符合国家相关监管规范的要求，中欧财富本身也做了大量探索，比如防 DDoS 攻击、流量清洗、内网监控、数据安全和审计等，这些能力经过过去三四年的发展逐渐建立起来，但要做到完全自动化还是比较困难的。基础架构层面，如前文言，初始架构已经适配了互联网时代的特点，在过去多年的演进中，中欧财富又针对不同的模块进行了优化，包括分布式数据库体系建立、私有云体系优化等。
InfoQ：您方便举例说明中欧财富通过数字化转型取得了哪些成果？
伍春兰：以投顾业务为例，首先该业务需要迅速理解客户需求，并基于数据驱动的逻辑做出快速、敏捷的反应，这对底层的数据能力要求较高；其次，作为国家首批五家基金投顾业务试点公司，中欧财富主要优势在于强大的自主研发能力。过去五年，中欧财富针对整个基础架构进行了升级，底层基建与行业技术演进的大趋势相匹配，实现了软件定义及弹性部署，降低了计算和运维成本。目前，公司业务全面部署在基于 K8s 的私有云上，可以很好地支持投顾等业务的发展。
InfoQ：如何看待人工智能技术在财富基金领域数字化转型中发挥的作用？
伍春兰 ：对于人工智能技术的落地，我认为大规模落地还是有难度的。虽然目前很多公司在这方面都有动作，但更多的是尝试，比如智能客服、敏感词审核等。在实际业务中，人工智能更多是在扮演辅助的角色，而不是代替很多人的劳动。
具体到金融领域，因为该领域强监管且对专业性要求较高，因此目前现有的、通用型的大模型可能无法很好匹配需求，未来可能会出现针对该领域的大模型，只是还需要一些时间。
面向未来，中欧财富如何联手 PingCAP 打造分布式数据库体系？
2.1 迁移前的旧有数据库体系基于 MySQL 搭建
InfoQ：中欧财富在与 PingCAP 的 TiDB 数据库合作之前，内部的数据体系是什么状态？
伍春兰： 在此之前，中欧财富的数据库体系是基于 MySQL 搭建的。随着业务的逐渐发展，传统的数据体系遇到了一些问题，中欧财富开始思考是否存在一些新的工具、平台、产品可以更好地满足目前的诉求。
在技术层面，团队当时面临着三大比较明显的问题：一是大表的 DDL 操作，该操作一般通过 gh-ost 工具去实现，非常耗时，且会产生大量 binlog 影响下游的同步。如果遇到有分表逻辑的大表，整个 DDL 过程需要持续几天；二是分库分表，单表数据量增速非常快，时常需要进行分表处理。但开发资源有限，没有这么多人力可以投入到分表工作中；三是单节点写入，MySQL 传统的一主多从架构，主节点承担应用的写入。当有清算或跑批任务时，主节点会出现写入瓶颈。
2.2 分布式数据库选型及迁移
InfoQ：在分布式数据库选型层面，中欧财富主要看中哪些因素？
伍春兰： 中欧财富在数据库选型层面主要看中整个架构的高可用性、去中心化、性能高且没有单点故障以及可以降低运维成本。以单点性能为例，虽然 MySQL 时代可以通过增加机器的方式来解决问题，但总体无法实现弹性扩展。经过对一些互联网公司数据库选型的调研，以及对市面上现有数据库产品的了解，最终团队抱着“试一试”的心态开始接触 TiDB。
选型确定后，研发团队对 TiDB 的稳定性、可用性、扩展性等进行了半年左右的测试，整个平台都放到了 TiDB 之上，包括核心业务，综合体验其对场景的适配情况。其实，数据库是一个非常复杂、庞大且核心的工程，且需要与时俱进。TiDB 在当时提出的存算分离等理念与场景能力特别匹配，且经过多方交流，其架构足以承担未来多年数据量的持续增长。
InfoQ：中欧财富的数据库迁移主要分了哪几步？
伍春兰：中欧财富从 2021 年开始进行调研、测试，2022 年开始部署、上线，并于今年进行深度测试并完成 30% 的业务迁移，包括组合投顾系统、营销系统、产品系统、用户系统和交易系统，未来希望可以实现全量业务运行在 TiDB 之上。
回头来看整个过程，中欧财富的方法还是比较科学的。一是，企业需要对当前的情况有充分认知，清晰定位需求并匹配合适的产品；二是团队需要充分印证升级后的数据库整体架构，对未来演进有明确的方案；三是培养人才，中欧财富和 TiDB 团队做了大半年的密切交流，并在其社区中学习，对其技术能力、研发能力、现有市场、可预见的协同、定位、技术演进方向等都有了充分了解；四是准备备案，即双轮驱动。起初，业务在 TiDB 和旧的 MySQL 体系上同时运行，这种模式下运转了大半年之后，整个技术架构完成了较好适配（当然，TiDB 本身兼容 MySQL 协议），业务运转良好后开始进行正式迁移，双方团队一起完善新老架构的兼容及下游系统适配。迁移过程中，下游不会感知到上游的架构变化，团队做了充分的准备并严格按计划执行。
生产 TiDB 集群配置如上图，为了应对复杂的业务场景，硬件层面都选择了超配。架构方面，计算层用了 5 台服务器，其中 3 台 TiDB-server 和 PD 混合部署，另外 2 台用于接收复杂 SQL 的请求（资源隔离）。每台 TiKV 服务器下挂三块盘，每一块盘都作为一个独立的 TiKV 节点，所有 TiKV 一共有 3*3=9 个节点。集群架构可见下图。
2.3迁移后的整体评价
InfoQ：您对于数据库体系更换的整体评价是什么？
伍春兰：一是敏捷性，不需要在资源分配层面投入过多精力，可以更快推行创新业务；二是简化了公司架构，统一数据库架构之后降低了运维难度和升级换代的难度；三是 HTAP 架构下的一些计算任务的链路缩短，风险相对更加可控；最后是有利于未来的业务创新和增长。
具体到技术层面， TiCDC 简化了数据同步，TiCDC 可以将 TiDB 内的数据同步至 MySQL 和 Kafka （canal - json 格式），大大降低了数据同步的改造工作；可观测性，配套的 dashboard 和 grafana 非常好用。测试阶段遇到问题或性能瓶颈，可以快速地定位出问题，加大测试的效率；服务器硬件故障，集群内服务器硬件故障导致宕机，没有影响任何业务；后续配件更换的停机流程也非常丝滑；Tiflash 优化模糊查询，业务有模糊查询的需求，通过 TiFlash 将行存数据转为列存，同时利用 MMP 对查询进行加速。
InfoQ：从运维角度来看，迁移前后的成本发生了哪些变化？
伍春兰 ：整体来看，运维层面还是节省了很多成本。举例来说，原有体系需要拆分出大量集群来运营数十个应用，现在只需要一个 TiDB 集群就可以解决问题，这种运营和计算资源（服务器等）成本是隐形的，因此整个迁移过程已经满足降本增效了。当然，很多企业可能足以承担这些成本，但运营效率也是不同的。更换之后，运营效率、架构敏捷度得到了极大提升，这在当前的业务场景下至关重要。
那么，为什么前几年企业不谈这些内容呢？在非互联网、非充分竞争的情况下，这些问题可能不是最关键的，靠人力驱动也可以搞定。但是，现在的市场环境下，效率在很多时候起决定性作用，这就逼得很多企业不得不对旧有的数据体系做出调整，而且企业不需要在纠结底层的选型和适配问题，资源全部池化，企业可以把所有精力投入到业务本身来获取最终的增长。
InfoQ：研发同学对于 TiDB 有哪些使用反馈？
伍春兰：从研发视角，首先我们对自己有清楚的认知才选择了 TiDB；其次，如上所言，运维难度和成本的降低是可以感受到的；再次，大厂倡导的分库分表技术肯定是成熟的，但对小企业来说，这带来的工作量是巨大的，在研发资源有限的情况下，这其中的成本不得不考虑；然后，业务需要及时、弹性，TiDB 的扩展能力让这一点成为可能；最后，TiDB 的 HTAP 融合架构解决了很多，以往的大批量数据计算任务对资源消耗极大且运行速度很慢，TiDB 在跑这类任务时资源隔离的情况下还能做到智能路由，资源隔离可以保证多个业务可放入一个集群，每个业务配置指定的 RU ，保证业务之间不会相互干扰。遇到突发流量，也可以控制爆炸半径，帮助精准判断资源消耗，而且性能非常好，这对业务发展非常重要。
2.4未来计划
InfoQ：未来的迁移计划是什么？
伍春兰：整体规划是今年完成 70%-80% 的业务迁移，目前已基本完成前期筹备工作。如果进展再快一些，今年底到明年初预计可以完成 90% 的业务迁移，基本涵盖整个互联网所有的核心业务。希望在市场新的机会到来之前，整个底层平台能力准备充分。我相信，未来是有广阔前景的。
在技术层面，未来会尝试用 TiProxy 替换 Haproxy 或 F5 ，能够保证集群无损升级，提供限流、熔断等高阶功能，未来可以抓取所有 SQL，实现流量重放，提高测试效率；功能集成，将 Dashboard、TiUniManager、DM-web，甚至 TiCDC 的管控集中在一个平台，该平台还能提供备份管理、告警调整等辅助功能；巡检功能，很多时候要靠人去分析 Dashboard 和 Grafna 的 Performanceoverview 来判断集群情况。巡检功能可以省去人力开销，依托 AI 给出准确的集群运行报告，并附上相关优化建议。