Улей: ошибка при выполнении выбирает и отбрасывает запросы улья разделов в одно и то же время

Я получаю сообщение об ошибке при выполнении двух запросов одновременно.

Вот сценарии.

Я использую AWS EMR, и ниже приведена схема таблицы моего куста.

CREATE TABLE India (OFFICE_NAME STRING,
OFFICE_STATUS     STRING,
PINCODE           INT,
TELEPHONE   BIGINT,
TALUK       STRING,
DISTRICT    STRING,
POSTAL_DIVISION   STRING,
POSTAL_REGION     STRING,
POSTAL_CIRCLE     STRING
)
PARTITIONED BY (STATE   STRING)
ROW FORMAT SERDE       'org.apache.hadoop.hive.ql.io.parquet.serde.ParquetHiveSerDe' 
STORED AS INPUTFORMAT  'org.apache.hadoop.hive.ql.io.parquet.MapredParquetInputFormat' 
OUTPUTFORMAT   'org.apache.hadoop.hive.ql.io.parquet.MapredParquetOutputFormat'
LOCATION  's3a://mybucket/'
TBLPROPERTIES (  'parquet.compression'='SNAPPY',   'transient_lastDdlTime'='1537781726');

Первый запрос:

SELECT count( distinct STATE ) FROM India;

Второй запрос:

ALTER TABLE India DROP PARTITION (STATE='Delhi');

При выполнении первого запроса я одновременно выполнил второй запрос, поэтому я получил эту ошибку в первом запросе.

Error: java.io.IOException: java.lang.reflect.InvocationTargetException
at org.apache.hadoop.hive.io.HiveIOExceptionHandlerChain.handleRecordReaderCreationException(HiveIOExceptionHandlerChain.java:97)
  at org.apache.hadoop.hive.io.HiveIOExceptionHandlerUtil.handleRecordReaderCreationException(HiveIOExceptionHandlerUtil.java:57)
  at org.apache.hadoop.hive.shims.HadoopShimsSecure$CombineFileRecordReader.initNextRecordReader(HadoopShimsSecure.java:271)
  at org.apache.hadoop.hive.shims.HadoopShimsSecure$CombineFileRecordReader.next(HadoopShimsSecure.java:144)
  at org.apache.hadoop.mapred.MapTask$TrackedRecordReader.moveToNext(MapTask.java:200)
  at org.apache.hadoop.mapred.MapTask$TrackedRecordReader.next(MapTask.java:186)
  at org.apache.hadoop.mapred.MapRunner.run(MapRunner.java:52)
  at org.apache.hadoop.mapred.MapTask.runOldMapper(MapTask.java:455)
  at org.apache.hadoop.mapred.MapTask.run(MapTask.java:344)
  at org.apache.hadoop.mapred.YarnChild$2.run(YarnChild.java:164)
  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:1698)
  at org.apache.hadoop.mapred.YarnChild.main(YarnChild.java:158)
Caused by: java.lang.reflect.InvocationTargetException
  at sun.reflect.GeneratedConstructorAccessor42.newInstance(Unknown Source)
  at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
  at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
  at org.apache.hadoop.hive.shims.HadoopShimsSecure$CombineFileRecordReader.initNextRecordReader(HadoopShimsSecure.java:257)
  ... 11 more
Caused by: com.amazon.ws.emr.hadoop.fs.consistency.exception.FileDeletedInMetadataNotFoundException: File 'mybucket/India/state=Delhi/000000_0' is marked as deleted in the metadata
  at com.amazon.ws.emr.hadoop.fs.consistency.ConsistencyCheckerS3FileSystem.getFileStatus(ConsistencyCheckerS3FileSystem.java:440)
  at com.amazon.ws.emr.hadoop.fs.consistency.ConsistencyCheckerS3FileSystem.getFileStatus(ConsistencyCheckerS3FileSystem.java:416)
  at sun.reflect.GeneratedMethodAccessor17.invoke(Unknown Source)
  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
  at java.lang.reflect.Method.invoke(Method.java:498)
  at org.apache.hadoop.io.retry.RetryInvocationHandler.invokeMethod(RetryInvocationHandler.java:191)
  at org.apache.hadoop.io.retry.RetryInvocationHandler.invoke(RetryInvocationHandler.java:102)
  at com.sun.proxy.$Proxy34.getFileStatus(Unknown Source)
  at com.amazon.ws.emr.hadoop.fs.s3n2.S3NativeFileSystem2.getFileStatus(S3NativeFileSystem2.java:227)
  at com.amazon.ws.emr.hadoop.fs.EmrFileSystem.getFileStatus(EmrFileSystem.java:509)
  at org.apache.parquet.hadoop.ParquetFileReader.readFooter(ParquetFileReader.java:386)
  at org.apache.parquet.hadoop.ParquetFileReader.readFooter(ParquetFileReader.java:372)
  at org.apache.hadoop.hive.ql.io.parquet.ParquetRecordReaderBase.getSplit(ParquetRecordReaderBase.java:79)
  at org.apache.hadoop.hive.ql.io.parquet.read.ParquetRecordReaderWrapper.<init>(ParquetRecordReaderWrapper.java:75)
  at org.apache.hadoop.hive.ql.io.parquet.read.ParquetRecordReaderWrapper.<init>(ParquetRecordReaderWrapper.java:60)
  at org.apache.hadoop.hive.ql.io.parquet.MapredParquetInputFormat.getRecordReader(MapredParquetInputFormat.java:75)
  at org.apache.hadoop.hive.ql.io.CombineHiveRecordReader.<init>(CombineHiveRecordReader.java:99)
  ... 15 more

после гугла я нашел эту ссылку

https://docs.aws.amazon.com/emr/latest/ManagementGuide/emrfs-files-tracked.html

Можно ли в любом случае синхронизировать метаданные во время выполнения или второй запрос не будет выполняться до тех пор, пока не будет завершен первый статус.

Пожалуйста, помогите мне решить эту проблему или любое предложение, установите любой параметр, который решит проблему.


person Gabber    schedule 07.12.2018    source источник


Ответы (1)


Путь к разделу и сплиты рассчитываются в самом начале. Ваши картографы начали читать файлы в расположении раздела, и в то же время, когда вы удалили раздел, это привело к удалению файлов, потому что ваша таблица управляется. Это вызывает исключение FileDeletedInMetadataNotFoundException во время выполнения.

Если вы все еще хотите удалить раздел во время чтения, попробуйте следующее:

Если вы сделаете свою таблицу ВНЕШНЕЙ, то DROP PARTITION не должен удалять файлы, они останутся, и это не должно вызывать исключений, и вы можете позже удалить расположение раздела из файловой системы. Или используйте политику жизненного цикла S3, чтобы удалить старые файлы, как описано здесь< /а>.

К сожалению, уже запущенное задание не может определить, что раздел Hive с файлами был удален, и изящно пропустить их чтение, поскольку метаданные Hive уже прочитаны, план запроса построен и разбиения уже могут быть рассчитаны.

Таким образом, решение состоит в том, чтобы удалить разделы Hive и отложить удаление файлов.

Кстати, когда вы добавляете разделы при запросе таблицы, все работает нормально.

person leftjoin    schedule 07.12.2018
comment
Спасибо за ответ. нет, я не могу перейти на внешнюю таблицу. - person Gabber; 07.12.2018
comment
есть ли в любом случае запрос на удаление раздела, ожидающий полного выполнения запроса на выборку - person Gabber; 07.12.2018
comment
я пробовал этот набор hive.support.concurrency=true; но это занимает много времени - person Gabber; 07.12.2018
comment
@Также хорошим решением может быть следующее: сделать таблицу ВНЕШНЕЙ и удалить разделы или запустить RECOVER PARTITIONS (или MSCK REPAIR), удалить старые файлы с помощью политики Lyfecycle корзины AWS S3. Вышестоящий рабочий процесс должен помещать только новые файлы. Срок действия файлов истекает в соответствии с политикой жизненного цикла, RECOVER PARTITIONS удаляет разделы без местоположений и добавляет новые - person leftjoin; 07.12.2018
comment
Нет, я не могу этого сделать... можно заблокировать только метаданные вместо блокировки всей таблицы?? - person Gabber; 07.12.2018
comment
Я имею в виду, что вы можете выполнить RECOVER PARTITIONS перед вашим запросом в том же сеансе, а не параллельно, процесс Upstream поместит свои файлы, S3 удалит файлы с истекшим сроком действия. Ваши разделы восстановления будут добавлять/удалять разделы в одном сеансе - person leftjoin; 07.12.2018
comment
@Gabber Или просто сделайте то же самое, что и сейчас, но сделайте свою таблицу ВНЕШНЕЙ. Удаление раздела не приведет к удалению файлов. И настройте политику жизненного цикла для удаления старых файлов. - person leftjoin; 07.12.2018
comment
@Gabber Обновил мой ответ - person leftjoin; 07.12.2018
comment
Это хорошее предложение, и оно, безусловно, сработает... но данные находятся в производственном режиме, и есть еще одна зависимость от внутренней таблицы... поэтому я не могу сделать ее внешней таблицей. - person Gabber; 07.12.2018
comment
@Gabber Что такое зависимость от ВНУТРЕННЕЙ таблицы? Единственная разница между внутренним и внешним — это поведение раздела/таблицы DROP. Все остальное будет работать одинаково: те же местоположения, те же данные, те же запросы и т. д. - person leftjoin; 07.12.2018