Загрузка данных с помощью разделов Hive, S3, EMR и Recover

решила: см. обновление #2 ниже для "решения" этой проблемы.

~~~~~~~

в s3 у меня есть журнал*.GZ файлы, хранящиеся во вложенной структуре каталогов, таких как:

s3://($BUCKET)/y=2012/m=11/d=09/H=10/

Я пытаюсь загрузить их в Hive на 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/'

Я могу просто написать сценарий для этого, но кажется, что мне не хватает чего-то фундаментального.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"). Так кажется, что Улей способен обнаруживать разделы, но затем сохраняет их в строчной форме ... Позже, когда он идет искать данные, эти пути (конечно) пусты, потому что S3 чувствителен к регистру.

Я собираюсь переместить свои данные во все строчные структуры каталогов и посмотреть, работает ли это...

обновление #2

действительно, я подтвердил, что заглавная " H " как имя раздела (в макете файла s3) была проблемой здесь. Насколько я могу судить, вот что происходило:--12-->

• мой макет на S3 имел имя раздела с учетом регистра (H=)
• Запуск восстановления разделов правильно обнаруживает эти разделы...
• но тогда они хранятся внутри в нижнем регистре (h)

команда "восстановить разделы" является расширением Hive, созданным Amazon. Я сильно подозреваю, что ошибка в этом компоненте. Насколько мне известно, native Hive не имеет понятия об изучении корня файла для обнаружения разделов...