{
    "componentChunkName": "component---src-templates-blog-blog-detail-tsx",
    "path": "/blog/tidb-won-the-bid-of-hangzhou-bank-core-system-database",
    "result": {"pageContext":{"blog":{"id":"Blogs_453","title":"TiDB 中标杭州银行核心系统数据库项目","tags":["TiDB"],"category":{"name":"公司动态"},"summary":"近日，平凯星辰 TiDB 分布式数据库成功中标杭州银行核心系统数据库项目。平凯星辰凭借前瞻的产品技术方案、金融领域的经验积累、专业快速的服务保障及高度活跃的开源社区，在竞争中脱颖而出。此次中标再次印证了 TiDB 新一代分布式数据库在银行核心系统建设、确保业务连续性以及支持业务敏捷高效创新等方面具备关键的服务能力。","body":"**近日，平凯星辰 TiDB 分布式数据库成功中标杭州银行核心系统数据库项目**。平凯星辰凭借前瞻的产品技术方案、金融领域的经验积累、专业快速的服务保障及高度活跃的开源社区，在竞争中脱颖而出。此次中标再次印证了 TiDB 新一代分布式数据库在银行核心系统建设、确保业务连续性以及支持业务敏捷高效创新等方面具备关键的服务能力。\n\n![1.png](https://img1.www.pingcap.com/prod/1_1ce4ab0524.png)\n\n核心系统是银行交易和账户处理的中心，是银行信息系统的基础和核心，被誉为银行的“心脏”。在数字经济的发展和新技术崛起的背景下，杭州银行**坚持自主研发、自主创新的系统建设思路，利用云原生、微服务等技术重构杭州银行技术架构和能力体系**，打造满足未来业务发展的新一代全栈式自主可控的分布式技术平台，构建稳定高效和灵活敏捷兼备的核心系统。\n\n分布式数据库是核心系统技术平台的关键组成部分，杭州银行 2019 年启动国产分布式数据库领域的前沿技术研究，有计划、分步骤地推进分布式数据库在业务场景的落地。围绕银行核心业务系统：数**据量大、交易数据变更频繁，交易热点集中；多渠道接入、交易并发量大；数据重要性高、安全等级要求高；系统可用性、可靠性高等特点**；在本次新一代分布式核心系统数据库的选型上，秉持“SAPE”原则（即 Safe 高安全、Availability 高可用、Performance 高性能和 Ecology 多生态）；坚持参照金融行业分布式数据库应用相关规范，结合杭州银行业务发展和新一代分布式核心系统整体架构的思路，开展适配新一代分布式核心系统的金融级分布式数据库选型工作。\n\n在本次核心系统数据库选型过程中，杭州银行组织多方，共建“风洞实验室”从软件开发、建设部署、数据迁移、业务交易、运维监控和容灾切换等多个维度，共同设计产品测试场景和用例，对 TiDB 进行了全面详尽的测试验证。测试结果表明，**TiDB 在开发易用性、混沌故障注入稳定性测试、多中心多活、性能横向扩展、HTAP 特性上具有显著的先进性**。从开放性上看，TiDB 在技术社区的活跃度、开发平台适配方面具备较明显的优势，拥有高度开放的数据技术生态。\n\n**基于前期选型成果和互联网核心的成功实践，杭州银行在新一代分布式核心系统中选择 TiDB 用于数据底座。**\n\nTiDB 历经全球 3000 多家行业用户海量数据的严苛场景打磨，稳定可靠，具备金融关键核心业务的支撑能力。TiDB 分布式数据库成功应用于中国银行、建信金科、浦发银行、北京银行、浙商银行、中国人寿、平安科技、微众银行等多家金融企业的联机交易、在线支付、信贷管理、实时风控等场景，帮助金融机构将核心的业务及数据能力下沉和拓展到更多场景，加速数字化转型与升级。","date":"2023-01-10","author":"PingCAP","fillInMethod":"writeDirectly","customUrl":"tidb-won-the-bid-of-hangzhou-bank-core-system-database","file":null,"relatedBlogs":[{"relatedBlog":{"body":">作者简介：余军，PingCAP 解决方案事业部总经理。\n\n对于金融企业来说，尤其是银行、证券、保险这些行业，在一个 IT 系统运行支撑业务的过程当中，考虑到硬件的故障、网络的故障，等一切可能会对业务产生影响的突发故障。那么，在过去漫长的 IT 发展的过程当中，大量的技术被应用在关于如何解决组件级的高可用，整个服务的容灾和灾备，包括如何保证整体业务的连续性。\n\n在金融行业来说，数据库作为最核心的基础组件之一，要求它能够安全运行和保障数据安全，这是一个刚需。另外，数据库服务本身的高可用，是我们实现整个对外数据服务连续性的最重要的基石。在这些基础上，光有高可用还是不够的，我们需要考虑到机房级的、数据中心级的、站点级的灾难导致的对业务的影响。配套的容灾技术，以及对应事件的方案，应运而生。在过去的二、三十年里面，关于容灾和技术的技术手段、软件工具，包括各种各样的方案、管理方法，在不断的展现。\n\n## 传统数据库支撑关键计算的高可用/容灾方案短板\n\n回到传统的数据库领域，在过去至少三四十年的时间里，我们都是在使用集中式的数据库，比如大家非常熟悉的 Oracle、DB2 包括曾经很辉煌的 Sybase、Informix 等等。这些数据库都是以大家所熟知的“ IOE”的架构来实现数据服务的。\n\n在这些技术体系下，在长期的技术发展过程当中，也有产生对应的高可用和容灾的方案，比如说大家非常熟悉的 Oracle RAC，比如说我们在 DB2 上，经常会用到的 HACMP，还有曾经大名鼎鼎的 Veritas VCS，MC/SG，以及红帽的 RHCS , Pacemaker/Corosync 等实现单机数据库高可用的。\n\n这些技术都是通过数据库，建主从的实例，然后共享数据库的数据文件，放在高端的数据的存储上。这种集中架构的话，它总体是比较稳定的，但是随着 IT 应用场景的不断发展，到今天为止，我们在考虑数据库的时候，除了要考虑它的可靠性之外，还需要考虑它如何应对海量的数据处理，海量的并发请求。**那么我们需要必须寻求扩展，而集中式的结构，它没有办法做横向扩散。此外的话，这种传统的数据库的高可用方式，非常依赖于外部的组件，就是前面说的这些独立的厂商提供的相关的高可用和容灾组件。**\n\n进入到开源数据库的阶段，大家所熟知的 MySQL 和  PostgreSQL，它们也会有对应的高可用的解决方案，比如 MySQL 它最常见的就是通过它的 Binlog 复制建立起来主从队，然后在数据库之外，我们采取类似像 MHA 这样的一个 SwitchManager 的工具，包括 PG 的话，它有 PAF、RepMgr、Ptroni 这样的技术。\n\n**在这样的技术场景中，其实在可用性和容灾方面，还是有很多的问题**，比如说复制的时候的采用的异步复制，增强的半同步复制以及国内好多互联网公司定制的 MySQL，PG 的同步方案，在多节点，跨地域容灾灾备场景中的一致性的问题，始终是一个很大的挑战。特别是在容灾的场景当中，超过 1000 公里以上的站点距离间隔，用上述复制的方式，用独立的 SwitchManager 的故障切换机制，是不是能够保证在千公里以上的容灾的可靠性是很大一个疑问。\n\n**此外，主从复制的模式资源利用率比较低**。到现在为止，我们还有在主从复制基础上，再往前走一步，提高高可用性的一些保障机制，比如说大家都熟知的组同步，像 Codership 之前做的 Galera，像包括 MariaDB Galera Cluster 和 Percona XtraDB Cluster，都把 Galera 组件放在产品当中。包括现在 MySQL 新版本中的复制技术实现了组同步 MGR。但是这些方向又有它的问题，比如说它的性能损耗非常显著，然后在多写场景的冲突的处理复杂性，以及整个集群的扩展规模，受到这样的限制。\n\n## 分布式数据库备份容灾的挑战\n\n所以，从单机数据库进入到分布式数据库的领域，问题的挑战就更加大了。集中来看的话，就是比如说我们最常见的两个传统的分布式的数据库的架构：MySQL、PG 加上主从复制核心组件，再加一个高可用的外部组件实现 Failover/Switchover，然后再加分库分表中间件。那么这样的方案，在传统的分布式架构当中，它的核心的可用性的技术限制和天花板没有变化。它还是如前文所说的：主从复制加上一个数据库外部组件实现 Failover/Switchover 。\n\n**然后，在分布式数据库架构里，我们需要非常认真的去考虑，分布式数据库的伸缩能力和它怎么样去跟高可用及容灾的要求达到平衡。甚至还要想怎么样再去做进一步的优化，这是比较困难和有挑战的。**\n\n另外，在互联网应用场景中， 访问量和数据量非常的大，业务逻辑相对简单。**但是在银行、保险、证券等这样的传统关键金融场景当中，业务的逻辑是非常复杂的。针对于这样的传统高可用及灾备容灾方案，它与应用进行适配，往往要做一些面向应用的反向适配，应用还需要为此进行调整与妥协**。比如说两地三中心的场景当中，应用适配的难度更加大，所以改造过程当中的适配过程和反向适配的风险，也是一个经常让金融行业的 IT 从业人员非常头痛的一件事情。\n\n最严峻的一个事情，当在这样的传统灾备容灾方案为基底的一套系统在运行的过程当中，真的发生了非预期的重大故障和灾难突发的时候，怎么样保证数据的严格安全，以及如何保证在故障发生以后，对于部分组件，对于机房级的灾难，对于中心级的灾难，在灾难发生的时候，要保证对业务的最小影响，也就是我们经常听到的，RPO 和 RTO 这样的要求。那么在这个过程当中，怎么样最大程度减少人工的干预？因为，**在灾难发生的时候，人的干预是必须的，但是人的反应也是比较迟钝的。所以，怎么样通过一个技术手段，在整个方案的能力上，能够去高效执行灾难恢复的处理工作？**\n\n## TiDB 的金融级备份及容灾之道\n\nTiDB 经常这么多年的积累和逐渐完善，在整个分布式数据库的容灾和灾备的领域，我们达到了金融生产级的要求。那么在整个 TiDB 的备份与灾备、容灾的体系里，我们主要是由以下几个方面来组成的。\n\n![1-TiDB-金融级备份及容灾之道](https://img1.www.pingcap.com/prod/1_Ti_DB_6ddab9cf1a.png)\n\n**第一个是我们默认的，也是我们推荐的，多中心的容灾方案，同城的两中心，异地的一中心，或者扩展到三地五中心模式**。这个方案也是 TiDB 最早原生的核心方案。通过多级标签的感知，能够实现服务器级、机架级、机房级、站点级的故障转移。能达到 RPO 等于 0，以及我们的故障影响时间小于 30 秒，也就是 RTO 小于 30 秒的一个刚性指标。\n\n这一套方案，目前我们在国内和国外，已经有了不少用户，尤其是金融行业的用户，在关键场景投产使用了。这其中也是经受过了很多的考验，比如说，同城光纤的抖动，同城到异地之间的通讯线路出现问题，以及机房里面多个节点同时出现了故障，随着在生产环境上持续运行时间的变长，这些问题都暴露出来了。通过 TiDB 的多中心的容灾方案，非常可靠地避免了这些故障对业务的影响，保障了业务连续性及数据安全。\n\n除此之外，在国内的话，从北到南，我们的运营商的线路也是非常的复杂。对于有些用户来说，从投资成本、业务的重要性、客户网络的物理条件来说，没有办法去构成同城多中心加异地的的容灾架构，他可能只能选择两中心的方案，那么在这个过程当中的话，TiDB 经过这几年对这个方面的积累，我们现在已经有了**两中心的容灾方案**，并且，在这个方案里面，我们有多种配置来适应不同的网络条件。即便是在两中心方案当中，我们也能达到 RPO 等于 0 的保护模式。当然也有一些用户的场景，他的网络线路可能延迟非常高，且用户要求有一个托底的容灾方案，同时对于数据的一致性可以有略微的放松和让步，在这个过程当中，**我们也会通过配置来为其提供异步同步的模式，来帮助其实现托底的容灾方案，最大程度保障服务的连续性和数据安全。**\n\n以上是我们交付给用户的多种金融生产级的灾备容灾的方案，它背后的支撑是由核心的 **TiDB 的 Multi Raft 的高可用机制**，以及一系列针对跨中心的调度、数据的调度管理、故障的自动转移判断等这一整套后台的保障技术机制来实现的。\n\n另外，对于数据业务来说，除了在线的热的故障转移、切换等。我们对于数据库的数据本身，也提供了完善的数据备份方案，除了全量的备份、增量、恢复时间点 (PITR ) 之外，**我们在数据的备份模式上面，也提供了包括基于日志的传统逻辑备份。并且，在去年我们也推出了 TiDB BR 工具和备份方案，直接从数据库的 TiDB 存储引擎 TiKV 层上，直接实现备份和恢复，备份与恢复非常高的效率。**\n\n但光有上述方案是不不够的，PingCAP 对于自身产品的要求是非常严格的，既然是要达到金融生产级的要求，除了要有对应的技术方案、对应的技术实现之外，必须为产品本身提供专业的分布式测试的体系和手段。每一个 TiDB 的版本，在我们的内部，都会通过极其严格及复杂的分布式数据库测试。为此，我们也专门根据混沌工程，设计开发了自己的一套测试平台，并且在最近把它开源了，这套工具叫做 [Chaos Mesh](https://pingcap.com/blog-cn/chaos-mesh/)，可以帮助用户更好的检测分布式系统的可用性和鲁棒性。\n\n在 TiDB 内部测试的整条链路上，我们有非常完善的对于可靠性和一致性和安全方面的测试保障。包括自动化故障注入，包括我们引入的 Jepsen 的一致性验证，包括我们对于一些最核心的算法，引入了 TLA+ 的验证。还有我们每天在数据中心，在我们测试环境，不停跑的自动化模拟的业务负载以及各种各样的集成测试。我们相信只要是人写出来的软件，一定是会有问题的，一定会有 Bug，不可能做到完全没有问题。**所以，在这个过程当中，需要的保障手段，除了高可用和软件架构本身设计的机制之外，先进的、完善的、强大的产品测试体系和可靠性 验证能力，也是最重要的保障手段之一。**\n\n## TiDB 灾备与容灾的核心机制\n\nTiDB 容灾的核心机制是我们的 Raft ，相信各位关注 TiDB 的朋友也通过我们的公众号、官网，包括社区里面，听到过小伙伴们提供的分享。Raft 是基于日志与状态机的一种一致性的算法。我们基于它，在 TiDB 里实现了 Multi Raft 的机制。它能够非常可靠的管理我们的数据与数据的副本，在 TiDB 里面，整个数据对我们的业务来说是自动的透明打散的，然后它会以一个一个 Region 的数据组织方式，在不同的存储节点上面进行自动存储和建立 Raft 副本。\n\n通过 Multi Raft 这样的一个机制，我们可以在不同的主机，不同的机房，不同的园区，一套数据库不同的节点上，产生它的第二、第三副本，甚至更多的副本。这个副本是动态可调的，并且我们可以保证，TiDB 上执行的所有的联机交易事务，在数据变更发生时都可以达到多数的一致，**也就是说在一个实施规划和部署正确的 TiDB 集群里面，在一个多中心的灾备容灾 TiDB 集群中，任何的主机，所在的机架、机房，乃至数据中心的失效，包括数据中心间的网络故障，通过 Multi Raft 机制以及 TiDB 的高可用调度机制，都可以完善的去保障，对我们的业务影响最小，同时，非常严格的保证了数据的绝对安全。**\n\n在 Raft 这个机制上，TiDB 的研发团队也做了大量的优化工作。比如说跨数据中心，包括跨区域的运维方式。另外，我们在 Raft 机制上面，也提供了很多的比如说新的一些增强化，像 Lazy Peer、像 Learner、像 Joint consensus 等机制的研发。\n\n## TiDB 高性能分布式备份机制\n\n刚刚我还提到一个叫 [TiDB BR](https://pingcap.com/blog-cn/cluster-data-security-backup/) 的工具，它是一个在存储层实现高性能分布式数据备份恢复的工具。所以，大家由下图可以看到，我们的测试中的备份速度、恢复速度，都是非常惊人的。而且随着节点数量的增加，在数据量一定的前提下，备份/恢复的性能都会有接近线性的增长：\n\n![2-TiDB高性能分布式备份机制](https://img1.www.pingcap.com/prod/2_Ti_DB_875ad97021.png)\n\n\n## 最强的多中心：TiDB 多中心多活容灾方案\n\n在多中心里面，前面提到，我们通过 Multi Raft 的机制，以及相关的工程优化，实现了跨中心的容灾方案。比如说，对于长距离的异地中心，我们在同城设了两个中心，通过光纤连接，异地的话，通常租用比如运营商的 MSTP 类型的线路，构成一个三中心的结构，通过 TiDB 内置的容灾和灾备的相关的一系列的机制与手段，可以构建出非常强健的容灾的架构。**任何中心级失效，都会由另外两个中心来立刻进行故障的转移，以及对外继续提供正常的数据库服务。**\n\n\n![3-TiDB多中心多活容灾方案](https://img1.www.pingcap.com/prod/3_Ti_DB_36dac4fe16.png)\n\n\n## 安全的两中心：TiDB 两中心容灾方案\n\n前面也提到，有些用户的网络，比如说一个中心在上海，一个在北京，延迟是非常大。因为高等级、低延迟线路的租用使用成本非常高。综合考虑成本及所需要保护的业务的关键性等级，不少用户会做一个权衡。部分用户最终希望核心数据库，只需要完成一个主从站点的容灾和灾备就可以了。\n\n通过 TiDB Binlog 模式能够去适配和满足对多中心网络通信成本敏感且对服务/数据防护能力略低的容灾需求的用户，我们会用两中心的 **TiDB Binlog based 方案**，它是异步同步模式，能够适配两个中心长距离间隔其网络延迟较大，比如延迟大于 30~40 毫秒的。采纳这样方案的用户对于 RPO 的要求就比较宽松了，该模式是一个异步同步，当灾难发生的时候，我们已经在 TiDB 的工程优化上尽可能通过多种机制来减少数据丢失的可能，但是从根本上来说，还是会存在一定数据丢失的情况。**该方案提供给用户低成本的保障能力，同时还提供了比较灵活的可选拓扑，比如双向的环形复制等。**\n\n也有用户希望在两中心的方案里，需要有一个强一致保障的方案。所以我们研发了两中心的 **Raft based 容灾方案**，它可以在同城或者接近同城距离的两中心环境中，且中心间网络条件比较好的情况下，实现严格的强一致同步。**这个方案可以达到 RPO 等于 0 的保障要求，也就是数据不丢失前提下的一个高等级的容灾要求。**\n\n\n![4-TiDB两中心容灾方案](https://img1.www.pingcap.com/prod/4_Ti_DB_fdf9238a38.png)\n\n## 结语\n\n最后，我们一直持续在花非常多的精力和投入，研究如何让 TiDB 变得更强，更安全，更可靠。能够达到更好的金融级的数据服务的支撑能力水平，依托于我们整个工程研发团队、 QA 测试团队，以及我们所打造和拥有的强大的测试体系、TiDB 产品的容灾灾备一系列高可用及灾备容灾机制，我们能够为银行、保险、证券等金融客户提供完善的、可靠的、放心的、金融级的分布式数据库服务。\n\n\n>本文整理自余军在 [TiDB DevCon 2020](https://pingcap.com/community-cn/devcon2020/) 上的演讲，大会相关视频回顾可以关注官方 Bilibli 账号 [TiDB_Robot](https://space.bilibili.com/86485707) 。","author":"余军","category":1,"customUrl":"tidb-financial-grade-backup-and-multi-center-disaster-recovery","fillInMethod":"writeDirectly","id":5,"summary":"依托于整个工程研发团队、QA 测试团队，以及所打造和拥有的强大的测试体系、TiDB 产品的容灾灾备一系列高可用及灾备容灾机制，我们能够为银行、保险、证券等金融客户提供完善的、可靠的、放心的、金融级的分布式数据库服务。","tags":["TiDB DevCon 2020","备份恢复","容灾机制"],"title":"TiDB 金融级备份及多中心容灾"}},{"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![001.png](https://img1.www.pingcap.com/prod/001_ce42a10ada.png)\n\n\n### 路线场景分析\n\n从数据使用场景来讲，可大致按下面进行划分：\n\n![002.png](https://img1.www.pingcap.com/prod/002_1f9a938e7e.png)\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![003.jpg](https://img1.www.pingcap.com/prod/003_a89e399f30.jpg)\n\n这一案例中，构建千万及以上数据规模、超过五张表的复杂关联实时查询能力，让业务人员在极短的时间内（大部分报表执行时间为几十到几百毫秒、个别报表秒级别）获得实时交易的详情。\n\n### 未来 HTAP 的场景发展\n\n实时数据处理技术还以某些具体的应用场景为主，从现状来看以事件驱动类、流式管道数据计算类为代表的场景，已经开始使用 HTAP 场景的。未来随着 HTAP 计算能力进一步的提升，实时全量数据的计算将带来更多场景。\n\n## 面向未来的架构趋势\n\n### 云原生\n\n从未来的发展趋势来看，云方向是一个大的趋势。\n\n![004.png](https://img1.www.pingcap.com/prod/004_be9d5cac08.png)\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 场景实践"}}]}}},
    "staticQueryHashes": ["1327623483","1820662718","3081853212","3430003955","3649515864","4265596160","63159454"]}