К вопросу о poor man data engineering, как обрабатывать данные в условиях ограниченных ресурсов с минимальными нагрузками на диск и на оперативную память, в первую очередь.
В работе в Dateno есть задача по добавлению стат. индикаторов в основной индекс и расширение фасетов на данными о частоте обновления индикаторов и временном промежутке который он охватывает (год начала и год окончания). Не у всех датасетов такие метаданные есть и есть особенность датасетов Европейского центрального банка (ECB) в том что для массовой выгрузки доступны сами данные, но не метаданные. Хотя обычно наоборот. А в данном случае можно скачать все значения, а метаданные из них надо извлечь.
Эти значения публикуются в виде коллекции из 108 CSV файлов общим объёмом в 93GB. Это не то чтобы много, но много для статистики и для обработки на десктопе. Первая мысль которая возникает, а не уменьшить ли эти данные в объёме. Можно их сжать, но ещё эффективнее преобразовать в parquet. После преобразования они занимают 664 MB. Это 0,7% от изначального объёма, итого сжатие в 140 раз! Такая эффективность редкость, обычно сжатие в 5-15 раз, но здесь накладывается эффект колоночного сжатия поскольку данные ECB денормализованные, эффективность хранения там уступает полноте публикации и простоте раскрытия.
Далее обработка. Чтобы получить метаданные каждого индикатора надо:
1. Получить список уникальных идентификаторов индикаторов
2. Для каждого ключа сделать запрос одной записи для извлечения метаданных
3. Получить минимальное и максимальное значения временного периода
4. Извлечь год из минимального и максимального значения если период не равен году.
Итого 3 запроса, которые, наверняка, можно было бы оптимизировать до 2-х и которые можно делать напрямую к файлам parquet. Однако ситуация осложняется тем что эти файлы parquet хотя и хорошо сжаты, но могут содержать до 570+ тысяч индикаторов, как это, например, происходит с датасетом Securities Issues Statistics, который в оригинале составляет 19GB CSV файл и содержит 30 миллионов строк.
При работе с этим датасетом, даже после преобразования в parquet, DuckDB "съедает" до 15GB RAM и работает, хотя и быстро, но не так быстро как хотелось бы.
Варианты решения:
1. Попробовать преобразовать данные в базу DuckDB, построить индексы и так обрабатывать. Минус: резко увеличивается объём хранения данных, не увеличивается скорость обработки.
2. Попробовать нормализовать данные и извлекать метаданные из нормализованных баз. Минус: время на преобразование многократно больше времени сбора метаданных из существующих parquet файлов, а также у разных датасетов разная схема данных и требуется потратить больше времени на их анализ.
Варианты с тем чтобы загрузить в какую-то другую СУБД или даже не рассматривались поскольку задача именно в обработке на среднемощном десктопе/ноутбуке и без резкого роста объёмов хранения.
Итоговое решение оказалось очень простым. Специфика запросов в том что они полностью локализованы внутри данных конкретного индикатора.
Но, так повезло, что в этих датасетах индикаторы разделены по группам являющихся странами или территориями, от 8 до 33 в одном датасете и разделять можно по ним. Данные отдельных индикаторов полностью попадают в один из разделённых файлов. И, одна из фишек DuckDB - это очень дешёвое разделение данных с точки зрения скорости и нагрузки на память. До обработки большого датасета через серию COPY TO операций из него создаются десятки меньших .parquet файлов каждый из которых обрабатывается по отдельности.
Итого:
- средняя скорость однопоточной обработки достигает 78 индикаторов в секунду
- потребление RAM не превышает 100MB, а в среднем держится менее 50MB
- потребление диска +664MB, теперь не в 140 раз меньше чем оригинальные CSV файлы, а только в 70 раз, но всё ещё очень и очень мало.
Понятно что перенеся всё это на серверную инфраструктуру, в несколько потоков и тд. можно многократно ускорить обработку данных, но и так с помощью DuckDB конвейеры данных можно запускать на очень дешёвом железе и получать приемлемый результат.
#data #thoughts #tech #duckdb #dataengineering
В работе в Dateno есть задача по добавлению стат. индикаторов в основной индекс и расширение фасетов на данными о частоте обновления индикаторов и временном промежутке который он охватывает (год начала и год окончания). Не у всех датасетов такие метаданные есть и есть особенность датасетов Европейского центрального банка (ECB) в том что для массовой выгрузки доступны сами данные, но не метаданные. Хотя обычно наоборот. А в данном случае можно скачать все значения, а метаданные из них надо извлечь.
Эти значения публикуются в виде коллекции из 108 CSV файлов общим объёмом в 93GB. Это не то чтобы много, но много для статистики и для обработки на десктопе. Первая мысль которая возникает, а не уменьшить ли эти данные в объёме. Можно их сжать, но ещё эффективнее преобразовать в parquet. После преобразования они занимают 664 MB. Это 0,7% от изначального объёма, итого сжатие в 140 раз! Такая эффективность редкость, обычно сжатие в 5-15 раз, но здесь накладывается эффект колоночного сжатия поскольку данные ECB денормализованные, эффективность хранения там уступает полноте публикации и простоте раскрытия.
Далее обработка. Чтобы получить метаданные каждого индикатора надо:
1. Получить список уникальных идентификаторов индикаторов
2. Для каждого ключа сделать запрос одной записи для извлечения метаданных
3. Получить минимальное и максимальное значения временного периода
4. Извлечь год из минимального и максимального значения если период не равен году.
Итого 3 запроса, которые, наверняка, можно было бы оптимизировать до 2-х и которые можно делать напрямую к файлам parquet. Однако ситуация осложняется тем что эти файлы parquet хотя и хорошо сжаты, но могут содержать до 570+ тысяч индикаторов, как это, например, происходит с датасетом Securities Issues Statistics, который в оригинале составляет 19GB CSV файл и содержит 30 миллионов строк.
При работе с этим датасетом, даже после преобразования в parquet, DuckDB "съедает" до 15GB RAM и работает, хотя и быстро, но не так быстро как хотелось бы.
Варианты решения:
1. Попробовать преобразовать данные в базу DuckDB, построить индексы и так обрабатывать. Минус: резко увеличивается объём хранения данных, не увеличивается скорость обработки.
2. Попробовать нормализовать данные и извлекать метаданные из нормализованных баз. Минус: время на преобразование многократно больше времени сбора метаданных из существующих parquet файлов, а также у разных датасетов разная схема данных и требуется потратить больше времени на их анализ.
Варианты с тем чтобы загрузить в какую-то другую СУБД или даже не рассматривались поскольку задача именно в обработке на среднемощном десктопе/ноутбуке и без резкого роста объёмов хранения.
Итоговое решение оказалось очень простым. Специфика запросов в том что они полностью локализованы внутри данных конкретного индикатора.
Но, так повезло, что в этих датасетах индикаторы разделены по группам являющихся странами или территориями, от 8 до 33 в одном датасете и разделять можно по ним. Данные отдельных индикаторов полностью попадают в один из разделённых файлов. И, одна из фишек DuckDB - это очень дешёвое разделение данных с точки зрения скорости и нагрузки на память. До обработки большого датасета через серию COPY TO операций из него создаются десятки меньших .parquet файлов каждый из которых обрабатывается по отдельности.
Итого:
- средняя скорость однопоточной обработки достигает 78 индикаторов в секунду
- потребление RAM не превышает 100MB, а в среднем держится менее 50MB
- потребление диска +664MB, теперь не в 140 раз меньше чем оригинальные CSV файлы, а только в 70 раз, но всё ещё очень и очень мало.
Понятно что перенеся всё это на серверную инфраструктуру, в несколько потоков и тд. можно многократно ускорить обработку данных, но и так с помощью DuckDB конвейеры данных можно запускать на очень дешёвом железе и получать приемлемый результат.
#data #thoughts #tech #duckdb #dataengineering
Смотрю презентации выступлений участников DuckCon 5 [1]. Там довольно много насыщенных докладов интересных, как с точки зрения технических особенностей применения DuckDB, так и с продуктовой точки зрения, когда применение в нужном месте даёт качественное повышение эффективности продукта.
Из того что особенно привлекло внимание так это выступление Miguel Filipe из Dune Analytics про то как они применяют DuckDB для предоставления результатов аналитикам из мира крипты [2] и Edward Ruiz из Boston University о том как он разработал на базе duckdb движок dbverse для языка R [3] который даёт существенный прирост скорости в обработке геномных и других научных данных.
В целом просмотренное подтверждает мои мысли что DuckDB хороший внутренний движок и фундаментальная технология для многих потенциальных продуктов.
Ссылки:
[1] https://duckdb.org/2024/08/15/duckcon5.html
[2] https://blobs.duckdb.org/events/duckcon5/miguel-filipe-delighting-users-with-restful-apis-and-duckdb.pdf
[3] https://blobs.duckdb.org/events/duckcon5/ed-ruiz-composable-database-libraries-for-larger-than-memory-scientific-analytics.pdf
#datatools #duckdb #dataengineering
Из того что особенно привлекло внимание так это выступление Miguel Filipe из Dune Analytics про то как они применяют DuckDB для предоставления результатов аналитикам из мира крипты [2] и Edward Ruiz из Boston University о том как он разработал на базе duckdb движок dbverse для языка R [3] который даёт существенный прирост скорости в обработке геномных и других научных данных.
В целом просмотренное подтверждает мои мысли что DuckDB хороший внутренний движок и фундаментальная технология для многих потенциальных продуктов.
Ссылки:
[1] https://duckdb.org/2024/08/15/duckcon5.html
[2] https://blobs.duckdb.org/events/duckcon5/miguel-filipe-delighting-users-with-restful-apis-and-duckdb.pdf
[3] https://blobs.duckdb.org/events/duckcon5/ed-ruiz-composable-database-libraries-for-larger-than-memory-scientific-analytics.pdf
#datatools #duckdb #dataengineering
DuckDB
DuckCon #5 in Seattle
DuckDB is an in-process SQL database management system focused on analytical query processing. It is designed to be easy to install and easy to use. DuckDB has no external dependencies. DuckDB has bindings for C/C++, Python, R, Java, Node.js, Go and other…
This media is not supported in your browser
VIEW IN TELEGRAM
Свежий любопытный BI(?) проект MotherDuck Data App Generator [1] который позволяет на основе датасета в DuckDB генерировать дата приложение. Приложение с открытым кодом, но зависит от инфраструктуры MotherDuck.
Хотя они и называют его Data App Generator, тут надо быть честными, это такой недо-BI, по крайней мере в текущей форме и примерах по генерации дашбордов.
Мне, честно говоря, показалось странным что они сделали такое, потому что визуализация данных не самая сильная сторона их команды, Mother Duck известны продуктом для облачной аналитики, но не BI. Но в итоге они, похоже, выбирают путь прокачки собственного продукта, а не интеграции с другими, предлагая свой продукт как бэкэнд.
В любом случае идея по генерации приложений на данных имеет право на существование и даже может быть весьма востребована.
Если бы я не был занят Dateno и поиском данных, я бы автоматизацию аналитики ставил бы где в верхней части своих приоритетов, потому что это большая рыночная востребованная тема.
Ссылки:
[1] https://motherduck.com/blog/data-app-generator/
#opensource #duckdb #data #dataapps #startups
Хотя они и называют его Data App Generator, тут надо быть честными, это такой недо-BI, по крайней мере в текущей форме и примерах по генерации дашбордов.
Мне, честно говоря, показалось странным что они сделали такое, потому что визуализация данных не самая сильная сторона их команды, Mother Duck известны продуктом для облачной аналитики, но не BI. Но в итоге они, похоже, выбирают путь прокачки собственного продукта, а не интеграции с другими, предлагая свой продукт как бэкэнд.
В любом случае идея по генерации приложений на данных имеет право на существование и даже может быть весьма востребована.
Если бы я не был занят Dateno и поиском данных, я бы автоматизацию аналитики ставил бы где в верхней части своих приоритетов, потому что это большая рыночная востребованная тема.
Ссылки:
[1] https://motherduck.com/blog/data-app-generator/
#opensource #duckdb #data #dataapps #startups
Пока я рассуждал о том что новые инструменты 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