1. 项目概述为什么要在Alluxio上跑Hive这真不是为了堆技术名词Alluxio和Hive这两个名字对数据平台工程师来说就像“电”和“灯泡”——单独存在时各司其职但一旦组合起来就不再是简单叠加而是触发了一次存储与计算关系的重新定义。我第一次在某高校实验室的离线数仓升级项目中看到这个组合时第一反应是Hive不是已经能连HDFS、S3、OSS了吗再加一层Alluxio是不是画蛇添足结果上线后第三天某张日志宽表的ETL任务平均耗时从27分钟压到了8分12秒中间还省掉了3台专用于缓存预热的YARN队列节点。这才真正理解Alluxio不是给Hive“加功能”而是给整个数据访问链路做了一次精准的“血管搭桥手术”。核心关键词——Alluxio、Apache Hive、统一命名空间、元数据一致性、短路径读写加速——不是抽象概念而是可量化的工程收益。它解决的不是“能不能跑”的问题而是“能不能稳、快、省地跑”的问题。尤其当你的Hive集群同时对接多个底层存储比如冷数据在Ceph、热数据在本地SSD阵列、归档数据在对象存储又面临大量重复查询、临时表高频创建、小文件扫描等典型场景时Alluxio提供的内存/SSD两级缓存、跨存储统一挂载、计算侧就近读取能力会直接反映在YARN资源队列水位、NameNode RPC压力、以及DBA每天早上看的SLA报表里。适合谁来参考这篇内容不是只看文档的初学者而是正在经历以下任一状况的实战者Hive查询响应时间波动大尤其在早高峰时段出现明显毛刺每次上线新业务表都要手动执行ALTER TABLE ... SET LOCATION去适配不同存储路径运维脚本越写越厚小文件问题严重合并任务占用了20%以上的集群CPU但合并后又因查询模式变化很快再次碎片化对象存储如MinIO或兼容S3接口的私有存储作为底座但Hive读取延迟高、List操作慢导致DESCRIBE TABLE都卡顿正在规划湖仓一体架构需要验证计算引擎与存储解耦的落地成本。这不是一篇讲“Alluxio是什么”的科普文而是一份我在三个不同规模集群50节点、200节点、800节点上反复验证过的、带参数依据、踩坑记录和性能基线对比的实操手记。所有配置项都有明确的取值逻辑所有命令都经过生产环境脱敏复现所有结论背后都对应着一次真实的GC日志分析或JVM堆转储。2. 整体架构设计与方案选型逻辑为什么是AlluxioHive而不是别的组合2.1 不是所有缓存层都叫Alluxio它和HDFS Cache、OSS-Hadoop Connector的本质区别很多人把Alluxio当成“HDFS的缓存插件”这是最大的认知偏差。我们先拆解三类常见加速方案的技术定位方案类型工作层级缓存粒度元数据同步机制对Hive SQL透明性典型瓶颈HDFS Cache (hdfs cache directive)NameNode DataNode内核层Block级64MB/128MB强一致性写即缓存完全透明无需修改Hive配置仅限HDFS无法跨存储缓存策略固定无法按表/分区定制NameNode内存压力随缓存指令数量线性增长OSS-Hadoop Connector如aliyun-sdkHadoop FileSystem API层文件级单个ORC/Parquet文件最终一致性依赖客户端重试ETag比对需显式配置fs.s3a.impl等参数部分SQL函数如INPUT__FILE__NAME行为异常List操作性能差OSS无目录概念导致分区发现慢小文件读放大严重不支持本地缓存纯网络IOAlluxioHive集成模式计算框架与存储之间独立服务层文件级Block级混合可配置可配置一致性模型CACHE_THROUGH / THROUGH / ASYNC_THROUGH仅需修改Hive表LOCATION为alluxio://其余SQL完全不变需额外部署Alluxio Master/Worker首次读取有缓存建立延迟需协调UFSUnder File System权限关键差异点在于控制权位置HDFS Cache由NameNode统一调度你无法告诉它“这张用户行为表我要常驻内存那张日志原始表只缓存最近7天”OSS Connector把所有决策压给客户端SDK而Alluxio把缓存策略下沉到独立服务允许你用alluxio fs setTtl按目录设置过期时间用alluxio fs pin锁定热点数据甚至用alluxio table命令管理结构化元数据——这才是面向数据治理的缓存。2.2 Hive on Alluxio的两种集成模式为什么我们最终放弃“Hive Metastore直连Alluxio”Alluxio官方文档提到两种Hive集成方式方式A推荐Hive表LOCATION指向Alluxio路径如alluxio://master:19998/data/ods/user_logHive通过Alluxio FileSystem读取数据Metastore仍管理原始HDFS/OSS路径方式B实验性将Alluxio注册为Hive Metastore的存储后端让Metastore直接调用Alluxio API管理表元数据。我们在某金融客户POC中实测了方式B结果在并发建表50 QPS时Alluxio Master的RPC超时率飙升至37%原因是Metastore频繁调用createDirectory、listStatus等重量级API而Alluxio Master的ZK锁竞争成为瓶颈。反观方式AHive只在执行阶段通过Alluxio Client读数据元数据操作完全走原有路径压力分散自然。更重要的是方式A保留了Hive原有的ACID事务能力如INSERT OVERWRITE、统计信息收集ANALYZE TABLE、以及与Spark ThriftServer的互操作性——这些在方式B中都需要Alluxio额外实现目前社区版本尚未完备。所以我们的架构图非常朴素HiveServer2 → Hive MetastoreMySQL/PostgreSQL ↓ Hive Query Execution → Alluxio Client → Alluxio Master/Worker集群 ↓ UFSHDFS/S3/MinIO/CephAlluxio在这里不是替代者而是“智能路由网关”它知道哪些数据在本地SSD上最快、哪些该走RDMA网络、哪些必须回源而Hive完全无感。这种解耦带来的运维弹性极大——你可以单独升级Alluxio Worker而不影响Hive服务可以动态扩缩Alluxio缓存容量而不重启HiveServer2。2.3 版本兼容性不是玄学我们如何确定Alluxio 2.9.3 Hive 3.1.3是最优组合版本匹配不是查官网表格就能搞定的事。我们在测试矩阵中发现一个关键现象Alluxio 2.8.x系列与Hive 3.1.3配合时在执行INSERT INTO TABLE ... SELECT语句时Alluxio Client会错误地将临时输出路径解析为UFS路径而非Alluxio路径导致数据写入HDFS而非Alluxio缓存。这个问题在Alluxio 2.9.0的PR #14822中修复但引入了新的问题——当Hive启用hive.optimize.index.filtertrue时Alluxio会因索引文件路径解析异常抛出FileNotFoundException。我们最终锁定Alluxio 2.9.3因为它同时满足包含PR #14822的修复解决写路径解析合并了PR #15211修复索引过滤器路径处理兼容Hive 3.1.3的Shim Layer避免Classloader冲突对Java 11的支持稳定我们集群已全面升级JDK11。验证方法很土但有效写一个包含10种典型SQL模式JOIN、UNION ALL、CTAS、INSERT OVERWRITE、窗口函数、UDF调用、分区剪枝、谓词下推、LIMIT优化、小文件合并的测试套件每个SQL执行100次统计成功率、P95延迟、Alluxio缓存命中率通过alluxio fsadmin report metrics中的CacheHitRate指标。Alluxio 2.9.3在全部场景下命中率稳定在92.3%±0.7%而2.9.0在CTAS场景下命中率跌至68%。这个数字差异直接决定了你是否需要为缓存未命中准备额外的带宽预算。3. 核心细节解析与实操要点从部署到首条SQL成功的完整链路3.1 Alluxio集群部署Master高可用不是可选项而是必选项Alluxio Master单点故障会导致整个Hive查询链路中断——因为Hive Client需要向Master获取文件元数据如block locations。我们曾在线上环境遭遇过Master GC停顿12秒期间所有Hive查询返回Failed to connect to master。因此生产环境必须部署3节点Master HA集群使用Embedded Journal非UFS Journal理由很实际Journal写入延迟直接影响Master响应速度而UFS Journal如写入HDFS的网络RTT和序列化开销在高并发元数据请求下会成为瓶颈。部署步骤精简如下以CentOS 7为例下载与解压wget https://downloads.alluxio.io/downloads/files/2.9.3/alluxio-2.9.3-bin.tar.gz tar -xzf alluxio-2.9.3-bin.tar.gz mv alluxio-2.9.3 /opt/alluxio配置conf/alluxio-site.properties三节点相同# 必须项HA配置 alluxio.master.hostnamemaster1 alluxio.master.embedded.journal.addressesmaster1:19200,master2:19200,master3:19200 alluxio.master.journal.typeEMBEDDED alluxio.master.journal.folder/opt/alluxio/journal # 性能关键关闭不必要的服务 alluxio.master.metastoreROCKS alluxio.master.ufsManager.enabledfalse # UFS管理交由Worker减轻Master压力 # 安全启用简单认证非Kerberos alluxio.security.authentication.typeSIMPLE alluxio.security.authorization.permission.enabledtrue提示alluxio.master.ufsManager.enabledfalse这个参数常被忽略。默认开启时Master会主动探测所有挂载的UFS健康状态每5秒一次心跳在UFS数量5时显著增加Master CPU负载。关闭后健康检查由Worker异步上报更符合生产环境稳定性要求。Worker节点配置重点在缓存策略# 缓存介质优先SSDFallback到内存 alluxio.worker.tieredstore.levels2 alluxio.worker.tieredstore.level0.aliasMEM alluxio.worker.tieredstore.level0.dirs.path/dev/shm alluxio.worker.tieredstore.level0.dirs.quota16GB alluxio.worker.tieredstore.level1.aliasSSD alluxio.worker.tieredstore.level1.dirs.path/data/alluxio-ssd alluxio.worker.tieredstore.level1.dirs.quota2TB # 缓存淘汰策略LRULFU混合实测比纯LRU提升12%热点命中 alluxio.worker.tieredstore.evictor.classalluxio.worker.block.evictor.LrfuEvictor alluxio.worker.tieredstore.lrfu.attenuation.factor0.95 alluxio.worker.tieredstore.lrfu.time.interval10min实测发现纯内存缓存/dev/shm在突发查询时容易OOM而纯SSD缓存随机读性能不如内存。采用MEMSSD双层让Alluxio自动将高频访问的小文件128MB保留在内存大文件块放在SSD既控成本又保性能。LrfuEvictorLeast Frequently/Recently Used比默认GreedyEvictor更能识别“周期性热点”比如每天上午9点准时运行的报表任务。3.2 Hive端集成不只是改个LOCATION还有三个隐藏开关Hive与Alluxio的集成90%的人只做第一步修改表LOCATION。但真正决定性能上限的是接下来三步第一步启用Alluxio FileSystem在$HIVE_HOME/conf/core-site.xml中添加property namefs.alluxio.impl/name valuealluxio.hadoop.FileSystem/value /property property namefs.AbstractFileSystem.alluxio.impl/name valuealluxio.hadoop.AlluxioFileSystem/value /property注意fs.AbstractFileSystem配置必须存在否则Hive 3.x的ACID事务会失败报错java.lang.ClassNotFoundException: alluxio.hadoop.AlluxioFileSystem。这是Hive 3.x重构文件系统抽象层引入的兼容性要求。第二步配置Alluxio Client参数关键在$HIVE_HOME/conf/hive-site.xml中加入property namealluxio.user.file.writetype.default/name valueCACHE_THROUGH/value /property property namealluxio.user.file.readtype.default/name valueCACHE/value /property property namealluxio.user.network.reader.chunk.size.bytes/name value1048576/value !-- 1MB比默认8KB提升吞吐3.2倍 -- /propertyCACHE_THROUGH写模式确保数据同时写入Alluxio缓存和UFS避免读写不一致CACHE读模式强制先查缓存reader.chunk.size调大是针对Hive批量读取场景的专项优化——实测1MB chunk比8KB减少92%的网络包数量TCP重传率下降至0.03%。第三步HiveServer2启动参数注入在$HIVE_HOME/conf/hive-env.sh中追加export HIVE_SERVER2_JAVA_OPTS$HIVE_SERVER2_JAVA_OPTS -Dalluxio.user.metadata.cache.enabledtrue -Dalluxio.user.metadata.cache.expiration.time300000元数据缓存文件列表、属性开启后SHOW PARTITIONS等操作延迟从2.3秒降至180ms5分钟过期时间是平衡实时性与Master压力的经验值——太短则频繁回源太长则分区新增感知延迟。3.3 表迁移实操如何把现有Hive表“无感”迁移到Alluxio迁移不是ALTER TABLE ... SET LOCATION一条命令就完事。我们设计了四阶段灰度方案阶段1新建Alluxio路径并挂载UFS# 在Alluxio中创建映射假设原HDFS路径为/hive/warehouse/ods.db/user_log alluxio fs mount \ --option alluxio.underfs.hdfs.configuration/etc/hadoop/conf/core-site.xml:/etc/hadoop/conf/hdfs-site.xml \ /data/ods \ hdfs://nameservice1/hive/warehouse/ods.db--option参数传递HDFS配置确保Alluxio能正确解析HA nameservice。挂载后alluxio fs ls /data/ods应能看到原表目录。阶段2创建Alluxio-backed新表保持Schema一致CREATE EXTERNAL TABLE ods.user_log_alluxio ( user_id STRING, event_time STRING, event_type STRING ) PARTITIONED BY (dt STRING) STORED AS PARQUET LOCATION alluxio://master1:19998/data/ods/user_log;注意LOCATION必须用alluxio://协议且指向挂载路径下的子目录不能直接挂载根路径。阶段3数据同步与一致性校验不用INSERT OVERWRITE用Alluxio原生命令# 同步指定分区避免全表拷贝 alluxio fs copyToLocal /data/ods/user_log/dt20231001 /tmp/user_log_20231001 # 校验MD5Alluxio提供内置校验 alluxio fs checksum /data/ods/user_log/dt20231001copyToLocal比HiveINSERT快4.7倍因为绕过了Hive的MapReduce/Tez执行引擎直接走Alluxio数据通道。阶段4流量切换与监控修改原表LOCATIONALTER TABLE ods.user_log SET LOCATION alluxio://master1:19998/data/ods/user_log;切换后立即检查alluxio fsadmin report metrics | grep CacheHitRate—— 应85%HiveServer2日志搜索alluxio—— 确认Client初始化成功执行SELECT COUNT(*) FROM ods.user_log WHERE dt20231001 LIMIT 1—— 验证读取通路。注意ALTER TABLE ... SET LOCATION不会触发数据移动只是元数据指针变更。如果原表有ACID事务需先执行COMPACT确保基础文件就绪否则可能读到delta文件导致结果不一致。4. 实操过程与核心环节实现从零开始跑通第一条Alluxio-Hive查询4.1 环境准备检查清单五个必须确认的硬性条件在敲下第一条SELECT前务必完成以下五项验证缺一不可Alluxio服务健康状态# 检查Master是否Quorum达成3节点应显示3/3 alluxio fsadmin report masters # 检查Worker注册数应等于物理Worker节点数 alluxio fsadmin report workers # 检查挂载点是否就绪 alluxio fs mount如果report masters显示2/3说明有节点未加入集群需检查conf/masters文件是否三节点IP都列出且防火墙开放19200端口。Hive Client Alluxio依赖完整性# 进入Hive CLI执行 !ls $HIVE_HOME/lib | grep alluxio必须看到alluxio-hadoop-client-2.9.3.jar和alluxio-core-common-2.9.3.jar。若缺失需将Alluxio的client/alluxio-2.9.3-client.jar软链接到$HIVE_HOME/lib/。HDFS UFS权限穿透验证# 在Alluxio Master节点执行 alluxio fs ls /data/ods # 应正常列出子目录若报Permission denied需检查 # a) HDFS中/hive/warehouse/ods.db目录的ACL是否允许Alluxio用户如alluxio读取 # b) Alluxio配置中是否设置了alluxio.underfs.hdfs.impersonation.enabledtrue启用代理。HiveServer2 Classloader隔离确认Hive 3.x默认启用hive.server2.use.SSLfalse但Alluxio Client依赖的Guava版本31.1-jre与Hive自带的Guava27.0-jre冲突。必须在hive-site.xml中添加property namehive.server2.enable.doAs/name valuefalse/value /property property namehive.server2.use.SSL/name valuefalse/value /propertyenable.doAsfalse禁用用户代理避免Classloader污染use.SSLfalse防止SSL握手时的Guava版本冲突。网络连通性终极测试# 从HiveServer2所在节点telnet Alluxio Master telnet master1 19998 # 从Alluxio Worker节点ping HDFS NN ping nameservice1 # 从HiveServer2节点curl Alluxio REST API curl -I http://master1:19999/api/v1/master/health三个端口19998 RPC, 19999 Web, HDFS NN端口必须全通。我们曾因DNS解析超时/etc/resolv.conf中配置了不可达的nameserver导致Worker注册失败排查耗时6小时。4.2 首条SQL执行与性能基线采集不只是“能跑”更要“知道为什么快”执行这条看似简单的SQLSELECT COUNT(*) FROM ods.user_log WHERE dt20231001;但我们要做的远不止看结果步骤1开启Alluxio调试日志在$ALLUXIO_HOME/conf/log4j.properties中log4j.logger.alluxio.client.file.FileSystemContextDEBUG log4j.logger.alluxio.client.file.FileSystemDEBUG重启Alluxio Worker让日志记录每次读取的路径解析、缓存决策、UFS回源详情。步骤2捕获Hive执行计划EXPLAIN EXTENDED SELECT COUNT(*) FROM ods.user_log WHERE dt20231001;重点关注TableScan算子的inputPaths是否显示alluxio://...PartitionPredicate是否被正确下推避免全分区扫描Statistics中numRows是否与ANALYZE TABLE结果一致验证元数据同步。步骤3采集三层性能指标层级工具关键指标健康阈值Hiveyarn logs -applicationId app_idTotal time taken15s10GB分区Alluxioalluxio fsadmin report metricsCluster.BytesReadAlluxio/Cluster.BytesReadUfs缓存读占比90%UFSHDFS Namenode UIRpcQueueTimeAvgTime5ms首次执行时BytesReadUfs会很高缓存未建立但第二次执行同一SQLBytesReadAlluxio应跃升至95%以上。如果第二次仍高UFS读说明缓存未生效需检查alluxio.user.file.readtype.default是否为CACHE或表LOCATION是否误写为hdfs://。步骤4验证缓存有效性# 清空Worker缓存模拟冷启动 alluxio fs free /data/ods/user_log/dt20231001 # 再次执行SQL记录耗时 # 然后查看该路径缓存状态 alluxio fsadmin report metrics | grep user_log/dt20231001应看到CachedFiles计数增加CacheHitRate在后续查询中稳定上升。这是我们判断“缓存真正起作用”的黄金标准。4.3 生产级调优参数详解每个数字背后的硬件与业务逻辑Alluxio的性能不是靠堆参数而是靠理解数据访问模式。以下是我们在800节点集群中验证有效的核心参数Worker内存分配公式alluxio.worker.memory.size min(总物理内存 × 0.4, 64GB)理由Worker进程需同时承载JVM堆、Direct MemoryNetty、Page Cache/dev/shm。超过64GB堆会导致Full GC时间不可控实测G1 GC单次8秒而低于物理内存40%则浪费SSD缓存潜力。我们256GB内存节点设为96GB64GB内存32GB SSD缓存。UFS读取并发度计算alluxio.user.file.readahead1048576 alluxio.user.network.reader.chunk.size.bytes2097152 alluxio.user.network.reader.threads32readahead预读大小设为1MB匹配Hive Parquet Reader的典型stripe大小chunk.size设为2MB使单次网络传输接近万兆网卡MTU上限reader.threads32是基于nproc结果的2倍32核CPU避免IO等待。实测此组合下10G文件顺序读吞吐达1.8GB/s比默认配置提升3.1倍。缓存淘汰阈值设定alluxio.worker.tieredstore.level0.watermark.high.ratio0.85 alluxio.worker.tieredstore.level0.watermark.low.ratio0.65内存层水位高低阈值设为0.85/0.65留出20%缓冲区应对突发查询。若设为0.95/0.9一次大查询可能触发激进淘汰导致后续查询缓存失效雪崩。元数据缓存策略alluxio.user.metadata.cache.enabledtrue alluxio.user.metadata.cache.max.size.entries1000000 alluxio.user.metadata.cache.expiration.time300000100万条目足够覆盖10万张表的分区元数据5分钟过期是业务分区更新频率T1的3倍确保新分区及时可见又避免Master频繁刷新。5. 常见问题与排查技巧实录那些文档里不会写的“血泪经验”5.1 典型问题速查表从报错日志直击根因报错现象日志关键词根本原因解决方案Failed to cache file: No space left on deviceNo space left on devicein worker.log/dev/shm满但df -h显示有空间检查/dev/shm是否被其他进程占用如Docker tmpfs执行mount -o remount,size32G /dev/shm扩容Failed to get block info from ufsFailed to get block infoUFS如S3返回404但Alluxio未同步删除元数据手动执行alluxio fs rm -R --alluxioOnly /path清理Alluxio元数据再loadMetadataHiveServer2 failed with java.lang.NoClassDefFoundError: com/google/common/collect/ImmutableListNoClassDefFoundErrorguavaHive与Alluxio Guava版本冲突在$HIVE_HOME/conf/hive-env.sh中添加export HIVE_AUX_JARS_PATH/opt/alluxio/client/alluxio-2.9.3-client.jar强制优先加载Query hangs at Map 1Waiting for resourcesin YARN UIAlluxio Worker未注册Hive尝试连接不存在的Worker检查alluxio fsadmin report workers确认Worker进程存活且网络可达检查alluxio.worker.hostname是否配置为Worker本机可解析的域名SELECT returns empty resultNo files matching path表LOCATION路径末尾缺少/Alluxio解析为文件而非目录ALTER TABLE ... SET LOCATION alluxio://.../user_log/末尾加/5.2 “缓存不命中”深度排查三步定位法缓存命中率低是最高频问题。我们总结出三步定位法第一步确认是否真的“未命中”# 查看该查询的Alluxio Client日志在HiveServer2节点 grep Cache miss $HIVE_HOME/logs/hiveserver2/hiveserver2.log | tail -20 # 若出现Cache miss for file: /data/ods/user_log/dt20231001/000000_0说明未命中第二步检查文件是否被Pin锁定# Pin热点表强制常驻缓存 alluxio fs pin /data/ods/user_log # 查看Pin状态 alluxio fs ls -f /data/ods/user_log # 输出中应有P标记如 -P- 表示已Pin未Pin的文件在内存紧张时会被淘汰Pin后即使内存满也会保留。第三步验证UFS路径可访问性# 以Alluxio Worker用户身份直接访问UFS sudo -u alluxio_user hadoop fs -ls hdfs://nameservice1/hive/warehouse/ods.db/user_log/dt20231001/ # 若报错说明UFS权限或网络问题Alluxio无法回源自然无法缓存我们曾遇到Kerberos票据过期导致UFS访问失败Alluxio静默降级为“只读缓存”新数据无法写入但旧缓存仍可读——这种半失效状态最难排查。5.3 生产环境避坑指南来自三次线上事故的教训坑1Alluxio Journal磁盘打满导致Master脑裂现象alluxio fsadmin report masters显示2/3但两个Master都认为自己是Leader。根因Embedded Journal默认写入/opt/alluxio/journal我们未配置磁盘监控Journal日志累积至120GB占满根分区。解决方案Journal目录必须挂载独立磁盘如/data/journal配置alluxio.master.journal.log.size.bytes.max10737418241GB自动轮转添加Zabbix监控/data/journal使用率85%告警。坑2Hive ACID表写入Alluxio后读取乱码现象INSERT OVERWRITE后SELECT返回二进制乱码。根因Alluxio默认以字节流方式写入而Hive ACID的delta文件需特定格式。解决方案ACID表必须使用CACHE_THROUGH写模式在hive-site.xml中添加hive.exec.orc.split.strategyBI避免Split错乱禁用Alluxio的alluxio.user.file.cache.partiallytrue防止部分缓存破坏ACID语义。坑3Alluxio Worker OOM Killer杀进程现象Worker进程被系统killdmesg | grep -i killed process显示alluxio-worker。根因/dev/shm内存超限Linux OOM Killer介入。解决方案严格限制/dev/shm大小mount -o size32G -o remount /dev/shm设置JVM参数-XX:UseG1GC -Xms32g -Xmx32g -XX:MaxDirectMemorySize32g监控cat /proc/$(pgrep -f AlluxioWorker)/status | grep VmRSSRSS持续90%需扩容。最后分享一个小技巧在HiveServer2启动脚本中加入Alluxio健康检查钩子# 在$HIVE_HOME/bin/hiveserver2开头添加 if ! curl -sf http://master1:19999/api/v1/master/health | grep -q healthy:true; then echo Alluxio master is unhealthy, exiting... exit 1 fi这样HiveServer2启动时自动校验Alluxio可用性避免服务起来却无法查询的尴尬局面。这个脚本现在是我们所有集群的标准配置上线三年零因Alluxio不可用导致的Hive服务中断。
