РЕШЕННО: См. обновление № 2 ниже для "решения" этой проблемы.
~~~~~~~
В s3 у меня есть некоторые файлы журнала *.gz, хранящиеся в вложенной структуре каталогов, такие как:
s3://($BUCKET)/y=2012/m=11/d=09/H=10/
Я пытаюсь загрузить их в Hive on Elastic Map Reduce (EMR), используя многоуровневую структуру раздела, например:
create external table logs (content string)
partitioned by (y string, m string, d string, h string)
location 's3://($BUCKET)';
Работает таблица. Затем я пытаюсь восстановить все существующие разделы:
alter table logs recover partitions;
Кажется, что это работает, и оно перетекает через мою структуру s3 и добавляет все уровни каталогов:
hive> show partitions logs;
OK
y=2012/m=11/d=06/h=08
y=2012/m=11/d=06/h=09
y=2012/m=11/d=06/h=10
y=2012/m=11/d=06/h=11
y=2012/m=11/d=06/h=12
y=2012/m=11/d=06/h=13
y=2012/m=11/d=06/h=14
y=2012/m=11/d=06/h=15
y=2012/m=11/d=06/h=16
...
Итак, кажется, что Hive может видеть и интерпретировать мой макет файла успешно. Однако никакие фактические данные никогда не загружаются. Если я попытаюсь сделать простой подсчет или выбрать *, я ничего не получаю:
hive> select count(*) from logs;
...
OK
0
hive> select * from logs limit 10;
OK
hive> select * from logs where y = '2012' and m = '11' and d = '06' and h='16' limit 10;
OK
Мысли? Не хватает ли какой-либо дополнительной команды для загрузки данных за пределы восстановления разделов?
Если я вручную добавлю раздел с явным местоположением, то это работает:
alter table logs2 add partition (y='2012', m='11', d='09', h='10') location 's3://($BUCKET)/y=2012/m=11/d=09/H=10/'
Я могу написать script, чтобы сделать это, но похоже, что мне не хватает чего-то фундаментального w.r.t 'восстановления разделов'.
ОБНОВЛЕНИЕ # 1
Благодаря блестящему и острому замечанию Джо К. в комментарии ниже, я думаю, что проблемы с чувствительностью к регистру могут быть задействованы здесь.
Файлы определенно организованы, как, например, следующая спецификация пути, с заглавной буквы H (я думаю, что это может быть некоторый подход к форматированию iso8601):
s3://($BUCKET)/y=2012/m=11/d=09/H=10/
Я создаю свою внешнюю таблицу со спецификацией раздела, которая делает соответствующую капитализацию:
partitioned by (y string, m string, d string, H string)
(Обратите внимание на "H" ). Я делаю разделы восстановления, которые, кажется, рекурсируют через каталоги и правильно подбирают разделы, но каким-то образом (несмотря на то, что до сих пор использовались "H" во всех поучительных местах), действительно кажется, что Hive сохраняет его как нижний регистр "h",
hive> show partitions logs;
OK
y=2012/m=11/d=06/h=08
(Обратите внимание на "h" ). Таким образом, кажется, что Hive способен обнаруживать разделы, но затем сохраняет их в строчной форме... Позже, когда он идет искать данные, эти пути (конечно) пусты, потому что S3 чувствителен к регистру.
Я собираюсь переместить мои данные в структуру всех нижних регистров и посмотреть, работает ли это...
ОБНОВЛЕНИЕ # 2
Действительно, я подтвердил, что проблема с заглавной буквы "H" в качестве имени раздела (в макете файла s3) была проблемой. Насколько я могу судить, это то, что происходило:
- В моем макете на S3 было имя раздела с учетом регистра (H =)
- Выполнение RECOVER PARTITIONS правильно обнаруживает эти разделы...
- Но тогда они хранятся внутри как нижний регистр (h)
Команда "восстановить разделы" - это расширение Hive, созданное Amazon. Я сильно подозреваю, что ошибка в этом компоненте. Насколько мне известно, у Hive нет концепции изучения корневого файла для обнаружения разделов...
