万字长文揭秘：阿里如何实现海量数据实时分析？(7)

所有这些组合降低了查询延迟，同时提高集群利用率，从而使得AnalyticDB能轻松支持高并发。 [原创文章：www.11jj.com]

动态统计信息收集 [原文来自：www.11jj.com]

统计信息是优化器在做基于代价查询优化所需的基本信息，通常包括有关表、列和索引等的统计信息。传统数据仓库仅收集有限的统计信息，例如列上典型的最常值（MFV）。商业数据库为用户提供了收集统计信息的工具，但这通常取决于DBA的经验，依赖DBA来决定收集哪些统计数据，并依赖于服务或工具供应商。

上述方法收集的统计数据通常都是静态的，它可能需要在一段时间后，或者当数据更改达到一定程度，来重新收集。但是，随着业务应用程序变得越来越复杂和动态，预定义的统计信息收集可能无法以更有针对性的方式帮助查询。例如，用户可以选择不同的聚合列和列数，其组合可能会有很大差异。但是，在查询生成之前很难预测这样的组合。因此，很难在统计收集时决定正确统计方案。但是，此类统计信息可帮助优化器做出正确决定。

我们设计了一个查询驱动的动态统计信息收集机制来解决此问题。守护程序动态监视传入的查询工作负载和特点以提取其查询模式，并基于查询模式，分析缺失和有益的统计数据。在此分析和预测之上，异步统计信息收集任务在后台执行。这项工作旨在减少收集不必要的统计数据，同时使大多数即将到来的查询受益。对于前面提到的聚合示例，收集多列统计信息通常很昂贵，尤其是当用户表有大量列的时候。根据我们的动态工作负载分析和预测，可以做到仅收集必要的多列统计信息，同时，优化器能够利用这些统计数据来估计聚合中不同选项的成本并做出正确的决策。

计划缓存

从在线应用案件看，大多数客户都有一个共同的特点，他们经常反复提交类似的查询。在这种情况下，计划缓存变得至关重要。为了提高缓存命中率，AnalyticDB不使用原始SQL文本作为搜索键来缓存。相反，SQL语句首先通过重写并参数化来提取模式。例如，查询 “SELECT * FROM t1 WHERE a = 5 + 5”将转化为“SELECT * FROM t1 WHERE a =？”。参数化的SQL模版将被作为计划缓存的关键字，如果缓存命中，AnalyticDB将根据新查询进行参数绑定。由于这个改动，即使使用有限的缓存大小，优化器在生产环境也可以保持高达90％以上的命中率，而之前只能达到40％的命中率。

这种方法仍然有一个问题。假设我们在列a上有索引，“SELECT * FROM t1 WHERE a = 5”的优化计划可以将索引扫描作为其最佳访问路径。但是，如果新查询是“SELECT * FROM t1 WHERE a = 0”并且直方图告诉我们数值0在表t1占大多数，那么索引扫描可能不如全表扫描有效。在这种情况下，使用缓存中的计划并不是一个好的决定。为了避免这类问题，AnalyticDB提供了一个功能Literal Classification，使用列的直方图对该列的值进行分类，仅当与模式相关联的常量“5”的数据分布与新查询中常量“0”的数据分布类似时，才实际使用高速缓存的计划。否则，仍会对新查询执行常规优化。

★ 执行引擎

在优化器之下，AnalyticDB在MPP架构基础上，采用流水线执行的DAG架构，构建了一个适用于低延迟和高吞吐量工作负载的执行器。如下图所示，当涉及到多个表之间非分区列JOIN时，CN(MPP Worker)会先进行data exchange (shuffling)然后再本地JOIN (SourceTask)，aggregate后发送到上一个stage(MiddleTask)，最后汇总到Output Task。由于绝大多情况都是in-memory计算（除复杂ETL类查询，尽量无中间Stage 落盘）且各个stage之间都是pipeline方式协作，性能上要比MapReduce方式快一个数量级。

在接下来的几节中，将介绍其中三种特性，包括混合工作负载管理，CodeGen和矢量化执行。

混合工作负载管理

作为一套完备的实时数仓解决方案，AnalyticDB中既有需要较低响应时间的高并发查询，也有类似ETL的批处理，两者争用相同资源。传统数仓体系往往在这两个方面的兼顾性上做的不够好。

AnalyticDB worker接收coordinator下发的任务, 负责该任务的物理执行计划的实际执行。这项任务可以来自不同的查询， worker会将任务中的物理执行计划按照既定的转换规则转换成对应的operator，物理执行计划中的每一个Stage会被转换成一个或多个operator。

执行引擎已经可以做到stage/operator级别中断和Page级别换入换出，同时线程池在所有同时运行的查询间共享。但是，这之上仍然需要确保高优先级查询可以获得更多计算资源。

根据经验，客户总是期望他们的短查询即使当系统负载很重的时候也能快速完成。为了满足这些要求，基于以上场景，通过时间片的分配比例来体现不同查询的优先级，AnalyticDB实现了一个简单版本的类Linux kernel 的调度算法。系统记录了每一个查询的总执行耗时，查询总耗时又是通过每一个Task耗时来进行加权统计的，最终在查询层面形成了一颗红黑树，每次总是挑选最左侧节点进行调度，每次取出或者加入（被唤醒以及重新入队）都会重新更新这棵树，同样的，在Task被唤醒加入这颗树的时候，执行引擎考虑了补偿机制，即时间片耗时如果远远低于其他Task的耗时，确保其在整个树里面的位置，同时也避免了因为长时间的阻塞造成的饥饿，类似于CFS 调度算法中的vruntime补偿机制。

这个设计虽然有效解决了慢查询占满资源，导致其他查询得不到执行的问题，却无法保障快查询的请求延迟。这是由于软件层面的多线程执行机制，线程个数大于了实际的CPU个数。在实际的应用中，计算线程的个数往往是可用Core的2倍。这也就是说，即使快查询的算子得到了计算线程资源进行计算，也会在CPU层面与慢查询的算子形成竞争。所下图所示，快查询的算子计算线程被调度到VCore1上，该算子在VCore1上会与慢查询的计算线程形成竞争。另外在物理Core0上，也会与VCore0上的慢查询的计算线程形成竞争。

在Kernel sched模块中，对于不同优先级的线程之间的抢占机制，已经比较完善，且时效性比较高。因而，通过引入kernel层面的控制可以有效解决快查询低延迟的问题，且无需对算子的实现进行任何的改造。执行引擎让高优先级的线程来执行快查询的算子，低优先级的线程来执行慢查询的算子。由于高优先级线程抢占低优先级线程的机制，快查询算子自然会抢占慢查询的算子。此外，由于高优先级线程在Kernel sched模块调度中，具有较高的优先级，也避免了快慢查询算子在vcore层面的CPU竞争。