Всем привет! Меня зовут Юлия Скогорева, я системный аналитик в команде Center of excellence дирекции данных и аналитики Lamoda.
Если бизнесу нужны какие-то данные для принятия важных решений, то на помощь приходит наша команда. Мы тщательно изучаем множество микросервисов, чтобы определить, какие же данные нужны для решения бизнес-целей, формируем архитектуру хранилища, пишем скрипты запросов и витрин данных, строим юниверсы, делаем отчеты и дашборды. Большая часть работы не обходится без участия команды DWH-разработки.
В статье я расскажу, как устроено хранилище данных в Lamoda, что находится на каждом его слое, с помощью каких инструментов мы визуализируем данные, сколько у нас отчетов и зачем используем APEX.
Структура DWH
Data Warehouse (DWH) — это централизованное хранилище данных, агрегирующее данные из разных систем-источников, на которых можно проводить анализ исторических и текущих данных.
Хранилище в Lamoda построено на Oracle, которое занимает около 60 TB данных, и Vertica на 7 TB.
Oracle | Vertica Cluster |
CPU 16 Core (32 threads) 1.5 TB RAM 90 TB SSD | 5 nodes CPU 160 Core (320 threads) 2.1 GHz 2.5 TB RAM 16 TB SSD |
Наше DWH состоит из пяти слоев:
Data Layer (DL),
Intelligence Layer (IL),
Business Layer (BL),
Metadata Layer (ML),
Operational Data Store (ODS Report).
Data Layer (DL)
Слой «сырых» данных. Он используется для хранения данных из систем-источников, которые загружаются в рамках автоматизированных ETL-процессов.
Данные на этом слое хранятся в первозданном виде, что позволяет нам выделять и отслеживать дельту их изменений независимо от того, ведет ли источник логи. Это важное преимущество в таких ситуациях, когда в последующих слоях данных (IL/BL) есть ошибки. В этом случае можно провести полную перезагрузку таблиц на основе историй данных из систем-источников или же проверить цифры и данные, которые вызывают сомнения.
Сложности при загрузке на слой: большой объем данных, перенос изменений из источника без потерь.
Intelligence Layer (IL)
Слой, который используется для консолидации, унификации и нормализации данных хранилища. Данные из внешних систем-источников мы приводим к единому формату, а для ключей таблиц генерируем уникальные идентификаторы, которые в дальнейшем используются при сборке витрин данных. Таким образом, этот слой обеспечивает целостность и качество данных из различных систем.
Сложность при загрузке на слой: сделать наиболее понятную сущность, которую удобно было бы переиспользовать при построении новых витрин данных.
Business Layer (BL)
Слой аналитических витрин, в которых данные преобразуются в удобный для пользователей вид для анализа и решения бизнес-задач. Данные витрины используются напрямую пользователями, а также BI-системами для построения юниверсов в SAP BusinessObjects и наборов данных в Power BI.
Часть таблиц перегружается в Vertica без изменений, чтобы пользователи могли выполнять аналитическую работу по различным ad hoc задачам. Тем самым мы не нагружаем основное хранилище, потому что Vertica — колоночная база данных.
Сложность при загрузке на слой: оптимизировать время расчета.
Metadata Layer (ML)
Слой метаданных, который хранит всю информацию о данных хранилища. Он нужен для управления загрузкой данных и их проверки. Также в нем хранятся маппинги ключей для фактовых таблиц и справочников.
Сервисный слой позволяет анализировать метаданные и обеспечивать качество и целостность загружаемой информации.
Operational Data Store (ODS Report)
Слой с витринами данных над Data Layer. Они применяются в трех случаях:
когда требования к отчетности не до конца понятны;
не нужно делать преобразования над данными источника;
данные нужны сразу же после их появления на DL.
Как организована работа с хранилищем в Lamoda
В Lamoda около 60-ти логических систем-источников и более 800 физических источников для DWH.
Типы источников | Их особенности |
Реляционные БД | Быстрая вычитка с помощью SQL. Иногда меняется структура таблиц. |
API | Могут менять структуру источника, оставляя API неизменным. Относительно медленное чтение. |
Kafka | Быстрая доставка только измененных записей с источника. Иногда записи «теряются» по пути — не все датафиксы и миграции на базы доставляются в Кафку. Неудобно перезагружать данные ретроспективно. |
Hadoop | Иногда зависают запросы. |
Google Docs и Excel | Ошибки в форматах данных из-за человеческого фактора, в связи с чем активно переходим на APEX. |
APEX | Подробнее расскажу о нем в следующем разделе. |
Также важно рассказать о том, как мы фиксируем изменения на источниках при загрузке на слой DL, а именно про типы историчности Slowly Changing Dimensions. У нас их три вида:
можем хранить первоначальное значение,
перезаписать старое значение новым,
добавить новую запись, оставив старую, что позволяет нам иметь историю изменения на источнике.
Типы историчности Slowly Changing Dimensions, применяемые в загрузке на DL:
Тип SCD | Строка вставилась на источнике | Значение поля изменилось на источнике |
SCD0 | Строка вставилась | Поле не поменяется, строка с новой версией не вставится |
SCD1 | Строка вставилась | Значение текущей строки поменяется, строка с новой версией не вставится |
SCD2 | Строка вставилась | Вставится новая строка с новой версией поля с датой загрузки |
Наша команда системных аналитиков исследует новые системы-источники и какие данные необходимо забрать в хранилище из этих источников, а еще описывает новые таблицы для команды DWH-разработки. Ребята загружают данные с источников на DL с помощью Pentaho DI, далее последующие слои формируются фреймворком собственной разработки: Oracle PL/SQL и Python.
Наше хранилище построено по методологии Билла Инмона. Важный слой в методологии — это Intelligence Layer (IL) или слой детальных данных. В нем мы создаем таблицы с данными, приближенными к 3NF (Third normal form или Третьей нормальной форме).
Таблицы — это нормализованное представление бизнес-сущностей или процессов (заказ, товар, сотрудник). Мы стараемся подбирать понятные имена таблицам, которые отражали бы смысл хранимых данных. Названия используем в единственном числе. Например, fct_orderitem_detail — фактовая витрина с данными по товарам в заказе, fct_order — фактовая витрина с данными по заказам, dim_brand — таблица-справочник брендов, article_daily — витрина состояния товаров (артикулов) на дату.
В источнике данные могут быть в ненормализованном виде, что может затруднять понимание бизнес-процесса. Например, один процесс может быть раскидан по нескольким таблицам или часть данных может лежать в JSON.
На слое IL одну сущность допускается разбивать на несколько таблиц, если часть атрибутов изменяется редко, а другая — крайне часто. Можно сэкономить место на историчном хранении и на времени загрузки.
Oracle APEX
Это среда быстрой разработки приложений с минимальным программированием на основе СУБД Oracle Database, реализованная в виде веб-приложения. APEX помогает отказаться от Google Docs и от ручных справочников, в которых сложно проследить, что изменилось, а также как часто и кем они обновляются.
Преимущества APEX:
Удобный user-friendly интерфейс, в котором можно загружать данные как построчно, так и из файлов.
Обновление полей и удаление некорректных записей (также можно удалять построчно или все записи в справочнике).
Выдача ролей на редактирование определенным пользователям, ответственным за конкретные данные. Так пользователь видит только те справочники, к которым у него есть доступ, что избавляет от случайных ошибок, как в Google Docs.
Возможность посмотреть, кто создал новую запись, обновил или удалил ее, а еще когда происходило изменение.
Загрузка данных из интерфейса в DWH на слой DL. Пользователи могут сами загружать эти данные, когда им нужно, и использовать справочники при построении логики финальных витрин на BL.
У нас создано около 80-ти справочников в APEX. Ниже пример простого справочника, который содержит разницу в часах между московским временем и временем остальных городов. Этот справочник нужен для того, чтобы переводить даты доставки, примерки и другие на местное время.
Инструменты для визуализации
В качестве интерфейса доступа к данным и визуализации для бизнес-пользователей мы используем SAP BusinessObjects и Power BI. В них мы строим юниверсы и наборы данных на BL-витринах, развивая self-service аналитику. Это означает, что любой сотрудник может запросить доступ к SAP BO и нужному юниверсу, построить отчет в нем или создать дашборд в Power BI.
SAP BusinessObjects
В SAP BO можно просматривать данные с разных точек зрения через диалоговое окно интерфейса и легко редактировать запросы и отчеты.
Бизнес-пользователи сами редактируют и формируют отчеты, добавляют или удаляют ограничивающие фильтры, если бизнес-логика поменялась или появилось дополнительное условие. Например, пользователь хочет в отчете видеть не просто заказанные товары, а только фактически доставленные, тогда он добавляет дополнительный фильтр для этого условия. Можно самостоятельно добавлять в отчет строки и столбцы, менять их, создавать формулы и переменные. Также можно подтягивать ссылки на сайт, чтобы при выгрузке отчета по товарам видеть его изображение и выгружаемые данные.
В SAP BO у нас около 10 000 отчетов, из которых 1300 стоят в расписании на обновление. 10% из них созданы системными аналитиками, остальные — бизнес-пользователями.
Power BI
Это инструмент для визуализаций и отчетов, с помощью которых пользователи могут отслеживать бизнес-показатели онлайн. Дашборды в Power BI используют для проверки статусов заказов, оперативного мониторинга работы автопарка и общего состояния инфраструктуры, а также для отслеживания доступности сервисов доставки в реальном времени.
Отображаемая информация в дашбордах помогает делать выводы о ситуации и оперативно решать проблемы. Например, дашборд с основными показателями использования собственного автопарка (коэффициенты утилизации, доступности, количество транспортных средств, штрафов, ремонтов) помогает мониторить его работу и зафиксировать зоны для улучшения в конкретном городе или подразделении.
Главный плюс Power BI — это user-friendly платформа. При созданных наборах данных пользователи могут сами строить визуализации.
Над чем работаем сейчас и планы на ближайшее будущее
Мы продолжаем работать над текущими и новыми проектами, общаемся с заказчиками из разных департаментов, рефакторим данные, анализируем новые сервисы и создаем витрины по ним, занимаемся автоматизацией бизнес-процессов компании и интеграцией с внешними сервисами.
Из основных крупных проектов — интеграция данных из 1С в пять HR-систем и миграция на новую Axapta 365. А в 2022 году нас ждет миграция из Oracle в Greenplum. Об этом мы напишем новые статьи :)