для чего в системах класса business intelligence используется хранилище данных
BI-системы: что это и зачем они нужны бизнесу
Статья подготовлена экспертами факультета BI-разработки GeekBrains.
На международных рынках компании-гиганты работают с миллионами, десятками, а кто-то — и с сотнями миллионов клиентов. С помощью интернета обо всех этих клиентах можно собирать самые разные данные: возраст, пол, образование, вкусы, предпочтения и т. д. Анализ этих данных помогает менеджерам ориентироваться в пространстве и времени, планировать спрос, оценивать перспективы развития и прорабатывать стратегии.
Компаниям нужно много данных, и за их хранение, как правило, отвечают администраторы баз данных. На основании анализа данных строятся и проверяются гипотезы для развития бизнеса. Этим занимаются аналитики.
В последнее время эти две группы всё чаще дополняются отделами Business Intelligence — бизнес-аналитики. Эти специалисты приводят сырые, неудобные данные в состояние, пригодное для бизнес-анализа. Сырые данные необходимо очищать от различных выбросов, дублей и других помех. А учитывая их объём, частое обращение к этим данным будет отнимать слишком много ресурсов.
Для изучения бизнес-метрик не нужны вообще все данные. Например, чтобы получить ежедневную динамику новых пользователей приложения, не нужны их id, пол и местоположение. Достаточно сделать таблицу, в которую для каждого дня проставляется количество новых пользователей — оно будет суммироваться. Таблица будет обновляться в нерабочее время, а днём сотрудники смогут работать с нужной статистикой.
Специалисты по BI готовят таблицы агрегированных данных (витрины), строят отчёты на основе полученных витрин (дашборды) и настраивают автоматическое обновление данных в этой системе. От стандартных отчётов дашборд отличается гибкостью и интерактивностью — в нём предусмотрены разные наборы фильтров, параметров и визуализаций. Дашборд можно назвать интерактивной аналитической панелью, где заказчик может просматривать данные в любом интересующем его разрезе.
BI-разработчики не скажут, как повлияет на ваши продажи новый продукт конкурента, но построят систему, где вы сможете проверить это сами.
Основные задачи BI
Сбор данных. BI-системы позволяют строить сложные виды отчётности, где можно объединить в одну таблицу данные из разнообразных источников — базы данных, файлы, онлайн-источники (Google Docs) и т. д.
Очистка и агрегация. Агрегация данных помогает не только избавиться от лишней информации, но и сэкономить память. При работе с большими объёмами данных имеет смысл разделять нагрузку при запросах: на первом этапе агрегируем данные и складываем в таблицу, на втором делаем запрос к этой таблице из дашборда.
Визуализация. BI-инструменты предоставляют множество вариантов визуализации данных: от обычных таблиц до различных Scatter Plots, которые можно применять для практически любого анализа. Нередко BI-инструменты дают возможность связывать различные визуализации друг с другом. Например, есть два графика с одинаковой цветовой легендой. Можно настроить так, чтобы при выделении одного из элементов легенды на первом графике этот же элемент подсвечивался/фильтровался на втором. Такие приёмы существенно ускоряют поиск нужной информации и упрощают анализ.
Быстрый доступ. Быстрый доступ к данным — огромная помощь в оперативном принятии решений. BI-разработчик может использовать единое пространство для дашбордов или другой инструмент — в любом случае доступ к информации значительно упрощается. Можно не ставить задачу аналитику, не писать собственноручно запрос к базе данных — достаточно открыть дашборд и отфильтровать там необходимую информацию. Особенно хорошо, если доступ к данным предоставляется в режиме реального времени.
Распределение доступа. BI-системы обычно располагают различными средствами распределения доступа, что помогает гибко настраивать процесс получения данных. Например, один и том же дашборд можно настроить так, чтобы разным пользователям были видны разные блоки данных.
Хорошо настроенная BI-система снимает с аналитиков и продуктовых команд часть нагрузки и освобождает время, которое они тратят на оперативную отчётность или постоянно повторяющиеся запросы к базе данных. Если формат отчётности зафиксирован, можно построить дашборд в соответствии с ним, и все необходимые данные будут отображаться автоматически. Один дашборд заменит множество еженедельных отчётов. Он будет хранить весь объём данных и заказчик сможет сам отфильтровать нужную ему информацию вместо того, чтобы ждать, пока эти данные ему пришлют.
Из чего состоят BI-системы?
BI-системы можно разделить на три основные составляющие:
Хранилище данных — база с сырыми и агрегированными данными, которые будут источником для аналитики (как для запросов к базе, так и для дашбордов).
ETL-система (Extract, Transform, Load) отвечает за подготовку и сбор агрегированных данных в витрины. Обычно это набор скриптов на языке программирования, каждый из которых берёт сырые данные из одних таблиц хранилища, обрабатывает их и отправляет в другие. Также ETL-система может использоваться для административных задач, например для резервного копирования или регулярного обновления дашбордов. ETL-системы может не быть, если в дашборд надо загружать небольшой объём данных и если не требуется использовать сложные запросы к БД.
BI-сервер/BI-инструмент. Почему через слеш? Потому что есть два основных подхода — поднимать BI-сервер или использовать только BI-инструмент.
BI-сервер — это место для хранения дашбордов, средство визуализации, а также система распределения доступов и автоматического обновления. Сотрудники строят дашборды у себя на компьютере, загружают результат работы на сервер, настраивают расписание обновления и права на просмотр.
BI-инструмент — это программная платформа для построения дашбордов и визуализаций. В этом случае компании экономят: не используют сервер, а строят дашборды на локальных компьютерах, загружают их в общее пространство (например, Git), а обновление дашбордов и отправку информации целевым пользователям настраивают в ручном режиме или с помощью языков программирования.
Хранение отчётов и данных в единой BI-системе обеспечивает прозрачную инфраструктуру и облегчает поиск информации.
О чём нужно подумать при внедрении BI
Проанализируйте источники данных, их объём и тип. Это позволит оценить необходимость разработки ETL-системы и правильно выбрать BI-инструмент.
Выберите BI-инструмент, подходящий вашим целям. Инструменты различаются возможностями визуализации, разнообразием источников данных, ценами и т. д. Самые известные инструменты рассмотрены в статье на Хабре. Также проанализируйте аудиторию будущих пользователей BI-системы, подумайте над распределением прав доступа и шаблонами дашбордов.
Определите необходимость разработки ETL-системы. Она зависит от того, насколько сложны запросы к данным и насколько большой их объём требуется анализировать. Если объём велик, для бесперебойной работы потребуется распределять нагрузку между BI-сервером и ETL-системой. Часто предобработку и агрегацию данных делают в ETL-системе, а в BI строят дашборды, опираясь на уже собранные таблицы. Это ускоряет работу и даёт возможность использовать агрегированные таблицы для нескольких отчётов одновременно.
Подумайте о правильной документации для своих дашбордов, о том, как обучить сотрудников ими пользоваться — например, запишите видеоинструкции.
Если вы хотите освоить BI-системы во всех подробностях, приглашаем на курс GeekBrains. Там подробно разбирается профессия BI-разработчика — от написания запросов к данным до построения всей инфраструктуры.
Заключение
Часто компании не решаются внедрять BI-системы из-за сложности развёртывания инфраструктуры с нуля. Это стандартная проблема смены парадигмы. Вроде и так всё работает, отчётность получаем вовремя — и хорошо. Однако развёртывание BI-систем — это серьёзная инвестиция в будущее компании, помогающая внедрить data-driven-подход — управление, основанное на данных. Его главный принцип: решения нужно принимать, опираясь на исторические и прогнозируемые данные, а не на интуицию и личный опыт. BI-системы внедряются небыстро, но если у всех сотрудников будет доступ к необходимым данным за любой период времени, это упростит принятие стратегически верных решений и многократно окупится. Не измеряешь — не управляешь.
Статья подготовлена экспертами факультета BI-разработки GeekBrains.
На международных рынках компании-гиганты работают с миллионами, десятками, а кто-то — и с сотнями миллионов клиентов. С помощью интернета обо всех этих клиентах можно собирать самые разные данные: возраст, пол, образование, вкусы, предпочтения и т. д. Анализ этих данных помогает менеджерам ориентироваться в пространстве и времени, планировать спрос, оценивать перспективы развития и прорабатывать стратегии.
Компаниям нужно много данных, и за их хранение, как правило, отвечают администраторы баз данных. На основании анализа данных строятся и проверяются гипотезы для развития бизнеса. Этим занимаются аналитики.
В последнее время эти две группы всё чаще дополняются отделами Business Intelligence — бизнес-аналитики. Эти специалисты приводят сырые, неудобные данные в состояние, пригодное для бизнес-анализа. Сырые данные необходимо очищать от различных выбросов, дублей и других помех. А учитывая их объём, частое обращение к этим данным будет отнимать слишком много ресурсов.
Для изучения бизнес-метрик не нужны вообще все данные. Например, чтобы получить ежедневную динамику новых пользователей приложения, не нужны их id, пол и местоположение. Достаточно сделать таблицу, в которую для каждого дня проставляется количество новых пользователей — оно будет суммироваться. Таблица будет обновляться в нерабочее время, а днём сотрудники смогут работать с нужной статистикой.
Специалисты по BI готовят таблицы агрегированных данных (витрины), строят отчёты на основе полученных витрин (дашборды) и настраивают автоматическое обновление данных в этой системе. От стандартных отчётов дашборд отличается гибкостью и интерактивностью — в нём предусмотрены разные наборы фильтров, параметров и визуализаций. Дашборд можно назвать интерактивной аналитической панелью, где заказчик может просматривать данные в любом интересующем его разрезе.
BI-разработчики не скажут, как повлияет на ваши продажи новый продукт конкурента, но построят систему, где вы сможете проверить это сами.
Основные задачи BI
Сбор данных. BI-системы позволяют строить сложные виды отчётности, где можно объединить в одну таблицу данные из разнообразных источников — базы данных, файлы, онлайн-источники (Google Docs) и т. д.
Очистка и агрегация. Агрегация данных помогает не только избавиться от лишней информации, но и сэкономить память. При работе с большими объёмами данных имеет смысл разделять нагрузку при запросах: на первом этапе агрегируем данные и складываем в таблицу, на втором делаем запрос к этой таблице из дашборда.
Визуализация. BI-инструменты предоставляют множество вариантов визуализации данных: от обычных таблиц до различных Scatter Plots, которые можно применять для практически любого анализа. Нередко BI-инструменты дают возможность связывать различные визуализации друг с другом. Например, есть два графика с одинаковой цветовой легендой. Можно настроить так, чтобы при выделении одного из элементов легенды на первом графике этот же элемент подсвечивался/фильтровался на втором. Такие приёмы существенно ускоряют поиск нужной информации и упрощают анализ.
Быстрый доступ. Быстрый доступ к данным — огромная помощь в оперативном принятии решений. BI-разработчик может использовать единое пространство для дашбордов или другой инструмент — в любом случае доступ к информации значительно упрощается. Можно не ставить задачу аналитику, не писать собственноручно запрос к базе данных — достаточно открыть дашборд и отфильтровать там необходимую информацию. Особенно хорошо, если доступ к данным предоставляется в режиме реального времени.
Распределение доступа. BI-системы обычно располагают различными средствами распределения доступа, что помогает гибко настраивать процесс получения данных. Например, один и том же дашборд можно настроить так, чтобы разным пользователям были видны разные блоки данных.
Хорошо настроенная BI-система снимает с аналитиков и продуктовых команд часть нагрузки и освобождает время, которое они тратят на оперативную отчётность или постоянно повторяющиеся запросы к базе данных. Если формат отчётности зафиксирован, можно построить дашборд в соответствии с ним, и все необходимые данные будут отображаться автоматически. Один дашборд заменит множество еженедельных отчётов. Он будет хранить весь объём данных и заказчик сможет сам отфильтровать нужную ему информацию вместо того, чтобы ждать, пока эти данные ему пришлют.
Из чего состоят BI-системы?
BI-системы можно разделить на три основные составляющие:
Хранилище данных — база с сырыми и агрегированными данными, которые будут источником для аналитики (как для запросов к базе, так и для дашбордов).
ETL-система (Extract, Transform, Load) отвечает за подготовку и сбор агрегированных данных в витрины. Обычно это набор скриптов на языке программирования, каждый из которых берёт сырые данные из одних таблиц хранилища, обрабатывает их и отправляет в другие. Также ETL-система может использоваться для административных задач, например для резервного копирования или регулярного обновления дашбордов. ETL-системы может не быть, если в дашборд надо загружать небольшой объём данных и если не требуется использовать сложные запросы к БД.
BI-сервер/BI-инструмент. Почему через слеш? Потому что есть два основных подхода — поднимать BI-сервер или использовать только BI-инструмент.
BI-сервер — это место для хранения дашбордов, средство визуализации, а также система распределения доступов и автоматического обновления. Сотрудники строят дашборды у себя на компьютере, загружают результат работы на сервер, настраивают расписание обновления и права на просмотр.
BI-инструмент — это программная платформа для построения дашбордов и визуализаций. В этом случае компании экономят: не используют сервер, а строят дашборды на локальных компьютерах, загружают их в общее пространство (например, Git), а обновление дашбордов и отправку информации целевым пользователям настраивают в ручном режиме или с помощью языков программирования.
Хранение отчётов и данных в единой BI-системе обеспечивает прозрачную инфраструктуру и облегчает поиск информации.
О чём нужно подумать при внедрении BI
Проанализируйте источники данных, их объём и тип. Это позволит оценить необходимость разработки ETL-системы и правильно выбрать BI-инструмент.
Выберите BI-инструмент, подходящий вашим целям. Инструменты различаются возможностями визуализации, разнообразием источников данных, ценами и т. д. Самые известные инструменты рассмотрены в статье на Хабре. Также проанализируйте аудиторию будущих пользователей BI-системы, подумайте над распределением прав доступа и шаблонами дашбордов.
Определите необходимость разработки ETL-системы. Она зависит от того, насколько сложны запросы к данным и насколько большой их объём требуется анализировать. Если объём велик, для бесперебойной работы потребуется распределять нагрузку между BI-сервером и ETL-системой. Часто предобработку и агрегацию данных делают в ETL-системе, а в BI строят дашборды, опираясь на уже собранные таблицы. Это ускоряет работу и даёт возможность использовать агрегированные таблицы для нескольких отчётов одновременно.
Подумайте о правильной документации для своих дашбордов, о том, как обучить сотрудников ими пользоваться — например, запишите видеоинструкции.
Если вы хотите освоить BI-системы во всех подробностях, приглашаем на курс GeekBrains. Там подробно разбирается профессия BI-разработчика — от написания запросов к данным до построения всей инфраструктуры.
Заключение
Часто компании не решаются внедрять BI-системы из-за сложности развёртывания инфраструктуры с нуля. Это стандартная проблема смены парадигмы. Вроде и так всё работает, отчётность получаем вовремя — и хорошо. Однако развёртывание BI-систем — это серьёзная инвестиция в будущее компании, помогающая внедрить data-driven-подход — управление, основанное на данных. Его главный принцип: решения нужно принимать, опираясь на исторические и прогнозируемые данные, а не на интуицию и личный опыт. BI-системы внедряются небыстро, но если у всех сотрудников будет доступ к необходимым данным за любой период времени, это упростит принятие стратегически верных решений и многократно окупится. Не измеряешь — не управляешь.
Современные Business Intelligence (BI) системы на примере IBM Cognos BI
В современном мире существуют определенные классы программного обеспечения, которое ориентированно в основном на корпоративный сегмент (крупный и средний бизнес) и соответственно не имеет широкого распространения. Но некоторые программные комплексы имеют достаточно интересные функции, которые можно применить не только в сфере мелкого бизнеса, но и в качестве персонального инструмента. Вот об одном из таких программных комплексов и пойдет речь в данной статье.
Примечание
Я являюсь техническим специалистом, соответственно статья имеет более технический уклон. Если есть желание почитать информацию по продукту, ориентированную на бизнес пользователей, то вам на офсайт IBM.
Основная цель этой статьи, показать вам как сделать свой первый «Hello World» (по аналогии с программированием) в IBM Cognos BI.
Также хочу отметить, что я имею большой опыт написания пошаговых инструкций со скриншотами каждого шага. Но эта статья не будет очередной пошаговой инструкцией, здесь я хочу показать концепцию работы с системой, а не сделать еще один мануал.
Что такое BI?
Возможность применения BI системы в качестве персонального инструмента
Сразу становится вопрос, как можно использовать эту систему в качестве персонального инструмента? Отвечу по личному примеру, я использую IBM Cognos BI в качестве инструмента по анализу статистики в своих проектах и инструмента по анализу статистики домашней бухгалтерии.
Тут конечно можно возразить, что-то в духе «я и обычным SQL запросами отлично анализирую статистику» или «встроенных функций Excel вполне достаточно чтобы проанализировать всю домашнюю бухгалтерию», но «все познается в сравнении». Как показывает практика, гораздо проще просто натаскать мышкой нужные элементы данных и получить результат в готовом виде, чем возится с написанием SQL запросов или перенастраиванием функций Excel.
Опять-таки, все написанное это лично мое мнение, с которым вы не обязаны соглашаться.
Архитектура IBM Cognos BI
Этапы работы с системой
Структура тестового источника данных
Перед тем как приступить к реализации вышеописанных этапов, я хочу сказать пару слов об тестовом источнике данных. С одной стороны, структура тестового источника данных относительно простая (как для промышленного хранилища данных) с другой стороны она несколько сложнее чем простой лист Excel. Все данные в источнике являются синтетическими (сгенерированы алгоритмами на основе случайных чисел), из-за этого агрегатные показатели выглядят весьма ровно.
Подключение к источнику данных
В IBM Cognos BI все необходимые параметры для подключения к источникам данных хранятся в специальных объектах системы, которые так и называются «Data Source Connections». Чтобы создать новое подключение, необходимо выполнить несколько простых шагов: зайти на портал IBM Cognos BI, перейти в раздел «Администрирование» («Administration»), открыть вкладку «Конфигурация» («Configuration»), выбрать подраздел «Подключения источника данных» («Data Source Connections») и нажать кнопку «Новый источник данных» («New Data Source») в панели инструментов. Далее появится серия диалоговых окон, в которых будет необходимо задать несколько параметров, таких как название подключения, тип соединения, сервер, логин, пароль и т. д.
Разработка метаданных
Разработка метаданных, это один из самых сложных и ответственных моментов. От качества метаданных зависит, как работоспособность системы (скорость формирования отчетов, корректность сформированных результатов и т. д.) так и удобство разработки отчетов. Но несмотря на вышесказанное, сложность разработки метаданных прямо пропорциональна сложности источника данных. Например, чтобы построить реляционное описание нашего тестового источника данных, достаточно запустить мастер построения метаданных, несколько раз кликнуть кнопку «Next», и метаданные готовы.
Итак, как я уже писал ранее, метаданные – это описание источника данных. В IBM Cognos BI. Фундаментом метаданных являются объекты «Query Subject» и связи между ними. Объект «Query Subject» это синоним «View» из реляционных СУБД. Т. е. в основе «Query Subject» стоит запрос к СУБД, определяющий структуру объекта источника, а связи между «Query Subject» это описание логического взаимодействия между этими запросами.
Для создания метаданных в IBM Cognos BI используется отдельное приложение IBM Cognos Framework Manager (единственное не Web приложение в комплексе IBM Cognos BI). После запуска Framework Manager будет предложено создать новый проект (необходимо будет ввести наименование проекта и его расположение в локальной файловой системе).
Следует понимать, что проект Framework Manager (также именуемый как модель Framework Manager) это набор локальных файлов, с которыми работает локальная программа, а пакет метаданных это результат, который располагается на IBM Cognos BI сервере (если проводить аналогию с программированием, то проект – это исходный код, а пакет – это скомпилированное приложение). На базе одного проекта Framework Manager можно создать несколько наборов пакетов.
Создание и публикация пакета метаданных
После того как метаданные созданы, необходимо сформировать метапакет и опубликовать его на IBM Cognos BI сервере. Как я упоминал ранее, метапакет – это некоторое подмножество метаданных, которое публикуется на сервере и с которым работают все Web приложения комплекса IBM Cognos BI. Настройки метапакета позволяют скрыть или не публиковать некоторые объекты метаданных. Например, в тестовых метаданных есть некоторый «Query Subject» [Country_RegDir], который влияет на логику обработки данных источника (является связующим звеном между страной и региональным директором), но не представляет ценности при разработке отчетов, вот такой объект метаданных имеет смысл скрыть на уровне пакета. Или, например, поля с идентификаторами, их тоже имеет смысл скрыть от пользователей метапакетов.
Создание отчетов (анализ данных)
Вот мы потихоньку и подобрались к самому интересному и регулярному процессу – это создание отчетов. Так сложилось что инструменты для создания регулярных отчетов и инструменты для быстрого анализа данных в IBM Cognos BI одни и те же (несмотря на то что в одних удобнее проводить быстрый анализ, а в других удобнее формировать регулярные отчеты, все они позволяют сохранять свои результаты в виде отчетов).
Лично я предпочитаю для всех BI задач использовать инструмент IBM Cognos Report Studio. Это наиболее универсальный инструмент, позволяющий строить отчеты фактически любой сложности и в тоже время предоставляет относительно удобные инструменты для быстрого анализа данных.
После запуска отчета на выполнение, получится примерно такой результат.
Глядя на получившийся отчет можно смело сказать, что оформлен он откровенно плохо, числа не отформатированы, экономический смысл откровенно сомнителен и т. д. Но все эти недостатки оформления можно убрать путем задания свойств соответствующих элементов настроек, а чтобы экономический смысл был более интересен, можно, например, сделать план/факт анализ.
Например, чтобы сделать отчет, показанный ниже (на готовых метаданных) я, как специалист с опытом, потратил где-то 20-30 минут.
А чтобы его полностью переоформить в темную цветовую схему, я потратил где-то еще 10 минут.
Заключение
Я надеюсь, что в этой статье читатель смог получить общие сведения о BI системах и принципе их работы. Конечно в рамках небольшой статьи невозможно рассмотреть относительно подробно ни один из затронутых аспектов (например, о том, как правильно сформировать метаданные, можно написать целую книгу), но я думаю, что если вы решите попробовать, то эта статья подскажет с чего начать и какого результата ожидать.
Также я совсем не затронул некоторые интересные механизмы и функции (например, механизм представления реляционного источника данных как многомерного), но это из-за того, что количество необходимого материала (минимум теории и минимум практики) потянет на отдельную статью.