Yuriy Gavrilov: posts tagged Data Visualization

Искусство скорости: Руководство по оптимизации для аналитики в Data Lakehouse с DuckDB

Tue, 09 Sep 2025 01:48:12 +0300

DuckDB завоевал огромную популярность как “SQLite для аналитики”. Это невероятно быстрый, встраиваемый, колоночный движок, который не требует отдельного сервера. Однако его мощь по-настоящему раскрывается, когда он получает доступ к данным эффективно. Просто натравить DuckDB на петабайтный дата-лейк без подготовки — это рецепт для медленных запросов и высоких затрат.

Как же построить мост между огромным хранилищем данных и молниеносной интерактивной аналитикой, которую обещает DuckDB?

В этой статье рассмотрим три фундаментальных архитектурных подхода к организации доступа к данным для DuckDB. Но прежде чем мы погрузимся в то, как *читать* данные, давайте поговорим о том, как их *готовить*.

Большая картина: Подготовка данных с помощью Trino

Данные в вашем Lakehouse не появляются из ниоткуда. Они поступают из операционных баз данных, потоков событий (Kafka), логов и десятков других источников. Прежде чем DuckDB сможет их эффективно запросить, эти данные нужно собрать, очистить, трансформировать и, что самое важное, организовать в надежный и производительный формат.

Здесь на сцену выходит Trino (ранее известный как PrestoSQL).

Что такое Trino? Это мощный распределенный SQL-движок, созданный для выполнения запросов к гетерогенным источникам данных. Его суперсила — способность “на лету” объединять данные из PostgreSQL, Kafka, Hive, MySQL и многих других систем.

Роль Trino в Lakehouse: В современной архитектуре Trino часто выступает в роли “фабрики данных”. Он выполняет тяжелую работу по ETL/ELT (Extract, Transform, Load), подготавливая данные для аналитических инструментов вроде DuckDB.

Типичный сценарий использования:

Источники: У вас есть события о прослушивании треков в Kafka, а информация о пользователях — в базе данных PostgreSQL.
Задача: Создать единую, денормализованную таблицу Iceberg для аналитики.
Решение с Trino: Вы настраиваете в Trino коннекторы к Kafka и PostgreSQL. Затем вы запускаете периодический SQL-запрос, который читает данные из обоих источников, объединяет их и записывает результат в новую или существующую таблицу Iceberg.

-- Этот запрос выполняется в Trino, а не в DuckDB!
    INSERT INTO iceberg_catalog.analytics.daily_user_activity
    SELECT
        u.user_id,
        u.country,
        e.event_timestamp,
        e.track_id,
        e.duration_ms
    FROM
        postgres_catalog.public.users u
    JOIN
        kafka_catalog.raw_data.listen_events e ON u.user_id = e.user_id
    WHERE
        e.event_date = CURRENT_DATE;

Как отмечается в одном из руководств, именно такой `INSERT INTO ... SELECT ...` является типичным способом перемещения данных в Iceberg с помощью Trino.

Итог: Trino работает “глубоко в машинном отделении” вашего Lakehouse. Он берет на себя тяжелые, распределенные задачи по преобразованию данных, а DuckDB получает на вход уже чистые, структурированные и оптимизированные для чтения таблицы Iceberg.

Теперь, когда данные готовы, давайте рассмотрим, как их лучше всего потреблять.

Подход 1: Табличные форматы (Iceberg) — Читайте только то, что нужно

Это самый продвинутый и рекомендуемый подход для серьезной аналитики, особенно в serverless-архитектуре.

Как это работает: Вместо того чтобы работать с “россыпью” файлов Parquet, вы работаете с логической таблицей, управляемой Apache Iceberg. Расширение `iceberg` в DuckDB использует метаданные Iceberg для интеллектуального отсечения ненужных файлов (partition pruning) и блоков данных (predicate pushdown), читая с диска минимально необходимый объем информации.
Архитектура: `Данные на S3 -> Trino (ETL) -> Таблица Iceberg -> DuckDB (Аналитика)`

Назначение и сценарии использования:

Serverless-аналитика: Основной кейс. AWS Lambda или Google Cloud Function, оснащенная DuckDB, выполняет SQL-запрос к озеру данных. Благодаря Iceberg, функция читает всего несколько мегабайт вместо гигабайт, что делает ее выполнение быстрым (<1 сек) и дешевым.
Локальная разработка и BI: Аналитик данных или инженер открывает Jupyter Notebook на своем ноутбуке. С помощью DuckDB он подключается напрямую к производственному Lakehouse и выполняет исследовательский анализ, не создавая копий данных и не перегружая кластеры.
Встраиваемая аналитика: Backend-сервис на Python или Node.js, которому нужно быстро отвечать на аналитические вопросы (например, “показать статистику пользователя за последний месяц”). Он использует DuckDB для прямого запроса к Lakehouse без обращения к промежуточной базе данных.

Подход 2: RPC-стриминг (Apache Arrow Flight) — Прямой канал к данным

Иногда вам не нужна вся мощь Iceberg, а нужно просто эффективно выполнить запрос на удаленном экземпляре DuckDB и получить результат.

Как это работает: Вы запускаете сервер, который инкапсулирует DuckDB. Клиент и сервер общаются по протоколу Arrow Flight — высокопроизводительному фреймворку для стриминга колоночных данных в формате Apache Arrow без затрат на сериализацию.
Архитектура: `Клиент -> Arrow Flight RPC -> Сервер с DuckDB -> Данные (любой источник)`

Назначение и сценарии использования:

Интерактивные дашборды: Веб-интерфейс (React, Vue) должен строить графики в реальном времени. Он отправляет SQL-запросы на Flight-сервер и получает данные для отрисовки практически мгновенно, без “тяжести” HTTP/JSON.
API-шлюз для данных: Централизация доступа к данным для множества внутренних микросервисов. Вместо того чтобы каждый сервис имел свои креды и логику подключения к БД, они обращаются к единому, стабильному Flight API.
Кросс-языковое взаимодействие: Сервис на Java должен получить результаты вычислений из BI-системы, построенной на Python и DuckDB. Arrow Flight обеспечивает эффективный и стандартизированный мост между ними.

Подход 3: “API поверх данных” (ROAPI & DataFusion) — Декларативная альтернатива

Что, если вам не нужна вся гибкость SQL, а нужен стандартный REST или GraphQL API поверх ваших данных без строчки кода? Здесь на сцену выходит ROAPI.

Как это работает: ROAPI — это инструмент, который автоматически создает API, читая конфигурационный YAML-файл, где вы описываете ваши данные (Parquet, CSV и т.д.). Под капотом он использует Apache Arrow DataFusion, движок запросов, написанный на Rust, являющийся идейным братом DuckDB.
Архитектура: `Клиент (HTTP/GraphQL) -> ROAPI Server -> Данные (файлы)`

Назначение и сценарии использования:

Быстрое прототипирование: Вам нужно за 5 минут предоставить команде фронтенда API для нового набора данных. Вы пишете 10 строк в YAML, запускаете ROAPI — и API готов.
Простые микросервисы данных: Сервис, единственная задача которого — раздавать данные из файла с поддержкой фильтрации и пагинации. ROAPI делает это из коробки, избавляя вас от написания рутинного кода на FastAPI или Express.js.
Дата-фиды для внешних систем: Предоставление стандартизированного API для партнерской системы, которая умеет работать с REST, но не умеет читать Parquet.

и еще немного про DuckDB

1. Читайте меньше данных (Золотое правило)

Используйте Iceberg: Это лучший способ.
Проекция колонок (`SELECT col1, col2...`): Никогда не используйте `SELECT *`.
Проталкивание предикатов (`WHERE`): Пишите максимально конкретные фильтры. DuckDB автоматически проталкивает их в сканеры Parquet и Iceberg. Используйте `EXPLAIN` для проверки того, что фильтры применяются на этапе сканирования.

2. Оптимизация SQL-запросов

Материализация промежуточных результатов: Если вы делаете несколько агрегаций над одним и тем же отфильтрованным срезом, сохраните его во временную таблицу с помощью `CREATE TEMP TABLE ... AS`.
Используйте `COPY` для массовой загрузки: При загрузке данных в DuckDB `COPY` на порядки быстрее, чем `INSERT`.
Предварительная агрегация: Для сверхбольших данных создавайте “витрины” с помощью Trino (см. выше) или DuckDB, а запросы стройте уже по ним.

3. Настройка окружения DuckDB

Управление памятью: `SET memory_limit = ‘1GB’;` — обязательная настройка в Lambda и контейнерах.
Параллелизм: `SET threads = 4;` — адаптируйте количество потоков под vCPU вашего окружения.
Настройка `httpfs` для S3: Настройте регион (`s3_region`), креды и включите кэширование метаданных, чтобы не перечитывать их при каждом запуске. ( Это комьюнити дополнение -cache_httpfs, см. ниже “Проблема Шторм” )

Еще вот тут можно почитать: https://duckdb.org/docs/stable/guides/performance/how_to_tune_workloads

Заключение: Какой подход выбрать?

Выбор архитектуры зависит от вашей задачи. Каждая из них занимает свою нишу в стеке современной инженерии данных.

Подход	Ключевая технология	Когда использовать
Табличный формат	Trino (Подготовка) + DuckDB/Iceberg (Потребление)	Стандарт для Lakehouse. Нужна строгая структура, надежность и максимальная производительность для аналитических SQL-запросов от различных инструментов.
RPC-стриминг	DuckDB + Arrow Flight	Нужен быстрый интерактивный SQL-доступ к удаленному экземпляру DuckDB, например, для дашборда или кастомного клиента.
API поверх данных	ROAPI + DataFusion	Нужно быстро и без кода поднять стандартный `REST`/`GraphQL` API поверх наборов данных для прототипирования или простых микросервисов.

Проблема Шторм из GET-запросов к S3

Давайте представим, что вы выполняете запрос к таблице Iceberg или просто к набору из 1000 файлов Parquet на S3:

SELECT count(*)
FROM read_parquet('s3://my-bucket/data/*.parquet')
WHERE event_type = 'click';

Чтобы выполнить этот запрос с максимальной эффективностью (с “проталкиванием предиката”), DuckDB должен сделать следующее, *прежде чем* читать основные данные:

Получить список всех 1000 файлов.
Для каждого из 1000 файлов прочитать его метаданные (футер). Футер Parquet-файла — это небольшой блок в конце файла, содержащий схему и, что самое важное, статистику по колонкам (min/max значения).
Проанализировав футер, DuckDB понимает, может ли в этом файле вообще содержаться `event_type = ‘click’`. Если статистика говорит, что в файле есть только типы `’view’` и `’purchase’`, утка его пропустит.

Проблема в том, что для чтения футера каждого файла DuckDB должен отправить отдельный HTTP `GET` запрос с указанием диапазона байт (range request) к S3. То есть, один SQL-запрос порождает 1000+ мелких HTTP-запросов. Это может быть медленно и может быть дорого, так как в S3 вы платите за каждый `GET` запрос.

Кэширование метаданных решает именно эту проблему: оно сохраняет результаты этих мелких запросов на локальный диск, чтобы при повторном обращении к тем же файлам DuckDB брал их из локального кэша, а не летел снова в S3.

Решение: Комьюнити-расширение `cache_httpfs`

Для реализации постоянного, дискового кэширования в DuckDB используется специальное комьюнити-расширение `cache_httpfs`. Оно работает как “обертка” над стандартным `httpfs`.

Основная идея: Вы говорите DuckDB использовать `cache_httpfs` в качестве клиента для HTTP-запросов. Этот клиент сначала проверяет, нет ли уже нужного блока данных (например, футера Parquet-файла) в локальном кэше. Если есть — отдает его мгновенно. Если нет — идет в S3, скачивает блок, сохраняет его в кэш и отдает DuckDB.

Вот как это настроить:

Шаг 1: Установка и загрузка расширений

Вам понадобятся три расширения: `httpfs` (для работы с S3), `cache_httpfs` (для кэширования) и, если вы работаете с Iceberg, то и `iceberg`.

INSTALL httpfs;
INSTALL cache_httpfs;
LOAD httpfs;
LOAD cache_httpfs;

Шаг 2: Активация кэширующего клиента

Это ключевой шаг. Вы должны указать DuckDB использовать `cache_httpfs` для всех HTTP-операций.

SET httpfs_client = 'cached_httpfs';

Шаг 3: Настройка пути к кэшу (критически важно для Serverless)

По умолчанию `cache_httpfs` сохраняет кэш в директорию `~/.cache/duckdb/`. Это хорошо работает на локальной машине, но в serverless-окружениях (AWS Lambda, Cloud Functions) эта папка либо недоступна для записи, либо является эфемерной.

В serverless-среде единственное гарантированно доступное для записи место — это директория `/tmp`.

SET cache_httpfs_cache_path = '/tmp/duckdb_cache';

Этот кэш в `/tmp` будет “жить” между “теплыми” вызовами вашей Lambda-функции. Если одна и та же функция вызывается несколько раз подряд, второй и последующие вызовы будут использовать уже заполненный кэш, что кардинально ускорит выполнение запросов к одним и тем же данным.

Полный пример конфигурации (Python)

import duckdb

# Подключаемся к базе данных
con = duckdb.connect()

# Устанавливаем и загружаем расширения
con.execute("INSTALL httpfs;")
con.execute("INSTALL cache_httpfs;")
con.execute("LOAD httpfs;")
con.execute("LOAD cache_httpfs;")

# --- Настройка S3 и кэша ---

# 1. Настройте креды для S3 (если не используются IAM-роли)
# con.execute("SET s3_access_key_id='YOUR_KEY';")
# con.execute("SET s3_secret_access_key='YOUR_SECRET';")
con.execute("SET s3_region='us-east-1';")

# 2. Активируем кэширующий http-клиент
con.execute("SET httpfs_client = 'cached_httpfs';")

# 3. Указываем путь к директории кэша (обязательно для serverless)
con.execute("SET cache_httpfs_cache_path = '/tmp/duckdb_http_cache';")

# --- Выполняем запрос ---

# Первый запуск этого запроса будет медленнее,
# так как он заполнит кэш метаданными файлов.
result1 = con.execute("SELECT count(*) FROM 's3://my-bucket/data/*.parquet'").fetchone()
print(f"Первый запуск: {result1[0]}")

# Второй запуск будет на порядки быстрее,
# так как все метаданные будут прочитаны из локального кэша в /tmp.
result2 = con.execute("SELECT count(*) FROM 's3://my-bucket/data/*.parquet'").fetchone()
print(f"Второй запуск (с кэшем): {result2[0]}")

Сравнение: Встроенный кэш vs `cache_httpfs`

Стоит отметить, что стандартный `httpfs` тоже имеет небольшой *внутренний, оперативный кэш*, но его возможности ограничены.

Параметр	Встроенный кэш `httpfs`	Расширение `cache_httpfs`
Тип	Внутренний, в памяти	Явный, на диске
Жизненный цикл	Живет в рамках одного соединения (connection). При переподключении кэш пуст.	Живет между сессиями и процессами. Сохраняется на диске до очистки.
Назначение	Ускорение повторных запросов в одной и той же длительной сессии.	Радикальное ускорение для любых повторных запросов, особенно в serverless (warm starts) и при локальной разработке.
Активация	Включен по умолчанию	Требует `SET httpfs_client = ‘cached_httpfs’;`
Настройка	Не настраивается	Настраивается путь (`cache_httpfs_cache_path`) и максимальный размер.

Для серьезной работы с данными на S3, особенно в serverless-архитектуре, использование расширения `cache_httpfs` является приятным дополнением и зачастую обязательным. Это та самая “серебряная пуля”, которая убирает узкое место в виде задержек сети и большого количества API-вызовов к облачному хранилищу.

Начиная с тяжелых ETL-процессов на Trino и заканчивая быстрыми запросами в DuckDB, современный стек данных предлагает невероятную гибкость и производительность. Выбрав правильный инструмент или их комбинацию для каждой задачи, можно построить по-настоящему эффективную и масштабируемую аналитическую платформу.

pic. Krenskiy Dmitriy

Экосистема инструментов для Data Science и AI: От Дашбордов до Продвинутого MLOps

Sun, 10 Aug 2025 23:40:36 +0300

Все это можно быстро и просто запустить тут: https://www.ploomber.io

В современной науке о данных и разработке искусственного интеллекта недостаточно просто создать модель в Jupyter Notebook ( о нем вы уже знаете ) . Настоящая ценность раскрывается, когда результатами можно поделиться, когда модели становятся интерактивными и когда они надежно развернуты в производственной среде. Для решения этих задач появилось множество фреймворков, каждый со своими сильными сторонами и философией.

В этой статье мы рассмотрим и оценим ключевые инструменты, которые позволяют дата-сайентистам и ML-инженерам создавать веб-приложения, чат-ботов, API, отчеты и управлять жизненным циклом моделей.

Категория 1: Фреймворки для создания веб-приложений и дашбордов

Это самая многочисленная группа, предназначенная для быстрого превращения данных и моделей в интерактивные пользовательские интерфейсы без необходимости глубокого изучения фронтенд-технологий.

Streamlit

GitHub Stars: 40.8k+
Официальный сайт: streamlit.io
GitHub Repo: streamlit

Описание и назначение: Streamlit — это, возможно, самый популярный фреймворк для быстрого создания data-приложений. Его философия — превратить скрипты в красивые веб-интерфейсы с минимальными усилиями. Приложение работает по простой модели: скрипт выполняется сверху вниз при каждом взаимодействии пользователя, что упрощает управление состоянием.

Особенности и оценка:

Сильные стороны: Невероятная простота и скорость разработки. Идеально подходит для создания прототипов, демо и внутренних инструментов medium.com. Отличная документация и большое сообщество.
Слабые стороны: Модель “перезапуска всего скрипта” может быть неэффективной для сложных приложений с большим количеством состояний. Кастомизация интерфейса за пределами стандартных компонентов может быть сложной задачей ai.gopubby.com.

Dash

GitHub Stars: 23.9k+
Официальный сайт: plotly.com/dash
GitHub Repo: github.com/plotly/dash

Описание и назначение: Dash от создателей Plotly — это мощный фреймворк для создания аналитических веб-приложений. Он использует Flask, Plotly.js и React.js под капотом, предоставляя Python-разработчикам доступ к современным веб-технологиям.

Особенности и оценка:

Сильные стороны: Высокая степень кастомизации и контроля. Идеален для корпоративных дашбордов и сложных приложений, требующих уникального дизайна и функциональности. Отличная интеграция с экосистемой Plotly.
Слабые стороны: Более высокий порог вхождения по сравнению со Streamlit. Концепция “коллбэков” требует времени для освоения.

Solara

GitHub Stars: 2.1k+
Официальный сайт: solara.dev
GitHub Repo: github.com/widgetti/solara

Описание и назначение: Solara позволяет создавать веб-приложения на чистом Python, используя компонентный подход, похожий на React. Он построен на базе Ipywidgets и может работать как в Jupyter Notebook, так и в виде самостоятельных приложений.

Особенности и оценка:

Сильные стороны: Компонентная архитектура способствует созданию чистого и переиспользуемого кода. Хорошо подходит для создания масштабируемых приложений корпоративного уровня ai.gopubby.com.
Слабые стороны: Менее известен, чем Streamlit или Dash, что означает меньшее сообщество и меньше готовых решений.

Gradio

GitHub Stars: 39.4k+
Официальный сайт: gradio.app
GitHub Repo: github.com/gradio-app/gradio

Описание и назначение: Gradio создан для невероятно быстрого создания демо для моделей машинного обучения. Всего за несколько строк кода можно обернуть любую Python-функцию (например, предсказание модели) в простой веб-интерфейс.

Особенности и оценка:

Сильные стороны: Максимальная простота для демонстрации моделей. Поддерживает различные типы ввода/вывода (текст, изображения, аудио). Легко встраивается в Jupyter/Colab и генерирует публичные ссылки для демонстрации.
Слабые стороны: Не предназначен для создания сложных, многостраничных дашбордов. Фокус смещен на “вход -> модель -> выход”. Структура приложения `app.py` часто используется для бэкенда при создании мультимодальных инструментов ai.plainenglish.io.

Shiny for Python & Shiny Express

GitHub Stars: 1.6k+ (Python)
Официальный сайт: shiny.posit.co/py
GitHub Repo: github.com/posit-dev/py-shiny

Описание и назначение: Shiny, легендарный фреймворк из мира R, теперь доступен и для Python. Он использует реактивную модель программирования, где изменения во входных данных автоматически вызывают пересчет связанных с ними выходных данных. Shiny Express — это его более легковесная версия в стиле Streamlit, позволяющая создавать приложения декларативно.

Особенности и оценка:

Сильные стороны: Мощная реактивная модель позволяет создавать очень эффективные приложения. Отличная интеграция с инструментами от Posit (ранее RStudio).
Слабые стороны: Сообщество в Python пока меньше, чем у аналогов. Реактивная модель требует особого подхода к мышлению.

Panel

GitHub Stars: 5.4k+
Официальный сайт: panel.holoviz.org
GitHub Repo: github.com/holoviz/panel

Описание и назначение: Panel — это мощный фреймворк из экосистемы HoloViz. Его главная особенность — совместимость практически с любой библиотекой для визуализации в Python. Он позволяет объединять виджеты и графики в гибкие макеты.

Особенности и оценка:

Сильные стороны: Непревзойденная гибкость и совместимость с другими библиотеками. Отлично подходит, если вы уже используете инструменты HoloViz (hvPlot, HoloViews).
Слабые стороны: Может показаться более многословным и сложным для простых задач по сравнению со Streamlit.

Другие интересные фреймворки UI

Chainlit (10k+ звезд): Специализированный фреймворк для быстрого создания чат-интерфейсов для LLM-агентов и приложений на базе LangChain/LlamaIndex.
Hyperdiv (900+ звезд): Предлагает новый подход: Python-код выполняется на сервере и мгновенно синхронизирует UI в браузере. Компоненты объявляются в простом, декларативном стиле.
Vizro (3k+ звезд): Конфигурационный фреймворк поверх Dash. Позволяет создавать дашборды через YAML или Pydantic-модели, что упрощает разработку.
Voilà (5.8k+ звезд): Превращает Jupyter-ноутбуки в самостоятельные веб-приложения, скрывая код и оставляя только виджеты и выводы ячеек.

---

Категория 2: Бэкенд и MLOps (Развертывание и управление)

Эти инструменты фокусируются на серверной части, производительности и управлении жизненным циклом моделей.

FastAPI

GitHub Stars: 88.2k+
Официальный сайт: fastapi.tiangolo.com
GitHub Repo: github.com/tiangolo/fastapi

Описание и назначение: FastAPI — это современный, высокопроизводительный веб-фреймворк для создания API на Python. Он стал де-факто стандартом для развертывания моделей машинного обучения в виде REST API благодаря своей скорости, автоматической документации и использованию стандартных аннотаций типов Python.

Особенности и оценка:

Сильные стороны: Невероятная производительность. Автоматическая интерактивная документация (Swagger UI, ReDoc). Простота использования благодаря Pydantic и аннотациям типов.
Слабые стороны: Это бэкенд-фреймворк. Для создания UI его нужно использовать в связке с фронтенд-технологиями.

vLLM

GitHub Stars: 54.8k+
Официальный сайт: vllm.ai
GitHub Repo: github.com/vllm-project/vllm

Описание и назначение: vLLM — это не UI-фреймворк, а высокопроизводительная библиотека для инференса (выполнения) больших языковых моделей (LLM). Ее главная цель — максимально увеличить пропускную способность при обслуживании LLM.

Особенности и оценка:

Сильные стороны: Значительно ускоряет работу LLM благодаря инновационным техникам, таким как PagedAttention. Совместимость с моделями Hugging Face. Становится стандартом для быстрого self-hosting LLM.
Слабые стороны: Узкоспециализированный инструмент для инференса LLM.

MLflow

GitHub Stars: 21.5k+
Официальный сайт: mlflow.org
GitHub Repo: github.com/mlflow/mlflow

Описание и назначение: MLflow — это платформа с открытым исходным кодом для управления полным жизненным циклом машинного обучения. Он включает в себя компоненты для отслеживания экспериментов (Tracking), упаковки кода (Projects), управления моделями (Models) и их развертывания (Registry).

Особенности и оценка:

Сильные стороны: Комплексное решение для MLOps. Помогает стандартизировать и воспроизводить ML-эксперименты. Интегрируется с большинством ML-библиотек.
Слабые стороны: Требует настройки и внедрения в рабочий процесс. Может быть избыточным для небольших проектов.

---

Категория 3: Интерактивные вычисления и отчетность

Эти инструменты меняют представление о статических отчетах и ноутбуках, делая их интерактивными и воспроизводимыми.

Quarto

GitHub Stars: 4.7k+ (CLI)
Официальный сайт: quarto.org
GitHub Repo: github.com/quarto-dev/quarto-cli

Описание и назначение: Quarto — это система публикации научных и технических документов нового поколения от Posit. Она позволяет создавать динамические документы и презентации из Jupyter-ноутбуков или простого Markdown, смешанного с кодом на Python, R или Julia.

Особенности и оценка:

Сильные стороны: Поддерживает множество форматов вывода (HTML, PDF, DOCX, презентации и др.). Языковая агностичность. Позволяет создавать красивые, профессиональные и воспроизводимые отчеты.
Слабые стороны: В первую очередь это инструмент для публикации, а не для создания интерактивных real-time приложений.

Marimo

GitHub Stars: 15.3k+
Официальный сайт: marimo.io
GitHub Repo: github.com/marimo-team/marimo

Описание и назначение: Marimo — это реактивная среда для Python, которая решает многие проблемы традиционных Jupyter-ноутбуков. В Marimo ноутбук — это интерактивное веб-приложение. Изменение в одной ячейке автоматически обновляет все зависимые ячейки.

Особенности и оценка:

Сильные стороны: Реактивность обеспечивает консистентность состояния. Встроенные UI-элементы. Ноутбуки легко экспортируются в виде приложений.
Слабые стороны: Новый инструмент с растущим, но пока небольшим сообществом. Отличается от привычного рабочего процесса в Jupyter.

---

Как выбрать подходящий инструмент?

Для быстрого прототипа или демо модели: Streamlit или Gradio.
Для сложного, кастомизированного корпоративного дашборда: Dash или Solara.
Для создания бэкенда и API для вашей модели: FastAPI.
Для максимальной производительности при развертывании LLM: vLLM.
Для построения полноценного MLOps-цикла: MLflow.
Для создания чат-бота на базе LLM: Chainlit.
Для создания красивых, воспроизводимых отчетов и статей: Quarto.
Если вы хотите попробовать реактивный, state-of-the-art ноутбук: Marimo.
Если вы из мира R или вам нравится реактивная парадигма: Shiny for Python.

Самые популярные инструменты бизнес-аналитики на основе кода: Обзор

Fri, 30 May 2025 22:48:31 +0300

Сравнение самых популярных BI-as-code инструментов: Evidence, Streamlit, Dash, Observable, Shiny и Quarto
Кейси Хуанси Ли – Приглашенный Автор 30 октября 2024 г. · 4 мин чтения
Кейси – специалист по данным, инженер-программист и писатель. Ранее она работала в McKinsey & QuantumBlack, а в настоящее время работает в Shopify.

Оригинал тут: https://evidence.dev/blog/business-intelligence-tools

а можно не читать, а идти сразу сюда: https://gavrilov.info/all/tetradki-nashe-vsyo-marimo-io-i-utochkadb/

Не существует единственного «лучшего» инструмента бизнес-аналитики (BI); лучший инструмент для вас зависит от ваших конкретных потребностей, рабочего процесса и набора навыков.

Это руководство сравнивает некоторые из самых популярных инструментов BI-as-code, чтобы помочь вам найти то, что наилучшим образом подходит для вашего стека анализа данных и технических компетенций:

* Evidence: Конструктор приложений на Markdown и SQL для аналитиков данных.
* Streamlit: Оболочка для веб-приложений для Python-специалистов по данным.
* Dash: Фреймворк для веб-приложений для Python-разработчиков.
* Observable: Набор инструментов для визуализации данных для JavaScript-разработчиков.
* Shiny: Простая R/Python-оболочка для статистиков и исследователей.
* Quarto: Минималистичная система публикации Jupyter/Markdown для ученых и технических писателей.

Каждый из этих инструментов является открытым исходным кодом, и вы можете найти исходный код на GitHub.

Инструмент	Репозиторий GitHub	Лицензия	Языки	Звезды
Evidence	evidence-dev/evidence	MIT	SQL/Markdown	4.3k
Streamlit	streamlit/streamlit	Apache 2.0	Python	35k
Dash	plotly/dash	MIT	Python	21k
Observable	observablehq/framework	ISC	JavaScript	2.5k
Shiny	rstudio/shiny	GPL-3.0	R/Python	5.4k
Quarto	quarto-dev/quarto-cli	MIT	Markdown/Jupyter	3.9k

Evidence

Инструмент для создания приложений на SQL и Markdown

Evidence выделяется своим управлением входными данными через SQL-запросы и созданием содержимого страниц с помощью Markdown и предварительно созданных компонентов.

Входные данные в Evidence управляются с помощью SQL-запросов. Содержимое страницы создается с помощью Markdown и предварительно созданных компонентов Evidence для общих визуализаций, таких как таблицы или столбчатые диаграммы.

Evidence разработан для аналитиков, знакомых с SQL и Markdown, предлагая расширяемость через веб-стандарты. Приложения Evidence отлаженные, производительные и легко воспринимаются бизнес-стейкхолдерами.

Evidence также предлагает неограниченные возможности для определения ваших собственных пользовательских компонентов с использованием HTML и JavaScript, а также стилизации страниц через CSS. Он также поддерживает постоянно растущий список вариантов развертывания, включая Evidence Cloud — безопасный, управляемый хостинг-сервис.

Пример кода:

# Sales Report

<Slider min=2019 max=2024 name=year_pick title=Year size=full/>

```sql sales_by_month
SELECT
    order_month,
    category,
    sum(sales) AS sales
FROM orders
WHERE year = '${inputs.year_pick}'
GROUP BY ALL
```

<BarChart
  data={sales_by_month}
  title="Sales by Month"
  x=order_month
  y=sales
/>

Хороший выбор, если:

Вы в основном работаете с SQL и хотите получать удобные для бизнеса результаты.
Вы не являетесь в первую очередь JavaScript-разработчиком.
Вы хотите иметь возможность добавлять пользовательские компоненты, если ваши потребности выходят за рамки готовой функциональности.

Не рекомендуется, если:

Вы не хотите использовать SQL-запросы для управления входными данными.

---

Streamlit

Веб-приложение-обертка для pandas, numpy и других основных инструментов Python для анализа данных

Если вы уже знакомы с такими вещами, как numpy или pandas, документация Streamlit заставит вас почувствовать себя как дома. Оборачивая, например, `np.histogram` во что-то вроде `st.bar_chart`, Streamlit берет на себя перевод вашего Python-кода в веб-приложение.

Streamlit запускает ваш Python-скрипт сверху вниз, передавая выходные данные, такие как текст, таблицы или диаграммы, на страницу. Этот инструмент также можно использовать для создания чат-бота в стиле ChatGPT с использованием выходных данных на основе Python.

Пример кода:

import streamlit as st
import pandas as pd
import numpy as np

st.title('Uber pickups in NYC')

DATE_COLUMN = 'date/time'
DATA_URL = ('https://s3-us-west-2.amazonaws.com/'
         'streamlit-demo-data/uber-raw-data-sep14.csv.gz')

@st.cache_data
def load_data(nrows):
    data = pd.read_csv(DATA_URL, nrows=nrows)
    lowercase = lambda x: str(x).lower()
    data.rename(lowercase, axis='columns', inplace=True)
    data[DATE_COLUMN] = pd.to_datetime(data[DATE_COLUMN])
    return data

# Create a text element and let the reader know the data is loading.
data_load_state = st.text('Loading data...')
# Load 10,000 rows of data into the dataframe.
data = load_data(10000)
# Notify the reader that the data was successfully loaded.
data_load_state.text("Done! (using st.cache_data)")

st.subheader('Raw data')
st.write(data)

st.subheader('Number of pickups by hour')

hist_values = np.histogram(
    data[DATE_COLUMN].dt.hour, bins=24, range=(0,24))[0]

st.bar_chart(hist_values)

hour_to_filter = st.slider('hour', 0, 23, 17)  # min: 0h, max: 23h, default: 17h
filtered_data = data[data[DATE_COLUMN].dt.hour == hour_to_filter]
st.subheader(f'Map of all pickups at {hour_to_filter}:00')
st.map(filtered_data)

Хороший выбор, если:

Вы являетесь Python-специалистом по данным, который хочет быстро создать веб-приложение, которым можно поделиться.

Не рекомендуется, если:

Вам нужно настроить UI/UX, выходя за рамки базовых цветовых тем.
Вам нужен точный контроль над повторной отрисовкой страницы (весь скрипт перезапускается при изменении входных данных, если вы не управляете фрагментами вручную).
Вам не нравится писать Python-скрипты.

---

Dash

Фреймворк для веб-приложений на Python, предоставляющий прямой контроль над макетами, элементами DOM и обратными вызовами.

Dash позволяет Python-разработчикам создавать интерактивные веб-приложения без необходимости изучать JavaScript. Он предлагает существенный контроль и настройку для тех, кто готов углубиться в документацию. Ядро Dash — это класс Python, который объединяет несколько концепций:

Python-обертки для отображения общих элементов DOM и визуализаций plotly (например, `html.H1`, `dcc.Graph`);
Макет приложения, определенный как список вышеуказанных элементов в `app.layout`;
Загрузка и обработка данных с помощью обычных средств анализа данных, таких как numpy или pandas;
Интерактивность посредством обратных вызовов, которые принимают именованные входные данные из приложения (например, значение из выпадающего списка) и возвращают именованные выходные данные (например, отфильтрованный DataFrame);
Возможность добавлять собственный CSS и JavaScript при необходимости.

Dash построен на базе Flask, поэтому любой Python-разработчик, имеющий опыт работы с веб-фреймворками, должен чувствовать себя в нем комфортно. Хотя R, Julia и F# также указаны как совместимые языки, подавляющее большинство документации Dash написано для Python.

Dash — мощный выбор для опытных программистов на Python, которым нужен точный контроль. Однако, если вам неудобны ментальные модели, такие как классы, обратные вызовы или DOM, кривая обучения в Dash может показаться несколько крутой.

Пример кода:

from dash import Dash, html, dcc, callback, Output, Input
import plotly.express as px
import pandas as pd

df = pd.read_csv('https://raw.githubusercontent.com/plotly/datasets/master/gapminder_unfiltered.csv')

app = Dash()

app.layout = [
    html.H1(children='Title of Dash App', style={'textAlign':'center'}),
    dcc.Dropdown(df.country.unique(), 'Canada', id='dropdown-selection'),
    dcc.Graph(id='graph-content')
]

@callback(
    Output('graph-content', 'figure'),
    Input('dropdown-selection', 'value')
)
def update_graph(value):
    dff = df[df.country==value]
    return px.line(dff, x='year', y='pop')

if __name__ == '__main__':
    app.run(debug=True)

Хороший выбор, если:

У вас сильные навыки Python, и вы хотите более прямого контроля над макетом, стилизацией и интерактивностью, чем в Streamlit.
Вы уже хорошо работаете с веб-фреймворками на базе Python, такими как Flask или Django.
Вы знакомы с библиотеками для анализа данных на базе Python, такими как pandas, numpy и plotly.

Не рекомендуется, если:

Вам неудобно работать с классами, обратными вызовами, методами или декораторами Python.
Вам неудобно напрямую взаимодействовать с DOM.

---

Observable Framework

Инструментарий для визуализации данных для веб-разработчиков на JavaScript.

Если `npm run dev` — это ваша скорость, Observable Framework — отличный выбор для использования всей мощи веб-разработки при визуализации данных. Предоставляя вам импортируемые вспомогательные элементы, такие как Plot и FileAttachment, Observable упрощает интеграцию входных данных и предварительно созданных компонентов визуализации в ваше веб-приложение. У вас по-прежнему есть все обычные инструменты веб-разработки: HTML, JSX, компоненты React, стили CSS, функции JavaScript и импорты и т.д.

Хотя загрузчики данных для Observable могут быть написаны на любом языке программирования, базовый уровень комфорта с концепциями веб-разработки (например, HTML, CSS и JavaScript) позволит вам наилучшим образом использовать многие функции Observable.

Пример кода:

import * as Plot from 'npm:@observablehq/plot';

export function temperaturePlot(data, { width } = {}) {
return Plot.plot({
title: 'Hourly temperature forecast',
width,
x: { type: 'utc', ticks: 'day', label: null },
y: { grid: true, inset: 10, label: 'Degrees (F)' },
marks: [
Plot.lineY(data.properties.periods, {
x: 'startTime',
y: 'temperature',
z: null, // varying color, not series
stroke: 'temperature',
curve: 'step-after'
})
]
});
}
# Weather report

import { temperaturePlot } from './components/temperaturePlot.js';

const forecast = FileAttachment('./data/forecast.json').json();

display(temperaturePlot(forecast));

Хороший выбор, если:

Вы веб-разработчик, который разбирается в HTML, CSS и JavaScript и хочет в полной мере использовать свои обычные инструменты (например, Node, React).

Не рекомендуется, если:

Вы не уверены, что такое node и npm, или что означает async/await.

---

Shiny

Авторитетная оболочка для R и Python, с акцентом на эффективную реактивность.

Если R или Python — ваш основной язык для анализа данных, и вы не заинтересованы в полноценной веб-разработке или ручном управлении обратными вызовами, то, возможно, стоит потрудиться, чтобы изучить ментальные модели Shiny. Из всех инструментов, рассмотренных в этой статье, он, вероятно, наиболее авторитетен в плане создания новых, специфичных для Shiny концепций, которые должен освоить пользователь. Например, все пользовательские входы (т.е. выпадающие списки) определяются с помощью функций `ui.input_*()`, а все выходы создаются декораторами, такими как `@render.plot`. Даже для опытного Python-разработчика понимание всех этих концепций может занять время. Код для сложной панели инструментов Shiny может стать довольно громоздким.

Преимущество всего этого заключается в том, что Shiny автоматически эффективно управляет реактивностью за вас. Их документация даже приводит пример воспроизведения панели инструментов Streamlit для более быстрой работы.

HTML, CSS и JavaScript могут управляться вручную, но необходимость их размещения внутри Python-оберток может привести к тому, что код будет выглядеть немного громоздко.

Если вы довольны использованием чистых, минималистичных, предварительно стилизованных компонентов Shiny и цените эффективную реактивность, Shiny может быть хорошим выбором.

Пример кода:

from shiny.express import input, render, ui
from shinywidgets import render_plotly

ui.page_opts(title="Penguins dashboard", fillable=True)

with ui.sidebar():
    ui.input_selectize(
        "var", "Select variable",
        ["bill_length_mm", "bill_depth_mm", "flipper_length_mm", "body_mass_g", "year"]
    )
    ui.input_numeric("bins", "Number of bins", 30)

with ui.card(full_screen=True):
    @render_plotly
    def hist():
        import plotly.express as px
        from palmerpenguins import load_penguins
        return px.histogram(load_penguins(), x=input.var(), nbins=input.bins())

Хороший выбор, если:

У вас сильные навыки R или Python, и вы хотите использовать только эти языки.
Вы цените быструю, эффективную реактивность и не хотите вручную управлять обратными вызовами.
Вам нравится использовать чистые, минималистичные, предварительно стилизованные компоненты.

Не рекомендуется, если:

Вы не хотите изучать специфические для Shiny ментальные модели для управления UI и реактивностью.
Вы предпочитаете напрямую контролировать UI с помощью более традиционного стека веб-разработки (например, HTML / CSS / JS).
Вам требуется очень тонкий контроль над внешним видом и ощущениями.

---

Quarto

Минималистичный рендерер страниц на Jupyter / Markdown, предназначенный для научной и технической публикации.

Если ваша цель — как можно быстрее и без излишеств преобразовать результаты анализа данных в HTML-файлы, .doc или PDF, Quarto может быть хорошим выбором. Quarto берет заметки Jupyter или Markdown в стиле Quarto и преобразует их в широкий спектр форматов. Доступны темы, а также некоторые параметры интерактивности. Фактически, если вы готовы потрудиться и изучить ее, Quarto предоставляет документацию для большинства задач, которые вы можете захотеть выполнить. В целом, однако, Quarto — хороший выбор для тех, кто уже знаком с заметками Jupyter и хочет быстро представить свою работу в общем формате без чрезмерной настройки или суеты.

Если вы привыкли публиковать свои работы в LaTeX, Quarto также может показаться более современной, гибкой альтернативой, которая по-прежнему предлагает чистый, простой, академический вид документа LaTeX.

Пример кода:

---
title: 'Quarto Basics'
format:
  html:
    code-fold: true
jupyter: python3
---

For a demonstration of a line plot on a polar axis, see @fig-polar.

#| label: fig-polar
#| fig-cap: "A line plot on a polar axis"

import numpy as np
import matplotlib.pyplot as plt

r = np.arange(0, 2, 0.01)
theta = 2 * np.pi * r
fig, ax = plt.subplots(
  subplot_kw = {'projection': 'polar'}
)
ax.plot(theta, r)
ax.set_rticks([0.5, 1, 1.5, 2])
ax.grid(True)
plt.show()

Хороший выбор, если:

Вы уже знакомы с заметками Jupyter или Markdown и хотите быстро представить свою работу в общем формате с минимальной стилизацией.
Вы не против изучать документацию для выполнения более сложных задач (например, пользовательские темы или развертывание в определенном сервисе, таком как Netlify).

Не рекомендуется, если:

Вам требуется полноценная функциональность веб-разработки.
Вам нужен обширный контроль над внешним видом и ощущениями, или интерактивностью.

---

Заключение

При выборе инструмента BI-as-code учитывайте технические навыки вашей команды и конкретные потребности:

* Evidence идеально подходит для аналитиков, которые в основном работают с SQL и хотят быстро создавать приложения для данных с использованием Markdown.
* Streamlit хорошо подходит для Python-специалистов по данным, стремящихся к быстрому прототипированию.
* Dash предлагает больше контроля для Python-разработчиков, знакомых с веб-фреймворками.
* Observable предоставляет полные возможности веб-разработки для JavaScript-разработчиков.
* Shiny подходит для пользователей R/Python, которым нужно эффективное управление реактивностью.
* Quarto идеально подходит для ученых и технических писателей, сосредоточенных на публикации документов.

Если вы хотите попробовать Evidence сами, вы можете начать бесплатно.

Evidence можно хостить на huggingface.co, но вот чем лучше в своей закрытой корпоративной среде пока не ясно. думаемс. 🤔

Кстати, вот такая штука еще интересная, но это тема другой статьи https://tabler.io/admin-template

Эволюция бизнес-аналитики: от монолитной к компонуемой архитектуре

Thu, 13 Feb 2025 01:23:28 +0300

Перевод: https://www.pracdata.io/p/the-evolution-of-business-intelligence-stack

По мере того, как мы вступаем в 2025 год, область инженерии данных продолжает свою стремительную эволюцию. В этой серии мы рассмотрим преобразующие тенденции, меняющие ландшафт инженерии данных, от новых архитектурных шаблонов до новых подходов к инструментарию.

Это первая часть нашей серии, посвященная эволюции архитектуры бизнес-аналитики (BI).

Введение

Ландшафт бизнес-аналитики (BI) претерпел значительные преобразования в последние годы, особенно в том, как данные представляются и обрабатываются.

Эта эволюция отражает более широкий переход от монолитных архитектур к более гибким, компонуемым решениям, которые лучше отвечают современным аналитическим потребностям.

В этой статье прослеживается эволюция BI-архитектуры через несколько ключевых этапов: от традиционных монолитных систем, через появление безголовой (headless) и бездонной (bottomless**) BI, до последних разработок в области BI-as-Code и встроенной аналитики.

** 😂 👯‍♀️

Если серьезно, то наверное лучший вариант бескрайний

Традиционная BI-архитектура: Монолитный подход

Традиционные BI-инструменты были построены как комплексные, тесно связанные системы со значительным акцентом на дизайне пользовательского интерфейса.

Эти системы обеспечивали обширную гибкость благодаря функциональности “кликай и смотри” для нарезки, разделения и группировки данных с использованием различных визуализаций. В своей основе эти системы состояли из трех взаимосвязанных компонентов, которые работали в гармонии для предоставления бизнес-аналитики.

*Традиционный BI-стек*

Серверный уровень служил основой, обрабатывая прием данных из источников OLAP и создавая оптимизированные кубы данных на сервере. Эти кубы содержали предварительно вычисленные измерения, которые позволяли исследовать данные в режиме реального времени.

Работая совместно с серверной частью, клиентский уровень предоставлял интерфейс визуализации, подключаясь к серверной части для доступа к кубам данных и построения панелей мониторинга.

Семантический уровень завершал архитектуру, определяя ключевые показатели эффективности (KPI) и метрики, встроенные в BI-программное обеспечение.

Недостатки традиционных BI-инструментов

Хотя эти традиционные системы были мощными, они имели значительные накладные расходы.

Организациям требовалась существенная инфраструктура для локального развертывания до того, как управляемые облачные BI-сервисы стали более доступными, а стоимость лицензирования часто была непомерно высокой.

Сроки реализации были длительными, даже демонстрации концепции требовали недель настройки и конфигурации. Для предприятий, обслуживающих большую пользовательскую базу, требования к ресурсам были особенно высокими.

Эти фундаментальные ограничения в сочетании с растущей потребностью в гибкости и экономичности вызвали серию архитектурных инноваций в области BI.

Появление бездонных (Bottomless) BI-инструментов

В ответ на эти вызовы появилось новое поколение легких, дезагрегированных BI-инструментов. Заметные решения с открытым исходным кодом, такие как Apache Superset, Metabase и Redash, начали появляться около десяти лет назад, причем Superset, первоначально разработанный в Airbnb, приобрел особую известность в экосистеме.

Эти новые инструменты приняли “безднную” архитектуру, устранив тяжелый серверный уровень, традиционно используемый для вычислений, построения и кеширования объектов куба.

Вместо того чтобы поддерживать свой собственный вычислительный уровень, они полагаются на подключенные исходные движки для запроса и предоставления данных на панели мониторинга во время выполнения. Этот архитектурный сдвиг вводит различные стратегии для обслуживания данных.

Работа с задержкой запросов

Отсутствие сервера отчетов представляет собой серьезную проблему для бездонных BI-инструментов: управление задержкой запросов при доступе к данным в режиме реального времени.

Чтобы решить эту проблему, эти инструменты используют несколько стратегий оптимизации. Один из ключевых подходов включает использование предварительно вычисленных агрегатов, хранящихся в основном хранилище данных, что позволяет панелям мониторинга эффективно предоставлять результаты.

Кроме того, такие инструменты, как Superset, реализуют уровни кеширования с использованием Redis для хранения часто используемых наборов данных. Этот механизм кеширования оказывается особенно эффективным: после того, как первоначальный запрос загружает набор данных, последующие визуализации и перезагрузки панели мониторинга могут обращаться к кешированной версии до тех пор, пока не изменятся базовые данные, что значительно сокращает время отклика.

Для компаний, работающих с большими объемами данных, интеграция со специализированными OLAP-движками реального времени, такими как Druid и ClickHouse, обеспечивает аналитические возможности с низкой задержкой.

Появление универсального семантического слоя

По мере того, как отрасль стремилась к большей гибкости в своем BI-стеке, переносимый семантический слой, или то, что известно как безголовая (headless) BI, появился в качестве промежуточного шага между традиционными монолитными системами и полностью легкими решениями.

Платформы безголовой BI предоставляют выделенный семантический слой, а некоторые объединяют движок запросов, позволяя организациям использовать любой инструмент визуализации по своему выбору. Этот подход полностью отделяет уровень представления (фронтенд) от семантического слоя.

С помощью таких инструментов, как Cube и MetricFlow (теперь часть dbt Labs), например, организации могут определять свои метрики и модели данных в центральном месте, а затем подключать различные инструменты визуализации, пользовательские приложения или легкие BI-решения к этому семантическому слою.

Этот архитектурный шаблон предлагает несколько преимуществ по сравнению с традиционными BI-системами. Он позволяет организациям поддерживать согласованные определения метрик в различных инструментах визуализации, поддерживает несколько интерфейсных приложений одновременно и обеспечивает лучшие возможности интеграции с современными стеками данных.

Семантический слой действует как универсальный переводчик между источниками данных и уровнями визуализации, обеспечивая согласованную бизнес-логику во всех аналитических приложениях.

Движение BI-as-Code

В последние годы наблюдается появление BI-as-Code, представляющего собой еще более легкий подход к разработке панелей мониторинга и интерактивных приложений для работы с данными.

Этот сдвиг парадигмы привносит рабочие процессы разработки программного обеспечения в разработку BI, позволяя использовать контроль версий, тестирование и методы непрерывной интеграции. Поскольку код служит основной абстракцией, а не пользовательским интерфейсом, разработчики могут реализовывать правильные рабочие процессы разработки перед развертыванием в производственной среде.

Известные инструменты в этой области, такие как Streamlit, легко интегрируются с экосистемой Python, позволяя разработчикам оставаться в рамках своих проектов Python без необходимости установки внешнего программного обеспечения для создания панелей мониторинга и приложений для работы с данными.

Этот подход делает упор на простоту и скорость, используя SQL и декларативные инструменты, такие как YAML, для создания панелей мониторинга. Полученные веб-приложения можно легко разместить самостоятельно, обеспечивая гибкость развертывания.

Хотя Streamlit лидирует по популярности, в последние годы появились новые решения с открытым исходным кодом, такие как Evidence, Rill, Vizro и Quary, каждое из которых привносит свой собственный подход к концепции BI-as-Code.

Ограничения BI-as-Code

Инструменты BI-as-Code в настоящее время имеют ограничения с точки зрения интерактивных функций исследования данных и предоставления BI-возможностей корпоративного уровня.

Они не обеспечивают тот же пользовательский опыт для нарезки и разделения данных, что и традиционные BI-инструменты, и им не хватает поддержки управления данными и семантического слоя, которые есть как в традиционных, так и в легких BI-решениях.

Тем не менее, BI-as-Code все чаще используется различными способами, например, командами специалистов по обработке данных, создающими интерактивные автономные приложения, командами разработчиков продуктов, создающими встроенные функции аналитики, и аналитиками, разрабатывающими внутренние приложения для работы с данными.

Новая развивающаяся тенденция: BI + Встроенная аналитика

Последняя эволюция в BI-архитектуре включает интеграцию высокопроизводительных встраиваемых OLAP-движков запросов, таких как Apache DataFusion и DuckDB.

Этот подход устраняет несколько пробелов в текущем ландшафте, сохраняя при этом преимущества легких, дезагрегированных архитектур.

Новая полнофункциональная компонуемая BI-архитектура дает несколько ключевых преимуществ:

Во-первых, она предлагает настоящую компонуемость и совместимость с возможностью замены встроенных вычислительных движков по мере необходимости, сохраняя при этом автономный семантический слой для определения метрик.

Возможности встроенной аналитики особенно мощны благодаря интеграции без копирования через стандартные фреймворки, в основном Apache Arrow, обеспечивающей доступ к данным на уровне микросекунд через оптимизированные столбчатые форматы в памяти.

Интеграция без копирования относится к методу оптимизации производительности, при котором доступ к данным и их обработка могут осуществляться без необходимости сериализации и преобразования данных между различными представлениями в памяти. В контексте DataFusion и Apache Arrow это означает, что когда данные загружаются в память в столбчатом формате Arrow, DataFusion может напрямую выполнять вычисления с этими данными без необходимости их преобразования или копирования во внутренний формат.

Прямая поддержка озер данных и lakehouse представляет собой еще один значительный шаг вперед, позволяя командам создавать панели мониторинга непосредственно поверх открытых табличных форматов, таких как Apache Iceberg и Apache Hudi, без промежуточного перемещения данных.

Эта возможность в сочетании с комплексной поддержкой федеративных запросов решает давнюю проблему в существующих легких BI-инструментах, которые с трудом эффективно объединяли данные из нескольких источников без необходимости использования внешнего движка федеративных запросов.

Внедрение в отрасли

Внедрение встраиваемых движков запросов в отрасли набирает обороты в экосистеме BI. Коммерческие поставщики возглавляют эту трансформацию: Omni интегрировала DuckDB в качестве своего основного аналитического движка, в то время как Cube.dev реализовала сложное сочетание Apache Arrow и DataFusion в своей безголовой BI-архитектуре.

Аналогичным образом, GoodData приняла эту тенденцию, реализовав Apache Arrow в качестве основы уровня кеширования своей системы FlexQuery, а Preset (Managed Superset) интегрировалась с MotherDuck (Managed DuckDB).

В области открытого исходного кода и Superset (с использованием библиотеки duckdb-engine), и Metabase теперь поддерживают встроенное подключение DuckDB с потенциальной будущей интеграцией в их основные движки.

Движение BI-as-Code также приняло встраиваемые движки. Rilldata объявила об интеграции DuckDB в 2023 году для автоматического профилирования и интерактивного моделирования при разработке панелей мониторинга, в то время как Evidence представила Universal SQL в 2024 году, основанный на реализации WebAssembly от DuckDB.

Заключение

Ландшафт бизнес-аналитики продолжает развиваться в сторону более гибких и эффективных решений.

Каждое архитектурное изменение принесло явные преимущества: безголовая BI обеспечила согласованность метрик между инструментами, бездонная BI снизила сложность инфраструктуры, BI-as-Code привнесла рабочие процессы разработчиков в аналитику, а встроенные движки теперь объединяют эти преимущества с высокопроизводительными возможностями запросов.

Интеграция встраиваемых движков запросов с легкими BI-инструментами представляет собой перспективное направление для реализации легкой BI, объединяющее лучшие аспекты традиционных BI-возможностей с современными архитектурными шаблонами. По мере развития этих технологий и роста экосистемы компании могут рассчитывать на все более сложные, но компонуемые решения для своих аналитических потребностей.

BI как код – Rill

Thu, 14 Dec 2023 21:30:52 +0300

https://github.com/rilldata/rill

Качаем, ставим, запускаем:

curl -s https://cdn.rilldata.com/install.sh | bash
rill start my-rill-project

Можно еще статейку полистать:
https://a.gavrilov.info/data/posts/Unlocking%20Data%20Insights%20with%20Rill:%20A%20Comprehensive%20Guide%20to%20Streamlined%20Data%20Analytics%20%7C%20by%20Felix%20Gu.pdf

🤌 DuckDB inside

Визуализация изменения ценности 1$ на протяжении 20 лет

Sun, 10 Dec 2023 22:17:39 +0300

Смотрим тут: https://perthirtysix.com/tool/visualizing-american-inflation

https://perthirtysix.com/tool/visualizing-american-inflation

Или копию pdf тут: https://a.gavrilov.info/data/posts/How%20Far%20Would%20$1%20From%201999%20Go%20Today%3F.pdf

Рисую простую диаграмму на Python

Sat, 09 Jul 2022 19:36:03 +0300

Вот собственно сам код:

import pandas as pd
import altair as alt

df = pd.read_excel('Sample - Superstore.xls', index_col=0) 
df2 = df.groupby('Region').sum()
df2 = df2.reset_index(level=0)

bars = alt.Chart(df2).mark_bar().encode(
   alt.X('Region:N', sort='-y'),
   alt.Y('Sales:Q'),
   color=alt.condition(  alt.datum.Region == 'West',  # If the year is 1810 this test returns True,
   alt.value('orange'),     # which sets the bar orange.
   alt.value('steelblue'))   
)

text = bars.mark_text(
    align='left',
    baseline='middle',
    dx=11  # Nudges text to right so it doesn't appear on top of the bar
).encode(
    text='mean(Sales):Q'
)

(bars + text).properties(height=300)