В мире цифровых данных качество их хранения и обработки играет решающую роль, особенно когда речь идет о больших объемах и сложных структурах. Одним из ярких примеров таких массивов является база данных музыкального каталога Discogs - одного из крупнейших и наиболее полных музыкальных ресурсов, содержащего миллионы записей по артистам, релизам, лейблам и мастер-записям. Ежемесячно команда Discogs публикует обновленные дампы своей базы в формате gzipped XML, сжатом текстовом виде, который хоть и широко распространен, но не всегда является оптимальным с точки зрения скорости обработки и размера. В связи с этим растет интерес к альтернативным форматам хранения, одним из которых мягко набирает популярность - бинарный колоночный формат Parquet. Данная технология позиционируется как эффективное решение для хранения больших данных, позволяя сжимать их гораздо эффективнее и одновременно оптимизировать производительность при запросах.
Эксперимент с преобразованием данных Discogs из стандартного сжатого XML в Parquet позволяет ясно увидеть преимущества нового формата, а также выявить особенности процесса конвертации и оптимизации. Источник вдохновения - работа, проведенная на базе инструмента dgtools, разработанного на языке Go, где была реализована команда экспорта в Parquet, позволяющая легко конвертировать огромные дампы данных Discogs в формат, более подходящий для аналитики и запросов. Parquet отличается от традиционных текстовых форматов принципом хранения данных. В отличие от XML, где все элементы записываются последовательно, Parquet сохраняет информацию в колонках, что позволяет наилучшим образом использовать алгоритмы сжатия, адаптированные для определенного типа данных. Так, например, в одном столбце могут храниться идентификаторы, в другом - названия артистов, а в третьем - даты релизов.
Такой подход дает значительные преимущества в скорости доступа и уменьшении итогового размера файлов. Бинарный формат также лучше взаимодействует с современными движками аналитики баз данных, например DuckDB или ClickHouse, которые нативно поддерживают Parquet, благодаря чему исключается необходимость в промежуточном парсинге и транскодировании. Главной задачей была оценка реального сокращения размера данных и скорости обработки при конвертации. В ходе тестирования процесс конвертации проходил для четырех ключевых типов данных: лейблы, артисты, мастеры и релизы. Последние являются наиболее объемными и сложными для обработки структурами.
Скорость конвертации оказалась достаточно высокой. Например, для 2,27 миллиона записей по лейблам потребовалось около 12 секунд, что свидетельствует о производительности инструмента даже при обработке миллионов строк. Наиболее длительную обработку заняли релизы, где при почти 18,4 миллионах записей скорость упала до порядка 9 тысяч записей в секунду, обусловленная более сложной структурой данных. В плане объема полученные результаты выявили интересный тренд: файлы в формате Parquet были в среднем на 5,5% до 13,2% меньше изначальных gzipped XML. Наибольший выигрыш по размеру наблюдался для более простых и меньших по объему файлов - например, по лейблам размер уменьшился на 13,2%.
У сложных и высокобъемных релизов сжатие составило порядка 5,5%, что связано с ограничениями в оптимизации сжатия при многослойных и вложенных данных. Несмотря на это, экономия в нескольких гигабайтах представляет большую ценность для повсеместного хранения и передачи данных. Parquet использует различные алгоритмы сжатия, в данном случае zstd показал себя наиболее сбалансированным выбором для большинства колонок расходов данных в проекте. Для столбцов с низкой кардинальностью (то есть с ограниченным набором уникальных значений) была применена словарная (dict) кодировка, что дополнительно уменьшает размер и повышает эффективность доступа к данным. Подход детальной настройки кодирования для каждого столбца позволяет добиться наилучших показателей компактности и скорости.
Важным аспектом выступает не только размер, но и возможности для запросов. Parquet благодаря своей колоночной природе и поддержке вложенных структур идеально сочетается с современными аналитическими движками. Использование DuckDB для прямого чтения и анализа позволяет выполнять сложные запросы без предварительной обработки. Это значительно ускоряет этапы анализа музыки, сбора статистики, поиска по базе и агрегации данных. С точки зрения разработчиков, переход от традиционных текстовых дампов к бинарному колоночному формату требует некоторого начального времени на моделирование данных и настройку процесса конвертации.
Однако в случае с dgtools, благодаря уже выполненной работе по описанию структуры базы в виде структур данных Go, этап внедрения экспорта в Parquet прошел с минимальными сложностями. Это свидетельствует о том, что при грамотном подходе внедрение современных форматов хранения не требует значительных ресурсов, а преимущества с течением времени окупаются многократно. Размышления о будущем форматов экспорта крупных структурированных данных приходят к мысли, что текстовые файлы, несмотря на свою простоту и широкое распространение, перестают быть оптимальным выбором. Они неудобны при загрузке в базы, трансформации и аналитике, требуют постоянных ресурсов на парсинг и занимают больше места. На смену приходят такие форматы, как Parquet, которые отлично подходят для современных рабочих процессов обработки данных благодаря комбинации компактности, скорости и удобства интеграции.
Подводя итоги, можно утверждать, что использование Parquet для хранения и передачи дампов Discogs демонстрирует значительные преимущества, особенно в тех случаях, когда важна экономия дискового пространства и скорость аналитических запросов. Несомненно, дальнейшие оптимизации могут улучшить результаты, но уже сейчас выигрыш говорит сам за себя. Этот опыт служит примером того, как современные форматы и инструменты способны облегчить работу с большими данными, повысить эффективность процессов и открыть новые горизонты в анализе музыкальной информации. Таким образом, если вы работаете с большими объемами структурированных данных, особенно с музыкальными каталогами или подобными сложными репозиториями, стоит серьезно рассмотреть возможность использования Parquet. Это решение поможет не только уменьшить объем хранимой информации, но и ускорить доступ к ней, сделать процессы анализа более удобными и эффективными.
В конечном итоге влияние таких изменений сказывается на качестве принимаемых решений и скорости работы с платформой в целом. Мир данных меняется, а Parquet становится одним из ключевых инструментов в арсенале современного специалиста по большим данным. .
