1. 准备阶段部署Impala前必须想清楚的三件事搞大数据的人对Impala这个名字应该不陌生。它是Cloudera主导开发的开源MPP查询引擎直接跑在Hadoop生态上能吃HDFS和Hive的数据却能做到秒级交互式查询。如果你公司里有Hadoop集群又对查询响应时间有要求那Impala基本是绕不开的选项。这篇文章我就结合自己实际部署的经验把Impala的安装部署从头到尾捋一遍从架构概念到落地实操、从环境准备到踩坑排查一次讲透。开始动手之前有几个问题我建议你先想清楚。部署Impala不是装个包、起个服务那么简单它的运行方式和Hive有本质区别这几个问题没想明白后面八成要返工。1.1 为什么团队需要Impala而不是继续用Hive跑查询Hive是批处理模型每个查询提交后要启动一个或多个MapReduce任务光任务调度和进程启动的损耗就要几十秒甚至几分钟。Impala不同它借鉴了MPP数据库的并行服务思路集群里的每个节点都常驻一个impalad守护进程查询进来直接在这群常驻进程上并行执行不走MapReduce这条慢路。用Hive跑一条超过1TB数据的聚合查询等几分钟甚至十几分钟很正常。同样的查询放到Impala上几十秒内就能出结果而且对交互式跑数、临时看数这类场景非常友好。如果你的团队经常要临时跑SQL看数据、做报表联调或者BI工具直连跑实时探查Impala会是一个比Hive顺手得多的选择。有人可能会问那Spark SQL呢Spark SQL的速度也不错但Spark的调度开销决定它在低并发交互式查询场景下其实没有Impala稳定尤其是几十上百个会话同时进来的时候Spark的Driver和任务调度会成为瓶颈。Impala的架构是纯服务化的所有查询都在常驻的impalad上跑并发能力要稳得多。这也是很多数仓团队在保留Hive做离线批处理的同时、另外搭一套Impala来服务交互查询的原因。1.2 Impala核心组件与它们各自扮演的角色Impala部署完以后集群里面会有三类角色理解清楚它们的分工对后面配置和管理特别重要。第一类是Catalog Server也就是目录服务。它负责管理整个集群的元数据维护表结构、分区信息、表统计信息等。新的表结构变更、新增分区这类操作都是由CatalogServer广播给所有查询节点的。第二类是Statestore Server状态存储服务。它的职责是持续监控所有impalad的健康状态维护一个集群成员列表哪个节点挂了、哪个节点又拉起来了它都会感知到并把这变化通知给其他节点。第三类是Impala Daemon查询执行引擎。每个数据节点都会部署一个impalad它既负责接收用户的查询请求也负责真正的数据读取和计算。查询进来以后由一个impalad充当协调者把任务分发给其他节点的impalad并行执行最后汇总结果返回给客户端。1.3 先确认你的Hadoop环境能不能支撑ImpalaImpala不能独立工作它必须跑在已有的Hadoop生态之上。所以我强烈建议你按下面这张清单核对一下前置条件缺一样后面都麻烦。Hadoop集群版本尽量选2.x以上HDFS要正常可用建议启用HA模式。Impala对NameNode的RPC压力很大如果没有HA单个NameNode很容易成为瓶颈。Hive元数据库一定要就绪。Impala共享Hive的元数据但它只支持加载Hive Metastore里的表信息不支持通过Impala去建Hive的库和表之外的复杂操作。Hive Metastore建议用MySQL或者PostgreSQL存元数据不要用Derby这种内嵌模式不然并发一上来直接卡死。所有数据节点的时间要同步。这个点很多人会忽略但分布式系统的时间不同步会导致各种诡异问题建议部署ntpd或者chrony做时间同步。操作系统建议用CentOS 7.x或者Ubuntu 16.04以上版本Java版本建议JDK 8。Impala对JDK版本有明确要求太高或太低都容易出幺蛾子。确认你的HDFS上数据目录、临时目录空间充足。Impala执行中间结果缓存在本地磁盘建议每个节点至少预留数据总容量的15%-20%作为临时空间。2. 环境准备与预检部署前把地基打牢很多人部署Impala失败不是Impala本身有多难装而是前置环境没弄干净。我在这一步踩过不少坑这里把操作细节和关键参数都展开说清楚。2.1 JDK、Hadoop与Hive环境的核对与处理JDK的安装这里不赘述重点说一下环境变量的统一。Impala的启动脚本会读取JAVA_HOME目录里有空格或者权限不对启动时直接报错。建议把JDK放到/usr/local/jdk这类统一路径下并确保所有节点路径完全一致。因为Impala是分布式系统每个节点上装的JDK路径不一致的话后续用Cloudera Manager或者手工脚本分发配置会非常痛苦。Hadoop这块我提醒一个细节Impala对HDFS的权限要求比较严格建议把所有数据目录的属主设置成运行Impala的系统用户比如hive用户或者impala用户。我自己习惯在Linux下新建一个impala系统用户然后把数据节点上的Impala相关目录都chown给这个用户。不然查询的时候就会看到Permission denied: userimpala, accessREAD_EXECUTE这类报错。Hive的部署要重点确认MySQL的元数据库连接没有问题。用下面的命令快速验证Hive Metastore能否连通mysql -uhive -p -hmysql-host -e select * from hive.COLUMNS_V2 limit 3;能查出数据说明Hive Metastore这边链路是通的。如果查不出数据先去把Hive端解决掉再往下走。2.2 网络、端口、DNS与系统参数预案Impala的组件之间要通过网络通信最怕的是DNS反向解析有问题或者hostname对不上。部署前我建议把所有节点的IP和hostname都写进/etc/hosts保证集群内任何一个节点都能通过hostname访问其他节点。不要依赖DNS服务器内网环境里DNS一抖动Impala的statestore就会误判节点失联。端口方面要提前规划好Impala各服务的默认端口如下服务端口说明Impala Daemon 查询接口21000客户端连接口beeswaxImpala Daemon HS2接口21050HiveServer2兼容接口Impala Daemon Web UI25000可视化监控页面Statestore24000状态存储服务通信Catalog Server26000元数据服务通信防火墙和SELinux这两兄弟我强烈建议部署前直接确认放行或关闭状态。生产环境可以只放行上述端口但测试环境直接systemctl stop firewalld省心。SELinux如果不会配置规则直接setenforce 0不然很容易出现端口能通、但服务之间诡异失败的情况。系统层面还有一个容易被忽略的参数vm.swappiness。Impala对内存非常敏感所以建议把swappiness调到0或者10以下让内核尽量不交换内存页。操作方法是echo vm.swappiness10 /etc/sysctl.conf sysctl -p另外单节点内存建议至少32GB起步。Impala是内存大户如果节点内存太小查询稍微复杂一点就OOM你会被折磨到怀疑人生。3. 基于Cloudera Manager的Impala安装实操大部分公司的Hadoop集群都是用Cloudera Manager以下简称CM管理的CM对Impala的安装配置做了大量自动化工作。如果你已经在用CM管理CDH集群那安装Impala就像在应用商店里点一个安装按钮。3.1 CM方式部署的完整步骤与参数配置登录CM后在主页找到集群点击“添加服务”在服务列表里选择Impala。CM会检查当前集群的HDFS和Hive服务状态只要这两个服务能正常接入CMImpala就能顺利进入安装流程。接下来最关键的一步是分配角色。一个典型的Impala部署会把Catalog Server和Statestore Server放在同一个管理节点上而所有运行DataNode的节点都部署Impala Daemon。这里不要省事一定要给Statestore和Catalog独立的管理节点不要和impalad混在一起。因为impalad进程是内存敏感型的一旦某个查询把内存吃满它会拖垮同节点的state信息同步。CM会自动处理parcel包下载和分发你基本不需要手动解压什么文件。等所有节点的角色状态显示为绿色后还需要做几项重要配置。内存相关的配置要重点照顾。CM里进入Impala服务的配置页搜索mem_limit这个参数控制每个impalad进程可以使用的最大内存比例。默认值是80%也就是每个impalad最多吃掉节点内存的80%。如果你节点的内存有限或者还有其他重要服务跑在同一台机器我建议把mem_limit调到60%-70%太低会导致大查询被频繁拒绝。还要设置default_query_options在这里可以加一些默认的查询优化选项。比如PARQUET_PAGE_CHECKSUMtrue用于校验Parquet文件RUNTIME_FILTER_MODEGLOBAL可以更好地做动态分区裁剪。根据我的经验RUNTIME_FILTER_MODEGLOBAL对于大表关联的性能提升非常明显值得优先配置。CM部署方式的优势在于角色的启动顺序、配置文件分发、健康检查这些事CM全都帮你做了。你只要盯着CM页面上的状态图标所有节点的Impala Daemon都显示绿色心跳那安装基本就成了。3.2 CM部署后的目录与数据梳理安装完成后有几个目录你要心里有数。CM部署的Impala日志一般放在/var/log/impala下配置文件在/etc/impala/conf下impalad的本地临时数据在/var/lib/impala下。排障的时候顺着这几个目录去翻日志比在CM界面上瞎点高效得多。CM界面上的Impala Web UI也是个好东西。打开任何一个节点的25000端口能看到这个impalad的查询队列、内存使用、执行中的Query列表。查询卡住的时候去Web UI上直接看它的执行计划能很快定位瓶颈。4. 手工部署Impala从CDH仓库到服务拉起如果没有CM或者公司不买Cloudera的商业授权手工部署Impala也是完全可行的。虽然过程多了一点但每一步都能看到实际做了什么理解也更透彻。4.1 通过CDH仓库安装Impala组件包手工部署最省力的方式是用CDH的yum或者apt仓库。以CentOS 7为例先配置CDH的软件源然后执行sudo yum install impala impala-server impala-catalog impala-statestore impala-shell -y这条命令会安装Impala的核心服务组件和shell客户端。安装完以后核心的二进制文件在/usr/bin下配置文件集中在/etc/impala/conf下。手工部署没有CM帮忙所以Impala对Hadoop集群的配置需要我们自己手动关联。具体来说要把/etc/hive/conf/hive-site.xml和/etc/hadoop/conf/core-site.xml、hdfs-site.xml这几个配置文件拷贝或者软链到Impala的配置目录下。ln -s /etc/hive/conf/hive-site.xml /etc/impala/conf/hive-site.xml ln -s /etc/hadoop/conf/core-site.xml /etc/impala/conf/core-site.xml ln -s /etc/hadoop/conf/hdfs-site.xml /etc/impala/conf/hdfs-site.xml这一步的目的是让impalad能够识别HDFS的NameNode地址、Hive Metastore的连接信息。少了这些配置Impala服务能启动但一执行查询就会报AnalysisException: Failed to load metadata for table之类的错。4.2 手工启动Statestore、Catalog与Impala Daemon启动顺序有讲究一定要严格按照Statestore - Catalog - Impala Daemon的顺序来。Statestore先起来Catalog再启动并向Statestore注册最后启动的impalad才能从StateStore那里获取到Catalog的地址。启动Statestoreservice impala-statestore start启动Catalogservice impala-catalog start启动所有数据节点上的impaladservice impala-server start所有服务都起来之后验证一下进程是否正常ps -ef | grep impala能看到impalad、catalogd、statestored这三个进程都在跑说明服务层面的安装已经完成了。4.3 手工部署常见坑配置不生效与文件权限手工部署最常遇到的问题就是改了配置文件但不生效。Impala的很多配置参数不仅仅放在配置文件里还会被CM或启动脚本覆盖。手工部署时一定要直接看/etc/default/impala这个文件它里面的IMPALA_CATALOG_ARGS、IMPALA_STATESTORE_ARGS、IMPALA_SERVER_ARGS这些环境变量是服务启动时的最终参数来源。比如你想调整impalad的内存限制光改impala-conf里的mem_limit是不够的还得在/etc/default/impala里的IMPALA_SERVER_ARGS加上-mem_limit70%改完以后重启impalad才会生效。另外一个坑是文件权限。手工部署时默认用impala用户启动服务如果HDFS里的数据目录属主和impala用户对不上查询时就会各种Permission denied。建议把所有HDFS数据目录和临时目录的属主设置为impala用户sudo -u hdfs hdfs dfs -chown -R impala:impala /user/hive/warehouse5. 服务验证、性能监控与优化方向安装部署做到这里只是把服务拉起来了。一个Impala集群好不好用还要靠验证和后续调优来打磨。5.1 用impala-shell跑通第一个查询安装完成后用impala-shell连接impalad节点端口是21000impala-shell -i impala-host:21000进去以后执行SHOW DATABASES;能看到Hive里的数据库列表说明Impala已经成功拉取了Hive的元数据。然后再执行一个真实的查询比如SELECT COUNT(*) FROM your_table;能返回结果Impala的部署就算基本完成。这里要特别注意如果查询报Table not found多半是元数据没同步。需要执行一下INVALIDATE METADATA;命令全量刷新元数据缓存。新增了表或者分区之后也要养成定期刷新元数据的习惯不然新数据可能查不到。5.2 监控要点内存、查询队列与数据倾斜集群正常跑起来以后重点盯几个监控指标。impalad的内存使用率是第一优先级一旦超限查询会被直接拒绝业务报表就会飘红。建议在监控系统里给impalad内存单独配一条告警线超过75%就触发通知。查询队列request_pool也需要关注。默认情况下Impala所有查询都走default队列并发数过高时查询会排队。如果团队人多并发大建议在CM里或者通过配置文件创建多个资源池给不同业务线分配不同的request_pool避免互相干扰。数据倾斜在Impala里也会影响查询性能。如果某个Join或者Group By的key分布极不均匀少量节点会变成计算热点拖慢整个查询。遇到这种情况可以在SQL层面加Hint比如/* SHUFFLE */强制Impala做一次shuffle操作牺牲一点网络IO来换取负载均衡。6. 常见问题与排查技巧实录部署过程中和日常使用中踩过的坑这里梳理成了一份速查表如果你也遇到类似问题可以直接对号入座。问题现象可能原因排查与解决impalad启动失败日志提示找不到namenode地址core-site.xml没有拷到Impala配置目录检查/etc/impala/conf下的core-site.xml是否存在且内容正确重启服务执行SHOW DATABASES能看到库但查表提示Table not foundImpala元数据缓存过期执行INVALIDATE METADATA; 如果有新表用REFRESH table名;查询报内存不足或查询被拒绝mem_limit设置过低或并发太高调大mem_limit或者限制并发查询数检查是否有大查询长期占用内存节点之间互相连不上状态监控显示节点失联防火墙或SELinux拦截检查25000、24000、26000端口连通性确认防火墙和SELinux状态查询结果和Hive不一致文件格式或统计信息不匹配执行COMPUTE STATS; 更新统计信息检查表文件格式是否为Impala支持的格式新节点的impalad起不来提示KERBEROS初始化失败无认证环境里误开了认证检查/etc/default/impala中的认证参数确认没有错误配置执行SQL时间一长就断连客户端与服务端空闲超时调整impalad的idle_session_timeout参数或者确认网络设备没有杀长连接6.1 最容易翻车的一个环节元数据刷新说起Impala的使用元数据刷新这个问题我一定要单独拎出来讲因为它实在太容易出问题了。Impala启动时会从Hive Metastore加载所有表的结构信息缓存到Catalog里平时查询走的是这份缓存不会每次都去Hive查元数据。好处是查询速度快坏处是一旦Hive那边有人建了新表、加了新分区Impala这边还是旧的元数据什么也看不到。我自己就经历过大半夜报表跑不出数据最后发现是几个小时前Hive那边新增的分区没在Impala里刷新。解决方式很简单分区变了用REFRESH table_name表的数量多了或者结构有大的变化就用INVALIDATE METADATA。前者刷单个表的轻量操作后者是全量刷新一般业务低谷期执行比较好。生产环境我建议干脆做个定时脚本每小时自动对常用表执行REFRESH能省掉很多隐性故障。6.2 关于Impala性能的几个经验值最后说几个我实测下来的经验值供参考。mem_limit设置在65%-75%之间比较平衡既能让大查询有足够内存也不至于把系统内存吃死。查询中涉及到的分区数尽量不要超过几万个量级太大的分区数会让catalogd成为瓶颈。Parquet文件建议每块128MB-256MB配合COMPUTE STATS收集统计信息后优化器才能制定出合理的执行计划。在实际操作中我一般不强依赖默认的Hash分发而是以表的分区和文件数为抓手做优化。一张几亿行的Parquet表如果小文件多到上千个查询的调度和读取开销会被严重放大。用Hive或者Spark做一次压缩合并把文件数控制在几十个的量级查询性能往往能提升好几倍。7. 最后再分享一点部署经验Impala的安装部署整套流程走下来你会发现它本身并不复杂真正复杂的是对环境和依赖的理解。CM方式半小时就能装好手工方式也不超过两小时。作为数据平台的工程师我建议你在部署时就把监控和告警的弦绷紧Impala是一个内存敏感型服务集群一旦跑起来最怕的不是安装包坏掉而是资源分配不均导致互相干扰。踩过几次坑之后我现在部署任何组件都习惯先写一份环境预检清单把端口、权限、JDK路径、时间同步、配置同步这些点逐个打勾再开始装。如果你在部署过程中也遇到什么奇怪的坑欢迎按这个思路去排查大概率都能顺藤摸瓜找到问题根源。Impala这个引擎本身是相当成熟的只要前期环境梳理清楚后续用起来会非常顺畅。