Как устроена платформа данных АстраЗенека в России: BI, DWH и Data Lake в одном контуре

Бизнес приходит с запросами разной природы. Одному нужна цифра, которую не стыдно поставить в годовую отчётность, другому - проверить гипотезу за три дня на сырых логах, третьему заархивировать большой массив данных для дальнейшего использования. Cо временем стало понятно, что разные сценарии работы с данными требуют специализированных инструментов и подходов. Поэтому мы разделили платформу на несколько компонентов, каждый из которых отвечает за свой класс задач. Рассказываем, как устроена эта система и что помогает ей работать как единое целое.

Почему одним инструментом не обойтись

Несколько лет назад мы, как и многие, считали, что главный вопрос в работе с данными - это выбор стека. Нужен ли новый BI? Строить классическое хранилище или сразу целиться в озеро? На чём поднимать интеграцию и чем оркестрировать загрузки? Кажется, что стоит правильно ответить на эти вопросы - и дальше всё поедет само.

Не поехало. Чем глубже мы уходили в развитие платформы, тем очевиднее становилось, что запросы бизнеса неоднородны, и разница между ними не в сложности, а в природе.

Одна половина запросов требует воспроизводимости. Отчётность, KPI, показатели для руководства - здесь цена ошибки измеряется деньгами и репутацией, а на вопрос «откуда взялась эта цифра» нужно уметь отвечать через полгода после того, как её показали. Такие данные нельзя грузить быстро: их нужно смоделировать, согласовать определения, встроить проверки.

Вторая половина требует скорости. Бизнес приходит не за дашбордом, а с гипотезой: появился новый цифровой канал, и его потенциал хочется проверить на сырых данных, прежде чем вкладываться в разработку. Здесь ценность в том, чтобы получить ответ за дни, а не за спринты. И если пропустить такой запрос через полный цикл моделирования, он умрёт раньше, чем дойдёт до продакшена - не потому что плохой, а потому что к моменту ответа перестанет быть актуальным.

Обычно компании выбирают одну из двух моделей и живут с её издержками. Ставка на скорость даёт хаос: отчёты противоречат друг другу, одна метрика обрастает десятком вариаций, команды перестают верить корпоративным дашбордам и уходят вести локальные версии реальности в Excel. Избыточный контроль усложняет работу с данными. Добавление нового поля в витрину может растянуться на несколько спринтов, а сами данные в такой системе начинают скорее тормозить процессы, чем помогать им.

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

Фундамент: облако и интеграционный слой

Платформа развёрнута в Yandex Cloud. Главное, что мы получили от облака, - эластичность: тяжёлые расчёты не требуют держать под них железо круглосуточно, а масштабирование под пиковые периоды закрытия отчётности не превращается в проект на квартал.

В нашем облачном хранилище мы используем managed сервисы от Яндекса:  YC IAM, YC Lockbox, YC KMS, YC Object Storage, YC Managed ClickHouse, YC Managed PostgreSQL, YC Managed GitLab, YC Managed Airflow, YC Audit Trails, YC Monitoring и другие.

Интеграционный слой объединяет данные из различных источников. Их загрузка и дальнейшая обработка выстроены как единый процесс: данные загружаются в Yandex Object Storage, далее с помощью Airflow происходит оркестрация и перенос данных на следующий этап обработки. Развилка происходит здесь: структурированные корпоративные данные уходят в DWH и проходят полный цикл моделирования, а массивы данных оседают в Data Lake в исходном виде. Решение принимается не по объёму данных, а по тому, к какому классу относится запрос, ради которого источник подключают.

BI: единый язык компании

Направление BI появилось в нашем ландшафте первым. И не потому, что компания «повзрослела», а потому что возникла потребность договориться о терминах. До этого у каждого подразделения была своя выгрузка и свой способ считать одну и ту же метрику.

BI закрыл три задачи: единая витрина вместо десятка выгрузок, централизованное управление доступами (RBAC) и максимальная прозрачность - стало видно, кто чем пользуется. Но по мере роста мы столкнулись с ограничением, о которое спотыкаются все: дашборд не решает проблему мусора на входе. Если данные льются из разрозненных систем без контроля, красивая визуализация просто быстрее доставляет ошибку до руководства.

В качестве корпоративной BI-платформы мы используем Power BI. Выбор был связан с его зрелостью, сильными позициями на рынке, наличием web- и mobile-версий, а также возможностью работы в on-premise-контуре. Это было важно и с точки зрения инфраструктуры, и в контексте импортозамещения. Разработка организована по трём средам: dev, test и prod.

Сегодня BI-платформой пользуются около 1900 сотрудников, из них примерно 1500 - активные пользователи в месяц. В продуктиве поддерживается более 90 отчётов. При этом BI для нас - не просто набор дашбордов, а рабочий инструмент, встроенный в повседневные процессы бизнеса.

Во всех отчётах действует ролевая модель доступов: используются статические и динамические роли, завязанные на AD-группы и логины пользователей. Что касается аналитики в Excel, мы не рассматриваем её как проблему: это удобный инструмент для быстрых локальных задач, а BI при этом остаётся единым источником доверенных метрик и управленческой отчётности.

Процесс создания нового дашборда выстроен последовательно:

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

Показательный пример - отчёт для полевой команды Х. Раньше перед каждой встречей сотрудники вручную собирали данные из нескольких отчётов и выгрузок. Мы сделали единый дашборд с автоматической фильтрацией, который собрал все основные показатели в одном месте. В итоге отчёт стал для команды ежедневным рабочим инструментом и заметно сократил время на подготовку.

DWH: контур воспроизводимости

За развитие DWH в нашей платформе отвечает команда во главе с руководителем разработки и архитектуры. Хранилище - это контур, где рождается официальная цифра. Общая модель данных, автоматизированные пайплайны (ETL/ELT), проверки качества на уровне загрузки, зафиксированное определение каждого KPI. Именно сюда идут за ответом на вопрос «какая цифра правильная» - и именно здесь мы можем восстановить историю любого показателя.

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

Долгое время нам казалось, что на DWH архитектурная эволюция и заканчивается: единый источник истины построен, данные живут по строгим правилам. Ограничение вскрылось с ростом экспертизы - стало приходить всё больше запросов, которые физически невозможно заранее заложить в жёсткую схему.

При этом сложность системы определяется не только объёмом: даже сравнительно небольшой массив данных может быть сложным из-за большого количества атрибутов, метрик и распределений, которые необходимо хранить и анализировать.

Цифры и факты:

Data Platform Status, 07.2026

Общая схема решения:

Сложный кейс «Интеграция с системой МДЛП»

Решение представляет собой систему сбора, хранения и анализа данных из системы MDLP в облаке Yandex Cloud. На представленной ниже диаграмме, изображен процесс движения данных от MDLP API к On-premise DWH.

Данные с использованием Managed Airflow извлекаются из API системы MDLP, сохраняются в сыром виде в бакете, предназначенном для хранения необработанных данных источника. После этого они преобразуются в табличный формат и, в завершение, передаются в локальное хранилище данных (On-premise DWH).

Архитектура состоит из следующих компонентов:

• Yandex Lockbox - хранение секретов учетной записи, сертификатов

• Yandex KMS - ключи шифрования/дешифрования секретов

• Yandex IAM - учетные записи, роли, права доступа

• Object Storage - s3 совместимое хранилище

• Managed Airflow - оркестрация процессов загрузки данных платформы данных

• Data Proc - Spark кластер для преобразования и обработки данных

• Managed ClickHouse - аналитическая СУБД для работы с загруженными в Data Lake данными при помощи языка SQL

• MDLP Connector - опциональный модуль для загрузки данных из MDLP API, если существующий в AZ Java загрузчик вполне может быть сохранен без нарушения общей архитектуры

• API Gateway и Yandex Cloud Function - для организации Pull-механизмов выгрузки данных

• Legacy - legacy хранилище данных MDLP

Доступны следующие опции к данным для Ad-hoc анализа:

• DBeaver - универсальный инструмент для работы с различными базами данных, в том числе для работы с ClickHouse

Data Lake: контур неопределённости

Data Lake развивается командой во главе с менеджером по исследованию данных как отдельный контур для работы с внешними данными и исследовательскими задачами.

Озеро появилось как ответ на запросы, которые не проходят через DWH по срокам. Новые цифровые каналы, внешние дата-сеты, исследовательские инициативы - во всех этих случаях заказчик приходит с гипотезой, а не с готовым требованием к витрине.

Мы сразу отказались от идеи считать озеро «убийцей DWH» или следующей ступенью эволюции. Для нас это песочница и пространство для работы с неопределённостью. Если хранилище отвечает на вопрос «какая цифра официальная», то озеро - на вопрос «а есть ли здесь вообще что-то интересное». Данные попадают туда в сыром виде, и работать с терабайтами исходных данных можно задолго до того, как эти данные причешут и разложат по реляционной модели.

Забавный побочный эффект: в каком-то смысле озеро вернуло нас к ощущению свободы времён Excel. Больше гибкости для исследования и проверки гипотез, но уже в управляемой среде с необходимыми требованиями к доступу и безопасности. А под капотом - облачные мощности и Python вместо файла на сетевом диске.

Сегодня в нашем озере данных «плещутся» сведения более чем из 60 источников, охватывающие исследовательские, цифровые, маркетинговые и операционные направления.

Хранятся данные в двух форматах: в виде исходных данных в  YC Object Storage и в структурированном виде в ClickHouse. Решение об использовании ClickHouse или DWH для работы с данными принимается в зависимости от дальнейших целей работы с данными.

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

Один из первых кейсов использования Data Lake - архивация RWE исследований. Благодаря использованию инструмента мы теперь можем не только не потерять данные, но и повторно их использовать, проверяя новые гипотезы (конечно же после проверки возможности их повторного использования). Также на базе озера данных у нас появилась возможность объединять данные исследований. Для удобства работы мы унифицируем структуру и названия полей в исследованиях в единый SDTM стандарт.

Data Catalog: навигация по ландшафту

Развитие Data Catalog и Data Governance в нашей платформе курирует менеджер по управлению данными.

Как только компонентов становится больше двух, возникает новая проблема: данные есть, но найти их сложнее, чем собрать заново. Каталог - это связующее звено ландшафта и по сути корпоративный поисковик по данным. Сотрудник за пару кликов находит нужный дата-сет, видит его происхождение (Data Lineage) и уровень доверия к нему.

Каталог решает не техническую задачу, а экономическую. Он превращает данные в переиспользуемый актив: если аналитик видит, что нужная витрина уже существует и кто-то за неё отвечает, он не пойдёт строить восьмую версию того же самого.

Чтобы этот подход работал, каталог должен охватывать значимую часть корпоративного ландшафта данных. Поэтому сейчас мы активно его наполняем: система уже сканирует метаданные более чем из 20 систем, включая DWH и BI, и охватывает более 10 тыс. таблиц и более 200 отчетов, в том числе 90 продуктивных. Бизнес-глоссарий содержит более 500 объектов. Но найти нужные данные недостаточно - важно понимать, насколько им можно доверять. И здесь мы переходим к следующему элементу платформы.

Data Quality: проверки в потоке данных

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

Само качество мы оцениваем иначе - проверками, встроенными прямо в потоки данных. Полнота, консистентность, соответствие справочникам, дубли, разрывы в истории считаются в пайплайне ещё до того, как данные дойдут до витрины пользователя. Это уже отдельный контур, а не каталог: проверки живут в загрузках и измеряют качество на потоке, аномалия ловится на входе, а инцидент заводится автоматически, без участия человека. Каталог лишь показывает результат этой работы как уровень доверия.

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

Как это работает вместе

Ценность набора в том, что каждый запрос находит свой маршрут. Вопрос «какая цифра официальная» уходит в DWH и возвращается воспроизводимым ответом с известным происхождением. Вопрос «есть ли здесь инсайт» уходит в озеро и возвращается быстро, но с честной пометкой, что это эксперимент, а не отчётность.

Самое интересное происходит на стыке. Сильные аналитические продукты обычно рождаются как черновой эксперимент в озере: кто-то проверил гипотезу на сырых данных, показал результат, гипотеза подтвердилась. Дальше начинается промоушен - дата-инженеры переносят логику в промышленный контур, описывают модель, вешают проверки и SLA. То, что в озере жило как ноутбук одного человека, становится витриной, которой пользуется вся компания.

Так DWH обеспечивает надёжность core-бизнеса, озеро - буфер для инноваций, а вместе они закрывают оба типа запросов без выбора между скоростью и доверием.

Что удерживает конструкцию от распада

Набор компонентов сам по себе не работает. Мы видели достаточно ландшафтов, где всё перечисленное выше есть, но данным всё равно никто не верит. Разница не в технологиях, а в том, есть ли у данных хозяин.

Соблазн решить это жёсткими правилами велик, особенно в фазе масштабирования. Но контроль ради контроля не производит качество, он производит сопротивление. Поэтому мы вкладывались не в регламенты, а в три вещи.

Роли. Мы сознательно разрушили стереотип, что за чистоту таблиц отвечают только дата-инженеры. Владельцы данных у нас - бизнес-лидеры, то есть те, кто понимает физический смысл метрики и теряет деньги, если она врёт. Рядом работают дата-стюарды, дата-партнёры и ответственные за качество. У каждой значимой сущности есть конкретный человек, а не абстрактная «ИТ-ответственность».

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

Автоматизация рутины. Всё, что можно проверить автоматически, проверяется автоматически. Человеческое внимание - дефицитный ресурс, и тратить его на сверку выгрузок мы считаем расточительством.

Это и есть та часть, которую принято называть Data Governance. Мы предпочитаем формулировать иначе: это не надзорный орган, а условие, при котором набор компонентов превращается в платформу.

Единый производственный процесс

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

Цикл выглядит так. Всё начинается с бизнес-потребности, но первый шаг после её осознания - не разработка, а взгляд в каталог: что по этой теме уже реализовано. Часто оказывается, что нужный показатель или витрина уже существуют, и задача сводится к переиспользованию, а не к построению восьмой версии того же самого. Дальше требования оформляются в BRD, и он не живёт в вакууме: термины в нём ссылаются на бизнес-глоссарий, а данные - на конкретные таблицы и витрины из каталога. Те же ссылки перетекают в HLD и FSD, так что на всех этапах команда говорит об одних и тех же объектах, а не о похоже названных сущностях. После завершения работ всё созданное и изменённое описывается обратно в каталог - и эти описания становятся входной точкой для следующего запроса. Круг замыкается.

Честно говоря, самое слабое место здесь - самый первый шаг. Заглянуть в каталог перед стартом - это договорённость, а не жёсткий гейт, и её периодически обходят: под давлением сроков проще сразу начать делать, чем сначала проверить, что уже есть. Мы решили не воевать за соблюдение регламента, а встроить в процесс живого человека. Команда Data Governance участвует в производственном цикле напрямую: Data Steward проверяет термины и показатели, помогает системному аналитику и архитектору на этапе анализа и страхует ту дисциплину, которую нельзя гарантировать одними правилами. Финальную приёмку документации тоже закрывает он - проверяет, что все созданные и изменённые объекты действительно описаны в каталоге. На этом шаге петля перестаёт быть договорённостью и становится условием сдачи работы.

У процесса есть прямая зависимость, о которой стоит сказать прямо: он работает ровно настолько, насколько наполнен каталог. Если объект не описан, петля рвётся - человек не находит существующее и добросовестно городит дубль. Поэтому наполнение каталога для нас не операционная рутина, а условие, без которого весь производственный процесс постепенно деградирует. И именно поэтому мы вложились не только в саму систему, но и в роль, которая следит за её актуальностью.

Data Award 2026

Прозрачность этих метрик и эффект от переиспользования данных помогли нам получить признание профессионального сообщества на премии Data Award 2026 в номинации «За командную работу». Отмечен проект по созданию единой экосистемы управления корпоративными данными на базе российской платформы RT.DataGovernance.

Строили не в вакууме. Со стороны «АстраЗенека» мы взяли на себя пилотирование и адаптацию процессов под фармацевтическую специфику, коллеги из Axenix отвечали за методологию, ролевую модель и настройку каталога, а команда TData закрыла техническую часть - развёртывание, интеграции и поддержку.

Сейчас каталог в активной стадии наполнения контентом. Ожидаемые эффекты: сокращение Time-to-Data с нескольких дней до минут по ключевым доменам, уход от дублирования аналитических активов, мониторинг качества в едином окне и оптимизация закупок внешних дата-сетов за счёт их обязательного документирования.

Вывод

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

"Наш подход - экосистема вместо контроля. Мы отказались от тотального контроля сверху и строим экосистему качества данных, включающую инструменты, процессы и роли, где каждый элемент усиливает все другие", - Александр Мамонтов, руководитель Chief Data Officer (CDO).

Поэтому зрелую платформу нельзя купить у вендора и внедрить приказом. Её можно только вырастить - шаг за шагом, вместе с продуктами, процессами и инженерной культурой компании. Пожалуй, именно это отличает data-driven организацию от компании, которая просто закупила модные технологии.