{
"componentChunkName": "component---src-templates-blog-blog-detail-tsx",
"path": "/blog/a-brief-discussion-on-htap-and-finance-application-scenarios",
"result": {"pageContext":{"blog":{"id":"Blogs_465","title":"浅谈 HTAP 混合技术和金融业应用场景","tags":["TiDB","HTAP"],"category":{"name":"案例实践"},"summary":"本文由中国银行软件中心（西安）个人业务研发部对客交易综合查询开发团队撰写。近年来，随着大数据应用场景的快速普及与多样化发展，传统的数据处理方案已愈发难以满足海量数据实时分析的数据处理需求，HTAP 具有明显的技术优势。","body":"> 以下文章来源于公众号中国金融电脑+ ，作者中国银行软件中心\n\n**本文作者**：中国银行软件中心（西安）个人业务研发部对客交易综合查询开发团队\n\n近年来，随着大数据应用场景的快速普及与多样化发展，传统的数据处理方案已愈发难以满足海量数据实时分析的数据处理需求。针对上述挑战，混合事务/分析处理（Hybrid Transaction and Analytical Process，HTAP）架构的出现为打破事务和分析之间的“隔阂”提供了可行方案，根据 Gartner 提出的概念，HTAP 架构的目的是在单一数据上不加区分地处理事务和分析任务。从发展历程来看，相比于联机事务处理（OLTP）型数据库、联机多维分析处理（OLAP）型数据库，HTAP 具有明显的技术优势，可以有效避免频繁的数据搬运操作，减轻系统额外负担，并降低数据的重复存储成本。\n\n## HTAP 特性及架构简介\n\n在大数据业务领域，事务（Transaction）和分析（Analysis）具有强相关性，人们为了进行海量数据的实时分析，发明了 TA 融合这一技术，而 HTAP 则是在存储、计算等方面具有极佳的线性扩展能力，能够更好地解决海量数据的容量问题。具体而言，HTAP 的典型特性如下：\n\n- 一是支持 TP 与 AP 混合的事务处理和分析过程。\n- 二是具有水平扩展能力，通过简单增加新节点即可按需实现 TiDB 的水平扩展，进而轻松满足高并发、海量数据场景需要。\n- 三是支持 SQL 请求在不同节点自由调度，少量工作节点宕机并不影响业务连续性，且在不丢失大多数副本的前提下，还可以实现故障自动恢复。\n- 四是支持两地多中心高可用架构部署，包括同城两机房双活及异地机房的实时切换。\n- 五是支持强一致分布式事务以及标准的 ACID 事务。\n- 六是可高度兼容 MySQL 协议和常用的功能及语法。\n- 七是可对数据库服务集群环境和数据库各进程以及运行 SQL 进行实时监控和告警。\n- 八是可根据请求 SQL 的特性，自动决定触发 TP 事务引擎还是 AP 分析引擎。\n- 九是具有独立的 TP 和 AP 引擎来支撑存储和计算需求。\n- 十是支持公有云、私有云和混合云，可实现自动化运维，简化部署、配置工作。\n\n## HTAP 在金融业的典型应用场景案例\n\n聚焦金融领域，HTAP 可高效支持高并发交易拼接加工、大批量交易加工、批量文件生成和推送等众多业务场景。举例来说，联机应用程序可实时对接收的交易数据进行拼接和加工，即通过关联方式对数据进行属性补齐，在夜间将每日批量交易中需要补齐、补漏的数据批量转联再进行加工；同时，还可每日批量对大数据量的交易进行加工，以及对交易明细进行月度、年度统计分析（至少可跨越 10 年）；此外，基于交易明细的实时分析查询结果，还可对交易明细按照交易类型、时间等维度进行统计并实时返回结果。TA 类型对应的金融业务应用场景见表 1，HTAP 混合特性与金融典型场景应用的映射关系见表 2。\n\n\n\n表1 TA 类型对应的金融业务应用场景\n\n\n\n表2 HTAP 混合特性与金融典型场景应用的映射关系\n\n## HTAP 数据库未来展望 \n\n当前，HTAP 数据库通常在 TP 和 AP 领域各有侧重，还无法做到同时支持 TP、AP 场景。对此，笔者团队建议在应用设计上可将非实时的海量、复杂、多维度数据加工场景，即重型批量处理操作放到 MPP 类、AP 类或者大数据平台实施；而对联机高并发、有实时聚合分析和轻量批量加工的场景则用 HTAP 来支撑。此外，在数据库设计和使用上尽量应用标准 SQL，以规避不完善特性带来的应用风险，并在应用侧通过分库路由策略来应对跨库数据访问，同时搭载数据同步工具来支撑数据库集群之间的数据交换。 \n\n展望未来，多元化需求场景决定了 HTAP 数据库不能是 OLTP 和 OLAP 的简单叠加，如果通过 OLTP 架构外扩实现 OLAP，显然只能算权宜之计，而基于当前对分布式数据库与大数据技术相互融合的需求，HTAP 或将成为数字化时代的一种普遍形态。同时，结合开源生态来看，HTAP 数据库未来仍需要在成百上千的业务场景中不断打磨，即将开源作为核心战略、构建高度活跃的开源社区将会是 HTAP 数据库的长远目标。最后，HTAP 数据库的发展还需能支持云原生架构，即在充分发挥云原生技术轻量化、松耦合、灵活度高等优势的同时，努力实现跨云与多云部署。\n\n团队成员：徐雅光、陈世强、韩路、罗皓、师鹏超（总体部）、肖柯舟、王朝阳、谢倩楠、黄慧玲、刘景怡、张鹏举\n\n","date":"2023-02-24","author":"中国银行软件中心","fillInMethod":"writeDirectly","customUrl":"a-brief-discussion-on-htap-and-finance-application-scenarios","file":null,"relatedBlogs":[{"relatedBlog":{"body":"> 本文转载自公众号：韩锋频道（hanfeng_channel） \n> **作者简介**：韩锋，CCIA（中国计算机协会）常务理事，有着丰富的一线数据库架构、软件研发、产品设计、团队管理经验；曾担任多家公司首席 DBA、数据库架构师等职，在云、电商、金融、互联网等行业均有涉猎；精通多种关系型数据库，对 NoSQL 及大数据相关技术也有涉足，实践经验丰富；曾著有数据库相关著作《SQL优化最佳实践》、《数据库高效优化》。\n\n作为数据基础设施的重要组成部分，数据库在其中扮演着重要的角色。近些年来，数据库整体发展也呈现出较之以往很大的不同。 \n \n其一是开源数据库受到更为广泛的关注，从多家机构的最新报告来看，开源数据库无论从产品数量还是受关注程度都超过商业数据库。开源这一新模式，正成为未来数据库发展的主流。 \n\n其二是云计算成为未来主要资源供给方式得到普遍共识。已经有越来越多的企业选择在云上构建基础环境，包括云上数据库的发展速度也远高于非云环境。据乐观估计，在未来 5~10 年云数据库将占据整体数据库市场的七成以上。此外，对迁移到公有云、使用多云环境等问题，也普遍被企业所接受。 \n\n其三是数据融合趋势，针对数据多场景应用，使用融合技术简化访问，提升效率。作为数据使用高地，金融行业一方面对数据库有着极高的要求，一方面又面临很多来自数据新的挑战，诸如海量规模、高并发、数据安全、实时分析等诉求亟待解决。分布式数据库的出现，迎合这一发展趋势，对于金融企业解决上述问题带来新的解决思路。 \n\n本文从金融用户角度入手，对如何选择分布式数据库及选型后的最优实践进行阐述。\n\n ## 金融业数据库选型背景\n\n随着企业数字化转型深入，对于数据使用场景也呈现多元化趋势，正有越来越多数据被企业利用起来。金融行业作为数据库应用“高地”，这一趋势表现更为明显。同时我们也看到，近些年来数据库领域也发展迅速，有分布式数据库、多模数据库、云数据库为代表的产品不断涌现。这些新兴数据库在特定场景有很好的使用前景。基于上面两种趋势，金融行业很多企业都在面临选择数据库的问题。\n\n### 选型技术层面要素分析\n\n从技术角度来看，在数据库选型中有哪些要素需要考虑呢？下面以近期比较关注的分布式数据库的选型为例，说明下重点考量的技术要素。\n\n**分布式事务**\n\n分布式架构，自然会带来分布式事务的问题。由于需要跨节点的网络交互，因此较单机事务会有很多损耗。随之带来的是事务处理时间较长、事务期间的锁持有时间也会增加，数据库的并发性和扩展性也会受到影响。针对单笔事务来说，分布式事务执行效率是肯定会有降低的，分布式带来的更多是整体处理能力的提升。\n\n**性能**\n\n由于分布式数据库通常使用的二阶段提交和各节点之间的网络交互会有性能损耗，分布式数据库优势不是单个简单 SQL 的性能，而是大数据量的 SQL 查询，每个节点会将过滤之后的数据集进行返回，会提升性能，并且分布式数据库的优势是并发，大量的 SQL 并发也会比单机数据库强大，应用需要做分布式架构的适配，将串行执行机制尽量都改造成并发处理。对于含有需要节点间数据流动的 SQL 语句的事务，OLTP 类的分布式数据库处理效率一般较差，事务处理时间会较长，事务期间的锁持有时间也会增加，数据库的并发性和扩展性也会受到影响。建议尽量改造存在跨节点数据流动的 SQL 语句（主要是多表关联）的事务。\n\n**数据备份**\n\n分布式数据库的一致性保证通过内部时钟机制所提供的全局时间戳，所有节点都会遵循该机制，所以备份恢复的增量也是基于全局时间戳，但是分布式数据库的备份解决方案最重要的标志为是否支持物理级的备份，物理级的备份会比逻辑的备份性能吞吐大很多，还有就是是否支持一些分布式备份方案，比如 S3 协议接口，是否支持压缩等功能。分布式数据库基本都具备备份和恢复方案，通常从备节点进行连续备份（全量+日志），恢复的时候指定节点进行恢复到指定时间点，整个过程可配置自动任务、自动执行。\n\n**高可用**\n\n分布式数据库大多都是基于多数派协议，同城双中心不适合多数派的要求，同城数据级多活建议采用三中心部署。如果同城主备可以采用集群级的异步复制，异地建议采用集群级的 binlog 异步复制，建议实例的主备节点设置在同城两个双活数据中心，仲裁节点三机房部署；异地灾备单独启实例与本地实例进行数据库间同步，也可以将本地备份文件 T+1 恢复到异地灾备。\n\n**数据一致性**\n\n分布式数据库大多都是通过获取全局时钟时间戳，采用二阶段提交，可以实现一致性的保证，分库分表架构对于事务的一致性，需要应用层考虑，比如通过合理的分区键设计来规避。部分分布式数据库对于跨节点事务目前还是实现的最终一致，对于全局一致性读，一般通过引入类似全局时间戳的组件统一管理全局事务，在数据库选型时可以重点关注厂商对这一块的实现。如果目前暂时无法提供全局一致性读的分布式数据库，对于要依赖分布式事务“中间状态”的业务，优先进行业务改造进行规避，其次通过合理的数据分片设计让其在单节点内完成。\n\n**数据分析**\n\n分布式数据库，多采用存算分离架构。针对数据分析场景，需要对数据从下层存储节点上移到计算节点，这对分布式数据库提出了更高的要求。一方面可通过算子下推等技术，减少需传输到计算节点的数量；一方面针对汇聚后的结果需要通过流式处理等方式，规避诸如 OOM 的问题；此外也可采用如 MPP 等并行处理技术，加速数据分析过程。\n\n### 选型过程问题痛点分析\n\n在选型过程中，会遇到来自以下几方面的痛点。 \n\n- 由于分布式数据库整体架构还比较新，也是近十年来逐步发展完善的。针对新型架构的诸多特点，包括厂商和用户还都在不断摸索积累之中，还需要有个长期实践的过程。此外，新架构也需要有个逐步成熟完善的过程。\n- 大量产品来自国内数据库厂商，其发展周期相对较短，还需要在产品成熟度、稳定性、周边生态等方面不断完善。对于用户来说，一方面需面临产品多、技术栈多的现状；另一方面还需面对成熟度不足等问题，存在较多痛点。\n- 近些年金融行业发展迅速，各种新的业态产品不断涌现，这些对作为底层数据基础的数据库也提出了更高的要求。\n\n## 数据库选型技术架构\n\n### 分布式路线分析\n\n针对分布式数据库的发展路线，大体可分为两种：\n\n**分布式中间件**\n\n这种架构是从中间件路线演进而来。其采用存储与计算分离架构，底层采用标准单机数据库，副本间基于数据库主从复制机制。上层承担计算，并可将部分计算下推到存储节点执行。这种架构在分布式事务、全局 MVCC 等方面，往往存在一定难点，各厂商也有各自解决之道。\n\n**原生分布式**\n\n这种架构正是受到 Google 论文影响演进而来。其采用存储与计算分离架构，底层采用单机库(不一定是关系型)，副本间采用分布式一致性协议完成复制，支持多数派提交。上层承担计算，并可将部分计算下推到存储节点执行。\n\n### 重点需求满足情况\n\n针对上述遇到的痛点，两类产品实现逻辑也所有不同：\n\n\n\n\n### 路线场景分析\n\n从数据使用场景来讲，可大致按下面进行划分：\n\n\n\n针对不同的场景，不同分布式数据库路线产品各有所长。\n- 针对事务类场景下，强调高并发联机交易、对分析能力要求不高的场景比较适合分布式中间件路线产品。\n- 针对事务类及事务/分析混合类场景，既要满足常规联机交易场景的同时，还需满足分析类的一部分能力，这种情况比较适合原生分布式产品。基于原生分布式的 HTAP 数据库，用一个数据平台应对规模化交易和实时分析，提升业务决策的时效性，降低数据技术栈的复杂性，越来越多的混合负载需求推动了 HTAP 在金融场景的落地。\n\n## 金融业 HTAP 应用场景实践\n\n### 金融场景下 HTAP 的分析\n\n在金融企业数字化转型的过程中，各类业务对“海量、实时、在线”的数据需求变得愈发迫切。在金融企业运营场景中，实时推荐、精准营销是企业提升竞争力的一大因素。在企业风险控制场景中，实时风控、反欺诈等业务开展可以更早地识别和阻断风险可以让企业减少损失，HTAP 正是基于上述背景诞生出的需求，为各类实时数据处理需求提供了解决方案。\n\n### 某金融用户 HTAP 的架构设计和实践\n\n随着金融市场同业业务的蓬勃发展，业务部门对于交易数据的实时统计分析和展现有了急切的需求。基于大数据技术栈的 T+1 报表模式，已无法满足业务部门通过实时分析交易发生情况来防范风险以及提供决策的需求，迫切的需要找到一种能让数据实时变现的解决方案。结合金融行业特点，在技术选型过程中，重点考察待选产品如下能力：包括承载业务复杂查询处理、海量数据容量存储、应用透明无侵入、开发协议可适配及混合负载下的表现等。经过测试，选择 TiDB 作为基础数据库平台。基于其 HTAP 的特性，打造金融市场实时数据平台，目前已投产了灵活报表和交易对手分析等应用场景。整个处理流程包括： \n\n- Flink 消费交易系统产生的实时增量数据，对部分事实表进行拉宽处理并写入 TiDB\n- 维表和其他明细表直接写入 TiDB\n- BI 工具直接连接 TiDB，提供秒级的实时计算和分析能力\n\n\n\n这一案例中，构建千万及以上数据规模、超过五张表的复杂关联实时查询能力，让业务人员在极短的时间内（大部分报表执行时间为几十到几百毫秒、个别报表秒级别）获得实时交易的详情。\n\n### 未来 HTAP 的场景发展\n\n实时数据处理技术还以某些具体的应用场景为主，从现状来看以事件驱动类、流式管道数据计算类为代表的场景，已经开始使用 HTAP 场景的。未来随着 HTAP 计算能力进一步的提升，实时全量数据的计算将带来更多场景。\n\n## 面向未来的架构趋势\n\n### 云原生\n\n从未来的发展趋势来看，云方向是一个大的趋势。\n\n\n\n从上图可见，云数据库的发展经历了几个阶段，从云托管、云服务、云原生之路。 \n\n- **云托管**，是最接近传统数据库系统的部署模式。本质是将原本部署于 IDC 机房内物理服务器上的传统数据库软件部署在了云主机上。这种模式下，云平台提供诸如高可用、异地灾备、备份恢复、数据安全、SQL 审计、性能优化和状态监测等企业级数据库管理能力，用户可减少运维投入即可享受之前同等的服务水平。\n- **云服务**，之前的托管架构中，受限于传统数据库架构的局限，未能完全发挥云计算的优势。在诸如弹性扩展、高性能、高可用等方面，均有不足。到了云服务时代，充分利用云基础设施的底层能力，提供定制化的数据库产品。\n- **云原生**，与之前的云服务架构不同，这一阶段产品将更为充分地利用云基础设施的能力，通过多层资源解耦，可享受云带来的弹性扩展、按需供给、超大规模能力。真正做到了数据库与云的深度结合。从长期来看，金融机构逐渐把业务和技术向云原生演进，实现传统应用迁移上云和云原生改造是重要的方向。在这个过程中需要考虑分布式数据库对 K8s、微服务应用的支持，提供高效、弹性调度能力，同时需要兼顾开发运维和敏捷度。\n\n### 多云方向\n\n云作为未来主流的资源供给方式，多云必然是企业不得不考虑的问题。多云通常指金融机构同时采用多种不同的云环境组合来满足业务需求的多样性和金融业监管的要求。如何围绕数据打造面向未来的多云 IT 架构，满足在多云之间提供数据服务能力，摆脱单一供应商的弊端，是必须考虑的问题。多云架构对分布式数据库的考察重点聚焦于跨地域、跨公有私有云、跨本地 IDC 和 K8S 的部署、服务提供与统一运维能力等。","author":"韩锋","category":5,"customUrl":"distributed-database-selection-and-htap-practice-in-financial-industry","fillInMethod":"writeDirectly","id":388,"summary":"本文转载自公众号：韩锋频道（hanfeng_channel）。文章从金融用户角度入手，对如何选择分布式数据库及选型后的最优实践进行了阐述。","tags":["分布式数据库","HTAP","TiDB"],"title":"金融业分布式数据库选型及 HTAP 场景实践"}},{"relatedBlog":{"body":"> **作者介绍** \n**陈培新**，参与国信证券基础平台研发工作（DevOps、微服务治理、Serverless）\n\n\n国信证券是一家全国性大型综合类证券公司，在 118 个城市和地区共设有 57 家分公司、185 家营业部，根据中证协发布的数据，近年来国信证券的总资产、净资产、净资本、营业收入、净利润等核心指标排名行业前列。\n\n国信证券从 2020 年 6 月开始接触 TiDB，从技术预研到第一个业务上线大约花了半年时间。第一个上线的业务是金太阳帐单，后面陆续在数据中台、服务观测等系统中应用。从只在东莞主机房的 TiDB 部署到 2021 年 9 月实现 TiDB 多机房的部署，并启动国产海光 x86 服务器的试点工作，国信证券在开源 NewSQL 数据库的探索和应用层面，积累了丰富的实践经验。目前，**国信证券共有 7 个 TiDB 集群，节点数量 109 个，最大表 100 亿，支撑了托管、经纪和自营等业务**。\n\n## 从 0 到 1，国信金太阳引入 TiDB\n\n身处互联网企业，大家可能跟富途牛牛接触的比较多。国信金太阳跟富途牛牛类似，它提供证券交易、理财和咨询相关的服务。我们使用证券软件最主要的功能就是交易，用户在做交易的时候，关注更多的是收益率以及什么时候去买卖股票，用户可以根据证券软件提供的功能对所有的交易做分析。国信金太阳的用户数大概有一千万左右，国信有一个大数据平台，存储了所有用户历年的交易数据，账单存量数据有一百多亿，清仓股票数据量大概是十亿，整个帐单和清仓股票增量数据大概是二十亿每年。\n\n下图是国信金太阳的数据服务架构。金太阳 App 直接连金太阳后端，后端架构基于国信自研的 gRPC 微服务框架构建。跟大多数券商系统一样，金太阳后端对接柜台系统，里面有交易、帐户、清算等各种后台应用。所有数据最后会推送到数据中心，数据中心每天或每周都会做跑批。跑批完之后，会将相关的数据推送到前端的数据库中，用户通过 App 端的查询服务来直接查询这个数据库，从而获取相关的帐单以及清仓股票的数据。\n\n\n\n图：国信金太阳数据服务架构\n\n整个账单经历了三个版本，账单 1.0 我们可以称它为**刀耕火种**的时代。在 1.0 版本的时候，只支持一年账单的查询，使用的是单库单表 SQL Server。具体是怎么实现的？首先，数据中心每天会将数据同步到一张临时表中，然后进行数据转换的服务，这个临时表的数据会加到正式表里面，正式表里面保存的是一年的数据量。在单库单表的情况下，通过一个中间程序将所有一年的数据都压缩到某一列里面去，里面是一个 JSON 字符串，存的是一年 365 天的数据。那如果新一天有新数据来了怎么办？这边会起一个临时任务，将新的一天推过来的数据压入到这个 JSON 里面去，再倒推 365 天，把以前最早那天的数据清除，最后再写到正式表里面去。可以看到，这其实是一个非常原始的实现。为什么要使用 JSON 这种格式？因为我们的数据用户量大概有一千多万，如果是每天存一行的话，用单库单表肯定是 hold 不住的。所以一开始，我们用了一个非常取巧的方式，将 360 多行给它并了一行，这样的话整个表的数据量将近有一千多万，查询效率还可以。\n\n\n\n图：账单 1.0 单库单表实现方式\n\n这种方式面临的问题是：业务上，用户是希望查询更长时间的数据，比如五年，使用单表的话，这一项其实是难以满足的。技术上，数据查询以及后续的更新压力大，难以扩展，有时候会出现数据更新出错，第二天用户来查询的时候，查到的数据就不准确了。\n\n为了应对这些业务和技术难点，国信在账单 2.0 版本使用 sharding-jdbc 来做分库分表。在引入这个技术的时候，我们也听说了 TiDB，考虑到**证券业务对稳定性要求较高**，当时对 TiDB 稳定性还有一定的担忧，所以选择了 sharding-jdbc。做了分库分表之后，可以支持 5 年帐单的查询，使用了 16 台 MySQL，总共分了 512 张表。数据中心与分库分表是如何进行同步的？数据中心还是和以前每天一样，先把数据写到临时表，转换服务会配置分库分表的规则，从临时表里面取数据，最后写到正式表里面。数据中心有个 ETL 工具，它不支持扩展，所以就没有直接写入到正式表。\n\n\n\n图：账单 2.0 分库分表实现方式\n\n大概跑了两年时间，我们发现了新问题，分库分表虽然可以满足业务需求，但后续在扩展性方面有很大的约束，这些约束包括：第一，字段扩展困难，我们分了 512 张表，如果要有新业务上来，需要新增一个字段，这个时候 DBA 就会很痛苦，需要到每个分表新增字段。第二，扩容极其麻烦，数据一开始预估不准确的话，后面分库分表的规则就一定要变，从一开始 512 张表要变到再乘以 2，变到一千多张表，DBA 迁移的工作非常繁杂，而且很容易出错。第三，同步还需要中间表，所以数据同步的时间也还是一样的慢，并且制约系统上线时间。第四，分表的定时创建跟清理也比较繁琐，每天会将一些日表删掉，比如五年前的表，然后还要去创建第二天的表，在开发的时候，始终是要使用这个定时器来做清理和创建。第五，运维方面，也要运维多个数据库。\n\n到了账单 3.0 的时候，公司的开发和运维方提出了需求，分库分表虽然可以搞定，但是太麻烦了。借这个机会，我们把 TiDB 引入到国信证券里面来，使用 NewSQL 数据库来支持 5 年账单查询。数据中心就直接将数据每天直接推到正式表里面，查询服务方面就是直接去查询 TiDB，在 TiDB 之上加了缓存，**每天同步入库的效率较以前提升了大概 70% 左右**。当前 TiDB 已经在国信三地机房里面做了部署，同时在东莞机房最近也在做国产海光 x86 服务器的试点。\n\n\n\n图：账单 3.0 TiDB 分布式数据库实现方式\n\n接下来谈谈一年多来 TiDB 相关的使用心得。从开发角度来看，首先是大数据量删除，一开始没有经验，还是按照以前老的套路，比如要删除指定某一天的数据，直接就是 DELETE SQL WHERE = “某一天”，当时是周六，运维告警显示 TiDB 有很多台机器逐个地挂掉，后来找排查发现 DELETE SQL 太大了，后续把事务大小调到 10 G，扩展 TiDB 机器内存到 64 G，这部分是满足系统层面的扩展。另外一方面是在应用程序侧做改造，需要去做分批的删除，可考虑使用 Range 分区表，删除数据直接 truncate 或 drop 分区即可。\n\n第二个经验是对新上 TiDB 的业务，尽量要使用 AUTO-RANDOM 作为主键，对那种持续插入、大量插入，很大情况下可以避免插入的热点。对于多机房数据同步，TiDB 是需要主键或者唯一索引，无主键或者唯一索引会造成同步 OOM。在表已有大量数据的时候，如果要加这个主键，整个过程也会比较麻烦。\n\n## 三地高可用容灾架构的实现\n\n一开始只在国信东莞主机房作为试点去做 TiDB 的部署，后续运维要求 TiDB 要做容灾部署相关的工作，应用要实现三地的高可用多活。之前每个机房的应用是访问自己本地的 TiDB ，每个季度会做灾备演练，验证东莞整个主机房故障之后，异地上海与同城福田灾备的可用性。\n\nPingCAP 的老师一开始给了三个方案。第一个方案是最简单直白的，在**三个机房都部署一套单独的 TiDB 集群**。东莞机房做读写，用 TiCDC 或者 binlog 将对应的数据同步到其他两个机房的灾备集群。这个方案的优点是比较简单，做灾备演练的时候，如果东莞主机房挂了，其他两个机房的应用基本上不用做什么操作，还是可以继续使用。这个方案存在问题是副本数比较大，需要有 9 个副本，同步的时延可能也会大一点。\n\n第二个方案是比较经典的**两地三中心**，这个方案对于网络的要求比较高，而且如果东莞机房挂了，福田机房要做一下手动恢复。第三个是**同城双中心**，把东莞跟福田当成一个集群，将数据同步到上海灾备集群，也就是两个集群。但这个方案在做灾备演练的时候做恢复也会比较复杂。\n\n\n\n图：多机房方案对比\n\n经过三个方案的对比，最后国信还是采用了最简单的 binlog 同步方案，每个机房部署一个 TiDB 集群，这也是根据业务特点来实现的。国信的业务基本上使用查询，不会存在多个机房同时写入，所以最后采用了这个最简单的方法。在多机房部署实现的过程中做了一些迁移导入的工作：一开始只有东莞机房，因为对于 TiDB 的使用不熟悉，有一些业务表是没有加主键或者没有唯一索引。福田机房搭建新的 TiDB 集群之后，我们发现在做两地集群同步的时候，同步器就直接 OOM 了，是因为没有加主键或唯一索引导致的。当时有一张最大的表已经到 60 多亿了，如果直接在表上加主键或者唯一索引的话其实是不可能的。\n\n那我们是怎么做到的呢？首先使用 Dumpling 将这个表导出到 CSV 文件，这个 CSV 文件的命名是带有表的名称的，在导出完成之后在原来的数据库上面去创建新表，里面加上主键或者唯一索引，再把导出的这两个 CSV 文件重命名跟新表一样，然后通过 Lightning 把数据导入到这个新的表里面，最后把旧表和新表给重命名，把这张新的表命名为正式表，正式表重命名为备份表，这样做的话可以尽量的减少对业务的影响，在导入导出的过程中，用户基本上是无感的。\n\n\n\n图：无主键表处理\n\n## 服务可观察的探索\n\n最后谈谈在金太阳**服务可观察方面**的探索。应用在使用了微服务架构之后，部署的节点会非常多，而且调用链整个过程也非常复杂，这个时候想定位一个问题就会很复杂，根据业界当前比较流行的 “服务可观察” 概念我们做了一个应用来辅助开发的问题定位。这个 “服务可观察应用” 主要是包含三个部分，一个是日志，第二个是指标，最后一个是跟踪链。我们针对日志部分做了增强，把系统的请求和响应日志通过 ETL 工具转换到 TiDB 里面，然后做了可视化相关的工作。\n\n\n\n图：金太阳服务的可观测性\n\n**可视化**部分是开发一直提的需求，采集了日志一般都是在 ELK 的 Kibana 里面看，都是一些文本，这是非常不直观的。我们做的优化是对于每个微服务的请求跟响应日志我们都导入到 TiDB 里面，用 “服务可观察” 应用去做展示。如果客户有什么问题，输入客户的手机号就可以很直观地看出这个客户在某个时间段做了什么操作，从而可以很快定位问题，同时我们也将内容和响应进行可视化，看起来更加方便。 \n\n当时在做 TiDB 入库也遇到一些问题，因为这个业务特点跟账单不一样，账单基本上都是每天晚上做插入，白天用户做查询操作。并且该业务在开市期间（上午九点到下午三点多）会做持续大量的插入，查询操作会比较小，有问题的时候才上去做查询。这是一个运维相关系统，所以没有用很好的磁盘，系统上线后就发现整个 TiDB 变得非常卡，一开始以为是插入的程序或者查询程序有问题，我们做了很多优化，发现还是不行，最后升级完磁盘之后发现整个性能获得了直接的提升。我们得到的经验就是上 TiDB 的话，一定要选择好的磁盘，这样才能确保处理效率。","author":"陈培新","category":4,"customUrl":"tidb-in-guosen-securities","fillInMethod":"writeDirectly","id":335,"summary":"本文讲述了 TiDB 在国信证券海量数据高并发场景中的实践。国信证券从 2020 年 6 月开始接触 TiDB，从技术预研到第一个业务上线大约花了半年时间。第一个上线的业务是金太阳帐单，后面陆续在数据中台、服务观测等系统中应用。","tags":["用户实践","高并发","服务可观察"],"title":"TiDB 在国信证券海量数据高并发场景中的实践"}},{"relatedBlog":{"body":"本文根据 PingCAP DevCon 2021 上来自微众银行资深数据库架构师黄蔚的分享整理而成，主要阐述 TiDB 在微众银行的应用实践，包括微众银行选择 TiDB 的背景和 TiDB 的部署架构，以及 **TiDB 在贷款核心批量场景的应用**，最后分享了**基于 TiDB 优化方案的最佳实践和未来规划。**\n\n## TiDB 的产品优势\n\n从 2018 年底微众银行开始接触 TiDB 的团队，到 2019 年上线，TiDB 在数据库的选型之中展现了很多独有的优势。\n\nTiDB 兼容 MySQL 协议，同时也兼容 MySQL 的生态工具，比如备份、恢复、监控等等，不管是应用本身还是运维或是开发人员，从 MySQL 迁移到 TiDB，其成本和门槛都较低。对于 TiDB 原生的计算、存储分离的架构，用户将不必担心容量或者单机性能的瓶颈，某种程度可以把 TiDB 当作一个很大的 MySQL 来使用。同时 TiDB 的数据多副本强一致的特性对金融场景来说十分重要，TiDB 还天然支持多 IDC 的部署架构，可以支持应用做到同城多活的部署架构。此外，TiDB 开源社区的运营也非常活跃，比如在 AskTUG 平台可以看到很多用户的典型问题的处理方法，包含大量的宝贵经验可以借鉴，可以进一步降低用户使用 TiDB 的门槛。\n\n现在使用 TiDB 的用户越来越多，不管是互联网头部厂商或者金融行业用户都在大量使用，这也是 TiDB 产品越来越成熟的体现，也给更多用户使用 TiDB 带来了更强的信心。\n\n## TiDB 在微众银行的部署架构\n\nTiDB 的特性是否能够满足金融机构高可用的架构需求？\n\n这是 TiDB 在微众银行的部署架构，如图所示，首先 TiKV 选择三副本，分别部署在同城的三个数据中心，这样可以实现 IDC 级别的高可用，同时在每个 IDC 部署了一套 TiDB Server，通过绑定到负载均衡器提供 VIP 服务，这样使得应用可以做到多活接入的模式。这套架构也经受过 IDC 级别的真实故障的演练验证，将其中一个 IDC 的网络全部断掉，观察到集群可以快速恢复，我们认为 **TiDB 能够符合金融场景高可用的要求。**\n\n\n\n## 核心批量核算场景\n\n**贷款核心批量核算**是金融行业比较经典且非常重要的场景，我们将其接入到了 TiDB。下图是之前微众银行贷款核心批量应用场景的架构，左边这部分有很多业务单元，相当于把用户的数据做了单元化拆分，每一个单元化数据可能不一样，但架构和部署模型是一样的，底层用的是单实例数据库，同时批量是在每一个单实例数据库上面运行，最终把批量结果 ETL 到大数据平台给下游使用，那么这个架构有哪些瓶颈或者优化点呢？\n\n\n\n它是一个**纯批量**的应用，意味着有大量的批量的写入、更新以及运算，而且数据量都特别大，亿级或者十亿级别以上，随着业务快速开展，借据数、用户数和流水数据也在持续增涨，如果使用单机数据库来承载，首先受限于单机数据库的性能上限，跑批耗时会越来越长，而且之前单机数据库负载已经很高，IO、CPU 已经达到 70% ~ 80%，如果想提升跑批效率，应用通过增加并发的方式是有风险的，因为数据库负载太高可能造成主备复制延迟或者遇到故障无法进行快速主备切换，所以效率很难提升；其次单机数据库对这种亿级或者十亿级的表加字段或者数据管理难度非常大，虽然微众银行日常会用 online DDL 工具比如 pt-online-schema-change 来做表变更操作，但也会有小概率锁表风险。另外基于资源利用率考虑，批量系统和联机系统复用了同一套单机数据库，所以如果批量任务造成高负载，很可能会影响联机交易。基于这些背景问题，微众银行借助 TiDB 做了架构优化的升级。\n\n升级改造后的架构如下图所示，可以看到微众银行把各个业务单元的数据通过 DM 工具把数据实时同步和汇总到 TiDB，然后批量 APP 直接基于 TiDB 做批量计算，再把结果传到大数据平台，相当于借助了 TiDB 的水平扩展性来达到批量效率的水平扩展。之前是传统的 MySQL 主备架构，会要求 APP 服务器 要跟 MySQL 的主节点是部署在同一个 IDC，而如果是跨机房访问，网络延时会比较大进而影响批量耗时，所以其他 IDC 的 APP服务器 就处于 standby 的状态，会有一定的资源浪费，而 TiDB 架构的所有 TiKV 节点可以同时读写，所以**可以多个 IDC 同时启动批量任务，最大化资源利用率。**\n\n\n\n## 价值收益\n\nTiDB 在微众银行贷款核心业务场景中的使用，总结有三个主要的价值收益：\n\n**1.批量效率的提高**。下图左边是微众银行其中一个贷款业务的账单日的批量耗时对比，可以看到在单实例架构下面，批量大概是跑三个多小时，而微众银行通过借助 TiDB 进行架构的升级优化后，耗时减少到了 50 分钟左右，有绝对效率上的提升。\n\n\n\n**2.线性水平扩展**。微众银行的需求不仅仅是效率提升，而且要求其做到水平扩展，也就是弹性伸缩。因为随着业务发展，借据量包括用户量在持续增长，如果存在热点或者其他瓶颈，以后想继续提升将十分困难，下图右边是展示其批量耗时的对比情况，在初始的一个资源情况下大概跑 25 分钟，如果数据量翻倍，耗时增加到 50 分钟，如果想把这个耗时降下来再把资源也翻倍，可以发现耗时又降回到 26 分钟左右，可见已经具备线性扩展能力。所以除了效率上的提升，线性扩展能力的一大好处就是随着业务持续的发展，借据数、借据量都在快速增长，这套架构将无需担心业务快速增长可能出现的技术瓶颈，业务可以更加聚焦于产品本身，这是 TiDB 带来的一个实实在在的业务价值。\n\n\n\n**3.批量系统与联机交易系统分离**。前面提到跟联机系统是因为资源的考虑做了一个复用，现在拆分之后实际上跟联机就已经完全剥离了，并且没有像单机数据库的主备复制延迟，可以最大化资源利用率来提升批量效率。\n\n## 基于 TiDB 的优化\n\n以上这些收益可以看到比较明显的效果，那么微众银行做了哪些优化或者遇到了哪些问题呢？\n\n1. **SQL 模式优化**。TiDB 因为本身分布式架构其单条请求时延会相对比 MySQL 更高，所以需要去把一些跟数据库频繁交互的请求进行打包，尽量减少交互，比如把多个 select 改成 in 的方式，把 insert 多条改成 insert 单条多 values 的方式，把多个 update 改成 replace 多条 values 的方式。此外，因为把多个单元化的数据全部汇总到一个 TiDB 集群，那么它的单表数据量一定非常非常大，如果跑了一个比较低效的 SQL，很容易把这个集群搞垮，比如存在着 OOM 的风险，所以需要特别注意 SQL 的审核和调优。再比如早期版本会出现执行计划不准确的问题，在 4.0 版本支持 SQL 执行计划绑定，可以对一些高频的 SQL 进行绑定，使其运行更加稳定。因为微众银行接入 TiDB 比较早期，所以主要使用的是乐观锁模式，应用也做了很多适配，目前适配乐观锁模式的代码已经固化为一个通用模块，新系统接入时直接拿来用就可以了。\n\n2. **热点与应用并发优化**。使用 TiDB 比较多的用户可能会对热点这个问题比较熟悉，前面提到弹性伸缩，而要做弹性伸缩，数据必须足够离散，所以微众银行在前期接入 TiDB 的时候也发现像在 MySQL 上的 Auto Increment 特性，可能会存在热点问题，还比如像用户的卡号、借据号也可能是一些连续的数字，所以微众银行针对这两块做了一些调整或优化，比如把它改成 Auto Random，然后把一些卡号，根据它的数据分布规律，通过算法提前把这些数据的分布区间算出来，再通过 Split Region 打散功能进行预打散，这样大批量瞬时写入时就可以充分利用每一个节点的性能；另外也对低频修改、高频访问的小表进行了应用内的缓存处理，缓解热点读问题。除了数据需要足够离散，应用同样也要做分布式改造优化，因为应用是分布式的，所以需要一个 App Master 节点来做数据分片的工作，然后把分片任务均匀分摊到每一个 App 上做运算，运行期间还需要监测每个分片任务的状态和进度；最终通过数据和应用的协同优化，达到整体具备的水平扩展能力。\n\n3. **数据同步与数据校验优化**。这就是前面提到微众银行通过 DM 工具把各个业务单元的数据汇总起来，早期使用的 DM 1.0 版本不具备高可用特性，这在金融场景下是比较致命的。而在 DM 2.0 版本上包括高可用性，兼容灰度 DDL，易用性等等几个特性都已稳定上线。此外是数据校验部分，因为是核心批量场景，数据同步必须做到数据不丢、不错，所以应用也内嵌了数据 checksum 的逻辑，比如在 MySQL 入库时先对数据进行分片，然后把各个分片的 checksum 值写到表里面，再通过 DM 同步到下游 TiDB，最后应用在跑批期间从 TiDB 把各个分片加载出来，然后再跑一遍对应分片的 checksum，再对上下游的 checksum 值进行比对，通过这样的校验机制以确保数据的一致性。\n\n4. **故障演练与兜底预案优化**。这个系统之前是基于 MySQL 的批量系统，迁到 TiDB 后有一些故障场景表现可能会出现非预期的现象，所以微众银行做了大量故障演练，第一是模拟各个 TiDB 组件节点异常，确保应用可以兼容，同时当出现批量中断后，应用也支持断点续跑；第二是整批次重跑，由于可能会遇到程序 bug 或者非预期问题导致整个批次需要重跑，为了快速恢复重跑现场，应用开发了快速备份和 rename 闪回的功能; 第三是针对极端场景的演练，比如假设 TiDB 库出现了整体不可用，微众银行结合 Dumpling 和 Lightning 进行了整集群的快速备份和恢复，难点包括 DM 同步的还原点快速确认、大表人工预打散等等，最后验证的结果符合正确性和时效性的要求。因为这个架构涉及到较多数据流转，所以针对故障场景做了大量的演练以及对应预案 SOP 的编写。\n\n## 未来规划\n\n微众银行从 2018 年开始调研及 POC，2019 年上线了第一个 TiDB 的应用，当前 TiDB 在微众银行的应用领域已覆盖了贷款、同业、科技管理、基础科技等等，当前还有多个核心业务场景在做 POC 测试。针对未来的规划有五个方面：\n\n1. **TiDB 的云原生 + 容器化**。可以带来比如自动化运维能力的提升、资源调配的能力等等。\n2. **基于 Redis + TiKV 的持久化方案**。主要是替换 Redis + MySQL 的兜底方案，借助 TiKV 天然的高可用特性来做持久化的方案。\n3. **基于 SAS 盘低成本应用**。微众银行在行内有很多归档场景，数据量特别大，因为受监管要求需要保留很长时间，针对这种存储容量要求高但低频访问的场景，TiDB 基于 SAS 盘低成本的方向也会做一些试点。\n4. **国产化 ARM 平台的 TiDB 应用**。去年微众银行已经有业务上了 TiDB ARM，未来随着国产化的趋势，这块将会被继续加大投入力度。\n5. **TiFlash 的评估与应用**。TiFlash 提供的是 HTAP 的能力，尤其像实时风控以及轻量 AP 查询的场景会带来很大帮助，这也是微众银行未来的重点规划方向。\n\n> 视频：TiDB 在微众银行核心批量场景的实践 \n\n\n","author":"黄蔚","category":4,"customUrl":"devcon-2021-webank","fillInMethod":"writeDirectly","id":306,"summary":"本文根据 PingCAP DevCon 2021 上来自微众银行资深数据库架构师黄蔚的分享整理而成，主要阐述 TiDB 在微众银行的应用实践，包括微众银行选择 TiDB 的背景和 TiDB 的部署架构，以及 TiDB 在贷款核心批量场景的应用，最后分享了基于 TiDB 优化方案的最佳实践和未来规划。","tags":["DevCon","核心批量核算"],"title":"TiDB 在微众银行核心批量场景的实践"}}]}}},
"staticQueryHashes": ["1327623483","1820662718","3081853212","3430003955","3649515864","4265596160","63159454"]}