Я просто столкнулся с этим, пытаясь ответить на тот же вопрос, и это было полезно, но не совсем полно. Короткий ответ - да, что-то вроде запроса в вопросе будет работать, но синтаксис не совсем прав.
Скажем, у вас есть три таблицы, которые были созданы с помощью следующих операторов:
CREATE TABLE staging_unpartitioned (datestring string, hour int, a int, b int);
CREATE TABLE staging_partitioned (a int, b int)
PARTITIONED BY (datestring string, hour int);
CREATE TABLE production_partitioned (a int, b int)
PARTITIONED BY (dt string, hour int);
Колонны a
и b
лишь некоторые примеры столбцов. dt
и hour
- значения, которые мы хотим разбить, как только они попадут в производственную таблицу. Перемещение промежуточных данных в производство с staging_unpartitioned
и staging_partitioned
выглядит точно так же.
INSERT OVERWRITE TABLE production_partitioned PARTITION (dt, hour)
SELECT a, b, datestring, hour FROM staging_unpartitioned;
INSERT OVERWRITE TABLE production_partitioned PARTITION (dt, hour)
SELECT a, b, datestring, hour FROM staging_partitioned;
Это использует процесс, называемый Dynamic Разметка, который вы можете прочитать о here. Важно отметить, какие столбцы связаны с тем, какие разделы определяются порядком SELECT. Все динамические разделы должны быть выбраны последними и упорядоченными.
Если вы попытаетесь запустить код выше, вы получите ошибку из-за свойств, которые вы установили. Во-первых, он не будет работать, если у вас есть динамическое разделение отключен, убедитесь, что:
set hive.exec.dynamic.partition=true;
Тогда вы могли бы привести к ошибке, если вы не секционирования по крайней мере один статический раздел перед динамическими разделами. Это ограничение избавит вас от случайного удаления корневого раздела, когда вы хотите перезаписать его подразделы динамическими разделами. По моему опыту это поведение никогда не было полезным и часто вызывало раздражение, но ваш пробег может отличаться. Во всяком случае, легко изменить:
set hive.exec.dynamic.partition.mode=nonstrict;
И это должно быть сделано.