Как экономить на DWH и не удалить что-нибудь важное

Сейчас работаю над проектом по оптимизации инфраструктуры в Авито. Размер DWH таких компаний может достигать 2-3 ПБ: тысячи таблиц и десятки тысяч метрик, загрузчиков, расчётов и датасетов. Всё это даёт аналитикам данные, а компании - осязаемый счёт за инфраструктуру.

Под проект собрали совместную команду BI и BDE. BDE - business data engineer. Не спрашивайте, чем он отличается от обычного дата-инженера: оргструктура знает ответ, но хранит его где-то рядом с бизнес-глоссарием 😁

У проекта три метрики:

▫️ Storage - сколько места объекты занимают на дисках и в объектном хранилище.
▫️ Compute, или модный ARV, - сколько CPU-часов мы тратим на расчёты.
▫️ Certified + healthy hits - какая доля реального потребления приходится на сертифицированные и здоровые витрины кор-слоя. Считаем трафик запросов, а не число зелёных табличек в каталоге.

Пилот показал: compute и долю healthy hits можно сдвинуть быстрее, а со storage придётся повозиться. Есть и чит-код. Передаёте дорогую нездоровую витрину в другой домен - ваш compute снижается, доля здоровых хитов растёт. BI-версия генеральной уборки: коробку не выбросили, а переставили соседу 😊

Работу разложили на несколько направлений.

Storage:

1️⃣ Неиспользуемые витрины. Ищем по истории запросов, зависимостям и техническим потребителям, согласовываем с владельцем, удаляем. Это хорошая гигиена, но не всегда большие деньги: основной объём часто лежит в нескольких популярных гигантах.
2️⃣ Table layout. Проверяем партиционирование, бакетирование и мелкие файлы. Компакция уменьшает файловый зоопарк и накладные расходы на чтение
3️⃣ Дубли и зеркала. После миграций старая и новая версии могут годами жить рядом. Переключаем потребителей и убираем лишнюю физическую копию.
4️⃣ Days to keep. Значения 9999 и NULL часто означают «историю никто не обсуждал». Сверяем срок хранения с SLA и считаем объём старых партиций.
5️⃣ Неиспользуемые столбцы. История чтений даёт кандидатов, lineage и поиск по коду защищают от сюрпризов.

Compute:

1️⃣ Начинаем с Парето. Несколько тяжёлых расчётов съедают больше CPU-часов, чем длинный хвост мелких витрин.
2️⃣ Меняем полный пересчёт на инкрементальный и сокращаем окно.
3️⃣ Пересматриваем расписание. Витрина, которую открывают раз в неделю, не обязана обновляться каждые 15 минут. Загруженный график запусков ещё не означает пользу.
4️⃣ Уменьшаем сканирование: фильтруем партиции, не тащим лишние столбцы, упрощаем тяжёлые join и window-расчёты.
5️⃣ Объединяем повторяющиеся вычисления. Один переиспользуемый слой дешевле пяти пайплайнов, которые независимо считают одно и то же.

Certified + healthy hits:

1️⃣ Сертифицируем самые востребованные источники вне кор-слоя
2️⃣ Лечим популярные, но нездоровые кор-витрины: добавляем владельца и документацию, настраиваем проверки, SLA и retention, разбираемся с чрезмерным CPU и storage.
3️⃣ Переводим потребителей на здоровую версию и выводим старые источники из обращения. Зелёный бейдж сам по себе трафик не переключает.

Три метрики требуют разного подхода. Storage - археологии и договорённостей, compute - инженерной работы, healthy hits - ещё и изменения пользовательских привычек. Поэтому мы идём сверху вниз по фактическому потреблению: сначала крупные объекты и популярные источники, затем длинный хвост.

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

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

В целом интересно принимать участие в подобных проектах большей частью инженерных, биай уже давно не только про рисование графиков 😎