Хранители данных: как устроена работа с DWH в Lamoda

Всем привет! Меня зовут Юлия Скогорева, я системный аналитик в команде Center of excellence дирекции данных и аналитики Lamoda.

Если бизнесу нужны какие-то данные для принятия важных решений, то на помощь приходит наша команда. Мы тщательно изучаем множество микросервисов, чтобы определить, какие же данные нужны для решения бизнес-целей, формируем архитектуру хранилища, пишем скрипты запросов и витрин данных, строим юниверсы, делаем отчеты и дашборды. Большая часть работы не обходится без участия команды DWH-разработки.

В статье я расскажу, как устроено хранилище данных в Lamoda, что находится на каждом его слое, с помощью каких инструментов мы визуализируем данные, сколько у нас отчетов и зачем используем APEX.

Структура DWH 

Data Warehouse (DWH) — это централизованное хранилище данных, агрегирующее данные из разных систем-источников, на которых можно проводить анализ исторических и текущих данных. 

Хранилище в Lamoda построено на Oracle, которое занимает около 60 TB данных, и Vertica на 7 TB.

Наше 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.

Также важно рассказать о том, как мы фиксируем изменения на источниках при загрузке на слой DL, а именно про типы историчности Slowly Changing Dimensions. У нас их три вида: 

• можем хранить первоначальное значение,

• перезаписать старое значение новым,

• добавить новую запись, оставив старую, что позволяет нам иметь историю изменения на источнике.

Типы историчности Slowly Changing Dimensions, применяемые в загрузке на DL:

Наша команда системных аналитиков исследует новые системы-источники и какие данные необходимо забрать в хранилище из этих источников, а еще описывает новые таблицы для команды 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. Об этом мы напишем новые статьи 🙂