大数据时代快速SQL引擎-Impala( 六 )_导读随着大数据时代的到来

Catalog服务提供了元数据的服务，它以单点的形式存在，它既可以从外部系统（例如HDFS NameNode和Hive Metastore）拉取元数据，也负责在Impala中执行的DDL语句提交到Metatstore ，由于Impala没有update/delete操作，所以它不需要对HDFS做任何修改。之前我们介绍过有两种方式向Impala中导入数据（DDL）——通过hive或者impala ，如果通过hive则改变的是Hive metastore的状态，此时需要通过在Impala中执行REFRESH以通知元数据的更新，而如果在impala中操作则Impalad会将该更新操作通知Catalog ，后者通过广播的方式通知其它的Impalad进程。默认情况下Catalog是异步加载元数据的，因此查询可能需要等待元数据加载完成之后才能进行（第一次加载）。该服务的存在将元数据从Impalad进程中独立出来，可以简化Impalad的实现，降低Impalad之间的耦合。

除了Catalog服务， Impala还提供了StateStore服务完成两个工作：消息订阅服务和状态监测功能。 Catalog中的元数据就是通过StateStore服务进行广播分发的，它实现了一个Pub-Sub服务， Impalad可以注册它们希望获得的事件类型， Statestore会周期性的发送两种类型的消息给Impalad进程，一种为该Impalad注册监听的事件的更新，基于版本的增量更新（只通知上次成功更新之后的变化）可以减小每次通信的消息大小；另一种消息为心跳信息， StateStore负责统计每一个Impalad进程的状态， Impalad可以据此了解其余Impalad进程的状态，用于判断分配查询任务到哪些节点。由于周期性的推送并且每一个节点的推送频率不一致可能会导致每一个Impalad进程获得的状态不一致，由于每一次查询只依赖于协调者Impalad进程获取的状态进行任务的分配，而不需要多个进程进行再次的协调，因此并不需要保证所有的Impalad状态是一致的。另外， StateStore进程是单点的，并且不会持久化任何数据到磁盘，如果服务挂掉， Impalad则依赖于上一次获得元数据状态进行任务分配，官方并没有提供可靠性部署的方案，通常可以使用DNS方式绑定多个服务以应对单个服务挂掉的情况。