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
Главная » Курсы » Учебный курс Современная архитектура хранилища данных

Введение в Data Engineering. ETL, схема «звезды» и Airflow

Способность data scientist-а извлекать ценность из данных тесно связана с тем, насколько развита инфраструктура хранения и обработки данных в компании. Это значит, что аналитик должен не только уметь строить модели, но и обладать достаточными навыками в области data engineering, чтобы соответствовать потребностям компании и браться за все более амбициозные проекты.

При этом, несмотря на всю важность, образование в сфере data engineering продолжает оставаться весьма ограниченным. Мне повезло, поскольку я успел поработать со многими инженерами, которые терпеливо объясняли мне каждый аспект работы с данными, но не все обладают такой возможностью. Именно поэтому я решил написать эту статью — введение в data engineering, в которой я расскажу о том, что такое ETL, разнице между SQL- и JVM-ориентированными ETL, нормализации и партиционировании данных и, наконец, рассмотрим пример запроса в Airflow.

 

Data Engineering

Maxime Beauchemin, один из разработчиков Airflow, так охарактеризовал data engineering: «Это область, которую можно рассматривать как смесь бизнес-аналитики и баз данных, которая привносит больше элементов программирования. Эта сфера включает в себя специализацию по работе с распределенными системами больших данных, расширенной экосистемой Hadoop и масштабируемыми вычислениями».

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

 

ETL: Extract, Transform, Load

Extract, Transform и Load — это 3 концептуально важных шага, определяющих, каким образом устроены большинство современных пайплайнов данных. На сегодняшний день это базовая модель того, как сырые данные сделать готовыми для анализа.


Extract. Это шаг, на котором датчики принимают на вход данные из различных источников (логов пользователей, копии реляционной БД, внешнего набора данных и т.д.), а затем передают их дальше для последующих преобразований.

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

Load. Наконец, мы загружаем обработанные данные и отправляем их в место конечного использования. Полученный набор данных может быть использован конечными пользователями, а может являться входным потоком к еще одному ETL.

 

Какой ETL-фреймворк выбрать?

В мире batch-обработки данных есть несколько платформ с открытым исходным кодом, с которыми можно попробовать поиграть. Некоторые из них: Azkaban — open-source воркфлоу менеджер от Linkedin, особенностью которого является облегченное управление зависимостями в Hadoop, Luigi — фреймворк от Spotify, базирующийся на Python и Airflow, который также основан на Python, от Airbnb.

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

Конфигурация. ETL-ы по своей природе довольно сложны, поэтому важно, как именно пользователь фреймворка будет их конструировать. Основан ли он на пользовательском интерфейсе или же запросы создаются на каком-либо языке программирования? Сегодня все большую популярность набирает именно второй способ, поскольку программирование пайплайнов делает их более гибкими, позволяя изменять любую деталь.

Мониторинг ошибок и оповещения. Объемные и долгие batch запросы рано или поздно падают с ошибкой, даже если в самой джобе багов нет. Как следствие, мониторинг и оповещения об ошибках выходят на первый план. Насколько хорошо фреймворк визуализирует прогресс запроса? Приходят ли оповещения вовремя?

Обратное заполнение данных (backfilling). Часто после построения готового пайплайна нам требуется вернуться назад и заново обработать исторические данных. В идеале нам бы не хотелось строить две независимые джобы: одну для обратного а исторических данных, а вторую для текущей деятельности. Насколько легко осуществлять backfilling c помощью данного фреймворка? Масштабируемо и эффективно ли полученное решение?

 

2 парадигмы: SQL против JVM

Как мы выяснили, у компаний есть огромный выбор того, какие инструменты использовать для ETL, и для начинающего data scientist-а не всегда понятно, какому именно фреймворку посвятить время. Это как раз про меня: в Washington Post Labs очередность джобов осуществлялась примитивно, с помощью Cron, в Twitter ETL джобы строились в Pig, а сейчас в Airbnb мы пишем пайплайны в Hive через Airflow. Поэтому перед тем, как пойти в ту или иную компанию, постарайтесь узнать, как именно организованы ETL в них. Упрощенно, можно выделить две основные парадигмы: SQL и JVM-ориентированные ETL.

JVM-ориентированные ETL обычно написаны на JVM-ориентированном языке (Java или Scala). Построение пайплайнов данных на таких языках означает задавать преобразования данных через пары «ключ-значение», однако писать пользовательские функции и тестировать джобы становится легче, поскольку не требуется использовать для этого другой язык программирования. Эта парадигма весьма популярна среди инженеров.

SQL-ориентированные ETL чаще всего пишутся на SQL, Presto или Hive. В них почти все крутится вокруг SQL и таблиц, что весьма удобно. В то же время написание пользовательских функций может быть проблематично, поскольку требует использования другого языка (к примеру, Java или Python). Такой подход популярен среди data scientist-ов.

Поработав с обеими парадигмами, я все-таки предпочитаю SQL-ориентированные ETL, поскольку, будучи начинающим data scientist-ом, намного легче выучить SQL, чем Java или Scala (если, конечно, вы еще с ними не знакомы) и сконцентрироваться на изучении новых практик, чем накладывать это поверх изучения нового языка.

 

Моделирование данных, нормализация и схема «звезды»

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

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

С другой стороны, гораздо легче писать запросы к денормализованным таблицам, поскольку все измерения и метрики уже соединены. Однако, учитывая больший размер таблиц, обработка данных становится медленнее (“Тут можно поспорить, ведь все зависит от того, как хранятся данные и какие запросы бывают. Можно, к примеру, хранить большие таблицы в Hbase и обращаться к отдельным колонкам, тогда запросы будут быстрыми” — прим. пер.).

Среди всех моделей данных, которые пытаются найти идеальный баланс между двумя подходами, одной из наиболее популярных (мы используем ее в Airbnb) является схема «звезды». Данная схема основана на построении нормализованных таблиц (таблиц фактов и таблиц измерений), из которых, в случае чего, могут быть получены денормализованные таблицы. В результате такой дизайн пытается найти баланс между легкостью аналитики и сложностью поддержки ETL.

 

Таблицы фактов и таблицы измерений

Чтобы лучше понять, как строить денормализованные таблицы из таблиц фактов и таблиц измерений, обсудим роли каждой из них:

Таблицы фактов чаще всего содержат транзакционные данные в определенные моменты времени. Каждая строка в таблице может быть чрезвычайно простой и чаще всего является одной транзакцией. У нас в Airbnb есть множество таблиц фактов, которые хранят данные по типу транзакций: бронирования, оформления заказов, отмены и т.д.

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

Ниже представлен простой пример того, как таблицы фактов и таблицы измерений (нормализованные) могут быть соединены, чтобы ответить на простой вопрос: сколько бронирований было сделано за последнюю неделю по каждому из рынков?

 

SELECT
    b.dim_market
  , SUM(a.m_bookings) AS m_bookings
FROM (
  SELECT
      id_listing
    , 1          AS m_bookings
    , m_a        # not used (for illustration only)
    , m_b        # not used (for illustration only)
    , m_c        # not used (for illustration only)
  FROM
    fct_bookings
  WHERE
    ds BETWEEN '{{ last_sunday }}' AND '{{ this_saturday }}'
) a
JOIN (
  SELECT
      id_listing
    , dim_market
    , dim_x      # not used (for illustration only)
    , dim_y      # not used (for illustration only)
    , dim_z      # not used (for illustration only)
  FROM
    dim_listings
  WHERE
    ds BETWEEN '{{ latest_ds }}'
) b
ON (a.id_listing = b.id_listing)
GROUP BY
  b.dim_market
;

 

Партиционирование данных по временной метке

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

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

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

 

Обратное заполнение (backfilling) исторических данных

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

Backfilling настолько распространен, что в Hive есть встроенная возможность динамического партиционирования, чтобы выполнять одни и те же SQL запросы по нескольким партициям сразу. Проиллюстрируем эту идею на примере: пусть требуется заполнить количество бронирований по каждому рынку для дашборда, начиная с earliest_ds и заканчивая latest_ds. Одно из возможных решений выглядит примерно так:

 

INSERT OVERWRITE TABLE bookings_summary PARTITION (ds= '{{ earliest_ds }}')
SELECT
      dim_market
    , SUM(m_bookings) AS m_bookings
FROM
    fct_bookings
WHERE
    ds = '{{ earliest_ds }}'
GROUP BY
    dim_market
;

# after many insertions from '{{ earliest_ds + 1 day }}' to '{{ latest_ds - 1 day }}'

INSERT OVERWRITE TABLE bookings_summary PARTITION (ds= '{{ latest_ds }}')
SELECT
      dim_market
    , SUM(m_bookings) AS m_bookings
FROM
    fct_bookings
WHERE
    ds = '{{ latest_ds }}'
GROUP BY
    dim_market
;

Такой запрос возможен, однако он слишком громоздкий, поскольку мы выполняем одну и ту же операцию, только над разными партициями. Используя динамическое партиционирование мы можем все упростить до одного запроса:

 

INSERT OVERWRITE TABLE bookings_summary PARTITION (ds)
SELECT
      dim_market
    , SUM(m_bookings) AS m_bookings
    , ds              # For Hive to know we are using dynamic partitions
FROM
    fct_bookings
WHERE
    ds BETWEEN '{{ earliest_ds }}' AND '{{ latest_ds }}'
GROUP BY
      dim_market
    , ds
;

Отметим, что мы добавили ds в SELECT и GROUP BY выражения, расширили диапазон в операции WHERE и изменили синтаксис с PARTITION (ds= '{{ds}}') на PARTITION (ds). Вся прелесть динамического партиционирования в том, что мы обернули GROUP BY ds вокруг необходимых операций, чтобы вставить результаты запроса во все партиции в один заход. Такой подход очень эффективен и используется во многих пайплайнах в Airbnb.

Теперь, рассмотрим все изученные концепции на примере ETL джобы в Airflow.

 

Направленный ациклический граф (DAG)

Казалось бы, с точки зрения идеи ETL джобы очень просты, однако на деле они часто очень запутаны и состоят из множества комбинаций Extract, Transform и Load операций. В этом случае очень полезно бывает визуализировать весь поток данных, используя граф, в котором узел отображает операцию, а стрелка — взаимосвязь между операциями. Учитывая, что каждая операция выполняется единожды, а данные идут дальше по графу, то он является направленным и ациклическим, отсюда и название.

Одна из особенностей интерфейса Airflow — это наличие механизма, который позволяет визуализировать пайплайн данных через DAG. Автор пайплайна должен задать взаимосвязи между операциями, чтобы Airflow записал спецификацию ETL джоба в отдельный файл.

При этом помимо DAG-ов, которые определяют порядок запуска операций, в Airflow есть операторы, которые задают, что необходимо выполнить в рамках пайплайна. Обычно есть 3 вида операторов, каждый из которых имитирует один из этапов ETL-процесса:

  • Сенсоры: открывают поток данных по истечении определенного времени, либо когда данные из входного источника становятся доступны (по аналогии с Extract).
  • Операторы: запускают определенные команды (выполни Python-файл, запрос в Hive и т.д.). По аналогии с Transform, операторы занимаются преобразованием данных.
  • Трансферы: переносят данные из одного места в другое (как и на стадии Load).

 

Простой пример

Ниже представлен простой пример того, как объявить DAG-файл и определить структуру графа, используя операторы в Airflow, которые мы обсудили выше:

 

"""
A DAG docstring might be a good way to explain at a high level
what problem space the DAG is looking at.
Links to design documents, upstream dependencies etc
are highly recommended.
"""

from datetime import datetime, timedelta
from airflow.models import DAG  # Import the DAG class
from airflow.operators.sensors import NamedHivePartitionSensor
from airflow.operators.hive_operator import HiveOperator


### You can import more operators as you see fit!
# from airflow.operators.bash_operator import BashOperator
# from airflow.operators.python_operator import PythonOperator

# setting some default arguments for the DAG

default_args = {
    'owner': 'you',
    'depends_on_past': False,
    'start_date': datetime(2018, 2, 9),
}

# Instantiate the Airflow DAG
dag = DAG(
    dag_id='anatomy_of_a_dag',
    description="This describes my DAG",
    default_args=default_args,
    schedule_interval=timedelta(days=1))   # This is a daily DAG.

# Put upstream dependencies in a dictionary
wf_dependencies = {
    'wf_upstream_table_1': 'upstream_table_1/ds={{ ds }}',
    'wf_upstream_table_2': 'upstream_table_2/ds={{ ds }}',
    'wf_upstream_table_3': 'upstream_table_3/ds={{ ds }}',
}

# Define the sensors for upstream dependencies
for wf_task_id, partition_name in wf_dependencies.iteritems():
    NamedHivePartitionSensor(
        task_id=wf_task_id,
        partition_names=[partition_name],
        dag=dag
    )

# Put the tasks in a list
tasks = [
    ('hql', 'task_1'),
    ('hql', 'task_2'),
]

# Define the operators in the list above
for directory, task_name in tasks:
    HiveOperator(
        task_id=task_name,
        hql='{0}/{1}.hql'.format(directory, task_name),
        dag=dag,
    )

# Put the dependencies in a map
deps = {
    'task_1': [
        'wf_upstream_table_1',
        'wf_upstream_table_2',
    ],
    'task_2': [
        'wf_upstream_table_1',
        'wf_upstream_table_2',
        'wf_upstream_table_3',
    ],
}

# Explicitly define the dependencies in the DAG
for downstream, upstream_list in deps.iteritems():
    for upstream in upstream_list:
        dag.set_dependency(upstream, downstream)

Когда граф будет построен, можно увидеть следующую картинку:

Итак, надеюсь, что в данной статье мне удалось максимально быстро и эффективно погрузить вас в интересную и многообразную сферу — Data Engineering. Мы изучили, что такое ETL, преимущества и недостатки различных ETL-платформ. Затем обсудили моделирование данных и схему «звезды», в частности, а также рассмотрели отличия таблиц фактов от таблиц измерений. Наконец, рассмотрев такие концепции как партиционирование данных и backfilling, мы перешли к примеру небольшого ETL джоба в Airflow. Теперь вы можете самостоятельно изучать работу с данными, наращивая багаж своих знаний. Еще увидимся!

 

 

 

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

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

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

loading...

Решения

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

Клиенты

  • Внедрение QlikView в fashion retail, готовое отраслевое решение для fashion retail по аналитике

    Интеграция готового отраслевого решения BusinessQlik for Fashion Retail для:

    Блок задач № 1. Анализ продаж и Анализ Чеков,

    Блок задач № 2. Анализ Товародвижения,      

    Блок задач № 3. Рабочее место Руководителя,

     

    Реализовано более 150 отчетных форм.

  • Газпромнефть
    Единая система фрод-менеджмента - автоматизированная информационная система, предназначенная для автоматизации процесса обработки и анализа данных учета технологических и бизнес-процессов с высокими рисками нанесения ОАО «Газпром нефть» материального и/или нематериального ущерба в результате мошеннических действий в автоматизированных системах.
  • classic-spb

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

  • Система управленческой отчетности (Баланс, Отчет о прибылях и убытках, Дэшборды по показателям отчетности) в QlikView

  • Решения
    • Дистрибуция
    • Розничная торговля
    • Производство
    • Операторы связи
    • Банки
    • Страхование
    • Фармацевтика
    • Лизинг
    • Логистика
    • Медицина
    • Нефтегазовый сектор
    • Сеть ресторанов
  • Продукты
    • 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