Привет, Хабр! Пришло время поговорить о пути данных от источника, где они возникают, до представления, в котором их удобно анализировать. Сейчас все мы работаем в среде, в которой скорость подготовки данных для их использования может стать конкурентным преимуществом. Давайте разберемся, как осуществляется моделирование данных в SAP BW/4HANA, насколько это быстро и удобно, и позволяет ли компаниям извлекать из этого выгоду.

Но сначала немного истории, а потом на примере всем небезразличной темы футбола разберем практические шаги в системе.

В 1998 году была представлена первая версия продукта компании SAP для отчетности, анализа и хранения данных под названием Business Warehouse Information System. Основная идея создания была в реализации более простого и эффективного хранения данных с особым фокусом на данные ERP-системы SAP. С тех пор решение прошло путь от версии 1.2A до BW/4HANA, став значимым компонентом для построения хранилищ данных для тысяч компаний по всему миру.

Те изменения, которые получило SAP BW за время своего существования, были ответом на вызовы разных этапов развития хранилищ данных. Это требования к функциональности, производительности, объемам данных для анализа. Например, переход SAP BW от традиционных к резидентным (In-memory) базам. Фактически, это движение к скорости обработки выросших объемов данных и решению с помощью BW практических бизнес-задач. Это особенно актуально сейчас, когда бизнес ожидает от IT применения новых требований в максимально сжатые сроки. Это не прихоть, а условия, которые диктует конкурентная среда для нормального функционирования бизнеса и его развития.

Эволюция в SAP BW/4HANA коснулась ставшую классической для BW архитектуру LSA (отлично описано вот здесь). Она получила своё развитие в парадигме LSA++. LSA++ в SAP BW/4HANA предоставляет больше технических возможностей для использования виртуальных уровней, чем в предыдущих решениях. Базовые аспекты новой архитектуры – описание объектов и уровней – представлены в конце статьи.

Давайте на практике наглядно разберем реализацию архитектуры LSA++. В качестве примера построим поток данных для истории матчей Чемпионатов мира по футболу с самого первого турнира, проходившего в Уругвае с 13 по 30 июля 1930 года.

В качестве источника исходных данных мы использовали .csv файл со статистикой прошедших матчей – датой, годом, этапом, командами-участниками, счётом, стадионом и количеством зрителей, присутствующих на матче. Вот так, на примере матчей этапа плей-офф замечательного Чемпионата мира 2018 года, прошедшего в России (помните Никольскую тем летом? :)), выглядит набор исходных данных (рис. 1).

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

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

Сначала мы создадим инфо-объекты – признаки (Characteristic) и показатели (Key Figures) . Это такие базовые объекты – строительный материал, на которых строится большинство объектов в BW.

При создании этих объектов нужно указать описание данных – тип, длину, при необходимости, наличие мастер-данных, иерархий, атрибутов для признаков (рис. 2).

Для показателей указываем тип данных, тип агрегации, свойства (рис. 3).

В результате получается такой набор (рис. 4а и 4б).

В SAP BW/4HANA шаг по созданию инфо-объектов опциональный. Инфо-провайдеры можно моделировать как с помощью инфо-объектов, так и с помощью полей. Помните, чуть выше мы рассказывали, что можно использовать объекты, смоделированные на полях, что позволяет существенно снизить временные затраты на их создание? Но в этой статье мы не будем рассматривать этот сценарий. Несмотря на то, что создание инфо-объектов требует дополнительных временных затрат, мы выбрали вариант с их использованием, потому что именно он даст более полное представление о процессе моделирования. Относительно моделирования на полях, использование инфо-объектов предлагает ряд преимуществ: поддержка работы с иерархиями, атрибутами, некумулятивными показателями, агрегация исключения и т.п.

Итак, у нас готовы все необходимые инфо-объекты, можем переходить к созданию объекта для хранения данных (инфо-провайдера). Мы будем использовать ADSO (рис. 5).

Наполняем его ранее созданными инфо-объектами, определяем ключи (рис.6).

Вы, наверное, обратили внимание, что мы не создавали признаки для характеристик времени, но в нашем ADSO присутствуют календарный день (0Calday) и календарный год (0Calyear). Для многих распространённых сущностей как признаков, так и показателей, они идут «из коробки». В BW календарные периоды, единицы измерения, валюты и т.п. можно не создавать, об этом уже позаботились разработчики SAP.

Итак, объект для хранения данных готов. Теперь нам нужно подготовить для него источник – набор логически связанных полей в плоской структуре (структуре извлечения) или в нескольких плоских структурах (для иерархий, но это не наш пример), который предназначен для доступа и передачи данных в BW. Выбираем исходную систему. В нашем случае это плоский файл (Flat file) и создаём источник (рис. 7).

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

Источник готов, теперь требуется связать его с целью передачи данных, ранее подготовленным ADSO. Для этого создадим поток, описание того, как объекты соединяются друг с другом для передачи данных (рис. 9).

Для построения потока данных используется графический интерфейс, в котором объекты добавляются методом drag and drop. Мы добавляем источник (исходная система привязана к нему и подтягивается автоматически) и цель данных. Чтобы соединить объекты в поток, нужно просто протянуть стрелку от одного объекта к другому (рис.10).

Когда объекты связаны, необходимо настроить правила, по которым содержимое полей источника должны быть «уложены» в цель. Для настройки этих правил используется объект «Трансформация». На изображении цели данных есть соответствующая пиктограмма, и мы ей воспользуемся (рис. 11).

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

В нашем примере всё просто, поэтому эти элементы остаются с настройками по-умолчанию, а мы переходим на вкладку «Правила». Здесь методом drag and drop производится связывание полей, при необходимости можно задать правила для каждой связи: прописать формулу, установить константу для поля в цели данных и т.п. (рис. 13).

Теперь нам требуется создать объект, позволяющий запустить передачу из источника в цель – процесс переноса данных (DTP - Data Transfer Process). Он так же создаётся на экране потока данных нажатием на пиктограмму справа от уже знакомой нам «Трансформации» (рис. 14).

Процесс переноса данных и трансформация всегда идут парой, без трансформации создать процесс нельзя, а без процесса нельзя запустить передачу. Процесс переноса данных позволяет задать параметры передачи данных между объектами, участвующими в трансформации (рис. 15).

Здесь же, на верхней панели расположен инструментарий запуска и мониторинга выполнения загрузки данных.

У нас всё готово, можно запускать загрузку данных из источника в ADSO (рис. 16).

Интерфейс позволяет выбрать вариант запуска: диалог или отладка (Debugging). Возникают ситуации, когда требуется по шагам проанализировать процесс загрузки, чтобы понять, почему в ходе процесса возникают ошибки. Режим отладки предназначен как раз для этого (рис. 17).

В нашем примере всё просто, отладка не нужна, запускаем обычный режим. Если, вдруг, возникнут ошибки, система нас об этом проинформирует.

Запрос загружен успешно и предлагает ознакомиться с монитором запроса (рис. 18).

Здесь приведена общая информация по процессу загрузки. В случае возникновения ошибок, в мониторе будет приведён их перечень с указанием этапа возникновения (рис. 19).

Для того, чтобы данные стали доступны для использования в отчётности или дальнейшем стейджинге с их физической передачей, запрос в ADSO нужно активировать. Для этого из монитора процесса переноса данных переходим в администрирование цели данных (рис. 20).

И выполняем активацию загруженного запроса данных (рис. 21).

Запрос активирован без ошибок, об этом сигнализирует зелёный индикатор в графе «Act.». Это значит, что загруженные данные в ADSO готовы для использования в отчётности. Здесь можно было бы остановиться, ведь над ADSO можно создавать запросы и, в отличии от версий BW на реляционных базах, это не возбраняется, а также прекрасно и быстро работает.

Но для того, чтобы полностью раскрыть архитектуру LSA++ нужен виртуальный провайдер (Virtual provider). Помните, на схеме в описании архитектуры этот тип объекта обозначен как обязательный?

Чтобы сценарий с виртуальным провайдером стал интереснее, мы повторили пройденный ранее путь и создали дополнительный ADSO, в который загрузили данные стадионов, на которых проходили матчи Чемпионата мира: город, где расположен стадион, и его вместимость. Получился вот такой объект (рис. 22).

Теперь можно создавать Composite provider, один из типов виртуальных провайдеров уровня Virtual Data Marts (рис. 23).

Чтобы дополнить статистику матчей Чемпионатов мира данными стадионов, мы соединяем наши ADSO с помощью Left Outer Join по полю ZSTAD – Стадион.  Оно есть в обоих объектах.

Посмотрим, что получилось. Просмотр данных доступен на уровне любого инфо-провайдера, прямо из его меню (рис. 24).

То, что надо! Вот мы и закончили моделирование – вишенкой на нашем слоёном торте стал Composite provider. Но давайте сделаем финальный штрих и создадим Query – запрос над этим объектом, который в дальнейшем можно использовать как источник для подключения BI-инструментов (рис. 25).

Query описывает структуру данных нашего провайдера для отчёта. Мы настраиваем, какие поля будут отображаться в строках, в столбцах, как будут представлены результаты. При необходимости в меню отчёта настраиваются различные расчёты и пересчёты валют и т.п.

Query готов! Смотрим, что получилось (рис. 26).

Давайте настроим фильтр на финальные матчи и отсортируем их по нисходящей по годам (рис.  27).

Сколько прекрасных эмоций скрыто за каждой строкой этого отчёта для любителя футбола! На создание такой аналитики уходит примерно пара-тройка часов, а эмоции и воспоминания от такого события остаются с нами на всю жизнь!

В заключение статьи немного теории по LSA++. По сравнению с LSA новая архитектура более гибкая, менее затратная с точки зрения физического хранения данных, позволяет существенно ускорить time-to-market за счёт оптимизации количества существующих объектов хранилища, архитектуры и упрощения моделирования.

Для моделирования используется 4 типа объектов:

InfoObject – самые маленькие единицы в BW. Используя их, информация отображается в структурированной форме, что необходимо для построения инфо-провайдеров. Инфо-объекты с мастер-данными (атрибутами или текстами) также могут быть инфо-провайдерами (если есть в запросе).

Advanced DataStore Object (ADSO) – это новый тип объектов, появившийся в версиях BW на HANA. ADSO является центральным инфо-провайдером для хранения и консолидации данных в BW. Это значит, что объект может предоставлять данные для отчётности. ADSO может содержать как инфо-объекты, так и поля, что позволяет загружать данные в BW без необходимости присвоения инфо-объектов. Он хорошо подходит для высокой частоты загрузки и работы с большими объемами данных.

Open ODS View – еще один новый тип объектов, появившийся для версий BW на HANA. Он позволяет определять модели данных BW для таблиц или представлений (View) баз данных, источников данных BW для прямого доступа на уровне полей. Все это можно сделать без необходимости создания инфо-объектов. Любой запрос к Open ODS View будет подключаться к внешнему источнику во время выполнения, этот объект физически не хранит в себе данные.

Composite Provider – виртуальные витрины, объединяющие данные «на лету». Инфо-провайдер объединяет данные из нескольких аналитических индексов или от других инфо-провайдеров, используя Union или Join, и делает их доступными для отчетов и анализа.

Итак, у нас есть составные части, из которых складываются уровни LSA++, представленные на схеме (рис. 28).

Staging layer/Corporate memory

Общее правило моделирования рекомендует хранить полную историю всех загруженных данных хотя бы на уровне Corporate memory. Данные этого уровня можно использовать как источник для их восстановления на следующих уровнях. При этом повторный доступ к источникам не потребуется. Это важно еще и для управления их жизненным циклом. Определив, к каким данным требуется обращаться чаще, а какие можно хранить на более дешевых носителях, появляется возможность экономить деньги, но при этом иметь «резерв» на случай какого-либо сбоя или аварии. Данные на этом уровне хранятся в ADSO.

Open ODS layer/Raw DWH

Здесь можно осуществлять быструю интеграцию с возможностью оперативного предоставления данных для отчётности.

Объекты этого уровня позволяют:

-      физически хранить данные в DSO, смоделированных на полях или в таблицах SAP HANA, которые доступны для BW через представления HANA Calculation View;

-      осуществлять прямой доступ к данным источника без репликации с помощью Open ODS View.

Уровень полезен, прежде всего, для интеграции не-SAP-данных, поскольку позволяет избежать длительного создания инфо-объектов для полей.

Propagation layer/Integrated DWH

Уровень является основным поставщиком данных для отчетов. Здесь хранятся гармонизированные, очищенные и консолидированные подробные данные. В основном он состоит из стандартных ADSO.

Architected Data Mart

Подразумевает физическое хранение агрегированных для отчётности данных. Объекты этого уровня создаются только в том случае, если комбинации объектов Propagation layer и Virtual data marts недостаточно для удовлетворения специфических системных или бизнес требований.

В качестве объектов на этом уровне могут использоваться ADSO и инфо-объекты.

Virtualization/Virtual Data Marts

Позволяет объединять между собой инфо-провайдеры, как устойчивые (с физическим хранением), так и виртуальные, используя операторы Union или Join. Может объединять объекты уровня Open ODS с объектами уровня Propagation layer или уровня Architected Data Mart, ограничения по уровням для объединяемых объектов отсутствуют.

Построенная на виртуальном провайдере отчётность остается доступной даже при замене базового инфо-провайдера. Поэтому рекомендуется все инфо-провайдеры, являющиеся поставщиками данных для отчётности, включать в виртуальные провайдеры. 

Объектами уровня Virtual Data Marts являются Composite Provider и Open ODS View разных типов.

В LSA++ уровень Virtualization/Virtual Data Marts является обязательным. Наличие остальных уровней опционально, так как зависит от требований бизнеса к хранилищу и потребности в сервисах, которые обеспечивают эти уровни. Например, интеграционные сервисы, дополнительные трансформации данных, немедленный доступ к данным и т.п.

Такой подход даёт ряд преимуществ:

-      построение отчетов на любом уровне хранилища;

-      быстрая и гибкая аналитика, в том числе на детальных данных;

-      виртуальное комбинирование данных разных уровней хранилища;

-      комбинирование моделирования данных снизу-вверх и сверху вниз – ускорение и упрощение разработки;

-      чем меньше уровней хранения, тем проще и быстрее процессы обновления данных в хранилище;

-      сокращение объемов физического хранения данных и необходимых для этого ресурсов.

Уф, кажется, теперь всё – мы вам рассказали, как осуществляется моделирование данных в SAP BW/4HANA в теории и на практике. Спасибо за время, которое вы уделили этой статье! Напишите в комментариях как вы оцениваете архитектуру LSA++, кажется ли вам такой подход к работе с данными удобным и быстрым, сможет ли компания, в которой вы работаете, с его помощью получать дополнительную выгоду?

Пробуйте, экспериментируйте, интересных задач и кайфа от работы! До новых встреч!