ODS, витрины, DWH: почему аналитический ландшафт нельзя строить одной аббревиатурой
Каждый слой аналитической архитектуры решает свою задачу, работает с разной скоростью и требует своего владельца. Смешение слоёв - источник большинства аналитических проблем.
Когда в компании заходит разговор о построении аналитической инфраструктуры, очень быстро начинают звучать аббревиатуры. ODS, DWH, витрины данных. Иногда их используют как синонимы. Иногда - как взаимозаменяемые варианты, из которых нужно выбрать один. Это приводит к ошибкам, потому что каждый из этих слоёв решает принципиально разную задачу.
Строить аналитику "одной аббревиатурой" - значит либо переусложнить систему там, где достаточно простого, либо упростить её там, где нужна серьёзная архитектура. Обе ошибки дорого обходятся.
Что делает каждый слой
ODS - операционное хранилище данных - это слой, который агрегирует данные из нескольких операционных систем в одном месте. Его задача - убрать необходимость ходить за данными в несколько разных источников. ODS часто обновляется часто, иногда в реальном времени. Данные здесь близки к исходному виду - не сильно преобразованные, не историзированные в глубину. Это слой для оперативного доступа, а не для долгосрочного анализа.
DWH - хранилище данных - это другая история. Его задача - хранить историю, обеспечивать воспроизводимость отчётов и позволять задавать вопросы "что было год назад". DWH обновляется по расписанию - обычно не чаще раза в день. Данные здесь трансформированы, очищены, согласованы между источниками. Это дорогостоящий в построении и поддержке слой, и он оправдан, когда история и консистентность данных критичны для принятия решений. Amazon Redshift изменил экономику построения хранилища - но вопрос о том, нужен ли вам этот слой вообще, никуда не делся.
Витрины данных - это слой, ближайший к конечному потребителю: аналитику, руководителю, автоматизированному отчёту. Витрина - это предрассчитанный, оптимизированный под конкретный бизнес-вопрос срез данных. Она работает быстро, потому что данные в ней уже подготовлены. Но она зависит от того, что лежит ниже - ODS или DWH, - и не заменяет их.
Почему смешение слоёв создаёт проблемы
Самая распространённая ошибка - строить витрины напрямую поверх операционных систем, минуя промежуточные слои. Это работает в начале: быстро, без лишних шагов. Но со временем возникают проблемы.
Если операционная система меняет структуру - витрина ломается. Если нужно сравнить данные за прошлый год - исходной системы в том виде уже нет. Если два аналитика считают одну и ту же метрику с разных источников - они получают разные ответы.
Другая ошибка - строить DWH там, где достаточно ODS или витрины. DWH требует серьёзных инвестиций в моделирование, ETL-процессы и поддержку. Если компания не принимает решений на основе исторических рядов за несколько лет - полноценный DWH может быть избыточным. Это та же проблема, только взгляд с инфраструктурной стороны - когда оправдан кластер, а когда достаточно нормального DWH.
У каждого слоя должен быть владелец
Технические слои без организационных владельцев не работают надолго. ODS обновляется слишком редко или перестаёт согласовываться с источниками. DWH накапливает нерабочие трансформации. Витрины перестают соответствовать реальным бизнес-вопросам.
Владелец слоя - это не тот, кто его обслуживает технически. Это тот, кто отвечает на вопрос: "эти данные корректны?" Для ODS это обычно ИТ или служба данных. Для витрины - бизнес-функция, которая этой витриной пользуется. Для DWH - чаще всего центральная аналитическая функция или ИТ-служба с участием бизнеса.
Без этого разграничения данные со временем превращаются в то, что никто не готов гарантировать.
Скорость обновления - не технический выбор
Один из ключевых атрибутов каждого слоя - режим обновления. ODS может обновляться несколько раз в день. DWH - раз в сутки или реже. Витрины - по расписанию, привязанному к бизнес-циклу.
Это не просто технический параметр - это договорённость с бизнесом о том, насколько свежие данные нужны для каждой задачи. Если аналитик ожидает свежих данных в витрине каждые полчаса, а обновление происходит раз в сутки - это не технический сбой. Это несогласованность ожиданий, которая должна была быть решена при проектировании.
Практический вопрос перед проектированием
Прежде чем принимать архитектурные решения, стоит ответить на несколько вопросов:
- Какие бизнес-вопросы мы должны уметь отвечать и с какой частотой они задаются?
- Нужна ли нам история - и за какой период?
- Каков допустимый возраст данных для каждой задачи?
- Кто будет отвечать за корректность данных в каждом слое?
- Что произойдёт, если операционная система изменит структуру?
Ответы на эти вопросы определяют, какие слои нужны, а не наоборот.