Концепция построения универсальной модели данных для бизнес-аналитики

Концепция универсальной модели
для бизнес-аналитики
(КУМБА)
Внедрите силами ваших аналитиков
единую аналитическую архитектуру.
Для быстрой и систематизированной разработки
отчетов любой сложности в любой BI-системе.
Даже если у вас в штате нет опытных BI-разработчиков,
и отсутствует качественное хранилище данных.
Кому полезна КУМБА
Зачем внедрять КУМБА
О чем этот документ
Цель КУМБА - создать удобный аналитический ландшафт
Области применения КУМБА
Стандарты КУМБА можно применять для любых аналитических инструментов
Единая модель данных - основа универсальной архитектуры
Забираем лучшее из из разных топологий
Реляционная топология
Плюсы и минусы реляционной модели
Топология Звезда
Плюсы и минусы Звезды
Как сочетать преимущества реляционной модели и топологии звезда
Почему Звезда, а не Снежинка?
Подготовка данных для сборки универсальной модели
Стандарт подготовки аналитических таблиц
Первичный ключ в каждой таблице
Поле с названием сущности в каждой таблице
Нормализация полей дат
Единый формат ключевых полей
Денормализация справочных таблиц
Одинаковый нейминг ключевых полей во всех таблицах
Уникальные имена для всех неключевых полей
Дополнительные метки для полей измерений и показателей
Нейминг полей не меняется при загрузке данных в BI-систему
Дополнительные концепции подготовки данных
Создание полей-счетчиков
Использование единого нейминга полей в агрегированных таблицах
Построение модели данных топологии Звезда
Восстановление кросс-табличных связей
Каноническая ось дат/времени
Основа документации аналитического слоя
Стратегия внедрения КУМБА
FAQ по применимости КУМБА
У нас сложная структура данных, делать единую звезду - очень сложно
У нас анализируются большие данные, которые никогда не уместить в звезду
Уже есть хранилище со своей структурой, не будем делать другое под звезду
У нас BI нормально работает с реляционной моделью, зачем нам звезда
У нас уже сделано так много отчетов, мы не потянем переезд на звезду
Это что, MDM-система?
Результаты внедрения КУМБА или ее компонентов
Как внедрить КУМБА
Реализация на Loginom
Реализация на Qlik
Варианты поставки
2
2
3
5
6
7
8
9
9
9
11
13
13
15
16
19
19
20
21
22
23
24
24
25
25
25
25
26
27
30
31
33
35
36
36
36
37
37
38
38
39
40
41
42
45
1
Кому полезна КУМБА
ИТ-директорам, которые не хотят быть заложниками одного супер-компетентного
сотрудника, разрабатывающего аналитику. А также иметь гибкость при выборе
аналитических платформ, и значительно облегчить миграцию между ними.
Руководителям направлений, которым нужно внедрить методы управления и
анализа, недоступные в текущих аналитических инструментах. И надежно
масштабировать их в процессе развития направления и расширении штата.
Руководителям команд, внедряющим BI-системы - для стандартизации проектного
производства и снижения рисков утери компетенций из-за текучки кадров. Позволяет
легко и на потоке работать со множеством моделей данных в разных проектах.
Аналитикам, которые хотят иметь больше свободного времени на развитие себя и
своей карьеры, а не закапываться в рутину постоянной переделки отчетов и
поддержания сделанных на скорую руку заплаток.
Зачем внедрять КУМБА
Чтобы выстроить единую архитектуру формирования отчетов, которую можно
легко наращивать. Без необходимости переделывать ранее созданные отчеты. Без
необходимости знать заранее, какие данные с какой структурой вы будете
анализировать через месяц или через год.
Чтобы обеспечить многопользовательскую работу с данными в режиме
самообслуживания и единой точки правды. Если сборкой отчетов в аналитической
системе занимаетесь не только вы (или есть задача вовлечь в работу с данными
бизнес-пользователей), то вам нужна архитектура, в которой аналитик с
минимальными знаниями сможет взять нужные данные для исследования. И эти
данные не будут противоречить тем, которые находятся в отчетах.
Также, если аналитический ландшафт развиваете не только вы один - вам 100%
понадобятся стандарты для обеспечения совместимости работы разных специалистов
и команд. КУМБА даст вам эти стандарты.
Чтобы упростить и даже автоматизировать формирование документации. Любая
аналитическая система требует документации для удобства разработки и
предоставления справочной информации пользователям. Предложенная структура
2
организации аналитических данных позволит облегчить, и даже почти полностью
автоматизировать рутину по описанию доступных данных, и их связей.
Чтобы минимизировать зависимость от аналитических платформ. Предложенная
структура модели данных совместима с минимальными изменениями с любой
аналитической системой. Это позволяет избежать ситуаций, когда слишком полагаясь
на возможности конкретной BI-системы, мы создаем решение, которое сложно
адаптировать под другую систему.
Например, модели данных Qlik могут оказаться несовместимы с Power BI. А модели
данных Power BI могут быть несовместимы с Visiology. И вообще, у вас есть ряд
пользователей, которым удобнее исследовать данные в Excel. Используя КУМБА, вы
можете создать структуру, которую легко мигрировать на любой визуализатор
данных.
О чем этот документ
Здесь приведены основные подходы организации единого аналитического ландшафта.
Этот подход сформировался в результате десятков проектов по внедрению
бизнес-аналитики. Вот цели этого подхода :
1) Ускорить производство проектов;
2) Упростить миграцию между BI-системами;
3) Внедрить единую точку правды для сводных отчетов уровня
топ-менеджмента;
4) Гарантировать качество разработки с минимальным контролем исполнителя;
5) Минимизировать риски необходимости пересобирать аналитику при появлении
новых вводных и источников;
6) Минимизировать усилия по ведению и поддержке документации;
7) Ускорить погружение бизнес-пользователей в работу с аналитическим
решением;
8) Упростить передачу дел между разработчиками при расширении команды или
замене специалистов;
3
9) Снизить порог входа в продвинутые техники построения аналитики для
пользователей без опыта BI-разработки;
4
Цель КУМБА - создать удобный аналитический ландшафт
Евгений Стучалкин, разработчик методологии.
На техническом уровне бизнес-аналитика выливается в
необходимость анализировать данные в большом количестве
взаимосвязанных таблиц
Сложность ландшафта данных со временем только растет добавляются новые источники, внедряются новые сценарии анализа.
Многие BI-инструменты дают возможность
строить аналитику на лету. Но чем больше
отчетов мы делаем без оглядки на
архитектуру, тем больше возникает
проблем, когда таблиц становится больше.
Это выливается в большие
трудозатраты при разработке аналитики.
Может даже потребоваться переделывать
ранее созданные отчеты, или
поддерживать параллельно несколько
веток аналитики.
Как резюме 9-ти летнего опыта разработки
BI-проектов в роли подрядчика, я
сформулировал ряд правил подготовки
данных для аналитики, которые позволяют:
-
Анализировать структуры данных
любой сложности;
-
Без проблем подключать новые
источники;
-
Сделать данные удобными для
многопользовательской работы;
-
Снизить зависимость от конкретных
аналитических платформ.
5
Области применения КУМБА
В первую очередь, данная методология необходима для систематизации разработки
бизнес-аналитики, основанной на множестве таблиц из множества источников.
Включая данные вне корпоративного DWH (если оно вообще у вас есть). На
картинке снизу показана реальная схема данных из 55 таблиц, которая включает в
себя: отгрузки, маркетинг, CRM, финансы, логистику, складские запасы, прогнозы,
планы, выгрузки из внешних источников.
Это не модель, которая загружается полностью в инструменты аналитики. Это набор
таблиц и связей между ними, которые интересны разным подразделениям. Модели
строятся из отдельных частей этой схемы. Но, благодаря КУМБА:
1) Это не занимает много времени у разработчиков. На самом деле, сборка
моделей настолько упрощается, что может быть передана даже
бизнес-пользователям;
2) Модели всегда совместимы между собой, и могут быть дополнены в любой
момент данными из другой модели, или даже объединены;
3) Общий набор таблиц может быть расширен в любой момент, не ломая ранее
6
созданные отчеты;
4) Соблюдение общей целостности аналитики не требует сложной и трудоемкой
документации. Возможность простого внедрения автообновляемой
документации;
5) Простое введение и поддержание единых правил работы с данными, которое
можно развить в аналитическое самообслуживание (бизнес пользователи
смогут сами собирать отчеты без обращения к разработчикам).
Таким образом, КУМБА хорошо подойдет:
1) В проектах консолидации аналитики со сложной структурой таблиц, с
непредсказуемым расширением этой структуры, для синхронизации отчетов
разных департаментов компании;
2) Как основа для внедрения аналитического самообслуживания;
3) Как проектная методология для компаний, внедряющих BI и
сопровождающих клиентов на подрядной основе.
Стандарты КУМБА можно применять для любых аналитических
инструментов
Не важно, используете ли вы западные/отечественные BI-платформы, или кодите все
на Python и визуализируете JS-библиотеками, или предпочитаете собирать отчеты в
Excel через ВПР (но зачем?).
Не важно, есть ли у вас в компании DWH или нет.
КУМБА - это прежде всего свод стандартов, а не функционал конкретной
системы. Более того, применяя КУМБА, у вас будут развязаны руки в выборе и замене
любых компонентов аналитического ландшафта.
Часть данных готовится в Python, а часть в Low-code платформе Loginom? Без
проблем. У вас нет сейчас хранилища, но в будущем оно может появиться? Вы будете
готовы и вам не придется перерабатывать все отчеты под новую структуру данных.
Нужно комбинировать в аналитике данные из DWH и пользовательских источников?
Легко. Хотите перейти с одного визуализатора на другой? Или использовать сразу
несколько инструментов визуализации? Как вам угодно.
7
В этом материале я описываю базовые подходы к подготовке данных, моделированию
данных, и формировании документации. Вы можете внедрять их с помощью любых
удобных инструментов.
Единая модель данных - основа универсальной
архитектуры
В КУМБА мы пляшем от построения модели данных. Казалось бы, почему, если
построение модели - это финальный этап перед визуализацией?
Все потому, что именно модель данных определяет наши возможности решения задач
в визуализаторах. В том числе - совместимость с разными визуализаторами, и
отработка сложных связей между таблицами.
Не все BI-системы умеют работать с реляционными моделями (когда таблицы
связываются между собой напрямую, как в Power BI). Некоторые BI-системы не могут
работать даже со звездой - им требуется единая плоская таблица на вход.
В КУМБА заложен следующий подход относительно этого: модель данных должна
быть приспособлена для визуализации в любой BI-системе с минимальными
изменениями. Модель данных не должна задействовать логики, которая
поддерживается только одним конкретным BI-инструментом.
8
Забираем лучшее из из разных топологий
Реляционная топология
Для задач бизнес-аналитики характерно использование одной из 2-х топологий:
1. Реляционная модель;
2. Звезда/Снежинка.
Реляционная модель подразумевает, что данные разбиты на отдельные таблицы
Иногда на факты и справочники, иногда на более глубокие подсущности. Например,
таблица продаж может состоять из таблицы документов, и таблицы детализации этих
документов по проданным позициям. Таблицы в такой модели соединяются
непосредственно между собой по аналогии с логикой, как в базах данных.
Плюсы и минусы реляционной модели
Плюсы этой топологии в том, что каждая бизнес-сущность находится в своей таблице,
что позволяет иметь карту данных всей компании и понимать, как связаны данные.
Также, такую модель проще строить, пока структуры данных простые. Аналитик просто
соединяет между собой таблички, и строит нужный отчет.
Однако, недостатки этой топологии тоже существенны.
9
Во-первых, ее поддерживают далеко не все BI-инструменты. Даже если брать топ
мировых платформ, то Power BI реляционную модель поддерживает, а вот Qlik уже нет.
Это значит, что аналитику на реляционной модели сложно мигрировать между
инструментами. Также, это затрудняет использование в компании одновременно
нескольких визуализаторов данных (в т.ч. Excel).
Во-вторых, при усложнении структуры данных по мере подключения новых источников
и формирования новых таблиц, реляционная модель будет усложняться вплоть до
нечитаемого состояния.
Сложная модель данных в PowerBI
При добавлении данных в такую модель сложно предсказать, как они будут
взаимодействовать с уже имеющимися показателями и измерениями. Поддержка
такой модели возможна разве что ее разработчиком. Порог входа в поддержку и
доработку такой структуры очень высокий.
Кроме того, при попытках обойти хитросплетения модели, аналитики часто вынуждены
писать сложные формулы показателей в визуальном слое. Что еще сильнее усложняет
структуру аналитического решения и его поддержку.
Дополнительно, по разному организованные реляционные модели могут возвращать
разные результаты показателей для одних и тех-же данных. Что усложняет поддержку
и контроль большого числа разрозненных моделей (когда их делают разные
10
специалисты из разных департаментов).
Топология Звезда
Альтернатива реляционной модели - топология Звезда/Снежинка. В этой схеме
таблицы соединяются между собой через центральный “мост” - таблицу связей. В
зависимости от используемой BI-системы, у звезды может быть несколько вариантов.
Вариант 1: Звезда для систем, поддерживающие двунаправленные связи между
таблицами. Я знаю 2 таких системы: Qlik Sense (View) с его ассоциативным движком,
для которого эта механика является нативной. И Power BI, в котором эта механика
является скорее костылем, и сильно влияет на производительность.
В такой модели центральная таблица содержит только ключевые поля, связываясь
через первичные ключи с таблицами данных.
Вариант 2: Стандартная звезда, поддерживается большинством аналитических
систем. Эта модель подходит для систем с однонаправленными связями. В
центральной таблице, помимо ключевых полей, размещаются поля для расчета мер
(показателей). В лучах остаются справочные поля (измерения, разрезы).
11
Связи смотрят из справочников в центральную таблицу. Таким образом, любой
показатель можно вывести в разрезе любого справочника, если между ними есть
соответствующая связь.
В итоге у нас получается большая таблица фактов в центре. А вокруг нее висят
таблицы-справочники.
Вариант 3: плоская таблица. Да, формально это не звезда. Но если мы соединим
через JOIN оставшиеся справочники с центральной таблицей, по логике работы это не
будет отличаться от Звезды. При этом, визуализацию такой модели потянет абсолютно
любой инструмент.
12
Плюсы и минусы Звезды
Главный плюс звезды - структуры данных любой сложности собираются в
непротиворечивую модель всегда через фиксированный набор шагов. При соблюдении
единых правил, разные модели данных (созданные разными людьми в разных
департаментах) будут работать одинаково.
Минусы топологии звезда: единые правила нужно соблюдать, иначе хаос реляционных
моделей вернется к вам. Правила сборки Звезды нужно соблюдать даже на простых
моделях, чтобы обеспечить будущую масштабируемость решения.
Для формирования Звезды нужно писать громоздкие скрипты.
Также, по схеме звезды невозможно понять, как именно связаны таблицы между
собой. Потому что все связи уходят в центральную таблицу.
Как сочетать преимущества реляционной модели и топологии
звезда
Наш подход в рамках КУМБА заключается в том, чтобы:
1. Подготавливать и хранить данные для аналитики в отдельных таблицах, как если бы
мы собирались строить реляционную модель. Это позволяет упростить подготовку
данных, фокусируясь на формировании таблиц отдельных бизнес-сущностей.
13
2. Использовать конвенцию именования полей, по которой связи между таблицами
определяются автоматически (одинаковый нейминг ключевых полей). Это
упрощает ведение документации, и контроль за целостностью структуры данных (все
не привязанное висит отдельно от схемы). На базе этих мета-данных можно построить
интерактивную схему данных.
3. Для задач бизнес-аналитики, собирать модели топологии Звезда. На стороне
BI-систем, или формируя отдельные таблицы с центрами Звезд в аналитическом
хранилище.
14
Это позволит обеспечить одинаковое поведение моделей независимо от
BI-инструмента, и позволит легко расширять и объединять модели при
необходимости.
4. Благодаря специфике формирования звезды, при которой структура связей любой
сложности всегда формируется через одинаковый набор шагов, использовать
автоматизацию, которая позволит упростить или полностью исключить рутину
формирования моделей топологии Звезда.
5. Вы получаете минимум двукратный прирост в скорости разработки отчетов. И
никаких проблем с несходящимися данными в разных отчетах.
Почему Звезда, а не Снежинка?
Потому что мы можем использовать для каждой таблицы только одну исходящую связь
к центру. А если у нас в центральной таблице появится блок записей, на который будет
ссылаться справочник, который уже ссылается на другой справочник - модель
придется пересобирать.
А так как мы заранее не знаем, когда это может произойти, мы исходим из того, что
каждый используемый справочник должен иметь прямую связь с центральной
таблицей.
15
Подготовка данных для сборки универсальной
модели
В упрощенном виде модель данных Звезда собирается так: поля показателей и
ключевые поля собираются в одну таблицу через конкатенацию (UNION). Поля
справочников стыкуются к получившейся центральной таблице через первичный ключ,
как связь один ко многим (JOIN).
Задача подготовки данных - сформировать набор удобно стыкующихся между
собой таблиц, из которых можно быстро собрать звезду. Кстати, термин “единая
модель данных” не подразумевает, что у вас должна быть одна модель на всю
компанию, в которую сведены все таблицы. Подразумевается, что вы должны
придерживаться единых правил в подготовке данных и сборке моделей.
Чтобы имея несколько разных звезд, иметь возможность в любой момент дополнить их
данными из другой звезды/нового источника, при этом не переделывая уже созданные
на базе этих моделей отчетов.
Также, некоторые BI (Visiology, Pix BI) поддерживают модель данных “Созвездие”. В
Такой модели таблицы показателей соединяются со справочниками, но при этом не
склеиваются в одну большую центральную таблицу. Сквозная аналитика доступа в
разрезе общих измерений полей справочников.
Для этой топологии также важно соблюдать стандарты подготовки данных, чтобы
таблицы легко комбинировались между собой.
16
Подготовленные для модели таблицы составляют аналитический ландшафт. В простом
виде аналитический ландшафт делается так: из источников формируем очищенные,
обогащенные аналитические таблицы. Из который строятся модели данных. И модели
данных подаются в визуализаторы.
Вот пример простейшей аналитической архитектуры.
Аналитическое хранилище для универсальной модели - не обязательно
отдельная структура БД. Это могут быть как оптимизированные файлы, хранимые в
17
формате аналитического инструмента (например, QVD в Qlik, LGD для Loginom). Так и
подготовленные запросы к уже существующему хранилищу, формирующие
необходимый нейминг полей, и выполняющие нужные преобразования. Либо можно
формировать такое хранилище как полноценную базу данных на отдельной СУБД.
Можно (нужно) начать проект с быстро разворачиваемого решения с
минимальной инфраструктурой. И нарастить ее по мере необходимости.
Большая ошибка строить аналитику без формирования аналитического
хранилища. Т.е. когда вы грузите данные из источника прямо в BI, трансформируется
в нем данные, и там же делаете отчеты, без сохранения промежуточных очищенных
таблиц. Такой подход оправдан только для отчетов, которые нужны здесь и сейчас.
Продолжая развивать такое решение, вы рискуете столкнуться с необходимостью его
полной переработки. Кроме того, вам будет очень сложно развивать аналитику в
параллели с коллегами, или дать возможность сторонним пользователям расширять
ваше решение. Чтобы закрепить эту мысль, вот вам аналогия:
Сбор модели данных
Сбор модели данных
без аналитического хранилища
с аналитическим хранилищем
Если вам кажется, что у товарища с камнями на реке все в порядке, то представьте,
что завтра ему дадут еще столько же камней, чтобы дополнить эту композицию. И
сегодня про эти дополнительные камни никто даже не подозревал.
И да, ребенок на картинке с кубиками - отсылка к низкому порогу входа в работу с
моделями Звезда на основе аналитического хранилища. А теперь, давайте
разберемся, как нам превратить таблицы в удобный кубики конструктора.
18
Стандарт подготовки аналитических таблиц
Аналитическая таблица - это готовая к визуализации таблица, лежащая в
аналитическом хранилище, не требующая никаких доработок и преобразований на
стороне инструмента визуализации.
Первичный ключ в каждой таблице
Первичный ключ - это поле, в котором содержится уникальное неизменяемое значение
для каждой строки таблицы. Неизменяемое - значит что если у вас появилась сделка с
ключом 12345, то с этим номером никогда не будет создана другая сделка.
Довольно часто, такие поля могут поступать непосредственно из источника.
LEAD_ID
Budget
CreateDate
Status
User
1
5000
01.01.2023
15:43
Win
Jack
2
6000
02.01.2023
16:37
Win
Jack
3
8000
03.01.2023
14:12
Lost
Tom
Иногда такое поле в источнике получить нельзя по причине его отсутствия (например,
если это данные из Excel с планами продаж, или некий лог событий). В этом случае,
поле первичного ключа нужно создать самому. Здесь может быть 2 подхода:
1) Если вы не планируете ссылаться на этот ключ из других таблиц, то можно
сделать ключ на основе нумерации строк;
2) Если ссылаться все таки планируете, тогда нужно делать составной ключ.
Обычно это соединенные в одну строку значения всех ключевых полей, через
разделитель. Главное, чтобы эта комбинация была уникальна для каждой
строки.
Поле с названием сущности в каждой таблице
Это поле нужно на этапе построения модели. Поэтому имеет смысл создать его
заранее. Кроме того, оно может быть полезно в некоторых автоматизациях, когда
нужно оперировать наименованиями таблиц, но невозможно передать атрибут с
19
именем таблицы.
Entity
LEAD_ID
Budget
CreateDate
Status
User
Leads
1
5000
01.01.2023
15:43
Win
Jack
Leads
2
6000
02.01.2023
16:37
Win
Jack
Leads
3
8000
03.01.2023
14:12
Lost
Tom
Нормализация полей дат
Это служит целям оптимизации, и позволяет потреблять аналитики меньше ресурсов
компьютера при визуализации данных. В частности, справочник-календарь для поля,
содержащего только даты без времени, будет намного меньше, чем для поля с
метками времени. В конце концов, в году только 366 дней максимум. И не менее
31 622 400 возможных меток времени (это только секунды).
Если отметки времени суток важны для аналитики, можете вынести их в отдельное
поле. И также округлить до целесообразного интервала. Например до пяти минут, или
до одного часа.
Entity
LEAD_ID
Budget
CreateDate
Status
User
Leads
1
5000
01.01.2023
Win
Jack
Leads
2
6000
02.01.2023
Win
Jack
Leads
3
8000
03.01.2023
Lost
Tom
Также, если в данных временной период задан текстом (например, январь 2023, Q4
2022, 2021), то имеет смысл преобразовать их в даты первого дня периода
(01.01.2023, 01.10.2022, 01.01.2021 соответственно).
Это позволит использовать поле с датой как ключевое, и присоединить к нему
справочник периодов, что позволит отображать эти данные в любом необходимом
разрезе без переусложнения модели.
20
Единый формат ключевых полей
Если у нас есть справочник, например, Пользователей, где каждому пользователю
сопоставлен идентификатор. А в другой таблице есть пользователь, который
определен не через идентификатор, а через имя.
Entity
LEAD_ID
Budget
CreateDate
Status
User
Leads
1
5000
01.01.2023
Win
Jack
Leads
2
6000
02.01.2023
Win
Jack
Leads
3
8000
03.01.2023
Lost
Tom
То нужно сделать так, чтобы во всех данных пользователь определялся через
идентификатор. Это упростит сбор модели данных, а также позволит использовать
дополнительные аналитические разрезы из справочника в любых связанных с ним
данных.
Entity
LEAD_ID
Budget
CreateDate
Status
USER_ID
Leads
1
5000
01.01.2023
Win
1
Leads
2
6000
02.01.2023
Win
1
Leads
3
8000
03.01.2023
Lost
2
Денормализация справочных таблиц
Если в исходной структуре данных у вас есть справочники, на которые ссылаются
другие справочники для расширения свойств (например, клиенты ссылаются на типы
клиентов, или города), то такие справочники имеет смысл объединить через JOIN для
получения одной таблицы с более полным справочником.
На картинке возможные объединения выделены контуром. Причем справочник городов
можно объединить и в Клиентов, и в Пользователей, чтобы иметь возможность
обращаться к этим атрибутам в привязке к конкретной сущности (город пользователя и
город клиента соответственно).
21
Одинаковый нейминг ключевых полей во всех таблицах
Все ключевые поля во всех аналитических таблицах должны называться одинаково.
На должно быть поля LEAD_ID в одной таблице, и ID_LEAD в другой. Также, имеет
смысл задать ключевым полям префикс, например KEY_, чтобы при дальнейшей
работе с таблицами все ключевые поля удобно сортировались.
Поле сущности тоже можно считать ключевым.
KEY_Entity
KEY_LEAD_ID
Budget
CreateDate
Status
KEY_USER_ID
Leads
1
5000
01.01.2023
Win
1
Leads
2
6000
02.01.2023
Win
1
Leads
3
8000
03.01.2023
Lost
2
Уникальные имена для всех неключевых полей
Все неключевые поля во всех таблицах (поля показателей и измерений) должны иметь
уникальное наименование. Проще всего добиться этого с помощью префиксов сокращенного названия таблицы в 2-4 буквы.
KEY_Entity
KEY_LEAD_ID
LD_Budget
LD_CreateDate
LD_Status
KEY_USER_ID
22
Leads
1
5000
01.01.2023
Win
1
Leads
2
6000
02.01.2023
Win
1
Leads
3
8000
03.01.2023
Lost
2
Дополнительные метки для полей измерений и показателей
Для упрощения понимания роли поля можно добавить в конец неключевым полям
метку _D (Dimension, измерение) для полей-разрезов, и _M
KEY_Entity
KEY_LEAD_ID
LD_Budget_M
LD_CreateDate_D
LD_Status_D
KEY_USER_ID
Leads
1
5000
01.01.2023
Win
1
Leads
2
6000
02.01.2023
Win
1
Leads
3
8000
03.01.2023
Lost
2
Нейминг полей не меняется при загрузке данных в BI-систему
Важный момент: при загрузке данных в BI, важно сохранить наименования полей в их
исходном виде. Чтобы формула продаж sum(LD_Budget_M) работала одинаково в
любой системе, куда загрузятся данные.
23
Дополнительные концепции подготовки данных
Создание полей-счетчиков
Некоторые показатели рассчитываются как арифметические агрегации значений поля.
Сумма, среднее, минимум, максимум, медиана. Однако, также есть и показатели,
которые считают кол-ва значений поля (в т.ч. только уникальных). Логические функции,
к которым относится подсчет количества, работают медленнее арифметических.
KEY_Entity
KEY_LEAD_ID
LD_Lead_count_M
KEY_USER_ID
Leads
1
1
1
Leads
2
1
1
Leads
3
1
2
Можно избежать использование функции count, если завести в таблице, чьи строки мы
хотим считать, поле со значением 1. Сумма по этому полю вернет кол-во объектов в
таблице. У подхода есть ограничение - его нельзя использовать для подсчета не
уникальных полей.
Например, в таблице выше мы не могли бы создать поле-счетчик, сумма по которому
показала бы нам кол-во пользователей в таблице Leads.
Использование единого нейминга полей в агрегированных таблицах
На удобство этого метода нужно смотреть в контексте конкретных сценариев
построения аналитики. Но вот в чем смысл. Когда в компании есть много данных
(например, много транзакций по продажам, 100 000 000 записей), то есть смысл в
качестве аналитической таблицы создать агрегированный вариант.
Чтобы не загружать каждый раз все сто миллионов в отчеты.
В агрегированной таблице продажи будут просуммированны по нужным разрезам, и
получить таблицу не на 100 000 000 записей, а например на 2 000 000 записей.
При этом, нейминг полей в такой таблице оставить таким же как, в исходной таблице.
Т.е. если поле в исходной таблице называлось LD_Budget_M, то в таблице с
24
просуммированными значениями оно тоже должно называться так.
Аналогично с подсчетом кол-ва чеков. Если в исходной таблице есть поле в
LD_Lead_count_M, то в агрегированной таблице поле, которое будет содержать число
кол-ва чеков за период, должно быть такое же название. Это позволит использовать
вам одни и те же названия полей в формулах, что может серьезно унифицировать
синтаксис выражений.
Построение модели данных топологии Звезда
Когда вы закончили подготовку таблиц, то получаете некую структуру данных, но еще
не модель данных. Это набор таблиц с общими ключевыми полями, которые могут
быть собраны в одну или несколько моделей данных.
Модели данных появится, когда вы соберете части этой структуры в звезды, которые
будут использоваться для визуализации данных и сквозной аналитики.
Использование нескольких моделей данных из одного общего дата-сета очень удобно,
т.к. позволяет экономить ресурсы и ограничивать доступные данные для разных
пользователей.
При этом, благодаря единому формату аналитических таблиц, любая модель может
быть легко расширена новыми таблицами. Или даже объединена с другой
25
моделью. Без потери логики связей и поломки синтаксиса выражений.
Главный компонент звезды - центральная таблица связей. В базовом варианте, она
строится как конкатенация (Union) фрагментов аналитических таблиц, которые
содержат ключевые поля и поля показателей. Также, обязательно добавляется поле
с указанием сущности.
В этом примере, поля из таблицы Leads и Plan образуют таблицу Linktable, с общими
ключевыми полями, и раздельными полями показателей.
Leads
KEY_Entity
KEY_Lead_ID
LD_Budget_M
KEY_User_ID
Leads
1
5000
1
Leads
2
6000
1
Leads
3
8000
2
+
Plan
KEY_Entity
KEY_User_ID
PL_Plan_Sum_M
KEY_Plan_ID
Plan
1
15000
1
Plan
2
7000
2
PL_Plan_Sum_M
KEY_Plan_ID
=
Linktable
KEY_Entity
KEY_Lead_ID
LD_Budget_M
KEY_User_ID
Leads
1
5000
1
Leads
2
6000
1
Leads
3
8000
2
Plan
1
15000
1
Plan
2
7000
2
По такой центральной таблице можно запросто визуализировать сумму по полю
бюджет и сумму плана продаж в разрезе пользователей.
26
Оставшиеся поля измерений (_D) остаются в таблицах-лучах вокруг центральной
таблицы, соединяясь по первичному ключу. Таким образом, центральная таблица
является источником для расчета показателей, а также коммутатором между
справочниками.
Как видите, благодаря правильному неймингу полей, этот процесс осуществляется
очень просто, и может быть выполнен даже не-экспертом в аналитических системах.
Поле KEY_Entity используется как параметр в формулах, когда нужно задать
агрегацию показателя по записям конкретной таблицы. Например, если мы захотим
посчитать пользователей, по которым задан план, то показатель будет иметь вид
формулы count(distinct {<[KEY_Entity]={‘Plan’}>} KEY_User_ID) (пример синтаксиса в
Qlik).
Процесс сборки центральной таблицы может выполняться на стороне
ETL-инструмента, с последующим сохранением модели в базу данных, и которой ее
будут брать визуализаторы. Либо внутри инструмента визуализации, если он
позволяет делать такие манипуляции при загрузке данных.
Однако, есть один дополнительный нюанс при построении таблицы связей.
27
Восстановление кросс-табличных связей
Плата за универсальность Звезды - в необходимости особым образом отрабатывать
сценарии, когда таблицы связаны не напрямую, а через другие таблицы. Представим,
что у нас есть 3 таблицы.
В реляционной структуре, не составляет проблем вывести из таблицы Сделки данные
в разрезе полей таблицы Компании. Потому что между ними есть мост в виде таблицы
Контакты.
Однако, если мы последуем правилу формирования центральной таблицы: взять
ключевые поля из каждой таблицы и поставить их друг на друга, то окажется, что мы
больше не можем выводить расчеты в сделках в разрезе полей компаний. Потому что
в записях сделок нет собственного поля CompanyID.
Таблица связей
Сущность
LeadID
ContactID
Сделки
1
3
Сделки
2
4
CompanyID
Контакты
3
9
Контакты
4
10
Компании
9
Компании
10
Это значит, что перед сборкой центральной таблицы связи нужно восстанавливать.
Это делается по правилу:
1) Если в таблице A есть ключевое поле, которое не является первичным ключом;
2) И оно ссылается на первичный ключ таблицы B, в которой есть ключевые поля,
отсутствующие в первой таблице;
28
3) То тогда в таблицу A нужно приджойнить отсутствующие ключевые поля из
таблицы B по первичному ключу таблицы B;
4) И так для каждого уровня связей в каждой таблицы модели.
Можно решать эту задачу двумя способами:
Восстанавливать связи на этапе подготовки данных, до построения моделей.
Плюс подхода - вы получаете готовые кирпичи для сбора модели. Но есть и минус.
Потребность в восстановлении связей зависит от того, какие таблицы анализируются в
модели. Если из примера выше убрать таблицу Компании, то этим и не нужно было бы
заниматься.
Кроме того, когда аналитический ландшафт будет насчитывать десятки таблиц,
записывать в каждую из них все возможные варианты связей - избыточное решение,
которое к тому же будет сложно поддерживать.
Восстанавливать связи на этапе сборки центральной таблицы. Универсальный
вариант с точки зрения сложности структуры, т.к. восстановление связей делается для
конкретных моделей. Я придерживаюсь этого подхода.
Минус подхода - этим нужно заниматься, это нужно поддерживать, это не доверишь
бизнес-пользователям, это источник потенциальных разночтений при составлении
моделей разными аналитиками.
Поэтому мы в BI2BUSINESS разработали решение для автоматической генерации
моделей, которое можно внедрить у вас, и убрать одну из самых ресурсоемких рутин в
построении единого аналитического ландшафта.
В чем разница работы с генератором и без? Без генератора, конструирование моделей
данных является прерогативой архитекторов данных. С генератором, можно передать
этот процесс на сторону бизнес-пользователей, и в целом сэкономить время на
разработку и поддержку моделей, а также избежать ошибок человеческого фактора.
Каноническая ось дат/времени
Разные системы визуализации по разному работают с расчетами показателей в
разрезе дат. Некоторые системы могут без проблем на одной временной оси вывести
значения, которые агрегируются по разным полям дат.
Однако, также существуют системы, где это не возможно (например, Qlik Sense). Эту
29
ситуацию можно обойти, используя особое ключевое поле - каноническую дату. Смысл
в том, что поля дат также отмечаются как ключевые, и помещаются в центральную
таблицу связи. За счет такой структуры, любая система визуализации сможет
отобразить показатели из разных таблиц на одной временной оси.
Linktable
KEY_Entity
KEY_Lead_ID
LD_Budget_M
KEY_Date
Leads
1
5000
01.01.2021
Leads
2
6000
02.01.2021
Leads
3
8000
02.01.2021
PL_Plan_Sum_M
KEY_Plan_ID
Plan
01.01.2021
15000
1
Plan
01.01.2021
7000
2
Однако, бывают ситуации, когда одна таблица содержит несколько полей дат.
Например, таблица сделок содержит дату создания и дату закрытия.
Leads
KEY_Entity
KEY_Lead_ID
LD_Budget_M
KEY_User_ID
LD_CreateDate
LD_CloseDate
Leads
1
5000
1
01.01.2021
04.01.2021
Leads
2
6000
1
01.02.2021
05.02.2021
Leads
3
8000
2
01.03.2021
В этом случае, таблицу фактов перед добавлением в центральную таблицу нужно
развернуть, сделав в ней единое поле дат. а также поле KEY_Date_type, которое будет
содержать исходное наименование поля даты.
Leads
KEY_Entity
KEY_Lead_ID
LD_Budget_M
KEY_User_ID
KEY_Date_type
KEY_Date
Leads
1
5000
1
LD_CreateDate
01.01.2021
Leads
2
6000
1
LD_CreateDate
01.02.2021
Leads
3
8000
2
LD_CreateDate
01.03.2021
Leads
1
5000
1
LD_CloseDate
04.01.2021
Leads
2
6000
1
LD_CloseDate
05.02.2021
30
При этом, поле KEY_Date_type используется как параметр в формулах, для
управления сценарием агрегации.
Так, выражение sum({<[KEY_Date_type]={‘LD_CreateDate’}>} LD_Budget_M) (пример
для Qlik) выведет нам сумму бюджета сделок на дату создания сделок.
В генератор моделей данных BI2BUSINESS такое преобразование выполняется
автоматически, в момент формирования модели.
Основа документации аналитического слоя
Документация - это бесконечная история. Самая сложная часть в документации
аналитического ландшафта - это поддерживать информацию о структуре связей всех
таблиц. Однако, если вы соблюдали нейминг ключевых полей по предложенному
стандарту, вам открывается возможность автоматизировать построение карты данных.
Для этого вам нужно:
Вести реестр таблиц на основе значений в поле KEY_Entity. При этом, в обязательном
порядке нужно указывать поле, являющееся первичным ключом. Можете добавить в
описание источников и содержимого таблицы.
Для полей показателей и измерений пишем отдельные описания, зачем они нужны.
31
Чтобы упростить сбор такого реестра,
рекомендуется обеспечить выгрузку списка
полей и таблиц в ETL-инструменте, который
вам эти таблицы готовит. Вы можете
выгружать список в табличные файлы, или в
базу данных.
Самое главное - чтобы вы вели справочник
названий таблиц и их первичных ключей.
С помощью этого справочника, и списка всех
полей в таблицах, можно создать
интерактивную карту данных в доступном
инструменте визуализации.
Плюс подхода в том, что вы сможете актуализировать структуру связей данных с
минимальными усилиями. На самом деле, благодаря единому неймингу ключевых
полей, для визуализации структуры достаточно выгрузить список полей и таблиц.
Обогащенные сведения можно писать по желанию в удобном вам виде.
Пример интерактивного каталога,
реализованного как дашборд Qlik Sense
Использование интерактивной карты данных не только сократит время на составление
и поддержание документации в актуальном состоянии. Но и позволит создать
отличный портал для бизнес-пользователей, где они смогут узнать, какие данные
32
доступны для аналитики, и как они связаны. Заодно, потренируются работать с
интерфейсом системы визуализации.
Предложенный вариант является базовым. Вы можете нарастить и видоизменить его
по своему усмотрению. Если вы будете соблюдать условие не изменять наименования
полей в системах визуализации, скорее всего вы сможете выгрузить мета-данные об
отчетах (например, в Qlik Sense или Visiology). И сопоставив название полей в
формулах показателей со справочником полей, сможете построить в документации
связь между аналитическим слоем и списком отчетов.
Стратегия внедрения КУМБА
Для обеспечения эффективности, КУМБА нужно внедрять итерационно. Имеет
смысл выбрать для старта одну область, в которой внедрение самообслуживания даст
быстрый результат в плане экономии на операционке, или за счет ускорения
тестирования гипотез. С каждой итерацией, структура будет нарастать, охватывая все
больше аспектов бизнеса и подразделений. Итерационность даст быстрый результат и
высокий уровень удовлетворенности сотрудников.
33
КУМБА можно внедрять как поверх имеющейся аналитической архитектуры, так
и формировать архитектуру с нуля. Если у вас уже имеется корпоративное
хранилище или другие источники данных, то можно без проблем переиспользовать их,
подстроив под стандарт.
КУМБА можно пилотировать как проект для одного подразделения, и
масштабировать на всю компанию. Хотя методика не имеет ограничений по кол-ву
таблиц и департаментов, первоначальное внедрение можно начать с одного участка,
не опасаясь что при масштабировании придется проводить рефакторинг решения.
FAQ по применимости КУМБА
У нас сложная структура данных, делать единую звезду - очень
сложно
У нас нет цели построить звезду для всех данных компании. Наша цель - превратить
аналитические таблицы в совместимые элементы. Из которых бизнес-пользователь
или разработчик по простым, всегда одинаковым правилам сможет собрать нужную
модель из тех таблиц, по которым надо построить аналитику.
Т.е. у вас будет несколько (сколько угодно) звезд, созданных по единым стандартам.
Каждая из которых может быть легко расширена данными другой модели.
У нас анализируются большие данные, которые никогда не
уместить в звезду
Допустим, у вас есть транзакционная таблица на триллион строк. И даже не одна. В
этом случае, для использования в рамках звезды можно формировать агрегированные
представления таких таблиц. Зачем вам загружать в аналитику сотни миллионов строк
сырых данных, если в отчете выводится анализ фактов в разрезе месяцев и
укрупненных категорий?
Такие агрегации отлично укладываются в задачи по консолидации аналитики, когда
важнее не детализация, а охват (показать в одной модели и финансы, и маркетинг, и
логистику, и продажи).
При этом, многие BI-инструменты позволяют на основе таких агрегированных
представлений загружать детализированные данные ограниченной выборкой (ROLAP
в целом, ODAG в Qlik, Direct Query в Power BI). Т.е., сначала аналитик выбирает месяц
34
и клиента, а только потом подгружаются его транзакции. Кроме того, можно работать с
топологией Созвездие, когда гигантская центральная таблица не формируется (если
ваша BI-система это позволяет)
Уже есть хранилище со своей структурой, не будем делать
другое под звезду
Вам не потребуется перестраивать хранилище. Для задач КУМБА, можно (и нужно)
использовать те данные, которые уже подготовлены у вас. При этом, можно
трансформировать эти данные в необходимый формат во время загрузки в
аналитический инструмент. Например, загружая данные через запрос
переименованием полей, или дополнительными джойнами.
Хранение центральных таблиц звезд может не потребоваться, если их может
формировать ваш аналитический инструмент (прежде всего, имеется в виду
возможность сделать Union ключевых полей и полей показателей при загрузке
данных). Если у BI-системы такой возможности нет, то придется формировать
центральные таблицы с помощью ETL-инструмента, и хранить их в общей БД. Но это
никак не затрагивает уже имеющуюся у вас структуру таблиц.
У нас BI нормально работает с реляционной моделью, зачем
нам звезда
Возможно, вы используете инструмент, который хорошо работает с реляционными
моделями (Power BI). Однако, он может быть доступен не всегда (другая компания другой BI). Или вам, как архитектору, может потребоваться обеспечить работу
нескольких BI-систем одновременно, и вы не хотите волноваться за то, что вам
придется поддерживать несколько разных логик построения отчетов.
Звезда - это единственная топология для сложных структур данных, с которой по
одинаковым правилам сможет работать практически любой BI-инструмент. А значит,
что внедрив звезду, вы сможете очень сильно снизить свою зависимость от
конкретного вендора, и легко мигрировать между платформами аналитики.
Действительно, подготовка данных для звезды подразумевает, что мы зашиваем
логику связей непосредственно в таблицы с данными. Чтобы потом во время сбора
модели руководствоваться простыми едиными правилами. Этот процесс может быть
трудозатратным. Поэтому мы предоставляем вам не только методологию, но и
35
автоматизационные инструменты, которые сократят, а в некоторых случаях полностью
исключат необходимость заниматься громоздкой проектировочной рутиной.
У нас уже сделано так много отчетов, мы не потянем переезд на
звезду
Поэтому внедрение этой топологии нужно начинать с области задач, которые пока не
решены в текущей архитектуре. Задача должна быть не очень объемной, чтобы можно
было достичь результатов в короткие сроки. В то же время, после ее решения вы
получите инфраструктуру, на которую можно будет перенести часть уже существующих
отчетов с минимальными затратами времени (или даже отдать это на откуп
самообслуживанию).
Создавая новые отчеты на звезде, вы также формируете ландшафт для быстрого
переноса старых отчетов. Кроме того, не все старые отчеты вам будет нужно
переносить. Вы можете удивиться, как много из них уже не востребовано в данный
момент ;)
Это что, MDM-система?
Это не MDM-система. MDM в парадигме КУМБА - это один из возможных источников
источников данных. Который используется наряду с другими: учетными системами
компании, облачными сервисами, пользовательскими данными (прогнозы / расчеты /
выгрузки из разных источников вне IT-контура компании). Задачи бизнес-аналитики
всегда шире, чем работа с единственным супер-сертифицированным источником, как
MDM.
Новые источники и данные появляются регулярно. Задачи по аналитике формируются
спонтанно и требуют быстрой реализации. КУМБА позволяет привнести порядок в
высоко динамичные процессы работы с данными, и не задушить все регламентами,
растянув сроки реализации с нескольких дней до недель и месяцев. Без
дополнительных сложных технических средств.
Но при этом, остается возможность усиления механик контроля там, где это
необходимо.
36
Результаты внедрения КУМБА или ее
компонентов
-
Эффективная поддержка одним разработчиком десятков моделей для разных
подразделений и компаний. Можно вернуться к решению через несколько
месяцев и не испытывать проблем с пониманием, как оно работает;
-
Экономия времени на разработку аналитических решений с применением
генератора моделей - около 50%;
-
Включение в работу аналитиков с нулевым опытом работы в BI. Через 4 дня
обучения, аналитик без опыта в BI самостоятельно создает модели наравне с
архитектором, без риска несовместимости;
-
Построение детальной, легко поддерживаемой документации.
Михаил Сирик, Datanomix. Экономия времени в проектной разработке: 70%
Мы опробовали генератор на нескольких доменных
моделях, например модель закупок одного из заказчиков
состояла из 21 таблицы. Генератор быстро и качественно
преобразовал её в универсальную модель, сгенерировав
понятный и чистый код создания таблицы связей.
Генератор активно развивается, внимательное отношение к
требованиям пользователей, формируемое коммьюнити
вокруг данного инструмента позволило выпустить 4 версию генератора и гарантирует
большой успех в будущем.
Евгений Скребанов, Conson. Экономия времени в проектной разработке: 80%
В моей работе существует отдельный класс задач в
скрипте, когда выполняю постоянно одни и те же действия,
или строю плюс-минус однотипные модели данных.
Решение BI2BUSINESS буквально позволило мне сократить
для таких задач время на разработку с 4-8 часов до 1-2
часов при исходной разработке. В процессах же поддержки,
37
внесение изменений занимает от минут до часа. Не могу не отметить этот факт, и как
следствие, высвобождение реального времени.
Алексей Голубев, СБЕР. Интерактивная визуализация аналитического ландшафта
превосходит классическую базу знаний
Основной задачей использования карты данных -являлось
описать файловое хранилище (qvd) и связи между ними в
удобном формате. Часто для этого использует
корпоративный стек Atlassian, однако я сразу был противник
данного решения, т.к. показывает практика мало кто
использует и применяет корпоративную базу знаний (КБЗ).
Основным отличием от решением КБЗ, считаю
интерактивный режим просмотра, с использованием различных группировок и
активных фильтров. В целом решение получилось более гибким, user friendly для
восприятия и наглядным для анализа взаимосвязей.
Как внедрить КУМБА
Цель BI2BUSINESS - передать компетенции построения единого аналитического
ландшафта вашим специалистам. Чтобы у вас были максимально развязаны
руки в реализации аналитических задач.
Как и говорилось в самом начале, вы можете реализовать эту концепцию на любом
технологическом стеке. При этом, если стоит задача развернуть эту инфраструктуру в
максимально быстрые сроки, то у BI2BUSINESS есть готовые варианты:
1) Развертывание с Loginom, как ETL-инструментом. При этом экспресс-анализ
данных в сводных таблицах будет доступен внутри Loginom. А для
визуализации в дашбордах нужно будет выбрать подходящий вам инструмент.
Данные, подготовленные в Loginom можно использовать в любой другой
системе.
2) Развертывание с Qlik Sense. Подготовка данных, построение моделей,
визуализация и каталог данных реализуется средствами Qlik Sense. Данные,
подготовленные Qlik, можно использовать только пользователям с лицензией
Qlik.
38
Реализация на Loginom
Поставляется в виде библиотеки компонентов, решающей задачи:
1) Автоматизация контроля соблюдения стандартов КУМБА при подготовке
данных;
2) Формирование мета-данных в формате, пригодном для визуализации
интерактивной карты данных;
3) Помощь в построении сложных моделей данных, через формирование
инструкций по сборке моделей, с возможностью полной автоматизации, при
условии хранения итоговых данных в единой базе.
Библиотека компонентов
Пример аудита соблюдения стандартов КУМБА при формировании
аналитической таблицы
39
Рекомендации по сборке модели данных. Можно сконвертировать в SQL-запросы.
Соответствует концепции импортозамещения и санкционной безопасности. Также, у
Loginom есть множество готовых инструментов для анализа качества данных,
выявления и устранения аномалий.
-
Loginom обеспечивает высокую производительность в работе с большими
объемами данных;
-
Loginom не запирает данные внутри себя, и допускает их использование в
других аналитических и учетных системах. Обмен данными возможен как через
промежуточные базы и файлы, так и в формате запросов/ответов
Web-сервисов;
-
Loginom дает удобные инструменты для самообслуживания, позволяя
аналитику решить свои задачи без взаимодействия с IT-отделом.
Однако, Loginom не дает функционала для построения интерактивных визуализаций.
Возможности интерактивных отчетов ограничиваются сводными/плоскими таблицами,
и статическими графиками. Если этого не достаточно, то для визуализации данных
нужно выбрать дополнительный инструмент. Подходы, заложенные в КУМБА,
позволяют использовать для визуализации любую BI-систему.
Реализация на Qlik
Поставляется в виде подпрограмм и шаблона приложения, которые формируют
мета-данные и интерактивную карту данных. Также, есть механизмы формирования
описания происхождения данных (data lineage).
40
Пример каталога данных
Также, в комплекте поставляется генератор моделей данных, который позволяет на
основе каталога сформировать любую модель, с любой сложностью связей без
написания скриптов, и с соблюдением лучших стандартов разработки на Qlik. Этот
подход не только ускоряет производство дашбордов, но и обеспечивает единообразие
и взаимосовместимость любого количества моделей данных без избыточного
контроля.
41
Процесс формирования модели: отбор данных в каталоге - получение скрипта визуализация.
Также, в комплекте поставляется конструктор выражений, облегчающий написание
формул с анализом множеств, заменяя ручной ввод выражений на отбор элементов с
помощью мышки.
Конструктор выражений, встроенный в приложение Qlik
Это решение позволяет построить всю аналитическую инфраструктуру в рамках
одного продукта. Однако:
-
Использование подготовленных в Qlik данных другими системами будет сильно
ограничено.
-
Встроенные возможности Qlik по аудиту качества данных также невелики по
сравнению с Loginom.
-
Производительность Qlik в операциях загрузки и преобразования данных в
среднем ниже чем в Loginom (особенно в операциях группировки, разница в
несколько раз).
-
Также, в настоящее время вы не можете официально приобрести лицензии Qlik
в Российской Федерации.
42
Варианты поставки
Комплект поставки модулей КУМБА включает в себя:
1) Модули КУМБА для Qlik или Loginom;
2) Тикетную техническую поддержку;
3) Доступ на обучающий портал на время действия технической поддержки: вы
легко обучить столько сотрудников, сколько необходимо. Без необходимости
организации тренингов;
4) Обновления компонентов.
Дополнительно можно заказать услуги:
1) Регулярного аудита проекта;
2) Разработки технического задания;
3) Развертывания, настройки и администрирования систем Loginom и Qlik.
Формат работы предполагает, что мы передаем вам инструментарий, учим с ним
работать, развиваем и улучшаем инструментарий, обеспечиваем преемственность и
совместимость работы, выполненной вашими разными сотрудниками . А также
консультируем по вопросам “как сделать лучше с архитектурной точкой зрения” и “а
все ли правильно сделано в проекте”.
Разработка отчетных форм и процессов подготовки данных ложится на сторону ваших
специалистов.
По интересующим вопросам и демонстрациям, обращайтесь по контактам:
Евгений Стучалкин
Email: es@bi2business.ru, stuchalkin@gmail.com
Telegram: https://t.me/stuchalkin
43