#apache-spark #hive #apache-spark-sql #parquet
Вопрос:
Предполагая, что у меня есть внешняя таблица улья поверх файлов parquet/orc, разделенных на дату, каково будет влияние использования на производительность
spark.read.parquet("s3a://....").filter("date_col='2021-06-20'")
в/с
spark.sql("select * from table").filter("date_col='2021-06-20'")
После считывания во фрейм данных за ним последует ряд преобразований и агрегаций.
версия spark : 2.3.0 или 3.0.2
версия улья : 1.2.1000
количество записей в день : 300-700 млн
Мое предчувствие заключается в том, что при использовании любого из вышеперечисленных запросов не будет никакой разницы в производительности, поскольку parquet изначально обладает большинством оптимизаций, которые может предоставить метастор hive, и spark способен его использовать. Например, выдвижение предикатов, преимущества столбчатого хранения и т. Д.
В качестве последующего вопроса, что произойдет, если
- Исходные данные были в формате csv, а не в формате parquet. Повышает ли производительность наличие таблицы улья сверху ?
- Стол-улей был застегнут. Имеет ли смысл в этом случае читать базовую файловую систему вместо чтения из таблицы ?
Кроме того, существуют ли какие-либо ситуации, когда чтение непосредственно с паркета является лучшим вариантом по сравнению с ульем ?
Ответ №1:
Hive на самом деле должен быть быстрее здесь, потому что у них обоих есть кнопки, в Hive уже сохранена схема. Паркет, прочитанный так, как он у вас здесь, должен будет вывести объединенную схему. Вы можете сделать их примерно одинаковыми, предоставив схему.
Вы можете сделать версию паркета еще быстрее, перейдя непосредственно к разделу. Это позволяет избежать необходимости выполнять начальный фильтр по доступным разделам.
Так что что-то вроде этого могло бы сделать это:
spark.read.option("basePath", "s3a://....").parquet("s3a://..../date_col=2021-06-20")
Обратите внимание, что это лучше всего работает, если у вас уже есть схема, потому что это также пропускает слияние схем.
Что касается ваших последующих действий:
- Это имело бы огромное значение, если бы это был CSV, так как тогда пришлось бы анализировать все данные, а затем отфильтровывать эти столбцы. CSV действительно плох для больших наборов данных.
- На самом деле это не должно принести вам столько пользы и может привести к неприятностям. Метаданные, которые хранит Hive, могут позволить Spark более эффективно перемещаться по вашим данным здесь, чем вы пытаетесь сделать это самостоятельно.
Комментарии:
1. Итак, подводя итог, производительность чтения с помощью parquet reader будет такой же, как и при чтении из метастора Улья, если мы предоставим следующие действия 1. прямой путь к разделу. 2. схема файлов. Кроме того, я где-то читал, что, если мы сможем сами определить схему набора данных, чтение необработанных файлов Spark будет быстрее, потому что мы обходим дополнительный переход к метастору улья. Насколько это верно ?
2. На самом деле это будет быстрее, чем Hive, потому что тогда Spark сможет напрямую обращаться к файлам, а не просить службу Hive обслуживать их (так что пропустите этого дополнительного посредника). Наличие схемы быстрее, потому что ее не нужно выводить или считывать из метастора улья, что означает, что вы говорите, что это правильно.