Полезные ссылки про данные, технологи и не только:
- dash расширение для DuckDB для быстрого построения дашбордов. Напоминает некоторые open source BI инструменты, но тут во всём Parquet формат и DuckDB как инструмент запросов
- gizmosql построение SQL сервера на базе DuckDB и Apache Arrow Flight Server в тесной связке и с бенчмарками на типовых облачных серверах. Обещают легкое развертывание и работу с большими объёмами данных, но, ИМХО, конкретных примеров использования нехватает
- httpie хорошо известный в узких кругах разработчиков инструмент с открытым кодом для тестирования HTTP запросов и API в частности. Интересная альтернатива Postman, APIDog и им подобным. В 2021 году подняли $6.5 миллиона венчурного финансирования на облачный коммерческий продукт и вот уже более 7 месяцев не обновляют код, не публикуют ничего в блоге, твиттере и тд. Есть ощущение что то там случилось, как бы продукт не погиб
- fastmcp быстрое создание MCP интерфейса поверх приложения FastAPI. Выглядит привлекательно простотой разработки, но надо тестировать на практике конечно же.
- nextcloud облачный сервис и open source продукт управления файлами, календарем и документами созданный в Германии. Очень характерно наблюдать как просто из продукта на рынке они превращаются в инструмент цифрового суверенитета Евросоюза. Риторика, стиль публикаций и акценты до боли напоминают некоторые российские компании играющие в импортозамещение.
- dash расширение для DuckDB для быстрого построения дашбордов. Напоминает некоторые open source BI инструменты, но тут во всём Parquet формат и DuckDB как инструмент запросов
- gizmosql построение SQL сервера на базе DuckDB и Apache Arrow Flight Server в тесной связке и с бенчмарками на типовых облачных серверах. Обещают легкое развертывание и работу с большими объёмами данных, но, ИМХО, конкретных примеров использования нехватает
- httpie хорошо известный в узких кругах разработчиков инструмент с открытым кодом для тестирования HTTP запросов и API в частности. Интересная альтернатива Postman, APIDog и им подобным. В 2021 году подняли $6.5 миллиона венчурного финансирования на облачный коммерческий продукт и вот уже более 7 месяцев не обновляют код, не публикуют ничего в блоге, твиттере и тд. Есть ощущение что то там случилось, как бы продукт не погиб
- fastmcp быстрое создание MCP интерфейса поверх приложения FastAPI. Выглядит привлекательно простотой разработки, но надо тестировать на практике конечно же.
- nextcloud облачный сервис и open source продукт управления файлами, календарем и документами созданный в Германии. Очень характерно наблюдать как просто из продукта на рынке они превращаются в инструмент цифрового суверенитета Евросоюза. Риторика, стиль публикаций и акценты до боли напоминают некоторые российские компании играющие в импортозамещение.
www.dash.builders
Dash - Data Exploration Tool
Open-source data visualization tool with DuckDB.
sqlite-vector: простой и удобный векторный поиск в SQLite
SQLite тоже умеет в векторный поиск — для этого уже есть несколько расширений. Но их главная проблема в том, что в основном они либо медленные, либо неудобные.
А ведь, наверное, главное, чего хотят от SQLite — чтобы он был легким, простым и быстрым. И, конечно, нашлись люди, которые попробовали разработать свое решение, отвечающее этим требованиям.
🔜 sqlite-vector — бесплатное кросс-платформенное расширение, которое обходится 30 МБ памяти, складывает векторы в обычные таблицы (без возни с виртуальными и сложными SQL-запросами), хранит данные локально и работает оффлайн. Ему не нужен дополнительный сервер и долгая нудная подготовка, настройка и преиндексиование.
Разработчики сравнили свое решение с популярными аналогами (точнее только с одним по факту) — если очень захотеть, то sqlite-vector может быть аж в 17 раз быстрее sqlite-vec. Да, названия у них не очень креативные и перепутать легко. С libsql сравнить не удалось, потому что он так долго возился с созданием индекса, что всем надоело ждать.
Расширение распространяется по Elastic License 2.0. Скачать можно с гитхаба.
SQLite тоже умеет в векторный поиск — для этого уже есть несколько расширений. Но их главная проблема в том, что в основном они либо медленные, либо неудобные.
А ведь, наверное, главное, чего хотят от SQLite — чтобы он был легким, простым и быстрым. И, конечно, нашлись люди, которые попробовали разработать свое решение, отвечающее этим требованиям.
Разработчики сравнили свое решение с популярными аналогами (точнее только с одним по факту) — если очень захотеть, то sqlite-vector может быть аж в 17 раз быстрее sqlite-vec. Да, названия у них не очень креативные и перепутать легко. С libsql сравнить не удалось, потому что он так долго возился с созданием индекса, что всем надоело ждать.
Расширение распространяется по Elastic License 2.0. Скачать можно с гитхаба.
Please open Telegram to view this post
VIEW IN TELEGRAM
www.sqlite.ai
SQLite-Vector - Fast vector search for embedded SQLite
SQLite-Vector adds cross-platform vector search to SQLite, with ordinary tables, quantization, SIMD acceleration, low memory usage, and semantic retrieval for synced agent memory.
Forwarded from rapeed
Выход rapeed 1.0 - рабочие области + ролевая модель, интеграция с Active Directory, панели виджетов, условия на значения полей и многое другое
После выхода версии 0.3, ядро которой обрабатывало миллиарды записей за субсекундное время,
и версии 0.8 с динамическими справочниками, которая упрощает работу с данными сложной структуры -
версия rapeed 1.0, выходящая сегодня, закрывает потребности Enterprise-клиентов в создании индивидуального контекста работы для каждого пользователя и коллективной работы групп пользователей в рамках корпоративной среды данных.
В составе rapeed 1.0 вышла следующая функциональность:
⁃ Интеграция с Active Directory (AD) с помощью KeyCloak. За аутентификацию пользователя, как и положено в корпоративной среде, отвечает AD, за авторизацию работы в rapeed - KeyCloak, за права пользователя в rapeed - сочетание ролевых моделей AD и rapeed;
⁃ Рабочие области. Рабочая область задаёт контекст работы пользователя с данными, или, проще говоря, какие источники данных, поля, показатели, связи и другие объекты пользователь видит и может ими пользоваться. Рабочие области можно публиковать и копировать полностью или частично, они бывают личными или общими. Например, из рабочей области по умолчанию (Default) можно создать несколько общих рабочих областей для каждого отдела со своими источниками и справочниками, администраторы отделов могут внутри этих рабочих областей раздать права каждому пользователю, включая права на значения полей (RLS или, точнее, VLS, см. следующий пункт), а пользователи себе для комфортной работы (например, в сводных таблицах Excel) могут оставить только нужные поля в личной рабочей области;
⁃ Система управления ролевой моделью и правами доступа. Доступно назначение ролей и прав вплоть до конкретных значений полей. Обычно это называется Row-Level Security (доступ на уровне строк), RLS, но более корректно говорить о Value-Level Security (доступ на уровне значений), VLS;
⁃ Панели виджетов. Это логическое объединение виджетов в группу с единым пространством фильтров, в том числе автоматических (возникающих из отметок пользователя в виджетах) и пользовательских (в том числе по полям и связям, отсутствующим в виджетах). В рабочей области может быть неограниченное количество панелей виджетов;
⁃ Условия на значения полей. Помимо значений на ячейки таблицы, задаваемых с помощью вложенных операторов IF/THEN/ELSE, в rapeed 1.0 появились условия на значения полей в источнике. Например, можно считать сумму, но только в январе-феврале 2024 года и только по конкретным категориям. При этом выводить этот показатель система будет как любой другой в динамически задаваемом контексте (например, определяемом раскрытием уровня сводной таблицы). Условия на значения полей - это фактически использование альтернативных массивов данных для показателей в одном виджете.
Система будет доступна для установки клиентам на этой неделе.
Получайте настоящее #удовольствие_от_аналитики! Встречайте rapeed 1.0!
После выхода версии 0.3, ядро которой обрабатывало миллиарды записей за субсекундное время,
и версии 0.8 с динамическими справочниками, которая упрощает работу с данными сложной структуры -
версия rapeed 1.0, выходящая сегодня, закрывает потребности Enterprise-клиентов в создании индивидуального контекста работы для каждого пользователя и коллективной работы групп пользователей в рамках корпоративной среды данных.
В составе rapeed 1.0 вышла следующая функциональность:
⁃ Интеграция с Active Directory (AD) с помощью KeyCloak. За аутентификацию пользователя, как и положено в корпоративной среде, отвечает AD, за авторизацию работы в rapeed - KeyCloak, за права пользователя в rapeed - сочетание ролевых моделей AD и rapeed;
⁃ Рабочие области. Рабочая область задаёт контекст работы пользователя с данными, или, проще говоря, какие источники данных, поля, показатели, связи и другие объекты пользователь видит и может ими пользоваться. Рабочие области можно публиковать и копировать полностью или частично, они бывают личными или общими. Например, из рабочей области по умолчанию (Default) можно создать несколько общих рабочих областей для каждого отдела со своими источниками и справочниками, администраторы отделов могут внутри этих рабочих областей раздать права каждому пользователю, включая права на значения полей (RLS или, точнее, VLS, см. следующий пункт), а пользователи себе для комфортной работы (например, в сводных таблицах Excel) могут оставить только нужные поля в личной рабочей области;
⁃ Система управления ролевой моделью и правами доступа. Доступно назначение ролей и прав вплоть до конкретных значений полей. Обычно это называется Row-Level Security (доступ на уровне строк), RLS, но более корректно говорить о Value-Level Security (доступ на уровне значений), VLS;
⁃ Панели виджетов. Это логическое объединение виджетов в группу с единым пространством фильтров, в том числе автоматических (возникающих из отметок пользователя в виджетах) и пользовательских (в том числе по полям и связям, отсутствующим в виджетах). В рабочей области может быть неограниченное количество панелей виджетов;
⁃ Условия на значения полей. Помимо значений на ячейки таблицы, задаваемых с помощью вложенных операторов IF/THEN/ELSE, в rapeed 1.0 появились условия на значения полей в источнике. Например, можно считать сумму, но только в январе-феврале 2024 года и только по конкретным категориям. При этом выводить этот показатель система будет как любой другой в динамически задаваемом контексте (например, определяемом раскрытием уровня сводной таблицы). Условия на значения полей - это фактически использование альтернативных массивов данных для показателей в одном виджете.
Система будет доступна для установки клиентам на этой неделе.
Получайте настоящее #удовольствие_от_аналитики! Встречайте rapeed 1.0!
Почему Text 2 SQL не работает?
Ко мне иногда приходят разные знакомые и говорят, что у них есть концепция Text 2 SQL или LLM-генератора SQL-кода — мол, классная идея для бизнеса, можно ее попродавать.
И вот наконец я понял, почему идея «пусть бизнес пишет запросы на естественном языке» не взлетает и не взлетит.
На бумаге все красиво. Даешь ИИшке команду: «Покажи выручку за август по городам», получаешь результат.
На практике же имеем несколько иной сетап: никто из бизнес-менеджеров не хочет и не может задавать правильные вопросы к данным.
Причина кроется в подмене понятий, за которую сами бизнес-менеджеры обычно аналитика и ругают. Так вот, написание SQL — это не основная работа аналитика. На самом деле аналитик занимается мыслительным трудом: как раз пытается разобраться, какие вопросы вообще стоит задать, чтобы понять, что там у бизнеса пошло не так. SQL — лишь удобный интерфейс для формулировки гипотез. Его просто изучить, но логика за пределами SQL.
И, соответственно, вторая часть проблемы: многие бизнес-менеджеры в большинстве случаев не обучены мыслить аналитически, эту часть работы они делегировали аналитику, чтобы он за них подумал. Они сами не думают в контексте данных, структур или понимания взаимосвязей. Именно поэтому LLM-промпты в виде «SQLGPT для маркетологов» и не взлетают.
🔜 AI может перевести вопрос в SQL, но не может придумать сам вопрос, который имеет смысл для бизнеса.
Сейчас мы на этапе следующего шага — передать LLM формирование вопросов и гипотез, а затем уже написание необходимого кода и SQL-запросов для решения аналитической задачи.
А пока просто осознаем, что произошла гиперинфляция хардскиллов. А вот мыслить и генерировать ценные инсайты — тот самый навык, который был и есть востребован в аналитиках.
Ко мне иногда приходят разные знакомые и говорят, что у них есть концепция Text 2 SQL или LLM-генератора SQL-кода — мол, классная идея для бизнеса, можно ее попродавать.
И вот наконец я понял, почему идея «пусть бизнес пишет запросы на естественном языке» не взлетает и не взлетит.
На бумаге все красиво. Даешь ИИшке команду: «Покажи выручку за август по городам», получаешь результат.
На практике же имеем несколько иной сетап: никто из бизнес-менеджеров не хочет и не может задавать правильные вопросы к данным.
Причина кроется в подмене понятий, за которую сами бизнес-менеджеры обычно аналитика и ругают. Так вот, написание SQL — это не основная работа аналитика. На самом деле аналитик занимается мыслительным трудом: как раз пытается разобраться, какие вопросы вообще стоит задать, чтобы понять, что там у бизнеса пошло не так. SQL — лишь удобный интерфейс для формулировки гипотез. Его просто изучить, но логика за пределами SQL.
И, соответственно, вторая часть проблемы: многие бизнес-менеджеры в большинстве случаев не обучены мыслить аналитически, эту часть работы они делегировали аналитику, чтобы он за них подумал. Они сами не думают в контексте данных, структур или понимания взаимосвязей. Именно поэтому LLM-промпты в виде «SQLGPT для маркетологов» и не взлетают.
Сейчас мы на этапе следующего шага — передать LLM формирование вопросов и гипотез, а затем уже написание необходимого кода и SQL-запросов для решения аналитической задачи.
А пока просто осознаем, что произошла гиперинфляция хардскиллов. А вот мыслить и генерировать ценные инсайты — тот самый навык, который был и есть востребован в аналитиках.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥3
DuckDB поддерживает стриминг?!
В статье они выделяют 3 архитектурных паттерна стриминга (потоковой аналитики)
🧱 Паттерн материализованного представления (Materialized View Pattern)
Часто реализуется с помощью облачных хранилищ данных, поддерживающих материализованные представления (например, BigQuery или Snowflake).
Поток событий записывается в «сырую» таблицу, а поверх неё создаётся материализованное представление.
Этот подход обычно имеет более высокую задержку обновления по сравнению со следующими двумя, хотя точных сравнений пока немного.
⚙️ Паттерн потокового движка (Streaming Engine Pattern)
Здесь используется классический ETL-подход.
Отдельный процесс (потоковый движок) читает сообщения из источника, выполняет запросы «на лету» и сохраняет результаты в постоянной таблице.
Типичные движки — Spark Streaming, Flink, Kafka Streams и более новый Arroyo.
Такой подход часто сопровождается сложностями: управление «водяными знаками» (watermarks), состоянием, потреблением памяти при бесконечных запросах и т.п.
🗄 Паттерн потоковой базы данных (Streaming Database Pattern)
Похож на предыдущий по задержке, но значительно проще в использовании.
Потоковые базы данных вроде RisingWave или Materialize могут напрямую читать поток данных и обновлять материализованное представление «на лету».
Они стремятся сохранять ACID-консистентность и позволяют клиентам выполнять запросы через PostgreSQL-совместимый протокол.
Согласно статье, DuckDB поддерживает 1й и 2й вариант. Так же можно напрямую писать запросы к Кафке через Tributary Extension.
В статье они выделяют 3 архитектурных паттерна стриминга (потоковой аналитики)
🧱 Паттерн материализованного представления (Materialized View Pattern)
Часто реализуется с помощью облачных хранилищ данных, поддерживающих материализованные представления (например, BigQuery или Snowflake).
Поток событий записывается в «сырую» таблицу, а поверх неё создаётся материализованное представление.
Этот подход обычно имеет более высокую задержку обновления по сравнению со следующими двумя, хотя точных сравнений пока немного.
⚙️ Паттерн потокового движка (Streaming Engine Pattern)
Здесь используется классический ETL-подход.
Отдельный процесс (потоковый движок) читает сообщения из источника, выполняет запросы «на лету» и сохраняет результаты в постоянной таблице.
Типичные движки — Spark Streaming, Flink, Kafka Streams и более новый Arroyo.
Такой подход часто сопровождается сложностями: управление «водяными знаками» (watermarks), состоянием, потреблением памяти при бесконечных запросах и т.п.
🗄 Паттерн потоковой базы данных (Streaming Database Pattern)
Похож на предыдущий по задержке, но значительно проще в использовании.
Потоковые базы данных вроде RisingWave или Materialize могут напрямую читать поток данных и обновлять материализованное представление «на лету».
Они стремятся сохранять ACID-консистентность и позволяют клиентам выполнять запросы через PostgreSQL-совместимый протокол.
Согласно статье, DuckDB поддерживает 1й и 2й вариант. Так же можно напрямую писать запросы к Кафке через Tributary Extension.
DuckDB
Streaming Patterns with DuckDB
DuckDB used for streaming analytics? This post will show you some patterns in which you can use DuckDB to refresh your data at near real-time speed.
👍2
В статье Exploring the Evolving File Format Landscape in AI Era: Parquet, Lance, Nimble and Vortex And What It Means for Apache Iceberg рассказывают про файловые форматы.
Мы привыкли к классическим форматам - Parquet, Avro, ORC, которые долгое время были стандартом для аналитики (batch-запросов, DWH, Data Lake, Lake House).
Они оптимизированы под:
- последовательное чтение больших объёмов данных
- компрессию и экономию места
- традиционную оффлайн-аналитику
Но они плохо подходят под:
- AI/ML, где нужно быстро извлекать отдельные строки или фичи
- векторные данные (embeddings)
- real-time-обновления и работу на GPU
А вот и сами новые форматы:
💻 Lance: быстрый доступ к данным для векторных и мультимодальных задач — embeddings, LLM-RAG, vector search.
Особенности:
- Нет row-groups, доступ к строкам O(1);
- Adaptive encoding для разных типов данных;
- Встроенные векторные индексы (HNSW, IVF_PQ);
- Поддержка версионирования (git-like snapshots).
Преимущество: до 2000× быстрее Parquet при случайных чтениях.
Минус: пока не поддерживается BI-инструментами.
https://lancedb.github.io/lance/
💻 Nimble: ускорение декодирования данных при обучении ML-моделей.
Проблема Parquet: сложные кодировки (dictionary/run-length) и компрессия замедляют загрузку данных в GPU-потоки.
Решение Nimble:
- Простая и предсказуемая структура памяти;
- Минимум переменной длины кодировок;
- Оптимизация под батчи и потоки данных для PyTorch/TensorFlow.
Эффект: ускорение чтения/декодирования в 2–3 раза по сравнению с Parquet.
Минус: увеличивается размер файлов, зато быстрее обучение.
https://github.com/facebookincubator/nimble
💻 Vortex: real-time-доступ и обновления без тяжёлых абстракций.
Проблема: Parquet и ORC не поддерживают частые апдейты/удаления — данные нужно “патчить” через Iceberg/Delta.
Решение:
- Индекс-ориентированные файлы с лёгкой метаданной структурой;
- Быстрый доступ к отдельным строкам или диапазонам;
- Гибкие схемы и низкая задержка при изменениях.
Применение:
- real-time аналитика;
- Event-driven системы;
- Динамичные агентные ИИ-приложения.
https://vortex.dev
Форматы пока не очень популярны, но они показывают высокую эффективность. Осталось подождать и посмотреть, кто возьмет лидерство и как пройдет адоптация в индустрии. А то Parquet уже совсем борода.
Некоторые статьи по теме
Nimble and Lance: The Parquet Killers
Hacker News Thread - Nimble: A new columnar file format by Meta
Reddit Thread - Vortex: A new file format that extends parquet and is apparently 10x faster
Lance: The Columnar Data Format Transforming Machine Learning Workflows
Мы привыкли к классическим форматам - Parquet, Avro, ORC, которые долгое время были стандартом для аналитики (batch-запросов, DWH, Data Lake, Lake House).
Они оптимизированы под:
- последовательное чтение больших объёмов данных
- компрессию и экономию места
- традиционную оффлайн-аналитику
Но они плохо подходят под:
- AI/ML, где нужно быстро извлекать отдельные строки или фичи
- векторные данные (embeddings)
- real-time-обновления и работу на GPU
А вот и сами новые форматы:
Особенности:
- Нет row-groups, доступ к строкам O(1);
- Adaptive encoding для разных типов данных;
- Встроенные векторные индексы (HNSW, IVF_PQ);
- Поддержка версионирования (git-like snapshots).
Преимущество: до 2000× быстрее Parquet при случайных чтениях.
Минус: пока не поддерживается BI-инструментами.
https://lancedb.github.io/lance/
Проблема Parquet: сложные кодировки (dictionary/run-length) и компрессия замедляют загрузку данных в GPU-потоки.
Решение Nimble:
- Простая и предсказуемая структура памяти;
- Минимум переменной длины кодировок;
- Оптимизация под батчи и потоки данных для PyTorch/TensorFlow.
Эффект: ускорение чтения/декодирования в 2–3 раза по сравнению с Parquet.
Минус: увеличивается размер файлов, зато быстрее обучение.
https://github.com/facebookincubator/nimble
Проблема: Parquet и ORC не поддерживают частые апдейты/удаления — данные нужно “патчить” через Iceberg/Delta.
Решение:
- Индекс-ориентированные файлы с лёгкой метаданной структурой;
- Быстрый доступ к отдельным строкам или диапазонам;
- Гибкие схемы и низкая задержка при изменениях.
Применение:
- real-time аналитика;
- Event-driven системы;
- Динамичные агентные ИИ-приложения.
https://vortex.dev
Форматы пока не очень популярны, но они показывают высокую эффективность. Осталось подождать и посмотреть, кто возьмет лидерство и как пройдет адоптация в индустрии. А то Parquet уже совсем борода.
Некоторые статьи по теме
Nimble and Lance: The Parquet Killers
Hacker News Thread - Nimble: A new columnar file format by Meta
Reddit Thread - Vortex: A new file format that extends parquet and is apparently 10x faster
Lance: The Columnar Data Format Transforming Machine Learning Workflows
Please open Telegram to view this post
VIEW IN TELEGRAM
GitHub
GitHub - facebookincubator/nimble: New and extensible file format for storage of large columnar datasets.
New and extensible file format for storage of large columnar datasets. - facebookincubator/nimble
Forwarded from SmartData — конференция по инженерии данных
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥1
Как выглядит кошмар аналитика
В честь Хеллоуина решили обсудить с вами кое-что действительно жуткое — страшнее приведений или клоунов.
Плохой SQL. 👻
Потому что приведений не существует, а вот кривой код очень даже реален и иметь с ним дело приходится регулярно. Для затравки нашли для вас целую подборку примеров, среди которых:
🔵 нагромождение
🔵 несколько уровней подзапросов, разобраться в которых не может даже сам автор,
🔵 вьюхи поверх вьюх поверх других вьюх — сначала это может быть удобно и красиво, но со временем система рискует стать слишком непонятной, еще и создает нагрузку на базу,
🔵 попытки «подчистить» результат запроса с помощью
Встречались с чем-то подобным? Или даже видели что-нибудь похуже? Делитесь в комментариях!👀
В честь Хеллоуина решили обсудить с вами кое-что действительно жуткое — страшнее приведений или клоунов.
Плохой SQL. 👻
Потому что приведений не существует, а вот кривой код очень даже реален и иметь с ним дело приходится регулярно. Для затравки нашли для вас целую подборку примеров, среди которых:
CASE WHEN, создающее хаос, в котором может разобраться только автор кода (но это не точно),DISTINCT для того, которые прячут проблему вместо того, чтобы ее решать.Встречались с чем-то подобным? Или даже видели что-нибудь похуже? Делитесь в комментариях!
Please open Telegram to view this post
VIEW IN TELEGRAM
Substack
SQL Anti-Patterns You Should Avoid
Introduction
❤1
Forwarded from Agentic Engineer
DE_Cheatsheet.pdf
106.1 KB
В качестве регулярных напоминаний, всяческий полезный [и бесполезный] код утилит для командной строки которые я когда-то делал и иногда продолжаю развивать когда это необходимо для работы,
например, для Dateno. Лично я испытываю глубокую привязанность к работе в командной строке отсюда и все эти инструменты:
- undatum - многофункциональная утилита для обработки данных изначально в формате JSON lines, делалась как xsv для JSON/JSON lines, я её лично активно и везде применяю.
- docx2csv - утилита по извлечению таблиц из файлов MS Word (.docx), настолько простая что надо её с чем-то объединить
- mongo2md - инструмент автоматизации документирования коллекций в MongoDB было полезно когда MongoDB была в основе технологического стека разных проектов, сейчас скорее буду переводить в статус легаси, но полезно как пример автодокументирования.
- metawarc утилита по извлечению метаданных из файлов WARC, умеет собирать данные из pdf, doc, docx, pdf, png, jpg, xls, xlsx и других файлов документов и изображений. Полезна для разного рода OSINT задач и для автоматизированного анализа WARC файлов
- apibackuper утилита для сбора данных из API через декларативно заданные правила. Использую её повсеместно и всё время хочу переписать чтобы вместо cfg файлов использовать yaml/toml, заменить zip контейнеры на базу duckdb и в целом сделать удобнее. Но и так работает
- wparc архиватор API и данных из Wordpress и файлов заодно. Одна из утилит для архивации сайтов для RuArxive
- lazyscraper скрейпер сайтов для лентяев, когда хочется извлечь данные минимальными усилиями и без программирования. Я её чуть-чуть не доделал чтобы даже xpath не использовать, но в остальном вполне рабочий инструмент
- metacrafter мой любимый инструмент идентификации структуры таблиц в файлах и таблицах с данными. Надо объединить с undatum её конечно же
- apicrafter утилита по быстрому созданию API поверх коллекций в MongoDB. Когда-то использовалась в проектах где основной стек был на MongoDB, сейчас всё по другому я бы делал
например, для Dateno. Лично я испытываю глубокую привязанность к работе в командной строке отсюда и все эти инструменты:
- undatum - многофункциональная утилита для обработки данных изначально в формате JSON lines, делалась как xsv для JSON/JSON lines, я её лично активно и везде применяю.
- docx2csv - утилита по извлечению таблиц из файлов MS Word (.docx), настолько простая что надо её с чем-то объединить
- mongo2md - инструмент автоматизации документирования коллекций в MongoDB было полезно когда MongoDB была в основе технологического стека разных проектов, сейчас скорее буду переводить в статус легаси, но полезно как пример автодокументирования.
- metawarc утилита по извлечению метаданных из файлов WARC, умеет собирать данные из pdf, doc, docx, pdf, png, jpg, xls, xlsx и других файлов документов и изображений. Полезна для разного рода OSINT задач и для автоматизированного анализа WARC файлов
- apibackuper утилита для сбора данных из API через декларативно заданные правила. Использую её повсеместно и всё время хочу переписать чтобы вместо cfg файлов использовать yaml/toml, заменить zip контейнеры на базу duckdb и в целом сделать удобнее. Но и так работает
- wparc архиватор API и данных из Wordpress и файлов заодно. Одна из утилит для архивации сайтов для RuArxive
- lazyscraper скрейпер сайтов для лентяев, когда хочется извлечь данные минимальными усилиями и без программирования. Я её чуть-чуть не доделал чтобы даже xpath не использовать, но в остальном вполне рабочий инструмент
- metacrafter мой любимый инструмент идентификации структуры таблиц в файлах и таблицах с данными. Надо объединить с undatum её конечно же
- apicrafter утилита по быстрому созданию API поверх коллекций в MongoDB. Когда-то использовалась в проектах где основной стек был на MongoDB, сейчас всё по другому я бы делал
GitHub
GitHub - datacoon/undatum: undatum: a command-line tool for data processing. Brings CSV simplicity to NDJSON, BSON, XML and other…
undatum: a command-line tool for data processing. Brings CSV simplicity to NDJSON, BSON, XML and other data files - datacoon/undatum