Любопытное про стартапы на данных:
- Collibbra приобрели стартап по созданию SQL тетрадок Huspray [1] учитывая что основной бизнес Collibra это корпоративные каталоги данных, причём изначально с сильным акцентом на выявление персональных данных, то эта покупка про сдвиг приоритетов на дата аналитиков.
- Treefera подняли pre-seed $2.2 миллиона инвестиций на дата-платформу по мониторингу лесного покрова [2], внутри обещают ИИ и создание data продуктов
- DataBricks получили ещё $500 миллионов инвестиций в рамках Series I [3], пишут что это скорее всего раунд перед IPO и на IPO оценка может достигнуть $43 миллиардов.
- Gable получил $7 миллионов на seed стадии [4] - Gable это стартап по повышению качества данных через применение data contracts. Тут так и хочется спросить "а что так можно было?!", стартап явно под экосистему работы с данными в Modern data stack и под последующую покупку одним из крупных платформенных игроков.
Ссылки:
[1] https://www.collibra.com/us/en/company/newsroom/press-releases/collibra-acquires-sql-data-notebook-vendor-husprey
[2] https://www.treefera.com/blog/treefera-pre-seed-funding-round
[3] https://techcrunch.com/2023/09/14/databricks-raises-500m-more-boosting-valuation-to-43b-despite-late-stage-gloom/
[4] https://www.linkedin.com/feed/update/urn:li:activity:7107413267072917504/
#startups #data #dataquality
- Collibbra приобрели стартап по созданию SQL тетрадок Huspray [1] учитывая что основной бизнес Collibra это корпоративные каталоги данных, причём изначально с сильным акцентом на выявление персональных данных, то эта покупка про сдвиг приоритетов на дата аналитиков.
- Treefera подняли pre-seed $2.2 миллиона инвестиций на дата-платформу по мониторингу лесного покрова [2], внутри обещают ИИ и создание data продуктов
- DataBricks получили ещё $500 миллионов инвестиций в рамках Series I [3], пишут что это скорее всего раунд перед IPO и на IPO оценка может достигнуть $43 миллиардов.
- Gable получил $7 миллионов на seed стадии [4] - Gable это стартап по повышению качества данных через применение data contracts. Тут так и хочется спросить "а что так можно было?!", стартап явно под экосистему работы с данными в Modern data stack и под последующую покупку одним из крупных платформенных игроков.
Ссылки:
[1] https://www.collibra.com/us/en/company/newsroom/press-releases/collibra-acquires-sql-data-notebook-vendor-husprey
[2] https://www.treefera.com/blog/treefera-pre-seed-funding-round
[3] https://techcrunch.com/2023/09/14/databricks-raises-500m-more-boosting-valuation-to-43b-despite-late-stage-gloom/
[4] https://www.linkedin.com/feed/update/urn:li:activity:7107413267072917504/
#startups #data #dataquality
Collibra
Collibra Acquires SQL Data Notebook Vendor Husprey
Collibra, the Data Intelligence company, today announced the acquisition of Husprey, a leading integrated SQL data notebook platform.
👍6❤1
Я в своих выступлениях про поисковик по данным Dateno рассказывал про то что один из приоритетов его развития - это повышение качества данных.
Причём, чтобы было понятно, качество данных и их описания, метаданных, подавляющего числа порталов открытых данных плохое. Иногда совсем плохое - чаще, реже среднее, но очень хорошее - это огромная редкость. Причём почти всегда это качество является отражением того что с ним работают люди которые вручную вносят файлы и заполняют описание.
Вот пример одной из практических задач. В Dateno сейчас 3383 типа форматов файлов, но, в реальности, это лишь 129 форматов, потому что пользователи указывают в полях типа file format что попало, часто с ошибками. Помимо того что есть указания по которым вообще нельзя понять что это за файл, так есть ещё и много форм написания расширений и типов. На скриншотах примеры с форматами и расширениями которые приходится приводить в порядок, сейчас, полувручную. Похожая ситуация с типами MIME, они очень даже активно заполняются с ошибками, хотя, казалось бы, так быть не должно.
Поэтому большая часть работы над поисковиком - это обогащение данных, повышение качества их описания, извлечение метаданных из самих данных и многое другое для нормализации описания каждого датасета.
На скриншотах можно увидеть проверку в OpenRefine автоматически размеченных форматов и типов mime по одному из снапшотов базы Dateno. И это с оговоркой что сейчас проиндексированы далеко не самые "грязные" каталоги данных. Скорее всего ситуация будет сильно хуже с форматами когда начнём индексировать большие каталоги научных данных. Вот тут, конечно, хотелось бы найти инструмент который бы всё это делал без участия человека, но такого не наблюдается.
Потому что, например, определение форматов и типов mime относительно хорошо можно делать по содержанию файла, но скачивание всех-всех файлов для поисковика является весьма дорогостоящей задачей, и с точки зрения трафика и с точки зрения ресурсов.
#dateno #data #howitworks #datasearch #dataquality
Причём, чтобы было понятно, качество данных и их описания, метаданных, подавляющего числа порталов открытых данных плохое. Иногда совсем плохое - чаще, реже среднее, но очень хорошее - это огромная редкость. Причём почти всегда это качество является отражением того что с ним работают люди которые вручную вносят файлы и заполняют описание.
Вот пример одной из практических задач. В Dateno сейчас 3383 типа форматов файлов, но, в реальности, это лишь 129 форматов, потому что пользователи указывают в полях типа file format что попало, часто с ошибками. Помимо того что есть указания по которым вообще нельзя понять что это за файл, так есть ещё и много форм написания расширений и типов. На скриншотах примеры с форматами и расширениями которые приходится приводить в порядок, сейчас, полувручную. Похожая ситуация с типами MIME, они очень даже активно заполняются с ошибками, хотя, казалось бы, так быть не должно.
Поэтому большая часть работы над поисковиком - это обогащение данных, повышение качества их описания, извлечение метаданных из самих данных и многое другое для нормализации описания каждого датасета.
На скриншотах можно увидеть проверку в OpenRefine автоматически размеченных форматов и типов mime по одному из снапшотов базы Dateno. И это с оговоркой что сейчас проиндексированы далеко не самые "грязные" каталоги данных. Скорее всего ситуация будет сильно хуже с форматами когда начнём индексировать большие каталоги научных данных. Вот тут, конечно, хотелось бы найти инструмент который бы всё это делал без участия человека, но такого не наблюдается.
Потому что, например, определение форматов и типов mime относительно хорошо можно делать по содержанию файла, но скачивание всех-всех файлов для поисковика является весьма дорогостоящей задачей, и с точки зрения трафика и с точки зрения ресурсов.
#dateno #data #howitworks #datasearch #dataquality
👍9❤2⚡2👏1
К вопросу о дата продуктах, реестр каталогов данных Dateno [1] - это как раз один из них, как сайт, и как репозиторий кода [2]. В нём и собственные результаты сбора каталогов так и то что присылали и присылают пользователи.
И если сам Dateno - это продукт с потенциальной монетизацией и доступом по API (кстати не забудьте зарегистрироваться и попробовать API тут dateno.io), то каталог - это датасет в JSON lines, а теперь ещё и в формате parquet, вот ту можно его забрать [3].
Как и у любого дата продукта у него есть метрики качества. Некоторые из них трудно измерить - это полнота, поскольку референсных каталогов теперь нет, Dateno давно уже превосходит по масштабу все аналогичные. Не хвастаюсь, а печалюсь, не с чем сравнить.
Но то что касается постепенного обогащения данных можно измерить. Например, у каждого каталога есть поле status оно может иметь значения active и scheduled. Значение active то что каталог прошёл ручное заполнение и обогащение метаданными, у него у уникального uid'а есть префикс cdi. А есть значение scheduled у него префикс temp и это означает что это скорее всего каталог данных, но не проверенный вручную и не обогащённый метаданными.
Таких временных каталогов данных примерно 60%. Сначала я непроверенные каталоги вёл в отдельном реестре, потом стало понятно что неполнота их метаданных это не повод их не индексировать и они были слиты в единый реестр с чистовыми записями.
При этом часть метаданных автозаполнены даже для таких каталогов. Для некоторых каталогов данных - это название, страна, язык, точки подключения API, тип ПО. Для других незаполнены эти атрибуты и ряд других.
При этом даже для тех каталогов данных которые чистовые может не быть привязки к темам, может не быть тегов, могут быть неуказаны точки подключения API и тд.
Иначе говоря всё это и есть то что надо измерять в метриках качества потому что часть этих атрибутов переходят в фасеты Dateno.
Самые простые метрики качества реестра могут измеряться несколькими достаточно простыми SQL запросами. Чуть более сложные метрики, запросами посложнее и набором правил в коде на Python.
Всё это, конечно, хорошо линкуется с работой над качеством самого индекса Dateno. А пока я могу в очередной раз порекомендовать DuckDB как универсальный инструмент для таких задач.
Ссылки:
[1] https://dateno.io/registry
[2] https://github.com/commondataio/dataportals-registry
[3] https://github.com/commondataio/dataportals-registry/raw/refs/heads/main/data/datasets/full.parquet
#dateno #dataquality #sql #duckdb #metrics #datacatalogs
И если сам Dateno - это продукт с потенциальной монетизацией и доступом по API (кстати не забудьте зарегистрироваться и попробовать API тут dateno.io), то каталог - это датасет в JSON lines, а теперь ещё и в формате parquet, вот ту можно его забрать [3].
Как и у любого дата продукта у него есть метрики качества. Некоторые из них трудно измерить - это полнота, поскольку референсных каталогов теперь нет, Dateno давно уже превосходит по масштабу все аналогичные. Не хвастаюсь, а печалюсь, не с чем сравнить.
Но то что касается постепенного обогащения данных можно измерить. Например, у каждого каталога есть поле status оно может иметь значения active и scheduled. Значение active то что каталог прошёл ручное заполнение и обогащение метаданными, у него у уникального uid'а есть префикс cdi. А есть значение scheduled у него префикс temp и это означает что это скорее всего каталог данных, но не проверенный вручную и не обогащённый метаданными.
Таких временных каталогов данных примерно 60%. Сначала я непроверенные каталоги вёл в отдельном реестре, потом стало понятно что неполнота их метаданных это не повод их не индексировать и они были слиты в единый реестр с чистовыми записями.
При этом часть метаданных автозаполнены даже для таких каталогов. Для некоторых каталогов данных - это название, страна, язык, точки подключения API, тип ПО. Для других незаполнены эти атрибуты и ряд других.
При этом даже для тех каталогов данных которые чистовые может не быть привязки к темам, может не быть тегов, могут быть неуказаны точки подключения API и тд.
Иначе говоря всё это и есть то что надо измерять в метриках качества потому что часть этих атрибутов переходят в фасеты Dateno.
Самые простые метрики качества реестра могут измеряться несколькими достаточно простыми SQL запросами. Чуть более сложные метрики, запросами посложнее и набором правил в коде на Python.
Всё это, конечно, хорошо линкуется с работой над качеством самого индекса Dateno. А пока я могу в очередной раз порекомендовать DuckDB как универсальный инструмент для таких задач.
Ссылки:
[1] https://dateno.io/registry
[2] https://github.com/commondataio/dataportals-registry
[3] https://github.com/commondataio/dataportals-registry/raw/refs/heads/main/data/datasets/full.parquet
#dateno #dataquality #sql #duckdb #metrics #datacatalogs
❤6👍3⚡1
Свежий интересный продукт по контролю качества данных DQX - Data Quality Framework от Databricks Labs [1].
Плюсы:
- зрелость поскольку Databricks один из лидеров рынка дата инженерии
- хорошая документация, судя по первому взгляду
- декларативное описание тестов в YAML (тут очень субъективно)
- интегрированность и заточенность на работу с Apache Spark
- открытый код на Github
Минусы:
- зависимость от Databricks Workspace в их дата каталоге Unity
- код открыт но лицензия несвободная, а специальная Databricks License с ограничениями [2], вполне возможно внешних контрибьюторов это оттолкнёт
Он очень напоминает движок Soda [3] который тоже даёт возможность декларативного описания тестов, но ещё более заточенный на их облачный сервис и который бесплатен только в рамках 45 дней тестирования. Можно пользоваться из Soda Core, правда, который под лицензией Apache 2.0
Итоговая ситуация такова что из частично открытых остались только движки Soda и great_expectations [4] который также стремительно коммерциализируется, но вроде как его команда обещала сохранить продукт GX Core под лицензией Apache 2.0 и развивать его, но как бы не закончилось также как с Elasticsearch и MongoDB, со сменой лицензии или тем что новые ключевые возможности будут только в облачных сервисах.
А DQX продукт интересный, но хотелось бы то же самое, но без вот этого вот всего (с).
Итого я могу сказать что есть заметный дефицит инструментов контроля качества данных. Сейчас нет ни одного подобного продукта под лицензией MIT, с простой интеграцией и, желательно, декларативным описанием тестов.
Поляна инструментов контроля качества данных совершенно точно заполнена не до конца и "рулят" на нём продукты в гибридном состоянии открытого кода и SaaS платформ.
Ссылки:
[1] https://databrickslabs.github.io/dqx/
[2] https://github.com/databrickslabs/dqx?tab=License-1-ov-file#readme
[3] https://github.com/sodadata/soda-core
[4] https://github.com/great-expectations/great_expectations
#opensource #dataquality #datatools
Плюсы:
- зрелость поскольку Databricks один из лидеров рынка дата инженерии
- хорошая документация, судя по первому взгляду
- декларативное описание тестов в YAML (тут очень субъективно)
- интегрированность и заточенность на работу с Apache Spark
- открытый код на Github
Минусы:
- зависимость от Databricks Workspace в их дата каталоге Unity
- код открыт но лицензия несвободная, а специальная Databricks License с ограничениями [2], вполне возможно внешних контрибьюторов это оттолкнёт
Он очень напоминает движок Soda [3] который тоже даёт возможность декларативного описания тестов, но ещё более заточенный на их облачный сервис и который бесплатен только в рамках 45 дней тестирования. Можно пользоваться из Soda Core, правда, который под лицензией Apache 2.0
Итоговая ситуация такова что из частично открытых остались только движки Soda и great_expectations [4] который также стремительно коммерциализируется, но вроде как его команда обещала сохранить продукт GX Core под лицензией Apache 2.0 и развивать его, но как бы не закончилось также как с Elasticsearch и MongoDB, со сменой лицензии или тем что новые ключевые возможности будут только в облачных сервисах.
А DQX продукт интересный, но хотелось бы то же самое, но без вот этого вот всего (с).
Итого я могу сказать что есть заметный дефицит инструментов контроля качества данных. Сейчас нет ни одного подобного продукта под лицензией MIT, с простой интеграцией и, желательно, декларативным описанием тестов.
Поляна инструментов контроля качества данных совершенно точно заполнена не до конца и "рулят" на нём продукты в гибридном состоянии открытого кода и SaaS платформ.
Ссылки:
[1] https://databrickslabs.github.io/dqx/
[2] https://github.com/databrickslabs/dqx?tab=License-1-ov-file#readme
[3] https://github.com/sodadata/soda-core
[4] https://github.com/great-expectations/great_expectations
#opensource #dataquality #datatools
👍7
Есть задачи для которых LLM совсем не годятся, а есть те которые годятся очень даже. Например, есть довольно узкая, но очень частая задача автоматического документирования данных.
У меня есть набор запросов к LLM на которых я это тестирую автодокументирование наборов данных. На полях/колонках которые содержат слова позволяющие по смыслу понять что там LLM выдает очень вменяемые ответы.
Это сколько же инструментов надо теперь переделать чтобы повысить их эффективность😂
В рамках экспериментов с Dateno у меня где-то несколько сотен тысяч схем CSV файлов которые можно превратить во что-то что было бы чем-то большим чем просто схема. В документацию.
#opendata #thoughts #datadiscovery #dataengineering #dataquality #datadocumentation
У меня есть набор запросов к LLM на которых я это тестирую автодокументирование наборов данных. На полях/колонках которые содержат слова позволяющие по смыслу понять что там LLM выдает очень вменяемые ответы.
Это сколько же инструментов надо теперь переделать чтобы повысить их эффективность😂
В рамках экспериментов с Dateno у меня где-то несколько сотен тысяч схем CSV файлов которые можно превратить во что-то что было бы чем-то большим чем просто схема. В документацию.
#opendata #thoughts #datadiscovery #dataengineering #dataquality #datadocumentation
👍6🤔4🔥2❤1
Полезные ссылки про данные, технологии и не только:
- The data validation landscape in 2025 [1] обзор библиотек для языка Python по проверке данных, охватывает только open source, без SaaS зависимостей типа Soda, но с перечислением альтернатив для great expectations. Полезно всем кто пишет тесты по проверке датасетов.
- Cutting-edge web scraping techniques workshop at NICAR 2025 [2] лонгрид/обзор/материал семинара по продвинутым техникам скрейпинга сайтов, включая использование LLM, GitHub Actions, Google AI Studio и других. Автор Simon Wilson хорошо известный многим дата журналистам, автор проекта Datasette
- NVIDIA-Ingest: Multi-modal data extraction [3] ускоренное извлечение метаданных из офисных документов и pdf с помощью сервисов NDIVIA. Не пробовал ещё, но потенциально важная штука для ускорения таких задач
- Defog Introspect: Deep Research for your internal data [4] выглядит как интересный пока ещё не продукт, но демо по исследованию датасетов и PDF файлов как структурированных источников, использует несколько внешних LLM.
- Introducing the New OpenAIRE Graph API: Enhanced functionalities and real-world applications [5] у проекта поисковика/агрегатора Евросоюза по научным результатам (статьи, данные, записи в базах и тд) появилось новое графовое API. Обещают представить его 3 апреля.
- Updating the Beneficial Ownership Data Standard RDF vocabulary to help linked data users [6] обновлённый стандарт публикации данных о конечных владельцах компаний, на сей раз для тех кто хочет использовать эти данные как связанные данные.
Ссылки:
[1] https://aeturrell.com/blog/posts/the-data-validation-landscape-in-2025/
[2] https://github.com/simonw/nicar-2025-scraping/
[3] https://github.com/NVIDIA/nv-ingest
[4] https://github.com/defog-ai/introspect
[5] https://www.openaire.eu/eventdetail/1427/introducing-the-new-openaire-graph-api-enhanced-functionalities-and-real-world-applications
[6] https://www.openownership.org/en/blog/updating-the-beneficial-ownership-data-standard-rdf-vocabulary-to-help-linked-data-users/
#opendata #linkeddat #opensource #webscraping #dataquality #openaire #openaccess
- The data validation landscape in 2025 [1] обзор библиотек для языка Python по проверке данных, охватывает только open source, без SaaS зависимостей типа Soda, но с перечислением альтернатив для great expectations. Полезно всем кто пишет тесты по проверке датасетов.
- Cutting-edge web scraping techniques workshop at NICAR 2025 [2] лонгрид/обзор/материал семинара по продвинутым техникам скрейпинга сайтов, включая использование LLM, GitHub Actions, Google AI Studio и других. Автор Simon Wilson хорошо известный многим дата журналистам, автор проекта Datasette
- NVIDIA-Ingest: Multi-modal data extraction [3] ускоренное извлечение метаданных из офисных документов и pdf с помощью сервисов NDIVIA. Не пробовал ещё, но потенциально важная штука для ускорения таких задач
- Defog Introspect: Deep Research for your internal data [4] выглядит как интересный пока ещё не продукт, но демо по исследованию датасетов и PDF файлов как структурированных источников, использует несколько внешних LLM.
- Introducing the New OpenAIRE Graph API: Enhanced functionalities and real-world applications [5] у проекта поисковика/агрегатора Евросоюза по научным результатам (статьи, данные, записи в базах и тд) появилось новое графовое API. Обещают представить его 3 апреля.
- Updating the Beneficial Ownership Data Standard RDF vocabulary to help linked data users [6] обновлённый стандарт публикации данных о конечных владельцах компаний, на сей раз для тех кто хочет использовать эти данные как связанные данные.
Ссылки:
[1] https://aeturrell.com/blog/posts/the-data-validation-landscape-in-2025/
[2] https://github.com/simonw/nicar-2025-scraping/
[3] https://github.com/NVIDIA/nv-ingest
[4] https://github.com/defog-ai/introspect
[5] https://www.openaire.eu/eventdetail/1427/introducing-the-new-openaire-graph-api-enhanced-functionalities-and-real-world-applications
[6] https://www.openownership.org/en/blog/updating-the-beneficial-ownership-data-standard-rdf-vocabulary-to-help-linked-data-users/
#opendata #linkeddat #opensource #webscraping #dataquality #openaire #openaccess
Arthur Turrell
Arthur Turrell is an economic data scientist.
👍8
Какое-то время я рассуждал о том как было бы хорошо если бы был инструмент для очистки и подготовки данных вроде OpenRefine, но более производительным движком внутри. Потому что OpenRefine хорошая штука, но с собственным движком на Java по работе с данными в памяти и всеми вытекающими из этого ограничениями на размеры датасетов. По личному опыту датасет в несколько гигабайт он уже тянет с трудом, на "стандартном настольном железе".
И вот вижу первый такой продукт, Coco Alemana [1] настольное приложение для очистки данных с DuckDB в качестве внутреннего движка. Обещают что работает с файлами до 50ГБ и нативную поддержку Parquet. Чем-то похоже на недавно появившийся DuckDB UI, но с акцентами на чистке и обработке данных.
Из дополнительных плюсов - быстрый поиск по данным и UI к базам данных.
Из минусов:
- работает только на Mac OS X, так что проверить лично смогут пока только маководы
- открытого кода нет, скорее это будет коммерческий продукт в будущем
Ссылки:
[1] https://www.cocoalemana.com
#duckdb #data #datatools #dataquality
И вот вижу первый такой продукт, Coco Alemana [1] настольное приложение для очистки данных с DuckDB в качестве внутреннего движка. Обещают что работает с файлами до 50ГБ и нативную поддержку Parquet. Чем-то похоже на недавно появившийся DuckDB UI, но с акцентами на чистке и обработке данных.
Из дополнительных плюсов - быстрый поиск по данным и UI к базам данных.
Из минусов:
- работает только на Mac OS X, так что проверить лично смогут пока только маководы
- открытого кода нет, скорее это будет коммерческий продукт в будущем
Ссылки:
[1] https://www.cocoalemana.com
#duckdb #data #datatools #dataquality
🤔4
Обнаружил ещё один инструмент по проверке данных validator [1], умеет делать кросс табличные проверки данных и использует схему из спецификации Frictionless Data [2]. Пока малоизвестный, но кто знает. Он выглядит неплохо по способу реализации, но есть проблема с самой спецификацией и о ней отдельно.
Я неоднократно писал про Frictionless Data, это спецификация и набор инструментов созданных в Open Knowledge Foundation для описания и публикации наборов данных. Спецификация много лет развивалась, вокруг неё появился пул инструментов, например, свежий Open Data Editor [3] помогающий готовить датасеты для публикации на дата платформах на базе ПО CKAN.
С этой спецификацией есть лишь одна, но серьёзная проблема. Она полноценно охватывает только плоские табличные файлы. Так чтобы работать со схемой данных, использовать их SDK, тот же Open Data Editor и тд. Это даёт ей применение для некоторых видов данных с которыми работают аналитики и куда хуже с задачами дата инженерными.
Существенная часть рабочих данных с которыми я сталкивался - это не табличные данные. К примеру, в плоские таблицы плохо ложатся данные о госконтрактах или юридических лицах или объектах музейных коллекций. Там естественнее применения JSON и, соответственно, построчного NDJSON.
Для таких данных куда лучше подходят пакеты валидации данных вроде Cerberus [4]. Я использовал её в случае с реестром дата каталогов [5] в Dateno и пока не видел решений лучше.
Ссылки:
[1] https://github.com/ezwelty/validator/
[2] https://specs.frictionlessdata.io
[3] https://opendataeditor.okfn.org
[4] https://docs.python-cerberus.org/
[5] https://github.com/commondataio/dataportals-registry/
#opensource #data #datatools #dataquality
Я неоднократно писал про Frictionless Data, это спецификация и набор инструментов созданных в Open Knowledge Foundation для описания и публикации наборов данных. Спецификация много лет развивалась, вокруг неё появился пул инструментов, например, свежий Open Data Editor [3] помогающий готовить датасеты для публикации на дата платформах на базе ПО CKAN.
С этой спецификацией есть лишь одна, но серьёзная проблема. Она полноценно охватывает только плоские табличные файлы. Так чтобы работать со схемой данных, использовать их SDK, тот же Open Data Editor и тд. Это даёт ей применение для некоторых видов данных с которыми работают аналитики и куда хуже с задачами дата инженерными.
Существенная часть рабочих данных с которыми я сталкивался - это не табличные данные. К примеру, в плоские таблицы плохо ложатся данные о госконтрактах или юридических лицах или объектах музейных коллекций. Там естественнее применения JSON и, соответственно, построчного NDJSON.
Для таких данных куда лучше подходят пакеты валидации данных вроде Cerberus [4]. Я использовал её в случае с реестром дата каталогов [5] в Dateno и пока не видел решений лучше.
Ссылки:
[1] https://github.com/ezwelty/validator/
[2] https://specs.frictionlessdata.io
[3] https://opendataeditor.okfn.org
[4] https://docs.python-cerberus.org/
[5] https://github.com/commondataio/dataportals-registry/
#opensource #data #datatools #dataquality
👍5😍1💯1
В задачах качества данных есть такое явление как Data quality reports. Не так часто встречается как хотелось бы и, в основном, для тех проектов где данные существуют как продукт (data-as-a-product) потому что клиенты интересуются.
Публичных таких отчётов немного, но вот любопытный и открытый - Global LEI Data Quality Reports [1] от создателей глобальной базы идентификаторов компаний LEI. Полезно было бы такое для многих крупных открытых датасетов, но редко встречается.
Ссылки:
[1] https://www.gleif.org/en/lei-data/gleif-data-quality-management/quality-reports
#opendata #datasets #dataquality
Публичных таких отчётов немного, но вот любопытный и открытый - Global LEI Data Quality Reports [1] от создателей глобальной базы идентификаторов компаний LEI. Полезно было бы такое для многих крупных открытых датасетов, но редко встречается.
Ссылки:
[1] https://www.gleif.org/en/lei-data/gleif-data-quality-management/quality-reports
#opendata #datasets #dataquality
✍5👍5
Полезные ссылки про данные, технологии и не только:
- 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
- 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
GitHub
GitHub - vanna-ai/vanna: 🤖 Chat with your SQL database 📊. Accurate Text-to-SQL Generation via LLMs using Agentic Retrieval 🔄.
🤖 Chat with your SQL database 📊. Accurate Text-to-SQL Generation via LLMs using Agentic Retrieval 🔄. - vanna-ai/vanna
1👍8
В рубрике полезных инструментов для работы с данными
- Textplot DuckDB Extension расширение для DuckDB для создания симпатичных текстовых графиков. Для всех кто любит работать в консоли
- DataKit сервис и одноимённый стартап по data exploration и анализу качества данных с помощью ИИ ассистента и тетрадок + визуализация. Выглядит как удобный рабочий инструмент аналитика, по ощущениям очень похожий на Mode. Цена пока неизвестна
#data #dataquality #datatools
- Textplot DuckDB Extension расширение для DuckDB для создания симпатичных текстовых графиков. Для всех кто любит работать в консоли
- DataKit сервис и одноимённый стартап по data exploration и анализу качества данных с помощью ИИ ассистента и тетрадок + визуализация. Выглядит как удобный рабочий инструмент аналитика, по ощущениям очень похожий на Mode. Цена пока неизвестна
#data #dataquality #datatools
✍6❤1
Кстати про инструменты которые относятся к data exploratory (изучение данных) включая визуализацию, контроль качества, поиск инсайтов и тд. Вот тот самый DataKit что я приводил ранее - это один из примеров таких инструментов и пример целого семейства/типа таких инструментов - работающих только в браузере.
В их основе DuckDB-WASM с возможностью вести всю обработку данных в браузере пользователя и таких инструментов всё больше. Это QuackDB, Duck-UI, SQL Workbench, PondPilot, Quacklytics, DB Pilot, Galaxy и другие. В некоторых уже есть встроенные ИИ ассистенты, в других в планах, но инструментов много.
Архитектура работы через DuckDB-WASM так привлекательна по нескольким причинам:
1. Вся нагрузка остаётся на пользовательском устройстве и на подключенной ИИ модели. Нагрузка на сам сервис минимальна.
2. Данные не выходят за контур устройства пользователя, кроме случаев когда пользователь осознанно хочет проаналитизировать данные с помощью LLM.
DuckDB-WASM не единственный пример движка обработки данных внутри WASM, есть и другие.
Важно что настольные приложения для обработки и анализа данных включая data exploration уже становятся моветоном.
#ai #datatools
В их основе DuckDB-WASM с возможностью вести всю обработку данных в браузере пользователя и таких инструментов всё больше. Это QuackDB, Duck-UI, SQL Workbench, PondPilot, Quacklytics, DB Pilot, Galaxy и другие. В некоторых уже есть встроенные ИИ ассистенты, в других в планах, но инструментов много.
Архитектура работы через DuckDB-WASM так привлекательна по нескольким причинам:
1. Вся нагрузка остаётся на пользовательском устройстве и на подключенной ИИ модели. Нагрузка на сам сервис минимальна.
2. Данные не выходят за контур устройства пользователя, кроме случаев когда пользователь осознанно хочет проаналитизировать данные с помощью LLM.
DuckDB-WASM не единственный пример движка обработки данных внутри WASM, есть и другие.
Важно что настольные приложения для обработки и анализа данных включая data exploration уже становятся моветоном.
#ai #datatools
Telegram
Ivan Begtin
В рубрике полезных инструментов для работы с данными
- Textplot DuckDB Extension расширение для DuckDB для создания симпатичных текстовых графиков. Для всех кто любит работать в консоли
- DataKit сервис и одноимённый стартап по data exploration и анализу…
- Textplot DuckDB Extension расширение для DuckDB для создания симпатичных текстовых графиков. Для всех кто любит работать в консоли
- DataKit сервис и одноимённый стартап по data exploration и анализу…
✍5❤2👍1
Ещё в продолжение правильного применения ИИ агентов, я системно занялся реестром каталогов данных в Dateno, я уже писал про предыдущее масштабное обновление, но это далеко не все. Основное обновление было про добавление большого числа каталогов данных. и их стало сильно больше.
А сейчас, в рамках задач по повышению качества индекса Dateno, повышение качество записей в реестре потому что при индексации датасетов часть их метаданных заполняется из записей в реестре. И здесь главное правильно сформулировать задачи ИИ агенту потому что это именно тот тип задач с которыми они справляются хорошо.
В итоге теперь в коде данных реестра появился отдельный блок dataquality в котором формируются отчеты по качеству записей. Отчеты разделены по странам, типам ошибок и критичности.
В общей сложности на 12281каталогов данных приходится 85956 ошибок, много, да? Потому что правила валидации весьма скурпулёзные и 49 тысяч из них - это проверка точек подключения к API (у одного каталога данных может быть до двух десятков таких API содержащих разные метаданные и данные).
Другие частые ошибки в отсутствии информации о лицензии каталога данных (она не всегда есть на уровне каталога, чаще лицензии указываются на уровне набора данных внутри, поэтому это корректируемое правило) и в отсутствии внешних идентификаторов у каталогов данных - это мэппинг каталогов данных на Wikidata и другие референсные источники, но тут важно знать что у большинства каталогов данных нет этих референсных источников и сам Dateno ими является.
Поэтому скурпулезность правил сейчас избыточная, в дальнейшем корректируемая, но безусловно полезная для собственного понимания что и как необходимо корректировать.
Что важно что все отчеты по качеству данных специально генерируются таким образом чтобы их можно было читать и править самостоятельно или же отдавать ИИ агенту командой примерно такого содержания "Fix issues listed in [название файла]"
А я по прежнему возвращаюсь к мысли о том что декларативная разработка справочных наборов данных и баз данных - это вполне рабочий подход достойный отдельного манифеста.
Второе направление мысли у меня по этому поводу в том что системные промпты и промпты это далеко не единственная модель взаимодействия которую могли бы предлагать среды разработки с ИИ. Я бы добавил что нехватает моделей взаимодействия которые я бы назвал сценарии и контроли. По сути есть стандартизированные цепочки промптов которые надо выполнять всегда при ручном или автоматизированном изменении кода.
Они включают:
- проверку и правку кода в части стилистика и линтинга (а ля pylint и аналоги для Python)
- подготовку и обновление тестов
- обновление документации (минимальное или весьма комплексное)
- acceptance тестирование (и другие виды тестирования при необходимости)
- сборка и релиз на Github/Gitlab/другой способ управления кодом
Многое из этого вшито в CI/CD пайплайны, но многое из этого может быть ИИ автоматизировано. Вопрос может ли это быть автоматизировано в IDE на стороне пользователя и пройти ручную финальную проверку или вынесено в CI/CD на внешнем сервисе и ручная проверка необязательна.
Мои ощущения что это скорее расширяемые модели контролируемых сценариев/строительных блоков внутри IDE с обязательными стадиями ручного контроля.
#thoughts #dateno #datacatalogs #dataquality
А сейчас, в рамках задач по повышению качества индекса Dateno, повышение качество записей в реестре потому что при индексации датасетов часть их метаданных заполняется из записей в реестре. И здесь главное правильно сформулировать задачи ИИ агенту потому что это именно тот тип задач с которыми они справляются хорошо.
В итоге теперь в коде данных реестра появился отдельный блок dataquality в котором формируются отчеты по качеству записей. Отчеты разделены по странам, типам ошибок и критичности.
В общей сложности на 12281каталогов данных приходится 85956 ошибок, много, да? Потому что правила валидации весьма скурпулёзные и 49 тысяч из них - это проверка точек подключения к API (у одного каталога данных может быть до двух десятков таких API содержащих разные метаданные и данные).
Другие частые ошибки в отсутствии информации о лицензии каталога данных (она не всегда есть на уровне каталога, чаще лицензии указываются на уровне набора данных внутри, поэтому это корректируемое правило) и в отсутствии внешних идентификаторов у каталогов данных - это мэппинг каталогов данных на Wikidata и другие референсные источники, но тут важно знать что у большинства каталогов данных нет этих референсных источников и сам Dateno ими является.
Поэтому скурпулезность правил сейчас избыточная, в дальнейшем корректируемая, но безусловно полезная для собственного понимания что и как необходимо корректировать.
Что важно что все отчеты по качеству данных специально генерируются таким образом чтобы их можно было читать и править самостоятельно или же отдавать ИИ агенту командой примерно такого содержания "Fix issues listed in [название файла]"
А я по прежнему возвращаюсь к мысли о том что декларативная разработка справочных наборов данных и баз данных - это вполне рабочий подход достойный отдельного манифеста.
Второе направление мысли у меня по этому поводу в том что системные промпты и промпты это далеко не единственная модель взаимодействия которую могли бы предлагать среды разработки с ИИ. Я бы добавил что нехватает моделей взаимодействия которые я бы назвал сценарии и контроли. По сути есть стандартизированные цепочки промптов которые надо выполнять всегда при ручном или автоматизированном изменении кода.
Они включают:
- проверку и правку кода в части стилистика и линтинга (а ля pylint и аналоги для Python)
- подготовку и обновление тестов
- обновление документации (минимальное или весьма комплексное)
- acceptance тестирование (и другие виды тестирования при необходимости)
- сборка и релиз на Github/Gitlab/другой способ управления кодом
Многое из этого вшито в CI/CD пайплайны, но многое из этого может быть ИИ автоматизировано. Вопрос может ли это быть автоматизировано в IDE на стороне пользователя и пройти ручную финальную проверку или вынесено в CI/CD на внешнем сервисе и ручная проверка необязательна.
Мои ощущения что это скорее расширяемые модели контролируемых сценариев/строительных блоков внутри IDE с обязательными стадиями ручного контроля.
#thoughts #dateno #datacatalogs #dataquality
🔥6⚡2❤1👍1😁1