Тем временем французы на национальном портале открытых данных Франции data.gouv.fr добавили возможность получать данные в формате Parquet [1]

Какие молодцы!

Ссылки:
[1] https://www.data.gouv.fr/fr/posts/telecharger-des-donnees-massives-au-format-parquet/

#opendata #parquet #france #dataengineering

Ещё один симпатичный движок для индексирования и поиска текста SeekStorm [1] умеет искать по тексту на разных языках, по скорости сравним с MeiliSearch, обещают многоязычность и внутри всё написано на Rust.

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

Можно попробовать с его помощью проиндексировать много миллионов документов. Десятки миллионов документов!

Но надо тестировать чтобы понять как он умеет инкрементально обрабатывать документов, сколько потребляет ресурсов и тд.

Ссылки:
[1] https://github.com/SeekStorm/SeekStorm
[2] https://deephn.org/?q=Data+indexing

#opensource #dataengineering

Тем временем 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

В рубрике интересных проектов по работе с данными LOTUS: A semantic query engine for fast and easy LLM-powered data processing [1] движок для обработки данных с помощью LLM поверх Pandas. Принимает на вход человеческим языком описанные конструкции, переводит их в программные операции над датафреймом.

Является демонстрацией работы из научной работы Semantic Operators: A Declarative Model for Rich, AI-based Analytics Over Text Data [2].

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

Если ещё и Pandas заменить на Polars или иную drop-in альтернативу, то ещё и обработка данных приобретёт хорошую скорость и производительность.

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

Ссылки:
[1] https://github.com/guestrin-lab/lotus
[2] https://arxiv.org/abs/2407.11418

#opensource #datatools #dataengineering #data #ai #llm

DBT купили SDF

Это весьма важное событие в дата инженерии для тех кто пользуется облачной дата инфраструктурой особенно. DBT - платформа и одноимённая компания [1] по трансформации данных через декларативное описание SQL операций купили компанию (и продукт) SDF [2] который делал то же самое на их же движке, но гораздо эффективнее.

Ссылки:
[1] https://www.getdbt.com
[2] https://www.sdf.com

#datatools #moderndatastack #dbt #dataengineering

Написал в рассылку текст Работаем с дата фреймами. Почему не Pandas и какие альтернативы? [1] про альтернативы Pandas такие как Polars, Dask, DuckdB и cuDF. А также там же подборка ссылок на большое число параллельно развивающихся инструментов.

А я повторю тезис что Pandas нужный, полезный и важный, но легаси инструмент у которого есть уже много высокопроизводительных альтернатив значительно упрощающих работу с данными большого объёма на недорогих устройствах.

Ссылки:
[1] https://begtin.substack.com/p/pandas

#opensource #dataengineering #dataframes #datatools

Видеозаписи прошедших семинаров:
- "Лучшие практики работы с большими научными данными: используем Parquet и DuckDB" доступен на сайте ИВ РАН или напрямую на RuTube или на YouTube

- "Дата-инженерия в цифровой гуманитаристике" доступен в сообществе в VK и в YouTube

Если кому-то будут интересны презентации с этих семинаров, напишите в комментарии, я их выложу онлайн или пришлю ссылку.

Честно говоря я давно не читал лекций и не выступал, сначала

Ближайшие мои выступления или мастер-классы будут в рамках дня открытых данных в России и в Армении, скорее и там, и там.

P.S. Ссылки на презентации:
- Дата инженерия в цифровой гуманитаристике
- Лучшие практики работы с большими научными данными. Используем Parquet и DuckDB

#opendata #digitalhumanities #lectures #parquet #duckdb #dataengineering

Я совсем недавно несколько раз писал лонгриды в рассылке о том как работать со статистическими данными и как их публикуют:
- Статистика как дата продукт
- Хорошие и плохие практики публикации данных. Метаданные и форматы файлов
- Российская статистика: немашиночитаемая институциональная фрагментация
А также много постов у меня тут в канале по хештегу #statistics

Однако я понял что у меня практически нет компактного тезисного текста о том что происходит со статистикой в мире и как она меняется, хотя бы в части работы с потребителями.

1. Основные направления развития статистических продуктов это:
- создание дашбордов по аналогии с корпоративными дашбордами (Dashboard Deutschland)
- создание инструментов самостоятельного построения визуализаций пользователями (visualize.admin.ch)
- превращение портала статслужбы в портал данных (ons.gov.uk)
- предоставление данных для массовой выгрузки (ECB Data Portal)
- использование форматов данных из data science таких как parquet (OpenDOSM)
- продвижение и развитие SDMX форматов и API (BIS Data Portal)
- предоставление статистики в режиме API-first (SingStat TableBuilder и многие другие)
- развитие публикации высокочастотных показателей вплоть до суток (порталы статистики центральных банков, BIS Data Portal)
- развитие экспериментальной статистики (Eurostat, IStat, Statistics Iceland)

2. Большая часть статистических порталов в мире индивидуальны. Из известного тиражируемого ПО можно выделить только:
- PxWeb - продукт разработанный статслужбой Швеции, активно используемый всеми скандинавскими странами и рядом других стран.
- .Stat Suite - теперь с открытым кодом. Используется статслужбой Австралии, ОЭСР и рядом стран.
- Fusion Metadata Registry - изначально разработан командой Банка международных расчётов, сейчас отдан на коммерциализацию. Является ядром для большей части публичных порталов данных отдающих статистику с SDMX совместимым API. Например, SDMX Registry Евростата

3. Всё большее число статистических ведомств создают и публикуют дата стратегии. Эти стратегии охватывают такие вопросы как:
- принципы работы с данными
- приоритеты
- стандарты и форматы обмена и публикации данными
- политики работы с данными
- источники получения данных

Примеры:
- ONS Data Strategy - стратегия работы с данными статслужбы Великобритании
- ABS Data Strategy 2021-22 to 2025 - стратегия работы с данными статслужбы Австралии
- Statistics Canada Data Strategy - дата-стратегия статслужбы Канады

4. В некоторых странах статслужбы отвечают за национальные порталы открытых данных:
- Новая Зеландия - глава статслужбы занимает позицию Government Chief Data Steward (GCDS) и определяет принципы развития и дорожную карту нац портала данных data.govt.nz
- Малайзия - национальный портал открытых данных data.gov.my переделан в портал статистики и дашбордов на основе портала статпоказателей open.dosm.gov.my статистического офиса страны.

5. Все коммерческие поставщики данных временных рядов активно игнорируют международные стандарты вроде SDMX и фокусируются, в первую очередь, на предоставлении данных через API (Nasdaq Data Link).

6. Всё что касается экспериментальной статистики - это то что в коммерческом секторе называется альтернативными данными. Их поставщиков много, они фокусируются на предоставлении их в тех форматах которые наиболее удобны потребителям. Чаще всего это API, датасеты или базы данных в облачных сервисах.

#opendata #statistics #sdmx #data #dataengineering

Полезный обзор Smallpond [1] свежего движка для обработки больших наборов/массивных потоков данных от Deepseek.

Внутри там DuckDB и автор копается во внутренностях движка объясняя как это работает.

Из интересного - да, это альтернатива Apache Spark или Daft. В общем-то DuckDB приобретает всё большую и большую популярность, встраивается внутрь самых разных инструментов.
Вот теперь ещё и в распределенные базы данных и в распределённую обработку данных.

Ссылки:
[1] https://mehdio.substack.com/p/duckdb-goes-distributed-deepseeks

#data #datatools #deepseek #dataengineering

Вакансия для тех кто ищет работу в области дата инженерии https://hh.ru/vacancy/118444436, но не в кровавом энтерпрайзе, а в общественных и научных проектах. Уметь строить конвееры данных обязательно, опыт не должен быть нулевым, но когда есть чему поучиться. Работа с общедоступными данными, их сбор, обработка и автоматизация и наблюдаемость этого всего.

#vacancy #dataengineering

Ожидаемая новость, Coalesce купили каталог данных CastorDoc [1], это был один из наиболее интересных каталогов корпоративных данных или их ещё можно называть каталогами метаданных. CastorDoc сделали сильный акцент на использовании ИИ и автоматизации документирования и контроля качества данных.

Ссылки:
[1] https://coalesce.io/company-news/coalesce-expands-data-platform-castordoc-acquisition-introduces-catalog/

#dataengineering #data #datacatalogs

Что я понял про дата инженерию за N лет работы с данными:
1. Из всех ресурсов всегда более всего, почти всегда, нехватает места для хранения и каналов для передачи данных. А когда начинает хватать, то потребности вырастают
2 Держи данные сжатыми, желательно всегда, но выбирая между способами сжатия выбирай те что позволяют использовать данные при потоковом разжимании данных.
3. Всегда имей архивную копию данных которые когда либо использовались. Если только нет юридических ограничений и ограничения в хранилищах не припёрли жёстко к стенке.
4. Не документировать данные тяжкий грех. Большинство патологические тяжкие грешники.
5. Если ты не платишь за данные поставщику они могут исчезнуть из доступа в любой момент. Если платишь то тоже, но реже и можно быстрее отреагировать.
6. Инструментарий очень быстро меняется, зацикливаться на инструментах 10-15 летней давности опасно для потери квалификации.
7. Все ненавидят облака, но жрут этот кактус. Иногда надо заставлять других этот кактус есть . Пользователей жалко, но всё идет туда.
8. Владей хотя бы одним ETL/ELT инструментом хорошо и ещё 2-3 хотя бы базово.
9. Данные всегда грязные. С небольшими табличками аналитики могут справиться сами, а большие требуют навыков дата инженеров.
10. Командная строка имеет значение (с). Многое работает значительно быстрее и эффективнее с командной строки.

Добавляйте ваши пункты😜

#dataengineering #thoughts

Очень любопытный подход к созданию каталогов данных для распространения тяжёлых датасетов бесплатно 0$ Data Distribution [1]. Если вкратце то автор воспользовался сервисом Clouflare R2 в опции Egress и используя DuckDB и таблицы Iceberg, распространяя файлы в формате Parquet.

DuckDB там можно заменить на PyIceberg или Snowflake, главное возможность бесплатно подключить и захостить данные. У автора хорошее демо [2] с тем как это работает, ограничения только в том что надо вначале, достаточно быстро и автоматически получить ключ доступа к каталогу, но это как раз не проблема.

Это, с одной стороны, выглядит как чистый лайфхак ибо Cloudflare может изменить ценовую политику, а с другой очень даже полезная модель применения.

И сама работа с таблицами используя Apache Iceberg [3]. Если вы ещё не читали об этом подходе и инструменте, то стоит уделить время. Это тот случай когда каталог данных существует в дата инженерном контексте, а то есть по автоматизации работы с данными, но без СУБД. Однако поверх Iceberg можно построить свои системы управления данными, как открытые так и не очень. Это одна из фундаментальных технологий в том смысле что из неё и других как конструктор можно собрать свой дата продукт.

Ссылки:
[1] https://juhache.substack.com/p/0-data-distribution
[2] https://catalog.boringdata.io/dashboard/
[3] https://iceberg.apache.org/

#opensource #datacatalogs #dataengineering #analytics

Про Apache Iceberg как всё более нарастающий технологический тренд в дата инженерии, ещё в декабре 2024 года Amazon добавили его поддержку в S3, а сейчас появляется всё больше число инструментов поддерживающих подключение к Apache Iceberg.

Даже удивительно как технология которой уже более 8 лет может стремительно набрать популярность при достижении определённого уровня зрелости и появлении эффективных инструментов.

Что важно знать про Apache Iceberg:
1. Это стандарт и ПО для построения озер данных созданный для преодоления ограничений предыдущих продуктов со схожими функциями такими как Apache Hudi
2. В основе Apache Iceberg технологии хранения на базе S3 и файлы Parquet. Parquet используется как контейнеры хранения данных, а S3 как хранилище данных и метаданных
3. Фундаментальная идея в реализации недорого хранилища для аналитических данных с высокопроизводительным доступом через SQL.
4. Важная причина роста популярности в комбинации: производительности, снижения стоимости и большой экосистемы из движком для запросов (query engines)
5. Серверных продуктов с открытым кодом для Apache Iceberg пока немного, кроме самой референсной реализации есть Nessie и Lakekeeper. Но много облачных провайдеров которые поддерживают такие таблицы.
6. Большая часть примеров сейчас про облачные S3 хранилища, в основном AWS. Для подключения S3 совместимых хранилищ требуется повозится
7. Применять Apache Iceberg оправдано когда у вас есть команда аналитиков умеющих в SQL и совсем неоправдано для не умеющих
8. К задачам связанным с открытыми данными этот тип дата каталога малоприменим потому что он про удобное рабочее место для продвинутого аналитика, а не про дистрибуцию данных.
9. Вообще такие продукты - это про разницу между каталогами данных, каталогами метаданных, каталогами открытых данных. Названия выглядят так словно отличий мало, а отличия огромны. Как и области применения.

#opensource #dataengineering #dataanalytics #iceberg

Полезные ссылки про данные, технологии и не только:
- Cloudflare R2 data catalog [1] свежий каталог данных на базе Apache Iceberg от Cloudflare поверх их сервиса хранения файлов R2. Хорошая новость, потому что R2 дешевле Amazon S3 при сравнимом качестве сервиса. Жду когда Backblaze запустит аналогичный сервис для их Backblaze B2
- xorq [2] читается как zork, фреймворк для обработки данных с помощью разных движков. Там и DuckDB, и Pandas, и DataFusion и др. Удобство в универсальности, но продукт пока малоизвестный, надо смотреть
- Iceberg?? Give it a REST! [3] автор рассуждает о том что без REST каталога Iceberg малополезен и, в принципе, про развитие этой экосистемы. Многие уже рассматривают стремительный взлёт Iceberg как хайп, что не отменяет того что технология весьма любопытная.
- BI is dead. Change my mind. [4] текст от Engeneering director в Clickhouse о том как меняется (может поменяться) BI в ближайшее время. TLDR: LLM + MCP + LibreChat. Чтение полезное для всех кто занимается внутренней аналитикой и использует Clickhouse
- Roadmap: Data 3.0 in the Lakehouse Era [5] изменения в экосистеме управления данными с точки зрения венчурного капитала. Простым языком для тех кто инвестирует средства в то какие новые технологии в дата инженерии появились и развиваются.

Ссылки:
[1] https://blog.cloudflare.com/r2-data-catalog-public-beta/
[2] https://github.com/xorq-labs/xorq
[3] https://roundup.getdbt.com/p/iceberg-give-it-a-rest
[4] https://www.linkedin.com/pulse/bi-dead-change-my-mind-dmitry-pavlov-2otae/
[5] https://www.bvp.com/atlas/roadmap-data-3-0-in-the-lakehouse-era

#opensource #dataanalytics #datatools #dataengineering

По поводу каталогов данных на базы Apache Iceberg, я не поленился и развернул один на базе Cloudflare R2 о котором писал ранее и могу сказать что всё прекрасно работает, с некоторыми оговорками конечно:

- каталог в Cloudflare R2 настраивается очень просто, без танцев с бубном, но требует ввода карты даже если не надо платить (на бесплатном тарифе в R2 можно хранить до 10GB и бесплатный исходящий трафик). Фактически там просто одна галочка которую надо включить
- подключение к pyIceberg также крайне простое, и в части загрузки данных, и в части запросов к ним. Для всего есть примеры
- а вот для прямого подключения DuckDB к этому каталогу танцы с бубном явно понадобятся, потому что в документации нет ничего про R2, примеры только с Amazon S3 Tables и Amazon Glue, скорее всего всё вскоре появится, но пока ничего нет.
- не заработало передача параметров фильтрации в функции table.scan, что решается последующим запросом к не фильтрованным записям, но при фильтрации требует очень много памяти;
- какие-либо UI для каталогов Apache Iceberg пока отсутствуют. Вернее есть встроенные инструменты в облачных сервисах и возможность посмотреть на загруженное в open source каталогах типа Nessie и Lakehouse, но всё это встроенные интерфейсы. Явно напрашивается UI для Iceberg browser и доступ к таблицам из веб интерфейса через DuckDB WASM к примеру.
- спецификация предусматривает возможность задания метаданных таблицам и пространствам имён, но у меня это не сработало. Впрочем я бы метаданные по пространствам имён хранил бы отдельно. Как то это логичнее
- хотя UI для каталога нет, но UI для доступа к данным в нём можно обеспечить через UI к DuckDB. Хотя для DuckDB нет пока инструкций для подключения к R2, но есть примеры прямого чтения метаданных по файлу манифеста в JSON
- есть ощущение что для работы с Iceberg и подобными таблицами напрашивается кеширующий клиент. Собственно я не первый и не один кто об этом думает.

В целом выглядит перспективно как долгосрочная технология, но ещё много что требует оптимизации и инструментарий только на стадии становления.

#datatools #data #dataengineering #dataanalytics

Полезные ссылки про данные, технологии и не только:
- vanna [1] движок с открытым кодом по генерации SQL запросов к СУБД на основе промптов. Относится к классу продуктов text-to-sql. Поддерживает много видом LLM и много баз данных. Выглядит многообещающие и его есть куда применить. Лицензия MIT.
- Boring Data [2] готовые шаблоны для Terraform для развёртывания своего стека данных. А я даже не думал что это может быть чем-то большим чем консультации, а оказывается тут просто таки автоматизированный сервис с немалым ценником.
- Understanding beneficial ownership data use [3] отчет о том как используются данные о бенефициарных собственниках компании, от Open Ownership. Пример того как делать исследования аудитории по большим общедоступным значимым базам данных / наборам данных.
- Дашборд по качеству данных в opendata.swiss [4] а ещё точнее по качеству метаданных, этим многие озадачены кто создавал большие каталоги данных.
- Open Data in D: Perfekte Idee, halbherzige Umsetzung? Ein Erfahrungsbericht. [5] выступление с рассказом о состоянии доступа к геоданным в Германии с конференции FOSSIG Munster. Всё на немецком, но всё понятно😜 там же презентации. TLDR: все геоданные в Германии доступны, но не во всех территориях одинаково. Можно только позавидовать
- Legal frictions for data openness [6] инсайты из 41 юридического случая проблем с использованием открытых данных для обучения ИИ.

Ссылки:
[1] https://github.com/vanna-ai/vanna
[2] https://www.boringdata.io/
[3] https://www.openownership.org/en/publications/understanding-beneficial-ownership-data-use/
[4] https://dashboard.opendata.swiss/fr/
[5] https://pretalx.com/fossgis2025/talk/XBXSVJ/
[6] https://ok.hypotheses.org/files/2025/03/Legal-frictions-for-data-openness-open-web-and-AI-RC-2025-final.pdf

#opendata #data #dataengineering #readings #ai #dataquality #geodata