简介：本文将会从阿里巴巴双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，请大家继续关注！
原文链接
本文为阿里云原创内容，未经容许不得转载。