Data Warehouse – корпоративное хранилище, объединяющее структурированные исторические и текущие данные для последующей аналитики.

**Место DWH в архитектуре управления данными**

Проект создания корпоративного хранилища данных (DWH) отличается значительными масштабами и сроками реализации.

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

**Пример концепции архитектуры DWH для промышленной компании**

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

**Стек, который чаще всего использует в проектах команда Qlever**

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

Один бизнес только начинает путь — у них отсутствует централизованная аналитика, данные разрознены, отчеты готовятся вручную или локально. Другой уже внедрил современные подходы к управлению качеством данных, ввел стандарты, выстроил Data Governance.

В зависимости от этого уровня на старте проекта DWH у компаний возникают уникальные задачи и потребности: от сокращения времени на подготовку текущей операционной отчетности, до масштабирования продвинутой аналитики на новые направления бизнеса.

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

Продемонстрируем важность индивидуального подхода к реализации на примере реальных проектов из нашей практики.

Кейс 1. Свой коннектор к Oracle: когда Debezium подвел

Предпосылки

С задачей построения корпоративного хранилища данных обратилась крупная компания из отрасли ритейл.

На этапе пресейла были определены два источника данных для интеграции: ERP-система на базе Oracle и кассовая система на PostgreSQL.

В дальнейшем на стадии обязательного предпроектного обследования и сбора требований, наши эксперты выявили три ключевых фокуса заказчика:

Перенести всю отчетность с систем-источников в контур DWH, чтобы снизить нагрузку на текущую инфраструктуру
Достигнуть доступности данных по 6 таблицам из 126 на уровне 2 минут от события до появления данных на слое детальных данных Data Detail Store (DDS)
Обеспечить историчность данных для таблиц Oracle без первичного ключа

При этом обязательным требованием клиента стала реализация хранилища с использованием только open-source инструментов.

Для обеспечения KPI по скорости передачи данных из источника в DDS изначально был выбран инструмент Debezium, который позволяет реализовать практику Change Data Capture (CDC) – стриминга изменений данных с низкой задержкой.

Debezium читал данные из логов Oracle и Postgres, отправлял сообщения в Kafka и в дальнейшем должен был записать их в хранилище на Greenplum.

При такой реализации команда столкнулась с «бутылочным горлышком» - на этапе передачи из Kafka количество сообщений вызывало очередь. Debezium не мог справиться с 5000 сообщений за 1–2 секунды на 1 таблицу и писать такой объем данных в Greenplum.

Ситуация требовала поиска альтернативного решения, которое бы заменило Debezium.

***

Варианты решения

Создать свой коннектор, который писал бы в csv, далее передавал файлы в Greenplum

Решение не подошло из-за ограничений, которые предполагает формат csv:

Подтверждение записи
Снижение производительности и скорости
Требуемый большой объем дисков для хранения файлов
Усложнение пайплайна и поддержки

2. Реализовать архитектуру Kafka – Rabit MQ – Greenplum Streaming Server – Greenplum

Несмотря на гибкость маршрутизации, решение не подошло из-за ряда факторов:

Greenplum Streaming Server – платное решение, не соответствующее ТЗ клиента
Сложность архитектуры, избыточность звеньев-брокеров сообщений
Проблемы с производительностью при высокой нагрузке

3. Использовать утилиту Greenplum GPFdist для работы с csv-файлами

Помимо вышеперечисленных ограничений csv, такое решение показало слабую производительность, задержки и отсутствие real-time обновления. Подобные решения хорошо применять, когда требования к обновлению более мягкие.

4. Использовать External web tables, которые бы наполнялись из топиков в Kafka – выбранный вариант

В спроектированном коннекторе Airflow запускает скрипт на Python, который проводит сериализацию сообщений из Kafka в бинарную строку и пишет в External web tables.

Так как External web tables работает напрямую с сегментами, а не с мастер-нодами Greenplum, данный вариант помог повысить производительность до 150 000 сообщений за 30 секунд.

Кроме того, скрипт на Python дал определенную гибкость в параметризации и простоту тестирования и отладки.

Вызовы при создании коннектора и пути их решения

Несмотря на возможность реализации требований клиента, при создании коннектора специалисты столкнулись с некоторыми трудностями:

Изменение типов данных при передаче из Debezium в Kafka
Проблема с часовыми поясами в timestamp из-за разницы часовых поясов магазинов сети, ошибочная и избыточная конвертация в UTC
В источнике данных может меняться структура 6 основных реплицируемых таблиц

Для решения задачи реализован дополнительный функционал Connectivity tool на Python и Airflow, который отслеживает изменения метаданных таблиц и корректирует состав полей как на уровне Kafka, так и на уровне Greenplum.

Источник данных на Oracle реплицируется порядка 2 секунд с помощью Oracle GoldenGate-клиента
Debezium обращается к логам Oracle раз в 5 секунд за данными об изменениях
Если изменения есть, Debezium отправляет сообщения в Kafka
Connectivity tool +Airflow запускается раз в 1 минуту и реплицирует данные в Greenplum
Через 3–5 секунд данные попадают на Staging слой хранилища
Если данных в Kafka нет, скрипт ждет 10 секунд и обращается к данным снова

Остальные 120 таблиц из Oracle реплицировались отдельным потоком, к которому не было жестких требований по скорости появления в DDS.

Где оказались узкие места производительности коннектора и как их обошли

Потеря репликации при сетевых сбоях

Для того, чтобы определить все возможные точки отказа, создали и протестировали Disaster recovery plan – план аварийного восстановления, который учитывает все возможные случаи сбоя настроенной цепочки обновления данных.

Архивация логов

Из-за большого объема данных 40–50 тыс. сообщений Debezium не всегда успевал найти события в online логах Oracle. Для решения задачи мы провели настройки параметров Debezium, определяющих ожидание логов и поиск новых строк.

Перекачка первичных данных

Стандартный коннектор Debezium не может забрать весь объем данных. Для загрузки первоначального объема данных и настройки репликации была применена технология PXF (Platform Extension Framework) в Greenplum и настроен параметр Snapshot no data в Debezium.

Таблицы без ключей

На уровне источника данных Oracle существуют таблицы, обновляемые напрямую ERP-системой. В этих таблицах может быть несколько одинаковых строк заказов с одним набором атрибутов (заказ, палета, товар), но с разной себестоимостью. При этом товары могут быть указаны как одной строкой, по пять штук, так и пятью строками, по одной штуке в каждой.

Для этих таблиц без ключа необходимо было обеспечить полную репликацию с версионностью, чтобы можно было отслеживать истории изменений напрямую в Greenplum.

Первичное обновление данных загружает всю комбинацию заказ-палета в Greenplum. В дальнейшем, при обновлении любой из строк заказа в ERP-системе, заказ еще раз выгружается полностью в хранилище через PXF с новой датой обновления, а старые строки помечаются как неактивные.

То есть, если таблица обновляется N раз, в Greenplum остается N копий данных, каждая со своей меткой обновления, но активная версия существует только одна - в источнике данных.

Итоги

Greenplum работает быстрее изначальной инфраструктуры, решена задача перевода отчетов на DWH
Данные на DDS появляются через 30–40 секунд после формирования в источнике
Kafka отлично справляется с большим объемом данных
Текущая инфраструктура - GP 7.2: 1 мастер + 1 резерв; 2 хоста 16 сегментов; 16 Core + 128 RAM на хост; 2 Tb на хост
Планируется еще 2 сегмента и увеличение общего объема хранилища до 10–12 Тб
Больше не греем вентиляторами космос :)

Кейс 2. Миграция с Qlik: DWH между командами (в условиях командной фрагментации)

Предпосылки

Задачей следующей компании из производственной отрасли было мигрировать с аналитической системы на базе Qlik Sense на PIX BI с готовым DWH. На старте проекта выяснилось, что DWH не было внедрено, а фактически только строилось.

Ситуацию осложняло количество команд, задействованных в проекте:

Team 1 - Внутренняя команда заказчика, которая ранее внедряла Qlik Sense + NPrinting
Team 2 - Внешний подрядчик, который начал внедрение DWH на тех же источниках данных
Team 3 - Команда Qlever DEV, осуществляющая миграцию из DWH на PIX BI
Team 4 - Команда Qlever Support, осуществляющая поддержку Qlik Sense, DWH, PIX BI

Проблематика проекта

Qlik Sense решение содержит кучу legacy – старых неиспользуемых наработок, и нужно определить, что из этого переносить
DWH не проектировалось через доменную структуру, а создавалось копированием логики из Qlik - переносились слои данных в QVD
Внедрявшая DWH внешняя команда покинула проект и не оставила документацию, но оставила технический долг
PIX BI в качестве источника данных для отчетов использует только DWH
Миграция происходит после «технической» сверки, что все посчиталось корректно
Не весь функционал можно было перенести сразу
Бизнес приходит с «новыми» задачами, вклиниваясь в ход проекта

Решение

Для решения возникших сложностей провели аудит внедренного хранилища данных. По результатам аудита:

Масштабировали архитектуру и добавили инфраструктуру, чтобы повысить отказоустойчивость DWH
Провели рефакторинг ETL-процессов
Сформировали базовые процессы и регламенты работ совместно с клиентом
Подключили логирование и мониторинг хранилища, что позволило Team 4 эффективнее осуществлять поддержку DWH

Итоги

Одним из важных итогов проекта стали установленные правила взаимодействия с клиентом:

Синхронизация в командах, расписание статусов проекта, единая среда для коммуникации
Definition of Ready (DoR) – критерии, определяющие, что задачу можно взять в разработку, которые дисциплинировали добавление поправок в ТЗ
Definition of Done (DoD) – критерии готовности и приемки работ по проекту, которые помогли сократить бесконечный цикл согласований и тестирования
Команда поддержки Team 4 стала единым входным окном для постановки задач бизнеса другим командам Team 1 и Team 3

Кейс 3. Бюрократия против DWH: проект в около-госсекторе

Предпосылки

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

Проблематика проекта

Дочерняя компания и холдинг работают в разных часовых поясах (4 часа)

Часть информации при коммуникации теряется, а оперативность в решении вопросов отсутствует

В проекте участвуют разные команды

Компания входит в холдинг, где уже есть собственная техподдержка и команда архитекторов

В проекте участвует внешний подрядчик

Подрядчик должен был настраивать один из источников данных – брокер сообщений Kafka, в итоге функционал был недостаточным для начала наших работ, сроки сдвигались

Дополнительные согласования

Из-за большого количества стейкхолдеров в дочерней компании и холдинге процесс согласования затягивался

Обезличивание данных

Одно из требований службы безопасности компании – обезличивание данных в тестовой среде

Решение

Подвинули время работы команды и перенесли все коммуникации на утренние часы
Зафиксировали критерии готовности Definition of Done (DoD) работ стороннего подрядчика, чтобы меньше зависеть от его сроков реализации
Составили Устав проекта и подготовили матрицу ответственности RACI, к которой обращались в спорных моментах
Ввели «избыточную коммуникацию» - добавляли в переписки и встречи дополнительных участников, которые могли бы согласовать часть работ уже в процессе первой коммуникации
Пошли на компромисс с клиентом и получили на уровне тоталов по периодам точные данные, так как обезличивание данных только бы усложнило проект

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

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

DWH без иллюзий. Три реальных кейса внедрения корпоративного хранилища в ритейле, производстве и госсекторе