从双11看实时数仓Hologres高可用设计与实践

2021年阿里巴巴双11完美落下为帷幕，对消费者来说是一场购物盛宴，对背后的业务支撑技术人来说，更是一场年度大考。在这场大考中，一站式实时数仓Hologres以每秒11.2亿条的高速写入，和每秒1.1亿次的查询峰值（包含点查和OLAP查询），交出了满意的答卷，稳定高效地支撑了阿里巴巴双11核心应用场景。

这是一站式实时数仓Hologres诞生的第5年，也是支撑阿里巴巴双11核心场景的第4年。这也证明实时数仓技术已经开始从幕后走到台前，支撑起更多的在线生产系统，并在性能、稳定性、高可用性等方面经受住了严苛的考验。
​
本文将会从阿里巴巴双11场景出发，分析实时数仓面临的高可用挑战以及针对性设计。

可用性、成本、复杂度的综合挑战

传统上，实时数仓（数据仓库）是一个非生产系统，主要面向内部客户，支撑实时大屏、实时报表等场景。用户对它的稳定性、可用性的要求相较于订单、购物车这样的生产系统要弱很多，只要能继续使用，即使实时数仓短暂不可用或者有明显波动，影响也不是很大。
​
而随着实时数仓开始对外提供服务，业务对系统的可用性、稳定性都提出了更高更严苛的要求。特别是如果提供的是to C的服务，那要求就更高了。

举几个Hologres被用在阿里生产系统中的例子：

1. 阿里的CCO（Customer Chief Officer）通过阿里小蜜来向C端消费者提供查询服务。
2. 阿里妈妈为广告主（B端）提供广告圈选服务。
3. 达摩院无人车包裹配送服务。
   …
   这些系统的最大特点是他们都是生产系统，如果系统不稳定或者不可用，那么影响会非常大。

具体到双11这样的极端场景，在流量洪峰下要做好生产高服务质量、达到高可用对任何系统都是一件极具挑战的事。传统分布式系统是通过副本和隔离机制来实现可用性和一致性，而要实现生产可用的高可用也需要面临一定的取舍和挑战：

• 面向流量洪峰时的可扩展能力
• 系统因意外或者故障宕机时的快速恢复能力
• 主备切换时的数据一致性问题
• 保证高性能的同时资源隔离能力
• 多副本隔离带来的资源成本问题
• …

通过本文，我们将会介绍，一站式实时数仓Hologers的高可用架构设计和实践，从而达到低成本、可扩展、高可用的生产服务能力。

Hologres高可用架构设计

1. 计算存储分离架构提高系统扩展灵活性

实时数仓技术不管是面向分析型场景还是服务型场景，所处理的数据量级、场景复杂度都远比传统数据库要高，尤其是互联网、电商等行业，活动促销多，大促和日常所处理的流量完全不一样，这就非常考验系统的资源水平扩展能力。
​
在传统的分布式系统中，常用的存储计算架构有如下三种：

1. Shared Disk/Storage （共享存储）：有一个分布式的存储集群，每个计算节点像访问单机数据一样访问这个共享存储上的数据；这种架构的存储层可以比较方便的扩展，但是计算节点需要引入分布式协调机制保证数据同步和一致性，因此计算节点的可扩展性有一个上限。
2. Shared Nothing：每个计算节点自己挂载存储，一个节点只能处理一个分片的数据，节点之间可以通信，最终有一个汇总节点把数据进行汇总。这种架构能比较方便的扩展，但是它的缺点是节点failover需要等待数据加载完成之后才能提供服务；并且存储和计算需要同时扩容，不够灵活。扩容后，有漫长的数据rebalance过程。
3. Storage Disaggregation（存储计算分离架构）：存储和Shared Storage类似，有一个分布式的共享存储集群，计算层处理数据的模式和Shared Nothing类似，数据是分片的，每个shard只处理自己所在分片的数据，每个计算节点还可以有本地缓存。
   

这种存储计算分离的架构好处在于：

• 一致性处理简单：计算层只需要保证同一时刻只有一个计算节点写入同一分片的数据。
• 扩展性更灵活：计算和存储可以分开扩展，计算不够扩计算节点，存储不够扩存储节点。这样在大促等场景上会非常灵活。计算资源不够了，马上扩容计算就好了，不需要像Shared Nothing那样做耗时耗力的数据rebalance；也不会出现Shared Nothing那样，出现单机的存储容量瓶颈。
• 计算节点故障恢复快：计算节点发生failover之后，数据可以按需从分布式的共享存储异步拉取。因此，failover的速度非常快。

在架构上，Hologres采用的是第3种存储计算分离架构，Hologres的存储使用的是阿里自研的Pangu分布式文件系统（类似HDFS）。用户可以根据业务需求进行弹性扩缩容，轻松应对在线系统不同的流量峰值。

2.多形态Replicati