本文根据微众银行资深数据库架构师黄蔚在 DevCon 2022 上的分享整理，主要叙述了微众银行关于 HTAP 架构的探究和实践状况，以及进步大规划分布式数据库运维功率的经历。
内容将从四个方面展开：HTAP 技能的演进进程、微众银行在 HTAP 技能的选型以及实践、在大规划分布式数据库主动化运维的优化实践、TiDB 在微众银行的未来规划。
TiDB HTAP 架构的演进
咱们知道一项新技能的呈现和开展，其背面往往有两个原因：一是由于事务驱动，寻求客户的极致体会；二便是技能的开展，经过一些新技能的立异和运用，进一步下降硬件本钱、开发本钱或全体维护本钱。HTAP 其实也是在这样布景下诞生的。
咱们首要来看传统的数据架构有哪些瓶颈或许有哪些优化点。咱们知道，按照负载类型划分，体系一般分为 OLTP 和 OLAP，OLTP 在金融场景一般是包含像买卖、转账、营销等，面向的是客户，寻求的是极致体会，假如有问题很或许就会影响用户体会，乃至构成用户丢失。所以 OLTP 要求的是耗时短，而且处理的数据量相对小。
而咱们还要根据这些用户产生的数据做商业剖析、数据挖掘，根据剖析结果来进行决议计划，比方进行战略方向上的调整。所以衍生出来了 OLAP，通常专门用来做一些剖析。而 OLTP 和 OLAP 的负载不一样，也就意味着技能底座是不一样的，所以一般是将两者分开，这个时分就需求经过 ETL 的方法把数据传输到 OLAP 上做剖析，可是这个传输的进程在时效性上会比较差，一起架构也会比较杂乱，但优势是这套架构十分老练，尤其是自从大数据三驾马车的论文出来之后，大数据的整个生态变得愈加老练，运用也更广泛。
跟着事务的开展，事务关于时效性的要求越来越高，比方期望实时对用户进行客群圈选、画像剖析、实时洞悉，或许做金融场景的风控，这时分就诞生出了 Kappa 架构。
Kappa 架构的中心便是流式处理， OLTP 体系产生的 CDC 或许 Message 经过 Kafka 消息行列传输到常见的流处理技能组件比方 Flink、Spark Streaming 进行处理，终究到 Serving DB 来寄存这些数据并实时对外供给服务。而关于 Serving DB 的要求首要是扩展性要好，一起受限于流式处理暂时无法彻底取代批处理，那就意味着在 Serving DB 上还需求做必定的 OLAP 剖析。其实 TiDB 在这个架构里也有必定的运用量，比方 Flink 要寄存一些中间态数据或许进行维表相关，关于 DB 也需求必定的扩展性，此刻 TiDB 的扩展能力正好可以满意。
这个架构的中心特点便是准实时处理，而且在工程实践上十分丰富。而这个架构的下风是组件许多，学习的本钱相对高，而且整个链路很长，意味着在数据共同性的保证上会比较困难。所以，咱们就在想能不能在一个数据库一起去承载 OLTP 跟 OLAP 事务呢？不需求去做额外的数据同步，不需求去学习额外的组件，所以就衍生出了 HTAP 数据库的概念。
它的架构很简练，可是完结技能难度也十分高。虽然这几年 HTAP 十分火，可是工程实践相对较少，像传统的 Oracle 12c In-Memory Column Store、Google Spanner PAX 其实都算是行列混存的架构，TiDB 也有自己的 HTAP 完结。HTAP 架构的难度是怎样做资源阻隔，怎样做共同性保证，怎么做 OLTP 和 OLAP 的负载平衡等等。
接下来谈谈 TiDB HTAP 架构的演进，咱们怎么根据事务需求去做选型以及对应的实践状况。
图中，咱们看到 TiKV 为了让数据均衡，简单做分布式调度，会把数据分红许多小片，也便是 Region，Region 在 TiKV 这一侧是强同步的，咱们可以看到绿色线条是实线。而 TiFlash 的立异点便是没有打破原来 TiKV 的架构，而是新增一个列式引擎，直接经过 Raft Log 的方法同步到 TiFlash，由于列式存储天然关于 OLAP 场景是比较友好的，所以还要做一个行转列的处理。咱们可以看到 TiKV 到 TiFlash 的同步线是一条虚线，意味着这是一个异步进程。那么又怎么保证在 TiFlash 上的查询是强共同的呢？这儿其实做了一些优化，每次收到读取恳求，TiFlash 中的 Region 副本会向 Leader 副本建议进度校正（一个十分轻的 RPC 恳求），只有当进度保证至少所包含读取恳求时刻戳所覆盖的数据之后才呼应读取，所以假如有同步延迟，就会需求等候，乃至有或许在 TiFlash 的查询会超时，在实践中咱们发现有些场景关于 OLAP 的共同性要求并没那么高，而在 6.0 版别的 TiFlash 供给了 Fast Scan 这个功用，下降共同性的保证，但可以进步读写速度。
咱们看到 TiDB HTAP 架构阻隔性十分好，由于列存跟行存彻底独立，一起 TiFlash 凭借了 MPP 并行核算框架，而且是根据 Clickhouse 底座，所以天然具有向量化核算引擎的一些 OLAP 特性。一起，TiDB HTAP 架构立异性地经过 Raft Log 来同步保证了共同性，一起也可以经过 Fast Scan 功用来下降共同性，进步读写速度。进一步的，TiDB 的产品迭代十分快，有一些特性是咱们也十分期待，比方说低本钱的硬盘支撑、更精确的优化器等。
微服务分布式链路追寻和微服务办理场景下的 HTAP 实践
在银行场景下咱们怎样选型 HTAP 技能呢？微众银行的根底架构是根据 DCN 的分布式架构，也便是单元化，一笔简单的买卖或许涉及到几十乃至上百个微服务在背面支撑，所以微服务的调用量很大。那么咱们怎样快速地进行定位反常问题呢？比方说一笔买卖或许一个体系假如有反常，怎样快速地知道哪里出问题了？这儿就需求凭借可观测的方法。可观测一般都会谈到 Trace、Metrics、Log 这三个基本元素。
根据微众银行 DCN 的分布式架构，假如两个用户分属不同的 DCN，要进行交互比方转账，就需求经过 RMB 可靠消息总线来进行交互。咱们为了保存完整全量的微服务调用联系，会旁路地消费一份服务之间的调用消息，把这些信息存到 TiDB。为什么存到 TiDB 呢？咱们行内买卖量特别大，TiDB 正好能供给扩展性，一起 TiDB 支撑的并发量也很大，每秒达到了 20 万+ 这样一个量级。
咱们可以经过这些 Trace 信息去追寻这一笔买卖涉及的不同服务、不同的子体系之间调用的详细信息，比方说源端、目标端调用的耗时，调用回来的状态，有没有报错等，这是微观层面的追寻。微服务场景下，服务数量十分多，品种也多，调用联系很杂乱，咱们怎样从全局的视点了解整个微服务的架构是否健康，是否存在问题，比方有没有流量突增，有没有体系性的问题？所以衍生出了服务办理这个体系。服务办理的要求是可以实时知道微服务整个调用联系的信息，所以咱们就把 TiKV 存储的 Trace 信息实时同步到 TiFlash，一起咱们预界说许多的衡量目标，比方实时剖析整个服务的健康度，整个子体系调用的次数排名，是否存在流量突增，耗时的改变等。
根据这些衡量目标，咱们再经过决议计划引擎去得到一个最优的办理战略。咱们的决议计划可以分红两部分，榜首个是主动决议计划，经过衡量目标直接把需求去办理的动作下发到出产环境的微服务的运用或许容器。第二个是辅助决议计划，生成一个决议计划值，人工进行判别，根据经历或许根据一些特定的阈值触发相应的战略，再下发到真实的出产环境。咱们看到整个体系构成了一个闭环，从出产环境产生消息，到剖析消息，再经过衡量产生决议计划，终究又反向去影响咱们的出产环境，让整个微服务的精细化办理越来越好，这是咱们在 HTAP 选型的一个场景。
当然咱们也遇到了一些应战，榜首是集群十分大，第二是在这么大规划的集群下还要跟 TiFlash 结合。所以咱们构成了相关的实践经历。首要，集群很大，怎么安稳运转？咱们从几个方面进行入手：榜首，TiDB 的组件 PD 或许会存在个别单点瓶颈，所以咱们把大集群 Region 总数操控在必定规划；第二，操控单个 TiKV 实例的 Region 数量，关于一些前史归档或许相对冷的数据，心跳维持不必太频繁，所以咱们开启了 Hibernate Region 功用，减轻单个实例或许产生的瓶颈问题。
其次，TiDB 架构中 OLTP 的负载运用的是 TiKV，OLTP 往往面临的是客户，直接联系到用户体会的问题，咱们以为在极端状况下 TiFlash 有反常的时分，不期望它影响到 TiKV，因而咱们建立了一个快速熔断机制，意图是在 TiFlash 悉数反常的状况下尽或许对 TiKV 的影响最小。咱们还在超大集群 POC 时做了许多暴力验证，比方说把 TiFlash 悉数直接关停，比方制造一些网络拥塞，IO、CPU 资源跑满等。在验证进程中咱们也发现了许多问题，也相应都做了修复，咱们以为未来在超大集群的运用上，HTAP 架构的健壮性会越来越好。
刚刚说到，TiKV 跟 TiFlash 需求联动，集群很大，又要做数据的生命周期办理。TiKV 是做链路追寻，咱们期望它的数据保留的时刻比较长，比方 7 天，7 天之外的就删掉，TiFlash 做的是实时剖析，咱们期望保存数据的天数少一点，比方 3 天，这两边的清理战略是不一样的。这时分就会有一个问题，TiKV 跟 TiFlash 虽然物理上是阻隔的，但 PD 调度是共用的，很或许会产生相互影响。举个简单例子，咱们在超大集群下往往需求去提前规避写入热点问题进行提前打散。咱们发现在打散的时分会影响正常写入，发现本质原因是打散动作首要会在一个 Region 上进行打散，终究再会去 scatter 均衡，而均衡背面有 Remove Peer 动作，便是把本地的 Peer 删掉，再调到其他节点上，而 Remove Peer 会有资源的占用。
由于写入相同也会触发分裂，相同也会需求 Remove Peer 功用，这时分就产生了互斥。咱们在整个实践中发现，各个调度参数之间或许会相互影响，所以需求找到参数之间的相互搅扰的要素，再找到一个最佳的平衡点。终究，咱们经过右下角这张图对相关参数进行了深化研究和调试，终究完结了超大集群下 TiKV+TiFlash 的安稳联动，可以保证 20 万+ 每秒的持续写入并不会产生明显颤动。
TiFlash 实际上也是一个 OLAP 的引擎，在许多场景里会拿 TiFlash 去跟一些 OLAP 传统组件去比照，比方拿 TiFlash 跟 Clickhouse 去比照。咱们在真实的事务场景中发现用户的需求场景许多，对应的技能要求也不一样，所以细分下来发现像有些剖析场景，或许关于实时性要求很高，有些场景或许核算量很大，维度很固定，期望做一些预核算，还有一些交互式的，期望灵敏和快速回来，所以咱们经过细分事务场景以及对应的技能要求的细化，终究找到了不同的 OLAP 组件所对应的场景和最佳实践。
咱们也对 TiFlash 和 Clickhouse 做了一个简单比照，可以很明显地看到 Clickhouse 在硬件本钱以及单表的性能上有很大优势，而 TiFlash 在运维本钱、开发本钱以及实时更新有不错的优势。所以咱们以为 OLAP 组件没有银弹，咱们可以经过这种组合的方法，经过在各个 OLAP组件之上增加一个中间层来统一来供给服务给事务，让事务不必感知详细的引擎或组件，对用户来说，只需求去满意事务需求就好了。
TiDB HTAP 的场景引荐有哪些呢？榜首个肯定是 HTAP 型的买卖体系，OLTP 是必定要用的，一起咱们要结合 OLTP 把数据同步到 TiFlash 进行实时剖析，这是榜首种最经典的场景。第二种，咱们知道 TiDB 有 DM 工具，可以把多个 MySQL 的数据快速地同步会聚到一个 TiDB 集群，多源会聚到 TiDB 后，TiDB 可以是一个数据中台、一个数据仓库或许是一个数据集市，再结合 TiFlash 的剖析能力，快速地进行事务剖析或事务监控，所以多源数据的会聚和实时剖析是第二个场景。第三个场景，便是上面说到的，把 TiDB 作为一个单纯的 OLAP 组件运用，当然本钱会较高，由于假如只运用用 TiFlash，还是需求从 TiKV 进行数据同步。可是 TiDB 的优点便是开发本钱比较低。
根据微信机器人的 TiDB 数据库运维优化
现在 TiDB 在微众银行的集群规划越来越大，从 2021 年开端的 20 多个集群到现在现已接近 60 个集群，数据的总容量也接近 800T，相同运用 TiDB DM 的量也十分大，运用的事务类型也特别多，包含贷款、存款、理财、科技办理、根底科技，运用的场景包含联机、批量、归档、办理平台等等。在数据增加快，运用规划大，事务场景类型多，重要性高的状况下，一起还要符合合规要求，因而在 TiDB 大规划分布式数据库的运维上，咱们也进行了许多探究，比方怎样更高效地运维和运用分布式数据库。
咱们有三个方面的总结：榜首，做标准化的 SOP，关于事务接入，日常改变和故障处理，咱们都需求一些标准化的流程；第二，这么大规划的集群量，咱们期望运维作业可以 Work Smart，也便是愈加高效地处理遇到的问题，咱们引进了微信机器人，把集群确诊、巡检这些作业都主动化了；终究，开源有一个最大的优点便是能看到源码，所以咱们期望可以从源码侧去解析，这样有些疑难问题咱们可以愈加深化，愈加快捷地去发现问题，一起供给更理想的优化计划。
接下来看看咱们根据微信机器人的 Smart 运维作业。可以看到，咱们的 DBA 只需求经过微信，经过一部手机就可以对一些场景进行快速处理。以往，在银行，关于遇到一些出产的告警，咱们需求去登陆 VPN，输入 Token，在其他的内部体系又要做二次登录校验，整个进程耗时比较长。而针对一些比较紧急的告警，登录到服务器，现已过去了不少时刻，所以咱们期望针对一些特定合适的告警场景，快速地去呼应，所以咱们根据微信机器人的方法进行了优化，分红几个层次。
榜首，经过 TiDB 自带的 TiUP 工具来做一些数据收集，包含集群信息和主机的 CMDB 信息，把这些信息全量入库。每天守时去把收集的信息进行剖析巡检，输出一个报告。第二，在主动确诊这块，咱们在 TiDB 上会遇到一些常见高频的问题，比方内存高、OOM、热点、慢查询、履行计划突变等，咱们把这些问题处理睬构成一个知识库，而且生成对应的剖析引擎，假如触发了对应告警，就会主动地触发根因剖析，而且生成引荐根因。在生成引荐根因的时分，咱们还会模仿爬虫在 Grafana 上把最近的半小时的 Overview，包含一些监控视图、实例信息截图生成一个图片，结合刚才的引荐根因一起推送到咱们的手机微信上。DBA 立马就可以看到告警产生或许的原因是什么，而且咱们还可以快速地进行履行，处理相应问题。
咱们在微信机器人上供给了一个交互的快速履行方法。比方可以对一些慢查询进行 Kill，比方 restart TiDB Server，当然条件必定是安全合规，咱们对一些高危指令会增加预审批流程，一起咱们会预界说一些白名单的指令。终究可以看到，咱们从巡检、数据收集、主动确诊以及交互式的快速履行四个维度来全体进步数据库的运维功率。
这儿是 Smart 运维的效果图，可以看到像 tiup display、show processlist，以及 kill 慢查询，restart server 等一系列动作，都可以经过一部手机去完结，咱们内部称为微信机器人的运维方法，这种方法进步了数据库的运维功率。
终究做一个简单的展望，咱们期望未来继续沉积 HTAP 技能在金融场景的探究和落地经历，构成金融场景的最佳实践。一起，咱们期望未来可以把内部的一些运维工具，比方 DM 主动化校验平台、主动确诊平台等开源出去，可以和咱们进行深化的沟通和共创。 终究，跟着国产化的进程，咱们也会推进 TiDB 在国产 ARM 服务器上的进一步扩大运用。
