По поводу каталогов данных на базы 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

Я для себя какое-то время назад составил список проектов по дата инженерии и аналитики для изучения и отслеживания.

Не у всех есть открытый код и некоторые я бы отдельно отметил:
- DoltHub - продукт и сервис по работе с данными как с Git, большой каталог данных. Активно используется в игровой индустрии и не только
- Mode - стартап Бэна Стенцила про рабочее место для аналитика. Полезно
- CastorDoc - дата каталог с сильным акцентом на автодокументирование. Его недавно купили Coalesce
- Clickhouse - open source продукт и сервис одной из лучших аналитической СУБД
- DuckDB - про это я пишу часто, open source продукт для аналитической базы и мощный инструмент запросов. Возможно лучший или один из лучших инструментов работы с parquet файлами
- CKAN - open source каталог открытых данных активно трансформирующийся в более человечный продукт PortalJS, в сильной конкуренции с другими продуктами для каталогов открытых данных
- OpenDataSoft - французский стартап облачного продукта каталога открытых данных. Не самый популярный, но имеет множество уникальных возможностей

А также я веду большую коллекцию продуктов с открытым кодом который я собрал в структурированных списках на Github вот тут https://github.com/ivbeg?tab=stars

#opendata #data #dataanalytics #dataengineering

Полезные ссылки про данные, технологии и не только:
- Data Engineering: Now with 30% More Bullshit [1] автор ругается на термин Modern Data Stack и рассказывает про архитектуры полезное, объясняя разницу между маркетингом и здравым смыслом
- dbt Isn't Declarative — And That's a Problem [2] автор явно член секты декларативного программирования недолюбливает dbt за недекларативность и объясняет как правильно и почему. Только пока что декларативных аналогов dbt нет как бы кому-то этого не хотелось. Не, ну если появится, я бы посмотрел
- How Agoda Uses GPT to Optimize SQL Stored Procedures in CI/CD [3] автор пишет про то как применил LLM к оптимизации хранимых процедур. Плохо пишет, код нормально не приводит, то какую LLM использовал неясно, но идея разумна и практична. Для тех кто пользуется хранимыми процедурами
- Parquet is a streaming data format [4] о том что Parquet файлы можно использовать для потоковой обработки данных. Неожиданно, немного, но всё так
- Introducing MAI-DS-R1 [5] открытая модель от Microsoft на базе DeepSeek превосходящая оригинальную по множеству параметров и обходящая цензурные ограничения дипсика на тему Китая.
- An Intro to DeepSeek's Distributed File System [6] подробности о том как устроена 3FS открытая файловая система от DeepSeek.
- SpacetimeDB [7] open source СУБД и сервис для баз данных и серверов для разработчиков онлайн игр. Вообще интересная ниша и продукт любопытный. Ни разу не дешёвый как сервис, но как открытый код вполне бесплатен.
- Cloudflare R2 + Apache Iceberg + R2 Data Catalog + Daft [8] автор пишет про Apache Iceberg поверх R2 и работать с данными с помощью Daft. Выглядит всё лучше и лучше, практичнее и практичнее.

Ссылки:
[1] https://luminousmen.com/post/data-engineering-now-with-30-more-bullshit
[2] https://jennykwan.org/posts/dbt-isnt-declarative/
[3] https://medium.com/agoda-engineering/how-agoda-uses-gpt-to-optimize-sql-stored-procedures-in-ci-cd-29caf730c46c
[4] https://www.linkedin.com/posts/danforsberg_parquet-is-a-streaming-data-format-i-activity-7319055651689631744-M64r/
[5] https://techcommunity.microsoft.com/blog/machinelearningblog/introducing-mai-ds-r1/4405076
[6] https://maknee.github.io/blog/2025/3FS-Performance-Journal-1/
[7] https://spacetimedb.com
[8] https://dataengineeringcentral.substack.com/p/cloudflare-r2-apache-iceberg-r2-data

#opensource #dataengineering

Подборка полезных ссылок про данные, технологии и не только:
- Wireduck [1] расширение для DuckDB для чтения файлов сохраненного сетевого трафика PCAP. Для тех кто анализирует трафик вручную или автоматически может оказаться очень полезным
- OpenDataEditor v1.4.0 [2] новая версия инструмента для публикации открытых данных от Open Knowledge Foundation. Пока не пробовал, но скоро надо будет посмотреть внимательнее.
- dataframely [3] библиотека для декларативной проверки данных в дата фреймах нативная для Polars. Есть вероятность что будет работать с хорошей производительностью. Уже напрашиваются бенчмарки для библиотек и инструментов валидации фреймов и датасетов.
- Repairing Raw Data Files with TASHEEH [4] статья про инструмент восстановления битых CSV файлов. Это результат работы команды из Hasso-Plattner Institut [5]. Код найти не удалось, хотя пишут что он открыт, скорее всего под эмбарго пока что
- Pollock [6] инструмент и бенчмарк от той же команды из HPI по измерению качества парсинга CSV файлов. Неожиданно и тут лидирует DuckDB. Удивительно что о нём никто не знает. У этой команды много инструментов и практических работ по теме data preparation.

Ссылки:
[1] https://github.com/hyehudai/wireduck
[2] https://blog.okfn.org/2025/04/21/announcement-open-data-editor-1-4-0-version-release/
[3] https://tech.quantco.com/blog/dataframely
[4] https://www.semanticscholar.org/paper/Repairing-Raw-Data-Files-with-TASHEEH-Hameed-Vitagliano/4ec3b2d9e8ef1658bfce12c75e1ad332d4f73665
[5] https://hpi.de/naumann/projects/data-preparation/tasheeh.html
[6] https://github.com/HPI-Information-Systems/Pollock

#opensource #data #datatools #dataengineering

В блоге Meta подробный пост на мою любимую тему про понимание данных How Meta understands data at scale [1] про задачи с масштабами которые бывают только в очень крупных компаниях про анализ и управление схемами данных, в их случае это более 100 миллионов схем из более чем 100 систем с данными. Можно обратить внимание что эта работа по пониманию данных у них идёт через так называемую Privacy Aware Infrastructure (PAI). То есть это не столько для удобства разработчиков, хотя и это там присутствует, но, в первую очередь, для контроля распространения и использования собираемых и рассчитываемых персональных данных.

Для чего всё сведено в единый каталог схем OneCatalog который за пределами мета нигде кроме как в их публикациях не фигурирует. Штука уникальная, довольно редкая. С протоколом Thrift внутри и семантическими типами данных которыми аннотируются колонки данных схем протокола.

Ссылки:
[1] https://engineering.fb.com/2025/04/28/security/how-meta-understands-data-at-scale/

#dataengineering #data

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

Вот приведу несколько примеров:
1. Статистические данные одного крупного международного агентства, сравнительно среднего объёма в CSV файлах в десятки гигабайт и сотнях миллионов строк. Какая-либо информация о файлах отсутствует, просто выложены дампами для массовой выгрузки (bulk download). Большая часть инструментов при автоматическом парсинге файлов выдаёт что у них кодировка us-ascii, но в итоге оказывается что она windows-1250 (Центрально и Восточно европейская). Причём символы выдающие эту кодировку начинаются где-то очень далеко при обработке файлов. Механизмы автоидентификации кодировки почти все используют куски файла, а не его целиком, в результате нужно понаступать на множество грабель прежде чем настроить автоматическое преобразование этих файлов в другие форматы. Могло бы быть проще будь файлы в кодировке UTF-8, или вообще не в CSV, а в Parquet, к примеру.

2. Файлы Parquet в 800MB и 3.5GB со статистикой международной торговли. Первый может быть развернут в примерно 14GB CSV файл, второй в примерно 56GB. Это сотни миллионов и даже миллиарды записей. Аналитические запросы к таким файлам, на среднем железе, выполняются очень долго и поэтому Parquet файлы необходимо разрезать на множество файлов поменьше по продукции или по странам, в зависимости от задач применения. Но и разрезка больших Parquet файлов весьма ресурсоёмкая задача если пользоваться SQL запросами на копирование. В этом случае большие CSV файлы проще и быстрее обрабатывать потоковым образом. Проблема именно в размере Parquet файлов и решается она дистрибуцией их в меньшем размере

3. В "дикой природе" на порталах открытых данных в мире CSV файлы слишком часто публикуются просто как экспорт Excel файлов которые, в свою очередь, могут не иметь нормальную табличную структуру, а имеют множество заголовков, отклонений и тд, в общем-то не рассчитанных на автоматическую обработку, не говоря уже о разнообразных кодировках. Вручную во всем этом разумеется, можно разобраться, а автоматический анализ сильно затрудняется. Например, попытка натравить duckdb на эти файлы лишь в чуть более 50% случаев заканчивается успехом, в основном потому что duckdb не умеет разные кодировки. Альтернативные способы лучше читают файлы, но существенно медленнее.

4. Один из крупных порталов международной статистики отдаёт данные статистики в CSV формате внутри файлов заархивированных 7z. Это десятки гигабайт в сжатом виде и 1.5 терабайта в разжатом. Если необходимо обработать эти данные целиком то это требует очень много дискового пространства просто потому что 7z не адаптирован под потоковую обработку файлов, если не писать специальных инструментов для работы с ним. В итоге обработка этих данных происходит через промежуточное их разжатие в виде файлов. Всё могло бы быть куда удобнее если бы данные сразу распространялись в форматах parquet или же в CSV сжатом для потоковой обработки, например, Zstandard или даже Gzip.

В принципе сейчас всё выглядит так что мир data science сейчас parquet-first, а в остальные области работа с новыми-старыми форматами файлов приходит на пересечении с data science.

#opendata #dataengineering #fileformats #csv #parquet

Я давно не писал про наш поисковик по данным Dateno, а там накопилось множество обновлений, надеюсь что вот-вот уже скоро смогу об этом написать. А пока приведу ещё пример в копилку задач как ИИ заменяет человека. Я много рассказывал про реестр дата каталогов который Dateno Registry dateno.io/registry, полезный для всех кто ищет не только данные, но и их источник. Этот реестр - это основа Dateno, в нём более 10 тысяч дата каталогов размеченных по разным характеристикам и с большими пробелами в описаниях. Откуда пробелы? потому что автоматизировать поиск источников удалось, а вот описание требует (требовало) много ручной работы.

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

В общем, чтобы долго не ходить, ИИ почти полностью справляется с этой задачей. Достаточно предоставить url сайта с каталогом данных и из него хорошо извлекаются все необходимые метаданные.

Для стартапа на данных - это очень заметное изменение. И это маленькая и теперь недорогая задача. После всех проверок можно будет значительно обновить реестр.

Кстати, о том зачем он нужен. Реестр каталогов данных точно нужен Dateno для индексации датасетов, но он же нужен и всем тем кто строит национальные порталы данных потому что позволяет агрегировать в него данные из всех национальных источников.

#opendata #dateno #datasets #dataengineering #llm #ai #dataunderstanding

Global stats just got a major upgrade at Dateno!

We’ve updated time series from the World Bank (DataBank) and International Labour Organization (ILOSTAT) — now available in a more powerful and usable format.

📊 What’s new?
19,000+ indicators across economics, employment, trade, health & more
3.85 million time series with clean structure and rich metadata
Support for multiple export formats: CSV, Excel, JSON, Stata, Parquet, and more
Fully documented schemas and all source metadata included
We’re not just expanding our data coverage — we’re raising the bar for how usable and reliable open statistical data can be.

And there’s more coming:
📡 New sources of global indicators
🧠 Improved dataset descriptions
🧩 A specialized API for working with time series in extended formats
Have a specific use case for international statistics? We’d love to hear from you → dateno@dateno.io

🔍 Try it now: https://dateno.io

#openData #datadiscovery #statistics #dataengineering #dateno #worldbank #ILOSTAT

В блоге DuckDB хороший обзор того как использовать DuckDB для анализа CSV файлов статья полезная, с одним НО. У DuckDB есть конкретная особенность в ограниченном поддержке кодировок. Поэтому анализировать CSV файлы в utf8 или кодировке latin1 - да, получится. А в кодировках типа cp1251 или cp1250 не получится. Это довольно существенное ограничение для всех кто работает с датасетами не на английском языке.

#csv #dataengineering #duckdb