Интеллектуальная работа с данными в SAP Data Intelligence
SAP Data Intelligence – это платформа, которая включает в себя унифицированный набор инструментов для управления данными, комплексной обработки данных и создания интеллектуальных сценариев на основе машинного обучения. SAP Data Intelligence позволяет оснащать интеллектуальными сервисами бизнес-системы предприятия, в частности SAP S/4HANA.
Комплексное решение для всех основных задач обработки данных
Управление данными компании из любых доступных источников
Встроенные интеллектуальные сценарии помогают находить инсайты
Описание системы SAP Data Intelligence
В последнее время мы замечаем существенную трансформацию, которая происходит в IT-ландшафтах компаний – к традиционным on-premise системам добавляются облачные продукты, а также специализированные решения, например, для работы с большими данными. Таким образом, ландшафты становятся более распределёнными и более комплексными, а для эффективного управления данными и их монетизации необходимо применять новые подходы и инструменты.
SAP Data Intelligence – это платформа, которая позволяет подключаться к различным системам ландшафта, собирать оттуда мета-данные с помощью Metadata Crawler, описывать бизнес-термины на понятном языке в глоссарии, настраивать связи бизнес-терминов и объектов каталога мета-данных, а также создавать бизнес-правила и оценивать с их помощью качество данных.
Кроме того, система даёт возможность моделировать пайплайны для комплексной обработки данных, а также разрабатывать модели во встроенной среде Yupyterlab, отслеживать их версии, обучать модели и оценивать их качество, создавать интеллектуальные сценарии на основе этих моделей, эффективно их продуктивизировать и управлять жизненным циклом.
Интеллектуальные сценарии
Разработка ML | Продуктивизация | Управление
Комплексная обработка данных
Сбор данных | Обработка | Прогнозирование
Управление данными
Поиск | Каталог метаданных | Глоссарий | Качество
Интеграция
Подключение к источникам данных
Управление данными с SAP Data Intelligence: Как превратить сырые и разрозненные сведения в полезные идеи и инструменты ведения бизнеса в цифровой экономике?
Барьеры на пути к прозрачной и эффективной работе с данными
Данные разрознены в различных системах и не описаны, нет системного подхода и архитектуры
“Теневые” ИТ-системы могут хранить важные данных, доступ к которым затруднён
Часть бизнес-процессов не автоматизирована, а их данные хранятся в виде файлов либо бумаг
Данные собираются или хранятся некачественно, что затрудняет работу с ними
Часть необходимых данных не сохраняется
Стандартный процесс управления данными:
Исследование
Поиск данных в ландшафте и их профилирование
Определение
Классификация данных и формирование каталога мета-данных, формирование бизнес-глоссария и связей между терминами и объектами
Применение
Поиск данных в каталоге мета-данных и терминов в глоссарии, применение правил для анализа качества данных, сотрудничество бизнеса и ИТ
Оценка и мониторинг
Проактивный мониторинг качества данных с помощью дашборда, анализ Data Lineage, оценка ценности процесса для бизнеса
Ключевые задачи управления данными по мнению SAP
К 2021 году по мнению Gartner функция CDO станет высококритичной, сравнимой по важности с IT, HR, финансами в 75% крупных компаний. Сегодня CDO отвечает не только за управление данными, но и за внедрение инновационных решений на их основе.
Сейчас работа с данными – это не просто их сбор, хранение и визуализация, а построение самообучающихся систем, которые позволяют оптимизировать бизнес каждую минуту.
5 ключевых задач управления данными
Использование и монетизация данных
Реализация интеллектуальных сценариев на основе машинного обучения.
Управление метаданными
В условиях увеличивающегося объёма данных критически важно синхронизировать объекты данных и бизнес-термины.
Анализ и улучшение качества данных
Использование машинного обучения для анализа качества данных и для уточнения бизнес-правил.
Интеграция и обработка данных
Помимо стандартных средств интеграции используется Data Piplines – конвейеры данных, состоящие из операторов, позволяющих собирать информацию из различных систем, обрабатывать их и публиковать результаты.
Хранение данных
Маскирование, анонимизация и управления правами доступа к данным.
Разработка интеллектуальных сценариев – от прототипа до промышленного решения
Поиск данных
Поиск и анализ данных. Подключение к системам и источникам
Подготовка данных
Сбор данных из источников. Извлечение данных в пакетном режиме.
Комбинирование данных и трансформация. Обработка и комбинирование данных.
Подготовка данных для ML. Публикация сета в ML Data Manager.
Разработка модели
Реализация модели. Анализ данных и тестирование.
Обучение модели. Обучение ML-модели на собранных данных.
Тестирование и валидация.
Создание модели
Разврёртывание. Создание Inference pipeline — REST API-сервиса
Управление жизненным циклом. Мониторинг результатов и анализ точности модели
ML-cценарий — объект SAP Data Intelligence, соответствующий бизнес-кейсу и объединяющий все его артефакты в едином консистентном виде.
Преимущества
Ускорение и упрощение внедрения ML-сценариев
Управление жизненным циклом: контроль версий, автообучение, ввод/вывод из эксплуатации, мониторинг выполнения SLA
Возможность автоматического построения моделей, включая генерацию и отбор признаков, работу с пропусками, подбор оптимальных алгоритмов и их параметров
Построение интеллектуальных сервисов для использования ML-сценариев в промышленной среде, встраивание ML в бизнес-приложения SAP и не-SAP
Унифицированный набор инструментов для реализации ML-сценариев и управления их жизненным циклом
SAP Data Intelligence: Совместная архитектура SAP и Microsoft Azure для работы с большими данными и ML
Решение SAP Data Intelligence построено на cloud native технологиях, микросервисной архитектуре и контейнеризации. Data Intelligence предоставляется клиентам в формате as-a-Service в различных публичных и частных облаках, а также, как on-premise решение. Вне зависимости используется ли SAP Data Intelligence as-a-service или решение развёрнуто в on-premise ландшафте, оно позволяет клиентам:
Таким образом, SAP Data Intelligence поддерживает мультиклаудную стратегию. Наглядным примером совместного использования SAP Data Intelligence и облаков является делегирование тяжёлых ML-задач, обрабатывающих десятки или сотни терабайт данных, из Data Intelligence в специализированные облачные сервисы, предлагающие лучшее соотношение производительности и стоимости в моменте. SAP Data Intelligence позволяет клиентам не зависеть от конкретного облачного провайдера, использовать best-of-breed облачные технологии и снижать TCO.
Получайте аналитические сведения на основе всех своих данных и создавайте решения с использованием искусственного интеллекта (AI) при помощи Azure Databricks, настройте среду Apache Spark™ за считанные минуты, обеспечьте автомасштабирование и участвуйте в совместной работе над общими проектами в интерактивной рабочей области.
Посмотрите записи вебинаров по SAP Data Intelligence
Скачайте брошюру 7 сценариев применения Azure Databricks
Здравоохранение, ритейл, коммуникации и СМИ, финансы, нефтегазовая отрасль и энергетика, маркетинг, безопасность
Что такое Business Intelligence
Существует огромное количество терминов: аналитика, data mining, анализ данных, business intelligence и разница между ними не всегда столь очевидна даже для людей, которые с этим связаны. Сегодня мы расскажем о том, что же такое Business Intelligence (BI) доступным и понятным языком. Тема безусловна огромна и её не покрыть лишь одной короткой статьей, но наша задача — помочь сделать первый шаг и заинтересовать читателя темой. Заинтересованный же читатель также найдет исчерпывающий список для дальнейших шагов.
Зачем всё это нужно: из жизни аналитика
Представим, нами (неким аналитиком Петровичем у поставщика Цветочек) стоит задача оценить продажи ряда магазинов (куда мы поставляем товар) и каждый магазин ведет свой учет проданных товаров. Реальность такова, что формы учета будут заполнены не пойми как и не пойми кем, то есть у них будет разная структура и разный формат хранения (некоторая форма таблиц). Схематично эта задача изображена на схеме выше.
Казалось бы задача несложная и поэтому рассмотрим лобовое решение: пусть у нас есть N таблиц и нам нужно их собрать вместе в одну таблицу, тогда напишем N скриптов, которые преобразуют эти таблицы и один сборщик, который собирает их вместе.
Если мы поднимемся на уровень целой организации, то увидим, что проблем даже больше.
В чем задача: проблема на уровне компании
Производитель Цветочек на самом деле работает не напрямую с магазинами, а через некоторых посредников. Посредники посещают магазины и непосредственно своими действиями пытаются стимулировать продажи. Соответственно, они являются материально заинтересованными лицами и информацию, которую они выдают, приходится перепроверять.
Принципиально, задача выглядит схожим образом: пусть у нас есть N магазинов и K дистрибьюторов, можем ли агрегировать данные магазинов и сравнить их с результатами дистрибьюторов? (У всех данные имеют разную структуру и формат.)
Здесь помимо таблиц, мы уже можем столкнуться с целым зоопарком форматов, к которым добавляются отчеты дистрибьюторов. Как правило задача характеризуется очень низким качеством данных, в том числе дублированием, несогласованностью и ошибками. На основе полученных результатов и сравнения данных, отдел по закупкам принимает решения о том сколько, кому и почем чего отгружать. То есть решение этой задачи непосредственно влияет на финансовые показатели компании, что безусловно важно.
Рассмотрим несколько вариантов решения на уровне компании:
В целом если мы говорим о небольшом или среднем производителе, то с точки зрения времени интеграции, цены и качества решения сервис выглядит оптимальным вариантом, так как ценообразование динамическое и интеграция минимальна через веб. Как правило плюсом корпоративного ПО является настраиваемость и касмтомизированность (каждый бизнес считает себя уникальным), но описанная задача достаточно типична и стандартна для достаточно широкого круга компаний. Безусловно, нет единого решения для всех, но для каждого в отдельности его можно найти.
Сам процесс на уровне компании выглядит схожим образом: консолидируется данные, определенным образом трансформируются (агрегируются) и загружаются в систему для анализа.
(кликабельно) 
Обобщаем задачу: всё это звенья одной цепи
В чём же разница между аналитикой, data mining и business intelligence (BI)? Первые включают в себя комплекс методов для анализа уже чистых данных, а на практике очистка и преобразование данных в удобный для анализа формат — важный и неотъемлемый процесс. Так же помимо работы с преобразованием и консолидацией данных, основная задача BI — это принятие решений для бизнеса.
Большая инфографика
В схематичной и немного упрощенной форме описывается задача консолидации данных. Если нет возможности заниматься изучением темы в деталях, то эта инфографика даёт хорошее первое приближение проблемы и возможных методов решения. (кликабельно; взято отсюда) 
С чем можно поэкспериментировать
Сервис бесплатен и доступен через веб — ссылка.
5 этапов от идеи до практического применения машинного обучения c SAP Data Intelligence
История машинного обучения началась с середины прошлого века. В то время данная технология была больше областью для научных исследований и экспериментов, а толчок к практическому применению ML дали мощные компьютеры.
Сегодня машинное обучение – это неоспоримый тренд на рынке ИТ. Все больше компаний из разных индустрий создают подразделения Data science, чтобы с помощью машинного обучения находить в накопленных данных новые возможности для роста и повышения эффективности бизнеса. Однако, пока эти инициативы не дают должной отдачи. По статистике 8 из 10 подтвержденных кейсов не переходят в промышленную эксплуатацию.
Скорее всего большинство из вас слышали шутку «самый эффективный способ продуктивизации машинного обучения – это слайды PowerPoint». К сожалению, это не шутка. Зачастую весь процесс выглядит так: бизнес передает выгруженные из бизнес-систем данные и бизнес-кейс. Дата-сайентисты разрабатывают модель машинного обучения в Jupyter Notebook, скриншот графиков помещают на слайд PowerPoint и отправляют бизнес-заказчику. Можно ли использовать полученный слайд в принятии управленческих решений? Скорее нет, так как данные прогноза быстро устаревают, и ситуация в бизнесе за это время может серьезно измениться.
Пытаясь преодолеть все преграды и поставить машинное обучение на поток, большинство компаний инвестируют в инфраструктуру сбора, хранения и обработки больших объемов данных – Data Lake. Безусловно, это необходимый шаг. Но что это меняет с точки зрения бизнеса? Возможно ли принимать решения, опираясь на машинное обучение? Нет, так как между Data Lake и бизнесом пропасть. Очевидно, почему 86% опрошенных компаний верят в то, что бизнес-приложения нового поколения должны быть оснащены машинным обучением.
Мы в компании SAP решили написать серию статей, как с помощью новой платформы SAP Data Intelligence преодолеть существующие сложности и поставить столь мощный инструмент, как машинное обучение, на службу бизнесу. И, если эта тема вам интересна, продолжайте читать 🙂
Для начала я расскажу вам про первый и очень важный этап разработки любого бизнес-кейса «Поиск и подготовка данных». В последующих статьях рассмотрим этапы «Разработка и обучение моделей», «Интеграция с SAP и non-SAP on-premise и cloud источниками данных в деталях», «Создание сервисов для использования моделей», «Перенос бизнес-кейсов в продуктив», «Мониторинг и эксплуатация бизнес-кейсов» и многое другое.
Разработка бизнес-кейса на основе машинного обучения. Поиск и подготовка данных.
Давайте рассмотрим процесс создания бизнес-кейса (Рис 1).
Изначально идею, как правило, формулирует бизнес. Зачастую он делает это охотно, так как у него есть определённая цель по цифровизации функции в рамках цифровой трансформации всего предприятия. Для сбора, оценки и приоритезации идей можно использовать, например, SAP Innovation Management.
Рисунок 1.
На первом этапе поиска и подготовки данных необходимо понять, есть ли они вообще для разработки бизнес-кейса, где хранятся, в каких форматах и какого они качества. Современный типовой ландшафт включает в себя множество разнородных систем. Данные могут дублироваться в разных приложениях. На поиск нужной информации может уйти много времени. Именно для этого в SAP Data intelligence существенно упрощена эта задача с помощью Каталога метаданных. Давайте рассмотрим, что это такое и как его использовать.
Для использования каталога метаданных необходимо подключить систему-источник к Data Intelligence. Источниками данных для Data Intelligence могут быть on-premise системы SAP ERP, BW, Marketing… и non-SAP MES, Oracle, MS SQL, DB2, Hadoop и многие другие, а также облачные сервисы Amazon, Azzure, Google SCP. Для подключения к источникам данных необходима информация о размещении систем и технические пользователи, созданные в этих системах специально для интеграции с SAP Data Intelligence. На рисунке 2 представлен пример настроенного ландшафта данных в SAP Data Intelligence.
Рисунок 2.
Сразу после настройки в Каталоге метаданных SAP Data Intelligence возможно увидеть информацию, которая хранится в подключенных системах. На рисунке 3 представлен перечень файлов, которые находятся в папке DAT263 в Hadoop, подключенном к SAP Data Intelligence.
Рисунок 3.
Если вы нашли данные, которые необходимы для реализации бизнес-кейса, давайте добавим объекты данных в Каталог с помощью функции публикации. Я буду использовать файл autos_history.csv, который содержит статистику продаж подержанных автомобилей. На рисунке 4 вы видите, как можно опубликовать объект данных и его метаданные в Каталог для быстрого доступа в будущем.
Рисунок 4.
Структуру каталога, уровни иерархии вы можете настраивать в соответствии с вашими требованиями бизнес-кейсов. Например, в моей папке Habr_demo будут собраны все метаданные об объектах, которые мне нужны для этой статьи.
Сформированный Каталог метаданных – это быстрый доступ к данным по бизнес-кейсу. Профилирование и анализ их качества я буду проводить на объектах моей папки в Каталоге метаданных SAP Data Intelligence. Начальный экран каталога метаданных показан на рис. 5.
Рисунок 5.
И вот тот самый объект данных, который я опубликовала в папку Habr_demo (Рис.6)
Рисунок 6.
Дополнительно для улучшения и ускорения поиска мы можем в каталоге объектов данных назначить тэги или метки, как это показано на рис. 7.
Рисунок 7.
Каталог метаданных позволяет искать объекты по названиям их самих, полей, а также по меткам. Один объект данных может иметь несколько меток. Это удобно, если с ним работают несколько разработчиков, каждый может назначить метку по своему бизнес-кейсу, и по ней быстро находить все необходимое. Также метками можно выделять персональные и конфиденциальные данные, доступ к которым должен быть строго ограничен.
По рассматриваемому дата-сету поиск по метке и по имени поля дает быстрый результат (рис. 8). Согласитесь, это очень удобно!
Рисунок 8.
Далее нам нужно понять, чем заполнен наш файл. Для этого мы можем профилировать данные. Запускаем процесс мы также из каталога метаданных и контекстного меню на объекты данных (Рис.9).
Рисунок 9.
В ходе профилирования каталог метаданных прочитает содержимое файла, проанализирует его структуру и заполнение. Результат можно посмотреть в Fact Sheet (рис.10).
Рисунок 10.
В Fact Sheet мы видим структуру файла и информацию по заполнению полей.
1. В выбранном файле в результате профилирования мы выявили: поле seller имеет одно значение I во всех строчках. Это означает, что это поле мы можем удалить из дата-сета, чтобы не использовать при построении модели машинного обучения, так как оно не будет влиять на результат прогноза (Рис. 11).
Рисунок 11.
2. Анализируя колону price, мы понимаем, что почти 3% данных у нас содержат нулевую цену. Для того, чтобы этот файл использовать в нашем бизнес-кейсе, мы должны заполнить price либо актуальными значениями, либо средним по данному продукту, или мы должны удалить строки с нулевой ценой из файла (Рис.12).
Рисунок 12.
Предобработку данных мы можем сделать двумя способами: в Каталоге метаданных или непосредственно в Jupyter Notebook. Выбор инструмента зависит от того, кто отвечает за предобработку данных для бизнес-кейса. Если аналитик, то я рекомендую использовать визуальный интерфейс подготовки данных, который доступен в Каталоге метаданных. Если подготовкой данных занимается дата-сайентист, то однозначно выбор должен быть в пользу Jupyter Notebook, который также интегрирован в Data Intelligence.
3. Значение поля model хорошо распределены, что позволит нам качественно обучить модель, как на рисунке 13.
Рисунок 13.
Теперь мы понимаем, какие объекты данных требуются для реализации бизнес-кейса, чем заполнены объекты данных, какую предобработку мы должны провести, чтобы использовать эти данные для реализации, обучения и тестирования модели. Но прежде, чем начать предобработку, необходимо проверить качество данных. Для этого в Каталоге метаданных доступны бизнес-правила. Сразу отмечу, что на текущий момент функциональность бизнес-правил имеет ряд серьезных ограничений. Поэтому более или менее сложную предобработку данных я рекомендую проводить в Jupyter Notebook, который интегрирован в SAP Data Intelligence.
Итак, давайте вернемся к нашему дата-сету и проверим соблюдение минимальных и максимальных порогов по полю price, таким образом мы сможем грубо оценить, есть ли в данных аномалии или некорректные значений. Как вы уже поняли, бизнес-правила настраиваются также в Каталоге метаданных, как на рис. 14а, в. Связь правил и данных настраивается в книге правил (Rulebook). Это позволяет использовать одни и тоже правила для проверки различных данных.
Рисунок 14 а.
Рисунок 14 в.
Итак, как мы видим, наши данные на 100% корректны.
Но так бывает не всегда. Данные могут быть признаны корректными, если 75% записей соответствует условиям, заданным в правилах.
Повысить качество данных возможно, и прежде всего это делается в учётных системах. Для этого в компании организуют процесс управления данными. Также возможная причина — неверно определенные критерии качества данных.
Резюмируя, хочется сказать о преимуществах и недостатках Каталога метаданных.
На мой взгляд, у него 3 основных преимущества:
И это следствие новизны и комплексности SAP Data Intelligence. SAP много ресурсов инвестирует в совершенствование этого решения. И это вселяет уверенность в том, что в ближайшее время Каталог метаданных превратится в мощный инструмент для управления данными. Появится возможность создавать комплексные бизнес-правила без программирования. А также станет возможным интегрировать SAP Information Steward и SAP Data Hub для целей полноценного функционального покрытия темы управления данными.
В следующей статье расскажем об этапе «Разработки и обучения модели в SAP Data Intelligence». Все самое интересное впереди!
Автор – Елена Ганченко, эксперт SAP CIS
Первые шаги в BI-аналитике. Роль Data Engineering
Добрый день, уважаемые читатели! Материал носит теоретический характер и адресован исключительно начинающим аналитикам, которые впервые столкнулись с BI-аналитикой.
Что традиционно понимается под этим понятием? Если говорить простым языком, то это комплексная система (как и, например, бюджетирование) по сбору, обработке и анализу данных, представляющая конечные результаты в виде графиков, диаграмм, таблиц.
Это требует слаженной работы сразу нескольких специалистов. Дата-инженер отвечает за хранилища и ETL/ELT-процессы, аналитик данных помогает в заполнении базы данных, аналитик BI разрабатывает управленческие панели, бизнес-аналитик упрощает коммуникации с заказчиками отчетов. Но такой вариант возможен, только если фирма готова оплачивать работу команды. В большинстве случаев небольшие компании для минимизации затрат делают ставку на одного человека, который зачастую вообще не обладает широким кругозором в области BI, а имеет лишь шапочное знакомство с платформой для отчетов.
В таком случае происходит следующее: сбор, обработка и анализ данных происходит силами единственного инструмента – самой BI-платформой. При этом данные предварительно никак не очищаются, не проходят компоновки. Забор информации идет из первичных источников без участия промежуточного хранилища. Результаты такого подхода можно легко лицезреть на тематических форумах. Если постараться обобщить все вопросы касательно BI-инструментов, то в топ-3 попадут, наверное, следующие: как загрузить в систему плохо структурированные данные, как по ним рассчитать требуемые метрики, что делать, если отчет работает очень медленно. Что удивительно, на этих форумах вы практически не найдете обсуждений ETL-инструментов, описания опыта применения хранилищ данных, лучших практик программирования и запросов SQL. Более того, я неоднократно сталкивался с тем, что опытные BI-аналитики не очень лестно отзывались о применении R/Python/Scala, мотивируя это тем, что все проблемы можно решить только силами BI-платформы. Вместе с тем всем понятно, что грамотный дата инжиниринг позволяет закрывать массу проблем при построении BI-отчетности.
Дальнейший разговор предлагаю построить в форме разбора упрощенных блок-схем. Я сознательно не буду называть конкретные программы, а лишь укажу их класс. Во-первых, это не имеет принципиального значения для раскрытия темы, а, во-вторых, упоминание инструментов сразу приводит к ненужным спорам в комментариях.
«Data – BI» Самый простой вариант. Именно с него начинается прототипирование управленческих панелей. В роли источника данных часто выступает отдельный (-ые) статичный файл (csv, txt, xlsx и т. д.).
Плюсы. Самый быстрый способ построения отчетности. Идеально подходит, для ситуационной аналитики или когда результат нужен был еще вчера. Не требует применения вспомогательных инструментов, следовательно, не нужно тратить ресурсы на их поддержание. Аналитик BI не обязан иметь компетенции в области дата инжиниринга или программирования.
Минусы. Далеко не изо всех источников можно забрать информацию напрямую (пример, прикладные решения на платформе 1С). Если массивы плохо структурированы, то это потребует много дополнительных шагов по их обработке. Качество данных никак не проверяется (проблема дубликатов, пустых строк, некорректного написания значений и т. д.). При большом количестве строк заметно замедляется работа самой BI-платформы, вплоть до полной невозможности перестраивать графики и диаграммы. Нет возможности составить расписание на обновление исходников.
«Data – DB – BI» Вариант похож на предыдущий за тем исключением, что первоначальный массив напрямую заливается в базу в неизмененным виде, а уже к ней идет подключение. База данных может быть как развернута локальна, запущена в контейнере, так и представлена облачным хранилищем.
Плюсы. Есть возможность агрегировать разрозненные, однотипные файлы. Нагрузку по хранению информации теперь несет хранилище. Есть возможность задействовать всю мощь языка запросов SQL (или его диалекта), чтобы отфильтровать или агрегировать сырые строки перед их передачей в BI-инструмент. Уменьшается размер файла с управленческими панелями.
Минусы. Нет контроля над первичными данными, поэтому в хранилище заливается большое количество ненужной информации. Качество загружаемых датасетов никак не контролируется. Добавление данных в базу осуществляется в ручном режиме. Аналитик должен на базовом уровне знать SQL.
«Data – ETL – DB – BI» Частичная автоматизация. В качестве ETL-инструмента может выступать как программный продукт с графическим интерфейсом, так и код написанный на R/Python/Scala и т. д. Все данные проходят предварительный предпроцессинг. Структура наполняемых таблиц прописывается заранее.
Плюсы. Возможность загружать только хорошо структурированную информацию, которая прошла предварительную верификацию. Экономия места в базе данных. Снижается количество доработок на BI-платформе.
Минусы. Аналитик должен уверенно владеть ETL-инструментом и языком запросов SQL. Процесс разработки и тестирования скриптов требует времени. Если источников информации много, то затрудняется синхронизация получения информации.
Для иллюстрации этого варианта я решил написать простейшие скрипты. В рамках «игрушечного» примера я использую SQLite. Это позволит прикрепить базу данных к публикации, чтобы каждый желающий мог попрактиковаться в написании скриптов (архив). Датасет для разбора это E-Commerce Data с сайта Kaggle.
В коде сочетается Extract и Transform. Считываем датасет, парсим столбец с датами. Рассчитываем сумму покупки по каждой строке и удаляем ненужные для дальнейшего анализа колонки. Так как датафрейм записывается в базу данных не монолитом, а разбивается на таблицы, то готовим три вспомогательные функции.
На следующем этапе (Load) мы создаем четыре таблицы. Две из них будут справочниками. Одна содержать сгруппированную информацию по продажам. Нам также потребуется вспомогательная таблица, в которую мы запишем строки с продажами до момента замены текстовых значений на числовые ид. На последнем шаге очистим ее от всех значений.
В заключении нам остается лишь выполнить тестовый запрос SQL, чтобы проверить корректность всех операций. Если все сделано правильно, запускаем BI-платформу.
Так как BI-инструмент не может из коробки напрямую подключиться к SQLite напишем простейший скрипт на Python.
После загрузки данных в систему и проверки корректности распознанных форматов можно приступать к непосредственному построению дашборда.
«Data – Workflow management platform + ETL – DB – BI» Полная автоматизация. Оркестратор скриптов берет на себя контроль за своевременным выполнением всех вспомогательных процессов в системе.
Плюсы. Возможность оптимально настроить время сбора данных из разрозненных источников. Можно мониторить ошибки и перезапускать упавшие задачи.
Минусы. Усложнение инфраструктуры. Рост требований к квалификации аналитика BI. Необходимо осваивать дополнительные инструменты или языки программирования.
«Data – Workflow management platform + ELT – Data Lake – Workflow management platform + ETL – DB – BI» Самый сложный вариант, где информация проходит двухступенчатый конвейер: сначала это неструктурированные данные (Data Lake), а затем уже хранилище (DB), где информация отсортирована и преобразована к требуемому виду.
Плюсы. Возможность разнести во времени сбор информации и ее обработку. Если на этапе проектирования таблиц учтены не все требования, возможно обращение за дополнительными данными в Data Lake.
Минусы. Аналогичны предыдущему варианту. Если выбранная платформа Data Lake – платная, как следствие рост расходов на аналитику компании.
Построение BI-аналитики без даты инжиниринга возможно лишь на старте.
Если аналитик BI работает в единственном числе и система постоянно усложняется, то он обязан подменять собой сразу несколько специалистов.
Понимание базовых принципов построения хранилищ данных, уверенное владение SQL, программирование на каком-либо языке и, конечно, дизайнерские навыки вот далеко не полный перечень требований к сотруднику, которому делегируется проектировать управленческие панели.
На этом все. Всем здоровья, удачи и профессиональных успехов!
