Для моего проекта я хочу проанализировать около 2 ТБ Protobuf объектов.Я хочу использовать эти объекты в Pig Script через библиотеку "elephant bird" .Однако мне не совсем понятно, как записать файл в HDFS, чтобы он мог использоваться классом ProtobufPigLoader.
Вот что у меня есть:
Pig-скрипт:
register ../fs-c/lib/*.jar // this includes the elephant bird library
register ../fs-c/*.jar
raw_data = load 'hdfs://XXX/fsc-data2/XXX*' using com.twitter.elephantbird.pig.load.ProtobufPigLoader('de.pc2.dedup.fschunk.pig.PigProtocol.File');
Инструмент импорта (его части):
def getWriter(filenamePath: Path) : ProtobufBlockWriter[de.pc2.dedup.fschunk.pig.PigProtocol.File] = {
val conf = new Configuration()
val fs = FileSystem.get(filenamePath.toUri(), conf)
val os = fs.create(filenamePath, true)
val writer = new ProtobufBlockWriter[de.pc2.dedup.fschunk.pig.PigProtocol.File](os, classOf[de.pc2.dedup.fschunk.pig.PigProtocol.File])
return writer
}
val writer = getWriter(new Path(filename))
val builder = de.pc2.dedup.fschunk.pig.PigProtocol.File.newBuilder()
writer.write(builder.build)
writer.finish()
writer.close()
Инструмент импорта работает нормально.У меня было несколько проблем с ProtobufPigLoader, потому что я не могу использовать библиотеку сжатия hadoop-lzo, и без исправления (см. здесь ) ProtobufPigLoader не работает.Проблема, в которой у меня проблемы, заключается в том, что DUMP raw_data;
возвращает Unable to open iterator for alias raw_data
, а ILLUSTRATE raw_data;
возвращает No (valid) input data found!
.
Для меня это выглядит так, будто данные ProtobufBlockWriter не могут быть прочитаны ProtobufPigLoader.Но что использовать вместо этого? Как записать данные во внешний инструмент в HDFS, чтобы они могли обрабатываться ProtobufPigLoader.
Альтернативный вопрос: Что использовать вместо этого?Как написать довольно большие объекты в Hadoop, чтобы использовать их в Pig?Объекты не очень сложны, но содержат большой список подобъектов в списке (повторное поле в Protobuf).
- Я хочу избежать любого текстового формата или JSON, потому что они просто слишком велики для моих данных.Я ожидаю, что данные будут раздуты в 2 или 3 раза (много целых, много байтовых строк, которые мне нужно будет кодировать как Base64) ..
- Я хочу избежать нормализации данных, поэтомучто идентификатор основного объекта присоединен к каждому из подобъектов (это то, что делается сейчас ), потому что это также увеличивает потребление пространства и делает необходимые объединения в последующей обработке.
Обновления:
- Я не использовал генерацию классов загрузчиков protobuf, но использовал загрузчик типов отражения
- Классы protobuf находятся в зарегистрированном фляге.
DESCRIBE
правильно показывает типы.