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

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

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

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

Помимо этого, сложность 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:

• Подтверждение записи

• Снижение производительности и скорости

• Требуемый большой объем дисков для хранения файлов

• Усложнение пайплайна и поддержки

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

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

• Greenplum Streaming Server – платное решение, не соответствующее ТЗ клиента

• Сложность архитектуры​, избыточность звеньев​-брокеров сообщений

• Проблемы с производительностью при высокой нагрузке​

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

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

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

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

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

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

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

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

1. Изменение типов данных при передаче из Debezium в Kafka ​

2. Проблема с часовыми поясами в timestamp из-за разницы часовых поясов магазинов сети​, ошибочная и избыточная конвертация в UTC

3. В источнике данных может меняться структура 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.