Когда хранилище данных становится узким местом
Признаки того, что корпоративное хранилище данных перестало справляться, и как думать о следующем шаге.
Хранилище данных строилось, чтобы решить проблему: собрать данные из разных систем в одном месте и дать аналитикам возможность задавать вопросы без обращения к транзакционным базам. Несколько лет это работает хорошо. Потом в какой-то момент хранилище начинает тормозить именно то, ради чего строилось.
Я видел этот сценарий достаточно часто, чтобы узнавать его симптомы. Проблема не в том, что хранилище плохое. Проблема в том, что компания выросла, а архитектура осталась прежней.
Как выглядят симптомы
Признаки того, что хранилище перестаёт справляться, редко появляются резко. Они нарастают постепенно:
- тяжёлые отчёты стали выполняться заметно дольше, чем год назад;
- аналитики стараются запускать большие запросы ночью, чтобы не мешать друг другу;
- добавление нового источника данных превратилось в многонедельный проект;
- ETL-процессы всё чаще не укладываются в ночное окно загрузки;
- история данных обрезана по сроку - "иначе не лезет".
Если несколько из этих признаков знакомы - хранилище стало узким местом, а не инструментом.
Почему это происходит
Классическая архитектура реляционного хранилища оптимизирована под определённый класс задач: регулярные отчёты, известные заранее агрегации, относительно небольшое число аналитиков. Когда объём данных вырастает в разы, число пользователей удваивается, а задачи начинают включать ad hoc-исследования и более сложные вычисления - архитектура начинает проседать.
Вертикальное масштабирование - купить сервер мощнее - помогает, но до определённого предела. И стоимость на этом пути растёт быстрее, чем производительность.
Какие есть варианты
Здесь нет одного правильного ответа, но есть несколько направлений, которые стоит оценить.
Оптимизация существующей системы. Иногда проблема не в архитектуре, а в конкретных запросах, схеме или настройке индексов. Прежде чем менять платформу, стоит понять, насколько велик потенциал оптимизации внутри.
Разгрузка через специализированные слои. Можно вынести конкретные тяжёлые сценарии - например, исследовательскую аналитику или работу с необработанными данными - в отдельный инструмент, оставив хранилище для операционной отчётности.
Переход на колоночное хранение. Аналитические нагрузки принципиально отличаются от транзакционных. Системы, хранящие данные по столбцам, а не по строкам, дают кратный выигрыш на агрегациях над большими объёмами. Это уже не экзотика - такие системы существуют и используются в production.
Облачные аналитические платформы. Несколько провайдеров предлагают аналитические хранилища, где вычислительная мощность отделена от хранения и масштабируется независимо. Новая экономика облачных хранилищ данных - где платят за запросы, а не за железо - ранний сигнал того, как эта модель меняет стоимость аналитики. Экономика здесь другая, и её стоит считать честно.
Как не ошибиться с выбором
Прежде чем двигаться к решению, нужно честно ответить на несколько вопросов:
- Какой именно сценарий является проблемой - медленные отчёты, долгая загрузка, неудобство для аналитиков или всё сразу?
- Сколько данных реально нужно иметь в оперативном доступе, а сколько можно архивировать?
- Кто будет владеть новой платформой - есть ли в команде люди с нужным опытом?
- Какова стоимость миграции с учётом ETL-логики, которая накоплена годами?
- Какова стоимость ничегонеделания - во что обходится текущее замедление?
Замена хранилища - дорогой и долгий проект. Но иногда дороже продолжать латать то, что уже не соответствует задачам.