Пока я рассуждал о том что новые инструменты data wrangling'а (манипуляция и трансформация данных) появятся уже на базе движков вроде DuckDB или Clickhouse, они начали появляться. Свежее видео выступления Hannes Mühleisen - Data Wrangling [for Python or R] Like a Boss With DuckDB [1] ровно про это и слайды к нему же [2].
Автор/докладчик там сравнивает DuckDB в загрузке файлов и упоминает duckplyr [3] очень производительный заменитель популярной библиотеки Dplyr [4] для языка R.
Всю презентацию можно свести к утверждению что DuckDB - это круто для манипуляции данными и я склонен с этим согласиться.
Я бы ещё добавил что хорошо и правильно сравнивать и с интерактивными инструментами вроде OpenRefine, Talend, Trifacta и ещё рядом других. Собственно только отсутствие UI поверх движка DuckDB или Clickhouse ограничивает их популярность.
Если бы, к примеру, OpenRefine авторы переделали на движок DuckDB то цены бы ему не было и возможность работать с большими данными стала бы естественной. Но OpenRefine так просто не переделать, так что больше надежды что это создаст кто-то другой.
Я какое-то время назад проектировал такой движок и могу сказать что это не так сложно. Если бы не прорыв в индексации каталогов данных превратившийся в Dateno, я может быть такой data wrangling инструмент бы даже попробовал сделать, но сейчас просто мало времени на такое, тоже интересное занятие.
P.S. Кстати, для Python есть аналог dplyr под названием dplython [5], но попроще.
Ссылки:
[1] https://www.youtube.com/watch?v=GELhdezYmP0&list=PL9HYL-VRX0oSFkdF4fJeY63eGDvgofcbn&index=66
[2] https://blobs.duckdb.org/posit-conf-2024-keynote-hannes-muehleisen-data-wrangling-duckdb.pdf
[3] https://github.com/tidyverse/duckplyr?tab=readme-ov-file
[4] https://dplyr.tidyverse.org/
[5] https://github.com/dodger487/dplython
#opensource #data #datatools #rdbms #duckdb #dataengineering
Автор/докладчик там сравнивает DuckDB в загрузке файлов и упоминает duckplyr [3] очень производительный заменитель популярной библиотеки Dplyr [4] для языка R.
Всю презентацию можно свести к утверждению что DuckDB - это круто для манипуляции данными и я склонен с этим согласиться.
Я бы ещё добавил что хорошо и правильно сравнивать и с интерактивными инструментами вроде OpenRefine, Talend, Trifacta и ещё рядом других. Собственно только отсутствие UI поверх движка DuckDB или Clickhouse ограничивает их популярность.
Если бы, к примеру, OpenRefine авторы переделали на движок DuckDB то цены бы ему не было и возможность работать с большими данными стала бы естественной. Но OpenRefine так просто не переделать, так что больше надежды что это создаст кто-то другой.
Я какое-то время назад проектировал такой движок и могу сказать что это не так сложно. Если бы не прорыв в индексации каталогов данных превратившийся в Dateno, я может быть такой data wrangling инструмент бы даже попробовал сделать, но сейчас просто мало времени на такое, тоже интересное занятие.
P.S. Кстати, для Python есть аналог dplyr под названием dplython [5], но попроще.
Ссылки:
[1] https://www.youtube.com/watch?v=GELhdezYmP0&list=PL9HYL-VRX0oSFkdF4fJeY63eGDvgofcbn&index=66
[2] https://blobs.duckdb.org/posit-conf-2024-keynote-hannes-muehleisen-data-wrangling-duckdb.pdf
[3] https://github.com/tidyverse/duckplyr?tab=readme-ov-file
[4] https://dplyr.tidyverse.org/
[5] https://github.com/dodger487/dplython
#opensource #data #datatools #rdbms #duckdb #dataengineering
К вопросу о дата продуктах, реестр каталогов данных 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
Для тех кто хочет поработать с относительно небольшими открытыми данными в области культуры по ссылке доступен слепок Госкаталога музейного фонда РФ в формате Parquet (3GB) преобразованный из слепка датасета в 78GB с портала данных Минкультуры.
Для тех кто захочет поделать интересных запросов к этим данным вот тут их примеры которые я приводил на семинаре и которые можно делать с помощью DuckDB.
Подчеркну что с файлами Parquet и DuckDB работать можно на недорогих ноутбуках, настольных компьютерах и тд., загружать эти данные на сервер нет необходимости.
Серия запросов по объединению наиболее тяжелых экспонатов по весу и получению отсортированного списка предметов по весу в любом измерении
1. copy (select name, museum.name, weight/1000 as weight from 'data.parquet' where weightUnit = '{"name":"килограммы"}' order by weight desc) to 'heavy_kg_to_tonn.csv';
2. copy (select name, museum.name, weight/100000 as weight from 'data.parquet' where weightUnit = '{"name":"граммы"}' order by weight desc) to 'heavy_gramm.csv';
3. copy (select name, museum.name, weight from 'data.parquet' where weightUnit = '{"name":"тонны"}' order by weight desc) to 'heavy_tonn.csv';
4. select * from read_csv(['heavy_kg_to_tonn.csv', 'heavy_tonn.csv']) order by weight desc;
Рейтинг музеев по качеству заполнения описания (поле description) во внесённых элементах каталога
select t1.name as name, c as num, total, c*100.0/total as share from (select museum.name as name, count(id) as c from 'data.parquet' where len(description) = 0 group by museum.name) as t1 join (select museum.name as name, count(id) as total from 'data.parquet' group by museum.name) as t2 on t1.name = t2.name order by share desc;
Рейтинг музеев по качеству заполнения invNumber (инвентарный номер) во внесённых элементах каталога
select t1.name as name, c as num, total, c*100.0/total as share from (select museum.name as name, count(id) as c from 'data.parquet' where invNumber = '' group by museum.name) as t1 join (select museum.name as name, count(id) as total from 'data.parquet' group by museum.name) as t2 on t1.name = t2.name order by share desc;
#opendata #russia #parquet #duckdb
Для тех кто захочет поделать интересных запросов к этим данным вот тут их примеры которые я приводил на семинаре и которые можно делать с помощью DuckDB.
Подчеркну что с файлами Parquet и DuckDB работать можно на недорогих ноутбуках, настольных компьютерах и тд., загружать эти данные на сервер нет необходимости.
Серия запросов по объединению наиболее тяжелых экспонатов по весу и получению отсортированного списка предметов по весу в любом измерении
1. copy (select name, museum.name, weight/1000 as weight from 'data.parquet' where weightUnit = '{"name":"килограммы"}' order by weight desc) to 'heavy_kg_to_tonn.csv';
2. copy (select name, museum.name, weight/100000 as weight from 'data.parquet' where weightUnit = '{"name":"граммы"}' order by weight desc) to 'heavy_gramm.csv';
3. copy (select name, museum.name, weight from 'data.parquet' where weightUnit = '{"name":"тонны"}' order by weight desc) to 'heavy_tonn.csv';
4. select * from read_csv(['heavy_kg_to_tonn.csv', 'heavy_tonn.csv']) order by weight desc;
Рейтинг музеев по качеству заполнения описания (поле description) во внесённых элементах каталога
select t1.name as name, c as num, total, c*100.0/total as share from (select museum.name as name, count(id) as c from 'data.parquet' where len(description) = 0 group by museum.name) as t1 join (select museum.name as name, count(id) as total from 'data.parquet' group by museum.name) as t2 on t1.name = t2.name order by share desc;
Рейтинг музеев по качеству заполнения invNumber (инвентарный номер) во внесённых элементах каталога
select t1.name as name, c as num, total, c*100.0/total as share from (select museum.name as name, count(id) as c from 'data.parquet' where invNumber = '' group by museum.name) as t1 join (select museum.name as name, count(id) as total from 'data.parquet' group by museum.name) as t2 on t1.name = t2.name order by share desc;
#opendata #russia #parquet #duckdb
hubofdata.ru
Государственный каталог музейного фонда в формате Parquet - Хаб открытых данных
Оригинальные данные опубликованы по адресу https://opendata.mkrf.ru/opendata/7705851331-museum-exhibits В этом наборе данных была взята версия 3 от 23.09.2023 и преобразована из формата JSONS в...
В продолжение моих расхваливаний в адрес Parquet и DuckDB, приведу ещё один пример. Для задача Dateno я в последние дни анализирую большой датасет индикаторов статистики Всемирного банка из data.worldbank.org.
И вот, для справки, Всемирный банк предоставляет данные своих индикаторов не самым удобным образом. При многих достоинствах их данных, но там почти нет того что называется массовой выгрузкой, bulk download, и приходится выкачивать данные через API. Выгрузка этих данных по каждому индикатору - это около 22 ГБ в виде 3382 JSON файлов. Общим объёмом около 76 миллионов записей. Это не все, а примерно 12% всех индикаторов которые удалось проверить. Немного, на самом деле, но всё равно надо чуть-чуть заморочиться.
После преобразования этих файлов в один Parquet файл его размер составляет 44MB, а это 0.2% от исходного объёма. Опять же полученный файл не только сохраняет все возможности его анализа, но и этот анализ происходит куда быстрее.
Откуда такая эффективность? От того что данные индикаторов сильно денормалированы. Колоночное сжатие на них крайне эффективно. Жаль что Всемирный банк данные для массовой выгрузки до сих пор не публикует, хочется надеяться что когда-нибудь начнёт.
Но важный вывод тут ещё и в другом. Если кто-то из статистических служб и не только говорит о том что они не публикуют данные потому что они очень большие и рядовой пользователь не может с ними работать, то знайте что этот человек:
1) Или безграмотен.
2) Или целенаправленно врёт.
Кроме DuckDB и Parquet есть и другие инструменты сильно снижающие порог аналитической работы на недорогих устройствах.
#opendata #duckdb #statistics #parquet #worldbank
И вот, для справки, Всемирный банк предоставляет данные своих индикаторов не самым удобным образом. При многих достоинствах их данных, но там почти нет того что называется массовой выгрузкой, bulk download, и приходится выкачивать данные через API. Выгрузка этих данных по каждому индикатору - это около 22 ГБ в виде 3382 JSON файлов. Общим объёмом около 76 миллионов записей. Это не все, а примерно 12% всех индикаторов которые удалось проверить. Немного, на самом деле, но всё равно надо чуть-чуть заморочиться.
После преобразования этих файлов в один Parquet файл его размер составляет 44MB, а это 0.2% от исходного объёма. Опять же полученный файл не только сохраняет все возможности его анализа, но и этот анализ происходит куда быстрее.
Откуда такая эффективность? От того что данные индикаторов сильно денормалированы. Колоночное сжатие на них крайне эффективно. Жаль что Всемирный банк данные для массовой выгрузки до сих пор не публикует, хочется надеяться что когда-нибудь начнёт.
Но важный вывод тут ещё и в другом. Если кто-то из статистических служб и не только говорит о том что они не публикуют данные потому что они очень большие и рядовой пользователь не может с ними работать, то знайте что этот человек:
1) Или безграмотен.
2) Или целенаправленно врёт.
Кроме DuckDB и Parquet есть и другие инструменты сильно снижающие порог аналитической работы на недорогих устройствах.
#opendata #duckdb #statistics #parquet #worldbank
Видеозаписи прошедших семинаров:
- "Лучшие практики работы с большими научными данными: используем Parquet и DuckDB" доступен на сайте ИВ РАН или напрямую на RuTube или на YouTube
- "Дата-инженерия в цифровой гуманитаристике" доступен в сообществе в VK и в YouTube
Если кому-то будут интересны презентации с этих семинаров, напишите в комментарии, я их выложу онлайн или пришлю ссылку.
Честно говоря я давно не читал лекций и не выступал, сначала
Ближайшие мои выступления или мастер-классы будут в рамках дня открытых данных в России и в Армении, скорее и там, и там.
P.S. Ссылки на презентации:
- Дата инженерия в цифровой гуманитаристике
- Лучшие практики работы с большими научными данными. Используем Parquet и DuckDB
#opendata #digitalhumanities #lectures #parquet #duckdb #dataengineering
- "Лучшие практики работы с большими научными данными: используем Parquet и DuckDB" доступен на сайте ИВ РАН или напрямую на RuTube или на YouTube
- "Дата-инженерия в цифровой гуманитаристике" доступен в сообществе в VK и в YouTube
Если кому-то будут интересны презентации с этих семинаров, напишите в комментарии, я их выложу онлайн или пришлю ссылку.
Честно говоря я давно не читал лекций и не выступал, сначала
Ближайшие мои выступления или мастер-классы будут в рамках дня открытых данных в России и в Армении, скорее и там, и там.
P.S. Ссылки на презентации:
- Дата инженерия в цифровой гуманитаристике
- Лучшие практики работы с большими научными данными. Используем Parquet и DuckDB
#opendata #digitalhumanities #lectures #parquet #duckdb #dataengineering
JSONBench [1] свежий бенчмарк для аналитических баз данных работающих с JSON от команды ClickHouse. Ожидаемо в бенчмарке ClickHouse на первых местах ;), но надо отдать им должное, в блоге у них подробный методологический рассказ про это [2] и конкуренты могут прийти и возразить обоснованно, если, конечно, придут.
Сам бенчмарк основан на датасете размером в 482GB в несжатом виде событий из соцсети BlueSky. В сжатом с помощью zstd виде они занимают 124GB, а в ClickHouse 99GB и 622GB в PostgreSQL.
Споры тут могут быть, в основном, исходя из моделей использования и подходов. К примеру, у DuckDB есть тип данных JSON, но в целом с его помощью можно работать с JSON файлами как с таблицами и импортировать их не в JSON тип, а сразу развертывать в табличную форму.
Что я лично и сделал бы с этими данными BlueSky вначале преобразовав из в Parquet.
С другой стороны способность ClickHouse работать с JSON объектами явно растёт и с той точки измерений что они проводили - это хороший тест.
Ссылки:
[1] https://jsonbench.com/
[2] https://clickhouse.com/blog/json-bench-clickhouse-vs-mongodb-elasticsearch-duckdb-postgresql
#clickhouse #postgresql #mongodb #duckdb #benchmark #json #rdbms
Сам бенчмарк основан на датасете размером в 482GB в несжатом виде событий из соцсети BlueSky. В сжатом с помощью zstd виде они занимают 124GB, а в ClickHouse 99GB и 622GB в PostgreSQL.
Споры тут могут быть, в основном, исходя из моделей использования и подходов. К примеру, у DuckDB есть тип данных JSON, но в целом с его помощью можно работать с JSON файлами как с таблицами и импортировать их не в JSON тип, а сразу развертывать в табличную форму.
Что я лично и сделал бы с этими данными BlueSky вначале преобразовав из в Parquet.
С другой стороны способность ClickHouse работать с JSON объектами явно растёт и с той точки измерений что они проводили - это хороший тест.
Ссылки:
[1] https://jsonbench.com/
[2] https://clickhouse.com/blog/json-bench-clickhouse-vs-mongodb-elasticsearch-duckdb-postgresql
#clickhouse #postgresql #mongodb #duckdb #benchmark #json #rdbms
Полезные ссылки про данные, технологии и не только:
- DocumentDB: Open-Source Announcement [1] похоже Microsoft выложили в открытый код [2] новый NoSQL продукт, прямой конкурент MongoDB. Внутри там FerretDB и PostgreSQL, бенчмарки пока не наблюдаются, что странно. Может быть в ClickBench/JSONBench они появятся через какое-то время. Пока главное достоинство лицензия MIT.
- ai_query function [3] в Databricks есть функция ai_query которую можно использовать прямо в SQL запросе и которая позволяет обрабатывать данные с помощью одной из LLM специальным запросом. Осталось подождать когда такая функция или аналог появятся во всех современных RDBMS
- Human-Computer Input via a Wrist-Based sEMG Wearable [4] исследование Metaпро уличную магию про использование жестов для управления устройствами. Помимо того что это может поменять многое в обыденной жизни тут ещё и много открытых наборов данных Я думал такие устройства будут делать в виде тонких перчаток, а оказывается что можно в виде браслета.
- pg_mooncake. Postgres extension for 1000x faster analytics [5] расширение для колоночных таблиц для PostgreSQL для ускорения аналитики. Внутри, ожидаемо, DuckDB
Ссылки:
[1] https://opensource.microsoft.com/blog/2025/01/23/documentdb-open-source-announcement/
[2] https://github.com/microsoft/documentdb
[3] https://docs.databricks.com/en/sql/language-manual/functions/ai_query.html#examples
[4] https://www.meta.com/blog/surface-emg-wrist-white-paper-reality-labs/
[5] https://github.com/Mooncake-Labs/pg_mooncake
#opensource #rdbms #postgresql #duckdb #datatools
- DocumentDB: Open-Source Announcement [1] похоже Microsoft выложили в открытый код [2] новый NoSQL продукт, прямой конкурент MongoDB. Внутри там FerretDB и PostgreSQL, бенчмарки пока не наблюдаются, что странно. Может быть в ClickBench/JSONBench они появятся через какое-то время. Пока главное достоинство лицензия MIT.
- ai_query function [3] в Databricks есть функция ai_query которую можно использовать прямо в SQL запросе и которая позволяет обрабатывать данные с помощью одной из LLM специальным запросом. Осталось подождать когда такая функция или аналог появятся во всех современных RDBMS
- Human-Computer Input via a Wrist-Based sEMG Wearable [4] исследование Meta
- pg_mooncake. Postgres extension for 1000x faster analytics [5] расширение для колоночных таблиц для PostgreSQL для ускорения аналитики. Внутри, ожидаемо, DuckDB
Ссылки:
[1] https://opensource.microsoft.com/blog/2025/01/23/documentdb-open-source-announcement/
[2] https://github.com/microsoft/documentdb
[3] https://docs.databricks.com/en/sql/language-manual/functions/ai_query.html#examples
[4] https://www.meta.com/blog/surface-emg-wrist-white-paper-reality-labs/
[5] https://github.com/Mooncake-Labs/pg_mooncake
#opensource #rdbms #postgresql #duckdb #datatools
Microsoft Open Source Blog
DocumentDB: Open-Source Announcement - Microsoft Open Source Blog
Learn more on how Microsoft Open Source can help with you with your data stores with the announcement of DocumentDB.
Вышла новая версия Duckdb 1.2.0 [1] что важно - это существенная оптимизация скорости чтения данных. Пишут что обновили парсер для CSV [2] ускорив его до 15% и общие ускорение на 13% по тестам TPC-H SF100.
Из другого важного - CSV парсер теперь поддерживает кодировки UTF-16 и Latin-1. Это хорошо, но пока недостаточно. Один из актуальных недостатков DuckDB в том что до сих пор он поддерживал только CSV файлы в кодировке UTF-8, а из всех остальных кодировок данные надо было преобразовывать. Почему так лично я до сих пор не знаю, подозреваю что дело в том что команда DuckDB фокусируется на повышении производительности.
Там есть и другие изменения, но, в целом, менее значимые. Основные сценарии использования DuckDB связаны с парсингом CSV и работой с другими дата-файлами и с общей производительностью.
Ссылки:
[1] https://duckdb.org/2025/02/05/announcing-duckdb-120
[2] https://github.com/duckdb/duckdb/pull/14260
#opensource #duckdb #datatools #rdbms
Из другого важного - CSV парсер теперь поддерживает кодировки UTF-16 и Latin-1. Это хорошо, но пока недостаточно. Один из актуальных недостатков DuckDB в том что до сих пор он поддерживал только CSV файлы в кодировке UTF-8, а из всех остальных кодировок данные надо было преобразовывать. Почему так лично я до сих пор не знаю, подозреваю что дело в том что команда DuckDB фокусируется на повышении производительности.
Там есть и другие изменения, но, в целом, менее значимые. Основные сценарии использования DuckDB связаны с парсингом CSV и работой с другими дата-файлами и с общей производительностью.
Ссылки:
[1] https://duckdb.org/2025/02/05/announcing-duckdb-120
[2] https://github.com/duckdb/duckdb/pull/14260
#opensource #duckdb #datatools #rdbms
DuckDB
Announcing DuckDB 1.2.0
The DuckDB team is happy to announce that today we're releasing DuckDB version 1.2.0, codenamed “Histrionicus”.