1).场景描述
随着金融数字化转型的深入，越来越多的金融业务向个性化、精细化、智能化方向发展，其对底层数据库也提出更高要求，包括对海量规模、实时分析、高并发访问等。传统数据库架构已难以满足上述需求，急需完成技术架构升级。作为典型金融场景之一，交易明细查询作为基础服务发挥着关键作用，其背后的银行卡交易流水记录对个人和企业的财务管理至关重要，同时也是贷款审批、税务申报及司法审计等过程中不可或缺的数据支撑。交易明细查询通常指依托交易类数据的存储和服务、由渠道类系统提供展现的客户级交易记录列表、详情查询等服务，属于典型的数据类服务，具有明显的时间访问特征。金融业务的数字化转型推动了银行交易明细查询系统的变革。交易明细数据的使用呈现出新的特点：一方面查询方式从传统柜台扩展到手机和网上银行等多种方式，其查询时间跨度也从三个月、六个月延长到三年甚至五年以上。这对于底层数据平台提出了更高的要求，包括在查询方式多样化、时间跨度灵活性、查询实时性以及海量数据存储等诸多方面。
2).技术特点
❖ 海量的存储容量
为了兼顾客户体验和监管要求，数据保留期限和可供查询范围需要满足更长时间跨度。由于交易明细数据处于持续动态增长过程中，保留明细数据的时间越长，接入业务系统越多，数据关联服务能力越丰富，客户服务体验就越好。这就需要数据平台支持海量存储规模且可通过横向扩展提升容量，最终具备准 PB 级别的数据总体容量。
❖ 准实时数据同步
为了给核心系统减负，通常此类平台通常独立建设，并与核心系统将使用数据同步完成数据流转。为进一步提升服务品质，对数据同步延迟提出了很高的要求，一般需达到秒级数据同步能力，并结合流式计算、实时分析技术扩展出更多的业务场景，如通知类服务、基于标签的收支分析、实时报表统计等，持续提升高价值交易数据的利用率和客户体验。
❖ 高并发与高性能
交易明细查询系统需面对海量的在线客户提供查询服务，客户能快速感知服务状态，因此需底层数据平台保证高并发访问下的服务质量，平台需具备通过横向扩展能力提升可并发连接容量。
❖ 连续性和稳定性
交易明细查询系统需支持大量业务系统，支持包括移动端在内的电子渠道的查询功能，其稳定性与服务连续性直接影响用户使用体验，因此系统需具备长期稳定可靠运行能力，具备多种高可用及容灾保障机制。
❖ 复杂工作负载支持
整个交易明细查询系统上下游涉及多个处理环节，包括采集、处理、服务等。采集部分包括日志捕捉与回放、批量数据导入；处理部分包括数据修正、宽表加工等；服务部分包括为不同业务系统提供的查询类服务，这其中又分为联机和批量业务，前者的优先级更高。上述多种工作负载要求底层平台具备隔离能力，以支持在不同工作负载下都能良好工作。
❖ 良好的存储经济性
交易明细查询系统需要存储大量明细数据，且数据具备明细的时间特点，用户访问上也具备与时间周期强关联的冷热特征。因此，底层数据平台应具备良好的存储支持性，支持包括数据压缩、冷热数据分离等技术，进而实现降低存储成本的目的。
❖ 全域可观测能力
如上所述，交易明细查询系统具备多种工作负载、多样化查询需求、差异化的数据热点等特点，这些都对基础运维提出了更高的要求，因此希望底层数据平台提供全域可观察的能力，能直观、全面的反应整体运行状态。
❖ 自主可控与系统安全
随着金融业整体技术战略发展，都对关基提出自主可控的需求，希望通过自主可控技术体系建设系统，不受传统供应链限制，能有效应对技术体系迭代快、数据量变化快、业务多变的新业态场景。作为交易明细查询支持系统的基础平台，也应满足同样的要求。
3).技术架构演进
❖ 阶段一：“以交易为中心”
业务应用形态以“源系统耦合”为代表。交易领域系统生成和存储全量交易明细，采用分区表归档历史数据并提供查询服务。这一阶段主要以 Oracle 等集中式数据库为主，数据通过原始格式进行明细查询。
❖ 阶段二：“以数据为中心”
业务应用形态以“下游托管”为代表。采用准实时或离线数据交换的方式将交易系统明细数据同步到下游的查询系统，根据数据同步频率，接管部分或全部的查询服务。这一阶段多采用 Hadoop 大数据生态或分库分表中间件架构为主。前者通过批量任务完成标签化，支持离线多维度查询；后者则通过数据拆分实现高并发下的明细查询。
❖ 阶段三：“以客户为中心”
业务应用形态以“统⼀视图多元服务”为代表。采用实时或准实时同步的方式将交易系统明细数据同步到下游的查询系统。这一阶段多采用 NewSQL 数据库构建⼀站式综合数据服务平台，提供数据实时、多源关联的服务能力，借助平台的可扩展能力实现高并发访问、HTAP 能力实现复杂查询支持。
1).解决方案概述
从数据流入来看，交易系统数据通过逻辑复制工具或者消费变化日志消息将上游新增数据实时地写入到 TiDB。根据数据源类型，可选择使用 TiDB 自带兼容 MySQL 的增量数据复制工具或者第三方提供的兼容 Oracle 和 DB2 等的异构复制工具，也可以通过文件加载或者大数据平台直写等方式写入明细查询库。多数据写入手段既兼顾实时性需求，也能提供多样化的选择。
从数据加工来看，交易系统的原始明细数据写入查询系统后，进一步扩展交易信息字段提升查询效率和个性化的服务能力，包括交易机构、对手方信息及业务标签等，成为真正适用于明细查询的宽表数据。数据加工批量任务采用时间窗口内的新增数据进行区间拆分的方式，由多个子任务执行，并行执行维度关联语句再写⼊业务宽表，最大化利用 TiDB 数据库的吞吐能力。明细加工数据可以进⼀步流转到数据仓库，结合数据仓库中的其他数据进行分析生成各种报表和数据可视化结果。
从数据查询来看，业务宽表数据以服务接口的方式面向查询渠道，随着服务接口能力维度的扩展，按账号、产品、时间、业务标签等条件组合查询，对客服务的查询接口调用频次和接口流量将大幅度提升。针对批量和交易两种任务类型共存或者不同查询交易的逻辑复杂度的区别，多个服务应用或者接口对应的数据库用户或者语句配置 TiDB 数据库的资源组，实现不同业务的资源隔离。
从数据管理来看，根据数据生命周期的时间区间定义，系统数据被划分为热数据、温数据、冷数据、归档数据，针对不同分层的数据制定相应的存储设备和资源规格要求，以及分层之间的迁移条件和方式。例如：近 1 年的数据定义为热数据，存储在高规格的服务器和高性能的 NVMe 介质，温数据及以下可采用云盘等存储介质。
从运维管理来看，充分利用 TiDB 提供的图形化管理（特别是内置的热点分析）能力，实现一站式的管理。此外，TiDB 集群支持采用同城两中心或两地三中心的部署方案，满足对高可用及业务多活的需求。
从自主可控来看，TiDB 适配 x86 和 ARM 在内的多种硬件架构，能够在全国产化平台上运行。能支持同⼀个集群中两种架构的硬件共存，可以实现业务在线的情况下从非国产化平台到国产化平台的跨平台架构迁移。
2).解决方案亮点
针对上面解决方案，我们将场景需求与产品关键能力对应起来。也就是说一款产品适合某场景的原因所在。
3).解决方案实践
4).案例挖掘与分析
通过对上述案例的深入分析，我们发现不同体量用户在交易明细查询业务上，仍然存在不小的差异且各自的关注点有所不同（如下表）。通过对这些宝贵案例的挖掘与分析，可以为后续进一步推广打下良好基础。同时，用户也可以根据案例及自身情况，“按图索骥”找到适合自己的产品及方案。
写在最后
