Формат хранения данных для строк неструктурированных данных в HDFS

Мы потребляем очень большие данные, которые должны быть записаны так же быстро, как мы получаем, и мы используем HDFS, поэтому мы предпочитаем использовать его. Данные почти неструктурированы, и мы будем редко выполнять базовые запросы по ним. Данные плоские, с несколькими полями, каждая строка представляет другие данные.

key1=str key2=30.3 key3=longtexthere

Другая строка данных:

key1=3 key5=abc

SequenceFile казался наиболее естественным, но я не мог найти, как хранить несколько строк в одном SequenceFile.

В настоящее время в нашем временном решении у нас есть несколько писателей, которые записывают в несколько текстовых файлов. Поэтому, когда необходимы запросы, мы читаем их параллельно. Однако текущие текстовые файлы содержат тысячи строк, и я не думаю, что создание одного SequenceFile для каждой строки было бы возможным, это повлекло бы за собой много накладных расходов для хранения метаданных и одновременного чтения слишком большого количества файлов при запросе.

Я думаю, что проблема может быть решена с помощью HBase или Cassandra, колумнарной базы данных, но мы почти обязаны использовать HDFS. Мне что-то не хватает с SequenceFiles, или нам действительно нужно использовать базу данных columunar?


hadoop hdfs serialization apache-flink sequencefile
person Mustafa    schedule 22.10.2016    source источник
comment
У вас есть фиксированное количество ключей / столбцов?   -  person oae    schedule 22.10.2016
comment
@oae Нет, хотя они и не фиксированы, они редко расширяются, то есть иногда мы добавляем новые столбцы, но в старых данных их нет.   -  person Mustafa    schedule 22.10.2016

Ответы (1)


arrow_upward
1
arrow_downward

Итак, формат файла последовательности выглядит следующим образом: <key, value> <key, value> <key, value> ... , где ключ - WritableComparable, а значение - Writable. Теперь то, что делают многие люди - и вы могли бы сделать то же самое - это:

  • Используйте только ключ ИЛИ значение "столбец"
  • Реализуйте настраиваемый объект записи, который обертывает набор других объектов записи (назовите его записью, строкой, ...)

Так вы сможете моделировать все, что захотите. Эта запись, доступная для записи, может иметь фиксированную схему, например, она содержит «IntWritable, Text, IntWritable, IntWritable» (в зависимости от ваших полей). Или, если вы не хотите поддерживать разные типы, вы можете использовать существующий ArrayWritable в качестве своей «записи». Зная схему каждого файла (например, поместите ее в метаданные файла последовательности, вы сможете читать файлы с разными / развитыми схемами.

Так что это много ручной работы, но сборка может быть очень эффективной и гибкой. Никогда не использовал его, но взгляните на http://pangool.net/userguide/schemas.html, думаю, они уже смоделировали такую ​​гибкую схему записи / кортежа поверх файлов последовательности.

В итоге, я думаю, вы можете добиться того, чего хотите, с файлами последовательности. Однако я бы порекомендовал также взглянуть на столбчатые форматы файлов, такие как Parquet или файлы ORC. У них есть свои собственные компромиссы, но у вас будет более высокая степень сжатия и выборочное чтение (проекция столбца, развертывание фильтра). Также вам не нужно изобретать структуру схемы / кортежа.

person oae    schedule 24.10.2016