BI Consult
  • Перейти на QlikSense
  • Перейти на QlikView
  • Перейти на Tableau
  • Перейти на Power BI
  • Контакты
  • +7 812 334-08-01
    +7 499 608-13-06
  • EN
  • Отправить сообщение
  • Главная
  • Продукты Business-Qlik
    • Дистрибуция
    • Розничная торговля
    • Производство
    • Операторы связи
    • Страхование
    • Банки
    • Лизинг
    • Логистика
    • Нефтегазовый сектор
    • Медицина
    • Сеть ресторанов
    • Энергетика
    • Фрод-менеджмент
    • E-Commerce
    • Фармацевтика
    • Построение хранилища данных
    • Создание Data Lake
    • Цифровая трансформация
    • Управление по KPI
    • Финансы
    • Продажи
    • Склад
    • HR
    • Маркетинг
    • Внутренний аудит
    • Категорийный менеджмент
    • S&OP и прогнозная аналитика
    • Геоаналитика
    • Цепочки поставок (SCM)
    • Process Mining
    • Сквозная аналитика
  • Платформы
    • Qlik Sense
    • QlikView
    • Tableau
    • Microsoft Power BI
    • Геоаналитика Qlik GeoAnalytics
    • Qlik NPrinting - рассылка отчетности QlikView/Qlik Sense
    • KliqPlanning Suite - бюджетирование в QlikView
    • ATK BiView-1C Коннектор (для Qlik/Tableau/PowerBI)
    • QlikView/Qlik Sense SAP Коннектор
    • QlikView R-Коннектор
    • Qlik Web Connectors - коннектор Google, Facebook, Twitter
    • Vizlib Qlik Sense extentions (библиотека экстеншнов)
    • Библиотека extention для Qlik
    • Qlik Alerting
    • Qlik Data Integration Platform - создание Data Lake
    • Qlik Data Catalog решение для Data Governance
    • ATK BiView документация
  • Услуги
    • Консалтинг
    • Пилотный проект
    • План обучения и сертификации
    • Подготовка специалистов по Qlik
    • Бесплатное обучение Qlik
    • Сертификация Qlik
    • Поддержка
    • Технические задания
    • Сбор требований для проекта внедрения BI-системы
    • Аудит приложений Qlik и Tableau
    • Разработка BI Стратегии
    • Styleguide для BI-системы
    • Как выбрать BI-систему
  • Курсы
    • Учебный курс по Qlik Sense
    • Учебный курс по Tableau
    • Учебный курс по Microsoft Power BI
    • Учебный курс Информационная грамотность (Data Literacy)
    • Учебный курс Современная архитектура хранилища данных
    • Учебный курс для бизнес-аналитиков
    • Учебный курс по NPrinting
    • Учебный курс по BigQuery
    • Учебный курс по Azure Databricks
    • Учебный курс по DWH
    • Учебный курс по Data Governance
    • Учебный курс по Data Science (ML, AI)
    • Учебный курс администратора Qlik Sense
  • Компания
    • Руководство
    • Новости
    • Клиенты
    • Карьера
    • Скачать
    • Контакты

Услуги

  • Консалтинг
    • Продуктивный и согласованный анализ закупок, продаж и маркетинговых активностей в Fashion-Retail
    • Тренинг «S&OP для производственно-торговых компаний»
    • Проект внедрения Qlik
  • План обучения и сертификации
    • Учебные курсы Qlik
    • Учебные курсы Tableau
    • Учебные курсы Microsoft PowerBI
  • Бесплатное обучение
  • Сертификация Qlik
  • Пилотный проект
  • Сопровождение и поддержка
  • Технические задания
  • Сбор требований для проекта внедрения BI-системы
  • Аудит приложений QlikView / Qlik Sense / Tableau
  • Разработка BI Стратегии
    • Становясь Data-Driven организацией: скрытые возможности и проблемы
  • Styleguide для BI-системы
  • Как выбрать подходящую современную BI-систему

Отраслевые решения

  • Дистрибуция
    • Business-Qlik Дистрибуция
  • Розничная торговля
    • Business-Qlik Розничная торговля
    • Business-Qlik Розничная торговля: DIY
    • Business-Qlik Розничная торговля: Fashion
    • Business-Qlik для сетей аптек
    • BusinessPack для Tableau: POS - Point of Sales Perfomance
  • Производство
    • Business-Qlik Производство
  • Операторы связи
  • Банки
    • Business-Qlik for Banking на базе QlikView/Qlik Sense
    • Бизнес-аналитика в банке
  • Страхование
  • Фармацевтика
    • Business-Qlik Фармацевтика
  • Нефтегазовый сектор
  • Лизинг
  • Логистика
  • Медицина
  • Сеть ресторанов
  • Энергетика
  • E-Commerce
  • Анализ мошенничеств (фрод-менеджмент)

Функциональные решения

  • Управление по KPI
    • Самоуправляемая компания
  • Финансы
    • Бюджетирование
    • Консолидация финансовой отчетности
    • Панель управления, KPI для CFO
    • Рабочий капитал
    • Финансовая отчетность по МСФО
    • Платежный календарь / прогнозный ДДС
  • Продажи
    • Анализ данных из CRM
    • Планирование
  • Склад
  • Категорийный менеджмент
  • HR
  • Маркетинг
  • Внутренний аудит
  • Построение хранилища данных
  • Геоаналитика, аналитика на географической карте
  • Цепочка поставок (SCM)
  • S&OP и прогнозная аналитика
    • Прогнозная аналитика
    • Прогноз спроса на основании данных о вторичных продажах
  • Разработка стратегии цифровой трансформации
  • Сквозная аналитика
  • Process Mining
Главная » Курсы » Учебный курс Современная архитектура хранилища данных

Устраняем «ад зависимостей» с помощью dbt

В Tiqets мы поддерживаем ряд производных представлений в нашем хранилище данных. Вместо того, чтобы всегда возвращаться к необработанным данным, стараясь найти ответ на вопрос, мы моделируем данные, чтобы они представляли более «высокоуровневые» абстракции, полезные для бизнеса. Например, получаем:

  • активные клиенты из заказов
  • распределение затрат на рекламу из заказов и отчетов Google Рекламы.
  • последовательности конверсии из просмотров страниц и множества целей.

 

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

Мы активно использовали постоянные производные таблицы Looker (PDT), чтобы смоделировать около 80 представлений. Они создавались по расписанию, управляемому в Looker. Основная проблема заключается в том, что у нас не было возможности отслеживать зависимости между этими представлениями. Например, мы хотим убедиться, что последние данные о заказах поступили на склад, прежде чем обновлять представление активных клиентов. Все становится еще сложнее, когда PDT зависят от других PDT.

Чтобы убедиться, что все обновилось, мы создали сложное расписание, в котором учтены зависимости и время, необходимое для создания каждого PDT. В основном это срабатывало, но не всегда получалось. Прием данных может быть отложен, запросы могут занять больше времени, чем обычно, или мы можем увидеть сбои из-за изменений схемы. Это потребовало бы, чтобы кто-то вручную устранял этот «ад зависимостей» и обновлял PDT.

В этом посте мы расскажем, как используем dbt, чтобы упростить управление представлениями и укрепить доверие к данным, которые мы храним в нашем хранилище данных. Наше решение включает Gitlab CI для автоматизированных тестов и доставки и Apache Airflow для планирования, чтобы поддерживать их в актуальном состоянии.

 

Что такое dbt?

Исторически хранилища данных были медленными и дорогими системами с ограниченными ресурсами. Это привело к разработке шаблона ETL (извлечение, преобразование, нагрузка): процесс создания новых объектов базы данных путем извлечения данных из исходной базы данных, их преобразования на отдельном сервере и загрузки преобразованных данных в хранилище. Современные хранилища данных снизили стоимость хранения данных, увеличив при этом доступную вычислительную мощность и память. Это привело к появлению шаблона ELT (извлечение, загрузка, преобразование), при котором извлеченные необработанные данные сначала загружаются, а затем преобразуются в хранилище данных.

Инструмент Data Build Tool, dbt, становится де-факто стандартом для выполнения преобразований в современных хранилищах данных (и других механизмах SQL). С помощью dbt описываются преобразования существующих данных в новые представления, называемые моделями, с помощью написания SQL-запросов. Эти запросы построены по шаблону с помощью Jinja, что добавляет им некоторую гибкость. Шаблонный запрос выглядит так:

Скриншот: https://github.com/fishtown-analytics/jaffle_shop/blob/master/models/sta...

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

 

Разработка с dbt

Для разработки мы используем типичный поток для разработки программного обеспечения с конвейером непрерывной интеграции (CI). Код хранится в git-репозитории. Изменения вносятся путем создания ветвей функций. Каждый раз, когда вносится изменение, автоматизированный конвейер CI запускает анализ и тесты (подробнее об этом позже). Затем код просматривает другой Tiqeteer. Если все проходит успешно, ветвь объединяется, что запускает автоматическое развертывание. Наконец, после развертывания конвейер генерирует документацию. Эта логика есть в конвейере Gitlab CI (аналогично людям из группы данных Gitlab).

Автоматизированные тесты позволяют нам уверенно вносить изменения. Это возможно благодаря двум функциям dbt:

  • Тесты: предоставляют простой способ запуска утверждений в данных (например, является ли этот столбец уникальным?). Есть несколько встроенных тестов, но вы также можете протестировать все, что можете выразить с помощью SQL-запроса.
  • Пользовательские схемы: это позволяет нам создавать модели с обновленным кодом без изменения моделей в нашей производственной среде.

Мы объединяем эти две функции, чтобы автоматически создавать модели в настраиваемой схеме и запускать для них тесты для каждой ветви функций.

В конвейере есть следующие этапы:

 

  1. Создание образа докера с помощью dbt и нашего проекта.
  2. Компиляция проекта dbt, чтобы отловить простые ошибки, далее проверка с помощью sqlfluff на предмет того, соответствуют ли запросы нашим стандартам.
  3. Разворачивание более 200 моделей с помощью dbt run.
  4. Тестирование модели с помощью dbt test, в настоящее время у нас есть более 1000 тестов в мастере.
  1. Документирование проекта с помощью dbt docs generate, мы обслуживаем результаты с помощью Gitlab Pages.

Интересные моменты есть на шаге 3 и шаге 4. Способ их работы зависит от того, предназначен ли конвейер для запроса на слияние или для основной ветви. Начнем с более простого случая: главные конвейеры. По сути, мы просто выполняем  dbt run , ориентируясь на схему разработки. Если разработка выполнена успешно, мы сохраняем результаты (целевая папка target ) в корзину S3, которая будет использоваться при выполнении запросов на слияние.

Для запросов на слияние мы создаем схему на основе имени ветки. Например, ветка с именем feature/add_awesome_model  создаст на нашем складе схему с именем dbt_feature_add_awesome_model . Поскольку создание каждой модели с нуля занимает много времени, мы строим только те модели, которые были созданы или изменены в ветке. Это возможно с функцией «тонкого CI», вот как это работает. Флаг --state  ожидает результатов от предыдущего запуска базы данных (которые мы сохранили на S3 в нашем главном конвейере). На основе этого состояния dbt run  может идентифицировать и строить только новые и измененные модели.

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

Тем не менее, некоторые модели очень дорого строить с нуля, просто в них слишком много рядов. В этом случае мы используем простой шаблон Jinja, который проверяет текущую цель. Если это не производство, мы ограничиваем количество строк с помощью специального условия where .

Наконец, тестирование после развертывания может быть обратным с точки зрения разработки программного обеспечения. Но dbt тесты – это утверждения на сгенерированных моделях, которые мы можем запускать только после того, как они будут построены. Часто мы обнаруживаем «ошибки» разработки в функциональных ветках, прежде чем объединить их. Сбои в главном конвейере редко случаются при первом слиянии функции. Однако они очень полезны при запланированных запусках, так как указывают на то, что что-то в исходных данных изменилось. Мы обсудим планирование в следующем разделе.

 

Планирование обновлений и тестов

Слияние ветки с master обновляет модели при обновлении кода. Нам необходимо решение, чтобы поддерживать модели в актуальном состоянии, когда новые данные попадают в хранилище. В Tiqets мы используем  Apache Airflow для планирования наших конвейеров данных, поэтому мы реализовали DAG, который запускает наш CI Gitlab конвейер после загрузки данных из нашей производственной базы данных. Это выглядит так:

 

  • wait_dwh_sync – датчик, который блокирует процесс до завершения экспорта из производственной базы данных
  • start_pipeline вызывает API Gitlab для запуска конвейера CI, обновления моделей и запуска тестов.
  • wait_pipeline – датчик, который проверяет статус и генерирует оповещение Slack в случае ошибок
  • drop_feature_schemas – вспомогательная задача, которая отбрасывает все схемы, созданные для запуска конвейера CI для ветвей функций в Gitlab, обсуждаемых в предыдущем разделе.

Однако вскоре мы поняли, что хотим обновить модели, которые зависят от разных источников данных. В настоящее время мы реализовали два других варианта использования, которые мы называем «Распределение затрат на рекламу» и «Машина времени» (запланировано еще несколько). Процесс распределения затрат на рекламу зависит от отчетов Google Рекламы, Google Analytics и Bing Ads. Он преобразует данные в общий формат и распределяет затраты по заказам в соответствии с рядом бизнес-правил. Конвейер Time Machine – это модель, содержащая ежедневные снимки важных таблиц из производственной базы данных. Она позволяет нам путешествовать во времени и извлекать содержимое таблиц. Например, наличие продуктов в Рейксмузеуме на 2020–07–03 гг.

Эти модели имеют разные источники данных и потенциально могут выполняться с разной частотой. Для поддержки этих моделей мы реализовали настраиваемые хуки и операторы на основе проекта airflow-dbt. Нашим основным изменением была интеграция с Gitlab для получения проекта dbt. Перед любым выполнением мы клонируем новую копию репозитория. Таким образом, нам не нужно беспокоиться о том, как отправлять модели dbt в Airflow, мы выполняем все, что находится на главном сервере. Мы аутентифицируемся с помощью токена API, хранящегося в базе метаданных Airflow.

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

 

Другие варианты использования

Помимо запуска трех описанных выше конвейеров данных, у нас есть еще несколько вариантов использования.

Управление пользовательскими функциями (UDF): добавление UDF в наш репозиторий dbt дает нам возможность управлять версиями кода. UDF также являются частью нашего конвейера CI, то есть они присоединяются к настраиваемой схеме базы данных, что позволяет нам попробовать что-то новое, не затрагивая производственные данные. Бонусные баллы, если вы используете сиды для создания приложений и тестируете свои UDF перед отправкой!

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

Тесты целостности данных: не все данные в нашем хранилище находятся под контролем dbt (пока?). Тем не менее, мы все еще можем использовать dbt, чтобы делать утверждения на их базе. Например, у нас есть тесты, которые проверяют, имеют ли наши последние запуски парсера ожидаемый результат или мы обнаруживаем недопустимые данные в наших данных потока посещений.

Обнаружение аномалий: еще одно использование тестов – проверить, наблюдаем ли мы большие изменения в наших наборах данных. Все, что может быть выражено в SQL, может быть тестом, поэтому мы отслеживаем изменения в нашем канале сбора данных, вызывая сообщение Slack, если мы обнаруживаем большие изменения. Бонусные баллы, если вы отправите сообщение @stakeholder вместо @ data-team.

Моментальные снимки: мечта каждого инженера по обработке данных – неизменяемые данные, позволяющие реконструировать любое состояние путем повторного выполнения задач. К сожалению, в реальном мире данные часто меняются на месте. Снимки отслеживают изменения в любых моделях, создавая новую строку для каждого обновления. Это позволяет нам отслеживать обновления в наших отчетах Google Analytics.

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

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

Вторая болевая точка – это не ограничение dbt, а ошибочное предположение с нашей стороны. Мы начали с того момента, когда модели dbt должны обновляться после того, как мы синхронизируем данные из нашей производственной базы данных с нашим хранилищем. Хотя верно и то, что большинство наших моделей основано на этих данных, у нас есть множество источников данных: CRM, инструменты электронной почты SaaS, системы продажи билетов и т. д. Разделение их на разные DAG группы дало нам некоторую гибкость, но теперь мы должны побеспокоиться о проблемах параллелизма: обновляют ли эти группы DAG одни и те же модели или UDF? Нам нужно будет разработать более гибкий способ организации и обновления моделей. Таким образом, наши модели всегда будут максимально свежими.

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

Помимо решения этих проблем, мы работаем над упрощением потока за счет того, что все «производственные» запуски dbt выполняются в Airflow. Это должно в основном решить проблему №2, позволяя нам использовать обновления источника данных для запуска dbt. К тому же оно круто смотрится.

 

 

 

Узнать стоимость решенияЗапросить видео презентацию

Запросить видео презентацию Запросить доступ к демо стенду online

Задать вопрос

loading...

Решения

Анализировать ФинансыУвеличивайте ПродажиОптимальный Склад и ЛогистикаМаркетинговые Метрики

Клиенты

  • Разработанное решение позволяет решить следующие задачи:
    Сбор и централизованное хранение отчетных данных бизнес-единиц;
    Оперативное получение отчетности;
    Управление на основе ключевых показателей отчетности.
  • Полноценное решение для оценки работы ресторанов в сети.  Решение состоит из трех основных блоков QlikView:
    • KPI деятельности ресторанов, LFL-анализ ресторанов, отчетность для совета директоров; 
    • Операционная аналитика, план/фактный анализ YTD, MTD / Forecast, DTD; 
    • Маркетинговая и продуктовая аналитика.
    А также включает дополнительное приложение NPrinting для ежедневной рассылки корпоративной отчетности по всем ресторанам, управляющим и директорам этих ресторанов.
    Приложение консолидирует данные из различных источников.
  • Внедрение QlikView в fashion retail, готовое отраслевое решение для fashion retail по аналитике

    Внедрение/кастомизация решения BusinessQlik for Fashion Retail c решением задач: DashBoard, Жизнь Артикула, Отчет Сводный, Отчет Реализация 8 недель, Конструктор

  • Adriver

    Группа компаний Internest работает на рынке интернет-рекламы с 1997 года.

    Основное направление деятельности - создание технологических и бизнес-решений в области интернет-маркетинга.  

  • Решения
    • Дистрибуция
    • Розничная торговля
    • Производство
    • Операторы связи
    • Банки
    • Страхование
    • Фармацевтика
    • Лизинг
    • Логистика
    • Медицина
    • Нефтегазовый сектор
    • Сеть ресторанов
  • Продукты
    • Qlik Sense
    • QlikView
    • Tableau
    • Microsoft Power BI
    • ATK BiView-1C Коннектор (для Qlik/Tableau/PowerBI)
    • Vizlib Qlik Sense extentions (библиотека экстеншнов)
    • NPrinting
    • Геоаналитика Qlik GeoAnalytics
    • KliqPlanning Suite
    • Qlik WebConnectors
    • QlikView R Коннектор
    • QlikView/Qlik Sense SAP Коннектор
    • Alteryx
    • Qlik Data Catalog
    • Документация ATK BiView
  • Услуги
    • Консалтинг
    • Пилотный проект
    • Поддержка
    • План обучения и сертификации Qlik
    • Бесплатное обучение
    • Учебные курсы
    • Сертификация Qlik
    • Аудит приложений
  • Курсы
    • Учебный курс по Qlik Sense
    • Учебный курс по Tableau
    • Учебный курс по Microsoft Power BI
    • Учебный курс Современная архитектура хранилища данных
    • Учебный курс Информационная грамотность
    • Учебный курс для бизнес-аналитиков
    • Учебный курс по NPrinting
    • Учебный курс по Azure Databricks
    • Учебный курс по Google BigQuery
  • Компания
    • О нас
    • Руководство
    • Новости
    • Клиенты
    • Скачать
    • Контакты
  • Функциональные решения
    • Продажи
    • Финансы
    • Склад
    • HR
    • S&OP и прогнозная аналитика
    • Внутренний аудит
    • Геоаналитика
    • Категорийный менеджмент
    • Построение хранилища данных
    • Система управления KPI и BSC
    • Управление цепочками поставок
    • Маркетинг
    • Цифровая трансформация
    • Сквозная аналитика
    • Process Mining
QlikView Partner
LinkedInYouTubeVkontakteFacebook
ООО "Би Ай Консалт",
ИНН: 7811437757,
ОГРН: 1097847154184
199178, Россия,
Санкт-Петербург,
6-ая линия В.О., Д. 63, 4 этаж
Тел: +7 (812) 334-08-01
Тел: +7 (499) 608-13-06
E-mail: info@biconsult.ru