Полезные ссылки про данные, технологии и не только:
- A Deep Dive into DuckDB for Data Scientists о том как дата сайентистам использовать DuckDB. Если коротко, то всё довольно просто и понятно.
- ClickHouse welcomes LibreChat: Introducing the open-source Agentic Data Stack Clickhouse поглотил LibreChat, инструмент с открытым кодом для создания ИИ чатботов. Инструмент был хороший, надеюсь таким и останется.
- Hannes Mühleisen - Data Architecture Turned Upside Down отличное выступление Hannes Mühleisen про ключевые изменения в архитектуре данных последних лет. Полезно и по смыслу и по визуальному представлению хорошо
- agor: Next-gen agent orchestration for AI coding ИИ агент для управления ИИ кодированием, автор его создатель Superset и позиционирует этот проект как думай об асситентах для кодирования как о Figma. С открытым. кодом. Любопытно, но ИМХО автор плохо объясняет преимущества, как подхода, так и интерфейса.

#opensource #data #datatools #dataengineering #ai

Полезные ссылки про данные, технологии и не только:
- quackstore расширение для DuckDB для кеширования облачных дата файлов, позволяет сильно ускорить выполнение запросов к облачным файлам благодаря их частичному сохранению. Полезная штука, её можно бы и сразу внутрь DuckDB ибо логично
- Catalog of Patterns of Distributed Systems для тех разработчиков кто хотят не только кодировать, но и двигаться в сторону архитектуры ПО.
- The Data Engineering Agent is now in preview Гугл запустили ИИ агента для дата инженеров внутри BigQuery, конечно же на базе Gemini. Дайте мне такой же только с открытым кодом и без инфраструктуры Google и с поддержкой всех основных инструментов и СУБД!
- Diseño del V Plan de Gobierno Abierto 2025-2029 5-й план по открытости гос-ва опубликовали власти Испании. Сейчас проходят публичные консультации и далее он будет утвержден. Открытые данные там, конечно же, присутствуют

#opendata #opensource #rdbms #datatools #dataengineering #ai

Часто встречающаяся задача когда необходимо быстро создать API над какими-то данными и предоставить его внутренним и/или внешним пользователям. API, как правило, нужно для одной или нескольких из перечисленных причин:
1. Данные обновляются слишком часто чтобы делать дампы или предоставлять к ним прямой доступ
2. Необходимо предоставить данные недоверенным пользователям и поэтому прямой доступ к данным невозможен
3. Данные предоставляются на каких либо условиях предусматривающих ограничения, например, за деньги и ограничением числа записей за раз
4. API необходимо для интеграции с каким-либо существующим ПО которое умеет в API, но плохо или совсем не умеет работать с дампами и выгрузками данных
5. Нужна возможность ссылаться постоянными ссылками на конкретные записи в машиночитаемом виде.
6. API нужно, например, для быстрого написания фронтэнда или иного интерфейса которое бы через это API работало

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

Эти инструменты можно поделить на условно 3 типа:
- преобразующие данные в API
- создающие API поверх SQL и других баз данных
- позволяющие загрузить данные и сразу получить API на выходе

Для превращения данных несколько инструментов существовало относительно давно, например, csv-to-api и csv2api, они работали с CSV файлами и в общем-то довольно просты

Для баз данных есть инструменты вроде:
- gosql относительно свежий, работает поверх условно любой SQL базы данных
- Express REST API Generator - для MongoDB, давно не обновлялся
- RestHEART аналогично для MongoDB, но вроде как живой
- DataBeam код 12-летней давности от GSA (орган пр-ва США) с поддержкой преимущественно тяжелых корпоративных баз данных

И, наконец, есть какое-то число low-code инструментов вроде Retool, Baserow, Directus и тд. которые позволяют загружать туда таблицы и генерируют интерфейс для их редактирования и API заодно.

В своё время я сделал два похожих инструмента. Первый, самый простой, apiready грузил данные в MongoDB (в основном это были csv или tsv) файлы, анализировал их и создавал API поверх них. Я этот инструмент довольно быстро забросил и писал его оочень давно.

Более продвинутый инструмент был apicrafter вместо загрузки данных, он строился поверх базы MongoDB и создавл интерфейсы с помощью Python Eve довольно удобного инструмента, но статического. А apicrafter анализировал данные и собирал схему для работы Python Eve.

Когда-то я думал сделать этот инструмент поумнее и автоматически генерировать не только точки к API, но и документацию, примеры и тд., но со временем я начал убеждаться что MongoDB - это, конечно, неплохая штука, но с несколькими системными изъянами главные из которых низкая производительность и серьёзная неэффективность в хранении данных. В общем-то DuckDB или Polars или другие датафреймовые инструменты дают качественно лучший опыт в работе с данными, но переписывать под них не так то просто и главное нужно применение.

Тем не менее если решать не общую задачу, а конкретную по организации доступа к данным со всеми ограничениями, то может оказаться что схема данных + FastAPI + ИИ агент помогут собрать REST API гораздо быстрее. А могут и не собрать😂

В любом случае полезно знать про альтернативы и инструменты.

#api #opensource #datatools

Подборка полезных ссылок про данные, технологии и не только. В этот раз ссылки на видео:
- Meta Just Changed Data Compression FOREVER (OpenZL Explained) про новый инструмент для сжатия файлов OpenZL. Его важная особенность - это понимание форматов сжимаемых файлов и выбор правильного способа сжатия.
- Trustworthy Data Visualization (Kieran Healy, Duke University) видео с конфренции Posit 2025 о том как создавать визуализации данным которым можно доверять, полезное для всех кто визуализирует данные или читает визуализируемое. Автор написал немало про визуализацию, три книги и много статей ну и выступает весьма неплохо
- Mooncake: Real-Time Apache Iceberg Without Compromise (Cheng Chen) про построение озера данных с Apache Iceberg и Mooncake для реального времени. Заодно и с историей OLTP и OLAP и переход к озерам данных
- Introduction to OpenRefine использование OpenRefine, инструмента для очистки и обогащения данных. Примеры.и применение из работы с цифровыми архивами и библиотеками и не все знают что библиотекари - это основная аудитория пользователей OpenRefine.
- PostgresAI я так понимаю что это пока малоизвестный стартап который обещает применение ИИ для оптимизации баз Postgres. Концептуальная идея на поверхности, я, если честно, думал что появится что-то более универсальное по мониторингу и оптимизации с поддержкой разных СУБД. Честно говоря видео оформлено дурацки.и документация на их сайте практичнее

#readings #ai #datatools #datatools

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

#opensource #ai #privacy #llm #tools #datatools

После экспериментов с простым кодом, я постепенно добрался до тех инструментов которые используются внутри Dateno для сбора данных. Один из них это утилита apibackuper которая помогает вытащить данные публикуемые через API и сохранять их в виде датасета. Фактически это инструмент скрейпинга API через декларативное описание параметров скрейпинга (да, я люблю декларативные описания). У инструмента был ряд недостатков которые я исправлял и думаю что исправил, вот перечень изменений:
- переход от декларативного описания скрейперов с INI (.cfg) файлов на YAML, читать легче, синтаксис приятнее
- валидация YAML описаний через JSON схему
- поддержка ограченичений и таймаутов на число запросов в минуту (Rate Limiting)
- поддержка аутентификации к API
- экспорт данных не только в JSONL, но и в Parquet
- автоопределение формата экспорта данных по расширению файла
- массовое обработка исключений и понятные сообщения об ошибках везде где возможно
- тесты для покрытия большей части кода
- подробная документация
- и всякое по мелочи

Я этот инструмент изначально разрабатывал для для архивации данных публикуемых через API, но сейчас он используется в части кода Dateno для выгрузки метаданных из каталогов данных. Может его даже пора уже перенести из ruarxive в dateno на Github'е, ещё не решил.

На скриншоте то как это выглядит на примере реестра лекарственных средств ЕСКЛП

Для сбора данных достаточно выполнить две команды
- apibackuper run
- apibackuper export current.parquet

Первая выгрузит все данные постранично, вторая сохранит выгруженные данные в parquet файл.

#opensource #datatools #data #dataengineering

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

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

Кроме того хорошо отрабатывают задачи которые:
- находят ошибки в метаданных дата каталогов
- находят и исправляют дубликаты записей
- обогащают карточки каталогов тематиками и тэгами
- исправляют геоклассификацию каталогов
- и многое другое что предполагает массовое исправление и обогащение данных

Лично для меня и Dateno это очень хорошая новость это означает что реестр (dateno.io/registry) можно вести теперь значительно меньшими личными усилиями.

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

P.S. Тут я описываю внутренности происходящего в Dateno, которым я занимаюсь как основным проектом и продуктом. А новости проекта всегда можно читать в LinkedIn

#opendata #datacatalogs #ai #dev #datatools

Ещё про официальную статистику, есть важный тренд о котором я писал пока что мало - это отделение данных от их представления. Официальная статистика чаще всего строится как цельные системы в которых сразу есть и возможность получения данных и их визуальное представление.

А за это время появились десятки стартапов и сервисов которые наглядность обеспечивают значительно лучше официальные статистические сервисы, например, я довольно давно слежу за сервисом PlotSet с их интерактивными графиками. Очень наглядные штуки они генерируют в очень короткие сроки. При этом я не призываю использровать именно их, есть и другие варианты, и многие из них создаются с помощью ИИ агентов.

Ключевое тут в отделении данных от представления. Отдельно данные и API и отдельно интерактивный сервис на них основанный. Для популяризации официальной статистики такое разделение может быть эффективнее любых монолитных централизованных платформ.

Интересно, кстати, есть ли альтернативы PlotSet с открытым кодом?

#dataviz #statistics #datatools

Для тех кто анализирует данные и тд. я масштабно обновил инструмент metacrafter https://github.com/apicrafter/metacrafter по идентификации семантических типов данных, включая персональные данные по многим странам и языка.

Что изменилось:
- добавлено много новых правил и обновлены имеющиеся
- сильно оптимизирован код для ускорения мэтчинга правил
- добавлена возможность фильтрации правил по стране (страна указывается в файле правил)
- добавлено множество опций для командной строки

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

Собственно сами правила тоже обновились https://github.com/apicrafter/metacrafter-rules

Это не финальные изменения, а подготовка кода к интеграцию в Dateno.

#opensource #datatools #dataengineering