简介：本文将会从阿里巴巴双 11 场景登程，剖析实时数仓面临的高可用挑战以及针对性设计。
2021 年阿里巴巴双 11 完满落下为帷幕，对消费者来说是一场购物盛宴，对背地的业务撑持技术人来说，更是一场年度大考。在这场大考中，一站式实时数仓 Hologres 以每秒 11.2 亿条的高速写入，和每秒 1.1 亿次的查问峰值（蕴含点查和 OLAP 查问），交出了称心的答卷，稳固高效地撑持了阿里巴巴双 11 外围利用场景。
这是一站式实时数仓 Hologres 诞生的第 5 年，也是撑持阿里巴巴双 11 外围场景的第 4 年。这也证实实时数仓技术曾经开始从幕后走到台前，撑持起更多的在线生产零碎，并在性能、稳定性、高可用性等方面禁受住了严苛的考验。
本文将会从阿里巴巴双 11 场景登程，剖析实时数仓面临的高可用挑战以及针对性设计。
可用性、老本、复杂度的综合挑战
传统上，实时数仓（数据仓库）是一个非生产零碎，次要面向外部客户，撑持实时大屏、实时报表等场景。用户对它的稳定性、可用性的要求相较于订单、购物车这样的生产零碎要弱很多，只有能持续应用，即便实时数仓短暂不可用或者有显著稳定，影响也不是很大。
而随着实时数仓开始对外提供服务，业务对系统的可用性、稳定性都提出了更高更严苛的要求。特地是如果提供的是 to C 的服务，那要求就更高了。
举几个 Hologres 被用在阿里生产零碎中的例子：
- 阿里的 CCO（Customer Chief Officer）通过阿里小蜜来向 C 端消费者提供查问服务。
- 阿里妈妈为广告主（B 端）提供广告圈选服务。
- 达摩院无人车包裹配送服务。
- …
这些零碎的最大特点是他们都是生产零碎，如果零碎不稳固或者不可用，那么影响会十分大。
具体到双 11 这样的极其场景，在流量洪峰下要做好生产高服务质量、达到高可用对任何零碎都是一件极具挑战的事。传统分布式系统是通过正本和隔离机制来实现可用性和一致性，而要实现生产可用的高可用也须要面临肯定的取舍和挑战：
- 面向流量洪峰时的可扩大能力
- 零碎因意外或者故障宕机时的疾速恢复能力
- 主备切换时的数据一致性问题
- 保障高性能的同时资源隔离能力
- 多正本隔离带来的资源老本问题
…….
通过本文，咱们将会介绍，一站式实时数仓 Hologers 的高可用架构设计和实际，从而达到低成本、可扩大、高可用的生产服务能力。
Hologres 高可用架构设计
1. 计算存储拆散架构进步零碎扩大灵活性
实时数仓技术不论是面向剖析型场景还是服务型场景，所解决的数据量级、场景复杂度都远比传统数据库要高，尤其是互联网、电商等行业，流动促销多，大促和日常所解决的流量齐全不一样，这就十分考验零碎的资源程度扩大能力。
在传统的分布式系统中，罕用的存储计算架构有如下三种：
- Shared Disk/Storage（共享存储）：有一个分布式的存储集群，每个计算节点像拜访单机数据一样拜访这个共享存储上的数据；这种架构的存储层能够比拟不便的扩大，然而计算节点须要引入分布式协调机制保证数据同步和一致性，因而计算节点的可扩展性有一个下限。
- Shared Nothing：每个计算节点本人挂载存储，一个节点只能解决一个分片的数据，节点之间能够通信，最终有一个汇总节点把数据进行汇总。这种架构能比拟不便的扩大，然而它的毛病是节点 failover 须要期待数据加载实现之后能力提供服务；并且存储和计算须要同时扩容，不够灵便。扩容后，有漫长的数据 rebalance 过程。
- Storage Disaggregation（存储计算拆散架构）：存储和 Shared Storage 相似，有一个分布式的共享存储集群，计算层解决数据的模式和 Shared Nothing 相似，数据是分片的，每个 shard 只解决本人所在分片的数据，每个计算节点还能够有本地缓存。
这种存储计算拆散的架构益处在于：
- 一致性解决简略：计算层只须要保障同一时刻只有一个计算节点写入同一分片的数据。
- 扩展性更灵便：计算和存储能够离开扩大，计算不够扩计算节点，存储不够扩存储节点。这样在大促等场景上会非常灵活。计算资源不够了，马上扩容计算就好了，不须要像 Shared Nothing 那样做耗时耗力的数据 rebalance；也不会呈现 Shared Nothing 那样，呈现单机的存储容量瓶颈。
- 计算节点故障复原快：计算节点产生 failover 之后，数据能够按需从分布式的共享存储异步拉取。因而，failover 的速度十分快。
在架构上，Hologres 采纳的是第 3 种存储计算拆散架构，Hologres 的存储应用的是阿里自研的 Pangu 分布式文件系统（相似 HDFS）。用户能够依据业务需要进行弹性扩缩容，轻松应答在线零碎不同的流量峰值。
2. 多状态 Replication 解决数据读写拆散
Replication（复制）是实现高可用的必备技术，通过不同状态的 Replication 设计，疾速将数据在节点间、集群间进行复制，实现隔离和 SLA 保障。
Hologers 同时反对了逻辑 Replication 和物理 Replication，上面将会针对 Hologres 的 Replication 性能做具体介绍。
1）基于 Binlog 的逻辑 Replication
相似于传统数据库 MySQL 中的 Binlog 概念，在 Hologres 中，Binlog 用来记录数据库中表数据的批改记录，比方 Insert/Delete/Update 的操作，次要利用场景包含：
数据实时复制、同步场景，典型的场景就是把一张 Hologres 的行存表复制成一张列存表，行存反对点查点写，列存反对多维分析型需要，同步的逻辑通常由 Flink 撑持。这个是 Hologres 在 V1.1 版本之前的一种典型用法。在 Hologres 1.1 中反对了行列共存表后，能够一张表满足行存和列存两种需要。
实现事件的全链路驱动，通过 Flink 生产 Hologres Binlog，实现事件驱动的加工开发，实现 ODS 向 DWD，DWD 向 DWS 等的全实时加工作业。
在 Hologres 中，逻辑 Replication 依赖 Binlog 实现，产生变更的表作为 Publication 公布变更事件，加工逻辑解决后写入 Subscription 侧。用户能够订阅一个表的 Binlog 转成 Record，写入到另外一张表里，实现逻辑上的复制性能。这种做法能够人造做到不同 Workload 的隔离，然而它有两个问题：它是一个最终一致性的模型，很难做到强统一；另一个是它耗费了两份资源，应用两份存储，并且写入链路的资源也得有两份。
因而 Hologres 也实现了物理 Replication。
2）物理 Replication
在 Hologres 中，物理 Replication 是基于 WAL log 的复制，咱们能够把存储引擎看成是状态机，WAL log 是这个状态机的输出。当咱们要对某个 Shard 做 Replication 的时候，咱们会起一个 Follower Shard 读取以后最新的 WAL log 进行回放（replay），同时 Leader Shard 又有新的 WAL 产生，Follower Shard 会从 Leader Shard 订阅最新的 WAL，一直的回放，从而达到和 Leader Shard 统一的状态。如果须要保障 Follower Shard 上的可见性，咱们能够在读申请中加一个强统一的选项，问一下 Follower Shard 和 Leader Shard 之间 WAL log 的回放差距，等补齐差距后再返回查问后果。
Follower Shard 回放 WAL log 的过程中，对 WAL log 中指向的数据文件能够进行复制。也能够只进行援用，其中复制的形式称为非共享存储模式，援用的形式称为共享存储模式。
基于此，Hologres 实现了 3 种状态的物理 Replication：
1. 单实例多正本：一个实例内采纳 Shard 级多正本机制，可用来实现跨过程高可用，读写拆散，同时因为正本可动静减少，能轻松反对高并发的读。
2. 多实例读写拆散：不同的实例之间共享一份存储，实现计算跨机房高可用，通常用于读写拆散场景，并反对高并发的读场景
3. 多实例容灾：多个实例之间不共享存储，实现计算和存储服务的跨机房高可用，反对读写拆散，读的高并发，版本的热降级和存储系统的迁徙等性能
- 单实例多正本
Hologres 数据分片单元是 Shard，Shard 能够有多个正本，然而存储只有一份。平时，查问流量能够被各个正本均摊，从而实现高 QPS。当某一个正本 failover 当前，流量能够疾速被导到其余正本。并且 Shard 的故障复原十分轻量，只需回放局部 WAL，没有数据的复制。基于单实例内多正本机制，能够很不便的实现计算的可扩展性，并疾速解决物理机单机 failover 问题。
利用场景：
单实例内的查问高可用：当一个 Shard 所在 Worker 产生故障时，能够通过前端阶段的重试操作，将申请重定向到正本 Shard 所在 Worker，从而利用异样无感知。
通过负载均摊，实现更高吞吐：同一份数据由多个 Shard 独特对外提供服务，不同的查问路由到不同的 Shard 所在节点，从而实现负载在多个 Shard 间的平衡，QPS 能够显著晋升，对于每次查问只拜访确定 Shard 的场景（例如点查场景）晋升显著。
机器故障疾速 Failover：从 Hologres V1.1 版本开始，采纳全新复原机制，Shard 复原速度在一分钟以内，可用性进一步加强。
- 多实例读写拆散
和单实例内多正本的 Replication 相比，跨实例的 Replication 实现了 Meta 的物理复制。
Hologres 在 V1.1 版本，反对了共享存储的多实例部署计划。在该计划中，主实例具备残缺能力，数据可读可写，权限、零碎参数可配置，而子实例处于只读状态，所有的变更都通过主实例实现，实例之间共享一份数据存储，实例间数据异步实时同步。
利用场景：
1. 读写拆散：这个计划实现了残缺的读写拆散性能，保障不同业务场景的 SLA，在高吞吐的数据写入和简单的架构作业、OLAP、AdHoc 查问、线上服务等场景中，负载之间物理上齐全隔离，不会因写入产生查问的抖动。
2. 多类型负载细粒度资源分配：一个主实例能够配置多个只读从实例，实例之间能够依据业务状况配置不同规格，例如应用 256Core 作为写入和加工实例，512Core 作为 OLAP 只读实例，128Core 作为在线 Serving 实例，32Core 作为开发测试实例。
- 多实例跨城容灾
多实例非共享存储的 Replication，能够了解为传统意义上的灾备性能，反对容灾，异地多活，并实现读写拆散和读的高并发，同样也能够基于多个实例实现读的高可用。除此之外，还能够进行版本热降级，存储系统迁徙。
利用场景：
- 灾备：在不同的 Region，部署有不同的存储集群（Pangu），数据在同步后会别离保留在不同的存储集群上，当产生某个 Region 不可用时，异地备份的实例能够持续对外提供服务。
- 集群迁徙：机房的容量空间总是无限，常常会产生因为不可控起因，须要将实例从某个机房迁徙到其余机房，甚至从某个 Region 迁徙到其余 Region，用户心愿迁徙过程尽可能是对业务无感的。因而能够通过 Replication 机制，实现实例状态在集群间的迁徙。
- 热降级：热降级过程中，须要业务服务能力不中断，属于高速公路上换发动机的需要，因而须要零碎具备某种相似“滚动”降级的能力。通过 Replication 机制，能够先克隆出一个实例，在新的实例上实现软件版本的降级，再将相干的网络路由等配置接入到新的实例，从而实现无需停机的热降级。
3. 调度零碎进步节点 failover 疾速恢复能力
分布式环境 failover 是不可避免的，当 failover 产生时，须要高效的检测，疾速的复原，这就是调度的领域。
一个 Hologres 实例有多个 HoloWorker，当某一个 HoloWorker 发生意外、宕机、failover 时，通过 Hologres 的调度零碎，能够疾速检测到节点异样，并将异样节点的 Service 如 Frontend、Coordinator、Shard 疾速调度到另外一个衰弱的 HoloWorker，同时 SLB 将会将流量导流到新的衰弱 Frontend 上。
调度分为计算单元的调度和流量的调度：
1）计算单元的调度
计算单元的调度分为 Pod 的调度、Pod 内子过程调度以及 Actor 的调度
- Pod 的调度利用了 K8S 的能力，Hologres 中被 K8S 调度的单元是 HoloWorker；
- Pod 内子过程调度以及 Actor 的调度是 Hologres 散布式调度模块 HoloFlow 提供的能力。
- Hologres 中两种类型的计算单元须要被调度，一类是以子过程模式提供 Service，例如 Frontend；另一类是以 Actor 模式提供的 Service，例如某一个分片的数据服务 Shard。HoloFlow 提供了这两类服务的衰弱检测以及调度的能力。
2）流量的调度
流量的调度又分为内部流量和外部流量的调度。
- 内部流量即入口流量，这部分调度是 SLB 提供的能力，Hologres 会定时监测 Frontend 的衰弱状态，一旦某个 Frontend 不衰弱了，流量就会从 SLB 上摘除。
- 外部流量 Hologres 提供了外部的衰弱检测和服务发现机制，例如 StoreMaster 提供了 Shard 的衰弱检测和服务发现机制，一旦某个 Shard 不衰弱，Coordinator 就会把流量导到这个 Shard 衰弱的 Replica 上。
通过 Hologres 的调度零碎，实现了节点故障、Failover 的疾速检测以及主动调度恢复能力，满足业务的稳定性需要，进步零碎可用性。
4. 多层次隔离轻松应答不同业务 SLA
随着实时数仓在生产零碎越来越宽泛的利用，不同的业务也有着不同的 SLA 诉求，比方双 11 时，老板和经营对交易数据的查问需要比拟高，物流端又心愿物流订单能实时高效刷新，开发又心愿数据能疾速写入，不要影响前面的数据查问和剖析 ….
具体到 Hologres，一个实例反对不同的 Workload，包含点查点写，批量导入，交互式剖析等。那么不同 Workload 的 SLA 须要被保障，例如批量导入不能影响交互式剖析的延时，交互式剖析的申请不能影响实时写入的实效性等；Hologres 也反对多租户同时应用，不同租户之间也不能相互影响；
以上形容的场景都是隔离的领域，相对来说隔离级别越高，老本越大，资源利用率越低。在过程外部实现低成本可用的隔离是一个很有技术挑战的事件。
Hologres 实现了多个档次的隔离伎俩。如下图是下面介绍的 Replication（复制）和隔离的关系，复制实质上是在不同的机器 / 容器中服务同一份数据（或其复本），所以实质上是一种物理隔离。在物理隔离外，Hologres 还反对资源组隔离、调度组和（SchedulingGroup）隔离，用户能够在老本和 SLA 上做 tradeoff，满足不同用户对隔离的需要。
1）物理机和容器隔离
在物理机和容器隔离上，Hologers 是通过 k8s 来部署，利用 k8s 的 Node Selector/Affinity 以及 Taints/Tolerations 等性能，能够比拟不便的实现实例和实例间容器的隔离。对于一些对 SLA 要求十分高的客户，咱们还能够对机器独自打标，只容许某一个实例的容器调度到打标的机器上，从而实现机器级别的隔离，避免其余实例的烦扰。
2）资源组隔离
在 Hologres 中，多租户的隔离需要是通过资源组来实现的。Hologres 的资源组隔离实质上是线程级别的隔离。实例内的 Worker 能够依照 CPU、内存、IO 划分为不同的资源组。不同的用户退出到不同的资源组，限度每个用户应用的资源下限，以保障用户之间的作业互不影响。
例如资源组（1）有 50% 的资源，资源组（2）有 30% 的资源，资源组（3）有 20% 的资源。咱们把用户 A 绑定的资源组（一）上，用户 B 绑定在资源组（2）上，用户 C 和 D 绑定到资源组（3）上。这样用户 A,B.C 发动的申请就会别离调度到不同的资源组。
通过资源组的隔离，实现实例内的资源隔离。这种隔离的长处是可能在一个实例内实现不同用户的隔离，保障用户间的作业不相互影响。这种隔离是一种软隔离，在隔离成果上是不如基于 replication 的物理隔离的。所以资源组隔离更适宜不同用户的 OLAP 查问隔离等场景，而基于 replication 的物理隔离更适宜线上服务。
3）SchedulingGroup 隔离
通常来说，2）中的线程级别隔离模型会有如下问题：
- 在操作系统层面：线程切换是一个不小的开销。为了把因为期待 IO 而闲暇的 CPU 利用起来，须要把很多 CPU 节约在线程切换上。测试发现，重大的时候线程切换能节约掉一半以上的 CPU；
- 线程的数目很难把握：不同的 query、不同的数据、不同的 cache 命中率，被 IO 阻塞的可能性差别会十分大，以至于须要的线程数差异十分大。这种状况下，应用固定线程数目的线程池是很好受的。线程多了会引起多余的切换，加剧切换的开销；线程少了则可能没法把闲暇的 CPU 都利用起来。而相比于线程切换，线程的创立和销毁会带来更大的开销，所以想要通过动态创建线程来放弃失当的线程数，这也是不太可能的；
现实的计划是能有一种轻量级的调度单元，性能相似于线程，然而创立 / 销毁和调度 / 切换的开销要小得多。这样的话：
- 咱们能够依据业务逻辑的须要，创立足够多的“线程”去并发应用 CPU，而不用放心切换的开销大、或者 CPU 用不满；
- 当须要业务逻辑须要应用 CPU 时，间接依据并发度的须要去创立 N 个这样的“线程”，用完即销毁。这样就能使业务逻辑灵便管制工作的并行度，不用受制于底层框架；
依据下面的设计理念，Hologres 在自研调度零碎 HOS 中，通过一个轻量级调度单元 EC 来实现。
SchedulingGroup 隔离利用了 HOS EC 调度的能力，同一个 Query 有多个 EC 执行，这些 EC 能够被归类到一个 SchedulingGroup，不同的 SchedulingGroup 能够用偏心的策略瓜分工夫片。
SchedulingGroup 隔离保障了当零碎中同时跑一个大 Query（剖析型）和一个小 Query（点查）的时候，小 Query 不至于因为抢不到 CPU 被大 Query block 住。SchedulingGroup 隔离实质上是协程级别的隔离，是 Hologres 的外围竞争力之一。
Hologres 高可用在双 11 的落地实际
Hologers 的高可用技术往年也稳固反对了阿里巴巴双 11 的外围业务场景，上面来做一一介绍。
1）业务双联路 + 读写实例拆散（DT 团队实际）
DT 大淘系数据是阿里巴巴团体典型的数据中台，负责天猫、淘宝、聚划算等业务大促及日常行业看数需要，通过天猫 / 淘宝营销流动剖析产品，反对决策层和小二在大促期间进行数据分析及决策。
随着业务增长和产品的一直迭代，数据团队也面临更简单的剖析需要，技术团队在保障数据实时性、准确性的同时，还要面临更高压力的写入，在保障整体数据链路的稳定性和整体产品的高可用上面临更严格的考验。
在高可用场景上，往年 DT 引入了 Hologres 的读写拆散能力，并联合全链路的主备双链路，在升高单库出问题概率的同时构建异地主备容灾，建设产品外围指标的“复活甲”，通过秒级切换的高可用容灾计划，高吞吐写入和灵便查问互不烦扰，剖析查问 QPS 增长 80% 的同时，查问抖动显著缩小，让业务领有底气和信念去应答随时可能呈现的不可控危险，为整个产品和业务决策分析提供稳固反对，
2）双链路容灾 + 读写拆散（CCO 团队实际）
CCO 是阿里巴巴团体的客户体验事业部，反对的场景包含服务资源调度、实时数据监控等。“客户第一”价值观落地的组织保障，是整个经济体客户体验的神经网络，也是触达消费者和商家的最火线。
随着业务的倒退，以及行业的整体业务趋势，以及相应商家和消费者们更加实时和稳固的服务申请。去年是业务上做了双链路写入和存储冗余来保障高可用。往年双 11 应用了 Hologres 原生的 只读实例 和 容灾 高可用计划下掉了业务的双链路，省去备用数据链路上实时工作开发保护、数据比对的人力投入，缩小链路切换时的数据不统一等，整体开发人力老本缩小 200 人日，环比去年升高 50% 以上；缩小了 100+ 用于实时重保的备份链路作业，缩小实时计算资源 2000CU。
总结
在过来一年，Hologres 引入了多正本、资源隔离、读写拆散等多种能力，并在往年阿里巴巴外围利用场景中失去了很好的利用，实现了生产高可用。
随着实时数仓技术被生产零碎的宽泛应用，业务对高可用的要求也越来也严苛。咱们心愿通过分享 Hologres 的高可用设计原理和利用实际，与行业互通有无，独特为社会的高度倒退添砖加瓦。
Hologres 是阿里云自研的一站式实时数仓，这个云原生零碎交融了实时服务和剖析大数据的场景，全面兼容 PostgreSQL 协定并与大数据生态无缝买通，能用同一套数据架构同时反对实时写入实时查问以及实时离线联邦剖析。它的呈现简化了业务的架构，为业务提供实时决策的能力，让大数据施展出更大的商业价值。从阿里团体诞生到云上商业化，随着业务的倒退和技术的演进，Hologres 也在继续一直优化核心技术竞争力，为了让大家更加理解 Hologres，咱们打算继续推出 Hologres 底层技术原理揭秘系列，从高性能存储引擎到高效率查问引擎，高吞吐写入到高 QPS 查问等，全方位解读 Hologres，请大家继续关注！
原文链接
本文为阿里云原创内容，未经容许不得转载。