Комментарии 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-файлов, например), какой-то один внешний компонент Авро — вообще ни разу не проблема.
Вообще да, это достаточно спорный минус в общем.
Ну или как выше вопрос задали: «вычитывание 5 столбцов из 6 в колоночном формате имеет все шансы оказаться менее эффективным» — а как по мне, надо начать с определения эффективности. Потому что паркет и сжатие — это про размен объема читаемых с диска данных на ядра процессора. Так как паркет хорошо сжимается, то объем считываемых данных (из HDFS, а может из из облака) возможно резко сократится, но процессор на сжатие и разжатие мы пожрем. В зависимости от того, что мы хотим, это может быть как плюсом, так и минусом.
каждая строка представляет собой отдельный json-файл
Эм, что?
Вы используете не совсем однозначный термин "витрина данных". Что представляет из себя обозначенная "витрина" на хадупе?
Авро уже сам по себе бинарник и у него по определению объем будет заметно меньше чем текстовое представление.
В сравнении есть один очень существенный недостаток - вы не пишете чем будете читать эта данные. Parquet содержит блочные и даже страничные индексы. Движок который их понимает работает на порядок быстрее того который такими данными оперировать не может. Кроме того, Parquet + Iceberg улетает в космос, потому что кроме storage индексов начинает работать скрытое bucket секционирование.
Ничего не сказано про компрессию. Какая использовалась при сравнении и использовалась ли вообще? Parquet + ZStandard = лучшая компрессия и скорость чтение.
Слабый материал, увы.
Сравнение поверхностное, вместо измерения скорости было бы лучше раскрыть разницу между orc
и parquet
Выбираем формат хранения данных в экосистеме Hadoop