Как переосмыслить накопленные хранилища данных

Зачастую корпоративное хранилище данных в компании, особенно если с момента его внедрения прошло несколько лет, во многом напоминает старый чердак в частном доме — годами там скапливаются самые разные вещи, но со временем большая часть содержимого превращается в бесполезный хлам. То же самое происходит и с данными: системы обрастают гигабайтами информации, большая часть которой либо дублируется, либо потеряла актуальность, либо не имеет никакой ценности, потому как хранится просто "на всякий случай".

Проблема усугубляется тем, что со временем данные теряют контекст, а отчёты только множатся, но при этом лишь малая часть из них действительно используется бизнесом.

Как следствие, система с каждым годом становится всё медленнее, а затраты на хранение данных и обслуживание системы возрастают.

При этом бизнес продолжает генерировать потребность в новой отчётности, а ИТ-команда тратит время на реализацию этих потребностей и сопровождение возрастающих объемов информации.

Почему хранилища данных превращаются в "свалки"?

1. Организационные проблемы

В крупных компаниях разные департаменты в рамках своих доменов часто фактически используют копии одних и тех же дынных. Например, отдел маркетинга и финансовая служба могут по-разному рассчитывать ROI, используя при этом одни и те же исходные данные в учетных системах, но с разной логикой агрегации и методикой расчёта. Со временем такие "альтернативные версии правды" множатся, создавая хаос. При этом подразделения не в курсе, что уже есть соответствующие потоки данных, их которых можно "вытянуть" нужные аналитические срезы.

2. Человеческий фактор

В корпоративной среде часто действует принцип "лучше перебдеть, чем недобдеть". Аналитики и дата-инженеры предпочитают сохранять все сырые данные, опасаясь, что в будущем может возникнуть потребность в их анализе. Это приводит к накоплению терабайтов информации, 80% которой никогда и ни при каких сценариях не будет востребована.

3. "Работает – не трогай"

Зачастую очередной поток данных разрабатывается как временное решение, для быстрого получения нужного аналитического среза. Но по классике, "Ничто не вечно, кроме временного". Эти потоки данных затем живут годами без должного описания в виде проектной и эксплуатационной документации. Когда внедрявшие это разработчики уходят из компании, новые члены команды боятся трогать "работающий, но непонятный" функционал, по факту создавая новые параллельные потоки вместо доработки и использования уже имеющихся. Как следствие, информация дублируется, нагрузка на систему за счёт наличия параллельных потоков возрастает.

4. Отсутствие культуры управления жизненным циклом данных

Обычно до реализации автоматизированных политики архивации и удаления данных не доходит. В лучшем случае об этом задумываются уже тогда, когда дисковые хранилища начинают исчерпывать свой ресурс. А пока этого не произошло, устаревшие мастер-данные, давно неактуальные исторические данные или же многолетние логи продолжают занимать место в оперативных хранилищах, снижая производительность системы.

Так как же нам определить, что из данных - ценно, а что - нет?

Ценность корпоративных данных — величина не абсолютная, а относительная. Она определяется исключительно тем, насколько информация востребована конечными бизнес-пользователями.

Поэтому, чтобы определить, что из реализованного несет в себе первостепенную ценность, следует:

1. Провести анализ использования отчетов и дашбордов

Современные BI-платформы (Power BI, Tableau, Qlik) предоставляют детальную статистику использования:

• Какие отчеты открываются чаще всего
• Какие визуализации просматриваются дольше других
• Какие фильтры применяются регулярно

Например, если дашборд по продажам по регионам открывают 50 пользователей еженедельно, а отчет по ключевым показателям эффективности блока HR — 1-2 раза в квартал, это четкий сигнал о разной степени востребованности.

Если в вашей BI-платформе нет готового инструментария с аналитикой по частоте использования объектов, обычно как минимум есть соответствующие логи аудита системы, которые позволяют выцепить нужную аналитику и построить соответствующий кастомный отчёт.

2. Провести опросы бизнес-пользователей

Количественные метрики нужно дополнять качественными исследованиями. Проведение структурированных интервью с ключевыми пользователями отчётности помогает понять:

• Какие отчёты используются, есть ли жалобы на производительность/удобство работы с отчётами
• Какие решения принимаются на основе конкретных отчетов
• Какие данные регулярно экспортируются в Excel для последующей "докрутки" (это явный признак несовершенства текущей отчетности)

На выходе мы можем понять не только то, что такой-то отчёт реально востребован, но и уже посмотреть на этот отчёт в разрезе его компонентов. Например, в ходе таких интервью может выясниться, что сложный многостраничный отчет по KPI используется только ради одной таблицы на 3-й вкладке, а все остальное — наследие ушедшего руководителя.

3. Анализ зависимостей данных

Технический аудит позволяет выявить:

• Витрины данных, которые не обновляются месяцами, не используются в отчётах, но при этом содержащие огромные массивы информации
• Показатели, рассчитываемые на постоянной основе, но в итоге нигде не используемые
• Устаревшие ETL-процессы, загружающие ненужные данные

Есть как специализированные инструменты, которые помогают сформировать соответствующее понимание, есть и методики, как провести такой аудит вручную и на выходе получить необходимые выводы.

Что дальше?

Мы отделили ценные данные и отчёты от неактуального "мусора", выполнили миграцию только нужного на новую BI-платформу, либо просто навели порядок в текущей системе.

Но если мы остановимся на этом, пройдет время, и мы окажемся в той же точке, с которой и начали.

Поэтому крайне важно выстроить "процессную" историю, а также в целом внедрять культуру работы с данными. Ниже несколько рекомендаций в части конкретных активностей:

• Настройка и анализ автоматических алертов о необновляемых / неиспользуемых объектах КХД;
• Проведение регулярных опросов ключевых пользователей о качестве отчётности;
• Регулярный анализ статистики использования отчётности ключевыми пользователями;
• Внедрение доменов по областям данных (например, по бизнес-направлениям) и назначение Владельцев данных для каждого из доменов – позволяет закрепить ответственность в разрезе каждого из доменов, что снижает риск последующей потери качества данных;

• Повышение прозрачности и доступности данных, в т.ч. между доменами – позволяет минимизировать случаи дублирования потоков данных, которые возникают от незнания, что требуемая аналитика уже есть в хранилище;

Работа с актуальностью данных - это не разовый проект, а постоянный процесс оптимизации. Этим просто необходимо заниматься, если мы хотим сохранять скорость выполнения запросов на приемлемом уровне и не раздувать затраты на обслуживание BI-системы. При этом важно руководствоваться главным принципом: данные должны работать на бизнес, а не бизнес на данные. Формировать понимание о том, какие данные и отчёты актуальны, а какие нет – нужно в первую очередь через диалог с бизнесом.