Ivan Begtin
9.32K subscribers
2.11K photos
3 videos
103 files
4.83K links
I write about Open Data, Data Engineering, Government, Privacy, Digital Preservation and etc.

Founder of Dateno https://dateno.io

Telegram @ibegtin
Facebook - https://facebook.com/ibegtin
Email ivan@begtin.tech

Ads/promotion agent: @k0shk
Download Telegram
Тем временем Amazon анонсировали S3 Tables [1], возможность работать с данными таблиц которые хранятся в S3, но работа с ними как с дата файлами и через SQL запросы. Внутри этого всего движок поддерживающий Apache Iceberg, относительно новый открытый формат хранения и распространения таблиц внутри которого файлы Parquet и ассоциированные с ними метаданныею

Много где пишут что такой продукт может подорвать бизнес крупнейших игроков рынка облачной дата аналитики и хранения Databricks и Snowflake [2], цена, как и у всех AWS продуктов, будет сложная, но похоже что честная за такой сервис.

Правда, по личному опыту могу сказать что использование облачных сервисов Amazon это удобно, но всегда влетает в копеечку. На эту тему бесконечное число мемов и даже стартапы есть оптимизирующие облачное использование.

Ссылки:
[1] https://aws.amazon.com/ru/blogs/aws/new-amazon-s3-tables-storage-optimized-for-analytics-workloads/
[2] https://meltware.com/2024/12/04/s3-tables.html

#opensource #dataengineering #amazon #aws
Я тут думал было запилить гайд по сжатию данных для дата инженеров, но понял что он сведётся в итоге к формуле: сжимай всё в Parquet с компрессией Zstd

Это работает для если не всех, то большинства случаев, а всё остальное было бы просто обоснованием этого тезиса с результатами тестов на живых и синтетических данных.

Тем не менее несколько лайфхаков:
1. Сжимать CSV файлы с булевыми значениями в виде 0/1 эффективнее чем преобразовывать в Parquet потому что по умолчанию эти значения распознаются как числа int64 и даже сжатый parquet файл крупнее чем архивный.
2. Распространять файлы в унаследованных архиваторах типа ARJ - это жуткий моветон, они крайне неэффективны в потоковой обработке.
3. Большая часть инструментов загрузки датафреймов поддерживают сжатые csv файлы, но по разному. Pandas умеет открывать .xz,.gz,.zip,.zst,.bz2, а вот duckdb умеет только .gz и .zst, а остальные придётся распаковывать промежуточно куда-то ещё. Polars тоже умеет работать с .gz, а для остальных форматов сжатия надо прикладывать доп усилия.
4. Всё сводится в итоге к балансу между объёмов хранения данных, поддержкой основными инструментами аналитика и скоростью чтения данных. По этим категориям Parquet оказывается на первом месте потому что данные сжаты лучше чем большинством способов сжатия данных, чтение происходит чуть ли не быстрее чем читать файлы CSV и поддерживается он большинством современных инструментов.
5. Небольшие трюки с Parquet связаны с его колоночным сжатием данных. Уровень сжатия может зависеть и от формы представления данных. Например, если у Вас датасет с ежемесячными показаниями, то если период записывать как отдельные поля year и month, а не как дату начала месяца типа "2024-12-01", только на сжатии этой колонки можно сэкономить до 25%, потому что колонки year и month сожмутся куда лучше.
6. Аналогично с полями с булевыми значениями. Для сжатия лучше если это родное булевое поле в parquet, а не число или строка. И если булевые значения в CSV описаны как True/False, то при преобразовании/распознавании они идентифицируются как таковые. А если записаны как 0/1 или Yes/No и тд., то нет

В целом трюки со сжатием данных не так уж необходимы, реальная потребность в них возникает только в ситуациях больших регулярных потоков данных для которых оптимизация хранения и обработки даже на 10% имеет значение.

В итоге если хотите опубликовать большой набор данных - публикуйте в Parquet с внутренним сжатием, не ошибётесь.

#dataformats #dataengineering