Изменение базового местоположения во внешнем столе Афины

Question

В моей корзине s3 данные разделены по ключам. Таким образом, мои данные будут в

s3://my-bucket/202001/tablenm/key=1/<data>
s3://my-bucket/202001/tablenm/key=2/<data>
s3://my-bucket/202001/tablenm/key=3/<data>
s3://my-bucket/202001/tablenm/key=4/<data>

У меня есть внешняя таблица athena, местоположение которой s3: // my-bucket / 202001 / tablenm /

Теперь, для следующего запуска, данные загружаются в ту же корзину, но в другую папку месяца. Таким образом, это выглядело бы примерно так:

s3://my-bucket/202002/tablenm/key=2/<data>
s3://my-bucket/202002/tablenm/key=3/<data>
s3://my-bucket/202002/tablenm/key=4/<data>
s3://my-bucket/202002/tablenm/key=5/<data>

Теперь я хочу, чтобы таблица показывала данные, которые находятся в папке s3://my-bucket/202002/tablenm/. Итак, я изменил расположение таблицы athena на

alter table tablenm set location "s3://my-bucket/202002/tablenm/"

, и после того, как я выполнил msck-восстановление таблицы, я получаю сообщение об ошибке: partition not in metastore : key=1, key=2, key=3, key=4

Помимо удаления и повторного -создание таблицы athena с новым местоположением, есть ли способ обновить метаданные, чтобы они указывали на новые разделы местоположения?

Answer 1

Таблицы являются просто метаданными и дешевыми ресурсами. Не беспокойтесь о том, чтобы сбросить и воссоздать их. В этой ситуации было бы лучше просто отбросить таблицу и создать новую.

Если вы действительно хотите избежать отбрасывания таблицы, вам необходимо удалить все разделы до или сразу после вас. изменить расположение таблицы.

Расположение таблицы и расположение ее разделов, к сожалению, не имеют никакого отношения друг к другу, они не связаны между собой. При изменении местоположения таблицы ранее добавленные разделы по-прежнему ассоциируются с таблицей. Затем, когда вы запускаете команду MSCK REPAIR TABLE, она сильно сбивается с толку, так как смотрит на новое местоположение таблицы, находит разделы, и когда он перепроверяет те, у которых есть существующие разделы, метаданные не совпадают.

* * * * MSCK REPAIR TABLE предполагает, что разделы располагаются ниже местоположения вашей таблицы. ALTER TABLE … SET LOCATION … между тем, не учитывает допущения MSCK REPAIR TABLE и просто делает то, что вам говорят, устанавливает местоположение таблицы, а также не переписывает расположение ее разделов. Одна из причин, по которой он этого не делает, заключается в том, что было бы неправильно делать это в других обстоятельствах - нет правила, согласно которому разделы должны иметь местоположения, связанные с местоположением таблицы. По крайней мере, в Афине расположение многораздельной таблицы в большинстве случаев бессмысленно, но такие команды, как MSCK REPAIR TABLE и Glue Crawlers, используют его как подсказку, с которой следует начинать поиск данных. Команда Athena также модернизировала множество команд из Presto / Hive для запуска на Glue вместо Hive metastore, который не подходит один к одному, и некоторые вещи, вероятно, просто невозможно было бы сделать так, чтобы работать согласованно.

Вы можете увидеть, что произойдет, если вы используете Glue API для запроса вашей таблицы до и после изменения ее местоположения, используйте вызов API GetPartitions, чтобы получить список разделов таблицу, и вы увидите, что они не меняются.

---

Кроме того, хотя использование MSCK REPAIR TABLE, как вы делаете, работает нормально, просто вы знаете, это очень, очень медленно, когда вы получаете больше перегородки. Не полагайтесь на это, кроме как для загрузки нескольких разделов. Вы можете найти дополнительную информацию здесь , здесь , здесь , здесь и здесь .