一 可用性、成本、复杂度的综合挑战
阿里的CCO(Customer Chief Officer)通过阿里小蜜来向C端消费者提供查询服务。 阿里妈妈为广告主(B端)提供广告圈选服务。 达摩院无人车包裹配送服务。
面向流量洪峰时的可扩展能力 系统因意外或者故障宕机时的快速恢复能力
主备切换时的数据一致性问题 保证高性能的同时资源隔离能力
多副本隔离带来的资源成本问题 .......
二 Hologres高可用架构设计
1 计算存储分离架构提高系统扩展灵活性
Shared Disk/Storage (共享存储):有一个分布式的存储集群,每个计算节点像访问单机数据一样访问这个共享存储上的数据;这种架构的存储层可以比较方便的扩展,但是计算节点需要引入分布式协调机制保证数据同步和一致性,因此计算节点的可扩展性有一个上限。 Shared Nothing:每个计算节点自己挂载存储,一个节点只能处理一个分片的数据,节点之间可以通信,最终有一个汇总节点把数据进行汇总。这种架构能比较方便的扩展,但是它的缺点是节点failover需要等待数据加载完成之后才能提供服务;并且存储和计算需要同时扩容,不够灵活。扩容后,有漫长的数据rebalance过程。 Storage Disaggregation(存储计算分离架构):存储和Shared Storage类似,有一个分布式的共享存储集群,计算层处理数据的模式和Shared Nothing类似,数据是分片的,每个shard只处理自己所在分片的数据,每个计算节点还可以有本地缓存。
一致性处理简单:计算层只需要保证同一时刻只有一个计算节点写入同一分片的数据。
扩展性更灵活:计算和存储可以分开扩展,计算不够扩计算节点,存储不够扩存储节点。这样在大促等场景上会非常灵活。计算资源不够了,马上扩容计算就好了,不需要像Shared Nothing那样做耗时耗力的数据rebalance;也不会出现Shared Nothing那样,出现单机的存储容量瓶颈。
计算节点故障恢复快:计算节点发生failover之后,数据可以按需从分布式的共享存储异步拉取。因此,failover的速度非常快。
2 多形态Replication解决数据读写分离
基于Binlog的逻辑Replication
数据实时复制、同步场景,典型的场景就是把一张Hologres的行存表复制成一张列存表,行存支持点查点写,列存支持多维分析型需求,同步的逻辑通常由Flink支撑。这个是Hologres在V1.1版本之前的一种典型用法。在Hologres 1.1中支持了行列共存表后,可以一张表满足行存和列存两种需求。 实现事件的全链路驱动,通过Flink消费Hologres Binlog,实现事件驱动的加工开发,完成ODS向DWD,DWD向DWS等的全实时加工作业。
物理Replication
单实例多副本
单实例内的查询高可用:当一个Shard所在Worker发生故障时,可以通过前端阶段的重试操作,将请求重定向到副本Shard所在Worker,从而应用异常无感知。 通过负载均摊,实现更高吞吐:同一份数据由多个Shard共同对外提供服务,不同的查询路由到不同的Shard所在节点,从而实现负载在多个Shard间的均衡,QPS可以显著提升,对于每次查询只访问确定Shard的场景(例如点查场景)提升明显。 机器故障快速Failover:从Hologres V1.1版本开始,采用全新恢复机制,Shard恢复速度在一分钟以内,可用性进一步增强。
多实例读写分离
多实例跨城容灾
灾备:在不同的Region,部署有不同的存储集群(Pangu),数据在同步后会分别保存在不同的存储集群上,当发生某个Region不可用时,异地备份的实例可以继续对外提供服务。 集群迁移:机房的容量空间总是有限,经常会发生因为不可控原因,需要将实例从某个机房迁移到其他机房,甚至从某个Region迁移到其他Region,用户希望迁移过程尽可能是对业务无感的。因此可以通过Replication机制,实现实例状态在集群间的迁移。 热升级:热升级过程中,需要业务服务能力不中断,属于高速公路上换发动机的需求,因此需要系统具备某种类似“滚动”升级的能力。通过Replication机制,可以先克隆出一个实例,在新的实例上完成软件版本的升级,再将相关的网络路由等配置接入到新的实例,从而完成无需停机的热升级。
3 调度系统提高节点failover快速恢复能力
Pod的调度利用了K8S的能力,Hologres中被K8S调度的单元是HoloWorker;
Pod内子进程调度以及Actor的调度是Hologres分布式调度模块HoloFlow提供的能力。
外部流量即入口流量,这部分调度是SLB提供的能力,Hologres会定时监测Frontend的健康状态,一旦某个Frontend不健康了,流量就会从SLB上摘除。
内部流量Hologres提供了内部的健康检测和服务发现机制,例如StoreMaster提供了Shard的健康检测和服务发现机制,一旦某个Shard不健康,Coordinator就会把流量导到这个Shard健康的Replica上。
4 多层次隔离轻松应对不同业务SLA
在操作系统层面:线程切换是一个不小的开销。为了把因为等待IO而空闲的CPU利用起来,需要把很多CPU浪费在线程切换上。测试发现,严重的时候线程切换能浪费掉一半以上的CPU;
线程的数目很难掌握:不同的query、不同的数据、不同的cache命中率,被IO阻塞的可能性差异会非常大,以至于需要的线程数差别非常大。这种情况下,使用固定线程数目的线程池是很难受的。线程多了会引起多余的切换,加剧切换的开销;线程少了则可能没法把空闲的CPU都利用起来。而相比于线程切换,线程的创建和销毁会带来更大的开销,所以想要通过动态创建线程来保持恰当的线程数,这也是不太可能的;
我们可以根据业务逻辑的需要,创建足够多的“线程”去并发使用CPU,而不必担心切换的开销大、或者CPU用不满;
当需要业务逻辑需要使用CPU时,直接根据并发度的需要去创建N个这样的“线程”,用完即销毁。这样就能使业务逻辑灵活控制任务的并行度,不必受制于底层框架;
三 Hologres高可用在双11的落地实践
1 业务双联路+读写实例分离(DT团队实践)
2 双链路容灾+读写分离(CCO团队实践)
四 总结
1、2020年VLDB的论文《Alibaba Hologres: A cloud-Native Service for Hybrid Serving/Analytical Processing》:http://www.vldb.org/pvldb/vol13/p3272-jiang.pdf
2、Hologres揭秘:首次公开!阿里巴巴云原生实时数仓核心技术揭秘:https://developer.aliyun.com/article/779118
3、Hologres揭秘:首次揭秘云原生Hologres存储引擎:https://developer.aliyun.com/article/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/article/785647?
网友评论已有0条评论, 我也要评论