Hologres（中文交互式分析）是阿里云自研的一站式实时数据仓库。这个云原生系统集成了实时服务和大数据分析场景。完全兼容PostgreSQL协议，无缝对接大数据生态，可以使用同一个数据架构，支持实时写入、实时查询和实时离线联合分析。它的出现简化了业务架构，同时为业务提供了实时决策的能力，让大数据发挥更大的商业价值。从阿里集团诞生到云端商业化，随着业务的发展和技术的演进，Hologres不断优化其核心技术竞争力。为了让大家更加了解Hologres，我们计划继续推出Hologres底层技术原理系列揭秘，从高性能存储引擎到高效查询引擎，从高吞吐写入到高-QPS查询等，Hologers全面解读，敬请持续关注！本期我们将带来Hologers高效分布式查询引擎的技术原理解析。Hologres是集成HSAP服务分析的最佳实践。其查询引擎是完全自主研发的执行引擎。其核心设计目标是支持各类分布式分析和服务查询，并实现极致的查询性能。为了实现这一点，我们借鉴了各种分布式查询系统，包括分析型数据库、实时数仓等，吸取了各方面的优点，从无到有打造了一个全新的执行引擎。为什么选择从头开始构建一个新的查询引擎？开源的分布式分析查询系统主要有两大类：一类是传统的MassivelyParallelProcessing系统，可以支持一般的SQL查询，但是对实时场景的支持不够好，性能也不够理想。一类是ApacheDruid、ClickHouse等实时数仓，专门针对实时场景进行设计和优化，可以较好地支持一些常见的单表实时查询，但复杂查询的性能相对较差。另外，大数据生态中基于MapReduce的引擎更适合批处理ETL，但一般不适合在线服务和多维分析场景，性能也比较差。Hologres执行引擎基于通用架构，可以支持复杂查询和上述高性能实时服务查询。首先，它实现了常见的实时数仓场景，并对其进行深度优化，并使用内部基准测试验证其性能和稳定性超过专用实时数仓。在其他竞争产品之后，它将被扩展以支持其他复杂查询。在扩展的过程中，系统不可避免地变得越来越复杂的同时，Benchmark也被用来帮助保持简单的实时查询的性能不退化。如果在现有的查询引擎上进行改进，因为很多架构和设计选择已经敲定，牵一发而动全身，就很难达到这样的效果。Hologres执行引擎从开发到实现面临诸多挑战，但也为我们提供了结合利用该领域各种新进展的机会，超越现有系统实现对各种查询类型的高性能处理主要基于具有以下特点：分布式执行模型：配合存储计算分离架构的分布式执行模型。执行计划由异步算子组成的执行图DAG（有向无环图）表示，可以表达各种复杂的查询，完美适配Hologres的数据存储模型，方便对接查询优化器，利用各种查询行业优化技术。全异步执行：端到端的全异步处理框架可以避免高并发系统中的瓶颈，充分利用资源，尽可能避免存储和计算分离系统带来的读取数据延迟的影响。向量化和列处理：算子在内部处理数据时，最大限度地使用向量化执行，并与存储引擎深度集成。通过灵活的执行模型，充分利用各种指标，最大限度地延迟向量物化和延迟计算。避免不必要的数据读取和计算。自适应增量处理：将查询模式应用于常见实时数据的自适应增量处理。具体查询深度优化：针对部分查询模式的独特优化下面将对各个模块一一进行介绍。分布式执行模型Hologres是一个能够弹性无限扩展数据量和计算能力的系统，需要能够支持高效的分布式查询。Hologres查询引擎执行优化器生成的分布式执行计划。执行计划由运算符组成。因为Hologres中一张表的数据会按照分布键分布在多个分片上，每个分片可以包含很多段，执行计划也会体现这种结构，数据会分布到数据所在的节点上位于执行。每个TableShard都会被加载到一个计算节点上，数据会缓存在这个节点的内存和本地存储中。因为是存储和计算分离的架构，如果一个节点出现故障，它服务的分片可以重新加载到任意一个计算节点，相当于清空了缓存。例如一个相对简单的查询。selectkey,count(value)astotalfromtable1groupbykeyorderbytotaldesclimit100。如果是单机数据库，可以使用这样的执行计划。如果数据和计算分布在多个节点上，则需要更复杂的执行计划。在分布式表上，为了更高效的执行和最小化数据传输，可以将执行计划分成不同的分片（Fragment）分布到相应的节点执行，同时可以将一些操作下推，减少Fragment的输出数据，这可能会变成这样一个执行计划：根据数据的特点，优化器可能会生成不同的计划。例如，当某个部分聚合不会显着减少数据量时，可以省略此运算符。再举个例子，当key为分发key时，可以这样优化：从这些例子可以看出，Hologres的执行计划是根据数据的特点分成不同的分片，然后分发执行的同时。Fragment之间通过Exchange算子进行数据交换。多表关联（Join）等更复杂的查询，碎片会更多，数据交换模式也会更复杂。比如下面的SQLselectuser_name,sum(value)astotalfromt1joint2ont1.user_id=t2.user_idwhere...groupbyuser_nameorderbytotallimit100在Hologres中可以是这样的执行计划。如果Joinkey和DistributionKey一致，可以优化为如下执行计划，减少远程数据传输。根据查询需要合理设置DistributionKey，可以显着提高查询性能。根据过滤条件和统计信息等，优化器还可以生成不同的优化执行计划，比如包括动态过滤、局部聚合等。这样的分布式执行计划足够通用，可以表达所有SQL查询和其他一些查询。执行计划也类似于大多数大规模并行处理（MPP）系统，方便业界一些适用的优化参考和集成。一个稍微独特的特点是查询计划片段的许多实例与Hologres存储结构对齐，从而实现高效的分区剪枝和文件剪枝。同时，Hologres实现了PostgreSQL的Explain和ExplainAnalyze系列语句，可以将执行计划和对应的执行信息以文本形式显示出来，方便用户自行了解执行计划，有针对性地进行SQL优化调整。高并发系统的全异步执行，尤其是大量I/O的系统，频繁等待或任务切换是常见的系统瓶颈。异步处理是避免这些瓶颈并将高并发系统的性能推向极致的行之有效的方法。Hologres整个后端，包括执行引擎、存储引擎等组件，都使用了HOS（HologresOperationSystem）组件提供的异步无锁编程框架，最大限度地发挥异步执行的效果。每个Fragment实例都使用一个HOS的EC（LogicalSchedulingUnit），这样一个Fragment中的所有算子和存储引擎都可以异步执行，并且可以无锁安全地访问大部分资源。Operators和Fragments是类似这样的接口：future<>Open(constSeekParameters¶meters,...)future
