Проблемы с сохранением в таблицу Hive из Pig

Я использую HCatalog для чтения и записи данных в Hive из Pig Script следующим образом:

A = LOAD 'customer' USING org.apache.hcatalog.pig.HCatLoader();

B = LOAD 'address' USING org.apache.hcatalog.pig.HCatLoader();

C = JOIN A by cmr_id,B by cmr_id;

STORE C INTO 'cmr_address_join' USING org.apache.hcatalog.pig.HCatStorer();

Определение таблицы для customer:

cmr_id                  int                     
name                    string                   

Адрес:

addr_id                 int                     
cmr_id                  int                     
address                 string                  

cmr_address_join:

cmr_id                  int                     
name                    string                  
addr_id                 int                     
address                 string    

Когда я запускаю это, Pig выдает следующую ошибку:

ERROR org.apache.pig.tools.grunt.Grunt - ERROR 1115: Column names should all be in lowercase. Invalid name found: A::cmr_id

Я полагаю, что это может быть связано с тем, что Pig пытается сопоставить имена файлов, сгенерированных Pig, со столбцами Hive, и это не совсем соответствует (A::cmr_id versus cmr_id). Я думаю, что HCatalogStorer ожидает, что псевдоним будет cmr_id, а не A::cmr_id. Я бы хотел, чтобы HCatalogStorer игнорировал префикс псевдонима и учитывал только имя поля.

grunt>  DESCRIBE C;

C: {A::cmr_id: int,A::name: chararray,B::addr_id: int,B::cmr_id: int,B::address: chararray}

Есть ли способ убрать префикс поля в Pig (т.е. A::)? Или, если у кого-то есть обходной путь или решение, было бы здорово.

Я знаю, что мы можем использовать следующее, чтобы явно добавить псевдоним и заставить его работать.

D = foreach C generate A::cmr_id as cmr_id,A::name as name, B::addr_id as addr_id, B::address as address;

STORE D INTO 'cmr_address_join' USING org.apache.hcatalog.pig.HCatStorer();

Но моя проблема в том, что у меня много таблиц, каждая из которых имеет сотни столбцов. Было бы утомительно указывать псевдоним, как указано выше.

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


person user3207663    schedule 05.12.2014    source источник
comment
См. этот вопрос для решения. stackoverflow.com/questions/38902046/   -  person user584583    schedule 11.11.2016


Ответы (2)


Вы можете использовать $0, $1 и т. д. для доступа к столбцам и, пожалуйста, переименуйте их как имя столбца, например: $0 как cmr_id

person Piyush Jindal    schedule 26.05.2015

Да, это не радость, но маловероятно, что у вас будет точно такое же решение, тем более что ваше отношение, возвращаемое соединением, будет иметь в себе оба ключа соединения (пример — A::cmr_id и B::cmr_id). Вы уже нашли единственное реальное решение; спроецируйте его соответствующим образом с помощью FOREACH/GENERATE и переименуйте имена столбцов. На практике вам, вероятно, все равно придется делать это для реальных структур Hive, поскольку вам нужно будет не только правильно назвать столбцы, но и в правильной последовательности. Не говоря уже о том, что в «настоящей» таблице Hive значение ключа соединения будет сохранено дважды.

Единственное другое решение, которое я могу придумать (и я не рекомендую), - это STORE C как файл в HDFS, в котором у вас есть неуправляемая (вероятно, ВНЕШНЯЯ) таблица Hive, настроенная так, чтобы она указывала на каталог, в котором вы только что сохранили файл в. Вы также можете предварительно создать представление Hive, которое последовательно, возможно, обрезает дополнительные столбцы (например, дубликат cmr_id), столбцы, чтобы затем вы могли выполнить новую команду LOAD с помощью HCatLoader, а затем использовать этот псевдоним для команды HCatStorer STORE. Это может выглядеть лучше в вашем сценарии Pig, но вам все равно придется выполнять большую часть работы (только в Hive), и это определенно повлияет на производительность, поскольку вам придется записывать, а затем читать файл HDFS, представленный C перед сохранением в нужную таблицу Hive.

person Lester Martin    schedule 10.12.2015
comment
stackoverflow.com/questions/38902046/ - person user584583; 11.11.2016