2021年，阿里巴巴的双11完美落下帷幕。对于消费者来说，这将是一场购物盛宴，而对于背后的业务支撑技术人员来说，则是一场年度大考。在本次大考中，一站式实时数仓Hologres以每秒11.2亿条的高速写入速率、每秒1.1亿次的查询峰值（含点检）交出了一份满意的答卷和OLAP查询）。高效支撑阿里巴巴双11核心应用场景。今年是一站式实时数仓Hologres诞生的第五个年头，也是支撑阿里巴巴双11核心场景的第四个年头。这也证明实时数仓技术已经开始从幕后走向台前，支持更多的线上生产系统，在性能、稳定性、高可用等方面经受住了严峻考验。本文将从阿里巴巴的双11场景出发，分析实时数仓面临的高可用挑战和针对性设计。1.易用性、成本、复杂性的综合挑战传统上，实时数仓（datawarehouse）是一个非生产系统，主要面向内部客户，支持实时大屏、实时报表等场景。用户对其稳定性和易用性的要求远弱于订单、购物车等生产系统。只要能继续使用，即使实时数仓暂时不可用或波动较大，影响也不会很大。随着实时数仓开始对外提供服务，业务对系统的可用性和稳定性提出了更高更严苛的要求。特别是如果提供的服务是给C的，要求就更高了。举几个阿里生产系统中使用Hologres的例子：阿里的CCO（CustomerChiefOfficer）通过阿里小米为C端消费者提供查询服务。阿里妈妈为广告主（B端）提供广告选品服务。达摩无人车包裹配送服务。...这些系统最大的特点就是都是生产系统。如果系统不稳定或不可用，影响会非常大。具体到双11这样的极端场景，任何一个系统在流量高峰下，要产生高质量的服务，实现高可用，都是极具挑战性的。传统的分布式系统使用副本和隔离机制来实现可用性和一致性。实现生产高可用，也有一定的权衡和挑战：流量高峰的可扩展性当系统因意外或故障宕机时主备倒换时的数据一致性问题，同时保证高性能和资源隔离能力时间。多副本隔离带来的资源成本问题……通过本文，我们将介绍一站式实时数据仓库Hologers的高可用架构设计与实践，从而实现低成本、可扩展、和高可用的生产服务能力。二、Hologres高可用架构设计1、计算存储分离架构，提高系统扩展灵活性实时数仓技术无论是面向分析的场景还是面向服务的场景，处理的数据量级和场景复杂度远高于传统数据库。尤其是在互联网、电商等行业，活动和促销活动较多，大促处理的流量与日常流量完全不同，非常考验系统的资源横向扩展能力。在传统的分布式系统中，常用的存储和计算架构有如下三种：SharedDisk/Storage（共享存储）：有一个分布式存储集群，每个计算节点都像单机一样访问这个共享存储上的数据数据数据；该架构的存储层可以轻松扩展，但计算节点需要引入分布式协调机制来保证数据的同步和一致性，因此计算节点的可扩展性存在上限。SharedNothing：每个计算节点挂载自己的存储。一个节点只能处理一份数据。节点可以相互通信。最后，有一个汇总节点来汇总数据。这种架构易于扩展，缺点是节点故障转移需要等待数据加载完成后才能提供服务；存储和计算需要同时扩展，不够灵活。扩容后，有一个漫长的数据再平衡过程。StorageDisaggregation（存储计算分离架构）：存储类似于SharedStorage，有一个分布式的共享存储集群。计算层的数据处理方式与SharedNothing类似。数据是碎片化的，每个分片只处理自己的碎片。对于数据，每个计算节点也可以有一个本地缓存。这种存储计算分离架构的好处是：一致性处理简单：计算层只需要保证一次只有一个计算节点向同一个分片写入数据。扩展性更灵活：计算和存储可以单独扩展，计算节点不够扩展计算节点，存储不够扩展存储节点。这样在大促等场景下会非常灵活。如果计算资源不够用，可以立即扩容。无需像SharedNothing那样做费时费力的数据rebalance；也不会像SharedNothing那样出现单机存储容量瓶颈。计算节点故障恢复快：计算节点发生故障转移后，可以按需从分布式共享存储中异步拉取数据。因此，故障转移非常快。在架构上，Hologres采用第三种存储计算分离架构。Hologres的存储采用了阿里自研的盘古分布式文件系统（类似HDFS）。用户可根据业务需要灵活扩缩容，轻松应对线上系统不同的流量高峰。2.Multi-formReplication解决了数据读写分离。复制（replication）是实现高可用性必不可少的技术。通过不同形式的Replication设计，可以在节点和集群之间快速复制数据，实现隔离和SLA保证。Hologers同时支持逻辑复制和物理复制。下面将详细介绍Hologres的Replication功能。基于Binlog的LogicalReplication类似于传统数据库MySQL中的Binlog概念。在Hologres中，Binlog用于记录数据库中表数据的修改记录，如Insert/Delete/Update操作。主要应用场景包括：实时数据复制和同步场景。一个典型的场景是将一个Hologres行存储表复制到一个列存储表中。行存支持checkpoint写入，列存支持多维分析需求。同步逻辑通常由Flink支持。这是HologresV1.1之前的典型用法。Hologres1.1支持行列共存表后，一张表可以同时满足行列存储需求。实现事件的全链路驱动，通过Flink消费HologresBinlog，实现事件驱动的处理和开发，完成从ODS到DWD、从DWD到DWS的全时处理操作。在Hologres中，逻辑复制依赖于Binlog来实现，将发生变化的表发布为一个Publication来发布变化事件，经过逻辑处理后写入到Subscription端。用户可以订阅一张表的Binlog，将其转化为一条Record写入另一张表，实现逻辑复制功能。这种方式可以很自然地隔离不同的工作负载，但是它有两个问题：它是一个最终的一致性模型，很难做到强一致性；另一个是它消耗两个资源并使用两个存储。并且必须有两份资源写入链接。因此，Hologres也实现了物理Replication。物理复制在Hologres中，物理复制是基于WAL日志复制。我们可以把存储引擎看成一个状态机，WAL日志就是这个状态机的输入。当我们要复制某个分片时，我们会设置一个followershard读取最新的WAL日志进行回放（replay），同时leadershard会产生新的WAL，followershard订阅最新来自leadershard的WAL不断回放，达到和LeaderShard一样的状态。如果需要保证在followershard上的可见性，可以在读请求中加入强一致性选项，询问followershard和leadershard之间的WAL日志回放差距，填补差距后返回查询结果.FollowerShard在回放WAL日志时，可以复制WAL日志中指向的数据文件。也可以只做引用，其中复制的方式称为非共享存储方式，引用的方式称为共享存储方式。基于此，Hologres实现了三种形式的物理复制：1）。单实例多副本：在一个实例中采用了shard级别的多副本机制，可以实现跨进程高可用，读写分离，并且由于副本可以动态增加，可以轻松支持高并发阅读。2).多实例读写分离：不同实例共享一个存储，实现跨机房的高可用。通常用于读写分离场景，支持高并发读场景。3).多实例容灾：多个实例不共享存储，实现跨机房计算和存储服务的高可用，支持读写分离、读高并发、版本热升级、存储系统迁移。单实例多副本Hologres的数据分片单元是Shard，Shard可以有多个副本，但只有一个副本用于存储。通常，查询流量可以由各个副本分担，从而达到高QPS。当一个副本发生故障转移时，流量可以快速定向到其他副本。而且shard的故障恢复很轻，只需要replay部分WAL，不需要数据复制。基于单实例内的多副本机制，轻松实现计算的可扩展性，快速解决物理机的单机故障转移问题。应用场景：单实例内查询高可用：当一个shard所在的worker发生故障时，可以通过前端阶段的retry操作将请求重定向到replicashard所在的worker，从而实现应用程序不知道异常。通过负载分担，实现更高的吞吐量：多个分片共同为同一个数据提供服务，将不同的查询路由到不同分片所在的节点，从而实现多个分片之间的负载均衡，可以显着提升QPS。查询仅访问某些分片的场景（例如枚举场景）得到显着改善。机器故障快速Failover：从HologresV1.1开始，采用全新的恢复机制，分片恢复速度在一分钟以内，易用性进一步增强。与多实例读写分离、单实例多副本复制相比，跨实例复制实现了Meta的物理复制。在V1.1版本中，Hologres支持共享存储的多实例部署方案。在该方案中，主实例具有完整的能力，可以读写数据，可以配置权限和系统参数，而子实例处于只读状态。所有的改变都是通过主实例完成的，实例之间共享一个数据存储。实例之间的数据异步实时同步。应用场景：1）。读写分离：该方案实现了完整的读写分离功能，保障了不同业务场景的SLA，适用于高吞吐数据写入和复杂架构操作、OLAP、AdHoc查询、在线服务等。场景下，负载在物理上是完全隔离的，不会因为写入而产生查询抖动。2).多类型负载细粒度资源分配：一个主实例可以配置多个只读从实例，实例之间可以根据业务情况配置不同的规格，例如256Core作为写处理实例，其中512Core作为OLAP只读实例，128Core作为在线Serving实例，32Core作为开发测试实例。多实例跨城容灾多实例非共享存储复制可以理解为传统意义上的容灾功能，支持容灾，异地多活，实现读写分离和高并发阅读。也可以基于多个实例实现读取的高可用。此外，还可以进行版本热升级和存储系统迁移。应用场景：容灾：在不同的Region部署不同的存储集群（盘古），数据同步后会存储在不同的存储集群中。当一个Region不可用时，远程备份实例可以继续对外提供服务。集群迁移：机房的容量空间总是有限的。经常会因为不可控的原因，需要将实例从一个机房迁移到另一个机房，甚至从一个Region迁移到另一个Region。用户希望迁移过程尽可能对业务友好。感觉不好。因此，实例状态可以通过Replication机制在集群之间迁移。热升级：在热升级过程中，业务服务能力需要不间断，这是高速公路换机的需求。因此，系统需要具备类似于“滚动”升级的能力。通过Replication机制，可以先克隆一个实例，在新实例上完成软件版本升级，然后将相关网络路由等配置接入新实例，从而实现不停机热升级。3提高节点故障转移快速恢复能力的调度系统分布式环境下故障转移是不可避免的。当故障转移发生时，需要高效的检测和快速的恢复，这就是调度的范畴。一个Hologres实例有多个HoloWorker。当一个HoloWorker发生事故、宕机或故障转移时，Hologres调度系统可以快速检测到节点异常，将异常节点的Frontend、Coordinator、Shard等服务快速调度到另一个健康的HoloWorker，SLB将分流到新的健康前端的流量。调度分为计算单元调度和流量调度：1）计算单元调度计算单元调度分为Pod调度、Pod子进程调度、Actor调度Pod调度使用了K8S的能力，Hologres是通过K8S调度的单元是全息工作者；Pod中的子进程调度和Actor调度是Hologres分布式调度模块HoloFlow提供的能力。Hologres中有两类计算单元需要调度。一种是以子流程的方式提供服务，比如Frontend；另一种是以actor模式提供服务，比如shardeddataserviceshard。HoloFlow为这两类服务提供了健康检测和调度能力。2）流调度流调度又分为外部流调度和内部流调度。外部流量是入口流量。这部分调度是SLB提供的能力。Hologres会定期监控Frontend的健康状态。一旦Frontend变得不健康，流量将从SLB中移除。内部流量Hologres提供内部健康检测和服务发现机制。例如，StoreMaster提供了分片健康检测和服务发现机制。一旦分片不健康，协调器会将流量引导到分片的健康副本。通过Hologres的调度系统，实现了对节点故障和Failover的快速检测以及自动调度和恢复的能力，满足了业务的稳定性需求，提高了系统的可用性。4多级隔离，轻松应对不同业务SLA随着实时数仓在生产系统中的应用越来越广泛，不同业务也有不同的SLA需求。比如双11期间，老板和运营对交易数据的查询要求比较高，物流方也希望能够实时高效的刷新物流订单，开发希望数据能够快速写入，不影响后续的数据查询和分析。具体来说，对于Hologres，一个实例支持不同的工作负载，包括枚举和写入。批量导入、交互式分析等。那么需要保证不同工作负载的SLA。比如批量导入不能影响交互分析的延迟，交互分析的请求不能影响实时写入的有效性。Hologres也支持多个租户同时使用，不同的租户不能相互影响；上述场景都是孤立的类别。相对来说，隔离级别越高，成本越大，资源利用率越低。在一个过程中实现低成本和可用的隔离是一个非常技术性的挑战。Hologres实现了多级隔离。下图展示了上面介绍的Replication（复制）和隔离的关系。复制本质上是为不同机器/容器中的相同数据（或其副本）提供服务，因此它本质上是一种物理隔离。除了物理隔离，Hologres还支持资源组隔离、调度组和（SchedulingGroup）隔离。用户可以权衡成本和SLA，以满足不同用户的隔离需求。1）物理机和容器隔离在物理机和容器隔离上，Hologers是通过k8s部署的，利用k8s的NodeSelector/Affinity和Taints/Tolerations功能，更方便的实现实例间和实例间容器的隔离。对于一些SLA要求非常高的客户，我们也可以单独标记机器，只允许将某个实例的容器派发到标记的机器上，达到机器级别的隔离，防止其他实例的干扰。2）资源组隔离在Hologres中，多租户隔离需求是通过资源组来实现的。Hologres的资源组隔离本质上是线程级别的隔离。一个实例中的Worker可以根据CPU、内存、IO划分为不同的资源组。不同的用户加入不同的资源组，限制每个用户使用资源的上限，保证用户之间的作业互不影响。例如，资源组(1)有50%的资源，资源组(2)有30%的资源，资源组(3)有20%的资源。我们将用户A绑定到资源组(1)，将用户B绑定到资源组(2)，将用户C和D绑定到资源组(3)。这样，用户A、B、C发起的请求就会被分别派发到不同的资源组。实例内的资源隔离是通过资源组的隔离来实现的。这种隔离的好处是可以在一个实例内隔离不同的用户，保证用户之间的作业不会相互影响。这种隔离是一种软隔离，其隔离效果不如基于复制的物理隔离。因此，资源组隔离更适合不同用户的OLAP查询隔离等场景，而基于复制的物理隔离更适合在线业务。3)SchedulingGroupisolation一般来说，2)中的线程级隔离模型存在以下问题：在操作系统层面：线程切换是不小的开销。为了利用因等待IO而空闲的CPU，需要在线程切换上浪费大量的CPU。测试发现，在严重的情况下，线程切换可以浪费一半以上的CPU；线程数很难掌握：不同的查询，不同的数据，不同的缓存命中率，被IO阻塞的可能性会有很大的差异，以至于需要的线程数差异很大。在这种情况下，很难使用线程数固定的线程池。线程过多会造成冗余切换，增加切换的开销；如果线程太少，可能无法利用空闲的CPU。与线程切换相比，线程的创建和销毁会带来更多的开销，因此无法通过动态创建线程来维持合适的线程数；理想的解决方案是有一个轻量级的A级调度单元，其功能类似于线程，但创建/销毁和调度/切换的开销要小得多。这样：我们可以根据业务逻辑的需要创建足够多的“线程”来并发使用CPU，而不用担心切换开销过高或者CPU占用率不够；需要创建N个这样的“线程”，用完就销毁。这样，业务逻辑就可以不受底层框架的约束，灵活控制任务的并行度；Hologres根据上述设计理念，通过自研调度系统HOS中的一个轻量级调度单元EC来实现。SchedulingGroup隔离利用了HOSEC的调度能力。同一个Query可以被多个EC执行。这些EC可以归为一个SchedulingGroup，不同的SchedulingGroup之间可以共享时间片，策略公平。SchedulingGroup隔离保证了当一个大Query（解析型）和一个小Query（枚举校验）同时在系统中运行时，小Query不会因为抢不到CPU而被大Query阻塞。SchedulingGroup隔离本质上是协程层面的隔离，是Hologres的核心竞争力之一。双11的三个Hologres高可用实现。Hologres的高可用技术也稳定支撑了阿里巴巴今年双11的核心业务场景。让我们一一介绍。1业务双链路+读写实例分离（DT团队实践）DT大数据是阿里巴巴集团典型的数据中台，负责天猫、淘宝、聚划算等业务推广及日常行业数据查看需求，通过天猫/淘宝营销活动分析产品，在大促期间，支持决策者和主妇进行数据分析和决策。随着业务的增长和产品的迭代，数据团队也面临着更加复杂的分析需求。在保证数据实时性和准确性的同时，技术团队也面临着更高的写入压力，同时保证整体数据链路的完整性。产品整体的稳定性和高可用性面临更加严苛的考验。在高可用场景，今年DT引入了Hologres的读写分离能力，结合全链路主备双链路，在构建异地主备容灾的同时降低单库故障概率，并建立产品的核心指标。“复活A”，秒级切换的高可用容灾方案，高吞吐写入与灵活查询互不干扰，分析查询QPS提升80%，同时查询抖动显着降低，让业务有信心和信心应对任何时候可能出现的不可控风险，为整个产品的分析和业务决策提供稳定的支持。2双链路容灾+读写分离（CCO团队实践）CCO是阿里巴巴集团客户体验事业部，支持业务资源调度、实时数据监控等场景。贯彻“顾客至上”价值观的组织保障是整个经济体中顾客体验的神经网络，也是触达消费者和商家的第一线。随着业务的发展，以及行业的整体业务趋势，相应的商家和消费者的服务请求更加实时稳定。去年，业务实现了双链路写入和存储冗余，以确保高可用性。今年双11使用独创的Hologres只读实例和容灾高可用方案，掉业务双链路，节省了实时任务开发维护和数据比对备份数据的人力投入链接，减少链接切换的时间。数据不一致等，整体开发人力成本减少200人日，比去年下降50%以上；实时再保险减少100+备份链路操作，实时计算资源减少2000CU。4.总结在过去的一年里，Hologres引入了多副本、资源隔离、读写分离等多项能力，今年在阿里巴巴的核心应用场景中得到了很好的应用，实现了生产高可用。随着实时数仓技术在生产系统中的广泛应用，业务对高可用性的要求也越来越严格。我们希望通过分享Hologres的高可用设计原理和应用实践，与业界交流，共同为社会的高水平发展贡献力量。Hologres是阿里云自研的一站式实时数据仓库。这个云原生系统集成了实时服务和大数据分析场景。全面兼容PostgreSQL协议，无缝对接大数据生态。它可以使用相同的数据架构来支持实时编写实时查询和实时离线联合分析。它的出现简化了业务架构，为业务提供了实时决策的能力，让大数据发挥更大的商业价值。从阿里集团的诞生到云端商业化，随着业务的发展和技术的演进，Hologres也在不断优化核心技术竞争力。我们计划推出一系列揭示Hologres底层技术原理的文章，从高性能存储引擎到高效Query引擎，从高吞吐量写入到高QPS查询等，全面解读Hologres。参考链接：1.2020VLDB论文《Alibaba Hologres: A cloud-Native Service for Hybrid Serving/Analytical Processing》：http://www.vldb.org/pvldb/vol13/p3272-jiang.pdf2.HologresRevealed：首次公开！阿里云原生实时数仓核心技术揭秘：https://developer.aliyun.com/article/7791183，Hologres揭秘：首次揭秘云原生Hologres存储引擎：https://developer.aliyun。com/文章/779284？4、Hologres揭秘：Hologres高效分布式查询引擎：https://developer.aliyun.com/article/784506?5、Hologres揭示：高性能原生加速MaxCompute核心原理：https://developer.aliyun.com/article/784755?6.Hologers揭秘：优化COPY，批量导入性能提升5倍+：https://developer.aliyun.com/article/785001?7、Hologres揭示：如何支持超高QPS在线服务（查看）场景：https://developer.aliyun。com/文章/785647？
