02.05.2023 11:59
MangoOffice 1 786 Источник

Привет, Хабр!

Меня зовут Борис Садовский, я руководитель группы развития корпоративного хранилища данных (КХД) в MANGO OFFICE. Решил написать статью о состоянии Data Warehouse (DWH), где рассматриваю проблемы, с которыми сталкивалась  компания в процессе работы с данным, и методы их решения.

Немного истории

Когда я пришел в MANGO OFFICE, DWH имела определенные точки роста.

Продуктивные ETL-скрипты выполнялись на единственном сервере приложений, развернутом в dev-среде без резервирования. На этом же сервере были развернуты FTP- и web-сервер для интеграции с другими ИТ-системами и загрузки данных из внешних источников. Это было потенциальным риском, поскольку в случае выхода из строя dev-сервера приложений все ETL-процессы DWH были бы приостановлены с сопутствующими потерями данных и проблемам с их восстановлением.

Отсутствовали GitLab-репозиторий ETL-скриптов, резервное копирование скриптов и расписание их запуска.

Все изменения кода проводились и тестировались практически «на живую нитку». Это создавало проблемы с разработкой и обновлением ETL-скриптов, сложности при откате к предыдущим версиям в случае ошибок новых версий.

Исходный Python-код ETL-скриптов отличался плохим структурированием в процедуры/модули/библиотеки/подпрограммы.

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

Следует добавить необходимость поддержки двух версий Python (2.7 и 3.8) вместе с окружением и зависимыми библиотеками, для выполнения разных групп ETL-скриптов.

Многие параметры определялись константами в коде вместо чтения из настроек или справочников, совсем не применялась Docker-контейнеризация Python-приложений.

Все эти факторы увеличивали сложность поддержки кода и время диагностики и решения инцидентов и аварий.

Нестабильно работали Python-приложения, были ограничены возможности отладки и диагностики ошибок, что неизбежно приводило к потерям и неконсистентности данных, ошибкам обновления витрин.

В части хранения данных в КХД все было также не идеально.

Продуктивные данные одного источника (биллинг) собирались параллельно на двух инстансах DWH (prod и dev) разными приложениями:

  • Трансформациями Pentaho (dwh-prod), с попыткой выстроить хранилище по модели Data Vault.

  • ETL-скриптами Python (DWH-dev), на базе информации об изменениях в таблицах биллинга и последующей загрузкой этих изменений в полностью идентичные структуры DWH-dev (модель Data Warehouse).

Как следствие, сборка витрин на dev-стенде требовала догрузить недостающие данные с DWH-prod, что приводило к дублированию многих справочников и витрин prod-стенда на dev-стенде.

Полностью отсутствовало резервное копирование данных DWH-prod.

Назначение многих справочников было непонятно, а содержимое справочников часто dev- и prod-стендов дублировало друг друга. Алгоритмы построения витрин не фиксировались в какой-либо системе учета (redmine/confluence/jira/etc.), и существовали только в виде устных договоренностей между заказчиком и исполнителем.

Что мы делали для улучшения DWH 

Направление КХД было выделено в отдельное подразделение, куда вошли два программиста с компетенциями в Python3, Greenplum PL/pgSQL, Docker, GitLab, аналитик и я, как руководитель группы. 

Одновременно с обновлением кадрового состава КХД был проведен ряд мероприятий, направленных на оптимизацию ETL-процессов.

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

Также был настроен мониторинг в Zabbix критичных бизнес-показателей для отдела BI финансового департамента, например, сумм обновления витрин списаний за услуги трафика и абонентской платы .

В ходе рефакторинга избавились от необходимости поддержки двух версий Python (2.7 и 3.8) со своим runtime-окружением и зависимыми библиотеками. После рефакторинга все скрипты стали выполняться в среде Python 3.8.12.

Сейчас большинство новых приложений КХД разрабатываются для выполнения в Docker-контейнерах, с необходимой версией Python и runtime-окружением.

В планах внедрение Apache Airflow в качестве базовой платформы выполнения ETL-скриптов.

Важным этапом в оптимизации ETL-процессов стала закупка оборудования для КХД.

Появилась возможность разделить dev- и prod- стенды КХД по ресурсам гипервизоров и виртуальных машин. Серверы prod-стенда функционально разделены на серверы приложений (выполнение python ETL-скриптов по расписанию) и интеграций (ftp- и web-сервер загрузки данных, хранение бэкапов).

Каждая пара VM — сервер приложений + сервер интеграций — размещена на своем гипервизоре для обеспечения отказоустойчивости ETL-процесса в целом. Ftp- и web-сервер разных гипервизоров объединены в кластер по схеме active/standby (резервный подключается при выходе из эксплуатации активного). Серверы prod-стенда поставлены на мониторинг загруженности ресурсов в Zabbix.

 Следующим значимым этапом было создание GitLab-репозитория скриптов КХД.

В корпоративном GitLab создана группа DWH с общими настройками ci\cd, применимыми для всех проектов группы. Группа постепенно наполнилась репозиториями новых проектов КХД и действующих проектов после рефакторинга скриптов. С помощью механизма GitLab ci/cd значительно упростилась доставка Python-кода в среду выполнения нескольких серверов приложений (идентичная структура папок с тиражированием dev/prod-веток репозиториев в отдельные dev/prod-папки приложений, сборка docker-контейнеров после обновления, резервное копирование перед и назначение прав после изменений).

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

Параллельно было организовано резервное копирование данных и приложений КХД.

  • Резервное копирование данных выполняется три раза в неделю, по схеме два инкрементальных + один полный бэкап, глубина хранения бэкапов — больше одного месяца.

  • Резервное копирование всех приложений КХД и расписания их запуска выполняется каждые два часа, глубина хранения архивов — один месяц.

  • Все значимые рабочие файлы входных/выходных данных, создаваемые в ходе выполнения ETL-приложений, архивируются раз в месяц с глубиной хранения один год.

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

Большая работа была проведена по реорганизации хранения данных КХД.

  • Все продуктивные данные мигрированы и обновляются на DWH-prod, все справочники и витрины обновляются там же.

  • Стенд DWH-dev используется по назначению, для разработки и тестирования новой функциональности.

  • Настроена сервисное обслуживание таблиц DWH-prod, по расписанию выполняется сжатие таблиц разных групп (в интервалы отсутствия запросов к ним) для высвобождения места в базах данных и ускорения работы с таблицами.

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

  • Раздел КХД confluence наполняется документацией по текущим процессам, регламентам, проектам и витринам КХД.

  • Документирование критичных бизнес-процессов и алгоритмов сборки витрин в confluence проводится после запуска проектов в эксплуатацию.

Итоги

Усилия нашей команды привели к заметным положительным результатам:

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

  • Значительно увеличились стабильность и качество обновления данных и витрин.

  • Повысилась эффективность формирования отчетов BI по данным КХД.

Хочется отметить, что  целом повысился престиж КХД как надежной системы корпоративной отчетности для эффективной работы всей компании.

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

Подписывайтесь на наши соцсети:

Аккаунты Mango Office

Комментарии (1)