Impala在国双的使用（一）：Impala架构和概念介绍

• • Impala是什么
  • 为什么国双采用Impala
  • Impala架构
    • Impalad
    • Catalogd
    • Statestored
  • Impala的资源池
    • Memory Limit
    • 软隔离

Impala是什么

Cloudera Impala是一个分布式的海量关系型数据查询引擎，有以下特点：

• 低延时，非常适合交互式查询的场景。我们和Hive on Tez, Azure SQL Data Warehouse做过查询性能对比，Impala的性能优势非常明显。
• Impala和Hive共享元数据和存储数据，使得Hive和SparkSQL生成的数据可以在Impala里刷新后直接查询，这一点非常重要，因为目前业内广泛采用Hive和SparkSQL做数据的ETL，ETL后数据只要简单刷新就可以在Impala里做交互式查询，为网站，APP等客户端直接提供及时的数据服务。
• 构建在Hive和HDFS的基础之上，由于Hive和HDFS都是业内久经考验的成熟技术，基本不会出现数据丢失或者集群彻底挂掉的情况。Hive和HDFS网上信息非常多，很多Impala问题可以从Hive和HDFS的角度来解决，降低了排查和解决问题的成本。
• 可扩展性强，扩展成本低：其他分布式数据库例如GreenPlum在可扩展性上有很多问题，根据 https://gpdb.docs.pivotal.io/500/admin_guide/expand/expand-redistribute.html GreenPlum在加节点后需要手动Redistributing来把老数据搬运到新节点上，在Redistributing期间对集群整体性能有较大影响，而且正在Redistributing的Table或者分区会被锁上无法访问。而Impala只要加HDFS和Impala节点就可以完成扩容，HDFS Balancer会负责数据缓慢迁移，而扩容期间查询性能几乎不会受任何影响。

为什么国双采用Impala

作为国内第一家在纳斯达克上市的大数据公司，国双每天处理和查询的数据量级非常大，所以我们采用了业界比较通用的Spark和Hive进行数据ETL，每天无论是国双的咨询师还是外部客户都需要在海量数据中第一时间得到有用的信息，而Cloudera Impala提供了这一能力。

Impala架构

官网上对Impala的架构和组件有一些介绍：https://www.cloudera.com/documentation/enterprise/5-8-x/topics/impala_components.html#intro_components 但说的并不非常清晰 。Impala由三大组件构成：

Impalad

基本是每个DataNode上都会启动一个Impalad进程，Impalad主要扮演两个角色：

• Coordinator：
  • 负责接收客户端发来的查询，解析查询，构建查询计划
  • 把查询子任务分发给很多Executor
  • 收集Executor返回的结果，组合后返回给客户端
  • 对于客户端发送来的DDL，提交给Catalogd处理
• Executor：
  • 执行查询子任务，将子任务结果返回给Coordinator

在Impala2.9中增加了新的Feature：is_executor and is_coordinator 。可以指定一个Impalad只作为Executor或者Coordinator。可以减轻Coordinator的负担，而且让职责单一化。

Catalogd

整个集群只有一个Catalogd，负责所有元数据的更新和获取。每个Impalad本地会缓存元数据信息。在Impala集群中Catalogd主要处理DDL，和Hive MetaStore通信，在Hive MetaStore里更新表的Schema。在Impala集群中Catalogd可以算是一大瓶颈，所以Impala本身不是一个很好的ETL工具，不适合承载大量的DDL操作。如果业务上允许最好是可以在Hive来做DDL，Impala只是做查询引擎。这个系列后续文章会仔细分析Catalogd的问题。

Statestored

整个集群只有一个Statestored，作为集群的订阅中心，负责集群不同组件的信息同步。所谓订阅如下图：

如上图所示各组件会在StateStored里订阅某个Topic，例如组件1，组件2，组件3订阅了Topic_1。于是StateStored会定期给组件1、组件2、组件3发送心跳，心跳的内容就是这个Topic的数据。订阅者例如组件1可以更新数据然后作为心跳的Response返回给StateStored，这样在下一次StateStored发送给组件2、组件3的心跳里就包含了组件1对于Topic_1的更新。上图中组件2同时订阅了两个Topic，StateStored会把两个Topic的数据通过过一次心跳发给组件2，不会发送两次。

目前已知的Topic有：

• impala-membership ：负责全局广播每个Impalad节点的进程健康状态，各Impalad都订阅了这个Topic，所以StateStored会定期发送这个Topic的心跳，广播所有节点的健康信息，也从心跳的Response得到所有节点的健康状态。
• catalog-update：负责广播元数据的更新，Catalogd和各Impalad都订阅了这个Topic。所以StateStored会定期发送这个Topic的心跳，Catalogd收到这个心跳后会在Response里放入更新的表元数据，StateStored收到更新后会放入下一次广播的心跳里，Impalad收到心跳后会用更新的元数据更新本地的元数据信息。
• impala-request-queue：负责广播每个Pool占用和Queue的情况，各Impalad都订阅了这个Topic，关于Pool和Queue下面一节会有详细的描述。

如果大家去看其他一些类似的分布式数据库例如Facebook的Presto，会发现其组件结构和Impala是非常类似的，虽然名字略有不同。

Impala的资源池

Impala可以划分很多资源池（Pool），用来对不同业务做资源隔离，对于一个Impala查询来说，用户可以设置使用哪个Pool，如果不设置，默认使用Default Pool。每个Pool有以下设置：

• 最大内存：Pool里的所用查询能用的总内存上限
• 最大运行查询数量：Pool里可以同时运行的最大查询数量
• Queue的长度：查询可能因为最大内存，最大运行数量等限制被Queue住。如果Queue长度已经到达这个上限，查询会被直接拒绝。
• Queue Timeout：查询在Queue里等待的时间，超过这个时间查询会被报错返回。
• Default Query Memory Limit

Memory Limit

对于一个Impala查询来说，用户可以设置 Memory Limit（mem_limit参数），就是这个查询在单个Impalad节点上能用到的内存上限，如果查询在某个节点超过了这个上限会被直接报错返回。如果用户不设置，默认使用Pool的Default Query Memory Limit，如果Pool没有设置，Impala会自己来估计这个值。据我们的使用经验来说，Impala自己估计的值非常不准确（如果表有统计信息会好一些，但还是很不准）。所以建议用户根据查询大小和复杂程度设置这个值。

mem_limit参数对查询的影响很大，例如一个查询set mem_limit = 10G，有30台Impalad节点，Impala就会认为这个查询会用到10G * 30 = 300G内存。如果Pool的剩余内存目前小于300G，查询就会被Queue住等待资源。所以mem_limit如果设置的太大会浪费内存，导致并发度降低；如果设置的太小会导致查询失败。这个系列后面会有一篇文章来说国双是如何通过机器学习的方式来解决这个问题的。

软隔离

由于Impala的每个Impalad节点都可以接受查询，对于每个Pool现在有多少查询，占了多少内存，Queue了多少，这些信息也是每个Impalad更新，通过Statestored来广播到其他Impalad，所以这个信息可能在每个节点上可能是不一致的。当一个Impalad收到查询需要做一些决策例如是否拒绝，是否Queue住，本地的这个决策信息可能是旧的，所以Impala基于Pool的资源隔离本身来说是一种软隔离，也就是说对于任何一个Pool来说，其用到的内存有可能会超过最大内存，运行的查询数量有可能会超过Pool设置的最大查询数量。这个我们在实际的使用中也证明了。软隔离问题会带来两个风险：

1. 单个节点申请的内存在某个时刻超过了分配给Impalad进程的内存，这个会导致Impalad OOM退出
2. 某个Pool在某一个时刻使用了远远超过这个Pool的资源，这个对于不同业务用Pool来做资源隔离是不利的。

这个问题我们也跟Impala社区的开发者做过讨论，最后使用的方案是：单个Pool指定唯一的Coordinator，这个Pool的所有查询都发送给同一个Impalad。于是这个Coordinator时刻都有这个资源池最新的信息，就从软隔离进化成了硬隔离，缺点是会带来单点问题，我们也采取了主备的方式来避免这一问题，后续的文章会进一步说明。