Impala is a new query system led by Cloudera. It provides SQL semantics and can query petabyte-scale big data stored in Hadoop's HDFS and HBase. Although the existing Hive system also provides SQL semantics, because the underlying execution of Hive uses the MapReduce engine, it is still a batch process, and it is difficult to meet the interactivity of the query. In contrast, Impala's biggest feature and biggest selling point is its speed. Before introducing Impala, we need to introduce Google's Dremel system, because Impala was originally designed with reference to the Dremel system.
Dremel is Google's interactive data analysis system. It is built on Google's GFS (Google File System) and other systems, and supports Google's data analysis service BigQuery and many other services. There are two main technical highlights of Dremel: one is to realize the column storage of nested data; the other is to use a multi-layer query tree, so that tasks can be executed in parallel on thousands of nodes and aggregated results. Column storage is not unfamiliar in relational databases. It can reduce the amount of data processed during query and effectively improve query efficiency. Dremel's column store is different in that it does not target traditional relational data, but data with nested structures. Dremel can convert records of nested structure into column storage form. When querying, read the required columns according to the query conditions, then filter the conditions, and then assemble the columns into nested records for output. Both forward and reverse transitions are implemented through efficient state machines. In addition, Dremel's multi-layer query tree draws on the design of distributed search engines. The root node of the query tree is responsible for receiving the query and distributing the query to the next layer of nodes. The bottom node is responsible for specific data reading and query execution, and then Return the result to the upper node.
Impala is a real-time interactive SQL big data query tool developed by Cloudera inspired by Google's Dremel. Impala no longer uses slow Hive+MapReduce batch processing, but uses a distributed query engine similar to that in commercial parallel relational databases (by Query Planner, Query Coordinator and Query Exec Engine), which can query data directly from HDFS or HBase with SELECT, JOIN and statistical functions, thus greatly reducing the delay. Impala is actually Dremel of Hadoop, and the column storage format used by Impala is Parquet. Parquet implements column storage in Dremel, and will support Hive in the future and add functions such as dictionary encoding and run-length encoding. The system architecture of Impala is shown in the figure. Impala uses Hive's SQL interface (including operations such as SELECT, INSERT, Join, etc.), but currently only implements a subset of Hive's SQL semantics (for example, UDF is not yet supported), and table metadata information is stored in Hive's Metastore . StateStore is a sub-service of Impala, which is used to monitor the health status of each node in the cluster and provide functions such as node registration and error detection. Impala runs a background service Impalad on each node. Impalad is used to respond to external requests and complete the actual query processing. Impalad mainly includes three modules: Query Planner, Query Coordinator and Query Exec Engine. QueryPalnner receives queries from SQL APP and ODBC, and then converts the query into many sub-queries. The Query Coordinator distributes these sub-queries to each node. The Query Exec Engine on each node is responsible for the execution of the sub-queries, and finally returns the sub-queries. As a result, these intermediate results are aggregated and finally returned to the user.
Impala mainly consists of Impalad, State Store and CLI.
Impalad
It runs on the same node as the DataNode and is represented by the Impalad process. It receives the query request from the client (the Impalad that receives the query request is the Coordinator, and the Coordinator invokes the Java front-end through JNI to interpret the SQL query statement, generates a query plan tree, and then executes it through the scheduler. The plan is distributed to other Impalads with corresponding data for execution), reads and writes data, executes queries in parallel, and streams the results back to the Coordinator through the network, and the Coordinator returns it to the client. At the same time, Impalad also maintains a connection with the State Store, which is used to determine which Impalad is healthy and can accept new work. Start three ThriftServers in Impalad: beeswax_server (connecting clients), hs2_server (borrowing Hive metadata), be_server (used internally by Impalad) and an ImpalaServer service. Each impalad instance receives, schedules, and moderates queries from clients such as ODBC or Impala Shell. Each impalad instance acts as a worker, processing query fragments distributed by other impalad instances. The client can connect to any impalad instance at will, and the connected impalad instance will act as the coordinator of the query and distribute the query to other impalad instances in the cluster for parallel computing. When all calculations are completed, other impalad instances will send their calculation results to the impalad instance acting as the Ordinator, and the Ordinator instance will return the results to the client. Each impalad process can handle multiple concurrent requests.
Impala State Store
跟踪集群中的Impalad的健康状态及位置信息，由statestored进程表示，它通过创建多个线程来处理Impalad的注册订阅和与各Impalad保持心跳连接，各Impalad都会缓存一份State Store中的信息，当State Store离线后（Impalad发现State Store处于离线时，会进入recovery模式，反复注册，当State Store重新加入集群后，自动恢复正常，更新缓存数据）因为Impalad有State Store的缓存仍然可以工作，但会因为有些Impalad失效了，而已缓存数据无法更新，导致把执行计划分配给了失效的Impalad，导致查询失败。
- 用于协调各个运行impalad的实例之间的信息关系，Impala正是通过这些信息去定位查询请求所要的数据。换句话说，state store的作用主要为跟踪各个impalad实例的位置和状态，让各个impalad实例以集群的方式运行起来。
- 与 HDFS的NameNode不一样，虽然State Store一般只安装一份，但一旦State Store挂掉了，各个impalad实例却仍然会保持集群的方式处理查询请求，只是无法将各自的状态更新到State Store中，如果这个时候新加入一个impalad实例，则新加入的impalad实例不为现有集群中的其他impalad实例所识别（事实上，经笔者测试，如果impalad启动在statestored之后，根本无法正常启动，因为impalad启动时是需要指定statestored的主机信息的）。然而，State Store一旦重启，则所有State Store所服务的各个impalad实例（包括state store挂掉期间新加入的impalad实例）的信息（由impalad实例发给state store）都会进行重建。
CLI（Impala shell）
提供给用户查询使用的命令行工具（Impala Shell使用python实现），同时Impala还提供了Hue，JDBC， ODBC使用接口。该客户端工具提供一个交互接口，供使用者发起数据查询或管理任务，比如连接到impalad。这些查询请求会传给ODBC这个标准查询接口。说白了，就是一个命令行客户端。
与Hive的关系
Impala与Hive都是构建在Hadoop之上的数据查询工具各有不同的侧重适应面，但从客户端使用来看Impala与Hive有很多的共同之处，如数据表元数据、ODBC/JDBC驱动、SQL语法、灵活的文件格式、存储资源池等。Impala与Hive在Hadoop中的关系下图所示。Hive适合于长时间的批处理查询分析，而Impala适合于实时交互式SQL查询，Impala给数据分析人员提供了快速实验、验证想法的大数据分析工具。可以先使用hive进行数据转换处理，之后使用Impala在Hive处理后的结果数据集上进行快速的数据分析。
SQL支持度：
支持SQL92中的大部分select语句， 以及SQL2003标准中的分析函数。 不支持DELETE和UPDATE， 但是支持批量装载数据（insert into select, LOAD DATA) 和批量删除数据（drop partition）。除此之外， 用户也可直接操作HDFS文件实现数据装载和清理。
查询执行
impalad分为frontend和backend两个层次， frondend用java实现（通过JNI嵌入impalad）， 负责查询计划生成， 而backend用C++实现， 负责查询执行。
frontend生成查询计划分为两个阶段：（1）生成单机查询计划，单机执行计划与关系数据库执行计划相同，所用查询优化方法也类似。（2）生成分布式查询计划。 根据单机执行计划， 生成真正可执行的分布式执行计划，降低数据移动， 尽量把数据和计算放在一起。
上图是SQL查询例子， 该SQL的目标是在三表join的基础上算聚集， 并按照聚集列排序取topN。 impala的查询优化器支持代价模型： 利用表和分区的cardinality，每列的distinct值个数等统计数据， impala可估算执行计划代价， 并生成较优的执行计划。 上图左边是frontend查询优化器生成的单机查询计划， 与传统关系数据库不同， 单机查询计划不能直接执行， 必须转换成如图右半部分所示的分布式查询计划。 该分布式查询计划共分成6个segment（图中彩色无边框圆角矩形）， 每个segment是可以被单台服务器独立执行的计划子树。
impala支持两种分布式join方式， 表广播和哈希重分布：表广播方式保持一个表的数据不动， 将另一个表广播到所有相关节点（图中t3）； 哈希重分布的原理是根据join字段哈希值重新分布两张表数据(譬如图中t1和t2）。分布式计划中的聚集函数分拆为两个阶段执行。第一步针对本地数据进行分组聚合（Pre-AGG）以降低数据量， 并进行数据重分步， 第二步， 进一步汇总之前的聚集结果（mergeAgg）计算出最终结果。 与聚集函数类似， topN也是分为两个阶段执行， （1）本地排序取topN，以降低数据量； （2） merge sort得到最终topN结果。
Backend从frontend接收plan segment并执行， 执行性能非常关键，impala采取的查询性能优化措施有
- 向量执行。 一次getNext处理一批记录， 多个操作符可以做pipeline。
- LLVM编译执行， CPU密集型查询效率提升5倍以上。
- IO本地化。 利用HDFS short-circuit local read功能，实现本地文件读取
- Parquet列存，相比其他格式性能最高提升5倍。
资源管理
impala通常与MR等离线任务运行在一个集群上， 通过YARN统一管理资源， 如何同时满足交互式查询和离线查询两种需求具有较大挑战性。 YARN通过全局唯一的Resource Mananger调度资源， 好处是RM拥有整个集群全局信息，能做出更好调度决策， 缺点是资源分配的性能不足。 Impala每个查询都需要分配资源， 当每秒查询数上千时， YARN资源分配的响应时间变的很长， 影响到查询性能。 目前通过两个措施解决这个问题：（1）引入快速、非集中式的查询准入机制， 控制查询并发度。（2）LLAM（low latency application master）通过缓存资源， 批量分配，增量分配等方式实现降低资源分配延时
Impala相对于Hive所使用的优化技术
- 没有使用MapReduce进行并行计算，虽然MapReduce是非常好的并行计算框架，但它更多的面向批处理模式，而不是面向交互式的SQL执行。与MapReduce相比：Impala把整个查询分成一执行计划树，而不是一连串的MapReduce任务，在分发执行计划后，Impala使用拉式获取数据的方式获取结果，把结果数据组成按执行树流式传递汇集，减少的了把中间结果写入磁盘的步骤，再从磁盘读取数据的开销。Impala使用服务的方式避免每次执行查询都需要启动的开销，即相比Hive没了MapReduce启动时间。
- 使用LLVM产生运行代码，针对特定查询生成特定代码，同时使用Inline的方式减少函数调用的开销，加快执行效率。
- 充分利用可用的硬件指令（2）。
- 更好的IO调度，Impala知道数据块所在的磁盘位置能够更好的利用多磁盘的优势，同时Impala支持直接数据块读取和本地代码计算checksum。
- 通过选择合适的数据存储格式可以得到最好的性能（Impala支持多种存储格式）。
- 最大使用内存，中间结果不写磁盘，及时通过网络以stream的方式传递。
Impala与Hive的异同
相同点：
- 数据存储：使用相同的存储数据池都支持把数据存储于HDFS, HBase。
- 元数据：两者使用相同的元数据。
- SQL解释处理：比较相似都是通过词法分析生成执行计划。
不同点：
执行计划：
- Hive: 依赖于MapReduce执行框架，执行计划分成map->shuffle->reduce->map->shuffle->reduce…的模型。如果一个Query会被编译成多轮MapReduce，则会有更多的写中间结果。由于MapReduce执行框架本身的特点，过多的中间过程会增加整个Query的执行时间。
- Impala: 把执行计划表现为一棵完整的执行计划树，可以更自然地分发执行计划到各个Impalad执行查询，而不用像Hive那样把它组合成管道型的map->reduce模式，以此保证Impala有更好的并发性和避免不必要的中间sort与shuffle。
数据流：
- Hive: 采用推的方式，每一个计算节点计算完成后将数据主动推给后续节点。
- Impala: 采用拉的方式，后续节点通过getNext主动向前面节点要数据，以此方式数据可以流式的返回给客户端，且只要有1条数据被处理完，就可以立即展现出来，而不用等到全部处理完成，更符合SQL交互式查询使用。
内存使用：
- Hive: 在执行过程中如果内存放不下所有数据，则会使用外存，以保证Query能顺序执行完。每一轮MapReduce结束，中间结果也会写入HDFS中，同样由于MapReduce执行架构的特性，shuffle过程也会有写本地磁盘的操作。
- Impala: 在遇到内存放不下数据时，当前版本0.1是直接返回错误，而不会利用外存，以后版本应该会进行改进。这使用得Impala目前处理Query会受到一定的限制，最好还是与Hive配合使用。Impala在多个阶段之间利用网络传输数据，在执行过程不会有写磁盘的操作（insert除外）。
调度：
- Hive: 任务调度依赖于Hadoop的调度策略。
- Impala: 调度由自己完成，目前只有一种调度器simple-schedule，它会尽量满足数据的局部性，扫描数据的进程尽量靠近数据本身所在的物理机器。调度器目前还比较简单，在SimpleScheduler::GetBackend中可以看到，现在还没有考虑负载，网络IO状况等因素进行调度。但目前Impala已经有对执行过程的性能统计分析，应该以后版本会利用这些统计信息进行调度吧。
容错：
- Hive: 依赖于Hadoop的容错能力。
- Impala: 在查询过程中，没有容错逻辑，如果在执行过程中发生故障，则直接返回错误（这与Impala的设计有关，因为Impala定位于实时查询，一次查询失败，再查一次就好了，再查一次的成本很低）。但从整体来看，Impala是能很好的容错，所有的Impalad是对等的结构，用户可以向任何一个Impalad提交查询，如果一个Impalad失效，其上正在运行的所有Query都将失败，但用户可以重新提交查询由其它Impalad代替执行，不会影响服务。对于State Store目前只有一个，但当State Store失效，也不会影响服务，每个Impalad都缓存了State Store的信息，只是不能再更新集群状态，有可能会把执行任务分配给已经失效的Impalad执行，导致本次Query失败。
适用面：
- Hive: 复杂的批处理查询任务，数据转换任务。
- Impala：实时数据分析，因为不支持UDF，能处理的问题域有一定的限制，与Hive配合使用,对Hive的结果数据集进行实时分析。
Impala的优缺点
优点：
- 支持SQL查询，快速查询大数据。
- 可以对已有数据进行查询，减少数据的加载，转换。
- 多种存储格式可以选择（Parquet, Text, Avro, RCFile, SequeenceFile）。
- 可以与Hive配合使用。
缺点：
- 不支持用户定义函数UDF。
- 不支持text域的全文搜索。
- 不支持Transforms。
- 不支持查询期的容错。
- 对内存要求高。
在Cloudera的测试中，Impala的查询效率比Hive有数量级的提升。从技术角度上来看，Impala之所以能有好的性能，主要有以下几方面的原因。
- Impala不需要把中间结果写入磁盘，省掉了大量的I/O开销。
- 省掉了MapReduce作业启动的开销。MapReduce启动task的速度很慢（默认每个心跳间隔是3秒钟），Impala直接通过相应的服务进程来进行作业调度，速度快了很多。
- Impala完全抛弃了MapReduce这个不太适合做SQL查询的范式，而是像Dremel一样借鉴了MPP并行数据库的思想另起炉灶，因此可做更多的查询优化，从而省掉不必要的shuffle、sort等开销。
- 通过使用LLVM来统一编译运行时代码，避免了为支持通用编译而带来的不必要开销。
- 用C++实现，做了很多有针对性的硬件优化，例如使用SSE指令。
- 使用了支持Data locality的I/O调度机制，尽可能地将数据和计算分配在同一台机器上进行，减少了网络开销。
虽然Impala是参照Dremel来实现的，但它也有一些自己的特色，例如Impala不仅支持Parquet格式，同时也可以直接处理文本、SequenceFile等Hadoop中常用的文件格式。另外一个更关键的地方在于，Impala是开源的，再加上Cloudera在Hadoop领域的领导地位，其生态圈有很大可能会在将来快速成长。
可以预见，在不久的未来，Impala很可能像之前的Hadoop和Hive一样在大数 据处理领域大展拳脚。Cloudera自己也说期待未来Impala能完全取代Hive。当然，用户从Hive上迁移到Impala上来是需要时间的。需要说明的是，Impala并不是用来取代已有的MapReduce系统，而是作为MapReduce的一个强力补充。总的来说，Impala适合用来处理输出数据适中或比较小的查询，而对于大数据量的批处理任务，MapReduce依然是更好的选择。另外一个消息是，Cloudera里负责Impala的架构师Marcel Komacker就曾在Google负责过F1系统的查询引擎开发，可见Google确实为大数据的流行出钱出力。
Impala与Shark，Drill等的比较
开源组织Apache也发起了名为Drill的项目来实现Hadoop上的Dremel，目前该项目正在开发当中，相关的文档和代码还不多，可以说暂时还未对Impala构成足够的威胁。从Quora上的问答来看，Cloudera有7-8名工程师全职在Impala项目上，而相比之下Drill目前的动作稍显迟钝。具体来说，截止到2012年10月底，Drill的代码库里实现了query parser, plan parser，及能对JSON格式的数据进行扫描的plan evaluator；而Impala同期已经有了一个比较完毕的分布式query execution引擎，并对HDFS和HBase上的数据读入，错误检测，INSERT的数据修改，LLVM动态翻译等都提供了支持。当然，Drill作为Apache的项目，从一开始就避免了某个vendor的一家独大，而且对所有Hadoop流行的发行版都会做相应的支持，不像Impala只支持Cloudera自己的发行版CDH。从长远来看，谁会占据上风还真不一定。
除此之外，加州伯克利大学AMPLab也开发了名为Shark的大数据分析系统。从长远目标来看，Shark想成为一个既支持大数据SQL查询，又能支持高级数据分析任务的一体化数据处理系统。从技术实现的角度上来看，Shark基于Scala语言的算子推导实现了良好的容错机制，因此对失败了的长任务和短任务都能从上一个“快照点”进行快速恢复。相比之下，Impala由于缺失足够强大的容错机制，其上运行的任务一旦失败就必须“从头来过”，这样的设计必然会在性能上有所缺失。而且Shark是把内存当作第一类的存储介质来做的系统设计，所以在处理速度上也会有一些优势。实际上，AMPLab最近对Hive，Impala，Shark及Amazon采用的商业MPP数据库Redshift进行了一次对比试验，在Scan Query，Aggregation Query和Join Query三种类型的任务中对它们进行了比较。图2就是AMPLab报告中Aggregation Query的性能对比。在图中我们可以看到，商业版本的Redshift的性能是最好的， Impala和Shark则各有胜负，且两者都比Hive的性能高出了一大截。
其实对大数据分析的项目来说，技术往往不是最关键的。例如Hadoop中的MapReduce和HDFS都是源于Google，原创性较少。事实上，开源项目的生态圈，社区，发展速度等，往往在很大程度上会影响Impala和Shark等开源大数据分析系统的发展。就像Cloudera一开始就决定会把Impala开源，以期望利用开源社区的力量来推广这个产品；Shark也是一开始就开源了出来，更不用说Apache的Drill更是如此。说到底还是谁的生态系统更强的问题。技术上一时的领先并不足以保证项目的最终成功。虽然最后那一款产品会成为事实上的标准还很难说，但是，我们唯一可以确定并坚信的一点是，大数据分析将随着新技术的不断推陈出新而不断普及开来，这对用户永远都是一件幸事。举个例子，如果读者注意过下一代Hadoop（YARN）的发展的话就会发现，其实YARN已经支持MapReduce之外的计算范式（例如Shark，Impala等），因此将来Hadoop将可能作为一个兼容并包的大平台存在，在其上提供各种各样的数据处理技术，有应对秒量级查询的，有应对大数据批处理的，各种功能应有尽有，满足用户各方面的需求。
未来展望
In fact, in addition to open source solutions such as Impala, Shark, and Drill, traditional manufacturers such as Oracle and EMC are not sitting still and waiting for their market to be swallowed by open source software. For example, EMC has launched a HAWQ system, and claims that its performance is more than ten times faster than Impala, and the aforementioned Amazon's Redshift also provides better performance than Impala. Although open source software is extremely powerful because of its strong cost advantage, traditional database vendors will still try to launch products with stronger performance, stability, maintenance services and other indicators to compete with them in a differentiated way, and participate in open source at the same time. Community, leveraging open source software to enrich their product lines, enhance their competitiveness, and meet certain consumer needs through more high-value-added services. After all, these manufacturers have often accumulated a lot of technology and experience in traditional fields such as parallel databases, and these backgrounds are still very deep. There are even NewSQL systems like NuoDB (a start-up company) that claim to support ACID and Scalability. In general, the big data analysis technology in the future will become more mature, cheaper, and easier to use; accordingly, it will be easier and more convenient for users to mine data from their own big data. Valuable business information.
References
Article source: https://www.biaodianfu.com/impala.html