阿里库器云数据服务有什么用_技术揭秘：实时数仓Hologres如何支持超大规模部署与运维

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

本次评测是迄今为止通过中国信息通信研究院大数据产品分布式分析型数据库大规模性能测评的规模最大的MPP数仓产品，证明了阿里云实时数仓可以作为数据仓库和大数据平台的基础设施，能够满足用户构建大规模数据仓库和数据平台的需求，具备支撑重点行业核心业务数据平台的能力。

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

超大规模部署的挑战

随着互联网的发展，数据量呈指数级增长，单机数据库已经不能满足业务需求。特别是在分析领域，一个查询可能需要处理很大一部分甚至全部数据，海量数据带来的压力变得尤为迫切。同时，随着企业数字化转型的加速，数据的时效性也变得越来越重要。如何利用数据更好地赋能业务，成为企业数字化转型的关键。

大数据实时数仓场景的规模相较于数据库往往是指数级增长的：数据量的增大（TB级、PB级，甚至EB级）、数据处理的复杂度更高、性能需要更快、要同时满足服务和分析等等。

用过开源 OLAP 系统的用户，特别是通过开源 OLAP 搭建过自己集群的用户，都有一些深刻的体会，那就是部署和运维的难度。包括 OLAP、Druid 等，都面临以下问题：

同时随着规模的增加，规模优势和高性能吞吐的压力使得实时数仓的部署和维护难度成倍增加，系统在调度、部署、运维等方面面临诸多挑战：

得益于阿里云强大的云原生基础服务研发能力，实时数仓通过优秀的架构设计、阿里云大数据智能运维中台等多项核心能力的构建解决了这些挑战，为用户提供了性能强大、扩展性优异、高可靠、免运维的实时数仓产品。

本文将从超大规模部署与运维体系构建出发，分析超大规模实时数仓面临的挑战以及针对性的设计和解决方案，在支撑高负载、高吞吐量的同时实现高性能，并实现生产级的高可用性。

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

随着云技术的兴起，越来越多的系统开始将其作为容器应用集群管理系统，为容器化应用提供自动化资源调度、容器部署、动态扩容、滚动升级、负载均衡、服务发现等功能。

我们一开始就优化了架构，采用云原生的容器化部署，作为资源调度系统，满足实时数仓场景下的超大规模节点和调度能力。我们依赖的云原生集群可以支持10000多台服务器，单实例可以达到8192个节点甚至更大。

10,000 台发货

官方给出的最大集群规模是 5000 台机器，但在阿里云场景下，为了满足业务规模需求，提高资源利用率，云原生集群规模必须达到 10000 台机器。众所周知，它是一个中心节点服务，严重依赖 ETCD 和 kube-，是性能瓶颈。要突破 10000 台机器的规模，需要对相关组件进行深度优化。同时需要解决单点速度问题，提高云原生集群的可用性。

通过压测，我们模拟了1万节点，100万pod下的压力，发现响应延迟问题比较严重，包括：

etcd 存在大量的读写延迟，并且曾经造成过拒绝服务，同时由于其空间限制，无法承载和存储大量对象；API 查询延迟非常高，并发查询请求可能导致后端 etcd oom；处理延迟高，异常恢复时间长，当发生异常重启时，服务恢复时间需要几分钟；高延迟、低吞吐量无法满足日常业务运维的需求，无法支撑大促等极端场景

为了突破k8s集群规模的瓶颈，相关团队进行了详细的调查，发现了处理瓶颈的原因：

性能瓶颈在于每10秒需要将全量信息上报给k8s作为心跳同步，数据量从几KB到十几KB不等，当节点数达到5000个时会对kube-和ETCD造成写入压力。etcd推荐的存储容量只有2G，但万台机器规模的k8s集群的对象存储需求远超这个要求，性能不能降低；在用于支撑集群高可用的多API部署中，会出现负载不均衡的情况，影响整体吞吐量；原生性能差，能力弱，无法满足混部部署、大促等场景的能力。

针对这种情况，为了实现万台机器的规模调度，我们做了如下优化：

etcd设计了全新的内存空闲页面管理算法，大大优化了etcd的性能；通过实现轻量心跳、提高HA集群中多个API节点的负载均衡，解决了性能瓶颈；通过热备，大大缩短了主备切换时的服务中断时间，提高了整个集群的可用性；通过支持等价类处理、引入随机松弛算法，提升了调度性能。三运维体系建设

1 运维体系概述

针对OLAP系统遇到的问题和痛点，以及超大规模部署压力下的运维挑战，我们基于阿里云大数据运维平台设计了运维体系，解决资源、集群交付等自动化问题、集群、实例级别的实时可观测性问题以及智能自愈系统，从而将SLA提升到生产可用级别。

2 集群自动化交付

完全基于云原生方式设计和实现，通过存储和计算分离，解耦计算资源和存储资源。计算节点通过K8s集群部署和启动。通过自研的运维管理系统ABM，我们对集群进行抽象，在集群交付中分离资源集群和业务集群的概念。针对资源集群的交付，ABM对接底层平台，完成资源集群的创建和容量维护。针对业务集群，ABM提供基于K8s理念的部署模板，在资源集群上快速启动管控等节点完成交付。

3 可观测性系统

系统的可观测性可以帮助业务更好的管理集群水位、排查问题，从而提升企业级管控能力。在可观测性方面，不仅要提供更简单易懂的监控指标，还需要有成熟的日志收集体系，实现更简单的运维，只需要关注业务问题。基于阿里云的监控产品和可观测性需求，我们设计了实时监控能力。

监视系统

为了支撑细致的系统能力观察、性能监控、快速问题定位和调试，需要支撑非常丰富的监控体系，这也对整个链路的采集、存储、查询提出了非常高的要求。在监控链路上，选择了阿里巴巴自研的Emon平台，Emon除了支撑每秒数十亿的写入，还支持自动化、聚合的优化能力；同时在后端，我们可以通过实时的链路把核心吐到云监控上，方便用户自己监控观察实例，以及定位问题。

日志收集与监控

在日志采集方面，我们采用了成熟的云产品SLS，可以支持集中式的日志排查和过滤。同时考虑到日志量巨大，我们在日志采集上采用了模块化、分层化的机制，在控制成本的同时，可以有效解决排查问题、审计的需求。同时，SLS还提供了基于关键字等方式的监控方案，可以对关键错误进行告警，方便及时处理问题。

基于元仓库的可用性监控

日志采集与报警方面，更多的是反映某个模块的问题，以上方式无法全面回答某个实例的可用性。基于此，我们构建了运维数据仓库，通过多维度的事件和状态，综合判断实例是否正常。

收集并维护多维度数据，包括实例元数据、各模块可用性判断标准、实例各模块状态，以及事件中心，包括运维事件、客户事件、系统事件等。在判断实例可用性的同时， 还提供各类数据用于实例诊断、实例巡检等。目前 的能力已经产品化发布为慢查询日志，用户可以利用慢查询日志进行自助问题诊断与优化。

4 智能运维提升产品SLA

在提升可观测性的基础上，为了加快问题定位，缩短实例恢复时间，也就是提升MTTR，我们基于阿里云大数据运维中心提供的基础能力和智能运维解决方案，构建了完整的SLA管理体系和故障诊断自愈体系。

SLA 系统

基于运维元仓库的数据以及实例可用性的定义，我们建立了实例级可用性管理体系。实例可用性数据会进入ABM的SLI数据库，SLI会根据数据和情况触发实例可用性监控，监控下发的同时会触发实例的诊断，系统会根据诊断结果判断是否进行自愈，如果是已知可以自动恢复的情况，就会触发自愈，自动从故障中恢复；如果是未知情况，就会触发生成人工工单，由人工在工单体系中跟进并完成，逐步形成自愈。

智能巡检

智能巡检主要解决集群或者实例的一些隐蔽的、不紧急的问题，防止小问题堆积到一定程度导致质变，影响线上稳定性。除了一些定义明确的巡检项，智能巡检还引入了聚类算法，对系统指标进行分析，帮助我们发现一些集群中的离散节点，并及时处理，防止问题节点影响整个实例的可用性。

智能诊断与自我修复

智能诊断不仅依赖运维元仓库的数据，还依赖诊断相关的算法支持，包括日志聚类、根因分析等，对错误日志进行聚类，并对聚类结果进行标记。在 ABM 提供的算法和工程能力的支持下，实例诊断帮助业务快速定位问题，提升问题解决效率，缩短实例 MTTR。

四大产品级运维能力

除了上述的服务运维稳定性保障外，在产品端，通过多种方式提升系统的稳定性：

1. 高可用架构

采用高可用架构设计，稳定支撑阿里巴巴集团双11等历年大促流量峰值，并历经大规模生产考验，包括

2. 多样化的系统可观测性指标

除了自身架构的设计之外，还为用户提供了多种观测指标，实时监控集群状态以及事后回顾，无需复杂操作，只需要对业务负责：

5. 结论

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

阿里云实时数仓：

作者 | 欧文

原文链接：