{
    "version": "https:\/\/jsonfeed.org\/version\/1.1",
    "title": "Yuriy Gavrilov: posts tagged BI",
    "_rss_description": "Welcome to my personal place for love, peace and happiness 🤖 Yuiry Gavrilov",
    "_rss_language": "en",
    "_itunes_email": "yvgavrilov@gmail.com",
    "_itunes_categories_xml": "",
    "_itunes_image": "https:\/\/gavrilov.info\/pictures\/userpic\/userpic-square@2x.jpg?1643451008",
    "_itunes_explicit": "no",
    "home_page_url": "https:\/\/gavrilov.info\/tags\/bi\/",
    "feed_url": "https:\/\/gavrilov.info\/tags\/bi\/json\/",
    "icon": "https:\/\/gavrilov.info\/pictures\/userpic\/userpic@2x.jpg?1643451008",
    "authors": [
        {
            "name": "Yuriy Gavrilov - B[u]g - for charity.gavrilov.eth",
            "url": "https:\/\/gavrilov.info\/",
            "avatar": "https:\/\/gavrilov.info\/pictures\/userpic\/userpic@2x.jpg?1643451008"
        }
    ],
    "items": [
        {
            "id": "272",
            "url": "https:\/\/gavrilov.info\/all\/novaya-era-transformacii-dannyh-dbt-protiv-bruin-i-aac\/",
            "title": "Новая эра трансформации данных: dbt против Bruin и aaC",
            "content_html": "<p>В мире данных произошла тихая, но фундаментальная революция. На смену традиционному подходу <b>ETL (Extract, Transform, Load)<\/b>, где данные преобразовывались до загрузки в хранилище, пришла новая парадигма — <b>ELT (Extract, Load, Transform)<\/b>. Благодаря мощности современных облачных хранилищ (таких как Snowflake, BigQuery, Databricks, Starburst\\Trino) стало выгоднее сначала загружать сырые данные, а уже затем трансформировать их непосредственно в хранилище.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/gavrilov.info\/pictures\/demo.gif\" width=\"1200\" height=\"900\" alt=\"\" \/>\n<\/div>\n<p>Этот сдвиг породил потребность в инструментах, которые специализируются на последнем шаге — трансформации (T). Именно в этой нише dbt (data build tool) стал безоговорочным лидером, но на его поле появляются и новые сильные игроки, такие как Bruin. Давайте разберемся, что это за инструменты, какой подход они олицетворяют и в чем их ключевые различия.<\/p>\n<h4>Подход «Аналитика как код»<\/h4>\n<p>И dbt, и Bruin являются яркими представителями движения <b>“Analytics as Code”<\/b> (аналитика как код). Это не просто инструменты, а целая философия, которая переносит лучшие практики разработки программного обеспечения в мир аналитики данных.<\/p>\n<p><b>Основные принципы и идеи:<\/b><\/p>\n<ol start=\"1\">\n<li><b>Версионирование:<\/b> Все трансформации данных описываются в виде кода (в основном SQL), который хранится в системе контроля версий, такой как Git. Это позволяет отслеживать изменения, совместно работать и откатываться к предыдущим версиям.<\/li>\n<li><b>Модульность и переиспользование (DRY – Don’t Repeat Yourself):<\/b> Сложные трансформации разбиваются на небольшие, логически завершенные модели, которые могут ссылаться друг на друга. Это делает код чище, понятнее и позволяет повторно использовать уже написанную логику.<\/li>\n<li><b>Тестирование:<\/b> Код трансформаций должен быть протестирован. Инструменты позволяют автоматически проверять качество данных после преобразований: на уникальность ключей, отсутствие `NULL` значений, соответствие заданным условиям и т.д.<\/li>\n<li><b>Документация и прозрачность:<\/b> Процесс трансформации становится самодокументируемым. Инструменты могут автоматически генерировать документацию и строить графы зависимостей моделей (data lineage), показывая, как данные текут и преобразуются от источника к конечному виду. <a href=\"https:\/\/www.element61.be\/en\/resource\/when-use-dbt-or-delta-live-tables\">element61.be<\/a><\/li>\n<li><b>CI\/CD (Continuous Integration \/ Continuous Deployment):<\/b> Изменения в коде трансформаций могут автоматически тестироваться и разворачиваться в продуктивную среду, что значительно ускоряет циклы разработки.<\/li>\n<\/ol>\n<p><b>Решаемые проблемы:<\/b><\/p>\n<ul>\n<li><b>“Черные ящики” ETL:<\/b> Заменяют сложные, трудноподдерживаемые и непрозрачные ETL-процессы на понятный и документированный код.<\/li>\n<li><b>Рассинхронизация команд:<\/b> Стирают границы между инженерами данных и аналитиками, позволяя аналитикам, владеющим SQL, самостоятельно создавать надежные модели данных.<\/li>\n<li><b>Низкое качество данных:<\/b> Встроенные механизмы тестирования помогают обеспечить надежность и согласованность данных.<\/li>\n<\/ul>\n<p>---<\/p>\n<h4>dbt (data build tool): Золотой стандарт трансформации<\/h4>\n<p><b>dbt<\/b> — это инструмент с открытым исходным кодом, который позволяет аналитикам и инженерам трансформировать данные в их хранилищах с помощью простых SQL-запросов. Важно понимать, что dbt <b>не извлекает и не загружает данные<\/b>. Он специализируется исключительно на шаге <b>“T”<\/b> в ELT  <a href=\"https:\/\/vutr.substack.com\/p\/why-is-dbt-so-popular\">vutr.substack.com<\/a>. <a href=\"https:\/\/github.com\/dbt-labs\/dbt-core\">dbt git<\/a>.<\/p>\n<p>Он работает как компилятор и исполнитель: вы пишете модели данных в `.sql` файлах, используя шаблонизатор Jinja для добавления логики (циклы, условия, макросы). Затем dbt компилирует этот код в чистый SQL и выполняет его в вашем хранилище данных <a href=\"https:\/\/www.element61.be\/en\/resource\/when-use-dbt-or-delta-live-tables\">element61.be<\/a>.<\/p>\n<h5>Плюсы dbt<\/h5>\n<ul>\n<li><b>Огромное сообщество и экосистема:<\/b> dbt стал де-факто стандартом индустрии. Существует огромное количество статей, курсов, готовых пакетов (библиотек) и экспертов.<\/li>\n<li><b>Фокус на SQL:<\/b> Низкий порог входа для аналитиков, которые уже знают SQL. Это демократизирует процесс трансформации данных.<\/li>\n<li><b>Мощное тестирование и документирование:<\/b> Встроенные команды для тестирования данных и автоматической генерации проектной документации с графом зависимостей.<\/li>\n<li><b>Зрелость и надежность:<\/b> Инструмент проверен временем и используется тысячами компаний по всему миру.<\/li>\n<li><b>Гибкость:<\/b> Благодаря шаблонизатору Jinja можно создавать очень сложные и переиспользуемые макросы, адаптируя dbt под любые нужды.<\/li>\n<\/ul>\n<h5>Минусы dbt<\/h5>\n<ul>\n<li><b>Только трансформация:<\/b> dbt не занимается извлечением (E) и загрузкой (L). Для этого вам понадобятся отдельные инструменты (например, Fivetran, Airbyte), что усложняет стек технологий.<\/li>\n<li><b>Кривая обучения:<\/b> Хотя основы просты, освоение продвинутых возможностей Jinja, макросов и структуры проекта требует времени.<\/li>\n<li><b>Зависимость от Python-моделей:<\/b> Хотя недавно появилась поддержка моделей на Python, она все еще не так нативна и проста, как основной SQL-подход, и требует дополнительных настроек.<\/li>\n<\/ul>\n<p>---<\/p>\n<h4>Bruin Data: Универсальный боец<\/h4>\n<p><b>Bruin<\/b> — это более новый игрок на рынке, который позиционирует себя как инструмент для создания “end-to-end” пайплайнов данных. В отличие от dbt, он не ограничивается только трансформацией, а стремится охватить больше этапов работы с данными, включая их загрузку (ingestion) <a href=\"https:\/\/github.com\/bruin-data\/bruin\">https:\/\/github.com\/bruin-data\/bruin<\/a>.<\/p>\n<p>Bruin разделяет ту же философию “Analytics as Code”, но предлагает более интегрированный опыт, где SQL и Python являются равноправными гражданами.<\/p>\n<h5>Плюсы Bruin<\/h5>\n<ul>\n<li><b>Универсальность:<\/b> Один инструмент для определения всего пайплайна: от загрузки из источников до финальных витрин данных. Это может упростить стек технологий.<\/li>\n<li><b>Нативная поддержка SQL и Python:<\/b> Позволяет легко комбинировать задачи на разных языках в одном пайплайне без дополнительных настроек. Это идеально для задач, где чистый SQL громоздок (например, работа с API, машинное обучение).<\/li>\n<li><b>Простота конфигурации:<\/b> Зачастую требует меньше шаблонного кода (boilerplate) для определения ассетов и пайплайнов по сравнению с dbt.<\/li>\n<li><b>Встроенное качество данных:<\/b> Как и dbt, делает акцент на проверках качества на каждом шаге.<\/li>\n<\/ul>\n<h5>Минусы Bruin<\/h5>\n<ul>\n<li><b> Пока маленькое сообщество:<\/b> Как у нового инструмента, у Bruin гораздо меньше пользователей, готовых решений и обсуждений на форумах по сравнению с dbt. Найти помощь или готовый пакет для решения специфической задачи сложнее.<\/li>\n<li><b>Незрелость:<\/b> Инструмент моложе, а значит, наверное, потенциально менее стабилен и может иметь меньше интеграций по сравнению с проверенным dbt. Пока нет облачных функция за деньги. Я так думал, но все же есть <a href=\"https:\/\/getbruin.com.\">https:\/\/getbruin.com.<\/a><\/li>\n<li><b>“Мастер на все руки — эксперт ни в чем?”:<\/b> Стремление охватить все этапы (E, L, T) может означать, что в каждом отдельном компоненте Bruin может уступать лучшим в своем классе специализированным инструментам (например, Fivetran в загрузке, dbt в трансформации), но это конечно субъективно.<\/li>\n<\/ul>\n<h4>Сводное сравнение<\/h4>\n<table cellpadding=\"0\" cellspacing=\"0\" border=\"0\" class=\"e2-text-table\">\n<tr>\n<td style=\"text-align: center\">Характеристика<\/td>\n<td style=\"text-align: center\">dbt (data build tool)<\/td>\n<td style=\"text-align: center\">Bruin Data<\/td>\n<\/tr>\n<tr>\n<td style=\"text-align: center\"><b>Основная задача<\/b><\/td>\n<td style=\"text-align: center\">Трансформация (T в ELT)<\/td>\n<td style=\"text-align: center\">Весь пайплайн (E, L, T)<\/td>\n<\/tr>\n<tr>\n<td style=\"text-align: center\"><b>Ключевые языки<\/b><\/td>\n<td style=\"text-align: center\">SQL с шаблонизатором Jinja<\/td>\n<td style=\"text-align: center\">SQL и Python как равноправные<\/td>\n<\/tr>\n<tr>\n<td style=\"text-align: center\"><b>Экосистема<\/b><\/td>\n<td style=\"text-align: center\">Огромная, стандарт индустрии<\/td>\n<td style=\"text-align: center\">Маленькая, развивающаяся<\/td>\n<\/tr>\n<tr>\n<td style=\"text-align: center\"><b>Зрелость<\/b><\/td>\n<td style=\"text-align: center\">Высокая, проверен временем<\/td>\n<td style=\"text-align: center\">Низкая\/Средняя<\/td>\n<\/tr>\n<tr>\n<td style=\"text-align: center\"><b>Стек инструментов<\/b><\/td>\n<td style=\"text-align: center\">Требует отдельных E\/L инструментов<\/td>\n<td style=\"text-align: center\">Стремится быть самодостаточным<\/td>\n<\/tr>\n<\/table>\n<h4>Итого<\/h4>\n<p>Выбор между dbt и Bruin — это выбор между двумя стратегиями построения современного стека данных.<\/p>\n<p><b>Выбирайте dbt, если:<\/b><\/p>\n<ul>\n<li>Вы строите гибкий стек из лучших в своем классе инструментов (“best-of-breed”): один для загрузки, другой для хранения, третий для трансформации.<\/li>\n<li>Ваша команда в основном состоит из аналитиков, сильных в SQL.<\/li>\n<li>Для вас критически важны поддержка сообщества, стабильность и наличие готовых решений.<\/li>\n<li>Вы работаете в большой организации, где принятие отраслевых стандартов является преимуществом.<\/li>\n<li>Вы готовы переехать к ним в платное облако, когда нибудь. Большая часть функционала доступна там.<\/li>\n<\/ul>\n<p><b>Выбирайте Bruin, если:<\/b><\/p>\n<ul>\n<li>Вы предпочитаете единый, интегрированный инструмент для управления всеми пайплайнами, чтобы упростить архитектуру<\/li>\n<li>Вы любите open source и End-to-end дата framework: фор data ingestion + transformations + кволити. :)<\/li>\n<li>Ваши пайплайны требуют тесной связки SQL и Python для трансформаций (например, обогащение данных через вызовы API или модели ML).<\/li>\n<li>Вы начинаете новый проект или работаете в небольшой команде и цените скорость настройки и меньшее количество движущихся частей.<\/li>\n<li>Вы Go’шник :) –  Bruin написан на Go почти на 100%.<\/li>\n<\/ul>\n<p>И dbt, и Bruin — мощные инструменты, воплощающие современные подходы к инженерии данных. dbt предлагает проверенный, сфокусированный и невероятно мощный движок для трансформаций, ставший стандартом. Bruin же предлагает более универсальный и интегрированный подход, который может быть привлекателен для команд, стремящихся к простоте и нативной поддержке Python.<\/p>\n<h4>А что такое “Аналитика как код” (Analytics as Code, AaC)?<\/h4>\n<p><b>Аналитика как код<\/b> — это подход к управлению аналитическими процессами, при котором все компоненты аналитики — от моделей данных и метрик до отчетов и правил доступа — определяются в виде кода в человекочитаемых файлах. Эти файлы затем управляются так же, как исходный код любого другого программного обеспечения: с помощью систем контроля версий, автоматизированного тестирования и развертывания <a href=\"https:\/\/medium.com\/gooddata-developers\/analytics-as-code-managing-analytics-solutions-like-any-other-software-504372ba6a61\">medium.com<\/a>.<\/p>\n<p>Самая близкая и известная аналогия — это <b>Infrastructure as Code (IaC)<\/b>. Как IaC (например, с помощью Terraform) позволил инженерам описывать серверы, сети и базы данных в коде вместо ручной настройки через веб-интерфейсы, так и AaC позволяет описывать в коде всё, что связано с данными <a href=\"https:\/\/medium.com\/@terezacihelkova\/analytics-as-code-what-is-it-and-how-does-it-help-you-93e9a3c179ee\">medium.com<\/a>.<\/p>\n<blockquote>\n<p>Идея проста и убедительна: “настройте свои системы один раз, выразите это в виде кода, а затем поместите в систему контроля версий” <a href=\"https:\/\/www.holistics.io\/blog\/analytics-as-code\/\">holistics.io<\/a>.<\/p>\n<\/blockquote>\n<h4>Проблема: Как было раньше?<\/h4>\n<p>Чтобы понять ценность AaC, нужно посмотреть на проблемы, которые он решает. В традиционном подходе аналитика часто была разрозненной и хрупкой:<\/p>\n<ul>\n<li><b>Логика в “черных ящиках”:<\/b> Сложные преобразования данных были скрыты внутри GUI-интерфейсов старых ETL-инструментов или непосредственно в настройках BI-платформы (например, Tableau, Power BI). Никто, кроме автора, не мог легко понять, как рассчитывается та или иная метрика.<\/li>\n<li><b>Разрозненные SQL-скрипты:<\/b> Аналитики хранили важные SQL-запросы на своих локальных машинах, в общих папках или на wiki-страницах. Не было единой версии правды, код дублировался и быстро устаревал.<\/li>\n<li><b>Отсутствие контроля версий:<\/b> Невозможно было отследить, кто, когда и почему изменил логику расчета ключевого показателя. Откат к предыдущей работающей версии был настоящей головной болью.<\/li>\n<li><b>“Ручное” тестирование:<\/b> Проверка качества данных после изменений была ручным, подверженным ошибкам процессом. Часто о проблемах узнавали уже от бизнес-пользователей, которые видели неверные цифры в отчетах.<\/li>\n<li><b>Рассинхронизация:<\/b> Инженеры данных готовили сырые таблицы, а аналитики строили свою логику поверх них. Любые изменения с одной стороны могли сломать всю цепочку, не будучи замеченными вовремя.<\/li>\n<\/ul>\n<p>Этот хаос приводил к главному — <b>недоверию к данным<\/b>. Никто не мог быть уверен, что цифры в дашборде верны.<\/p>\n<h4>Ключевые принципы “Аналитики как код”<\/h4>\n<p>AaC решает эти проблемы, внедряя практики из мира разработки ПО.<\/p>\n<ol start=\"1\">\n<li><b>Декларативное определение:<\/b> Все аналитические артефакты описываются в файлах.\n<ul>\n  <li>Модели данных:** `SELECT * FROM ...` в `.sql` файлах.<\/li>\n  <li>Тесты:** `not_null`, `unique` в `.yml` файлах.<\/li>\n  <li>Документация:** Описания таблиц и полей в `.yml` файлах.<\/li>\n  <li>Метрики и дашборды:** Определения в `.yml` или специализированных файлах <a href=\"https:\/\/medium.com\/gooddata-developers\/analytics-as-code-managing-analytics-solutions-like-any-other-software-504372ba6a61\">medium.com<\/a>.<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n<ol start=\"2\">\n<li><b>Контроль версий (Git):<\/b> Весь код хранится в репозитории (например, на GitHub или GitLab).\n<ul>\n  <li>Прозрачность:** Каждое изменение — это `commit` с понятным описанием.<\/li>\n  <li>Совместная работа:** Аналитики работают в отдельных ветках, а изменения вносятся через `Pull Request` (или `Merge Request`), что позволяет проводить ревью кода (code review).<\/li>\n  <li>Восстанавливаемость:** Если что-то пошло не так, можно легко откатиться к предыдущей версии.<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n<ol start=\"3\">\n<li><b>Автоматизированное тестирование:<\/b> Тесты являются неотъемлемой частью кода. Они запускаются автоматически при каждом изменении, чтобы гарантировать, что данные по-прежнему соответствуют ожиданиям (например, `user_id` всегда уникален и не равен `NULL`).<\/li>\n<\/ol>\n<ol start=\"4\">\n<li><b>CI\/CD (Непрерывная интеграция и развертывание):<\/b> Процессы полностью автоматизированы.\n<ul>\n  <li>Когда аналитик вносит изменения в `Pull Request`, автоматически запускаются тесты.<\/li>\n  <li>После одобрения и слияния ветки изменения автоматически развертываются в продуктивной среде (например, dbt Cloud или Jenkins запускает команду `dbt run`).<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n<ol start=\"5\">\n<li><b>Модульность и переиспользование (DRY – Don’t Repeat Yourself):<\/b> Сложные потоки данных разбиваются на небольшие, логичные и переиспользуемые модели. Одна модель может ссылаться на другую, создавая четкий граф зависимостей (lineage), который можно визуализировать.<\/li>\n<\/ol>\n<h4>Преимущества подхода AaC<\/h4>\n<p>Принятие этой философии дает компании ощутимые выгоды:<\/p>\n<ul>\n<li><b>Надежность и доверие:<\/b> Благодаря автоматическому тестированию и ревью кода значительно повышается качество данных, а вместе с ним и доверие бизнеса к аналитике.<\/li>\n<li><b>Скорость и гибкость:<\/b> Аналитики могут вносить изменения гораздо быстрее. Цикл от идеи до готового отчета сокращается с недель до дней или даже часов.<\/li>\n<li><b>Масштабируемость:<\/b> Кодовая база легко поддерживается и расширяется. Новые члены команды могут быстро разобраться в проекте благодаря документации и прозрачности.<\/li>\n<li><b>Прозрачность и обнаруживаемость:<\/b> Автоматически сгенерированная документация и графы зависимостей позволяют любому сотруднику понять, откуда берутся данные и как они рассчитываются.<\/li>\n<li><b>Демократизация:<\/b> AaC дает возможность аналитикам, владеющим SQL, самостоятельно создавать надежные и протестированные модели данных, не дожидаясь инженеров данных. Это стирает барьеры между командами.<\/li>\n<\/ul>\n<p>В конечном итоге, “Аналитика как код” — это культурный сдвиг, который превращает аналитику из ремесленного занятия в зрелую инженерную дисциплину, обеспечивая скорость, надежность и масштабируемость, необходимые современному бизнесу.<\/p>\n",
            "date_published": "2025-08-23T16:04:02+03:00",
            "date_modified": "2025-08-24T11:51:29+03:00",
            "tags": [
                "BI",
                "Data Engineer",
                "Data Quality",
                "dbt",
                "ETL"
            ],
            "image": "https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-08-23-v-15.37.26.png",
            "_date_published_rfc2822": "Sat, 23 Aug 2025 16:04:02 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "272",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": [
                    "https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2025-08-23-v-15.37.26.png",
                    "https:\/\/gavrilov.info\/pictures\/demo.gif"
                ]
            }
        },
        {
            "id": "193",
            "url": "https:\/\/gavrilov.info\/all\/evolyuciya-biznes-analitiki-ot-monolitnoy-k-komponuemoy-arhitekt\/",
            "title": "Эволюция бизнес-аналитики: от монолитной к компонуемой архитектуре",
            "content_html": "<p>Перевод: <a href=\"https:\/\/www.pracdata.io\/p\/the-evolution-of-business-intelligence-stack\">https:\/\/www.pracdata.io\/p\/the-evolution-of-business-intelligence-stack<\/a><\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/gavrilov.info\/pictures\/image-132.png\" width=\"1336\" height=\"944\" alt=\"\" \/>\n<\/div>\n<p>По мере того, как мы вступаем в 2025 год, область инженерии данных продолжает свою стремительную эволюцию. В этой серии мы рассмотрим преобразующие тенденции, меняющие ландшафт инженерии данных, от новых архитектурных шаблонов до новых подходов к инструментарию.<\/p>\n<p>Это первая часть нашей серии, посвященная эволюции архитектуры бизнес-аналитики (BI).<\/p>\n<p><b>Введение<\/b><\/p>\n<p>Ландшафт бизнес-аналитики (BI) претерпел значительные преобразования в последние годы, особенно в том, как данные представляются и обрабатываются.<\/p>\n<p>Эта эволюция отражает более широкий переход от монолитных архитектур к более гибким, компонуемым решениям, которые лучше отвечают современным аналитическим потребностям.<\/p>\n<p>В этой статье прослеживается эволюция BI-архитектуры через несколько ключевых этапов: от традиционных монолитных систем, через появление безголовой (headless) и бездонной (bottomless**) BI, до последних разработок в области BI-as-Code и встроенной аналитики.<\/p>\n<p>** 😂 👯‍♀️<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/gavrilov.info\/pictures\/evolyuciya-biznes-analitiki-ot-monolitnoy-k-komponuemoy-arhitekt.png\" width=\"2156\" height=\"222\" alt=\"\" \/>\n<div class=\"e2-text-caption\">Если серьезно, то наверное лучший вариант бескрайний<\/div>\n<\/div>\n<p><b>Традиционная BI-архитектура: Монолитный подход<\/b><\/p>\n<p>Традиционные BI-инструменты были построены как комплексные, тесно связанные системы со значительным акцентом на дизайне пользовательского интерфейса.<\/p>\n<p>Эти системы обеспечивали обширную гибкость благодаря функциональности “кликай и смотри” для нарезки, разделения и группировки данных с использованием различных визуализаций. В своей основе эти системы состояли из трех взаимосвязанных компонентов, которые работали в гармонии для предоставления бизнес-аналитики.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/gavrilov.info\/pictures\/image-133.png\" width=\"473\" height=\"487\" alt=\"\" \/>\n<\/div>\n<p>*Традиционный BI-стек*<\/p>\n<p>Серверный уровень служил основой, обрабатывая прием данных из источников OLAP и создавая оптимизированные кубы данных на сервере. Эти кубы содержали предварительно вычисленные измерения, которые позволяли исследовать данные в режиме реального времени.<\/p>\n<p>Работая совместно с серверной частью, клиентский уровень предоставлял интерфейс визуализации, подключаясь к серверной части для доступа к кубам данных и построения панелей мониторинга.<\/p>\n<p>Семантический уровень завершал архитектуру, определяя ключевые показатели эффективности (KPI) и метрики, встроенные в BI-программное обеспечение.<\/p>\n<p><b>Недостатки традиционных BI-инструментов<\/b><\/p>\n<p>Хотя эти традиционные системы были мощными, они имели значительные накладные расходы.<\/p>\n<p>Организациям требовалась существенная инфраструктура для локального развертывания до того, как управляемые облачные BI-сервисы стали более доступными, а стоимость лицензирования часто была непомерно высокой.<\/p>\n<p>Сроки реализации были длительными, даже демонстрации концепции требовали недель настройки и конфигурации. Для предприятий, обслуживающих большую пользовательскую базу, требования к ресурсам были особенно высокими.<\/p>\n<p>Эти фундаментальные ограничения в сочетании с растущей потребностью в гибкости и экономичности вызвали серию архитектурных инноваций в области BI.<\/p>\n<p><b>Появление бездонных (Bottomless) BI-инструментов<\/b><\/p>\n<p>В ответ на эти вызовы появилось новое поколение легких, дезагрегированных BI-инструментов. Заметные решения с открытым исходным кодом, такие как Apache Superset, Metabase и Redash, начали появляться около десяти лет назад, причем Superset, первоначально разработанный в Airbnb, приобрел особую известность в экосистеме.<\/p>\n<p>Эти новые инструменты приняли “безднную” архитектуру, устранив тяжелый серверный уровень, традиционно используемый для вычислений, построения и кеширования объектов куба.<\/p>\n<p>Вместо того чтобы поддерживать свой собственный вычислительный уровень, они полагаются на подключенные исходные движки для запроса и предоставления данных на панели мониторинга во время выполнения. Этот архитектурный сдвиг вводит различные стратегии для обслуживания данных.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/gavrilov.info\/pictures\/image-134.png\" width=\"1456\" height=\"1147\" alt=\"\" \/>\n<\/div>\n<p><b>Работа с задержкой запросов<\/b><\/p>\n<p>Отсутствие сервера отчетов представляет собой серьезную проблему для бездонных BI-инструментов: управление задержкой запросов при доступе к данным в режиме реального времени.<\/p>\n<p>Чтобы решить эту проблему, эти инструменты используют несколько стратегий оптимизации. Один из ключевых подходов включает использование предварительно вычисленных агрегатов, хранящихся в основном хранилище данных, что позволяет панелям мониторинга эффективно предоставлять результаты.<\/p>\n<p>Кроме того, такие инструменты, как Superset, реализуют уровни кеширования с использованием Redis для хранения часто используемых наборов данных. Этот механизм кеширования оказывается особенно эффективным: после того, как первоначальный запрос загружает набор данных, последующие визуализации и перезагрузки панели мониторинга могут обращаться к кешированной версии до тех пор, пока не изменятся базовые данные, что значительно сокращает время отклика.<\/p>\n<p>Для компаний, работающих с большими объемами данных, интеграция со специализированными OLAP-движками реального времени, такими как Druid и ClickHouse, обеспечивает аналитические возможности с низкой задержкой.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/gavrilov.info\/pictures\/image-135.png\" width=\"1339\" height=\"1173\" alt=\"\" \/>\n<\/div>\n<p><b>Появление универсального семантического слоя<\/b><\/p>\n<p>По мере того, как отрасль стремилась к большей гибкости в своем BI-стеке, переносимый семантический слой, или то, что известно как безголовая (headless) BI, появился в качестве промежуточного шага между традиционными монолитными системами и полностью легкими решениями.<\/p>\n<p>Платформы безголовой BI предоставляют выделенный семантический слой, а некоторые объединяют движок запросов, позволяя организациям использовать любой инструмент визуализации по своему выбору. Этот подход полностью отделяет уровень представления (фронтенд) от семантического слоя.<\/p>\n<p>С помощью таких инструментов, как Cube и MetricFlow (теперь часть dbt Labs), например, организации могут определять свои метрики и модели данных в центральном месте, а затем подключать различные инструменты визуализации, пользовательские приложения или легкие BI-решения к этому семантическому слою.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/gavrilov.info\/pictures\/image-136.png\" width=\"542\" height=\"755\" alt=\"\" \/>\n<\/div>\n<p>Этот архитектурный шаблон предлагает несколько преимуществ по сравнению с традиционными BI-системами. Он позволяет организациям поддерживать согласованные определения метрик в различных инструментах визуализации, поддерживает несколько интерфейсных приложений одновременно и обеспечивает лучшие возможности интеграции с современными стеками данных.<\/p>\n<p>Семантический слой действует как универсальный переводчик между источниками данных и уровнями визуализации, обеспечивая согласованную бизнес-логику во всех аналитических приложениях.<\/p>\n<p><b>Движение BI-as-Code<\/b><\/p>\n<p>В последние годы наблюдается появление BI-as-Code, представляющего собой еще более легкий подход к разработке панелей мониторинга и интерактивных приложений для работы с данными.<\/p>\n<p>Этот сдвиг парадигмы привносит рабочие процессы разработки программного обеспечения в разработку BI, позволяя использовать контроль версий, тестирование и методы непрерывной интеграции. Поскольку код служит основной абстракцией, а не пользовательским интерфейсом, разработчики могут реализовывать правильные рабочие процессы разработки перед развертыванием в производственной среде.<\/p>\n<p>Известные инструменты в этой области, такие как Streamlit, легко интегрируются с экосистемой Python, позволяя разработчикам оставаться в рамках своих проектов Python без необходимости установки внешнего программного обеспечения для создания панелей мониторинга и приложений для работы с данными.<\/p>\n<p>Этот подход делает упор на простоту и скорость, используя SQL и декларативные инструменты, такие как YAML, для создания панелей мониторинга. Полученные веб-приложения можно легко разместить самостоятельно, обеспечивая гибкость развертывания.<\/p>\n<p>Хотя Streamlit лидирует по популярности, в последние годы появились новые решения с открытым исходным кодом, такие как Evidence, Rill, Vizro и Quary, каждое из которых привносит свой собственный подход к концепции BI-as-Code.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/gavrilov.info\/pictures\/image-137.png\" width=\"688\" height=\"745\" alt=\"\" \/>\n<\/div>\n<p><b>Ограничения BI-as-Code<\/b><\/p>\n<p>Инструменты BI-as-Code в настоящее время имеют ограничения с точки зрения интерактивных функций исследования данных и предоставления BI-возможностей корпоративного уровня.<\/p>\n<p>Они не обеспечивают тот же пользовательский опыт для нарезки и разделения данных, что и традиционные BI-инструменты, и им не хватает поддержки управления данными и семантического слоя, которые есть как в традиционных, так и в легких BI-решениях.<\/p>\n<p>Тем не менее, BI-as-Code все чаще используется различными способами, например, командами специалистов по обработке данных, создающими интерактивные автономные приложения, командами разработчиков продуктов, создающими встроенные функции аналитики, и аналитиками, разрабатывающими внутренние приложения для работы с данными.<\/p>\n<p><b>Новая развивающаяся тенденция: BI + Встроенная аналитика<\/b><\/p>\n<p>Последняя эволюция в BI-архитектуре включает интеграцию высокопроизводительных встраиваемых OLAP-движков запросов, таких как Apache DataFusion и DuckDB.<\/p>\n<p>Этот подход устраняет несколько пробелов в текущем ландшафте, сохраняя при этом преимущества легких, дезагрегированных архитектур.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/gavrilov.info\/pictures\/image-138.png\" width=\"1209\" height=\"1094\" alt=\"\" \/>\n<\/div>\n<p>Новая полнофункциональная компонуемая BI-архитектура дает несколько ключевых преимуществ:<\/p>\n<p>Во-первых, она предлагает настоящую компонуемость и совместимость с возможностью замены встроенных вычислительных движков по мере необходимости, сохраняя при этом автономный семантический слой для определения метрик.<\/p>\n<p>Возможности встроенной аналитики особенно мощны благодаря интеграции без копирования через стандартные фреймворки, в основном Apache Arrow, обеспечивающей доступ к данным на уровне микросекунд через оптимизированные столбчатые форматы в памяти.<\/p>\n<p>Интеграция без копирования относится к методу оптимизации производительности, при котором доступ к данным и их обработка могут осуществляться без необходимости сериализации и преобразования данных между различными представлениями в памяти. В контексте DataFusion и Apache Arrow это означает, что когда данные загружаются в память в столбчатом формате Arrow, DataFusion может напрямую выполнять вычисления с этими данными без необходимости их преобразования или копирования во внутренний формат.<\/p>\n<p>Прямая поддержка озер данных и lakehouse представляет собой еще один значительный шаг вперед, позволяя командам создавать панели мониторинга непосредственно поверх открытых табличных форматов, таких как Apache Iceberg и Apache Hudi, без промежуточного перемещения данных.<\/p>\n<p>Эта возможность в сочетании с комплексной поддержкой федеративных запросов решает давнюю проблему в существующих легких BI-инструментах, которые с трудом эффективно объединяли данные из нескольких источников без необходимости использования внешнего движка федеративных запросов.<\/p>\n<p><b>Внедрение в отрасли<\/b><\/p>\n<p>Внедрение встраиваемых движков запросов в отрасли набирает обороты в экосистеме BI.  Коммерческие поставщики возглавляют эту трансформацию: Omni интегрировала DuckDB в качестве своего основного аналитического движка, в то время как Cube.dev реализовала сложное сочетание Apache Arrow и DataFusion в своей безголовой BI-архитектуре.<\/p>\n<p>Аналогичным образом, GoodData приняла эту тенденцию, реализовав Apache Arrow в качестве основы уровня кеширования своей системы FlexQuery, а Preset (Managed Superset) интегрировалась с MotherDuck (Managed DuckDB).<\/p>\n<p>В области открытого исходного кода и Superset (с использованием библиотеки duckdb-engine), и Metabase теперь поддерживают встроенное подключение DuckDB с потенциальной будущей интеграцией в их основные движки.<\/p>\n<p>Движение BI-as-Code также приняло встраиваемые движки. Rilldata объявила об интеграции DuckDB в 2023 году для автоматического профилирования и интерактивного моделирования при разработке панелей мониторинга, в то время как Evidence представила <a href=\"https:\/\/evidence.dev\/blog\/why-we-built-usql\">Universal SQL в 2024 году<\/a>, основанный на реализации WebAssembly от DuckDB.<\/p>\n<p><b>Заключение<\/b><\/p>\n<p>Ландшафт бизнес-аналитики продолжает развиваться в сторону более гибких и эффективных решений.<\/p>\n<p>Каждое архитектурное изменение принесло явные преимущества: безголовая BI обеспечила согласованность метрик между инструментами, бездонная BI снизила сложность инфраструктуры, BI-as-Code привнесла рабочие процессы разработчиков в аналитику, а встроенные движки теперь объединяют эти преимущества с высокопроизводительными возможностями запросов.<\/p>\n<p>Интеграция встраиваемых движков запросов с легкими BI-инструментами представляет собой перспективное направление для реализации легкой BI, объединяющее лучшие аспекты традиционных BI-возможностей с современными архитектурными шаблонами. По мере развития этих технологий и роста экосистемы компании могут рассчитывать на все более сложные, но компонуемые решения для своих аналитических потребностей.<\/p>\n",
            "date_published": "2025-02-13T01:23:28+03:00",
            "date_modified": "2025-02-14T23:09:31+03:00",
            "tags": [
                "BI",
                "Data Mesh",
                "Data Visualization"
            ],
            "image": "https:\/\/gavrilov.info\/pictures\/image-132.png",
            "_date_published_rfc2822": "Thu, 13 Feb 2025 01:23:28 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "193",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": [
                    "https:\/\/gavrilov.info\/pictures\/image-132.png",
                    "https:\/\/gavrilov.info\/pictures\/evolyuciya-biznes-analitiki-ot-monolitnoy-k-komponuemoy-arhitekt.png",
                    "https:\/\/gavrilov.info\/pictures\/image-133.png",
                    "https:\/\/gavrilov.info\/pictures\/image-134.png",
                    "https:\/\/gavrilov.info\/pictures\/image-135.png",
                    "https:\/\/gavrilov.info\/pictures\/image-136.png",
                    "https:\/\/gavrilov.info\/pictures\/image-137.png",
                    "https:\/\/gavrilov.info\/pictures\/image-138.png"
                ]
            }
        }
    ],
    "_e2_version": 4171,
    "_e2_ua_string": "Aegea 11.4 (v4171e)"
}