Привет, Хабр! Меня зовут Борис Садовский, я руководитель группы развития корпоративного хранилища данных (КХД) в 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.), и существовали только в виде устных договоренностей между заказчиком и исполнителем. Направление КХД было выделено в отдельное подразделение, куда вошли два программиста с компетенциями в 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 по данным КХД. Хочется отметить, что  целом повысился престиж КХД как надежной системы корпоративной отчетности для эффективной работы всей компании. Если у вас возникли вопросы после прочтения статьи, буду рад ответить в комментариях.  Подписывайтесь на наши соцсети: ВКонтакте: https://vk.com/mangotelecom Телеграм: https://t.me/mango_office