简介：在本次评测中，Hologres是目前通过中国信通院大数据产品分布式剖析型数据库大规模性能评测的规模最大的MPP数据仓库产品。通过该评测，证实了阿里云实时数仓Hologres可能作为数据仓库和大数据平台的基础设施，能够满足用户建设大规模数据仓库和数据平台的需要，具备撑持要害行业外围业务数据平台的能力。

作者 | 欧文
起源 | 阿里技术公众号

2021年11月23日至12月3日，中国信息通信研究院（以下简称“中国信通院”）对第13批分布式剖析型数据库共计27款产品进行了大数据产品能力评测。阿里云实时数仓Hologres（原阿里云交互式剖析）在报表工作、交互式查问、压力测试、稳定性等方面通过了中国信通院分布式剖析型数据库性能评测（大规模），并以8192个节点刷新了通过该评测现有参评的规模记录。

在本次评测中，Hologres是目前通过中国信通院大数据产品分布式剖析型数据库大规模性能评测的规模最大的MPP数据仓库产品。通过该评测，证实了阿里云实时数仓Hologres可能作为数据仓库和大数据平台的基础设施，能够满足用户建设大规模数据仓库和数据平台的需要，具备撑持要害行业外围业务数据平台的能力。

在Hologres实例的云原生调度和运维体系建设上，团队也联结阿里云云原生等团队，解决了在超大规模集群；在运维能力建设上，团队通过自动化、智能化的运维体系建设，解决了实例部署和稳定性保障的问题。

一 超大规模部署面临的挑战

随着互联网的倒退，数据量呈现了指数型的增长，单机的数据库曾经不能满足业务的需要。特地是在剖析畛域，一个查问就可能须要解决很大一部分甚至全量数据，海量数据带来的压力变得尤为迫切。同时，随着企业数字化转型过程的减速，数据的时效性变得越来越重要，如何利用数据更好的赋能业务成为企业数字化转型的要害。

大数据实时数仓场景相比数据库的规模往往是成倍增加：数据量减少（TB级、PB级甚至是EB级）、数据处理的复杂度更高、性能要更快、服务和剖析要同时满足等等。

而应用过开源OLAP零碎的用户，尤其是通过开源OLAP自建集群的用户，都有一些比拟粗浅的领会，就是部署和运维艰难，包含ClickHouse、Druid等，都面临了如下难题：

  • 如何满足集群的疾速交付和弹性伸缩
  • 如何定义服务的可用性指标和SLA体系
  • 存储计算一体，机型抉择和容量布局艰难
  • 监控能力弱，故障复原慢，自愈能力缺失

同时，随着规模的减少，规模劣势和高性能吞吐下的压力，实时数仓的部署和运维难度呈指数级减少，零碎面临了诸多调度、部署和运维上的各种挑战：

  • 如何解决调度能力满足在单集群万台规模下服务实例的秒级拉起和弹性伸缩能力的要求；
  • 如何解决大规模集群本身的容量布局、稳定性保障、机器自愈，晋升相干的运维效率；
  • 如何实现实例和集群的监控时效和准确性的双重要求，包含怎么在分钟内实现问题发现和分钟级的问题解决

得益于阿里云弱小的云原生根底服务研发能力，实时数仓Hologres通过优良的架构设计和阿里云大数据智能运维中台的能力等多个外围能力的建设，解决这些挑战，为用户提供了一个性能弱小、扩大能力优良、高牢靠、免运维的实时数仓产品。

本文将会从超大规模部署与运维体系建设登程，剖析超大规模实时数仓面临的挑战和针对性的设计及解决方案，实现在高负载高吞吐的同时反对高性能，并做到生产级别的高可用。

二 基于云原生的大规模调度架构设计

随着云技术的衰亡，原来越多的零碎刚开始利用Kubernetes作为容器利用集群化管理系统，为容器化利用提供了自动化的资源调度，容器部署，动静扩容、滚动降级、负载平衡，服务发现等性能。

Hologres在设计架构之初就提前做了优化，采纳云原生容器化部署的形式，基于Kubernetes作为资源调度零碎，满足了实时数仓场景上的超大规模节点和调度能力。Hologres依赖的云原生集群能够反对超过1万台服务器，单实例能够达到8192个节点甚至更大的规模。

1 Kubernetes万台调度

Kubernetes官网颁布集群最大规模为5000台，而在阿里云场景下，为了满足业务规模需要、资源利用率晋升等要求，云原生集群规模要达万台。家喻户晓Kubernetes是核心节点式服务，强依赖ETCD与kube-apiserver，该块是性能瓶颈的所在，冲破万台规模须要对相干组件做深度优化。同时要解决单点Failover速度问题，晋升云原生集群的可用率。

通过压测，模仿在万台node和百万pod下的压力，发现了比较严重的响应提早问题，包含：

  • etcd大量的读写提早，并且产生了拒绝服务的情景，同时因其空间的限度也无奈承载 Kubernetes 存储大量的对象；
  • API Server 查问提早十分高，并发查问申请可能导致后端 etcd oom；
  • Controller 解决延时高，异样复原工夫久，当产生异样重启时，服务的复原工夫须要几分钟；
  • Scheduler 提早高、吞吐低，无奈适应业务日常运维的需要，更无奈反对大促态的极其场景

为了冲破k8s集群规模的瓶颈，相干团队做了具体调研，找到了造成解决瓶颈的起因：

  • 发现性能瓶颈在kubelet，每10s上报一次本身全量信息作为心跳同步给k8s，该数据量小则几KB大则10KB+，当节点达到5000时，会对kube-apiserver和ETCD造成写压力。
  • etcd 举荐的存储能力只有2G，而万台规模下k8s集群的对象存储要求远远超过这个要求，同时要求性能不能降落；
  • 用于反对集群高可用能力的多API Server部署中，会呈现负载不平衡的状况，影响整体吞吐能力；
  • 原生的scheduler 性能较差，能力弱，无奈满足针对混部、大促等场景下的能力。

针对该状况，做了如下优化，从而达到万台规模调度：

  • etcd设计新的内存闲暇页治理算法，大幅优化etcd性能；
  • 通过落地 Kubernetes 轻量级心跳、改良 HA 集群下多个 API Server 节点的负载平衡，解决了APIServer的性能瓶颈；
  • 通过热备的形式大幅缩短了 controller/scheduler 在主备切换时的服务中断工夫，进步了整个集群的可用性；
  • 通过反对等价类解决以及随机松弛算法的引入，晋升了Scheduler的调度性能

三 Hologres运维体系建设

1 Hologres运维体系总览

针对OLAP体系碰到的问题和痛点，以及在超大规模部署压力下的运维挑战，同时依靠阿里云大数据运维中台，咱们设计了Hologres的运维体系，解决资源和集群交付等自动化问题、集群和实例级别的实时可观测性问题和智能化的自愈体系，晋升Hologres的SLA到生产可用级别。

2 集群自动化交付

Hologres 是齐全基于云原生的形式设计和实现的，通过存储计算拆散的形式，解耦了计算资源和存储资源；其中计算节点的部署通过K8s集群进行部署和拉起。通过自研的运维管理系统ABM，在集群交付上，咱们对集群进行形象设计，拆散出资源集群和业务集群的概念；资源集群的交付，ABM和底层平台进行买通，进行资源集群的创立和容量维持；在业务集群上，ABM提供基于K8s 概念的部署模板，将管控等节点在资源集群上疾速拉起，实现交付。

3 可观测性体系

零碎的可观测性能帮忙业务更好的治理集群水位和问题排查等，从而晋升企业级管控能力。在可观测性上，不仅须要透出更加简略易懂的监控指标，还须要有成熟的日志采集零碎，从而实现更简略的运维，只须要为业务问题负责。基于阿里云的监控产品和Hologres的可观测性需求，咱们设计了Hologres的实时监控能力。

Metric监控体系

为了反对具体的零碎能力察看、性能监控、疾速的问题定位和debug，Hologres 反对了十分丰盛的Metric监控体系，这也对整个Metric链路的采集、存储和查问提出了十分高的要求。在监控链路上，Hologres 抉择了阿里巴巴自研的Emon平台，除了反对亿级Metric每秒的写入，Emon还反对主动downsample、聚合优化等能力；同时在后端咱们通过实时链路，能够把外围Metric吐到云监控，不便用户自助的对实例进行监控察看和问题定位。

日志采集和监控

在日志采集上，Hologres采纳了成熟的云产品SLS，能够反对核心式的日志排查和过滤 ；同时思考到Hologres的日志量也十分宏大，在采集上采纳了分模块和分级的机制，在管制老本的同时，能很好的解决问题排查和审计的须要。同时，SLS也提供了基于关键字等形式的监控计划，能够对要害谬误进行告警，以不便及时处理问题。

基于元仓的可用性监控

在Metric和日志的采集及告警上，更多的是体现某一个模块上的问题，下面的伎俩还无奈残缺的答复某一个实例的可用性。基于此，咱们构建了一个Hologres运维数仓，通过多维度的事件、状态进行综合判断实例是否工作失常。
在元仓中会收集和保护多维度数据，包含实例的meta数据、Hologres中各模块的可用性判断规范、实例各模块的状态、事件核心，包含运维事件、客户事件、零碎事件等；在进行实例可用性判断的同时，元仓还提供了用于实例诊断、实例巡检等各种数据。以后元仓的能力曾经产品化公布为慢Query日志，用户能够通过慢query日志，进行自助化问题诊断和调优。

4 智能运维晋升产品SLA

在可观测性欠缺的根底上，为了晋升问题定位的速度和缩短实例复原工夫，即晋升Hologres的MTTR，基于阿里云大数据运维中台提供的根底能力和智能运维计划，咱们构建了残缺的Hologres SLA管理体系和故障诊断及自愈体系。

SLA体系

基于Hologres运维元仓的数据和实例可用性定义，咱们建设了Hologres实例级别可用性的管理系统，实例可用性数据会进入ABM的SLI数据库，SLI依据数据和条件触发实例可用性监控，在监控收回的同时，会触发实例的诊断，零碎依据诊断后果，判断是否进行自愈，如果是已知能够主动复原状况，会触发自愈，进行故障的主动复原；如果是未知状况，会触发生成人工工单，工单零碎会由人跟进实现，并逐步形成自愈的action。

智能巡检

智能巡检解决的是集群或者实例的一些隐性和不紧急的问题，防止一些小问题的与日俱增引发量变影响线上的稳定性；除了一些比拟清晰定义的巡检项，智能巡检还引入了聚类算法等，对系统指标进行剖析，这也会帮忙咱们发现一些集群中的离散节点，进行及时处理，防止问题节点导致影响整个实例的可用性。

智能诊断和自愈

智能诊断既依赖运维元仓的数据，同时还会依赖诊断相干的算法反对，包含日志聚类、根因剖析等，进行谬误日志的聚类，对聚类后果进行打标。在ABM提供的算法和工程能力反对下，实例诊断曾经在帮忙业务进行问题的疾速定位，晋升问题解决的效率，缩短了实例的MTTR。

四 Hologres产品级运维能力

除了下面介绍的Hologres服务自身的运维稳定性保障。在Hologres 产品侧，通过多种形式晋升零碎的稳定性：

1、高可用架构

采纳高可用架构设计，稳固撑持阿里团体历年双11等大促流量峰值，经验大规模生产考验，包含

  • 存储计算拆散架构晋升零碎扩大灵活性
  • 多状态replication解决数据读写拆散，次要包含多正本进步吞吐、单实例资源组隔离、多实例共享存储高可用
  • 调度零碎晋升节点failover疾速恢复能力

2、多元化的零碎可观性指标

除了Hologres自身架构的设计，同时也为用户提供多元化的观测指标，实时监控集群状态和预先复盘，无需简单操作，只需为业务负责：

  • 多维度监控指标：CPU、内存、连接数、IO等监控指标实时查问，实时预警；
  • 慢query日志：产生的慢Query或失败Query通过工夫、plan、cpu耗费等各项指标进行诊断、剖析和采取优化措施，进步自助诊断能力；
  • 执行打算可视化：通过多种可视化展示的形式，对Query进行运行剖析、执行剖析，具体算子解读，并进行优化倡议疏导，防止自觉调优，升高性能调优门槛，疾速达到性能调优的目标。

五 总结

通过对大规模调度下面临的调度性能瓶颈的剖析和针对性的优化，Hologres 能够实现8192节点甚至更大规模的实例交付和扩缩容。同时基于云原生的Hologres智能运维体系建设，解决了大规模集群和实例下面临的运维效率和稳定性晋升问题，使得Hologres在阿里巴巴外部外围场景历经多年双11生产考验，在高负载高吞吐的同时实现高性能，实现生产级别的高可用，更好的撑持业务，为企业的数字化转型提供了良好的反对。

原文链接
本文为阿里云原创内容，未经容许不得转载。