impala paper笔记1 | 易学教程

不生产博客，只是汉化别人的成果

摘要

介绍

impala paper的链接

http://cidrdb.org/cidr2015/Papers/CIDR15_Paper28.pdf

摘要

impala是一个现代化，开源的mpp sql引擎架构，一开始就是为了处理hadoop环境上的数据。impala提供低延迟和高并发的query对于hadoop上的BI/OLAP，不像hive那样的批处理框架，这篇paper从使用者的角度阐述impala的总体架构和组件，简要说明Impala较别的sql on hadoop的优势

介绍

impala是开源的，最先进的mpp sql引擎，与hdaoop高度集成，高伸缩、高灵活。impala的目的是结合sql支持与传统数据库的多用户高性能(高并发)在hadoop上

不像别的系统，eg:postgre，impala是一个全新的引擎，由c++和java编写，拥有像hadoop一样的灵活性通过结合一些组件，eg:hdfs、hbase、hive metastore等等，并且能够读取常用的存储格式数据，eg:parquet、rcfile、avro等，为了降低延迟，没有使用类似mapreduce和远程拉取数据，impala实现了一个分布式的架构基于daemon进程，该进程负责接受所有的查询请求并且运行在hadoop上面，这样做的结果导致性能依赖于负载(就是并发高了查询就慢)

后面主要吹impala有多牛b，尤其在多用户环境下，吊打所有sql-on-hadoop

用户角度的impala

impala是一个集成hadoop的query引擎，可以结合一些组件比如metastore、hdfs、hbase来提供一个类rdbms的使用体验

impala专门用来与商业BI智能集成，所以客户端可以使用标准的jdbc、odbc来访问，认证通过kerberos或者ldap，授权也是标准的sql role和权限(类似sentry，role是权限的集合)，为了查询hdfs的数据，用户创建表通过类似create table的语法，提供对数据的逻辑schema，也是物理的layout，例如，hdfs的文件和目录

物理schema设计

创表的时候，用户可以指定分区

create table t (...) partitioned by (day int) location 'hdfs路径' stored as parquet

对于未分区的表，数据都存在表的目录下，对于分区的表，数据存放在表目录的子目录下，类似hive。例如对于表zlq，分区day=17的数据都放在zlq/17/下，注意，这种分区下的数据只是在hdfs的一个目录下，但block还是按128M分布在不同节点间

impala也给用户高灵活性对于选择文件格式，支持textfile的压缩与不压缩，sequence file，rcfile,avro,parquet。不仅可以对表指定一种格式，也可以对各个分区指定不同的格式

sql 支持

impala支持大部分的sql-92语法，还有部分的sql-2003 分析函数，和大多数的标准字段类型，比如整型、浮点、string,char,varchar,timestamp,decimal，也可以实现udf通过java或者c++,和udaf通过c++，当前不支持java,不知道现在支持不

由于hdfs本身的限制，impala不像传统的RDBMS,它不支持update、delete(除了kudu)，仅仅支持insert into .. select..，

用户可以通过hdfs的copy或mv数据文件到表的数据目录，也可以使用load data来加载数据

类似bulk insert,可以删除表的数据通过alter table drop partition，因为它不可能去更新hdfs的文件数据，impala不支持updata，但是可以insert overwrite某个分区

当数据load完，只要涉及到数据的change，无论什么时候，都需要compute stats <table>,将表的统计信息给到Impala优化器，以便后续查询选择最优方式

每次执行compute stats table就是给所有字段干了下面这个事,ndv类似distinct，只是不是准确值，预估，所有表越大，字段越多，compute stats时间越长

select count(*) from table

架构

impala是一个massively-parallel引擎，运行在成百上千台hadoop上，与底层存储引擎完全隔离，不像传统的RDBMS，紧密的结合在一起

impala部署需要3个角色，impalad服务负责接受客户端请求并且分发查询段在集群间，并且执行单个查询段。jdbc连的impala节点会充当查询的coordinator角色，所有的impalad服务都是平等的，这样也提供了负载均衡和容错的可能

一个impalad角色部署在有datanode的节点上，这样有利于impala从本地读取数据，不需要通过网络拉取底层数据，

statestore角色是impala的元数据的发布订阅服务，广播变化的元数据到所有的impalad节点，部署在单节点上就可以

catalog角色作为元数据访问的gateway，通过catalog，impalad可能执行ddl操作将元数据分发到外部存储例如hive metastore

这些impala的服务都是有配置选项的，比如资源池大小，可用内存等等

state distribution

状态分发，用词狂魔呀，statestore就负责分发、广播元数据

对于mpp数据库一个大的设计挑战就是怎么在那么多机器上同步元数据，impala是symmetric-node架构（各个impalad之间是平等的），要求所有计算节点都能够接收query请求并且执行查询，所以，所有的计算节点必须有最新版本的元数据和知道集群中哪些计算节点还活着，以便正确调度，避免出现把查询段分给一个已经宕掉的节点

当然可以设计成一个单独的管理节点，有整个集群的元数据，那个计算节点接收到查询请求，就去该节点拉数据，这样虽然可以保证每次的数据都是最新的，但是impala设计的时候尽量避免关键的步骤使用同步的rpc，觉得可能这样的话，在高并发场景下，每个计算节点都去请求元数据，势必会有性能瓶颈，就是查询的延迟都用来干网络连接、拉取远程信息。所以，impala设计了一个基于MQ的服务，statestore来广播元数据的改变

这个statestore包含一组topic，<key，value，version>,称它为entries，kv为二进制数组，version为64位整型，topic是别的服务定义的，statestore不负责管理里面存的什么玩意，topic的生命周期很长，但服务启停时不会持久化这些东西，订阅者期望接收到任意topic更新的信息，只要在statestore启动的时候注册、并且提供下topic即可。statestore响应这些订阅者通过发送第一次topic数据，包含当前topic所有信息，类似消费者吧，只要告诉statestore你需要那个topic，它就会不断的发变化给消费者

注册以后，statestore定期发两类信息给每个消费者，一类是topic的数据更新、删除、新增等，每个消费者包含每个topic的版本表示，所以statestore只要发送修改的信息即可，第二类是impalad的keepalive，就是那个计算节点还有心跳，超时的话将重新注册到statestore。之前版本的statestore都是使用topic来实现这两消息的传递，但是随着数据量增大，分发消息到每个消费者变得异常困难，尤其是故障检测中的误报，如果检测到失败的消费者(比如keepalive重试多次仍然失败)，将不再发送更新的元数据信息，一些topic里的entries可能被标记为'transient'，就是那个节点宕了。（一脸懵逼，不知道想表达啥，可能翻译的有问题）

statestore提供非常弱的语义，消费者可能接收更新以不同的速率(尽管statestore尝试公平分发)，所以对于一个topic的内容可能有不同的view。然而，impala仅仅使用本地的元数据来做决策，不会去读集群内别的元数据，比如，一个计算节点接到query请求，直接解析分发到别的节点，不要求别的执行节点有相同版本的元数据和解析的节点。

虽然部署的时候只有一个statestore,发现中等规模的集群下，表现还可以，(擦，也就是大了，这还是有瓶颈)，statestore不持久化元数据，只是push给活着的消费者。所以statestore被重启，计算节点会到这重新注册，所以不需要高可用，宕了，在别的节点重新起就可以了

catalog service

该服务主要服务与计算节点通过statestore的广播机制，执行ddl操作。这个服务pull信息从第三方的元数据存储(eg：hive的metastore或者hdfs的namenode），并且聚合成与Impala兼容的catalog structure，这种架构允许impala不必知道它底层的存储引擎，直接添加到元数据即可。任何对catalog系统的该表将通过statestore广播出去，该服务也允许我们扩展catalog 系统，比如只注册udf到该服务，没有持久化到hive metastore

由于catalog通常会非常大，访问这些表一般不会一下访问所有，该服务启动的时候仅仅加载一些比较粗粒度的信息，更多的详情还需访问第三方存储，如果刚启动时有对某张表的请求，该服务会优先加载该表的全部信息

当执行ddl的时候，如果使用的是Impala，那么元数据会到catalog，并持久化到hive metastore，然后当后面有query用到这张表时，会先执行invalidate metadata db.table，默认第一次用到该表的时候会拉取元数据，也可以改为创完以后就拉取，有个参数可以设置，当官网建议用到再取，一来好多表不会用户，就没必要拉元数据到每个节点，二来impala重启的时候，会加载大量无用的元数据

下面这个参数就是控制什么时候加载元数据

-load_catalog_in_background