MSCK REPAIR TABLE
- крайне неэффективная команда. Я действительно хотел бы, чтобы документация не поощряла людей использовать это.
Что делать вместо этого зависит от ряда вещей, которые являются уникальными для вашей ситуации.
В общем случае я бы порекомендовал написать сценарий, который выполнял бы списки S3 и создавал список разделов с их расположением, а также использовал Glue API BatchCreatePartition
для добавления разделов в вашу таблицу.
Когда ваше местоположение S3 содержит много файлов, как это звучит у вас, я бы либо использовал S3 Inventory , чтобы избежать перечисления всего, либо перечислил объекты с разделителем /
, чтобы я мог перечислить только часть структуры каталогов / разделов и пропустить список всех файлов. Разделы 27K могут быть перечислены довольно быстро, если вы избегаете перечисления всего.
Glue's BatchCreatePartitions
немного раздражает в использовании, поскольку вам нужно указывать все столбцы, serde и все для каждого раздела, но это быстрее, чем выполнение ALTER TABLE … ADD PARTION …
и ожидание завершения выполнения запроса - и до смешного быстрее, чем MSCK REPAIR TABLE …
.
Когда дело доходит до добавления новых разделов в существующую таблицу, вы также никогда не должны использовать MSCK REPAIR TABLE
, по большей части по тем же причинам. Почти всегда, когда вы добавляете новые разделы в таблицу, вы знаете местоположение новых разделов, и ALTER TABLE … ADD PARTION …
или Glue's BatchCreatePartitions
могут использоваться напрямую без необходимости сценариев.
Если процесс, который добавляет новые данные, отделен от процесса, который добавляет новые разделы, я бы порекомендовал настроить уведомления S3 в очередь SQS и периодически читать сообщения, объединять расположения новых файлов и составлять список новых разделов. из этого.