Ivan Begtin
9.37K subscribers
2.16K photos
4 videos
104 files
4.89K 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 [email protected]

Ads/promotion agent: @k0shk
加入频道
Про эксперименты с автоматизированным документированием датасетов, вот живой пример документирования связки DuckDB + LLM. На вход файл в формате Parquet, можно увидеть его содержимое. На выходе таблица с размеченными колонками. Некоторые LLM дают очень хороший результат с описанием колонок на основе их названия с пониманием контекста и расшифровкой полей в зависимости от контекста который LLM тоже понимает.
Осталось дообогатить таблицу семантическим типом данных и добавить генерацию документации. На вход был файл дампа Единого структурированного справочника-каталога лекарственных препаратов (ЕСКЛП), а на выходе его описание.

Осталось понять сделать ли это отдельным инструментом или встроить в ранее созданные утилиты undatum или metacrafter которые тут пересекаются

#datadocumentation #dataengineering #datatools
Полезный обзор 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
Я для себя какое-то время назад составил список проектов по дата инженерии и аналитики для изучения и отслеживания.

Не у всех есть открытый код и некоторые я бы отдельно отметил:
- 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
Ещё один инструмент построения конвееров данных sql-flow [1] через декларативное описание в конфигурации YAML и SQL запросы.

Внутри DuckDB и Apache Arrow, поддерживаются Kafka, PostgreSQL и другие источники цели для записи.

Выглядит как нечто неплохо спроектированное и описанное.

Для тех кто любит SQL и YAML - самое оно.

Ссылки:
[1] https://github.com/turbolytics/sql-flow

#opensource #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
Forwarded from Dateno
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 → [email protected]

🔍 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
Вышла новая версия 1.3.0 DuckDB [1] с кучей изменений и улучшений.

Из важного стоит отметить:
1. Кэширование внешних файлов.
Теперь при обращении к файлу по ссылке он по умолчанию кешируется. Это очень удобно при работе с файлами относительно небольшого объёма.Опять же DuckDB здесь выступает скорее как query engine чем как база данных

2. Прямое обращение к файлу с командной строки

Позволяет сразу передать файл параметром и сделать запрос. Удобно тем что позволяет сократить описание к командной сроке и сэкономить время.

3. Расширение для кодировок
Это, конечно, давно ожидаемая [2] возможность работы с файлами в любой кодировке. Многим это существенно облегчит жизнь.

Также пишут что системно переработали код чтения и записи в Parquet файлы и всё должно быть быстрее, вот это надо будет проверить. Потому что чтение вроде как и раньше было неплохо, а вот запись в Parquet в DuckDB съедала много оперативной памяти.

Там ещё много изменений связанных с работой с геоданными, JOIN'ам, инструмент явно и быстро улучшается.

Ссылки:
[1] https://duckdb.org/2025/05/21/announcing-duckdb-130.html
[2] https://duckdb.org/docs/stable/core_extensions/encodings

#opensource #dataengineering #duckdb