Impala--组件与架构（一）

Impala

介绍

• 支持HDFS，HBASE数据的高性能，低延迟的交互式SQL查询。
• 基于hive使用内存计算，兼顾数据仓库，具有批处理，实时，多并发的优点。

用人话翻译一下

• 高性能：基于内存。
• 低延迟：不会低到ms级别。
• 基于hive：hive相关模块有元数据模块，保存了海量数据文件内容的元数据；compile模块将SQL转化为MR；HIVE去执行SQL任务，无非是直接调用HDFS的API，又或者转化为MR去处理数据。元数据这个模块是很优秀的，hive的元数据模块其实就是以表的数据模型抽象了所有的文件数据集。除了表的数据模型，也可以用流式，dataset等等模型，模型不同，操作方法不同。基于hive只是基于hive的元数据模块。
• 使用内存：hive是转成MR的，MR又是基于磁盘的，所有中间结果都需要落磁盘。磁盘的优点就是稳定可靠，中间有步骤失败了，还可以从上一步磁盘结果重来，impala基于内存计算，中间所有结果都不落地磁盘，所以一旦中间有错误，任务直接失败，从头再来。
• 兼顾数仓：最好不要，数仓就是存放历史静态数据的，不需要你有多快，需要稳定。
• 与hive的关系：两者是共用元数据模块，背对背的关系，HIVE用MR和HDFS的API，Impala直接操作HDFS

优点

• 基于内存
• 无需转化为MR，直接读取HDFS
• C++编写，速度快
• 兼容HiveSQL
• 具有数仓特性，可直接对hive直接进行数据分析
• 支持DataLocal（将元数据库所有元数据预加载到内存）
• 支持列式存储（行式存储查询时不见得查所有字段，列式减少IO）

缺点

• 对内存依赖大（CDH公司推荐放ImpalaServer的机器内存128G）
• 完全依赖于HIVE，稳定性不如HIVE
• C++编写，开源性，移植性不太好（os:C++太难了=_=）
• 实际做时，分区超过1W，性能下降严重（基于内存计算，粒度不同，分组太多太吃内存）

架构&核心组件

impala是个无主模型

• StateStore Daemon：收集分布在集群中各个impalad进程的资源信息（心跳），各节点健康状况，同步节点信息，一个实例。
• Catalog Daemon：从hive元数据库拉取元数据（不是实时的，启动拉一次，其他更新手动拉取），交给statestore分发表的元数据信息到各个impalad进程（所以最好部署在statestore节点上）；如果有DDL操作，impalad心跳发给statestore，statestore再发给Catalog，statestore广播给impalad，更新每个节点的元数据，保持一致性，同时Catalog更新给hive，一个实例。
• Impala Daemon：接收client，hue，jdbc，odbc请求，query执行并返回给中心协调节点，也是子节点的守护进程，负责向statestore汇报结果，保持通信，多个实例，和DataNode一比一。