Оптимизация хранилища данных
Как понять, какие из накопленных массивов представляют ценность, а от каких можно избавиться, а также стоит ли перерабатывать архитектуру хранилища, рассказывает Татьяна Дидова, архитектор DWH в АЭРО.
На первый взгляд это может показаться неочевидным, но захламление корпоративных хранилищ — чаще всего не техническая проблема, а менеджерская. Если точнее, она связана с отсутствием регламентированных процессов по управлению данными, их сбору, хранению и обработке.
Происходить это может следующим образом: бизнес-подразделение просит собрать отчет для разового анализа метрики, техническая команда его делает. Задача выполнена, отчет больше не нужен — о нем забывают, но данные для него продолжают собираться. Это годами съедает ресурсы, увеличивая стоимость хранения, раздувая время на ETL-функции и усложняя процессы. Да, один отчет не сильно увеличит нагрузку на систему, но если их десятки и сотни, проблема становится существенной.
Отделяем нужное от ненужного
Чтобы реконструировать хранилище, сначала нужно провести инвентаризацию — описать все отчеты, дашборды, витрины и потоки данных, которые их собирают. Этот процесс можно упростить с помощью дата-каталога: он выгрузит сущности, которые существуют в базе, и построит последовательность обработки данных. Анализ хранилища автоматизировать не получится: чтобы понять, какие из массивов данных вам пригодятся в будущем, нужно проводить полноценное исследование.
Я могу выделить два основных способа, которые позволят понять, какие данные должны остаться или пойти в новое хранилище, а от каких можно избавиться. Первый — оценить существующие массивы: насколько часто они используются и используются ли вообще. Например, в каком количестве витрин или дашбордов задействованы эти данные, охватывает ли их тот временной промежуток, по которому строится отчет, существуют ли они в рамках какого-то пайплайна или как отдельные сущности.
Идеально, если у вас сохранился тикет на создание каждого спорного дашборда или витрины. Так вы можете посмотреть, кто из сотрудников ставил задачу, и выяснить, для чего была нужна эта сущность и нужна ли до сих пор. Если тикет не сохранился, а ответственные за него люди давно покинули компанию, можно самостоятельно проанализировать, где используются данные, либо пойти на более радикальные меры — и провести эксперимент. Временно отключите обновление данных и посмотрите, заметит ли это кто-то из сотрудников. Если в течение месяца-двух никто не поинтересовался, почему отчет перестал работать — вероятно, он уже не используется, и можно планировать его удаление.
Готовьтесь к тому, что придется много спорить с командой. Люди могут годами не пользоваться таблицами и логами, но настаивать, что они еще могут пригодиться.
Исследуем бизнес-задачи
Второй способ реструктуризации хранилища — ориентироваться не на существующие данные, а на бизнес-требования. Для этого нужно провести исследование и пообщаться с коллегами — какие метрики смотрят команды, для чего они нужны, где используются дашборды и витрины. Собрав эту информацию, посмотрите: есть ли эти метрики в базе и во всех нужных витринах? Не дублируются ли они? Как они посчитаны и нет ли ошибок в методологии? И уже на основе этого планировать, какие данные подлежат удалению и как переработать отчетность.
Этот способ более сложный и долгий, чем первый, но более эффективный. Он позволяет не просто удалить ненужные данные, но и обновить систему хранения: например, построить новую модель данных, которая будет отражать реальные процессы бизнеса, и возможно, разработать новую методологию расчета ключевых бизнес-метрик. Как я уже говорила, проблема возникновения захламленного архивного подвала — чаще всего вопрос не архитектуры, а неверно выстроенных процессов. И именно ориентация на запросы бизнеса позволит выстроить процессы по-новому, чтобы собирать те данные, которые действительно используются.
Наконец, оба подхода можно совместить: с одной стороны, выявить потребности бизнеса, с другой — проанализировать текущую структуру данных и то, насколько часто они используются в реальности.
Начало реструктуризации
Следующий этап — собственно реструктуризация хранилища и удаление данных. Для начала я рекомендую собрать список таблиц, обновление которых обходится дороже всего: ресурсы ETL, время выполнения запросов, поддержка, ошибки — и приоритезировать их на вынос.
Но обновление хранилища не сводится к удалению ненужного: еще нужно оптимизировать место хранения, поделив его на горячее и холодное, а возможно, и пересмотреть саму модель хранения.
Начнем с горячего и холодного хранения. «Горячие» данные лежат в оперативном доступе — это та информация, к которой часто обращаются. Они могут храниться в полноразмерном формате или несильно сжаты. «Холодные» данные находятся в объектном хранилище: они сильнее сжаты и скорость доступа к ним ниже, чем у «горячих» — зато их дешевле хранить.
Из этого вытекает и принцип распределения данных: чтобы выбрать, какие данные отправить в «горячее» хранилище, а что в «холодное», нужно понять, как часто вы к ним обращаетесь. Если вы храните историю за 5 лет, но для ежедневных задач используете только последние пару месяцев, а остальное смотрите раз в год — нет смысла держать всё в горячем хранении: 4,5 года можно смело убирать в холодное. Бывает и по-другому: если вы строите аналитику в режиме реального времени, но используете для нее данные год к году — вам нужен весь объем в горячем хранении.
Итак, общий принцип — частота обращения, но в реальности есть множество нюансов. Например, возможностей текущей архитектуры может не хватить на поддержку объемов, которые нужны в горячем хранении. И тогда нужно либо модернизировать мощности, либо выяснять, насколько бизнесу действительно необходимы все массивы в оперативном доступе — или же что-то можно спокойно отправить в холодное хранение.
Пересмотр модели хранения
В процессе работы важно понять, хватит ли возможностей хранилища на будущие задачи, если вы планируете масштабироваться и увеличивать объемы данных. Нужно учесть не только планы по расширению, но и специфику базы данных: как часто данные будут обновляться, какие технологии лежат в основе БД, какие потоки данных используются. Например, у вас планируется много данных в оперативном слое, которые будут постоянно обновляться, но вы используете схему «звезда». Скорее всего, она не сможет закрыть все потребности — и вам придется менять модель либо на «снежинку», либо на Data Vault.
Компаниям, которые оперируют более серьезными объемами данных, нужно выбирать между крупными системами: Data Lake и Lake House. Если в основе DWH лежит база данных (реляционная, MPP или колоночного формата), то Data Lake зачастую предполагает наличие S3 или Hadoop, откуда БД забирает сырые данные для обработки. Lake House же полностью строится на объектном хранилище с применением табличных движков и позволяет объединить транзакционность и аналитические возможности.
Решение о переходе с DWH на Data Lake или с Data Lake на Lake House должно подкрепляться реальной необходимостью, поскольку это довольно масштабная задача, которая потребует, помимо прочего, привлечения в команду дорогих высококвалифицированных специалистов. Если у вас используется до десяти терабайт данных и не планируется серьезного расширения, Data Warehouse будет вполне достаточно. Но если объемы данных исчисляются десятками терабайт, есть смысл задуматься о Data Lake, сотнями — о Lake House. Объем данных — это условный критерий, по которому можно провести раздел, важно ещё обращать внимание на характер нагрузки, типы данных, требования к SLA и стоимости дата-платформы.
Заключение
Напоследок расскажу о личном опыте. Однажды я руководила проектом по модернизации хранилища, где хранилось больше 60 таблиц в ODS и почти 200 в DDS: многослойная структура, отчеты на Power BI, а поверх всего — десятки самописных выгрузок в Excel, по которым продолжали жить отчеты. Половиной витрин никто не пользовался, а другая половина не обновлялась, но удалить данные никто не решался. Более 70% объектов за последние полгода вообще не запрашивались.
Когда я начала работу, стало понятно, что проблема глубже, чем просто «лишние» данные: дело в том, что сама модель давно не отражала реальность бизнеса. Например, метрики не были унифицированы, и один и тот же показатель в продуктовом и маркетинговом отделах означал разное. BI-команда сводила все в одну метрику, но ей в итоге никто не доверял.
Пришлось остановиться и задать вопрос: а что мы вообще хотим видеть в новых витринах и отчетах, чтобы принимать бизнес-решения? Мы начали заново описывать смыслы, составляя модель, где каждое поле имело бизнес-контекст и актуальность.
Этот кейс подтверждает тезис, который я приводила в начале: переосмысление хранилища — это всегда разговор о ценности, о процессах и задачах бизнеса. Поэтому начинать надо не с выгрузок и логов, а с вопроса: что именно у вас считается ценной информацией?
Опубликовано 31.10.2025
