Как стать автором
Обновить

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

Блог компании Lamoda Oracle *IT-инфраструктура *Хранение данных *Хранилища данных *
✏️ Технотекст 2021

Всем привет! Меня зовут Юлия Скогорева, я системный аналитик в команде 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. Об этом мы напишем новые статьи :)

Теги:
Хабы:
Всего голосов 19: ↑16 и ↓3 +13
Просмотры 5.6K
Комментарии Комментарии 26

Информация

Дата основания
Местоположение
Россия
Сайт
tech.lamoda.ru
Численность
5 001–10 000 человек
Дата регистрации