【翻译】Impala: A Modern, Open-Source SQL Engine for Hadoop

作者

Marcel Kornacker, Alexander Behm, Victor Bittorf, Taras Bobrovytsky, Casey Ching, Alan Choi, Justin Erickson, Martin Grund, Daniel Hecht, Matthew Jacobs, Ishaan Joshi, Lenni Kuff, Dileep Kumar, Alex Leblang, Nong Li, Ippokratis Pandis, Henry Robinson, David Rorke, Silvius Rus, John Russell, Dimitris Tsirogiannis, Skye Wanderman-Milne, Michael Yoder

公司

Cloudera, http://impala.io/

摘要

Cloudera Impala 是一个现代化的开源 MPP SQL 引擎，专为 Hadoop 数据处理环境而设计。Impala 为 Hadoop 上的以读取为主的 BI/分析查询提供低延迟和高并发性，而不是由 Apache Hive 等批处理框架提供。本文从用户的角度介绍了 Impala，概述了其架构和主要组件，并简要展示了与其他流行的 SQL-on-Hadoop 系统相比的卓越性能。

1. 引言

Impala 是一个开源的、完全集成的、最先进的 MPP SQL 查询引擎，专为利用 Hadoop 的灵活性和可扩展性而设计。Impala 的目标是将传统分析数据库熟悉的 SQL 支持和多用户性能与 Apache Hadoop 的可扩展性和灵活性以及 Cloudera Enterprise 的生产级安全性和管理扩展能力相结合。Impala 的 beta 版本于 2012 年 10 月发布，并于 2013 年 5 月正式发布。最新版本 Impala 2.0 于 2014 年 10 月发布。Impala 的生态系统势头继续加速，自正式发布以来下载量已接近 100 万次。

与其他系统（通常是 Postgres 的分支）不同，Impala 是一个全新的引擎，用 C++ 和 Java 从头开始编写。它通过使用标准组件（HDFS、HBase、Metastore、YARN、Sentry）来保持 Hadoop 的灵活性，并且能够读取大多数广泛使用的文件格式（例如 Parquet、Avro、RCFile）。为了减少延迟，例如由于使用 MapReduce 或远程读取数据而导致的延迟，Impala 实现了基于守护进程的分布式架构，这些守护进程负责查询执行的所有方面，并与 Hadoop 基础架构的其余部分运行在同一台机器上。结果是性能相当于或超过商业 MPP 分析 DBMS，具体取决于特定的工作负载。

本文讨论了 Impala 为用户提供的服务，然后概述了其架构和主要组件。今天可实现的最高性能需要使用 HDFS 作为底层存储管理器，因此这是本文的重点；当在与 HBase 结合处理某些技术方面存在显著差异时，我们会在文本中注明，但不会详细说明。

Impala 是性能最高的 SQL-on-Hadoop 系统，尤其是在多用户工作负载下。正如第 7 节所示，对于单用户查询，Impala 比替代方案快 13 倍，平均快 6.7 倍。对于多用户查询，差距扩大：Impala 比替代方案快 27.4 倍，平均快 18 倍——多用户查询的平均速度是单用户查询的近三倍。

本文的其余部分结构如下：下一部分从用户的角度概述 Impala，并指出它与传统 RDBMS 的不同之处。第 3 节介绍了系统的整体架构。第 4 节介绍前端组件，其中包括基于成本的分布式查询优化器，第 5 节介绍后端组件，负责查询执行并使用运行时代码生成，第 6 节介绍资源/工作负载管理组件。第 7 节简要评估了 Impala 的性能。 第 8 节讨论未来的规划，第 9 节进行总结。

2. IMPALA 的用户视图

Impala 是一个集成到 Hadoop 环境中的查询引擎，并利用许多标准的 Hadoop 组件（Metastore、HDFS、HBase、YARN、Sentry）来提供类似 RDBMS 的体验。 但是，本节的其余部分将指出一些重要的差异。

Impala 特别注重与标准商业智能环境的集成，并为此支持大多数相关的行业标准：客户端可以通过 ODBC 或 JDBC 连接；使用 Kerberos 或 LDAP 完成身份验证；授权遵循标准的 SQL 角色和权限（这是由另一个名为 Sentry [4] 的标准 Hadoop 组件提供的，它还使 Hive 和其他组件可以使用基于角色的授权。）。为了查询 HDFS 存储的数据，用户通过熟悉的 CREATE TABLE语句创建表，该语句除了提供数据的逻辑模式外，还指示物理布局，例如文件格式和在 HDFS 目录结构。然后可以使用标准 SQL 语法查询这些表。

2.1 物理模式设计

创建表时，用户还可以指定分区列的列表：

CREATE TABLE T (...) PARTITIONED BY (day int, month int) LOCATION '<hdfs-path>' STORED AS PARQUET;

对于未分区表，数据文件默认直接存储在根目录（但是，位于根目录下任何目录中的所有数据文件都是表数据集的一部分。 这是处理未分区表的常用方法，Apache Hive 也采用这种方法。）中。对于分区表，数据文件放置在路径反映分区列值的子目录中。例如，对于表 T 的第 2 个月第 17 天的所有数据文件都将位于目录 <root>/day=17/month=2/ 中。请注意，这种分区形式并不意味着单个分区的数据的位置：一个分区的数据文件块随机分布在 HDFS 数据节点上。

在选择文件格式时，Impala 还为用户提供了极大的灵活性。它目前支持压缩和未压缩的文本文件、序列文件（一种可拆分的文本文件形式）、RCFile（一种传统的列格式）、Avro（一种二进制行格式）和 Parquet，这是最高性能的存储选项（第 5.3 节将更详细地讨论文件格式）。如上面的例子所示，用户在 CREATE TABLE 或 ALTER TABLE 语句中指明存储格式。也可以单独为每个分区选择单独的格式。例如，可以使用以下命令将特定分区的文件格式具体设置为 Parquet：ALTER TABLE PARTITION(day=17, month=2) SET FILEFORMAT PARQUET。

作为这样设置是有用的一个示例，请考虑包含按时间顺序记录的数据（例如点击日志）的表。当天的数据可能以 CSV 文件的形式出现，并在每天结束时批量转换为 Parquet。

2.2 SQL 支持

Impala 支持大多数 SQL-92 SELECT 语句语法，以及额外的 SQL-2003 分析函数，以及大多数标准标量数据类型：整数和浮点类型、STRING、CHAR、VARCHAR、TIMESTAMP 和最多 38 位精度的 DECIMAL。自定义应用的逻辑可以使用 Java 和 C++ 中的用户定义函数 (UDF) 和用户定义聚合函数 (UDA) ，目前仅支持 C++ 。

由于 HDFS 作为存储管理器的局限性，Impala 不支持 UPDATE 或 DELETE，并且本质上只支持批量插入（INSERT INTO ... SELECT ...）（我们还应该注意到 Impala 支持 VALUES 子句。 但是，对于 HDFS 支持的表，这将为每个 INSERT 语句生成一个文件，这会导致大多数应用的性能非常差。 对于 HBase 支持的表，VALUES 变体通过 HBase API 执行单行插入。）。与传统的 RDBMS 不同，用户可以使用 HDFS 的 API 简单地通过将数据文件复制/移动到该表的目录位置来将数据添加到表中。或者，可以使用 LOAD DATA 语句完成相同的操作。

与批量插入类似，Impala 通过删除表分区（ALTER TABLE DROP PARTITION）支持批量数据删除。由于无法原地更新 HDFS 文件，因此 Impala 不支持 UPDATE 语句。相反，用户通常重新计算数据集的一部分再合并更新，然后替换相应的数据文件，通常是通过删除和重新添加分区实现。

在初始数据加载之后，或者每当表数据的很大部分发生变化时，用户应该运行 COMPUTE STATS <table> 语句，该语句指示 Impala 收集表的统计信息。这些统计信息随后将在查询优化期间使用。

3. 架构

Impala 是一个大规模并行查询执行引擎，它运行在现有 Hadoop 集群中的数百台机器上。它与底层存储引擎分离，这与传统的关系数据库管理系统不同，在传统的关系数据库管理系统中，查询处理和底层存储引擎是单个紧密耦合系统的组件。Impala 的高层架构如图 1 所示。

图 1：Impala 是 Hadoop 生态系统的分布式查询处理系统。 此图还显示了查询处理期间的流程。

Impala 部署由三个服务组成。Impala 守护进程 (impalad) 服务既负责接受来自客户端进程的查询并协调它们在整个集群中的执行，又代表其他 Impala 守护进程执行单个查询片段。当 Impala 守护进程通过管理查询执行以第一个角色运行时，它被称为该查询的协调器。然而，所有的 Impala 守护进程都是对称的；他们都可以扮演各种角色。此特性有助于容错和负载均衡。

一个 Impala 守护进程部署在集群中的每台机器上，这些机器也运行一个 datanode 进程——底层 HDFS 部署的块服务器——因此通常每台机器上都有一个 Impala 守护进程。这使得 Impala 能够利用数据本地性，并在无需使用网络的情况下从文件系统读取块。

Statestore 守护进程（statestored）是 Impala 的元数据发布订阅服务，它将集群范围的元数据传播到所有 Impala 进程。只有一个单一的 statestored 实例，在下面的第 3.1 节中有更详细的描述。

最后，第 3.2 节中描述的 Catalog 守护进程 (catalogd) 充当 Impala 的目录存储库和元数据访问网关。通过catalogd，Impala 守护进程可以执行反映在外部目录存储（例如Hive Metastore）中的DDL 命令。对系统目录的更改通过 statestore 广播。

所有这些 Impala 服务，以及一些配置选项，例如资源池的大小、可用内存等（有关资源和工作负载管理的更多详细信息，请查看第 6 节），也暴露给 Cloudera Manager，一个复杂的集群管理应用。Cloudera Manager 不仅可以管理 Impala，还可以管理几乎所有服务，以获得 Hadoop 部署的整体视图。

3.1 状态分布

旨在在数百个节点上运行的 MPP 数据库设计的一个主要挑战是集群范围元数据的协调和同步。Impala 的对称节点架构要求所有节点都必须能够接受和执行查询。Impala 的对称节点架构要求所有节点都必须能够接受和执行查询。因此，所有节点都必须具有例如最新版本的系统目录和 Impala 集群成员的最新视图，以便可以正确调度查询。

我们可能会通过部署一个单独的集群管理服务来解决这个问题，其中包含所有集群范围元数据的真实准确版本。Impala 守护进程可以懒查询这个存储（即仅在需要时），从而确保所有查询都得到最新的响应。然而，Impala 设计的一个基本原则是在任何查询的关键路径上尽可能避免同步 RPC。如果没有重点关注这些成本，我们发现查询延迟通常会因建立 TCP 连接或加载某些远程服务所花费的时间而受到影响。相反，我们将 Impala 设计为向所有感兴趣的各方推送更新，并设计了一个简单的发布订阅服务，称为 statestore，将元数据更改传播给一组订阅者。

statestore 维护一组主题，它们是三元组（键、值、版本）条目的数组，其中“键”和“值”是字节数组，“版本”是 64 位整数。主题由应用定义，因此 statestore 不了解任何主题条目的内容。主题在 statestore 的整个生命周期中都是持久存在的，除了在服务重启后没有持久存在。希望接收任何主题更新的进程称为订阅者，并在启动时向 statestore 注册并提供他们感兴趣的主题列表。statestore 通过向订阅者发送每个注册主题的初始主题更新来响应注册，其中包含当前在该主题中的所有条目。

注册后，statestore 会定期向每个订阅者发送两种消息。第一种消息是主题更新，包含自上次更新成功发送给订阅者以来对主题的所有更改（新条目、修改条目和删除）。每个订阅者维护一个每个主题的最新版本标识符，它允许 statestore 仅在更新之间发送增量信息。作为对主题更新的响应，每个订阅者发送它希望对其订阅主题进行操作的相关更改列表。保证在收到下一次更新时这些更改已经被 statestore 应用了。

第二种 statestore 发送的消息是keepalive。statestore 使用 keepalive 消息来维护与每个订阅者的连接，否则订阅者将超时并尝试重新注册。先前版本的 statestore 将主题更新消息同时用于这两个目的，但随着主题更新的大小增加，确保及时向每个订阅者交付更新变得困难，导致订阅者的故障检测过程中出现误报。

如果 statestore 检测到失败的订阅者（例如，通过重复失败的 keepalive 交付来检测），它将停止发送更新。一些主题条目可能被标记为“暂态”，这意味着如果“拥有”他们的订阅者失败，他们将被删除。这是一个自然原语，用于在专用主题中维护集群的活跃度信息，以及每个节点的负载统计信息。

statestore 提供了非常弱的语义：订阅者可能以不同的速率更新（尽管 statestore 尝试公平地分发主题更新），因此可能看到的主题内容非常不同。然而，Impala 只使用主题元数据在本地做出决策，没有任何跨集群的协调。例如，基于目录元数据主题在单个节点上执行查询计划，一旦计算出完整计划，执行该计划所需的所有信息都会直接分发到执行节点。执行节点不需要知道相同版本的目录元数据主题。

尽管现有 Impala 部署中只有一个 statestore 进程，但我们发现它可以很好地扩展到中型集群，并且通过一些配置，可以为我们最大的部署集群提供服务。statestore 不会将任何元数据持久化到磁盘：所有当前元数据都由活跃订阅者推送到 statestore（例如负载信息）。因此，如果 statestore 重新启动，则可以在初始订阅者注册阶段恢复其状态。或者，如果运行 statestore 的机器出现故障，则可以在其他地方启动一个新的 statestore 进程，并且订阅者可能会故障然后转移到这个新进程。Impala 中没有内置的故障恢复机制，而是部署集群通常使用可重定向的 DNS 条目来强制订阅者自动移动到新的进程实例。

3.2 目录服务

Impala 的目录服务通过 statestore 广播机制为 Impala 守护进程提供目录元数据，并代表 Impala 守护进程执行 DDL 操作。目录服务从第三方元数据存储（例如 Hive Metastore 或 HDFS Namenode）中拉取信息，并将该信息聚合到与 Impala 兼容的目录结构中。这种架构允许 Impala 对其所依赖的存储引擎的元数据存储保持相对透明，这允许我们相对快速地向 Impala 添加新的元数据存储（例如 HBase 支持）。对系统目录的任何更改（例如，加载新表时）都通过 statestore 传播。

目录服务还允许我们使用 Impala 特定的信息来扩充系统目录。例如，我们仅向目录服务注册用户自定义函数（例如，不将其复制到 Hive Metastore），因为它们是 Impala 特有的。

由于目录通常非常大，并且对表的访问很少是统一的，因此目录服务仅为它在启动时发现的每个表加载一个骨架条目。更详细的表元数据可以在后台从其第三方存储中延迟加载。如果在完全加载之前需要一个表，Impala 守护进程将检测到这一点并向目录服务发出优先级请求。此请求会阻塞，直到表完全加载。

4. 前端

Impala 前端负责将 SQL 文本编译为 Impala 后端可执行的查询计划。它是用 Java 编写的，由功能齐全的 SQL 解析器和基于成本的查询优化器组成，所有这些都是从头开始实现的。除了基本的 SQL 特性（select, project, join, group by, order by, limit），Impala 还支持内联视图、不相关和相关的子查询（被重写为连接）、外连接的所有变体以及显式左/右半连接和反连接，以及分析窗口函数。

查询编译过程遵循传统的分工：查询解析、语义分析和查询计划/优化。我们将重点关注查询编译中最具挑战性的后一个部分。提供了一个解析树以及在语义分析期间组装的查询全局信息（表/列标识符、等价类等）作为 Impala 查询计划器输入。一个可执行的查询计划分两个阶段构成：（1）单节点计划和（2）计划并行化和碎片化。

第一阶段，解析树被翻译成不可执行的单节点计划树，由以下计划节点组成：HDFS/HBase 扫描、hash join、cross join、union、hash 聚合、排序、top-n ，和分析计算。这一步负责在尽可能底层的计划节点分配谓词，根据等价类推断谓词，裁剪表分区，设置限制/偏移量，应用列投影，以及执行一些基于成本的计划优化，例如排序和合并分析窗口函数和连接重排序以最小化总评估成本。成本估算基于表/分区基数加上每列的基数（我们使用 HyperLogLog 算法 [5] 进行去重值估计。）；直方图目前不是统计数据的一部分。Impala 使用简单的启发式方法来避免在常见情况下详尽地枚举和计算整个连接顺序空间。

第二个计划阶段以单节点计划为输入，生成分布式执行计划。总体目标是最小化数据移动并最大化扫描本地性：在 HDFS 中，远程读取比本地读取慢得多。通过在计划节点之间添加必要的交换节点，并通过添加额外的非交换计划节点来最小化网络上的数据移动（例如，本地聚合节点）来使计划分布式。在第二阶段，我们决定每个连接节点的连接策略（此时连接顺序是固定了的）。支持的连接策略有广播和分区。前者将连接的整个构建端复制到执行探测的所有集群机器上，后者在连接表达式上哈希重分布构建端和探测端。Impala 选择预估的可以最小化通过网络交换的数据量并同时利用连接输入的现有数据分区的策略。

当前所有聚合都作为本地预聚合执行，然后是合并聚合操作。对于分组聚合，预聚合输出在分组表达式上进行分区，合并聚合在所有参与节点上并行完成。对于非分组聚合，合并聚合在单个节点上完成。Sort 和 top-n 以类似的方式并行化：分布式本地 sort/top-n 之后是单节点合并操作。分析表达式计算是基于分区表达式并行化的。它依赖于根据 partition-by/order-by 表达式对输入进行排序。最后，分布式计划树在交换边界处被拆分。计划的每个这样的部分都放置在一个计划片段中，即 Impala 的后端执行单元。计划片段封装了在单个机器上的同一数据分区上运行的计划树的一部分。

图 2 举例说明了查询计划的两个阶段。该图的左侧显示了连接两个 HDFS 表 (t1, t2) 和一个 HBase 表 (t3) 的查询的单节点计划，然后是聚合和 order by with limit (top-n)。右侧显示了分布式、碎片化的计划。圆角矩形表示片段边界和箭头表示数据交换。表 t1 和 t2 通过分区策略连接。在属于它们自己的一个片段中进行扫描，因为它们的结果会立即交换给消费者（连接节点），消费者在基于哈希的数据分区上进行操作，而表数据是随机分区的。接下来与 t3 的连接是一个广播连接，与 t1 和 t2 之间的连接放置在同一片段中，因为广播连接保留了现有的数据分区（连接 t1、t2 和 t3 的结果仍然是基于 t1 和 t2 连接键的哈希分区）。在连接之后，我们执行两阶段分布式聚合，其中在与最后一个连接相同的片段中进行预聚合计算。根据分组键对预聚合结果进行哈希交换，然后再次聚合以计算最终聚合结果。同样的两阶段方法应用于 top-n，最后的 top-n 步骤在协调器处执行，它将结果返回给用户。

图 2：两阶段查询优化示例。

5.后端

Impala 的后端从前端接收查询片段并负责它们的快速执行。它旨在利用现代化硬件设施。后端是用 C++ 编写的，并在运行时使用代码生成来生成高效的代码路径（相对于指令计数）和较小的内存开销，尤其是与其他用 Java 实现的引擎相比。

Impala 利用了数十年的并行数据库研究成果。执行模型是传统的 Volcano 风格，带有 Exchange 运算符 [7]。处理是每次一批执行的：每个 GetNext() 调用都对成批的行进行操作，类似于 [10] 。除了“stop-and-go”操作符（例如排序）之外，执行完全可以流水线化，这最大限度地减少了存储中间结果的内存消耗。在内存中处理时，元组具有规范的内存中行存格式。

可能需要消耗大量内存的运算符被设计为能够在需要时将其工作集的一部分溢出到磁盘。可溢出的运算符有哈希连接、（基于哈希的）聚合、排序和分析函数计算。

Impala 对哈希连接和聚合运算符采用分区方法。也就是说，每个元组的哈希值的一些比特位确定目标分区，其余比特位用于哈希表探测。在正常操作期间，当所有哈希表都在内存中时，分区步骤的开销最小，在非溢出非分区实现的性能的 10% 以内。当存在内存压力时，一个“受害者”分区可能会溢出到磁盘，从而为其他分区释放内存以完成它们的处理。当为哈希连接构建散列表时，构建侧相关的基数减少 ，我们构建了一个布隆过滤器，然后将其传递给探测端扫描器，实现了一个简单版本的半连接。

图 3：Impala 中解释的代码与代码生成的代码。

5.1 运行时代码生成

使用 LLVM [8] 的运行时代码生成是 Impala 后端广泛采用的技术之一，以优化执行时间。5 倍或更多的性能提升对于代表性工作负载来说非常典型。

LLVM 是一个编译器库和相关工具的集合。与作为独立应用实现的传统编译器不同，LLVM 被设计为模块化和可重用的。它允许像 Impala 这样的应用在运行的进程中执行即时 (JIT) 编译，通过为编译过程中的所有步骤暴露独立的 API，具有现代优化器的全部优势和为许多架构生成机器代码的能力。

Impala 使用运行时代码生成来生成对性能至关重要的特定于查询的函数版本。特别是，代码生成应用于“内循环”函数，即那些在给定查询中执行多次（对于每个元组）的函数，因此构成查询执行总时间的很大一部分。例如，必须为扫描的每个数据文件中的每条记录调用用于将数据文件中的记录解析为 Impala 内存中元组格式的函数。对于扫描大表的查询，这可能是数十亿条记录或更多。因此，此函数必须非常高效才能获得良好的查询性能，甚至从函数的执行中删除一些指令也会导致极大的查询加速。

如果没有代码生成，为了处理程序编译时未知的运行时信息，函数执行效率低下几乎是必然的。例如，仅处理整数类型的记录解析函数在解析仅包含整数的文件时将比同时处理其他数据类型（如字符串和浮点数）的函数更快。然而，要扫描的文件的模式在编译时是未知的，因此必须使用通用函数，即使在运行时知道更有限的函数功能就足够了。

大量运行时开销的一个来源是虚函数。虚函数调用会导致很大的性能损失，特别是当被调用的函数非常简单时，因为调用不能被内联。如果在运行时知道对象实例的类型，我们可以使用代码生成将虚函数调用替换为对正确函数的直接调用，然后就可以内联。这在计算表达式树时特别有价值。在 Impala 中（和许多系统中一样），表达式由单个运算符和函数组成的树组成，如图 3 的左侧所示。可以出现在树中的每种类型的表达式都是通过覆盖表达式基类（递归调用其子表达式）中的虚拟函数实现的。许多这些表达式函数非常简单，例如，将两个数字相加。因此，调用虚函数的成本往往远远超过实际函数计算的成本。如图 3 所示，通过使用代码生成解析虚函数调用，然后内联解析后函数调用，从而可以直接计算表达式树，而没有函数调用开销。此外，内联函数增加了指令级并行性，并允许编译器进行进一步优化，例如跨表达式消除子表达式。

总的来说，JIT 编译的效果类似于自定义编码查询。例如，它消除了分支、循环展开、传播常量、偏移量、指针和内联函数。代码生成对性能有显著影响，如图 4 所示。例如，在一个 10 节点集群中，每个节点具有 8 个核、48GB RAM 和 12 个磁盘，我们测量了代码生成的影响。我们使用比例因子为 100 的 Avro TPC-H 数据库，并运行简单的聚合查询。代码生成最多可将执行速度提高 5.7 倍，并且随着查询复杂度的增加而增加。

图 4：对 Impala 中运行时代码生成性能的影响。

5.2 I/O 管理

有效地从 HDFS 检索数据是所有 SQL-on-Hadoop 系统面临的挑战。为了以接近硬件的速度从磁盘和内存执行数据扫描，Impala 使用称为短路本地读取 [3] 的 HDFS 特性在从本地磁盘读取时绕过 DataNode 协议。Impala 几乎可以以磁盘带宽（每个磁盘大约 100MB/s）进行读取，并且通常能够使所有可用磁盘饱和。我们使用 12 个磁盘测量出，Impala 能够以 1.2GB/秒的速度维持 I/O。此外，HDFS 缓存 [2] 允许 Impala 以内存总线速度访问内存驻留数据，并且还节省了 CPU 周期，因为无需复制数据块和/或校验它们。

从/向存储设备读取/写入数据是 I/O 管理器组件的职责。I/O 管理器为每个物理磁盘分配固定数量的工作线程（每个旋转磁盘一个线程，每个 SSD 磁盘八个线程），为客户端提供异步接口（例如扫描器线程）。Impala 的 I/O 管理器的有效性最近得到了 [6] 的证实，这表明 Impala 的读取吞吐量比其他测试系统高 4 到 8 倍。

5.3 存储格式

Impala 支持最流行的文件格式：Avro、RC、Sequence、纯文本和 Parquet。 这些格式可以与不同的压缩算法结合使用，例如 snappy、gzip、bz2。

在大多数用例中，我们建议使用 Apache Parquet，这是一种最先进的开源列式文件格式，可提供高压缩率和高扫描效率。它由 Twitter 和 Cloudera 在 Criteo、Stripe、Berkeley AMPlab 和 LinkedIn 的贡献下共同开发。除了 Impala，大多数基于 Hadoop 的处理框架包括 Hive、Pig、MapReduce 和 Cascading 都能够处理 Parquet。

简单来说，Parquet 是一种可定制的类 PAX [1] 的格式，针对大数据块（数十、数百、数千兆字节）进行了优化，并内置了对嵌套数据的支持。受 Dremel 的 ColumnIO 格式 [9] 的启发，Parquet 按列存储嵌套字段，并用最少的信息增强它们，以便在扫描时从列数据重新组装嵌套结构。Parquet 有一组可扩展的列编码。最新版本（Parquet 2.0）还实现了嵌入式统计：用于进一步优化扫描效率的内联列统计，例如最小/最大索引。

如前所述，Parquet 提供高压缩和扫描效率。图 5（左）比较了缩放因子为 1,000 的 TPC-H 数据库的 Lineitem 表以文件格式和压缩算法的一些流行组合存储时的磁盘大小。带有 snappy 压缩的 Parquet 实现了其中最好的压缩。同样，图 5（右）显示了当数据库以纯文本、序列、RC 和 Parquet 格式存储时，来自 TPC-DS 基准测试的各种查询的 Impala 执行时间。Parquet 始终优于所有其他格式的 5 倍。

图 5：（左）流行的文件格式和压缩方式组合的压缩率比较。（右）Impala中纯文本、SEQUENCE、RC、Parquet的查询效率对比。

6. 资源/工作负载管理

任何集群框架的主要挑战之一是谨慎控制资源消耗。Impala 通常在繁忙的集群环境中运行，其中 MapReduce 任务、摄取作业和定制框架竞争有限的 CPU、内存和网络资源。难点在于在查询之间甚至框架之间协调资源调度，而不影响查询延迟或吞吐量。

Apache YARN [12] 是 Hadoop 集群上资源中介的当前标准，它允许框架共享 CPU 和内存等资源，而无需对集群进行分区。YARN 具有集中式架构，其中框架请求 CPU 和内存资源，这些资源由中央 Resource Manager 服务仲裁。这种架构的优点是允许在完全了解集群状态的情况下做出决策，但它也对资源获取增加了显著的延迟。由于 Impala 以每秒数千个查询的工作负载为目标，我们发现资源请求和响应周期长得令人望而却步。

我们解决这个问题的方法有两部分：首先，我们实现了一个互补但独立的准入控制机制，允许用户控制他们的工作负载，而无需昂贵的集中决策。其次，我们设计了一个位于 Impala 和 YARN 之间的中间服务，目的是纠正一些负载不匹配。该服务称为 Llama for Low-Latency Application MAster，实现资源缓存、组调度和增量分配更改，同时仍将实际调度决策延缓到 YARN，用于未命中 Llama 缓存的资源请求。

本节的其余部分描述了使用 Impala 进行资源管理的两种方法。我们的长期目标是通过单一机制支持混合工作负载资源管理，该机制支持准入控制的低延迟决策制定和 YARN 的跨框架支持。

6.1 Llama 和 YARN

Llama 是一个独立的守护进程，所有 Impala 守护进程都会向它发送每个查询的资源请求。每个资源请求都与一个资源池相关联，该资源池定义了查询可能使用的集群可用资源的公平份额。

如果资源池的资源在 Llama 的资源缓存中可用，Llama 会立即将它们返回给查询。当资源争用较低时，这种快速路径允许 Llama 绕过 YARN 的资源分配算法。否则，Llama 将请求转发给 YARN 的资源管理器，并等待所有资源返回。这与 YARN 的“逐步满足”分配模型不同，后者在资源分配后才返回资源。Impala 的流水线执行模型要求所有资源同时可用，以便所有查询片段可以并行处理。

由于查询计划的资源估计，特别是在非常大的数据集上，通常不准确，我们允许 Impala 查询在执行期间调整其资源消耗估计。YARN 不支持这种模式，相反，我们让 Llama 向 YARN 发出新的资源请求（例如，要求每个节点多 1GB 的内存），然后从 Impala 的角度将它们聚合为单个资源分配。这种适配器架构使 Impala 能够与 YARN 完全集成，而其本身又不会承担处理不适配的编程接口的复杂性。

6.2 准入控制

除了与 YARN 集成以进行集群范围的资源管理之外，Impala 还具有一个内置的准入控制机制来限制传入的请求。请求被分配到资源池，并根据定义每个池限制的最大并发请求数和请求的最大内存使用量的策略来允许、排队或拒绝请求。准入控制器设计为快速且非中心化的，因此可以准入从任何 Impala 守护程序传入的请求，而无需向中央服务器发出同步请求。做出准入决策所需的状态通过 statestore 在 Impala 守护进程之间传播，因此每个 Impala 守护进程都能够基于其全局状态的聚合视图做出准入决策，而无需在请求执行路径上进行任何额外的同步通信。然而，由于共享状态是异步接收的，Impala 守护进程可能会在本地做出导致超出策略指定限制的决定。在实践中，这不是问题，因为状态通常比复杂查询更新得更快。此外，准入控制机制主要设计为简单的节流机制，而不是 YARN 等资源管理解决方案。

资源池是分层定义的。传入请求根据放置策略分配给资源池，并且可以使用 ACL 控制对资源池的访问。该配置由 YARN 公平调度程序分配文件和 Llama 配置指定，Cloudera Manager 提供了一个简单的用户界面来配置资源池，无需重新启动任何正在运行的服务即可对其进行修改。

7. 评估

本节的目的不是详尽地评估 Impala 的性能，而主要是给出一些指示。有独立的学术研究得出了类似的结论，例如 [6]。

7.1 实验设置

所有实验都在同一个 21 节点集群上运行。集群中的每个节点都是一台 2 插槽的机器，具有 2.00GHz 的 6 核 Intel Xeon CPU E5-2630L。每个节点有 64GB RAM 和 12 个 932GB 磁盘驱动器（一个用于操作系统，其余用于 HDFS）。

我们在 15TB 比例因子数据集上运行了一个决策支持风格的基准测试，该基准测试由 TPC-DS 查询的子集组成。在下面的结果中，我们根据查询访问的数据量将查询分类为交互式查询、报表查询和深度分析查询。特别地，交互式桶包含查询：q19、q42、q52、q55、q63、q68、q73和q98；报表桶包含查询：q27、q3、q43、q53、q7 和 q89；深度分析桶包含查询：q34、q46、q59、q79 和 ss_max。我们用于这些测量的工具包是公开可用的。

为了进行比较，我们使用了能够显示结果的最流行的 SQL-on-Hadoop 系统（还有其他几个用于 Hadoop 的 SQL 引擎，例如 Pivotal HAWQ 和 IBM BigInsights。 不幸的是，据我们所知，这些系统利用了 DeWitt 条款，我们在法律上被禁止对它们进行比较。）：Impala、Presto、Shark、SparkSQL 和 Hive 0.13。由于在除 Impala 之外的所有测试引擎中都缺乏基于成本的优化器，我们使用已转换为 SQL-92 样式的连接查询测试了所有引擎。为了一致性，我们对 Impala 运行了相同的查询，尽管 Impala 在没有这些转换修改的情况下也会生成相同的结果。

7.2 单用户性能

图 6 比较了四个系统在单用户运行时的性能，其中单个用户以零间隔时间重复提交查询。在所有查询运行中，Impala 在单用户工作负载上的表现优于所有替代方案。Impala 的性能优势从 2.1 倍到 13.0 倍不等，平均快 6.7 倍。实际上，早期版本的 Impala 相比 Hive 0.13（从平均 4.9 倍到 9 倍）和 Presto（从平均 5.3 倍到 7.5 倍），其性能优势的差距更大。

图 6：单用户运行时查询响应时间的比较。

7.3 多用户性能

Impala 的卓越性能在多用户工作负载中变得更加明显，多用户在现实世界的应用中无处不在。图 7（左）显示了当有 10 个并发用户从交互类别提交查询时四个系统的响应时间。在这种情况下，当从单用户到并发用户工作负载时，Impala 的性能比其他系统高 6.7 倍到 18.7 倍。根据比较，加速从 10.6 倍到 27.4 倍不等。请注意，Impala 在 10 用户负载下的速度接近是单用户负载下的一半——而替代方案的平均值仅为单用户负载下的五分之一。

同样，图 7（右）比较了四个系统的吞吐量。当 10 个用户从交互式桶提交查询时，Impala 的吞吐量比其他系统高 8.7 倍到 22 倍。

图 7：多用户运行时查询响应时间和吞吐量的比较。

7.4 与商业 RDBMS 的比较

从以上比较可以看出，Impala 在性能方面处于 SQL-on-Hadoop 系统的前列。但是 Impala 也适合部署在传统的数据仓库设置中。在图 8 中，我们将 Impala 的性能与流行的商业列式分析 DBMS 进行了比较，由于具有限制性的专有许可协议，这里称为“DBMS-Y”。我们使用比例因子为 30,000（30TB 的原始数据）的 TPC-DS 数据集，并在前面段落中介绍的工作负载下运行查询。我们可以看到 Impala 的性能比 DBMS-Y 高 4.5 倍，平均高出 2 倍，只有三个查询的执行速度更慢。

图 8：Impala 和商业分析 RDBMS 的性能比较。

8. 规划

在本文中，我们概述了 Cloudera Impala。尽管 Impala 已经对现代数据管理产生了影响并且是 SQL-on-Hadoop 系统中的性能领导者，但仍有很多工作要做。我们的规划项大致分为两类：一类是添加更传统的并行 DBMS 技术，这是解决越来越多的现有数据仓库工作负载所必需的，另一类是解决 Hadoop 环境特有的问题。

8.1 进一步的 SQL 支持

Impala 对 SQL 的支持在 2.0 版本中已经相当完整，但仍然缺少一些标准语言特性：设置 MINUS 和 INTERSECT；ROLLUP 和 GROUPING SET；动态分区裁剪；DATE/TIME/DATETIME 数据类型。我们计划在下一个版本中添加这些。

Impala 目前仅限于平面关系模式，虽然这通常足以满足预先存在的数据仓库工作负载，但我们看到越来越多的新文件格式的使用允许本质上是嵌套关系模式，并添加了复杂的列类型（结构体、数组、映射）。Impala 将被扩展以处理这些模式，以可以在单个查询中处理的嵌套层次或嵌套元素的数量没有任何限制的方式。

8.2 进一步的性能增强

计划的性能增强包括连接、聚合和排序的节点内并行化，以及更普遍地使用运行时代码生成来执行诸如网络传输的数据准备、查询输出的物化等任务。我们也在考虑为需要在查询处理期间物化的数据切换到列式规范的内存格式，以便利用 SIMD 指令 [11, 13] 。

另一个计划改进的领域是 Impala 的查询优化器。它探索的计划空间目前被刻意局限在健壮性/可预测性，部分原因是缺乏复杂的数据统计（例如直方图）和额外的模式信息（例如主/外键约束、列的可空性），这将能更准确地计算计划替代方案的成本。我们计划在中期将直方图添加到表/分区元数据中，以纠正其中一些问题。利用这些额外的元数据并以稳健的方式合并复杂的计划重写是一项具有挑战性的持续任务。

8.3 元数据和统计信息收集

在 Hadoop 环境中收集元数据和表统计信息很复杂，因为与 RDBMS 不同，新数据可以简单地通过将数据文件移动到表的根目录中来而出现。目前，用户必须发出一个命令来重新计算统计信息并更新物理元数据以包含新的数据文件，但事实证明这是有问题的：用户经常忘记发出该命令或在确切需要发出该命令时感到困惑。该问题的解决方案是通过运行后台进程自动检测新数据文件，该进程还更新元数据并调度计算增量表统计信息的查询。

8.4 自动数据转换

允许并行使用多种数据格式的更具挑战性的方面之一是格式之间的相互转换。数据通常以面向行的结构化格式（例如 Json、Avro、XML 或文本形式）添加到系统中。另一方面，从性能的角度来看，Parquet 等面向列的格式是理想的。让用户管理从一个到另一个的转换在生产环境中通常是一项重要的任务：它本质上需要建立一个可靠的数据管道（识别新数据文件，在转换过程中合并它们等），这本身需要很大的工程量。我们计划增加转换过程的自动化，以便用户可以将一个表标记为自动转换；转换过程本身搭载在后台元数据和统计数据收集过程中，该过程额外调度在新数据文件上运行的转换查询。

8.5 资源管理

在开放的多租户环境中，Impala 与 MapReduce、Spark 等其他处理框架共享集群资源的资源管理仍然是一个未解决的问题。与 YARN 的现有集成目前并未涵盖所有用例，并且 YARN 专注于拥有一个具有同步资源预留的单一预留注册表，这使得它难以适应低延迟、高吞吐量的工作负载。我们正在积极研究这个问题的新解决方案。

8.6 支持远程数据存储

Impala 目前依靠存储和计算的搭配来实现高性能。然而，像亚马逊的 S3 这样的云数据存储正变得越来越流行。此外，基于 SAN 的传统存储基础架构需要分离计算和存储。我们正在积极致力于扩展 Impala 以访问 Amazon S3（计划于 2.2 版）和基于 SAN 的系统。除了简单地用远程存储替换本地存储之外，我们还计划研究允许本地处理而不增加额外操作负担的自动缓存策略。

9. 总结

在本文中，我们介绍了 Cloudera Impala，这是一种开源 SQL 引擎，旨在将并行 DBMS 技术引入 Hadoop 环境。 我们的性能结果表明，尽管 Hadoop 起源于批处理环境，但可以在其上构建一个分析 DBMS，其性能与当前的商业解决方案一样好或更好，并同时保留了灵活性和 Hadoop 的成本效益。

在目前的状态下，Impala 已经在许多工作负载场景下可以替换传统的、单一的分析 RDBMS。我们预测，这些系统在 SQL 功能方面的差距将随着时间的推移而消失，Impala 将能够承担越来越多的现有数据仓库工作负载。然而，我们相信 Hadoop 环境的模块化特性，其中 Impala 借鉴了许多跨平台共享的标准组件，赋予了一些传统的单一 RDBMS 无法复制的优势。特别是，混合文件格式和处理框架的能力意味着单个系统可以处理更广泛的计算任务，而无需移动数据，这本身通常是组织使用它的数据的最大障碍之一。

Hadoop 生态系统中的数据管理仍然缺乏过去几十年为商业 RDBMS 开发的一些功能；尽管如此，我们预计这种差距会迅速缩小，并且开放模块化环境的优势将使其在不久的将来成为占主导地位的数据管理架构。

参考文献

1. A. Ailamaki, D. J. DeWitt, M. D. Hill, and M. Skounakis. Weaving relations for cache performance. In VLDB, 2001.
2. Apache. Centralized cache management in HDFS. Available at https://hadoop.apache.org/docs/r2.3.0/hadoop-project-dist/hadoop-hdfs/CentralizedCacheManagement.html.
3. Apache. HDFS short-circuit local reads. Available at http://hadoop.apache.org/docs/r2.5.1/hadoop-project-dist/hadoop-hdfs/ShortCircuitLocalReads.html.
4. Apache. Sentry. Available at http://sentry.incubator.apache.org/.
5. P. Flajolet, E. Fusy, O. Gandouet, and F. Meunier. HyperLogLog: The analysis of a near-optimal cardinality estimation algorithm. In AOFA, 2007.
6. A. Floratou, U. F. Minhas, and F. Ozcan. SQL-on-Hadoop: Full circle back to shared-nothing database architectures. PVLDB, 2014.
7. G. Graefe. Encapsulation of parallelism in the Volcano query processing system. In SIGMOD, 1990.
8. C. Lattner and V. Adve. LLVM: A compilation framework for lifelong program analysis & transformation. In CGO, 2004.
9. S. Melnik, A. Gubarev, J. J. Long, G. Romer, S. Shivakumar, M. Tolton, and T. Vassilakis. Dremel: Interactive analysis of web-scale datasets. PVLDB, 2010.
10. S. Padmanabhan, T. Malkemus, R. C. Agarwal, and A. Jhingran. Block oriented processing of relational database operations in modern computer architectures. In ICDE, 2001.
11. V. Raman, G. Attaluri, R. Barber, N. Chainani, D. Kalmuk, V. KulandaiSamy, J. Leenstra, S. Light-stone, S. Liu, G. M. Lohman, T. Malkemus, R. Mueller, I. Pandis, B. Schiefer, D. Sharpe, R. Sidle, A. Storm, and L. Zhang. DB2 with BLU Acceleration: So much more than just a column store. PVLDB, 6, 2013.
12. V. K. Vavilapalli, A. C. Murthy, C. Douglas, S. Agarwal, M. Konar, R. Evans, T. Graves, J. Lowe, H. Shah, S. Seth, B. Saha, C. Curino, O. O’Malley, S. Radia, B. Reed, and E. Baldeschwieler. Apache Hadoop YARN: Yet another resource negotiator. In SOCC, 2013.
13. T. Willhalm, N. Popovici, Y. Boshmaf, H. Plattner, A. Zeier, and J. Schaffner. SIMD-scan: ultra fast in-memory table scan using on-chip vector processing units. PVLDB, 2, 2009.