Эволюция схемы в паркетном формате

Question

В настоящее время мы используем формат данных Avro в производстве. Из N хороших точек Avro мы знаем, что это хорошо в эволюции схемы.

Сейчас мы оцениваем Формат паркета из-за его эффективности при чтении случайных столбцов. Итак, прежде чем двигаться вперед, наша забота - Схема эволюции!

Кто-нибудь знает, если эволюция схемы можно паркетом, если да Как, если не почему. Некоторые presentation говорят, что это возможно, но Могу только добавить столбцы в конце

Что это значит?

Спасибо, ~ Начинающие Разработчика

Answer 1

эволюция

Схемы может быть (очень) дорого, так как выяснить схему, которую вы должны в основном прочитать все паркетные файлы и reconsile/объединить свои схемы на время чтения, которые могут быть дорогими в зависимости сколько файлов/сколько столбцов в наборе данных.

Именно поэтому в Spark 1.5 они отключили эволюцию схемы (по умолчанию, но могут быть снова включены). http://spark.apache.org/docs/latest/sql-programming-guide.html:

Поскольку схема слияние является относительно дорогостоящей операции, а не необходимости в большинстве случаев, мы выключили его по умолчанию, начиная с 1.5.0.

Без эволюции схемы вы можете прочитать схему из одного файла паркета, и, читая остальную часть файлов, предположите, что она остается прежней.

Эволюция схемы паркета зависит от реализации.

улей, например, имеет ручку

parquet.column.index.access = ложный

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

Как я сказал, это зависит от конкретной реализации, например, Импала не будет читать такие паркетные столы правильно (зафиксировано в недавнем выпуске Impala 2.6): http://community.cloudera.com/t5/Interactive-Short-cycle-SQL/external-table-stored-as-parquet-can-not-use-field-inside-a/m-p/36012

Спарк в версии 2.0.2, кажется, все еще только поддержка добавления столбцов: http://spark.apache.org/docs/latest/sql-programming-guide.html#schema-merging

Пользователи могут начать с простой схемой, и постепенно добавлять более столбцов к схеме по мере необходимости. Таким образом, пользователи могут получить несколько файлов с паркетами с разными, но совместимыми схемами. Источник данных паркета теперь может автоматически определять этот случай и объединяет схемы всех этих файлов.

PS. То, что я видел, что некоторые люди имеют большую гибкость при изменении схемы, заключается в том, что они создают представление поверх фактических паркетных таблиц, которые отображают две (или более) разные, но совместимые схемы для одной общей схемы. Допустим, вы добавили одну новую область (registration_date) и сбросили еще одну колонку (last_login_date) в новом выпуске, то это будет выглядеть так:

CREATE VIEW datamart.unified_fact_vw 
AS 
SELECT f1..., NULL as registration_date 
FROM datamart.unified_fact_schema1 f1 
UNION ALL 
SELECT f2..., NULL as last_login_date 
FROM datamart.unified_fact_schema2 f2 
; 

вы получили представление .. Хорошая вещь она будет работать так же, через все sql на диалектах Hadoop (как я упоминал выше, Hive, Impala и Spark), и все еще имеют все преимущества таблиц Паркета (хранилище столбцов, предикатное нажатие и т. д.).