我之前也碰到过类似的兼容性坑，咱们先拆解下错误根源，再一步步解决这个问题。

问题到底出在哪？ #

你遇到的NumberFormatException: For input string: "0000112_0000"，本质是Drill 1.10.0对Hive ACID事务表的文件命名逻辑处理不兼容。Hive的事务表会生成带下划线后缀的ORC文件（比如0000112_0000这种命名格式），而Drill 1.10.0的Hive存储插件错误地把整个文件名当成纯数字去解析，自然就抛出了数字格式化异常。

三种可行的解决办法 #

1. 升级Drill版本（最推荐） #

Drill 1.10.0是比较老旧的版本，后续的Drill稳定版本（比如1.16及以上）专门修复了大量和Hive ACID表兼容的bug。直接升级到新的稳定版，是一劳永逸的解决方案，不仅能解决当前问题，还能获得更多功能和稳定性提升。

2. 把Hive事务表转成非ACID表（适合暂时不能升级的场景） #

如果业务暂时不允许升级Drill，可以把Hive的ACID表转换成普通ORC表，步骤如下：

• 先导出原表数据到HDFS临时目录：

INSERT OVERWRITE DIRECTORY '/tmp/non_acid_backup' SELECT * FROM your_acid_table;

• 删除原ACID表：

DROP TABLE your_acid_table;

• 创建不带ACID特性的ORC表（列定义要和原表完全一致）：

CREATE TABLE your_non_acid_table (
  id INT,
  name STRING,
  -- 其他列按原表定义填写
) STORED AS ORC;

• 把临时目录的数据导回新表：

INSERT INTO your_non_acid_table SELECT * FROM '/tmp/non_acid_backup';

3. 修改Drill的Hive插件配置（临时应急方案） #

这个方法是临时绕过错误，不一定能保证数据完全正确读取，适合紧急测试场景：

• 打开Drill的Web UI（默认地址是http://<drill-host>:8047）
• 进入「Storage」页面，找到hive插件，点击「Update」
• 在配置的config区块里添加一行：

"hive.acid.enabled": false

• 保存配置后，重新执行查询试试。这个配置会让Drill忽略Hive的ACID表结构，可能会丢失部分事务相关的数据，所以只建议临时使用。

验证是否解决 #

改完之后，执行一个简单的查询验证：

SELECT * FROM hive.your_db.your_table LIMIT 10;

如果不再抛出NumberFormatException，说明问题已经解决啦。

内容的提问来源于stack exchange，提问作者Smruti Ranjan