简介：在本次评测中，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 生产考验，在高负载高吞吐的同时实现高性能，实现生产级别的高可用，更好的撑持业务，为企业的数字化转型提供了良好的反对。
原文链接
本文为阿里云原创内容，未经容许不得转载。