Колоночные хранилища и новый темп аналитики: почему месяцами строить DWH уже странно
Когда аналитика запускается за дни, а не за месяцы, меняются и ожидания бизнеса, и то, как стоит проектировать хранилища данных.
Традиционная схема построения корпоративного хранилища данных выглядит примерно так: несколько месяцев на проектирование схемы, потом ETL-процессы, потом согласование с бизнесом, потом доработка, потом запуск. Всё это время бизнес либо ждёт, либо работает с Excel.
Я не говорю, что такой подход был плохим - он соответствовал возможностям инструментов своего времени. Но когда те же задачи можно закрыть за дни, а не за кварталы, продолжать работать по старой схеме - это уже не осторожность, это потеря темпа. Вопрос о том, какая архитектура хранилища подходит для аналитической нагрузки - и когда Hadoop-кластер оправдан, а когда достаточно обычного DWH, - важен до оценки колоночных хранилищ.
Что изменилось с появлением колоночных хранилищ
Классические реляционные базы хранят данные построчно: вся запись о клиенте или транзакции лежит вместе. Это удобно для оперативных операций - найти запись, обновить её, вставить новую.
Аналитика работает иначе: она читает несколько колонок по миллионам строк. При построчном хранении это означает, что из диска читается всё - даже то, что не нужно. При колоночном хранении читаются только нужные колонки. Разница в скорости на больших объёмах - на порядок.
Практический эффект: аналитические запросы, которые раньше шли часами, начинают возвращать результат за минуты или секунды. Это не только удобство - это изменение того, какие вопросы вообще можно задавать интерактивно.
Как меняются ожидания бизнеса
Когда аналитик может получить ответ за секунды, а не за ночь, меняется сам характер работы: появляется возможность проверять гипотезы в реальном времени, а не ждать следующего дня. Менеджер, однажды попробовавший быстрый дашборд, уже не хочет возвращаться к ежемесячным отчётам.
Это создаёт давление на ИТ-отделы и архитекторов данных. "Нам нужна аналитика по этому продукту" больше не звучит как запрос на шестимесячный проект. Оно звучит как запрос на следующую неделю. И если инфраструктура позволяет - это реалистично.
Что это означает для проектирования
Высокая скорость колоночных хранилищ снижает цену ошибки в схеме. Если классический DWH требовал тщательного проектирования "на годы вперёд" - потому что переделка была дорогой - то более гибкие хранилища позволяют итерировать.
Это не отменяет необходимость думать об архитектуре. Но меняет баланс: лучше запустить рабочую схему быстро и улучшать её по факту, чем полгода проектировать идеальную и никогда не запустить.
Ключевые вопросы при проектировании смещаются:
- Какие запросы будут наиболее частыми - и под них проектируем в первую очередь.
- Какой объём данных реально нужен в "горячем" слое, а что можно архивировать.
- Как устроена нагрузка - пиковая или равномерная.
- Кто пишет запросы: аналитики, которым нужен SQL, или инструменты, которым нужен API.
Где ловушки
Скорость колоночного хранилища не означает, что можно не думать о модели данных. Несколько типичных проблем:
Денормализация без меры - таблицы-факты с сотнями колонок, куда всё свалено ради "удобства". Через год никто не знает, что в каком поле.
Отсутствие слоёв - сырые данные, витрины и агрегаты лежат вместе без разделения. Результат: неясно, что является источником правды.
Игнорирование стоимости загрузки - быстрый запрос не отменяет медленную и хрупкую загрузку. Если ETL падает раз в неделю, скорость чтения не имеет значения.
Практический вопрос для руководителя
Если аналитика в вашей компании запускается раз в месяц - стоит спросить: это потому что данные обновляются раз в месяц, или потому что инфраструктура не позволяет чаще?
Если второе - это не технический вопрос. Это вопрос о том, какие решения вы принимаете с задержкой в месяц, хотя могли бы принимать быстрее.