Как стать автором
Обновить

Комментарии 11

Много. Очень много вопросов по результатам тестирования.

Количество и размер файлов на диске для разных случаев? Были ли csv и json сжаты хотя бы гзипом? И почему вы регили, что они несжимемые? Количество ресурсов на кластере? Как вы объясните, что CSV с фильтрацией оказался в два раза быстрее CSV без фильтрации? Почему время запросов с фильтром на колоночных форматах не отличается от времени запросов без фильтра?

Вычитывание 1 столбца из 100 в колоночных форматах, вероятно, окажется весьма эффективным. А вот вычитывание 5 столбцов из 6 в колоночном формате имеет все шансы оказаться менее эффективным. Какой сетап в тестах?

Колоночные форматы требуют больших блоков в памяти. Какое кумулятивное потребление памяти и процессора в тестах?

Честно говоря, про возможность сжатия json\csv отдельно узнал уже после написания статьи в связи с чем при тестировании сжатие не использовалось.

Про сетап, вычитывал 5 колонок из 61 с подсчетом кол-ва строк.

Конфиг выбирал таким образом, чтобы он в среднем соответствовал используемым конфигам в работе:

spark.executor.instances = 4

spark.executor.core = 3

spark.driver.inctances = 1

spark.driver.memory = 4g

spark.executor.memory = 8g

overhead ~ 25% от показателя memory на driver`е и executor`е

 

Количество файлов на данный момент не возможно получить, поскольку данные таблички уже удалены за ненадобностью

По этой же причине не смогу вам ответить по кумулятивному потреблению памяти и процессора на тест.

Объем на диске рассчитывался без учета фактора репликации, т.е. он соответствует фактору репликации 1, если я конечно правильно понял ваш вопрос.

на дворе 2023 год, можно было бы что-то не из 90х потестить. на хадупе, например, сейчас delta с от датабрикса доступна с z-order индексами поверх паркета. еще есть iceberg и hudi.

К минусам можно отнести то, что этот формат отсутствует из коробки и для возможности чтения и записи необходимо устанавливать внешний компонент Avro.

Когда это кому-то мешало? В типичном хадуп кластере сотни, если не тысячи компонентов (в виде jar-файлов, например), какой-то один внешний компонент Авро — вообще ни разу не проблема.

Вообще да, это достаточно спорный минус в общем.

Конечно. По сравнению с тем, что методика измерения не описана вовсе — это совсем ерунда. По-моему, даже софт не был описан, который данные читал (сейчас я вижу что это спарк был). А без этого любые измерения на хадупе — как цена на бананы в африке. Ну вот реально, запустили вы в 10 или в 100 раз больше процессов спарка, и запрос выполнился быстрее в два раза. Как бы время выполнения меньше — но при этом ядра*часы, и гигабайты*часы намного хуже. Это лучше, или хуже?

Ну или как выше вопрос задали: «вычитывание 5 столбцов из 6 в колоночном формате имеет все шансы оказаться менее эффективным» — а как по мне, надо начать с определения эффективности. Потому что паркет и сжатие — это про размен объема читаемых с диска данных на ядра процессора. Так как паркет хорошо сжимается, то объем считываемых данных (из HDFS, а может из из облака) возможно резко сократится, но процессор на сжатие и разжатие мы пожрем. В зависимости от того, что мы хотим, это может быть как плюсом, так и минусом.

каждая строка представляет собой отдельный json-файл

Эм, что?

Опечатался, прошу прощение. Смысл в том, что каждый создаваемый spark`ом файл состоит из строк формата:

{“json_col”: value, ….}

{“json_col”: value, ….}

….

  1. Вы используете не совсем однозначный термин "витрина данных". Что представляет из себя обозначенная "витрина" на хадупе?

  2. Авро уже сам по себе бинарник и у него по определению объем будет заметно меньше чем текстовое представление.

В сравнении есть один очень существенный недостаток - вы не пишете чем будете читать эта данные. Parquet содержит блочные и даже страничные индексы. Движок который их понимает работает на порядок быстрее того который такими данными оперировать не может. Кроме того, Parquet + Iceberg улетает в космос, потому что кроме storage индексов начинает работать скрытое bucket секционирование.

Ничего не сказано про компрессию. Какая использовалась при сравнении и использовалась ли вообще? Parquet + ZStandard = лучшая компрессия и скорость чтение.

Слабый материал, увы.

Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории