Impala官网介绍（翻译）

Impala（ 官网）:一个现代的、开源的 Hadoop SQL 引擎

摘要

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 的测试版发布于 2012 年 10 月，GA 版发布于 2013 年 5 月。最新版本 Impala2.0 于 2014 年 10 月发布。

Impala 的生态系统势头继续加速，自 GA 以来下载量已接近 100 万次。 与其他系统(通常是 Postgres 的分支)不同，Impala 是一个全新的引擎，用 c++和 Java 从头开始编写。它通过使用标准组件(HDFS、HBase、Metastore、YARN、 Sentry)来保持 Hadoop 的灵活性，并且能够读取大多数广泛使用的文件格式(例如 Parquet、Avro、RCFile)。为了减少延迟，比如使用 MapReduce 或远程读取数据所产生的延迟，Impala 实现了一个基于守护进程的分布式架构，守护进程负责查询执行的所有方面，并且与 Hadoop 基础设施的其他部分运行在相同的机器上。其结果是性能 (GitHub impala 开源社区)

本文在知识共享署名许可(http://creativecommons.org/licenses/by/3.0/)下
发布，该许可允许在任何媒体上分发和复制，也允许衍生作品，前提是您将原始 作品归因于作者和 CIDR 2015。第七届创新数据系统研究双年会议(CIDR ’ 15) 2015 年 1 月 4 日至 7 日，美国加利福尼亚州阿西洛马。这与商业 MPP 分析 dbms 相当或超过，具体取决于特定的工作负载。

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

Impala 是性能最高的 SQL-on-Hadoop 系统，特别是在多用户工作负载下。如 第7节 所示，对于单用户查询，Impala 比其他选择快 13 倍，平均快 6.7 倍。对 于多用户查询，差距扩大了:Impala 比其他替代品快 27.4 倍，平均快 18 倍多用户查询比单用户查询平均快近 3 倍。

本文的其余部分结构如下:下一节从用户的角度概述 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 角色和特权 2。以便查询 HDFS-resident

这是由另一个标准的 Hadoop 组件提供的，它也使基于角色的授 权对 Hive 和其他组件可用。对于 data，用户通过熟悉的 CREATE TABLE 语句创建表，该语句除了提供数据的逻辑模式外，还指示物理布局，例如文件格式和在 HDFS 目录结构中的位置。然后可以用标准 SQL 语法查询这些表。

2.1 物理模式设计

在创建表时，用户还可以指定一个分区列列表:CREATE TABLE T (…) PARTITIONED BY (day int, month int) LOCATION ’’ STORED AS PARQUET;
对于未分区的表，数据文件默认直接存储在根目录 3 中。对于分区表，数据 文件被放置在子目录中，子目录的路径反映了分区列的值。例如，对于表 T 的第 17 天，第 2 个月，所有的数据文件将位于目录/day=17/month=2/. 。请注意，这 种形式的分区并不意味着单个分区的数据并配:分区的数据文件块随机分布在 HDFS 数据节点上。

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

作为一个例子，当这很有用时，考虑一个按时间顺序记录数据的表，例如点 击日志。当天的数据可能以 CSV 文件的形式输入，并在每天结束时批量转换为 Parquet 格式。

2.2 SQL 支持

Impala 支持大多数 SQL-92 SELECT 语句语法，以及附加的 SQL-2003 分析函 数，以及大多数标准标量数据类型:整数和浮点类型、STRING、CHAR、VARCHAR、 TIMESTAMP 和精度高达 38 位的 DECIMAL。自定义应用逻辑可以通过 Java 和 c++ 中的用户自定义函数(user-defined functions, UDFs)和用户自定义聚合函数 (user-defined aggregate functions, UDAs)来合并，目前仅在 c++中。

由于 HDFS 作为存储管理器的限制，Impala 不支持 UPDATE 或 DELETE，本质 上只支持批量插入(INSERT INTO…SELECT…)与传统的 RDBMS 不同，用户可以简 单地通过复制/移动数据文件到目录中来向表中添加数据使用 HDFS 的 API 或者 可以通过 LOAD DATA 语句来完成。

3、然而，位于根目录下的所有数据文件都是表数据集的一部分。这是处理未分区表的常用方法，Apache Hive 也采用了这种方法。
4、我们还应该注意到，Impala 支持 VALUES 条款。但是，对于支持 hdfs 的表，每 个 INSERT 语句将生成一个文件，这将导致大多数应用程序的性能非常差。对于 HBase 支持的表，VALUES 变体通过 HBase API 执行单行插入。

与大容量插入类似，Impala 支持通过删除表分区(ALTER TABLE DROP PARTITION)来删除大容量数据。因为无法就地更新 HDFS 文件，所以 Impala 不支持 UPDATE 语句。相反，用户通常会重新计算部分数据集以合并更新，然后替换 相应的数据文件，通常是通过删除和重新添加分区的方式

在初始数据加载之后，或者每当表的数据有很大一部分发生变化时，用户就应该运行 COMPUTE STATS语句，指示 Impala 收集表格上的统计数据。这些统计信息将在后续的查询优化过程中使用。

3. 体系结构

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

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

集群中的每台机器上都部署了一个 Impala 守护进程，同时也运行着
datanode 进程(底层 HDFS 部署的块服务器)，因此通常每台机器上都有一个 Impala 守护进程。这允许 Impala 利用数据局部性，并且无需使用网络就可以从文件系统中读取块。

Statestore 守护进程(stateststored)是 Impala 的元数据发布-订阅服务，
它将集群范围的元数据传播到所有 Impala 进程。有一个 statestore 实例，会在下面 3.1 节详细描述。

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

所有这些 Impala 服务，以及一些配置选项，如资源池的大小，可用内存等。 (有关资源和工作负载管理的更多详细信息，请参见第 6 节)也公开给 Cloudera Manager，这是一个复杂的集群管理应用程序 5。Cloudera Manager(CDH) 不仅可以管理 Impala，还可以管理几乎所有的服务，以获得 Hadoop 部署的整体视图。

图 1:Impala 是 Hadoop 生态系统的分布式查询处理系统。这张图还展示了查询处 理过程中的流程。

3.1 状态分布

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

我们可以通过部署一个单独的集群管理服务来解决这个问题，该服务包含集 群范围内所有元数据的真实版本。然后，Impala 守护进程可以惰性地查询这个 存储(即仅在需要时)，这将确保所有查询都得到最新的响应。然而，Impala 设 计的一个基本原则是在任何查询的关键路径上尽可能避免同步 rpc。如果不密切 关注这些成本，我们发现查询延迟通常会受到建立 TCP 连接所需时间或加载某些 远程服务所需时间的影响。相反，我们将 Impala 设计为向所有相关方推送更新， 并设计了一个简单的发布-订阅服务(称为 statestore)，将元数据更改分发给一 组订阅者。

statestore 维护着一组主题，这些主题是由(key, value, version)三元组 组成的数组，称为条目，其中“key”和“value”是字节数组，“version”是 一个 64 位整数。一个主题是由应用程序定义的，因此 statestore 不了解任何主 题条目的内容。主题在 statestore 的生命周期中持续存在，但不会在服务重启 时持续存在。希望接收任何主题更新的进程被称为订阅者，并通过在启动时向 statestore 注册并提供主题列表来表达他们的兴趣。statestore 通过向订阅者发送每个已注册主题的初始主题更新来响应注册，该主题包含当前在该主题中的 所有条目。

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

第二种 statestore 消息是持久连接(keepalive)。statestore 使用 keepalive 消息来维护与每个订阅者的连接，否则会使其订阅超时并试图重新注 册。statestore 之前的版本使用主题更新消息来实现这两个目的，但随着主题更新的大小增长，很难确保及时向每个订阅者发送更新，导致订阅者的故障检测 过程出现误报。

如果 statestore 检测到一个失败的订阅者(例如，通过重复失败的持久连接 传递)，它将停止发送更新。一些主题条目可能被标记为“瞬态”，这意味着如 果它们的“拥有”订阅者应该失败，它们将被删除。这是一个很自然的原语，用 于维护专用主题中的集群活动信息，以及每个节点的负载统计信息。

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

虽然在现有的 Impala 部署中只有一个状态存储流程，但我们发现它可以很 好地扩展到中等规模的集群，并且通过一些配置，可以服务于我们最大的部署。 statestore 不会将任何元数据持久化到磁盘:所有当前的元数据都是由实时订 阅者推送到 statestore 的(例如加载信息)。因此，如果 statestore 重启，它的 状态可以在初始订阅者注册阶段恢复。或者，如果运行 statestore 的机器出现 故障，可以在其他地方启动一个新的 statestore 进程，订阅者可能会故障转移 到它。Impala 中没有内置故障转移机制，相反，部署通常使用可重新定位的 DNS 条目来强制订阅者自动移动到新的流程实例。

3.2 目录服务

Impala 的目录服务通过 statestore 广播机制向 Impala 守护进程提供目录 元数据，并代表Impala守护进程执行DDL操作。目录服务从第三方元数据存储(例 如，Hive Metastore 或 HDFS Namenode)提取信息，并将这些信息聚合到 impalaccompatible 目录结构中。这种架构允许 Impala 相对不知道它所依赖的 存储引擎的元数据存储，这允许我们相对快速地向 Impala 添加新的元数据存储 (例如 HBase 支持)。任何对系统目录的更改(例如，当新表加载完成时)都会通过 statestore 传播。

目录服务还允许我们使用特定于 impala 的信息来扩展系统目录。例如，我 们只在目录服务中注册用户定义的函数(例如，不将其复制到 Hive Metastore)， 因为它们是特定于 Impala 的。

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

4. 前端

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

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

在第一阶段，解析树被转换成一个不可执行的单节点计划树，该计划树包括 以下几个计划节点:HDFS/HBase 扫描、哈希连接、交叉连接、联合、哈希聚合、 排序、top-n 和分析求值。这一步负责在尽可能低的计划节点上分配谓词，根据 等价类推断谓词，修剪表分区，设置限制/偏移量，应用列投影，以及执行一些 基于成本的计划优化，如排序和合并分析窗口函数和连接重排，以最小化总评估 成本。成本估计是基于表/分区基数加上每个列的不同值计数 6;直方图目前不是 统计的一部分。Impala 使用简单的启发式来避免在常见情况下穷尽枚举和耗费 整个联合顺序空间。

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

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

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

6 我们使用 HyperLogLog 算法[5]进行不同的值估计。图 2:两阶段查询优化的例子。

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

5. 后端

Impala 的后端接收来自前端的查询片段，并负责它们的快速执行。它的设 计充分利用了现代硬件的优势。后端是用 c++编写的，并在运行时使用代码生成 来产生高效的代码路径(相对于指令计数)和较小的内存开销，特别是与其他用 Java 实现的引擎相比。

Impala 利用了并行数据库数十年的研究成果。执行模型是传统的火山式与 交易所运营商[7]。处理是批量执行的:每个 GetNext()调用都在批量的行上操 作，类似于[10]。除了“走走停停”的操作符(例如排序)，执行是完全可流水线 的，这将存储中间结果的内存消耗降到最低。在内存中处理时，元组具有规范的 内存中面向行格式。

可能需要消耗大量内存的操作符被设计为能够在需要时将其工作集的部分 溢出到磁盘。可溢出的操作符包括散列连接、(基于散列的)聚合、排序和解析函 数计算。

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

图3:Impala中的解释代码和编码代码。

5.1 运行时代码生成

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

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

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

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

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

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

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

5.2 I / O 管理

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

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

5.3 存储格式

Impala 支持最流行的文件格式:Avro, RC，序列，纯文本和 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 具有一组可 扩展的列编码。版本 1.2 支持游程和字典编码，版本 2.0 增加了对 delta 和优化的字符串编码的支持。最新版本(Parquet 2.0)也实现了嵌入式统计:内联列统 计，进一步优化扫描效率，例如最小/最大索引。

如前所述，Parquet 提供了高压缩和扫描效率。图 5(左)比较了缩放因子为 1000 的 TPC-H 数据库的 Lineitem 表在以一些流行的文件格式和压缩算法组合存 储时在磁盘上的大小。具有弹性压缩的 Parquet 在其中达到了最好的压缩效果。 类似地，图 5(右)显示了当数据库以纯文本、Sequence、RC 和 Parquet 格式存储 时，来自 TPC-DS 基准测试的各种查询的 Impala 执行时间。Parquet 一贯优于所 有其他格式高达 5 倍。

图5:(左)流行的文件格式和压缩组合的压缩比比较。(右)Impala中plain text、SEQUENCE、RC和Parquet的查询效率比较。

6. 资源/工作负载管理

任何集群框架的主要挑战之一是仔细控制资源消耗。Impala 经常运行在一
个繁忙的集群环境中，在这个环境中，MapReduce 任务、摄取任务和定制框架会
争夺有限的 CPU、内存和网络资源。困难在于在不影响查询延迟或吞吐量的情况
下，协调查询之间，甚至框架之间的资源调度。

Apache YARN[12]是 Hadoop 集群上资源中介的当前标准，它允许框架在不划
分集群的情况下共享 CPU 和内存等资源。YARN 具有集中式体系结构，其中框架
对 CPU 和内存资源发出请求，这些请求由中央资源管理器服务仲裁。这种架构的
优点是允许在完全了解集群状态的情况下做出决策，但它也对资源获取施加了显
著的延迟。由于 Impala 的目标工作负载是每秒数千个查询，因此我们发现资源
请求和响应周期非常长。

我们解决这个问题的方法有两个方面:首先，我们实现了一个互补但独立的
准入控制机制，允许用户控制他们的工作负载，而不需要昂贵的集中决策。其次，
我们设计了一个介于Impala和YARN之间的中介服务，旨在纠正一些阻抗不匹配。
这个服务被称为 Llama (Low-Latency Application MAster)，它实现了资源缓
存、队列调度和增量分配更改，同时对于没有到达 Llama 缓存的资源请求，仍然
将实际的调度决策推迟到 YARN。

本节的其余部分将介绍使用 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-onHadoop 系统，我们能够显示结 果 8:Impala、Presto、Shark、SparkSQL 和 Hive 0.13。由于在除 Impala 之外 的所有测试引擎中都缺乏基于成本的优化器，我们使用已转换为 SQL-92 风格连 接的查询对所有引擎进行了测试。为了保持一致性，我们对 Impala 进行了相同的查询，尽管 Impala在没有这些修改的情况下产生了相同的结果。

每个引擎都 评估了它在哪个文件格式上表现最好，同时始终使用 Snappy 压缩来确保公平的
比较:Apache Parquet 上的 Impala, ORC 上的 Hive 0.13, RCFile 上的 Presto, Parquet 上的 SparkSQL。

7.2 单用户性能

图6比较了四个系统的性能在单用户运行时，单个用户重复提交查询而没有思考时间。Impala的性能优于所有在单用户工作负载上运行所有查询的替代方案。Impala的性能优势在2.1x到13.0x之间平均速度是6.7倍。实际上，与Hive 0.13相比，这是一个更大的性能优势差距(从平均5.3倍到7.5倍)来自早期版本的Impala

7 https://github.com/cloudera/impala-tpcds-kit
8 Hadoop 还有其他几个 SQL 引擎，例如 Pivotal HAWQ 和 IBM BigInsights。不幸
的是，据我们所知，这些系统利用了 DeWitt 条款，我们在法律上被禁止与它们
进行比较。

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

7.3 Mutli-User 性能

Impala 的卓越性能在多用户工作负载中变得更加明显，这在现实世界的应 用程序中无处不在。图 7(左)显示了当有 10 个并发用户提交来自交互式类别的 查询时，4 个系统的响应时间。在这个场景中，当从单用户工作负载切换到并发 用户工作负载时，Impala 的性能比其他系统高出 6.7 倍到 18.7 倍。根据不同的 对比，加速比从 10.6x 到 27.4x 不等。值得注意的是，Impala 在 10 用户负载下 的速度几乎是单用户负载下的一半，而其他替代方案的平均速度仅为单用户负载 下的五分之一。

类似地，图 7(右)比较了四种系统的吞吐量。当 10 个用户从交互桶中提交 查询时，Impala 的吞吐量比其他系统高 8.7 倍到 22 倍。

7.4 与商业 RDBMS 进行比较

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

8. 路线图

本文概述了Cloudera Impala。尽管Impala已经对现代产生了影响作为sql - hadoop系统中性能领先的数据管理系统，还有很多工作要做。我们的路线图项目大致分为两类:添加而更传统的并行DBMS技术需要解决越来越多的现有的数据仓库工作负载，以及问题的解决方案这在某种程度上是Hadoop环境特有的。

9 https://blog.cloudera.com/

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

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

8.1 附加 SQL 支持

Impala 对 SQL 的支持在 2.0 版本中是相当完整的，但是仍然缺少一些标准 的语言特性:set 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 以访问亚马逊 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, M. Skounakis。为缓存性 能编织关系。在 VLDB, 2001。

[2] Apache[2]。HDFS 集中缓存管理。可在 https://hadoop.apache.org/docs/r2.3.0/hadoopproject-dist/hadoop-hdfs/ CentralizedCacheManagement.html 获取。

[3] Apache[3]。HDFS 本地读短路。可在 http://hadoop.apache.org/docs/r2.5.1/hadoop-projectdist/hadoop-hdfs/S hortCircuitLocalReads.html 下载。

[4] Apache[4]。哨兵。可在 http://sentry.incubator.apache.org/下载。

[5] P. Flajolet、E. Fusy、O. Gandouet、F. Meunier。HyperLogLog:近最 优基数估计算法的分析。在 AOFA, 2007 年。

[6] A. Floratou、U. F. Minhas、F. Ozcan。SQL-onHadoop:回到无共享数 据库架构的完整循环。PVLDB, 2014 年。

[7] G. Graefe。火山查询处理系统中的并行性封装。在 SIGMOD, 1990 年。

[8] C.拉特纳，V. Adve。LLVM:用于终身程序分析和转换的编译框架。在 CGO, 2004 年。

[9] S. Melnik、A. Gubarev、J. J. Long、G. Romer、S. Shivakumar、M. Tolton、 T. Vassilakis。Dremel:网络规模数据集的交互式分析。PVLDB, 2010 年。

[10] S. Padmanabhan, T. Malkemus, R. C. Agarwal, A. jinggran。现代 计算机体系结构中关系数据库操作的面向块处理。2001 年，ICDE。

[11] V. Raman、G. Attaluri、R. Barber、N. Chainani、D. Kalmuk、V. KulandaiSamy、J. Leenstra、S. Lightstone、S. Liu、G. M. Lohman、T. Malkemus、 R. Mueller、I. Pandis、B. Schiefer、D.Sharpe、R. Sidle、A. Storm 和 L. Zhang。带 BLU 加速的 DB2:远不止是一个列式存储。Pvldb, 2013年第 6 期。

[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、E. baldeschwiwer。Apache Hadoop YARN:又 一个资源谈判者。SOCC, 2013。

[13] T. Willhalm, N. Popovici, Y. Boshmaf, H. Plattner, A. Zeier, J. Schaffner。SIMD-scan:使用片上向量处理单元的超快内存表扫描。Pvldb, 2009 年 2 期。