{
    "componentChunkName": "component---src-templates-blog-blog-detail-tsx",
    "path": "/blog/user-case-wonhigh",
    "result": {"pageContext":{"blog":{"id":"Blogs_476","title":"TiDB x 云盛海宏丨加速精细化运营，云海零售系统的架构演进","tags":["TiDB"],"category":{"name":"案例实践"},"summary":"本文介绍了云盛海宏云海零售系统所使用的数据库架构从集中式到分布式的演进历程，并根据使用的经验和体验，阐述了为什么选择 TiDB 数据库来支撑其业务，详细讲述了 TiDB 如何在实际使用中助力精细化运营。","body":"## 导读\n\n本文为云盛海宏数据库架构师徐婷的分享实录。云海零售系统是支撑着全渠道、全品类运动鞋服的零售服务平台。本文介绍了云盛海宏云海零售系统所使用的数据库架构从集中式到分布式的演进历程，并根据使用的经验和体验，阐述了为什么选择 TiDB 数据库来支撑其业务，详细讲述了 TiDB 如何在实际使用中助力精细化运营。\n\n大家好，我是徐婷，云盛海宏的数据库架构师，也是 TiDB 的深度用户，很高兴和大家分享 TiDB 在云盛海宏“云海零售系统”中的应用。云盛海宏是一家零售行业的科技公司，以科技的力量为门店和线上客户打造 360 度的优秀体验，目前服务全国近万家的线下门店和千万级别的线上会员。\n\n## 云海零售系统升级历程\n\n云海零售系统是支撑着全渠道、全品类运动鞋服的零售服务平台。在过去的十年间我们的业务系统和架构经历过多次的升级和改造，整体来看就是一个从集中式演进到分布式的过程。在 2016 年之前，各个大区自建设信息化系统，每天向总部上传业务数据，属于烟囱式的数据架构。随着移动互联网和数字经济的发展，该架构也暴露出一些问题，比如说没有办法很及时地去查看地区的汇总数据，也无法跨大区去查看全国的实时库存等。\n\n![云海零售系统升级历程.png](https://img1.www.pingcap.com/prod/_30a009ac11.png)\n\n为了解决这些问题，我们在 2016 年的时候就上线了全新的架构——云海零售系统。新架构是采用的微服务 + MySQL 的分库分表架构，并通过 Otter 将数据的实时汇聚到 Oracle，用于支撑复杂的报表查询。随着数字化零售时代的开启，汇聚库 Oracle 也遇到了一些瓶颈，例如存储无法扩展、分析时效差等问题，所以我们就引入了 TiDB 和 Oracle 一起支撑业务需求。对于未来的规划，我们希望能借助 TiDB 混合负载特性，支撑我们整个零售系统。\n\n## 使用新的架构支撑数字化业务\n\n2016 年为了支撑数字化业务，我们进行了业务流程的变革，并升级了我们的 IT 架构，上线了云海零售系统，这是当时的系统架构图。基于 MyCAT 进行分库分表和读写分离，拆分的规则复杂一点，基于每个业务系统还有大区都做了一定的拆分，这个架构的好处是将当时比较分散的数据汇聚到了一起。但这套架构也增加了实时分析的难度，做到了数据的共享，但因为数据做了拆分，如果要做一些复杂的需求，比如一些报表，比较复杂的 SQL，还有一些其他业务的时候就会增加相应的难度，一方面由于 MyCAT 对复杂 SQL 的支持有限、另外 MySQL 大表复杂查询效率也有限，所以我们通过 Otter 将数据实时汇聚到 Oracle 中，在 Oracle 上进行复杂的 SQL 查询。\n\n![新架构支撑云海零售业务.png](https://img1.www.pingcap.com/prod/_34dc631937.png)\n\n## 新架构带来的新挑战\n\n这套架构支撑了我们业务高速发展的五年，实现了很多小目标，比如实现了全国各地区、各大区的海量数据的存储，实现了数据的实时共享，也达到了业务可视化的目标。但是随着业务的扩展和需求难度的增加，慢慢地面临了一些新的挑战。由于 MyCAT 分库分表规则基于静态的策略，在日常的使用中需要大量的人工维护，如新的业务或者组织机构合并，需要新建表或者调整数据时，需要调整策略以及手动导数据。  \n\n其次业务对于 Otter 也有很高的依赖度，同步通道 100 多个，维护成本也比较大。源端进行 DDL 操作、大表 DML 操作时，有可能导致同步中断或者同步延迟，人力成本较大。最紧迫的还是在聚合库这边遇到的问题，由于数据量一直增涨，Oracle 很快就面临了单机数据库的存储容量上限问题，并且随着数据增长部分 SQL 效率越来越差。\n\n![新架构带来的新挑战.png](https://img1.www.pingcap.com/prod/_2dde99b7d1.png)\n\n## 为何选择 TiDB 分布式数据库\n\n到 2020 年的时候，我们当时已经不得不减少 Oracle 这边数据存储周期，来保障大部分查询的时效性，但同时也导致了有一部分业务需求无法实现。于是我们开始探索其他解决方案，用于解决 Oracle 聚合库这边的问题。  \n\n我们当时调研了 PG XL、Impala、TiDB 这几个方案，综合来看：TiDB 作为一个分布式关系型数据库天然具备水平扩展能力，协议上与 MySQL 兼容，并且复杂 SQL 执行效率也比较高，在解决我们问题的时候成本是最低的。另外 TiDB 文档比较齐全、社区比较活跃，我们的学习成本也比较低。经过了详细测试和业务评估，我们正式引入了 TiDB。  \n\n![云海零售系统方案对比.png](https://img1.www.pingcap.com/prod/_51c3c3e9d2.png)\n\n## 引入 TiDB 加速精细化运营\n\n下图是云海零售系统引入 TiDB 之后的新架构，使用 TiDB 去共同支撑聚合库这边的一些需求，并且将绝大部分功能迁移到 TiDB 上。TiDB 的实际使用效果超出我们的预期：TiDB 分布式架构可以灵活扩展，数据存储周期越来越长；绝大部分 SQL 从 Oracle 迁移过来时，效率都获得提升，当然也有小部分 SQL 效率退化（通过我们手动调整解决）；之前由于数据存储周期和查询时效性导致的一系列难以实现的需求，目前也可以实现了。\n\n![云海零售系统引入 TiDB 的新架构.png](https://img1.www.pingcap.com/prod/Ti_DB_8d6b0c01a1.png)\n\n## 当前 TiDB 使用情况\n\n这个是目前 TiDB 的使用规模，基本上承载了整个系统的数据，总数据量将近 15 TB，最大的业务表单表达到了 600GB。在业务的高峰期，比如上午业务比较繁忙的时候，QPS 达到 20000 以上，地区的业务报表每天最大并发差不多在 300 以上。\n\n![云海零售当前使用 TiDB 的情况.png](https://img1.www.pingcap.com/prod/Ti_DB_4b170fa30a.png)\n\n## 经验分享\n\n### 从 MySQL 到 TiDB 的压测方案\n\n我们目前正计划迁移一个业务子系统，迁移的过程中也整理了一些经验分享，供大家参考。对于一个存量系统的迁移，可以认为它是简单的也可以认为是复杂的。简单的原因是因为 TiDB 兼容 MySQL 协议，业务基本上不需要太多改造就可以在 TiDB 上跑起来；而复杂的原因恰好因为不需要太多改造，导致测试的时候可能会遗漏一些边边角角的功能测试，导致上线的时候出现隐患。  \n\n所以目前该系统的迁移，除了有开发、测试同学的人力测试外，还有数据库级别的流量测试。即将源端各个分片的慢查询日志收集起来，根据分片规则作对日志中的库表名进行相应的调整转换，然后利用 perconca-playback 工具去目标端回放，实现流量回放的目的，发现执行异常、执行效率存在差异的 SQL，并进行分析和优化。如果上游是单库的话，只要制定源端慢查询日志和目标端的数据库地址、库名等信息，就可以直接进行流量回放。  \n\n![压测方案.png](https://img1.www.pingcap.com/prod/_92dd3989be.png)\n\n### 使用中遇到的问题\n\n在使用 TiDB 的两年里面也遇到一些问题：最多的还是优化器生成的执行计划有时不准，像索引选择不准、Join 顺序选择不准、存储引擎选择不准等问题，目前我们基本都是通过在 SQL 中指定 hint 或者在计算节点上设置默认引擎来解决。统计信息也存在一些收集不及时的情况，导致优化器影响较大，目前我们也自己部署了定时收集统计信息的脚本，保障统计信息的健康度。其他的基本上就是一些排序规则和工具上使用上的小问题，影响不大。\n\n![使用中遇到的问题及解决方案.png](https://img1.www.pingcap.com/prod/_bb9cea38b3.png)\n\n### 改善建议\n\n从 2020 年的 4.0 版本开始使用 TiDB，到目前线上的 5.4.2 版本，每一次升级 TiDB 给我们带来了很多比较实用的特性和功能，像 MPP、中文字符排序、CTE、canal-json 等等，并且持续提升稳定性和性能，是一个非常有活力的产品。当前 TiDB 仍存在一些需要改善的地方：在执行计划正确的时候，TiDB 效率都比较高。但当前仍旧存在索引设计合理、统计信息准确时，执行计划还是不对的情况。而且遇到时，往往都是事后才发现并去手动处理，对业务已经产生一定影响。  \n\n此外，业务上有大量数据批处理操作，当前像 Insert Into ... Select（复杂查询）这样的 SQL 当前无法走 TiFlash，只能走 TiKV，而走 TiKV 一方面效率不佳，另外一方面走 TiKV 时消耗资源可能影响其他正常业务接口。业务上使用到的主数据，基本上都是读多写很少，一天才写 100 多条，写入基本都是从上游下发下来的，对实时性要求不那么高，反而对查询响应及吞吐性能要求很高，而当前 TiDB 缓存表无法缓存整张表数据，导致这个功能在我们这无法发挥出价值。\n\n![改善建议.png](https://img1.www.pingcap.com/prod/_9cd812848b.png)\n\n## 未来展望\n\n我也想和大家分享一些未来的规划，我们目前正计划升级 TiDB 6.1 LTS 版本，去解锁更多新特性：使用 Placement Rule in SQL，来实现冷热数据的分离以及资源的隔离；新版本 TiFlash 支持更高的并发能力以及更高的处理效率；TiKV 全新日志引擎及内存锁可以提升写入效率并降低资源消耗等等。  \n\n我们计划将 TiDB 应用到更有挑战的场景中，比如使用 TiDB 去升级分库分表的架构，支撑整个零售系统，使用 TiDB 去支撑有更多复杂需求的 Oracle 系统。  \n\n![云海零售系统未来展望.png](https://img1.www.pingcap.com/prod/_a150c5fa89.png)\n\n未来，我们计划将整个零售系统演进到单库的形态，基于 TiDB 混合负载能力，支撑整个零售系统，通过两套集群 + 两套存储引擎的方式，实现业务和资源的隔离，以下是我们未来初步规划的架构。\n\n![云海零售未来架构规划.png](https://img1.www.pingcap.com/prod/_94cf99aaf8.png)\n\n预估的收益体现在几个方面：  \n- 首先，新架构将大幅降低数据同步通道，预计可从 100 多个降低到 20 个左右；\n- 其次，之前 MyCAT 上存在大量的数据冗余，部分库表冗余度从 10 份降低到 2 份；\n- 由于数据冗余降低，再加上 TiDB 自带的压缩能力，我们预计硬件资源可降低约 50% 左右；\n- 此外，在开发和运维层面，也能大幅提升我们的效率，加速业务需求的快速落地。\n\n整体来说，TiDB 是一款非常不错的产品，对我们来说是相见恨晚的，最后感谢 PingCAP 给我们带来一款这么好用的数据库产品。","date":"2023-03-28","author":"徐婷","fillInMethod":"writeDirectly","customUrl":"user-case-wonhigh","file":null,"relatedBlogs":[{"relatedBlog":{"body":"vivo 是一个专注于智能手机领域的国际化品牌，市场不断变化，新零售热潮扑面而来。在数字化转型过程中，vivo 的基础平台架构也面临着更多的挑战。在自主研发的同时，vivo 依托包括 TiDB、TiKV 在内的众多开源项目进行迭代和设计，打造了全新的数据库与存储平台，覆盖通用存储产品运维和研发需求。\n\n本文来源于 vivo 互联网技术，根据 vivo 存储技术团队研发总监肖博在 2021 vivo 开发者大会上的分享整理而成，**从数据库与存储平台的建设背景、能力介绍、探索思考、未来展望四个角度进行了整体的介绍**。\n\n## 一、数据库与存储平台建设背景\n\n![01.jpeg](https://img1.www.pingcap.com/prod/01_9069c434b6.jpeg)\n\n以史为鉴，可以知兴替，做技术亦是如此，在介绍平台之前，我们首先回顾下 vivo 互联网业务近几年的发展历程。  \n\n我们将时间拨回到三年前，2018 年 11 月，vivo 移动互联网累计总用户突破 2.2 亿；2019 年应用商店、浏览器、视频、钱包等互联网应用日活突破千万大关；2020 年浏览器日活突破 1 亿，2021 年在网总用户（不含外销）达到 2.7 亿，数十款月活过亿的应用，数据库和存储产品也达到了 4000 + 服务器和 5 万 + 数据库实例的规模。  \n\n那三年前的数据库和存储平台是什么样呢?\n\n![02.jpeg](https://img1.www.pingcap.com/prod/02_b73e957869.jpeg)\n\n2018 年的数据库服务现状如果用一个词形容，那我觉得“**危如累卵**”最适合不过了，主要表现为以下几点：  \n\n- 数据库线上环境的可用性由于低效的 SQL、人为的误操作，基础架构的不合理，开源产品的健壮性等问题导致可用性经常受到影响。\n- 变更不规范，变更和各种运维操作的效率低下，没有平台支撑，使用命令行终端进行变更，导致数据库使用的成本极高，为了应对日益复杂的业务场景，增加了很多额外的成本。\n- 安全能力不够健全，数据分类分级、密码账号权限等缺乏规范。\n\n我们再看看这些年 vivo 数据库运营数据上的变化趋势。\n\n![03.jpeg](https://img1.www.pingcap.com/prod/03_87c3c0aeeb.jpeg)\n\n从 17 年底，18 年初开始计算，这三年时间里数据库实例的规模增加了接近 5 倍，维护的数据库服务器规模增加了 6.8 倍，数据库实例的单机部署密度增加了 5 倍以上，DBA 人均运维的数据库实例规模增加了 14.9 倍。  \n\n通过以上这些数字，我们可以发现，**近几年 vivo 互联网业务正处于一个高速发展的状态，在这个过程中无论是从用户感受到的服务质量上来看还是从内部的成本效率来看，解决数据存储的问题都是迫在眉睫的**，于是我们在 2018 年启动了自研数据库与存储平台的计划，通过几年时间的建设，我们初步具备了一些能力，现在就这些能力给大家做下简单的介绍。\n\n## 二、数据库与存储平台能力介绍\n\n![04.jpeg](https://img1.www.pingcap.com/prod/04_95dc265508.jpeg)\n\n数据库与存储平台产品主要分为 2 层。**底层是数据库和存储产品**，包括关系型数据库、非关系型数据库和存储服务三大块。**上层主要是工具产品**，包括提供的数据库和存储、统一管控的研发和运维平台、数据传输服务、运维白屏化工具，还有一些 SQL 审核，SQL 优化，数据备份等产品。工具产品主要以自研为主，下面一层的数据库和存储产品我们会优先选用成熟的开源产品，同时也会在开源产品的基础上或者纯自研一些产品，以更好地满足业务发展。\n\n### DaaS 平台\n\n![05.jpeg](https://img1.www.pingcap.com/prod/05_3ebbd46d00.jpeg)\n\n![06.jpeg](https://img1.www.pingcap.com/prod/06_d04d1503ec.jpeg)\n\nvivo 的 DaaS 平台旨在**提供高度自助化、高度智能化、高可用、低成本的数据存储使用和管理的平台**，涵盖了数据库和存储产品从服务申请、部署、维护直至下线的全生命周期。主要从四个方面为公司和用户提供价值。  \n\n第一是提升数据库产品的可用性，通过巡检、监控、预案、故障跟踪等对故障进行事前防范、事中及时处理、事后复盘总结进行全流程闭环；第二是提升研发效能，研发自助使用数据库，提供变更检测、优化诊断等功能，减少人工沟通流程，项目变更规范流程清晰，提升研发效率；第三是提升数据安全性，通过权限管控、密码管控、数据加密、数据脱敏、操作审计、备份加密等一系列手段全方位地保障数据安全性；第四是降低数据库和存储产品的运营成本，首先通过自动化的流程减少 DBA 的重复工作，提高人效，其次通过服务编排和资源调度，提升数据库和存储服务的资源使用效率，持续降低运营成本。  \n\n通过几年时间的建设，以上工作取得了一些进展，其中每月数以千计的需求工单，90% 以上研发同学可以自助完成，服务可用性最近几年都维持在 4 个 9 以上，平台对 6 种数据库产品和存储服务的平台化支持达到了 85% 以上，而且做到了统一能力的全数据库场景覆盖，比如数据变更，我们支持 MySQL、ElastiSearch、MongoDB、TiDB 的变更前语句审查，变更数据备份，变更操作一键回滚，变更记录审计追踪等。\n\n### DTS\n\n![07.jpeg](https://img1.www.pingcap.com/prod/07_4054146a20.jpeg)\n\n![08.jpeg](https://img1.www.pingcap.com/prod/08_4e120b9515.jpeg)\n\nvivo 的 DTS 服务是基于自身业务需求完全自研的数据传输服务，主要提供 RDBMS、NoSQL、OLAP 等数据源之间的数据交互。集数据迁移、订阅、同步、备份的一体化服务，从功能上来看，主要有三个特性：第一是同步链路的稳定性和数据可靠性保障，通过结合各个数据源产品的自身特性可以做到数据不重不丢，给业务提供 99.99% 的服务可用性保障；第二是功能层面支持异构的多种数据库类型，除了同步、迁移、订阅等这些通用功能外，我们还支持变更数据的集中化存储和检索；第三是故障容灾层面，支持节点级别故障容灾，可以做到同步链路秒级恢复，也支持断点续传，可以有效地解决因硬件、网络等异常导致的传输中断问题。\n\n### MySQL 2.0\n\n![09.jpeg](https://img1.www.pingcap.com/prod/09_afaa3f4b71.jpeg)\n\n![10.jpeg](https://img1.www.pingcap.com/prod/10_db42533dbf.jpeg)\n\nMySQL 作为最流行的开源数据库，在 vivo 同样承担了关系型数据库服务的重任，上图的 MySQL 2.0 是我们内部的架构版本。  \n\nvivo 为了快速解决当时面临的可用性问题，基于 MHA+ 自研组件做了MySQL 1.0 版本。目前已经演化到了 2.0 版本，MHA 等组件依赖已经没有了，从架构上看，2.0 版本的服务接入层我们支持业务使用 DNS 或者名字服务接入，中间加入了一层自研的代理层 Proxy，这一层做到了 100%与 MySQL 语法和协议兼容，在 Proxy 上面我们又实现了三级读写分离控制，流量管控，数据透明加密，SQL 防火墙，日志审计等功能。  \n\nProxy 层结合底层的高可用组件共同实现了 MySQL 集群的自动化、手动故障转移，通过 Raft 机制保障了高可用管控组件自身的可用性，当然 MySQL 用的还是主从架构，在同地域可以跨 IDC 部署，跨地域同步可以用前面提到的 DTS 产品解决，跨地域多活目前还未支持，这部分将在规划中的 3.0 架构实现。\n\n### Redis 服务\n\n![11.jpeg](https://img1.www.pingcap.com/prod/11_167656fd55.jpeg)\n\n![12.jpeg](https://img1.www.pingcap.com/prod/12_ff8d149494.jpeg)\n\nRedis 作为非常流行和优秀的 KV 存储服务，在 vivo 得到了大量的应用，在 vivo 互联网的发展历程中，有使用过单机版的 Redis，也有使用过主从版本的 Redis。到目前为止，已经全部升级到集群模式，集群模式的自动故障转移，弹性伸缩等特性帮我们解决了不少问题。  \n\n但当单集群规模扩大到 TB 级别和单集群节点数扩展到 500+以后还是存在很多问题，基于解决这些问题的诉求，我们在 Redis 上面做了一些改造开发，主要包括三部份：  \n\n第一是 Redis Cluster 的多机房可用性问题，为此我们研发了基于 Redis Cluster 的多活版本 Redis。  \n\n第二是对 Redis 的数据持久化做了加强，包括 AOF 日志改造，AEP 硬件的引入，包括正在规划中的 Forkless RDB 等。  \n\n第三是 Redis 同步和集群模式的增强，包括异步复制，文件缓存，水位控制等，还有对 Redis Cluster 指令的时间复杂度优化，Redis Cluster 指令的时间复杂度曾经给我们的运维带来了很多的困扰，通过算法的优化，时间复杂度降低了很多，这块的代码目前已经同步给社区。\n\n### 磁盘 KV 存储服务\n\n我们在 Redis 上做了这些优化后，发现仅仅有内存型的 KV 存储是无法满足业务需要，未来还有更大的存储规模需求，必须有基于磁盘的 KV 存储产品来进行数据分流，对数据进行分层存储，为此我们基于 TiKV 研发了磁盘 KV 存储产品。\n![13.jpeg](https://img1.www.pingcap.com/prod/13_8246d924cf.jpeg)\n\n![14.jpeg](https://img1.www.pingcap.com/prod/14_89cb057453.jpeg)\n\n我们在启动磁盘 KV 存储服务研发项目时就明确了业务对存储的基本诉求。第一是兼容 Redis 协议，可以很方便地从原来使用 Redis 服务的项目中切换过来；第二是存储成本要低，存储空间要大，性能要高，结合运维的一些基本诉求比如故障自动转移，能够快速地扩缩容等。最终我们选择了以 TiKV 作为底层存储引擎实现的磁盘 KV 存储服务，我们在上层封装了 Redis 指令和 Redis 协议。其中选择 TiKV 还有一个原因是 vivo 整体的存储产品体系中有使用到 TiDB 产品，这样可以降低运维人员学习成本，能够快速上手。  \n\n我们还开发了一系列周边工具，比如 Bulk load 批量导入工具，支持从大数据生态中导入数据到磁盘 KV 存储，数据备份还原工具，Redis 到磁盘 KV 同步工具等，这些工具大大地降低了业务的迁移成本，目前我们的磁盘 KV 存储产品已经在内部广泛使用，支撑了多个 TB 级别的存储场景。\n\n### 对象存储服务\n\n![15.jpeg](https://img1.www.pingcap.com/prod/15_508970371c.jpeg)\n\n![16.jpeg](https://img1.www.pingcap.com/prod/16_fc6d3087aa.jpeg)\n\n我们知道业务运行过程中除了需要对一些结构化或者半结构化的数据有存取需求之外，还有大量的非结构化数据存取需求。vivo 的对象与文件存储服务正是在这样的背景下去建设的。  \n\n对象和文件存储服务使用统一的存储底座，存储空间可以扩展到 EB 级别以上，上层对外暴露的有标准对象存储协议和 POSIX 文件协议，业务可以使用对象存储协议存取文件、图片、视频、软件包等，标准的 POSIX 文件协议可以使得业务像使用本地文件系统一样扩展自己的存取需求，比如 HPC 和 AI 训练场景，可以支撑百亿级别小文件的 GPU 模型训练。针对图片和视频文件，还扩展了一些常用的图片和视频处理能力，比如水印、缩略图、裁剪、截帧、转码等。\n\n前面简单介绍了 vivo 数据库与存储平台的一些产品能力，那么下面我们再来聊聊在平台建设过程中，我们对一些技术方向的探索和思考。\n\n## 三、数据库与存储技术探索和思考\n\n### 运维研发效率提升\n\n![17.jpeg](https://img1.www.pingcap.com/prod/17_69393c4e30.jpeg)\n\n![18.jpeg](https://img1.www.pingcap.com/prod/18_45f4a2dfda.jpeg)\n\n在平台建设方面，运维研发效率提升是老生常谈的话题，在业内也有很多建设得不错的平台和产品，但是关于如何在数据存储这一层提升运维研发效率相关的探索还比较少。  \n\n我们的理解是：**首先是资源的交付要足够敏捷，要屏蔽足够多的底层技术细节**，为此我们将 IDC 自建的数据库、云数据库、云主机自建数据库进行云上云下的统一管理，提供统一的操作视图，降低运维和研发的使用成本；同时**要提升效率就不能只关注生产环境**，需要使用有效的手段将研发、测试、预发、生产等多种环境统一管控起来，做到体验统一，数据和权限安全隔离。  \n\n此外，我们运用 DevOps 解决方案的思想，将整个平台在逻辑上分为两个域，一个是研发域，一个是运维域。  \n\n在研发域，我们需要思考如何解决研发同学关于数据库和存储产品的效率问题。交付一个数据库实例和支持他们在平台上可以建库建表是远远不够的，很多操作是发生在编码过程中的，比如构造测试数据，编写增删改查的逻辑代码等等。我们希望在这些过程中就和我们的平台发生交互，最大程度的提升研发效率。  \n\n在运维域，目前有一个比较好的衡量指标就是日常运维过程中需要登录服务器操作的次数，现在我们在做的工作就是将运维的动作全部标准化、自动化，并且未来有一些操作可以智能化。  \n\n在研发和运维交互的部分，我们的建设目标是减少交互，流程中参与的人越少效率就越高，让系统来做决策，实现的方案是做自助化。  \n\n### 数据安全管理\n\n![19.jpeg](https://img1.www.pingcap.com/prod/19_7235bdd577.jpeg)\n\n![20.jpeg](https://img1.www.pingcap.com/prod/20_092f919738.jpeg)\n\n安全无小事，为此我们将数据库安全和数据安全的部分单独拿出来进行规划和设计，基本的原则就是权责分明。数据库体系涉及到账号密码等，我们联合 SDK 团队共同研发了密码加密传输使用方案，数据库的密码对研发、运维而言都是密文，在项目的配置文件中依然是密文，使用时对接公司的密钥管理系统进行解密。  \n\n针对数据的部分，我们联合安全团队对敏感数据做了自动标注识别，分类分级，对敏感数据的查询、导出、变更上做了严格的管控，比如权限管控、权限升级、通过数字水印技术进行使用追踪，通过事后的审计可以追溯到谁在什么时刻查看了什么数据。针对敏感数据我们也做了透明加解密操作，落盘到存储介质的数据是经过加密存储的。  \n\n同理，备份的数据和日志也做了加密存储，这些是目前我们做的事情，未来在安全上我们还有很多的工作要做。\n\n### 数据变更管理\n\n![21.jpeg](https://img1.www.pingcap.com/prod/21_287e17ba15.jpeg)\n\n![22.jpeg](https://img1.www.pingcap.com/prod/22_33a0f94200.jpeg)\n\n针对数据变更的场景，我们关注的主要有两点：  \n\n第一是数据变更本身会不会影响已有的业务，为此我们建设了不锁表结构、不锁表数据的变更能力，针对上线前、上线中、上线后三个环节设置三道防线。杜绝一些不好的 SQL 或者 Query 流入到生产环境，针对变更过程中或者变更结束后如果想回滚，我们也做了一键回滚方案。  \n\n第二是变更效率问题，针对多个环境、多个集群我们提供了一键同步数据变更方案，同时为了更好地提升用户体验，我们也提供了 GUI 的库表设计平台。有了这些基础之后，我们将整个场景的能力全部开放给研发同学，现在研发同学可以 24 小时自助进行数据变更操作，极大地提升了变更效率。  \n\n### 数据存储成本管控\n\n![23.jpeg](https://img1.www.pingcap.com/prod/23_5bbd17b8a3.jpeg)\n\n关于成本我们主要从四个方面进行管理：  \n\n第一是预算的管控，资源去物理化，业务以资源为粒度进行预算提报，在预算管控层面对服务器的消耗进行预测和不断的修正，保证水位的健康。  \n\n第二是数据库服务的部署，这块我们经历了几个阶段，最早期是单机单实例，浪费了很多资源，后面发展为标准化套餐部署，同一类型的存储资源不同的套餐混合，通过算法的优化不断的提升资源的使用效率。  \n\n第三是不同属性资源的混合部署，比如数据库的代理层和对象存储的数据节点混合部署，这两种资源一个是 CPU 型的，一个是存储型的，正好可以互补，再往后发展的下一个阶段应该是云原生存储计算分离，还在探索中。  \n\n第四是服务部署之后还需要不断的关注运行中的状况，对容量做巡检和预警，对集群及时的做升降配操作，保障整个运行状态有序。同时需要关注业务运行状态，及时回收下线数据存储集群，减少僵尸集群的存在。  \n\n成本部分还有一个重点就是硬件资源的迭代，这里就不做展开了。  \n\n### 对象与文件储存建设与思考\n\n![24.jpeg](https://img1.www.pingcap.com/prod/24_df500f8909.jpeg)\n\n![25.jpeg](https://img1.www.pingcap.com/prod/25_1b313cd6bf.jpeg)\n\n对象与文件存储这块我们主要关注的有两点：  \n\n第一是成本，关于成本这块我们在数据冗余策略这块使用了 EC，并且做了跨 IDC 的 EC，单个 IDC 全部故障也不会影响我们的数据可靠性。我们还引入了高密度大容量存储服务器，尽可能多地提升单机架存储密度，需要注意的是服务器采购之后的运行成本也不可忽视，依然有很大的优化空间。我们还提供了数据无损和透明压缩的能力和生命周期管理的能力，及时清理过期数据和对冷数据进行归档。通过多种手段持续降低存储成本。  \n\n第二是性能，关于性能这块我们提供了桶&对象粒度底层存储引擎 IO 隔离，通过引入一些开源组件如 alluxio 等提供了服务端+客户端缓存，提升热点数据读取性能，在底层存储引擎我们引入了 opencas 和 IO_URING 技术，进一步提升整机的磁盘 IO 吞吐。\n\n以上就是我们目前在建设的能力的一些探索和思考，最后再来看下我们未来的规划。\n\n## 四、数据库与存储平台规划\n\n![26.jpeg](https://img1.www.pingcap.com/prod/26_6e6dfc750f.jpeg)\n\n在整个存储服务层，我们会不断地完善存储服务矩阵，打磨产品，提供更多元的存储产品，更好地满足业务发展诉求。同时在存储服务层会基于现有存储产品做一些 SAAS 服务来满足更多的业务诉求。在功能层，我们拆解为 4 部分：  \n\n- **数据基础服务**，这部分提供存储产品基本功能，包括部署、扩缩容、迁移、监控告警、备份恢复，下线回收等等。\n- **数据服务**，存储产品本质上是存储数据的载体，针对数据本身我们也有一些规范，最基本的比如数据的查询变更性能优化，数据治理和如何深入到业务编码过程中去。\n- **存储自治服务**，初步划分为性能自治、容量自治、智能诊断、场景服务四大块，通过自治服务一方面可以提升 DBA 工作的幸福感，一方面也可以大大的提升我们系统本身的健壮性和稳定性。\n- **数据安全服务**，目前虽然建设了一些能力，但是不够体系化，未来会继续加大投入。\n\n未来整个存储服务体系会融入到公司整体的混合云架构中，给用户提供一站式和标准化的体验。","author":"肖博","category":4,"customUrl":"construction-and-exploration-of-vivo-database-and-storage-platform","fillInMethod":"writeDirectly","id":351,"summary":"本文根据 vivo 存储技术团队研发总监肖博在 2021 vivo 开发者大会上的分享整理而成，从数据库与存储平台的建设背景、能力介绍、探索思考、未来展望四个角度进行了整体的介绍。","tags":["TiKV"],"title":"vivo 数据库与存储平台的建设和探索"}},{"relatedBlog":{"body":"本文根据微众银行资深数据库架构师黄蔚在 DevCon 2022 上的分享整理，主要讲述了微众银行对于 HTAP 架构的探索和实践情况，以及提升大规模分布式数据库运维效率的经验。\n\n内容将从四个方面展开：HTAP 技术的演进历程、微众银行在 HTAP 技术的选型以及实践、在大规模分布式数据库自动化运维的优化实践、TiDB 在微众银行的未来规划。\n\n## TiDB HTAP 架构的演进\n\n我们知道一项新技术的出现和发展，其背后往往有两个原因：一是因为业务驱动，追求客户的极致体验；二就是技术的发展，通过一些新技术的创新和应用，进一步降低硬件成本、开发成本或整体维护成本。HTAP 其实也是在这样背景下诞生的。\n\n我们首先来看传统的数据架构有哪些瓶颈或者有哪些优化点。我们知道，按照负载类型划分，系统一般分为 OLTP 和 OLAP，OLTP 在金融场景一般是包括像交易、转账、营销等，面向的是客户，追求的是极致体验，如果有问题很可能就会影响用户体验，甚至造成用户损失。所以 OLTP 要求的是耗时短，并且处理的数据量相对小。\n\n而我们还要基于这些用户产生的数据做商业分析、数据挖掘，根据分析结果来进行决策，比如进行战略方向上的调整。所以衍生出来了 OLAP，通常专门用来做一些分析。而 OLTP 和 OLAP 的负载不一样，也就意味着技术底座是不一样的，所以一般是将两者分开，这个时候就需要通过 ETL 的方式把数据传输到 OLAP 上做分析，但是这个传输的过程在时效性上会比较差，同时架构也会比较复杂，但优势是这套架构非常成熟，尤其是自从大数据三驾马车的论文出来之后，大数据的整个生态变得更加成熟，使用也更广泛。\n\n![1.png](https://img1.www.pingcap.com/prod/1_bdab763240.png)\n\n随着业务的发展，业务对于时效性的要求越来越高，比如希望实时对用户进行客群圈选、画像分析、实时洞察，或者做金融场景的风控，这时候就诞生出了 Kappa 架构。\n\nKappa 架构的核心就是流式处理， OLTP 系统产生的 CDC 或者 Message 通过 Kafka 消息队列传输到常见的流处理技术组件比如 Flink、Spark Streaming 进行处理，最终到 Serving DB 来存放这些数据并实时对外提供服务。而对于 Serving DB 的要求首先是扩展性要好，同时受限于流式处理暂时没法完全取代批处理，那就意味着在 Serving DB 上还需要做一定的 OLAP 分析。其实 TiDB 在这个架构里也有一定的使用量，比如 Flink 要存放一些中间态数据或者进行维表关联，对于 DB 也需要一定的扩展性，此时 TiDB 的扩展能力正好可以满足。\n\n这个架构的核心特点就是准实时处理，而且在工程实践上非常丰富。而这个架构的劣势是组件很多，学习的成本相对高，并且整个链路很长，意味着在数据一致性的保证上会比较困难。所以，大家就在想能不能在一个数据库同时去承载 OLTP 跟 OLAP 业务呢？不需要去做额外的数据同步，不需要去学习额外的组件，所以就衍生出了 HTAP 数据库的概念。\n\n它的架构很简洁，但是实现技术难度也非常高。虽然这几年 HTAP 非常火，但是工程实践相对较少，像传统的 Oracle 12c In-Memory Column Store、Google Spanner PAX 其实都算是行列混存的架构，TiDB 也有自己的 HTAP 实现。HTAP 架构的难度是怎样做资源隔离，怎样做一致性保证，如何做 OLTP 和 OLAP 的负载平衡等等。\n\n接下来谈谈 TiDB HTAP 架构的演进，我们如何基于业务需求去做选型以及对应的实践情况。\n\n图中，我们看到 TiKV 为了让数据均衡，容易做分布式调度，会把数据分成很多小片，也就是 Region，Region 在 TiKV 这一侧是强同步的，我们可以看到绿色线条是实线。而 TiFlash 的创新点就是没有打破原来 TiKV 的架构，而是新增一个列式引擎，直接通过 Raft Log 的方式同步到 TiFlash，因为列式存储天然对于 OLAP 场景是比较友好的，所以还要做一个行转列的处理。我们可以看到 TiKV 到 TiFlash 的同步线是一条虚线，意味着这是一个异步过程。那么又如何保证在 TiFlash 上的查询是强一致的呢？这里其实做了一些优化，每次收到读取请求，TiFlash 中的 Region 副本会向 Leader 副本发起进度校对（一个非常轻的 RPC 请求），只有当进度确保至少所包含读取请求时间戳所覆盖的数据之后才响应读取，所以如果有同步延迟，就会需要等待，甚至有可能在 TiFlash 的查询会超时，在实践中我们发现有些场景对于 OLAP 的一致性要求并没那么高，而在 6.0 版本的 TiFlash 提供了 Fast Scan 这个功能，降低一致性的保障，但可以提升读写速度。\n\n![2.png](https://img1.www.pingcap.com/prod/2_c6ad6584d1.png)\n\n我们看到 TiDB HTAP 架构隔离性非常好，因为列存跟行存完全独立，同时 TiFlash 借助了 MPP 并行计算框架，并且是基于 Clickhouse 底座，所以天然具备向量化计算引擎的一些 OLAP 特性。同时，TiDB HTAP 架构创新性地通过 Raft Log 来同步保证了一致性，同时也可以通过 Fast Scan 功能来降低一致性，提高读写速度。进一步的，TiDB 的产品迭代非常快，有一些特性是我们也非常期待，比如说低成本的硬盘支持、更准确的优化器等。\n\n## 微服务分布式链路追踪和微服务治理场景下的 HTAP 实践\n\n在银行场景下我们怎样选型 HTAP 技术呢？微众银行的基础架构是基于 DCN 的分布式架构，也就是单元化，一笔简单的交易可能涉及到几十甚至上百个微服务在背后支撑，所以微服务的调用量很大。那么我们怎样快速地进行定位异常问题呢？比如说一笔交易或者一个系统如果有异常，怎样快速地知道哪里出问题了？这里就需要借助可观测的方式。可观测一般都会谈到 Trace、Metrics、Log 这三个基本元素。\n\n基于微众银行 DCN 的分布式架构，如果两个用户分属不同的 DCN，要进行交互比如转账，就需要通过 RMB 可靠消息总线来进行交互。我们为了保存完整全量的微服务调用关系，会旁路地消费一份服务之间的调用消息，把这些信息存到 TiDB。为什么存到 TiDB 呢？我们行内交易量特别大，TiDB 正好能提供扩展性，同时 TiDB 支撑的并发量也很大，每秒达到了 20 万+ 这样一个量级。\n\n![3.png](https://img1.www.pingcap.com/prod/3_75c2a9ba33.png)\n\n我们可以通过这些 Trace 信息去追踪这一笔交易涉及的不同服务、不同的子系统之间调用的详细信息，比如说源端、目标端调用的耗时，调用返回的状态，有没有报错等，这是微观层面的追踪。微服务场景下，服务数量非常多，种类也多，调用关系很复杂，我们怎样从全局的角度了解整个微服务的架构是否健康，是否存在问题，比如有没有流量突增，有没有系统性的问题？所以衍生出了服务治理这个系统。服务治理的要求是能够实时知道微服务整个调用关系的信息，所以我们就把 TiKV 存储的 Trace 信息实时同步到 TiFlash，同时我们预定义很多的度量指标，比如实时分析整个服务的健康度，整个子系统调用的次数排名，是否存在流量突增，耗时的变化等。\n\n基于这些度量指标，我们再通过决策引擎去得到一个最优的治理策略。我们的决策可以分成两部分，第一个是自动决策，通过度量指标直接把需要去治理的动作下发到生产环境的微服务的应用或者容器。第二个是辅助决策，生成一个决策值，人工进行判断，根据经验或者根据一些特定的阈值触发相应的策略，再下发到真正的生产环境。我们看到整个系统形成了一个闭环，从生产环境产生消息，到分析消息，再通过度量产生决策，最后又反向去影响我们的生产环境，让整个微服务的精细化管理越来越好，这是我们在 HTAP 选型的一个场景。\n\n当然我们也遇到了一些挑战，第一是集群非常大，第二是在这么大规模的集群下还要跟 TiFlash 结合。所以我们形成了相关的实践经验。首先，集群很大，如何稳定运行？我们从几个方面进行入手：第一，TiDB 的组件 PD 可能会存在个别单点瓶颈，所以我们把大集群 Region 总数控制在一定范围；第二，控制单个 TiKV 实例的 Region 数量，对于一些历史归档或者相对冷的数据，心跳维持不用太频繁，所以我们开启了 Hibernate Region 功能，减轻单个实例可能产生的瓶颈问题。\n\n![4.png](https://img1.www.pingcap.com/prod/4_59d74316fc.png)\n\n其次，TiDB 架构中 OLTP 的负载使用的是 TiKV，OLTP 往往面对的是客户，直接关系到用户体验的问题，我们认为在极端情况下 TiFlash 有异常的时候，不希望它影响到 TiKV，因此我们建立了一个快速熔断机制，目的是在 TiFlash 全部异常的情况下尽可能对 TiKV 的影响最小。我们还在超大集群 POC 时做了很多暴力验证，比如说把 TiFlash 全部直接关停，比如制造一些网络拥塞，IO、CPU 资源跑满等。在验证过程中我们也发现了很多问题，也相应都做了修复，我们认为未来在超大集群的使用上，HTAP 架构的健壮性会越来越好。\n\n刚刚提到，TiKV 跟 TiFlash 需要联动，集群很大，又要做数据的生命周期管理。TiKV 是做链路追踪，我们希望它的数据保留的时间比较长，比如 7 天，7 天之外的就删掉，TiFlash 做的是实时分析，我们希望保存数据的天数少一点，比如 3 天，这两边的清理策略是不一样的。这时候就会有一个问题，TiKV 跟 TiFlash 虽然物理上是隔离的，但 PD 调度是共用的，很可能会产生相互影响。举个简单例子，我们在超大集群下往往需要去提前规避写入热点问题进行提前打散。我们发现在打散的时候会影响正常写入，发现本质原因是打散动作首先会在一个 Region 上进行打散，最终再会去 scatter 均衡，而均衡背后有 Remove Peer 动作，就是把本地的 Peer 删掉，再调到其他节点上，而 Remove Peer 会有资源的占用。\n\n![5.png](https://img1.www.pingcap.com/prod/5_965690fb29.png)\n\n因为写入同样也会触发分裂，同样也会需要 Remove Peer 功能，这时候就产生了互斥。我们在整个实践中发现，各个调度参数之间可能会相互影响，所以需要找到参数之间的相互干扰的因素，再找到一个最佳的平衡点。最后，我们通过右下角这张图对相关参数进行了深入研究和调试，最终实现了超大集群下 TiKV+TiFlash 的稳定联动，可以确保 20 万+ 每秒的持续写入并不会产生明显抖动。\n\nTiFlash 实际上也是一个 OLAP 的引擎，在很多场景里会拿 TiFlash 去跟一些 OLAP 传统组件去对比，比如拿 TiFlash 跟 Clickhouse 去对比。我们在真正的业务场景中发现用户的需求场景很多，对应的技术要求也不一样，所以细分下来发现像有些分析场景，可能对于实时性要求很高，有些场景可能计算量很大，维度很固定，希望做一些预计算，还有一些交互式的，希望灵活和快速返回，所以我们通过细分业务场景以及对应的技术要求的细化，最终找到了不同的 OLAP 组件所对应的场景和最佳实践。\n\n![6.png](https://img1.www.pingcap.com/prod/6_15706b5cce.png)\n\n我们也对 TiFlash 和 Clickhouse 做了一个简单对比，可以很明显地看到 Clickhouse 在硬件成本以及单表的性能上有很大优势，而 TiFlash 在运维成本、开发成本以及实时更新有不错的优势。所以我们认为 OLAP 组件没有银弹，我们可以通过这种组合的方式，通过在各个 OLAP组件之上增加一个中间层来统一来提供服务给业务，让业务不用感知具体的引擎或组件，对用户来说，只需要去满足业务需求就好了。\n\nTiDB HTAP 的场景推荐有哪些呢？第一个肯定是 HTAP 型的交易系统，OLTP 是一定要用的，同时我们要结合 OLTP 把数据同步到 TiFlash 进行实时分析，这是第一种最经典的场景。第二种，我们知道 TiDB 有 DM 工具，可以把多个 MySQL 的数据快速地同步汇聚到一个 TiDB 集群，多源汇聚到 TiDB 后，TiDB 可以是一个数据中台、一个数据仓库或者是一个数据集市，再结合 TiFlash 的分析能力，快速地进行业务分析或业务监控，所以多源数据的汇聚和实时分析是第二个场景。第三个场景，就是上面提到的，把 TiDB 作为一个单纯的 OLAP 组件使用，当然成本会较高，因为如果只使用用 TiFlash，还是需要从 TiKV 进行数据同步。但是 TiDB 的好处就是开发成本比较低。\n\n![7.png](https://img1.www.pingcap.com/prod/7_bc61d19baa.png)\n\n## 基于微信机器人的 TiDB 数据库运维优化\n\n目前 TiDB 在微众银行的集群规模越来越大，从 2021 年开始的 20 多个集群到现在已经接近 60 个集群，数据的总容量也接近 800T，同样使用 TiDB DM 的量也非常大，应用的业务类型也特别多，包括贷款、存款、理财、科技管理、基础科技，应用的场景包括联机、批量、归档、管理平台等等。在数据增长快，应用规模大，业务场景类型多，重要性高的情况下，同时还要符合合规要求，因此在 TiDB 大规模分布式数据库的运维上，我们也进行了很多探索，比如怎样更高效地运维和使用分布式数据库。\n\n![8.png](https://img1.www.pingcap.com/prod/8_24a0250ae9.png)\n\n我们有三个方面的总结：第一，做标准化的 SOP，对于业务接入，日常变更和故障处理，我们都需要一些标准化的流程；第二，这么大规模的集群量，我们希望运维工作可以 Work Smart，也就是更加高效地处理遇到的问题，我们引进了微信机器人，把集群诊断、巡检这些工作都自动化了；最后，开源有一个最大的好处就是能看到源码，所以我们希望可以从源码侧去解析，这样有些疑难问题我们可以更加深入，更加快捷地去发现问题，同时提供更理想的优化方案。\n\n接下来看看我们基于微信机器人的 Smart 运维工作。可以看到，我们的 DBA 只需要通过微信，通过一部手机就可以对一些场景进行快速处理。以往，在银行，对于遇到一些生产的告警，我们需要去登陆 VPN，输入 Token，在其他的内部系统又要做二次登录校验，整个过程耗时比较长。而针对一些比较紧急的告警，登录到服务器，已经过去了不少时间，所以我们希望针对一些特定合适的告警场景，快速地去响应，所以我们基于微信机器人的方式进行了优化，分成几个层次。\n\n![9.png](https://img1.www.pingcap.com/prod/9_7ed05e4202.png)\n\n第一，通过 TiDB 自带的 TiUP 工具来做一些数据采集，包括集群信息和主机的 CMDB 信息，把这些信息全量入库。每天定时去把收集的信息进行分析巡检，输出一个报告。第二，在自动诊断这块，我们在 TiDB 上会遇到一些常见高频的问题，比如内存高、OOM、热点、慢查询、执行计划突变等，我们把这些问题处理会形成一个知识库，并且生成对应的分析引擎，如果触发了对应告警，就会自动地触发根因分析，并且生成推荐根因。在生成推荐根因的时候，我们还会模拟爬虫在 Grafana 上把最近的半小时的 Overview，包括一些监控视图、实例信息截图生成一个图片，结合刚才的推荐根因一起推送到我们的手机微信上。DBA 立马就可以看到告警发生可能的原因是什么，并且我们还可以快速地进行执行，处理相应问题。\n\n我们在微信机器人上提供了一个交互的快速执行方式。比如可以对一些慢查询进行 Kill，比如 restart TiDB Server，当然前提一定是安全合规，我们对一些高危命令会增加预审批流程，同时我们会预定义一些白名单的命令。最终可以看到，我们从巡检、数据采集、自动诊断以及交互式的快速执行四个维度来整体提升数据库的运维效率。\n\n这里是 Smart 运维的效果图，可以看到像 tiup display、show processlist，以及 kill 慢查询，restart server 等一系列动作，都可以通过一部手机去完成，我们内部称为微信机器人的运维方式，这种方式提升了数据库的运维效率。\n\n![10.png](https://img1.www.pingcap.com/prod/10_3ec3f64d9c.png)\n\n最后做一个简单的展望，我们希望未来继续沉淀 HTAP 技术在金融场景的探索和落地经验，形成金融场景的最佳实践。同时，我们希望未来能够把内部的一些运维工具，比如 DM 自动化校验平台、自动诊断平台等开源出去，能够和大家进行深入的交流和共创。 \n最后，随着国产化的进程，我们也会推动 TiDB 在国产 ARM 服务器上的进一步扩大使用。\n\n<div class=\"is-flex is-flex-direction-row is-justify-content-center\">\n  <div class=\"is-flex is-flex-direction-column\">\n    <a target=\"_blank\" class=\"button is-link mx-5\"\n       href=\"/product-community/\"\n       style=\"background-color: #4fc172;\">\n      下载 TiDB 社区版\n    </a>\n  </div>\n  <div class=\"is-flex is-flex-direction-column\">\n    <a target=\"_blank\" class=\"button is-link mx-5\"\n       href=\"https://pingcap.com.cn\"\n       style=\"background-color: #3a40e1;\">\n      了解 TiDB 企业版\n    </a>\n  </div>\n  <div class=\"is-flex is-flex-direction-column\">\n    <a target=\"_blank\" class=\"button is-link mx-5\"\n       href=\"https://tidbcloud.com/free-trial?utm_source=website-zh&utm_medium=referral&utm_campaign=blog-tidb-6.5-release\"\n       referrerpolicy=\"no-referrer-when-downgrade\" style=\"background-color: #3a40e1;\">\n      免费试用 TiDB Cloud\n    </a>\n    <div style=\"font-size:12px; text-align:center\">适用于中国出海企业和开发者</div>\n  </div>\n</div>\n\n","author":"黄蔚","category":4,"customUrl":"tidb-htap-in-webank","fillInMethod":"writeDirectly","id":457,"summary":"本文根据微众银行资深数据库架构师黄蔚在 DevCon 2022 上的分享整理，主要讲述了微众银行对于 HTAP 架构的探索和实践情况，以及提升大规模分布式数据库运维效率的经验。","tags":["TiDB","HTAP"],"title":"微众银行 TiDB HTAP 和自动化运维实践"}}]}}},
    "staticQueryHashes": ["1327623483","1820662718","3081853212","3430003955","3649515864","4265596160","63159454"]}