Свежая научная статья Why TPC Is Not Enough: An Analysis of the Amazon Redshift Fleet [1] изнутри Amazon AWS с анализом около 32 миллионов таблиц и около 500 миллионов запросов за 3-х месячный период, а также открытый датасет который лежит в основе этой статьи и её выводов.
Для дата инженерии там немало инсайтов:
1. До сих пор использование parquet это редкость, большая часть клиентов AWS используют сжатые GZip'ом CSV и JSON файлы.
2. Самый популярный тип данных varchar, более 52%. Это ещё раз подтверждает что на AWS явно основное применение не для математических расчётов, анализа геномных данных и тд.
3. Реально больших данных мало, больше 99.8% запросов работают менее чем с 10TB.
По поводу последнего в блоге MotherDuck, пост со ссылкой на эту статью [3] как раз про то что "больших данных не существует" и то что статья про данные AWS это подтверждает. Реальная потребность в обработке очень больших данных невелика.
Ссылки:
[1] https://assets.amazon.science/24/3b/04b31ef64c83acf98fe3fdca9107/why-tpc-is-not-enough-an-analysis-of-the-amazon-redshift-fleet.pdf
[2] https://github.com/amazon-science/redset?tab=readme-ov-file
[3] https://motherduck.com/blog/redshift-files-hunt-for-big-data/
#datasets #data #datatools #dataresearch
Для дата инженерии там немало инсайтов:
1. До сих пор использование parquet это редкость, большая часть клиентов AWS используют сжатые GZip'ом CSV и JSON файлы.
2. Самый популярный тип данных varchar, более 52%. Это ещё раз подтверждает что на AWS явно основное применение не для математических расчётов, анализа геномных данных и тд.
3. Реально больших данных мало, больше 99.8% запросов работают менее чем с 10TB.
По поводу последнего в блоге MotherDuck, пост со ссылкой на эту статью [3] как раз про то что "больших данных не существует" и то что статья про данные AWS это подтверждает. Реальная потребность в обработке очень больших данных невелика.
Ссылки:
[1] https://assets.amazon.science/24/3b/04b31ef64c83acf98fe3fdca9107/why-tpc-is-not-enough-an-analysis-of-the-amazon-redshift-fleet.pdf
[2] https://github.com/amazon-science/redset?tab=readme-ov-file
[3] https://motherduck.com/blog/redshift-files-hunt-for-big-data/
#datasets #data #datatools #dataresearch
К вопросу об обработке данных с минимальным футпринтом (потреблением памяти оперативной и при хранении). Я добавил к библиотеке iterable пример по обработке дампов Википедии [1].
Для тех кто не сталкивался ранее, Фонд Викимедия обеспечивает открытость всех вариантов Википедии на сайте дампов [2] где они доступны в виде файлов SQL для загрузки в MySQL совместимые СУБД сжатых GZip и в виде дампов XML сжатых Bzip2. Если хочется поработать с этими данными локально, то надо или воссоздавать SQL базу данных из SQL файлов или работать с большими XML документами внутри которых страницы и другие объекты. Размер этих XML документов может быть весьма велик, до десятков гигабайт и обрабатывать их DOM парсерами весьма накладно.
Для некоторых задач Dateno мне нужны дампы Википедии, так чтобы к ним можно было строить запросы, но без желания воспроизводства инфраструктуры с MySQL и, в целом, хочется обрабатывать их оптимизировано.
Поэтому в примере выше использование библиотеки iterable для преобразования одной из маленьких Wiki (simplewiki) с дампом в 308MB в формате xml.bz2.
Идея в том чтобы:
1. Превратить его в формат для работы с помощью DuckDB
2. Сохранить минимально возможный объем для локального хранения, обработки и анализа.
3. Иметь возможность проделывать вме это на десктопе и с минимальным потреблением оперативной памяти.
В итоге пример можно посмотреть в репозитории. Два скрипта.
- convert.py преобразует xml.bz2 файл в jsonl.zst.
- enrich.py добавляет в полученный файл дополнительные метаданные по категориям вики страниц.
Почему jsonl и zst ? Потому что DuckDB умеет этот формат. После преобразования можно работать с ним напрямую без доп. преобразований.
Итог:
1. Сжатый XML дамп в 308MB преобразуется в сжатый JSONl файл в 325 MB
2. Время преобразования на простом десктопе порядка 2 минут.
3. С итоговым результатом можно работать как с базой данных DuckDB и делать запросы.
Еще лучше было бы будь возможность преобразовать в parquet, но и такой вариант пригоден к дальнейшей работе. К тому же parquet наиболее эффективен на хорошо сжимаемых колонках, а тут много викитекста для которого колоночное сжатие того же эффекта не несёт.
Пример на то и пример чтобы продемонстрировать саму идею. Simplewiki небольшая вики и на русскоязычной или испаноязычной википедиях процесс займёт дольше времени, но всё это демонстрация того что с этими данными можно работать локально и с удобными инструментами.
P.S. Если кто-то знает хорошие движки и примеры быстрого преобразования викидампов в компактные локальные базы данных, поделитесь плз.
Ссылки:
[1] https://github.com/apicrafter/pyiterable/tree/main/examples/simplewiki
[2] https://dumps.wikimedia.org
#dataengineering #datatools #opendata #wikipedia
Для тех кто не сталкивался ранее, Фонд Викимедия обеспечивает открытость всех вариантов Википедии на сайте дампов [2] где они доступны в виде файлов SQL для загрузки в MySQL совместимые СУБД сжатых GZip и в виде дампов XML сжатых Bzip2. Если хочется поработать с этими данными локально, то надо или воссоздавать SQL базу данных из SQL файлов или работать с большими XML документами внутри которых страницы и другие объекты. Размер этих XML документов может быть весьма велик, до десятков гигабайт и обрабатывать их DOM парсерами весьма накладно.
Для некоторых задач Dateno мне нужны дампы Википедии, так чтобы к ним можно было строить запросы, но без желания воспроизводства инфраструктуры с MySQL и, в целом, хочется обрабатывать их оптимизировано.
Поэтому в примере выше использование библиотеки iterable для преобразования одной из маленьких Wiki (simplewiki) с дампом в 308MB в формате xml.bz2.
Идея в том чтобы:
1. Превратить его в формат для работы с помощью DuckDB
2. Сохранить минимально возможный объем для локального хранения, обработки и анализа.
3. Иметь возможность проделывать вме это на десктопе и с минимальным потреблением оперативной памяти.
В итоге пример можно посмотреть в репозитории. Два скрипта.
- convert.py преобразует xml.bz2 файл в jsonl.zst.
- enrich.py добавляет в полученный файл дополнительные метаданные по категориям вики страниц.
Почему jsonl и zst ? Потому что DuckDB умеет этот формат. После преобразования можно работать с ним напрямую без доп. преобразований.
Итог:
1. Сжатый XML дамп в 308MB преобразуется в сжатый JSONl файл в 325 MB
2. Время преобразования на простом десктопе порядка 2 минут.
3. С итоговым результатом можно работать как с базой данных DuckDB и делать запросы.
Еще лучше было бы будь возможность преобразовать в parquet, но и такой вариант пригоден к дальнейшей работе. К тому же parquet наиболее эффективен на хорошо сжимаемых колонках, а тут много викитекста для которого колоночное сжатие того же эффекта не несёт.
Пример на то и пример чтобы продемонстрировать саму идею. Simplewiki небольшая вики и на русскоязычной или испаноязычной википедиях процесс займёт дольше времени, но всё это демонстрация того что с этими данными можно работать локально и с удобными инструментами.
P.S. Если кто-то знает хорошие движки и примеры быстрого преобразования викидампов в компактные локальные базы данных, поделитесь плз.
Ссылки:
[1] https://github.com/apicrafter/pyiterable/tree/main/examples/simplewiki
[2] https://dumps.wikimedia.org
#dataengineering #datatools #opendata #wikipedia
Смотрю презентации выступлений участников 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…
Неплохая подборка примеров проектов в том что называют Rewrite Bigdata in Rust (RBiR) [1], а то есть по переписыванию функциональности и отдельных продуктов с открытым кодом на Rust, вместо Python или Java.
Подборка хорошая и примеры там все как один вполне применимые к инфраструктуре практически любого дата-продукта.
А самое главное что у Rust и Python хорошая интеграция, можно заменять какие-то компоненты без болезненной адаптации проекта в целом.
Ссылки:
[1] https://xuanwo.io/2024/07-rewrite-bigdata-in-rust/
#opensource #rust #bigdata #datatools #data
Подборка хорошая и примеры там все как один вполне применимые к инфраструктуре практически любого дата-продукта.
А самое главное что у Rust и Python хорошая интеграция, можно заменять какие-то компоненты без болезненной адаптации проекта в целом.
Ссылки:
[1] https://xuanwo.io/2024/07-rewrite-bigdata-in-rust/
#opensource #rust #bigdata #datatools #data
xuanwo.io
Rewrite Bigdata in Rust
An infrastructure engineer, focused on distributed storage system
В блоге Clickhouse о том как ускорять запросы в Pandas в 87 раз [1], что, с одной стороны неплохо, а с другой стороны лукавство. Потому что есть Polars, Daft и, конечно, DuckDB. То что chDB может ускорить приведенный пример запросов в 87 раз - вполне можно поверить, но другие то продукты и побыстрее могут.
В общем, в плане технологического евангелизма тут какой-то провал, из рассказов про chDB я вижу только один резон применять его, если вся инфраструктура построена на Clickhouse и есть люди в команде поднаторевшие в оптимизации Clickhouse.
А в данном конкретном случае всё выглядит довольно сомнительно в плане выгоды от применения продукт без рассмотрения альтернатив.
Ссылки:
[1] https://clickhouse.com/blog/chdb-pandas-dataframes-87x-faster
#opensource #clickhouse #datatools
В общем, в плане технологического евангелизма тут какой-то провал, из рассказов про chDB я вижу только один резон применять его, если вся инфраструктура построена на Clickhouse и есть люди в команде поднаторевшие в оптимизации Clickhouse.
А в данном конкретном случае всё выглядит довольно сомнительно в плане выгоды от применения продукт без рассмотрения альтернатив.
Ссылки:
[1] https://clickhouse.com/blog/chdb-pandas-dataframes-87x-faster
#opensource #clickhouse #datatools
ClickHouse
How we made querying Pandas DataFrames with chDB 87x faster
We just released chDB version 2.0, which lets you query Pandas DataFrames 87x faster than 1.0. In this blog post we'll explain how we did it.
Симпатичный продукт для тетрадок работы с данными Briefer [1], обещают поддержку Python и SQL, генерацию Data apps, ИИ помощника и построение дашбордов.
Поддерживаются Y Combinator и даже с открытым кодом и ещё интереснее их рассказ о том почему они с открытым кодом и каково это открывать код когда тебя финансируют венчурный фонд [3]. Ожидаемо там про выбор AGPL лицензии.
Ссылки:
[1] https://briefer.cloud/
[2] https://github.com/briefercloud
[3] https://briefer.cloud/blog/posts/launching-briefer-oss/
#opensource #datatools #data
Поддерживаются Y Combinator и даже с открытым кодом и ещё интереснее их рассказ о том почему они с открытым кодом и каково это открывать код когда тебя финансируют венчурный фонд [3]. Ожидаемо там про выбор AGPL лицензии.
Ссылки:
[1] https://briefer.cloud/
[2] https://github.com/briefercloud
[3] https://briefer.cloud/blog/posts/launching-briefer-oss/
#opensource #datatools #data
А помните я писал о том что хорошо бы многим продуктам иметь SQL интерфейс для продвинутых пользователей? Вместо API, в дополнение API Так вот всё больше такого появляется. К примеру? Hugging Face совсем недавно добавили SQL консоль.
Внутри там всё на базе DuckDB WASM и выглядит как весьма полезная фича.
К каким сервисам ещё бы очень хотелось иметь SQL консоли?
1. Всё что касается веб аналитики. Чтобы не тягать всё время из API и чтобы не испытывать мучения с их веб интерфейсами.
2. К почте, вот просто к корпоративной почте.
3. К любым другим массовым онлайн сервисам (?)
#sql #datatools #data
Внутри там всё на базе DuckDB WASM и выглядит как весьма полезная фича.
К каким сервисам ещё бы очень хотелось иметь SQL консоли?
1. Всё что касается веб аналитики. Чтобы не тягать всё время из API и чтобы не испытывать мучения с их веб интерфейсами.
2. К почте, вот просто к корпоративной почте.
3. К любым другим массовым онлайн сервисам (?)
#sql #datatools #data
Я как раз собирался составить очередную подборку интересного чтения про данные и понял что один из текстов стоит упомянуть отдельно и поговорить про него. Это заметка Is Excel immortal? [1] от Benn Stancil. Бэн регулярно пишет интересно про данные, венчурный рынок, стартапы, аналитику и про Excel он пишет очень правильные слова.
Основная мысль которую он доносит в том что Excel вечен и раскрывает её с тем что заменить его сложно и для этого требуется сильное долгосрочное видение и команда которая готова играть в очень длинную дистанцию. Он говорит об этом другими словами, но я лично перевожу их именно так.
Причём тут важна сильная сторона Excel, это сочетание гибкой манипуляции табличными данными, внутреннего языка и формул и (самое главное!) гибкой визуализации.
Даже в самых продвинутых сервисах с визуальной аналитикой, например, продаж и посещаемости, менеджеры скачивают Excel файлы и работают с данными внутри них.
Бэн упоминает замену в виде Tableau, но Tableau не поставляется по умолчанию на почти все десктопы и у него отсутствует (?) сильный инструмент по операциями с данными. Странно что при этом он не упоминает PowerBI от MS.
Но в, самом деле, какой может быть замена Excel к 2075 году?
Лично я много что перепробовал в своей жизни:
- Airtable для ведения таблиц онлайн. Скорее онлайн замена MS Access, непомерно дорогая при коммерческом использовании, удобная при личном, но
- OpenRefine для того что называют data wrangling. Он заменяет Excel в задачах визуальной чистки данных.
- PowerBI для визуализации данных, но, признаюсь, в простых задачах Excel удобнее
Что печально, продуктов с открытым кодом для таких задач маловато. Но и коммерческие продукты пока не тянут что-то кроме ограниченных задач.
Обратите внимание, что обычно Excel'ю противопоставляют LibreOffice/OpenOffice, но я лично считаю что времена такого сравнения давно прошли. LibreOffice/OpenOffice обладает очень ограниченными функциями визуализации и манипуляции с данными.
Каким может быть Excel будущего?
1) Разделение данных и представления. Таблицы с данными в embedded базе, а ля DuckDB или SQlite, а разметка в гипертексте, может быть на основе одного из существующих стандартов.
2) Разделение визуализации и представления. Звучит странно, но это как с данными. Визуализация строится на основе одного из будущих стандартов описания дашбордов, а разметка это как накладываемые на неё стили.
3) Облачная синхронизация, но local-first.
4) Отсутствие ограничений на объёмы хранимых данных
5) Типизация вкладок. Сейчас когда в Excel готовят данные некоторые вкладки - это таблицы, а другие это тексты с пояснениями к ним и третьи - это формы. Нужны вкладки которые останутся дата таблицами, вкладки заметок, вкладки форм и вкладки аля markdown notebooks
Что можно добавить?
Ссылки:
[1] https://benn.substack.com/p/is-excel-immortal
#thoughts #excel #data #datatools
Основная мысль которую он доносит в том что Excel вечен и раскрывает её с тем что заменить его сложно и для этого требуется сильное долгосрочное видение и команда которая готова играть в очень длинную дистанцию. Он говорит об этом другими словами, но я лично перевожу их именно так.
Причём тут важна сильная сторона Excel, это сочетание гибкой манипуляции табличными данными, внутреннего языка и формул и (самое главное!) гибкой визуализации.
Даже в самых продвинутых сервисах с визуальной аналитикой, например, продаж и посещаемости, менеджеры скачивают Excel файлы и работают с данными внутри них.
Бэн упоминает замену в виде Tableau, но Tableau не поставляется по умолчанию на почти все десктопы и у него отсутствует (?) сильный инструмент по операциями с данными. Странно что при этом он не упоминает PowerBI от MS.
Но в, самом деле, какой может быть замена Excel к 2075 году?
Лично я много что перепробовал в своей жизни:
- Airtable для ведения таблиц онлайн. Скорее онлайн замена MS Access, непомерно дорогая при коммерческом использовании, удобная при личном, но
- OpenRefine для того что называют data wrangling. Он заменяет Excel в задачах визуальной чистки данных.
- PowerBI для визуализации данных, но, признаюсь, в простых задачах Excel удобнее
Что печально, продуктов с открытым кодом для таких задач маловато. Но и коммерческие продукты пока не тянут что-то кроме ограниченных задач.
Обратите внимание, что обычно Excel'ю противопоставляют LibreOffice/OpenOffice, но я лично считаю что времена такого сравнения давно прошли. LibreOffice/OpenOffice обладает очень ограниченными функциями визуализации и манипуляции с данными.
Каким может быть Excel будущего?
1) Разделение данных и представления. Таблицы с данными в embedded базе, а ля DuckDB или SQlite, а разметка в гипертексте, может быть на основе одного из существующих стандартов.
2) Разделение визуализации и представления. Звучит странно, но это как с данными. Визуализация строится на основе одного из будущих стандартов описания дашбордов, а разметка это как накладываемые на неё стили.
3) Облачная синхронизация, но local-first.
4) Отсутствие ограничений на объёмы хранимых данных
5) Типизация вкладок. Сейчас когда в Excel готовят данные некоторые вкладки - это таблицы, а другие это тексты с пояснениями к ним и третьи - это формы. Нужны вкладки которые останутся дата таблицами, вкладки заметок, вкладки форм и вкладки аля markdown notebooks
Что можно добавить?
Ссылки:
[1] https://benn.substack.com/p/is-excel-immortal
#thoughts #excel #data #datatools
benn.substack
Is Excel immortal?
It might not just be immortal; it might be the most immortal thing of all.
SQL Has Problems. We Can Fix Them: Pipe Syntax In SQL [1] научная статья от исследователей Google про GoogleSQL. Особенность в том что это не альтернативный новый язык, а именно специальный диалект для удобного написания конвейеров и так называемого pipe syntax для SQL.
GoogleSQL уже реализован во многих их продуктах вроде BigQuery, F1 и ZetaSQL [2]
Ссылки:
[1] https://research.google/pubs/sql-has-problems-we-can-fix-them-pipe-syntax-in-sql/
[2] https://github.com/google/zetasql
#google #sql #datatools #data
GoogleSQL уже реализован во многих их продуктах вроде BigQuery, F1 и ZetaSQL [2]
Ссылки:
[1] https://research.google/pubs/sql-has-problems-we-can-fix-them-pipe-syntax-in-sql/
[2] https://github.com/google/zetasql
#google #sql #datatools #data
Со стороны и не скажешь, но всю жизнь я лично был большим фанатом командной строки. Потому что печатать быстрее и удобнее чем кликать в интерфейсе, а визуальное растровое отображение элементов интерфейса нужно, на самом деле, очень редко.
Тем больше меня радует начавшийся ренессанс TUI (Text User Interface) приложений, в виде командной строки или в виде интерактивных, но текстовых, инструментов которые можно запускать локально или на терминале.
Поэтому подборка полезного open source с командной строкой и TUI:
- stu [1] текстовый навигатор (TUI) для корзин s3. Удобно для тех кто любит командную строку и работу с серверами через терминал. Работает на базе движка ratatui [2] для Rust, помогающего быстро создавать текстовые приложения.
- csvlens [3] ещё одна утилита с текстовым интерфейсом для манипуляции с CSV файлами. Тоже на базе ratatui. Кстати, стоит посмотреть галерею других TUI приложения, там много полезного [4]
- goaccess [5] текстовый интерфейс для анализатора логов веб сервера в реальном времени.
- visidata [6] текстовый интерфейс для просмотра табличных данных в разных форматах
- htop [7] альтернатива top, монитору процессов для Unix.
Ссылки:
[1] https://github.com/lusingander/stu
[2] https://github.com/ratatui/ratatui
[3] https://github.com/YS-L/csvlens
[4] https://ratatui.rs/showcase/apps/
[5] https://github.com/allinurl/goaccess
[6] https://github.com/saulpw/visidata
[7] https://github.com/htop-dev/htop/
#cli #commandline #opensource #tools #datatools
Тем больше меня радует начавшийся ренессанс TUI (Text User Interface) приложений, в виде командной строки или в виде интерактивных, но текстовых, инструментов которые можно запускать локально или на терминале.
Поэтому подборка полезного open source с командной строкой и TUI:
- stu [1] текстовый навигатор (TUI) для корзин s3. Удобно для тех кто любит командную строку и работу с серверами через терминал. Работает на базе движка ratatui [2] для Rust, помогающего быстро создавать текстовые приложения.
- csvlens [3] ещё одна утилита с текстовым интерфейсом для манипуляции с CSV файлами. Тоже на базе ratatui. Кстати, стоит посмотреть галерею других TUI приложения, там много полезного [4]
- goaccess [5] текстовый интерфейс для анализатора логов веб сервера в реальном времени.
- visidata [6] текстовый интерфейс для просмотра табличных данных в разных форматах
- htop [7] альтернатива top, монитору процессов для Unix.
Ссылки:
[1] https://github.com/lusingander/stu
[2] https://github.com/ratatui/ratatui
[3] https://github.com/YS-L/csvlens
[4] https://ratatui.rs/showcase/apps/
[5] https://github.com/allinurl/goaccess
[6] https://github.com/saulpw/visidata
[7] https://github.com/htop-dev/htop/
#cli #commandline #opensource #tools #datatools
GitHub
GitHub - lusingander/stu: TUI explorer application for Amazon S3 (AWS S3) 🪣
TUI explorer application for Amazon S3 (AWS S3) 🪣. Contribute to lusingander/stu development by creating an account on GitHub.
Data Pond (Пруд данных) - это как data lake, но поменьше. На последнем DuckCon интересное выступление спикера из Fivetran о том как они делали озеро данных на DuckDB [1] и в блоге проекта dlthub рассуждения его основателя про portable data lake [2], а по сути это и есть data pond о чём автор и пишет. Если не обращать внимание на желание делать его именно на dlthub, в остальном такие задачи потребности реально есть.
Бывает что быстро надо развернуть инфраструктуру для хранения и обработки условно небольших данных, до нескольких десятков гигабайт и применять его в среде разработки.
А вообще термин этот хоть и не устоявшийся, но совсем не новый. А вот хорошего простого технического воплощения мне ещё не попадалось.
Ссылки:
[1] https://www.youtube.com/watch?v=I1JPB36FBOo
[2] https://dlthub.com/blog/portable-data-lake
#datatools #data #opensource
Бывает что быстро надо развернуть инфраструктуру для хранения и обработки условно небольших данных, до нескольких десятков гигабайт и применять его в среде разработки.
А вообще термин этот хоть и не устоявшийся, но совсем не новый. А вот хорошего простого технического воплощения мне ещё не попадалось.
Ссылки:
[1] https://www.youtube.com/watch?v=I1JPB36FBOo
[2] https://dlthub.com/blog/portable-data-lake
#datatools #data #opensource
YouTube
Building Data Lake Using DuckDB (DuckCon #4, Amsterdam, 2024)
Speaker: Subash Roul (Fivetran)
Slides: https://blobs.duckdb.org/events/duckcon4/subash-roul-building-a-data-lake-solution-using-duckdb.pdf
Slides: https://blobs.duckdb.org/events/duckcon4/subash-roul-building-a-data-lake-solution-using-duckdb.pdf
Подборка полезных open source инструментов для работы с данными и не только:
- JameSQL [1] внедряемая NoSQL СУБД похожая на MongoDB. Несколько лет назад я бы сказал, "о как хорошо", а сейчас слишком много альтернатив в виде NewSQL продуктов, вроде DuckDB и аналогов. NoSQL базы уже не единственные инструменты работы с JSON'ами
- pyloid [2] библиотека для написания бэкэндов для настольных браузерных приложений/продуктов типа Electron. Для тех кто хочет писать настольные приложения на связке JS + Python
- tabled [3] библиотека и командная строка для извлечения таблиц из PDF. Лично я ещё не пробовал, а надо попробовать на неанглийском языке. Много есть PDF документов на разных языках на которых хотелось бы такое опробовать.
- nixiesearch [4] движок для организации поиска, работает поверх Apache Lucene. Выглядит неплохо, надо потестить на реально больших данных которые у нас есть. К вопросу о декларативном программировании, тут оно тоже есть, все настройки в YAML файле:)
- Vortex [5] колоночный формат файла и набор инструментов альтернативных Parquet и Apache Arrow. Выглядит интересно, но нужны сравнения. Кто сделает сравнение?
- Stricli [6] для тех кто любит командную строку и Javascript удобный фреймворк для первого на втором.
Ссылки:
[1] https://github.com/capjamesg/jamesql
[2] https://github.com/pyloid/pyloid
[3] https://github.com/VikParuchuri/tabled
[4] https://github.com/nixiesearch/nixiesearch
[5] https://github.com/spiraldb/vortex
[6] https://bloomberg.github.io/stricli/
#opensource #data #datatools #csv #pdf #search
- JameSQL [1] внедряемая NoSQL СУБД похожая на MongoDB. Несколько лет назад я бы сказал, "о как хорошо", а сейчас слишком много альтернатив в виде NewSQL продуктов, вроде DuckDB и аналогов. NoSQL базы уже не единственные инструменты работы с JSON'ами
- pyloid [2] библиотека для написания бэкэндов для настольных браузерных приложений/продуктов типа Electron. Для тех кто хочет писать настольные приложения на связке JS + Python
- tabled [3] библиотека и командная строка для извлечения таблиц из PDF. Лично я ещё не пробовал, а надо попробовать на неанглийском языке. Много есть PDF документов на разных языках на которых хотелось бы такое опробовать.
- nixiesearch [4] движок для организации поиска, работает поверх Apache Lucene. Выглядит неплохо, надо потестить на реально больших данных которые у нас есть. К вопросу о декларативном программировании, тут оно тоже есть, все настройки в YAML файле:)
- Vortex [5] колоночный формат файла и набор инструментов альтернативных Parquet и Apache Arrow. Выглядит интересно, но нужны сравнения. Кто сделает сравнение?
- Stricli [6] для тех кто любит командную строку и Javascript удобный фреймворк для первого на втором.
Ссылки:
[1] https://github.com/capjamesg/jamesql
[2] https://github.com/pyloid/pyloid
[3] https://github.com/VikParuchuri/tabled
[4] https://github.com/nixiesearch/nixiesearch
[5] https://github.com/spiraldb/vortex
[6] https://bloomberg.github.io/stricli/
#opensource #data #datatools #csv #pdf #search
GitHub
GitHub - capjamesg/jamesql: An in-memory NoSQL database implemented in Python.
An in-memory NoSQL database implemented in Python. - capjamesg/jamesql
Пока я рассуждал о том что новые инструменты 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