0

我有一个 ACID 配置单元表，其中包含 ORC 格式的文件。尝试压缩时，出现以下错误：Task: ... exited : java.io.IOException: Two readers for ...完整错误如下：

2019-06-03 07:01:05,357 ERROR [IPC Server handler 2 on 41085] org.apache.hadoop.mapred.TaskAttemptListenerImpl: Task: attempt_1558939181485_29861_m_000001_0 - exited : java.io.IOException: Two readers for {originalWriteId: 143, bucket: 536870912(1.0.0), row: 3386, currentWriteId 210}: new [key={originalWriteId: 143, bucket: 536870912(1.0.0), row: 3386, currentWriteId 210}, nextRecord={2, 143, 536870912, 3386, 210, null}, reader=Hive ORC Reader(hdfs://HdfsNameService/tbl/delete_delta_0000209_0000214/bucket_00001, 9223372036854775807)], old [key={originalWriteId: 143, bucket: 536870912(1.0.0), row: 3386, currentWriteId 210}, nextRecord={2, 143, 536870912, 3386, 210, null}, reader=Hive ORC Reader(hdfs://HdfsNameService/tbl/delete_delta_0000209_0000214/bucket_00000, 9223372036854775807)]
    at org.apache.hadoop.hive.ql.io.orc.OrcRawRecordMerger.ensurePutReader(OrcRawRecordMerger.java:1171)
    at org.apache.hadoop.hive.ql.io.orc.OrcRawRecordMerger.<init>(OrcRawRecordMerger.java:1126)
    at org.apache.hadoop.hive.ql.io.orc.OrcInputFormat.getRawReader(OrcInputFormat.java:2402)
    at org.apache.hadoop.hive.ql.txn.compactor.CompactorMR$CompactorMap.map(CompactorMR.java:964)
    at org.apache.hadoop.hive.ql.txn.compactor.CompactorMR$CompactorMap.map(CompactorMR.java:941)
    at org.apache.hadoop.mapred.MapRunner.run(MapRunner.java:54)
    at org.apache.hadoop.mapred.MapTask.runOldMapper(MapTask.java:465)
    at org.apache.hadoop.mapred.MapTask.run(MapTask.java:349)
    at org.apache.hadoop.mapred.YarnChild$2.run(YarnChild.java:174)
    at java.security.AccessController.doPrivileged(Native Method)
    at javax.security.auth.Subject.doAs(Subject.java:422)
    at org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1730)
    at org.apache.hadoop.mapred.YarnChild.main(YarnChild.java:168)

该表是通过将 avro 文件添加到一个 orc 表中来创建和更新的merge，因此有一堆 deltadelete_delta和delta.

我有许多其他这样的表，它们没有这个问题。该表没有什么特别之处，实际上非常小（<100k 行，磁盘上 2.5M），并且在上个月更新了 100 次（更新了 20k 行，更新了 5M 数据）。DDL 是：

CREATE TABLE `contact_group`(
  `id` bigint,
  `license_name` string,
  `campaign_id` bigint,
  `name` string,
  `is_system` boolean,
  `is_test` boolean,
  `is_active` boolean,
  `remarks` string,
  `updated_on_utc` timestamp,
  `created_on_utc` timestamp,
  `deleted_on_utc` timestamp,
  `sys_schema_version` int,
  `sys_server_ipv4` bigint,
  `sys_server_name` string,
  `load_ts` timestamp)
ROW FORMAT SERDE
  'org.apache.hadoop.hive.ql.io.orc.OrcSerde'
STORED AS INPUTFORMAT
  'org.apache.hadoop.hive.ql.io.orc.OrcInputFormat'
OUTPUTFORMAT
  'org.apache.hadoop.hive.ql.io.orc.OrcOutputFormat'
LOCATION
  'hdfs://HdfsNameService/dwh/vault/contact_group'
TBLPROPERTIES (
  'bucketing_version'='2',
  'last_modified_by'='hive',
  'last_modified_time'='1553512639',
  'transactional'='true',
  'transactional_properties'='default',
  'transient_lastDdlTime'='1559522011')

这种情况每隔几个月就会发生一次。由于其他一切（选择、合并）都有效，修复通常是创建第二个表（create table t as select * from contact_group）并切换表，但我想找到真正的根本原因。

我发现的关于我的错误的唯一参考是代码本身，这对我没有多大帮助。

这是在 hdp3.1 上，带有 Hive 3。

4

4 回答 4

1

就我而言，这是由用户错误引起的。它是由两个表引用同一个 hdfs 目录引起的。创建表时，我创建了位置名称，不小心将同一个目录复制到另一个表中。

然后我的程序对两个事务表执行了更改，导致无法解析的增量文件。

于 2020-09-01T21:37:42.540 回答
1

以下是我们的一位用户观察到的问题的摘要：

表在从磁盘获取任务操作期间失败，它被 delete_delta 文件（https://issues.apache.org/jira/browse/HIVE-22318）中的重复键标识符损坏，有一个临时解决方法来读取表设置set hive.fetch.task.conversion=none 但这无助于压缩或任何获取任务操作的成功。

创建表备份的步骤：

  • 连接直线并在会话中运行以下属性：

    set hive.fetch.task.conversion=none ;

  • 现在您将能够在提到的表上运行选择语句。

  • 运行以下语句为表创建备份

    create table <backup_tbl_name> as select * from <problem_tbl> ;

  • 准备好备份后，从会话中注销并检查备份表而不设置任何属性（从数据质量角度检查计数和表一致性）

    select * from <backup_tbl_name> ;

从备份表创建原始副本：

  • 现在您可以删除问题表并替换为备份表

    drop table <problem_tbl> ;

    alter table <backup_tbl_name> rename to <original_tbl_name> ;

注意：为避免以后出现此问题，请在 DDL 中创建带有分桶列的表

于 2021-01-08T15:43:43.393 回答
1

就我而言，我无法使用@ShuBham ShaRma 建议的解决方案解决问题。在查看@cang_yun 的发现后，我尝试删除其中一个存储桶文件（bucket_00001）并能够再次在该表上运行选择语句。我不确定这是不是正确的方法，但它在我的情况下有效。

于 2021-08-04T04:57:18.327 回答
1

我也遇到过这个问题。通过orc-tools我扫描了delete_delta下的所有文件，可以发现这些文件中的所有行都是相同的（例如bucket_00000中有7行，其他有7行相同）文件bucket_00001。）。所以迭代下一个bucket文件时key（originalTransacion-bucket-rowId-currentWriteId）将相同。

另一个解决方法是将表创建为存储桶，也许可以避免该问题。

于 2019-10-10T06:15:23.857 回答