{
"componentChunkName": "component---src-templates-blog-blog-detail-tsx",
"path": "/blog/user-case-ctrip",
"result": {"pageContext":{"blog":{"id":"Blogs_480","title":"携程 x TiDB丨应对全球业务海量数据增长，一栈式 HTAP 实现架构革新","tags":["TiDB","技术出海"],"category":{"name":"案例实践"},"summary":"本文介绍了携程数据库架构从 SQL Server 到 MySQL 再到 TiDB 的革新历程，从痛点分析、选型思考到部署实践，介绍了 TiDB 如何支撑携程的酒店和度假场景以及全球化业务，以一栈式 HTAP 支持携程全球业务海量数据增长。","body":"> 本文作者为携程数据库总监刘博\n\n## 导读\n\n携程作为全球领先的一站式旅行平台，旗下拥有携程旅行网、去哪儿网、Skyscanner 等品牌。携程旅行网向超过 9000 万会员提供酒店预订、酒店点评及特价酒店查询、机票预订、飞机票查询、时刻表、票价查询、航班查询等服务。 \n\n随着业务量迅速增长，携程需要更敏捷的技术架构来满足不断激增的并发与数据量，一个稳定、可靠，可以随业务增长不断扩展的数据库对于携程来说显得尤其重要。作为海内外在线旅游行业的翘楚，携程也曾面临着数据库带来的技术挑战。 \n\n本文介绍了携程数据库架构从 SQL Server 到 MySQL 再到 TiDB 的革新历程，从痛点分析、选型思考到部署实践，全面介绍了 TiDB 如何支撑携程的酒店和度假结算场景、海量数据场景以及全球化业务，以一栈式 HTAP 支持携程全球业务海量数据增长。\n\n## 原 MySQL 架构痛点与挑战\n\n携程创立于 1999 年，最初选择使用 SQL Server 数据库，在整体数据库技术栈中占比达到 99%。2012 年初，携程开始逐步关注开源技术，尤其是 MySQL，不过该阶段 MySQL 使用占比仍然很低，只有 10% 左右。从 2014 至 2019 年，携程开始加深 MySQL 的应用，并因为业务形态发生了变化，携程开始从 SQL Server 转型到 MySQL，对 MySQL 进行了深入研究，包括内核补丁、全自动故障诊断等。\n\n\n\n携程的应用部署在两个或多个 IDC 中，数据库也对等部署在每个 IDC 中。MySQL 部署方式采用 HA 节点，即主备节点，在同一机房部署，另一节点在不同 IDC 部署，这种方式保证了 HA 切换速度和数据的容灾。比如遇到单机房故障或者整个机房宕机，可以迅速把第二节点启动起来。携程在主备切换和第二切换时做了很多自动化工作，但这种架构也有明显缺点，由于应用的无状态化，数据库的切换会造成业务的短暂中断，因为数据库只有一个主节点。\n\n\n\n在扩展方式方面，携程没有采用中间件的方式，而是采用客户端实现分片规则。客户端在上线时会确定分片规则，再根据 ID 使用取模运算定位到某个分片，这样可以更方便地进行扩展。当业务增加时实例数量从 1 变成 N ，当负载下降时也可以缩回来。\n\n但是这种扩展方式对 DBA 运维来说还有一些挑战，随着 DBA 越来越多，聚合会比较困难，业务代码也变得复杂。\n\n## 分布式数据库选型\n\n2018 年，随着携程业务的快速发展，底层架构需要支持弹性扩展，特别是在季节性高峰期（例如春运火车票抢票等）。分布式数据库由于具有 DB 级弹性、快速扩展和混合负载（HTAP）等优势，更适合业务的发展，携程开始考虑引入分布式数据库，并进行调研选型。携程主要从以下几个维度考量分布式数据库：\n\n- 性能：平衡性能和成本，选择通用机型，不使用高端存储或机器，并要求响应稳定；\n- 运维与社区：学习成本适中，运维复杂度低，产品需开源且社区活跃；\n- 成本：一方面，业务研发需要学习使用 SQL，特别是 MySQL 协议；另一方面，运维团队希望产品不要过于复杂，易于维护；\n- 扩展性：分布式数据库需要具有快速的扩展能力，扩缩容对业务影响小。\n\n\n携程 TiDB 部署模式\n\n2018 年，携程开始正式引入 TiDB。考虑到 TiDB 的架构和携程的 IDC 环境，携程将 TiDB 分别部署在三个 IDC 机房（IDC1、IDC2、IDC3）中，遵循同时部署的标准。TiKV、TiDB 和 PD 均匀分布在三个 IDC 机房中，业务流量可以本地感知到每个机房的 TiDB Server ，在单机房故障时可以自动重启到其它机房。因为客户端对 TiDB 进行了探活与感知，单个 TiDB 服务器故障时客户端可以重新定向。\n\n## TiDB 在酒店和度假结算场景的应用\n\n携程作为一个大型的在线旅游平台，其酒店和度假结算场景下需要处理大量的交易数据。携程原 MySQL 架构主要采用分片（sharding）的扩展方式，对于酒店和度假结算这类业务来说，分片会变得非常困难。最初的方案是把 SQL Server 上的数据原封不动导入到 MySQL 中，但测试后发现性能不佳，扩展性也受限。如果采用分片方式部署，不论从酒店的维度、供应商的维度或者是用户维度，都很难选择合适的分片键（ sharding key），这种方式也对业务代码侵入性比较大。\n\nTiDB 的分布式架构可以将数据分散存储在多个节点上，实现数据的水平扩展，提高系统的承载能力。因此，携程最终选择了 TiDB，将酒店和度假结算业务从 SQL server 迁移到 TiDB 上，总数据量规模达到 8TB，并受到了开发人员的一致好评，满足了性能和扩展性的诸多要求，同时降低了运维成本，能够更好地支持携程业务的发展。\n\n## TiDB 在海量数据场景中的应用\n\n携程的海量数据场景涉及到大量数据存储。原架构中由于单机存储限制，扩展必须通过 sharding 方式实现。但该解决方案对于一些业务而言过于复杂，例如在 IBU 海外业务部数据，单表数据已经超过 300 亿。应用 TiDB 可以大幅提高查询性能，实现大量数据的高效存储。TiDB 的行列混存架构（ TiFlash 和 MPP 技术），使得携程部分查询性能有了 20 倍提升；在信息安全源数据标记数据时，单表数据也超过了 60 亿行，读写的响应时间都达到毫秒级，单天聚合查询秒级返回。\n\n\n\n除了使用 TiDB ，携程还在使用其存储层 TiKV。引入 TiKV 是因为携程现在的业务有一些简单的 KV 存储需求，携程在使用的产品有 Redis 和 Hbase，但是 Hbase 的性能相比于 Redis 比较差，而 Redis 则存在数据不一致的风险，比如网络抖动、中断等。携程有一些业务有强一致 KV 需求，例如近期引入的酒店取消政策项目，Redis 虽然能满足业务需求，但没有强一致性能。综合考量之后，携程选择了 TiKV 解决上述挑战。TiKV 的部署与 TiDB 类似，也是在三个机房分布部署，应用可以感知到每个机房的 PD，并且 PD 也在三个机房分别部署。该架构可以确保如果出现机房级故障，或是单 PD 故障，运维团队都可以做到平滑切换。\n\n\n\n## TiDB 在携程的全球化运用\n\n\n\n\n\n\n\n随着携程近年来开始走向海外，海外业务呈现迅猛增长趋势。携程也将国内成熟的数据库技术直接用于海外。目前，TiDB 在携程的国内和海外业务是分开部署的，海外应用复用了国内的 schema 和代码，监控告警方式也与国内保持一致，部署方式也是相同的。\n\n携程引入 TiDB 并完成了一系列内部生态整合，包括发布系统（如表结构发布、索引发布）、数据修改和查询等。由于 TiDB 和 MySQL 采用了相同的协议，整合过程相对简单平滑：\n\n- TiDB 原生支持 Prometheus + Grafana，提供了丰富的诊断数据，可以根据 TiDB 故障诊断手册快速定位问题。\n- 由于 Grafana 的数据在每个集群上单独分布，携程通过 prometheus 源生 remote write 转发性能数据到携程统一监控平台，以便在监控平台上进行性能告警和大盘监控。\n\n目前 TiDB 稳定应用于携程的国内、海外各业务场景中，借助 TiDB HTAP 能力，携程大幅提高了查询性能，实现海量数据的高效存储。","date":"2023-03-07","author":"刘博","fillInMethod":"writeDirectly","customUrl":"user-case-ctrip","file":null,"relatedBlogs":[{"relatedBlog":{"body":"vivo 是一个专注于智能手机领域的国际化品牌，市场不断变化，新零售热潮扑面而来。在数字化转型过程中，vivo 的基础平台架构也面临着更多的挑战。在自主研发的同时，vivo 依托包括 TiDB、TiKV 在内的众多开源项目进行迭代和设计，打造了全新的数据库与存储平台，覆盖通用存储产品运维和研发需求。\n\n本文来源于 vivo 互联网技术，根据 vivo 存储技术团队研发总监肖博在 2021 vivo 开发者大会上的分享整理而成，**从数据库与存储平台的建设背景、能力介绍、探索思考、未来展望四个角度进行了整体的介绍**。\n\n## 一、数据库与存储平台建设背景\n\n\n\n以史为鉴，可以知兴替，做技术亦是如此，在介绍平台之前，我们首先回顾下 vivo 互联网业务近几年的发展历程。 \n\n我们将时间拨回到三年前，2018 年 11 月，vivo 移动互联网累计总用户突破 2.2 亿；2019 年应用商店、浏览器、视频、钱包等互联网应用日活突破千万大关；2020 年浏览器日活突破 1 亿，2021 年在网总用户（不含外销）达到 2.7 亿，数十款月活过亿的应用，数据库和存储产品也达到了 4000 + 服务器和 5 万 + 数据库实例的规模。 \n\n那三年前的数据库和存储平台是什么样呢?\n\n\n\n2018 年的数据库服务现状如果用一个词形容，那我觉得“**危如累卵**”最适合不过了，主要表现为以下几点： \n\n- 数据库线上环境的可用性由于低效的 SQL、人为的误操作，基础架构的不合理，开源产品的健壮性等问题导致可用性经常受到影响。\n- 变更不规范，变更和各种运维操作的效率低下，没有平台支撑，使用命令行终端进行变更，导致数据库使用的成本极高，为了应对日益复杂的业务场景，增加了很多额外的成本。\n- 安全能力不够健全，数据分类分级、密码账号权限等缺乏规范。\n\n我们再看看这些年 vivo 数据库运营数据上的变化趋势。\n\n\n\n从 17 年底，18 年初开始计算，这三年时间里数据库实例的规模增加了接近 5 倍，维护的数据库服务器规模增加了 6.8 倍，数据库实例的单机部署密度增加了 5 倍以上，DBA 人均运维的数据库实例规模增加了 14.9 倍。 \n\n通过以上这些数字，我们可以发现，**近几年 vivo 互联网业务正处于一个高速发展的状态，在这个过程中无论是从用户感受到的服务质量上来看还是从内部的成本效率来看，解决数据存储的问题都是迫在眉睫的**，于是我们在 2018 年启动了自研数据库与存储平台的计划，通过几年时间的建设，我们初步具备了一些能力，现在就这些能力给大家做下简单的介绍。\n\n## 二、数据库与存储平台能力介绍\n\n\n\n数据库与存储平台产品主要分为 2 层。**底层是数据库和存储产品**，包括关系型数据库、非关系型数据库和存储服务三大块。**上层主要是工具产品**，包括提供的数据库和存储、统一管控的研发和运维平台、数据传输服务、运维白屏化工具，还有一些 SQL 审核，SQL 优化，数据备份等产品。工具产品主要以自研为主，下面一层的数据库和存储产品我们会优先选用成熟的开源产品，同时也会在开源产品的基础上或者纯自研一些产品，以更好地满足业务发展。\n\n### DaaS 平台\n\n\n\n\n\nvivo 的 DaaS 平台旨在**提供高度自助化、高度智能化、高可用、低成本的数据存储使用和管理的平台**，涵盖了数据库和存储产品从服务申请、部署、维护直至下线的全生命周期。主要从四个方面为公司和用户提供价值。 \n\n第一是提升数据库产品的可用性，通过巡检、监控、预案、故障跟踪等对故障进行事前防范、事中及时处理、事后复盘总结进行全流程闭环；第二是提升研发效能，研发自助使用数据库，提供变更检测、优化诊断等功能，减少人工沟通流程，项目变更规范流程清晰，提升研发效率；第三是提升数据安全性，通过权限管控、密码管控、数据加密、数据脱敏、操作审计、备份加密等一系列手段全方位地保障数据安全性；第四是降低数据库和存储产品的运营成本，首先通过自动化的流程减少 DBA 的重复工作，提高人效，其次通过服务编排和资源调度，提升数据库和存储服务的资源使用效率，持续降低运营成本。 \n\n通过几年时间的建设，以上工作取得了一些进展，其中每月数以千计的需求工单，90% 以上研发同学可以自助完成，服务可用性最近几年都维持在 4 个 9 以上，平台对 6 种数据库产品和存储服务的平台化支持达到了 85% 以上，而且做到了统一能力的全数据库场景覆盖，比如数据变更，我们支持 MySQL、ElastiSearch、MongoDB、TiDB 的变更前语句审查，变更数据备份，变更操作一键回滚，变更记录审计追踪等。\n\n### DTS\n\n\n\n\n\nvivo 的 DTS 服务是基于自身业务需求完全自研的数据传输服务，主要提供 RDBMS、NoSQL、OLAP 等数据源之间的数据交互。集数据迁移、订阅、同步、备份的一体化服务，从功能上来看，主要有三个特性：第一是同步链路的稳定性和数据可靠性保障，通过结合各个数据源产品的自身特性可以做到数据不重不丢，给业务提供 99.99% 的服务可用性保障；第二是功能层面支持异构的多种数据库类型，除了同步、迁移、订阅等这些通用功能外，我们还支持变更数据的集中化存储和检索；第三是故障容灾层面，支持节点级别故障容灾，可以做到同步链路秒级恢复，也支持断点续传，可以有效地解决因硬件、网络等异常导致的传输中断问题。\n\n### MySQL 2.0\n\n\n\n\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\n\n\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\n\n\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\n\n\n\n我们知道业务运行过程中除了需要对一些结构化或者半结构化的数据有存取需求之外，还有大量的非结构化数据存取需求。vivo 的对象与文件存储服务正是在这样的背景下去建设的。 \n\n对象和文件存储服务使用统一的存储底座，存储空间可以扩展到 EB 级别以上，上层对外暴露的有标准对象存储协议和 POSIX 文件协议，业务可以使用对象存储协议存取文件、图片、视频、软件包等，标准的 POSIX 文件协议可以使得业务像使用本地文件系统一样扩展自己的存取需求，比如 HPC 和 AI 训练场景，可以支撑百亿级别小文件的 GPU 模型训练。针对图片和视频文件，还扩展了一些常用的图片和视频处理能力，比如水印、缩略图、裁剪、截帧、转码等。\n\n前面简单介绍了 vivo 数据库与存储平台的一些产品能力，那么下面我们再来聊聊在平台建设过程中，我们对一些技术方向的探索和思考。\n\n## 三、数据库与存储技术探索和思考\n\n### 运维研发效率提升\n\n\n\n\n\n在平台建设方面，运维研发效率提升是老生常谈的话题，在业内也有很多建设得不错的平台和产品，但是关于如何在数据存储这一层提升运维研发效率相关的探索还比较少。 \n\n我们的理解是：**首先是资源的交付要足够敏捷，要屏蔽足够多的底层技术细节**，为此我们将 IDC 自建的数据库、云数据库、云主机自建数据库进行云上云下的统一管理，提供统一的操作视图，降低运维和研发的使用成本；同时**要提升效率就不能只关注生产环境**，需要使用有效的手段将研发、测试、预发、生产等多种环境统一管控起来，做到体验统一，数据和权限安全隔离。 \n\n此外，我们运用 DevOps 解决方案的思想，将整个平台在逻辑上分为两个域，一个是研发域，一个是运维域。 \n\n在研发域，我们需要思考如何解决研发同学关于数据库和存储产品的效率问题。交付一个数据库实例和支持他们在平台上可以建库建表是远远不够的，很多操作是发生在编码过程中的，比如构造测试数据，编写增删改查的逻辑代码等等。我们希望在这些过程中就和我们的平台发生交互，最大程度的提升研发效率。 \n\n在运维域，目前有一个比较好的衡量指标就是日常运维过程中需要登录服务器操作的次数，现在我们在做的工作就是将运维的动作全部标准化、自动化，并且未来有一些操作可以智能化。 \n\n在研发和运维交互的部分，我们的建设目标是减少交互，流程中参与的人越少效率就越高，让系统来做决策，实现的方案是做自助化。 \n\n### 数据安全管理\n\n\n\n\n\n安全无小事，为此我们将数据库安全和数据安全的部分单独拿出来进行规划和设计，基本的原则就是权责分明。数据库体系涉及到账号密码等，我们联合 SDK 团队共同研发了密码加密传输使用方案，数据库的密码对研发、运维而言都是密文，在项目的配置文件中依然是密文，使用时对接公司的密钥管理系统进行解密。 \n\n针对数据的部分，我们联合安全团队对敏感数据做了自动标注识别，分类分级，对敏感数据的查询、导出、变更上做了严格的管控，比如权限管控、权限升级、通过数字水印技术进行使用追踪，通过事后的审计可以追溯到谁在什么时刻查看了什么数据。针对敏感数据我们也做了透明加解密操作，落盘到存储介质的数据是经过加密存储的。 \n\n同理，备份的数据和日志也做了加密存储，这些是目前我们做的事情，未来在安全上我们还有很多的工作要做。\n\n### 数据变更管理\n\n\n\n\n\n针对数据变更的场景，我们关注的主要有两点： \n\n第一是数据变更本身会不会影响已有的业务，为此我们建设了不锁表结构、不锁表数据的变更能力，针对上线前、上线中、上线后三个环节设置三道防线。杜绝一些不好的 SQL 或者 Query 流入到生产环境，针对变更过程中或者变更结束后如果想回滚，我们也做了一键回滚方案。 \n\n第二是变更效率问题，针对多个环境、多个集群我们提供了一键同步数据变更方案，同时为了更好地提升用户体验，我们也提供了 GUI 的库表设计平台。有了这些基础之后，我们将整个场景的能力全部开放给研发同学，现在研发同学可以 24 小时自助进行数据变更操作，极大地提升了变更效率。 \n\n### 数据存储成本管控\n\n\n\n关于成本我们主要从四个方面进行管理： \n\n第一是预算的管控，资源去物理化，业务以资源为粒度进行预算提报，在预算管控层面对服务器的消耗进行预测和不断的修正，保证水位的健康。 \n\n第二是数据库服务的部署，这块我们经历了几个阶段，最早期是单机单实例，浪费了很多资源，后面发展为标准化套餐部署，同一类型的存储资源不同的套餐混合，通过算法的优化不断的提升资源的使用效率。 \n\n第三是不同属性资源的混合部署，比如数据库的代理层和对象存储的数据节点混合部署，这两种资源一个是 CPU 型的，一个是存储型的，正好可以互补，再往后发展的下一个阶段应该是云原生存储计算分离，还在探索中。 \n\n第四是服务部署之后还需要不断的关注运行中的状况，对容量做巡检和预警，对集群及时的做升降配操作，保障整个运行状态有序。同时需要关注业务运行状态，及时回收下线数据存储集群，减少僵尸集群的存在。 \n\n成本部分还有一个重点就是硬件资源的迭代，这里就不做展开了。 \n\n### 对象与文件储存建设与思考\n\n\n\n\n\n对象与文件存储这块我们主要关注的有两点： \n\n第一是成本，关于成本这块我们在数据冗余策略这块使用了 EC，并且做了跨 IDC 的 EC，单个 IDC 全部故障也不会影响我们的数据可靠性。我们还引入了高密度大容量存储服务器，尽可能多地提升单机架存储密度，需要注意的是服务器采购之后的运行成本也不可忽视，依然有很大的优化空间。我们还提供了数据无损和透明压缩的能力和生命周期管理的能力，及时清理过期数据和对冷数据进行归档。通过多种手段持续降低存储成本。 \n\n第二是性能，关于性能这块我们提供了桶&对象粒度底层存储引擎 IO 隔离，通过引入一些开源组件如 alluxio 等提供了服务端+客户端缓存，提升热点数据读取性能，在底层存储引擎我们引入了 opencas 和 IO_URING 技术，进一步提升整机的磁盘 IO 吞吐。\n\n以上就是我们目前在建设的能力的一些探索和思考，最后再来看下我们未来的规划。\n\n## 四、数据库与存储平台规划\n\n\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":"近些年，由于互联网的快速发展以及线上需求的爆发，**直播在国内已经成为一个非常成熟的商业模式**。在娱乐、教育、办公等场景中涌现出许多优秀的视频直播产品。随着国内市场竞争日益白热化，加之企业出海渐成趋势，越来越多的直播公司选择走出去，寻找新的海外直播市场，借鉴国内成熟的产品、运营以及商业模式，让全球的用户都用上中国人创造的产品，LiveMe 便是成功的出海直播产品之一。\n\nLiveMe 是一个全球直播和社交平台，于 2016 年 4 月推出。LiveMe 的产品功能包括 H2H、多人聊天、虚拟形象直播、蹦迪房等，它使用户能够随时随地直播、并观看其他精彩的直播以及与世界各地的朋友进行视频聊天。**目前 LiveMe 已在全球积累了超过 1 亿用户和超过 300 万的主播。它已成为美国最受欢迎的社交应用程序之一，并已在 200 多个国家和地区推出。**\n\n## 业务痛点\n\n与其他行业出海一样，直播产品的出海也面临着许多全球化挑战。如各地的合规监管、本地化运营、持续创新、政治文化差异等，都为直播产品出海带来巨大挑战。**而在出海的过程中，底层的技术能力帮助 LiveMe 在成本节约、用户增长、金融风控、提升研发效率等方面不断实现精细化运营与业务创新。**\n\n经过了多年的沉淀，LiveMe 在业务上已经形成了线上微服务主导，线下计算中心主导的技术架构。线上业务是通过 Go 语言开发的一套微服务架构，每个服务根据不同业务特性具有自己独立的存储。线下业务是由数据研发团队来维护，通过 sqoop 和 MySQL Binlog 同步等方式从数据库层面抓取数据到数据仓库，完成一系列业务相关的支持。\n\n这套业务架构中线上业务主要面临着以下痛点：\n\n第一，虽然完成了微服务分库的设计，每个服务都有自己独立的数据库，**但是每个业务中又存在很多业务上的大表**，都存在 MySQL 分表的现象。在典型的分表场景中，数据库表会按照用户的 UID 尾号经过 MD5 后分到 256 张表，但是日积月累后又需要再根据时间日期做一个垂直的分表，导致数据库表无法完成聚合查询，再加上跨时间段的分表需求，很多场景无法满足线上需求。\n\n第二，**对于分析型业务数据而言，需要保证数据的实时性，并保留数据细节**。实时的数据分析，可以在业务上更快做出决策，例如在一些活动运营场景中，业务团队需要快速从各个数据维度来分组统计观察活动效果；在金融相关风控业务中，需要根据各个维度快速聚合来判断各项数据是否达到风控模型的阈值。如果使用离线计算的方式，数据的实时性根本无法得到保证；此外，经过离线计算或者实时计算过的数据，如果用户反馈数据有问题，需要查看数据的细节也很难实现。\n\n第三，各种精细化运营需求，例如推荐、个性化运营等场景不断增加，**对于数据的实时要求越来越高**。因此，LiveMe 急需一种更简单，同时让线上线下业务做好平衡的方案。\n\n此时，如果 LiveMe 继续选择大数据技术栈解决痛点就会面临以下挑战：1）大数据技术栈的架构非常复杂，中间件过多；2）需要额外的技术栈学习成本，比如如果使用数据同步，就需要 sqoop、scala、kafka 等中间件，会大幅增加整个业务的复杂性；3）希望线上业务以及架构非常简单，能够简化到普通开发人员只要能够 CRUD（增加(Create)、读取(Read)、更新(Update)和删除(Delete)） 数据库就可以上手开发。\n\n## 为什么选择 TiDB ？\n\n基于以上业务挑战，**LiveMe 经过一系列技术选型后最终选择了 TiDB 数据库**。TiDB 的以下特性可以帮助 LiveMe 很好的应对挑战：\n\n1. TiDB 的性能大于等于 MySQL ；\n\n2. TiDB 的 HTAP 特性能够解决线上大表的问题，在后台或者一些实时分析场景中，其 OLAP 分析能力能够保证实时数据报表；\n\n3. TiDB 引入的 MPP 架构分析能力，使得 OLAP 查询速度非常快，这也是 OLAP 数据库架构上的技术方向；\n\n4. TiDB 团队有着完善和专业的技术支持，在过程中可以帮助 LiveMe 解决很多问题，在线上大规模使用后也没有后顾之忧。\n\n## 如何利用 TiDB 实现实时聚合查询\n\n鉴于 LiveMe 的微服务架构，如果将数据源全部替换，工程量大且不能一蹴而就，因此就需要一种兼容性的方案，在保证线上业务不受影响的同时也能使用 TiDB 的特性来解决 LiveMe 的业务痛点。因此，对于需要聚合查询的业务， LiveMe 通过消息队列广播的方式，在业务层订阅相关事件再补充业务侧需要的宽表信息写入 TiDB，基于 TiFlash 就可以做到实时的运营报表。业务开发人员只需要编写对应的 SQL 查询，就可以轻松完成需求。**没有了复杂的 ETL 过程，大大简化了开发流程。**\n\n**对于业务数据， LiveMe 使用 AWS SQS 消息队列**，相比 Kafka 的优势在于每条数据都是原子性的，每条数据都可以用来做幂等重试，来保证数据的最终一致性。目前，这套技术方案已经支撑了 LiveMe 的活动运营和金融风控等多个业务场景，满足了 LiveMe 对于线上大量数据实时聚合查询的要求。\n\n\n\n## 如何使用 TiDB 简化技术架构\n\nLiveMe 有一个类似朋友圈功能的场景，这个业务中存在两个技术难点：**第一是对于数据的无限量增长存储如何实现扩容；第二是数据的冷热分离，这又涉及到数据成本的问题。**\n\n以用户发 Twitter 的场景举例：如果用户发了一条 Twitter，它会写入到自己所有的关注列表，比如有 100 个粉丝，就写入 100 条，如果有 10 万粉丝就需要写入 10 万条数据，这是一个典型的写扩散场景。这个场景带来的效果是数据爆炸半径非常大，如果某流量网红发一条 Twitter ，数据写入量会非常大，因此需要一个能够接近于无限扩容的存储机制才可以实现这个场景。\n\n\n\nTwitter 的技术实现\n\nTwitter 是通过维护一个 redis-cluster 来解决 feed 分发的存储。LiveMe 的技术团队也想到使用这种技术架构，技术团队经过选型考虑使用 codis 集群来做存储，但通过对成本的考量，认为这个方案是不可行的，大量的 feed 冷数据存储在 codis 这样的内存密集型数据库中，成本非常高。因此，技术团队面临的挑战是如何用低成本的方式去实现一个写扩散的场景。\n\n\n\nTwitter 的解决方案\n\n基于 TiDB 解决方案，LiveMe 技术团队在上述写扩散场景中，把扩散写入的部分替换成了 TiDB，使用一张数据库表来存储所有 feed 的写入关系，比如用户有 100 万粉丝，就在数据库里插入 100 万条数据。**基于 TiDB 的分布式数据库特性，帮助 LiveMe 简单高效地解决了数据增长扩容问题。**\n\n基于此技术架构，技术团队简化了一个典型的 redis 缓存设计问题，热数据放在 redis 中，用 mget 来获取。冷数据放在 TiDB 中，用 select in 查询，这样做数据冷热区分就非常容易，甚至可以实现一个简单的布隆过滤器来了解哪些数据在热数据，哪些数据在冷数据里。以此减少无效数据的回源，更高效获取数据。\n\nLiveMe 的朋友圈功能基于 TiDB 的分布式存储特性进行技术改造后，**feed 表从 2021 年中旬上线至今已经达到数十亿数据写入**，现在的数据量单表 39 亿条。因为这些数据是永久保留不会删除的，所以该数据也会一直增长。\n\n## 未来规划\n\n未来， LiveMe 将会继续尝试 TiDB 在更多业务中，一方面会做数据库管理开发；另一方面将对于强事务依赖交易型的业务尝试使用 TiDB，为直播电商场景做技术储备。","author":"张龙","category":4,"customUrl":"tidb-in-liveme","fillInMethod":"writeDirectly","id":449,"summary":"LiveMe 是一个全球直播和社交平台，目前已在全球积累了超过 1 亿用户和超过 300 万的主播，面临新的业务挑战，LiveMe 经过一系列技术选型后最终选择了 TiDB 数据库。","tags":["TiDB","技术出海"],"title":"LiveMe x TiDB丨单表数据量 39 亿条，简化架构新体验"}},{"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\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\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\n\n我们可以通过这些 Trace 信息去追踪这一笔交易涉及的不同服务、不同的子系统之间调用的详细信息，比如说源端、目标端调用的耗时，调用返回的状态，有没有报错等，这是微观层面的追踪。微服务场景下，服务数量非常多，种类也多，调用关系很复杂，我们怎样从全局的角度了解整个微服务的架构是否健康，是否存在问题，比如有没有流量突增，有没有系统性的问题？所以衍生出了服务治理这个系统。服务治理的要求是能够实时知道微服务整个调用关系的信息，所以我们就把 TiKV 存储的 Trace 信息实时同步到 TiFlash，同时我们预定义很多的度量指标，比如实时分析整个服务的健康度，整个子系统调用的次数排名，是否存在流量突增，耗时的变化等。\n\n基于这些度量指标，我们再通过决策引擎去得到一个最优的治理策略。我们的决策可以分成两部分，第一个是自动决策，通过度量指标直接把需要去治理的动作下发到生产环境的微服务的应用或者容器。第二个是辅助决策，生成一个决策值，人工进行判断，根据经验或者根据一些特定的阈值触发相应的策略，再下发到真正的生产环境。我们看到整个系统形成了一个闭环，从生产环境产生消息，到分析消息，再通过度量产生决策，最后又反向去影响我们的生产环境，让整个微服务的精细化管理越来越好，这是我们在 HTAP 选型的一个场景。\n\n当然我们也遇到了一些挑战，第一是集群非常大，第二是在这么大规模的集群下还要跟 TiFlash 结合。所以我们形成了相关的实践经验。首先，集群很大，如何稳定运行？我们从几个方面进行入手：第一，TiDB 的组件 PD 可能会存在个别单点瓶颈，所以我们把大集群 Region 总数控制在一定范围；第二，控制单个 TiKV 实例的 Region 数量，对于一些历史归档或者相对冷的数据，心跳维持不用太频繁，所以我们开启了 Hibernate Region 功能，减轻单个实例可能产生的瓶颈问题。\n\n\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\n\n因为写入同样也会触发分裂，同样也会需要 Remove Peer 功能，这时候就产生了互斥。我们在整个实践中发现，各个调度参数之间可能会相互影响，所以需要找到参数之间的相互干扰的因素，再找到一个最佳的平衡点。最后，我们通过右下角这张图对相关参数进行了深入研究和调试，最终实现了超大集群下 TiKV+TiFlash 的稳定联动，可以确保 20 万+ 每秒的持续写入并不会产生明显抖动。\n\nTiFlash 实际上也是一个 OLAP 的引擎，在很多场景里会拿 TiFlash 去跟一些 OLAP 传统组件去对比，比如拿 TiFlash 跟 Clickhouse 去对比。我们在真正的业务场景中发现用户的需求场景很多，对应的技术要求也不一样，所以细分下来发现像有些分析场景，可能对于实时性要求很高，有些场景可能计算量很大，维度很固定，希望做一些预计算，还有一些交互式的，希望灵活和快速返回，所以我们通过细分业务场景以及对应的技术要求的细化，最终找到了不同的 OLAP 组件所对应的场景和最佳实践。\n\n\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\n\n## 基于微信机器人的 TiDB 数据库运维优化\n\n目前 TiDB 在微众银行的集群规模越来越大，从 2021 年开始的 20 多个集群到现在已经接近 60 个集群，数据的总容量也接近 800T，同样使用 TiDB DM 的量也非常大，应用的业务类型也特别多，包括贷款、存款、理财、科技管理、基础科技，应用的场景包括联机、批量、归档、管理平台等等。在数据增长快，应用规模大，业务场景类型多，重要性高的情况下，同时还要符合合规要求，因此在 TiDB 大规模分布式数据库的运维上，我们也进行了很多探索，比如怎样更高效地运维和使用分布式数据库。\n\n\n\n我们有三个方面的总结：第一，做标准化的 SOP，对于业务接入，日常变更和故障处理，我们都需要一些标准化的流程；第二，这么大规模的集群量，我们希望运维工作可以 Work Smart，也就是更加高效地处理遇到的问题，我们引进了微信机器人，把集群诊断、巡检这些工作都自动化了；最后，开源有一个最大的好处就是能看到源码，所以我们希望可以从源码侧去解析，这样有些疑难问题我们可以更加深入，更加快捷地去发现问题，同时提供更理想的优化方案。\n\n接下来看看我们基于微信机器人的 Smart 运维工作。可以看到，我们的 DBA 只需要通过微信，通过一部手机就可以对一些场景进行快速处理。以往，在银行，对于遇到一些生产的告警，我们需要去登陆 VPN，输入 Token，在其他的内部系统又要做二次登录校验，整个过程耗时比较长。而针对一些比较紧急的告警，登录到服务器，已经过去了不少时间，所以我们希望针对一些特定合适的告警场景，快速地去响应，所以我们基于微信机器人的方式进行了优化，分成几个层次。\n\n\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\n\n最后做一个简单的展望，我们希望未来继续沉淀 HTAP 技术在金融场景的探索和落地经验，形成金融场景的最佳实践。同时，我们希望未来能够把内部的一些运维工具，比如 DM 自动化校验平台、自动诊断平台等开源出去，能够和大家进行深入的交流和共创。 \n最后，随着国产化的进程，我们也会推动 TiDB 在国产 ARM 服务器上的进一步扩大使用。\n\n\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"]}