1 
Содержание
Бизнес в AstraZeneca столкнулся с противоречивыми требованиями к данным: одни запросы требуют проверенных цифр для отчётности, другие — быстрых экспериментов на сырых логах, третьи — долгосрочного архива больших объёмов. Вместо единой системы компания разделила платформу на специализированные компоненты, каждый из которых решает свой класс задач. Такой подход позволил избежать компромиссов в производительности и качестве данных, но потребовал дополнительных усилий по интеграции.
Разделение по типам нагрузок
BI-слой ориентирован на регламентированную отчётность и согласованные метрики. Здесь данные проходят строгую валидацию, версионирование и аудит, чтобы цифры можно было использовать в годовых отчётах без дополнительных проверок. BI-слой обеспечивает единообразие показателей, что критично при внешнем аудите и регуляторных требованиях. DWH обеспечивает более гибкую аналитику, где уже допустимы преобразования и агрегации, но сохраняется контроль над качеством. В DWH данные структурированы для многомерного анализа, что упрощает построение дашбордов и расчёт KPI, при этом история изменений остаётся traceable. Data Lake принимает сырые логи и события, где приоритет — скорость загрузки и возможность быстро запустить эксперимент без долгой подготовки схемы. Data Lake хранит информацию в исходном виде, позволяя дата-инженерам и исследователям тестировать гипотезы на полных объёмах без риска повлиять на производственные отчёты.
Такое разделение возникло после того, как единая система начала тормозить и на отчётность, и на исследования. Каждый слой получил собственный стек инструментов и SLA. При этом между ними сохраняется поток данных: из Lake данные могут попасть в DWH после очистки, а из DWH — в BI после согласования. Разделение помогает распределить нагрузку и избежать конфликтов между тяжёлыми пакетными запросами и интерактивными исследованиями. При принятии решения важно оценить, насколько часто бизнес требует одновременного доступа к разным типам данных и готовы ли команды управлять несколькими средами одновременно.
Интеграция и управление качеством
Чтобы компоненты работали как единое целое, платформа использует централизованный каталог метаданных и правила lineage. Lineage показывает цепочку преобразований от исходного события до финальной метрики, что позволяет быстро находить источник расхождений. Это позволяет отслеживать происхождение цифры из BI вплоть до исходного события в Lake. Без такого механизма расхождения в определениях метрик быстро стали бы проблемой при переходе между слоями.
Дополнительно введены процессы сертификации данных: часть наборов помечается как «золотые» и доступна только через DWH и BI. «Золотые» датасеты проходят дополнительную проверку на полноту и непротиворечивость, что снижает вероятность ошибок в ключевых отчётах. Сырые данные в Lake остаются доступны инженерам и аналитикам для проверки гипотез, но не попадают напрямую в регулярную отчётность. Такой подход снижает риск ошибок, но требует чётких правил доступа и мониторинга использования. Перед внедрением стоит определить, какие именно наборы данных будут сертифицироваться и как часто будет происходить пересмотр правил.
Ограничения и риски при внедрении
Разделение увеличивает количество точек отказа и сложность поддержки. При переносе данных между слоями возможны задержки и расхождения, особенно если источники меняются часто. Командам приходится поддерживать несколько стеков мониторинга и резервного копирования, что повышает нагрузку на администраторов. Дополнительные усилия требуются на согласование SLA между слоями и на обучение сотрудников работе с разными инструментами.
В российском контуре добавляются ограничения на выбор вендоров и облачные сервисы. Приходится ориентироваться на доступные on-premise решения и проверять совместимость с существующими корпоративными политиками безопасности. Отсутствие части западных инструментов вынуждает либо дорабатывать open-source аналоги, либо упрощать отдельные пайплайны. Перед принятием решения стоит оценить, хватит ли ресурсов на поддержку трёх независимых слоёв и их синхронизацию в условиях ограниченного рынка. Также важно рассчитать совокупную стоимость владения с учётом доработок и мониторинга.
Источник
Это краткий разбор материала Habr. Полная версия с примерами кода, схемами и деталями реализации — в оригинале: Платформа AstraZeneca — разделение хранилищ под разные задачи.
Курс по теме — Каталог курсов Школы Больших Данных
