Характеристики паркета Apache:
В сравнении с Avro, Sequence Files, RC File и т.д. Мне нужен обзор форматов. Я уже читал: Как Impala работает с форматами файлов Hadoop, он дает некоторое представление о форматах, но я хотел бы знать, как доступ к данным и хранению данных выполненных в каждом из этих форматов. Как паркет имеет преимущество перед другими?
Я думаю, что основное отличие, которое я могу описать, относится к форматам, ориентированным на запись и сравнение с колонками. Форматы, ориентированные на запись, - это то, к чему мы все привыкли, - текстовые файлы, такие как CSV, TSV. AVRO немного прохладнее, потому что он может менять схему с течением времени, например. добавление или удаление столбцов из записи. Другие трюки различных форматов (особенно в том числе сжатие) связаны с тем, можно ли разделить формат, т.е. Вы можете прочитать блок записей из любого места в наборе данных и все еще знать его схему? Но здесь более подробно о столбчатых форматах, таких как Parquet.
Паркет и другие столбчатые форматы обрабатывают общую ситуацию Hadoop очень эффективно. Как правило, таблицы (наборы данных) имеют гораздо больше столбцов, чем можно было бы ожидать в хорошо продуманной реляционной базе данных - сто или две сотни столбцов не являются необычными. Это происходит потому, что мы часто используем Hadoop в качестве места для денормализации данных из реляционных форматов - да, вы получаете много повторяющихся значений, а множество таблиц все сглаживается в один. Но становится намного проще запрашивать, так как все соединения сработаны. Существуют и другие преимущества, такие как сохранение данных о состоянии. Так или иначе, это общепринято, чтобы иметь лодку столбцов в таблице.
Скажем, есть 132 столбца, а некоторые из них - очень длинные текстовые поля, каждый столбец один за другим и использует, возможно, 10K за запись.
При запросе этих таблиц легко с точки зрения SQL, обычно бывает, что вы захотите получить ряд записей на основе только нескольких из этих столбцов со сто плюс. Например, вам могут потребоваться все записи в феврале и марте для клиентов с продажами > $500.
Чтобы сделать это в формате строки, запрос должен будет сканировать каждую запись набора данных. Прочитайте первую строку, проанализируйте запись в полях (столбцах) и получите столбцы даты и продаж, включите ее в свой результат, если она удовлетворяет условию. Повторение. Если у вас есть 10 лет (120 месяцев) истории, вы читаете каждую запись, чтобы найти 2 из этих месяцев. Конечно, это отличная возможность использовать раздел по году и месяцу, но даже в этом случае вы читаете и разбираете 10K каждой записи/строки за эти два месяца, чтобы узнать, продаются ли продажи клиентов > 500 долларов.
В столбчатом формате каждый столбец (поле) записи хранится с другими в своем роде, распространяется по множеству разных блоков на диске - столбцы за год вместе, столбцы за месяц вместе, столбцы для справочника сотрудника клиента (или другой длинный текст), и все остальные, которые делают эти записи настолько огромными в своем отдельном месте на диске, и, конечно, столбцы для продаж вместе. Ну, черт, дата и месяцы - это цифры, а также продажи - это всего лишь несколько байтов. Было бы здорово, если бы нам нужно было прочитать несколько байтов для каждой записи, чтобы определить, какие записи соответствуют нашему запросу? Колонное хранилище на помощь!
Даже без разделов, сканирование небольших полей, необходимых для удовлетворения нашего запроса, является сверхбыстрым - все они упорядочены по записи и имеют одинаковый размер, поэтому диск ищет гораздо меньше проверки данных для включенных записей. Не нужно читать этот справочник сотрудника и другие длинные текстовые поля - просто игнорируйте их. Таким образом, группируя столбцы друг с другом, вместо строк вы почти всегда можете сканировать меньше данных. Win!
Но подождите, все наладится. Если ваш запрос должен был знать только эти значения и еще несколько (скажем, 10 из 132 столбцов), и не заботился об этом столбце справочника сотрудника, как только он выбрал нужные записи для возвращения, теперь ему нужно будет только обратно в 10 столбцов, необходимых для получения результатов, игнорируя остальные 122 из 132 в нашем наборе данных. Опять же, мы пропускаем много чтения.
(Примечание: по этой причине форматы столбцов являются отвратительным выбором при выполнении прямых преобразований, например, если вы объединяете все две таблицы в один большой набор результатов (ger), который вы сохраняете в качестве новой таблицы, источники будут полностью отсканированы, поэтому нет никакой пользы в производительности чтения, а потому, что в форматах столбцов нужно больше помнить о том, где находится материал, они используют больше памяти, чем аналогичный формат строки).
Еще одно преимущество столбца: данные распространяются. Чтобы получить одну запись, вы можете иметь 132 рабочих, каждый из которых считывает (и записывает) данные из/в 132 разных места на 132 блоках данных. Yay для распараллеливания!
И теперь для clincher: алгоритмы сжатия работают намного лучше, когда могут найти повторяющиеся шаблоны. Вы могли бы сжать AABBBBBBCCCCCCCCCCCCCCCC как 2A6B16C, но ABCABCBCBCBCCCCCCCCCCCCCC не получится столь же маленьким (ну, на самом деле, в этом случае это было бы, но поверьте мне:-)). Так что еще раз, меньше чтения. И писать тоже.
Таким образом, мы читаем намного меньше данных для ответа на общие запросы, это потенциально быстрее для чтения и записи параллельно, а сжатие имеет тенденцию работать намного лучше.
Columnar отлично работает, когда ваша входная сторона большая, а ваш результат - отфильтрованное подмножество: от большого до маленького - отлично. Не так полезно, когда вход и выходы примерно одинаковы.
Но в нашем случае Импала воспользовалась нашими старыми запросами на улей, которые выполнялись через 5, 10, 20 или 30 минут, и закончились больше всего через несколько секунд или минуту.
Надеюсь, это поможет ответить хотя бы на часть вашего вопроса!
Avro - это формат хранения на основе строк для Hadoop.
Паркет - это формат хранения на основе столбцов для Hadoop.
Если ваш пример использования обычно сканирует или возвращает все поля в строке в каждом запросе, Avro обычно является лучшим выбором.
Если в вашем наборе данных много столбцов, и ваш прецедент обычно включает работу с подмножеством этих столбцов, а не целыми записями, Parquet оптимизирован для такого рода работ.
Ответ Tom довольно подробный и исчерпывающий, но вы также можете быть заинтересованы в в этом простом исследовании о Парке против Авро, сделанном в Allstate Insurance, вкратце изложенный здесь
"В целом, Parquet показал либо одинаковые, либо лучшие результаты для каждого теста [чем Avro]. Различия в отношении запросов к более крупным наборам данных в Parquets благоприятствуют частично из-за результатов сжатия, а при запросе широкого набора данных Spark приходилось на 3,5 раза меньше данных для паркета, чем у Avro. Avro плохо себя зарекомендовал при обработке всего набора данных, как подозревали.