Привет! Меня зовут Дмитрий Мележиков, я отвечаю за BI в домене Маркетинг и участвую в общих DWH/BI-проектах Авито. Сегодня поговорим о здоровье данных.
В статье расскажу, как мы построили систему HealthScore — метрику здоровья данных. От математической модели и пайплайна сбора метаданных до процесса массовой очистки.
И покажу, почему HealthScore и сертификация витрин важны для AI Copilot. Без белого списка доверенных витрин ассистент может масштабировать ошибки так же быстро, как и инсайты.
В этой статье:
Почему нельзя просто хранить данные, не неся за них ответственность
Как мы создали метрику здоровья данных и из чего она состоит
Как модель эволюционировала: от баллов к Core и автосертификации
Как построили пайплайн сбора метрик
Как субботники и governance-культура помогают повышать HealthScore объектов
Как мы переходим от мониторинга к автоматизации
Про то, как начинался наш переезд из Vertica и Trino, читайте в статье:
✍️ «Trino в Авито два года спустя: от движка к полноценной экосистеме»
Почему нельзя просто хранить данные, не неся за них ответственность
Когда количество витрин в хранилище переваливает за несколько тысяч, классические методы управления качеством перестают работать. Мы столкнулись с этим, когда масштаб нашего аналитического слоя достиг 6700 витрин, распределённых между Vertica и Trino.
Стало невозможно быстро ответить на базовые вопросы: какие данные можно использовать для принятия решений, а какие — неиспользуемое легаси? Кто отвечает за эту таблицу, если автор уволился год назад? Почему важный отчёт строится на витрине, которая падает каждый второй вторник?
На старте проекта мы имели классическую проблему роста DWH. Когда у вас 100 витрин, вы знаете их поимённо, но когда их становится 6700, наступает хаос.
Объясню на гипотетическом примере. Представьте, что вам поставили задачу: посчитать, сколько человек увидели рекламу вашей компании в интернете и кликнули по ней. Это все ваши вводные.
Вы не знаете:
есть ли в компании хоть какие-то данные о рекламе;
если есть — кто их собирает;
где они хранятся: как называется нужная таблица / система / база;
в каком виде они хранятся.
Задачу в любом случае нужно сделать, поэтому вы не сдаётесь и продолжаете искать нужную информации.
Вот, спустя пару дней, вы чудом находите какую-то таблицу с названием dma.ads_2025. При этом у неё нет описания, владельца, в ней куча столбцов с непонятными названиями, и вы не понимаете, что за информация в них хранится.
После множества попыток вы примерно разбираетесь в содержимом таблицы, делаете нужный расчёт и уносите его заказчику. И хотя дедлайн был ещё позавчера, вы не могли отдать расчёты в срок, потому что 2 дня ходили по чатам и пытались что-то найти.
При этом рекламный аналитик Вася на самом деле уже всё посчитал ещё до вас. А ещё его цифры были точнее, надёжнее и актуальнее. Но он назвал свою таблицу test1234, и никак не описал её, поэтому вы не смогли её найти. Как итог: вы сделали двойную работу, ещё и получили не очень хороший результат — ведь можно было просто взять таблицу Васи, в которой данные были точнее, и предоставить расчёты из неё.
И тут мы понимаем: без управления данными всё превращается в хаос, и ценность аналитики резко снижается.
Подобная ситуация вполне может встречаться в компаниях, где сотрудники работают с огромными объёмами данных и витрин. Мы выделили три фундаментальные проблемы, которые могут мешать развиваться:
Размытие ответственности. У витрины формально может быть автор, но, когда дело доходит до работы с ней, может оказаться, что этот человек давно уволился или перешёл в другую команду. А нового ответственного у витрины нет.
Ресурсный голод. Витрины обновляются по расписанию, потребляют CPU/RAM кластера, но если мы не понимаем, что за данные там хранятся и актуальны ли они — мы не сможем определить их реальную ценность для бизнеса.
Отсутствие доверия. Как и в случае с примером выше, аналитики и стейкхолдеры не доверяют имеющимся данным, тратят часы на поиск, валидацию и создание новых витрин, вместо переиспользования существующих объектов. И в связи с этим общая ценность аналитики в компании снижается.
У нас уже была попытка решить некоторые из описанных проблем. Например, мы закрепили основные бизнес-домены за BI-партнёрами, чтобы навести порядок. Именно они в своих зонах ответственности проводили инвентаризацию: искали реальных владельцев для каждой витрины, связывались с аналитиками и добивались, чтобы у каждого объекта был ответственный.
Но даже при таком подходе 100% покрытия достичь не удавалось — не в каждом домене появился свой BI-партнёр, не у каждой легаси-витрины удалось определить владельца. Такие объекты продолжали потреблять ресурсы, но никто не мог гарантировать, что данные в них были актуальны.
Нам нужен был единый инструмент, который позволил бы ранжировать витрины по качеству и здоровью, а затем автоматизировать их жизненный цикл. Так появилась метрика здоровья — HealthScore (HS).
Как мы создали метрику здоровья данных и из чего она состоит
Мы не стали изобретать велосипед и пошли по пути взвешенной оценки. HealthScore витрины — это композитная метрика, которая рассчитывается ежедневно.
Мы разделили понятия Здоровье и Важность. Здоровье (HealthScore) показывает, насколько качественно сделана витрина, а Важность (Importance) — насколько «больно» бизнесу будет от её поломки. Это позволяет нам не тратить ресурсы на лечение идеальных, но никому не нужных таблиц.
Рассчитывать метрики мы решили по таким формулам:
Factor: нормализованная оценка компонента (0–100).
Weight: вес компонента в общей оценке.
Выделили 4 группы базовых компонентов здоровья витрины и 2 компонента значимости. Веса балансировались в ходе экспериментов, аналитики реального распределения и здравого смысла, но базовая логика выглядит так:
Интегральные индексы | Компоненты | Суть, метрики, зачем это нужно |
HealthScore | Data Quality (DQ) | Assurance & Control — мы не верим данным, если тесты падают или их нет. • Coverage: доля колонок, покрытых чекерами, покрытие дата-контрактами; • Control: отсутствие открытых инцидентов и серьёзных чекеров за 30 дней. Cost of Quality — DQ не должен стоить дороже самого ETL. Мы блокируем ситуации, когда на проверку таблицы тратятся ресурсы кластера впустую. • Цена проверок: затраты ресурсов на запуск чекеров не должны превышать x% от стоимости расчёта витрины. |
Performance | Эффективность расчёта — выявляем витрины, которые потребляют ресурсы непропорционально отдаче. • Стабильность: минимизация разброса времени расчёта (разница между p80 и p20 за 30 дней); • Ресурсоёмкость: затраты CPU/RAM на одну выходную строку; • Скорость: устойчивое (p80) время расчёта. Эффективность хранения — борьба с бесконечным раздуванием стораджа. • Scan/Size Ratio: отношение считанных байт к байтам на диске на p50 — cколько тела таблицы реально нужно среднестатистическому запросу, p95 — а бывают ли у нас тяжёлые запросы, которые превращают витрину в проблемного потребителя ресурсов. Эффективность использования — оценка того, насколько удобно и дёшево аналитикам читать эту витрину. • Output/Scan Ratio: отношение байт на выходе к считанным байтам (считаем минимум необходимого); • Сложность джойнов: минимизация количества таблиц в запросах к витрине. | |
Governance | Архитектура и Идемпотентность — защита от дублирования данных и кривых архитектурных паттернов, которые ломаются при перезапуске. • Устойчивость к пересчёту: наличие детерминированной сортировки и фильтров по инкременту; • Чистота модели: одна витрина — одна бизнес-сущность. Tech-слой — только один источник; • Lineage: отсутствие циклических зависимостей. Метаданные и Апстрим — прозрачность и защита от использования мусорных данных. • Описание: заполненность описания таблицы и колонок; • Качество источника: отсутствие в апстриме deprecated, temp или non-prod таблиц. | |
Freshness | Пайплайн и Расписание — витрина может рассчитаться быстро, но если её источник (апстрим) опаздывает на 5 часов, то данные бесполезны. • Critical Path: критический путь построения витрины не превышает SLA по времени и ресурсам; • Guaranteed Sensors: апстрим опирается только на источники с гарантированным временем готовности (DDS); • Постановка витрины на регламент, доля успешных обновлений. | |
Importance | Business Usage | Популярность витрины. Позволяет не тратить ресурсы на починку идеальных, но никому не нужных таблиц. • Размер её даунстрима на регламенте; • Количество ad-hoc запросов; • Количество уникальных пользователей. |
Criticality | Ручной признак повышения значимости. Например, если витрина является частью значимого для бизнеса апстрима. |
Схематично иерархия метрик выглядит так:
Схема показывает, как из базовых показателей качества (Data Quality, Governance, Freshness, Performance) формируется интегральная оценка здоровья витрины (HealthScore). Параллельно рассчитывается важность витрины (Importance) на основе её использования (Business Usage) и критичности (Criticality).
Также мы используем метрику приоритизации витрин (Priority). Она рассчитывается по формуле:
Итоговая метрика Priority объединяет здоровье и важность, позволяя сфокусироваться на проблемных, но значимых для бизнеса объектах.
В результате расчётов мы получили отсортированную таблицу приоритетных витрин, где сфокусировались на витринах с низким HS и высоким Importance.
Как модель эволюционировала: от баллов к Core и автосертификации
Пока мы измеряли здоровье витрин в баллах, стало понятно, что этим сложно управлять: средний балл мало о чём говорит, и на его основе трудно сформулировать конкретные действия. При этом критериев оказалось слишком много, и некоторые из них были неуправляемыми или избыточными.
Поэтому метрика Importance в итоге стала шкалой, по которой мы определяем витрины-кандидаты в Core-слой. Это самые важные витрины, которые мы выделяем на основе их использования и ручной разметки BI-партнёров в доменах.
Например, витрины, на основе которых строятся ключевые дашборды или витрины, участвующие в важных бизнес-процессах.
Мы сфокусировались основных витринах HealthScore. Для нас важно, чтобы данные:
были готовы вовремя;
вызывали доверие;
были удобны в использовании;
рассчитывались с разумными затратами ресурсов.
Исходя из этих принципов мы отобрали факторы из всего набора показателей и разделили их на две группы: assurance-кр��терии и control-метрики.
Assurance-критерии — это требования, выполнение которых можно гарантировать, то есть ими можно напрямую управлять.
Control-метрики — это показатели, которые должны изменяться при выполнении assurance-критериев. Ими нельзя управлять напрямую, но на них можно влиять через выполнение соответствующих критериев.
HealthScore мы стали использовать для сертификации витрин — кандидатов в Core-слой. Сначала определяем важные витрины, а затем оцениваем их состояние: они могут быть здоровыми или нет.
Чтобы получить HealthScore, витрина должна пройти набор assurance-критериев. В большинстве случаев это не балльная оценка, а бинарная проверка: есть пороговое значение, которое витрина либо проходит, либо нет.
Сертифицированная Core-витрина — та, которая выполнила все критерии HealthScore. Такой подход позволяет владельцу витрины или BI-партнёру понимать, какие действия можно предпринять самостоятельно, чтобы выполнить критерий и через какие процессы платформы данных нужно пройти совместно с дата-инженерами, если критерий нельзя быстро исправить.
Таким образом, у нас появляются:
важные витрины-кандидаты в Core-слой — здоровые сертифицированные Core-витрины нездоровые несертифицированные витрины;
все остальные витрины.
Мы стремимся, чтобы пользователи в большинстве случаев работали именно с важными витринами, и чтобы эти витрины были здоровыми, то есть сертифицированными. Для этого в платформенных инструментах, например, в дата-каталоге, мы показываем признаки здоровья и сертификации витрин, а также объясняем, почему витрина не сертифицирована и как это исправить. Это помогает пользователям явно понимать, с какими данными они работают.
Как построили пайплайн сбора метрик
Для расчёта Health Score нужно было собрать метаданные из разрозненных источников, и мы построили следующий пайплайн:
Схема потоков данных:
1. Слой источников событий (Source Layer):
Query Logs. Логи запросов к движкам Vertica, Trino для расчёта метрик популярности витрины (Usage), эффективности их расчёта, хранения и использования (Performance);
DataCatalog. Внутренний каталог данных: описания, владельцы, теги;
Scheduler. Статусы выполнения заданий: успех, ошибка, время старта, финиша;
DQ Service. Результаты прогона проверок качества данных.
2. Calculation Core. ETL-процессы собирают сырые логи, парсят SQL и агрегируют статистику. Расчёт скоринга по формуле. Здесь применяется логика весов, описанных выше.
3. Storage & BI. Результаты, история Health Score и снапшот среза текущего дня. Они пишутся в Trino-витрину мониторинга.
Redash для визуализации:
Overview-дашборд для менеджмента и BI-партнёров, чтобы управлять ситуацией в доменах;
Detailed-дашборд для подробной аналитики факторов выбранной витрины;
Dynamic-дашборд для мониторинга процесса в целом и трекинга динамики изменений.
Архитектура пайплайна сбора и расчёта HealthScore
Где мы теряем доверие
Первое открытие было позитивным: у 90% витрин нашёлся формальный владелец. Казалось бы, в DWH порядок — за каждую таблицу кто-то отвечает. Но как только мы начали спускаться по уровням требований, картина изменилась.
Этап 1. Ответственные за витрины. Из 6700 витрин почти все имели привязку к сотруднику. Но при проверке оказалось, что часть владельцев — это коллеги, которые перевелись в другие домены, и не передали ответственность в старом домене. А также часть витрин при увольнении сотрудников автоматически передавалась руководителям, хотя де-факто они не понимали, что в них происходит.
Этап 2. Наличие документации. Здесь мы потеряли половину DWH: только 48% витрин имели хотя бы краткое описание того, зачем они нужны, и хотя бы 30% описанных полей.
Этап 3. HealthScore ≥ 90. В первой версии мы использовали этот порог, чтобы отделить витрины, которые выглядят почти идеальными по набору требований: описаны, протестированы, оптимально хранятся и обновляются вовремя. Таких объектов оказалось всего 0.2%.
В целом после проверки получилось такое распределение:
Когда мы посмотрели на распределение HealthScore, средний балл по компании составил 63 из 100. Основная масса наших данных находилась в жёлтой зоне: 50–80 баллов. Это витрины-середнячки: они работают, не падают, но у них всегда чего-то не хватает, в основном — тестов и описания.
А также около 23% витрин находились в красной зоне < 40 баллов. Это таблицы с явными проблемами, на которые никто не решался обратить внимание. При этом именно этот хвост создавал основные проблемы на платформе с точки зрения потребления ресурсов и подрывал доверие к данным в целом.
В итоге мы увидели ситуацию, в которой плодим чёрные ящики. Большинство объектов формально живые — регулярно обновляются, даже попадают в SLA и потребляют ресурсы. Но без описания полей и тестов мы не понимаем, что именно и почему считается внутри. Для аналитика или AI-агента использование такой витрины — это риск, а не помощь.
Мы осознали, что понимание данных и доверие к ним — наше узкое горлышко. Если хотим готовить DWH к эпохе AI и LLM-агентов, которые будут сами писать SQL, нам критически важно увеличить число тех самых 0.2% идеальных витрин до 20–30%.
И это важно не только для людей. AI-ассистенту мало уметь писать SQL — ему нужно понимать, каким данным можно доверять по умолчанию. Сертификация витрин как раз и превращает хаос из тысяч таблиц в машинно-читаемый сигнал доверия: что можно рекомендовать, на что ссылаться в ответах и что нести в прод.
Во второй версии вместо единого порога мы перешли к сертификации витрин-кандидатов в Core-слой по набору управляемых assurance-критериев (бинарные отсечки), чтобы статус был прозрачным и чтобы владелец мог им управлять.
Как субботники и governance-культура помогают повышать HealthScore объектов
Чтобы изменить эти цифры, мы запустили субботник — системную активность для повышения здоровья объектов в каждом домене. В рамках первого субботника нас беспокоило качество описания объектов и наличие свободного места в DWH, поэтому мы сфокусировались на следующих факторах:
Описание таблиц и полей в них;
Разметка кандидатов на удаление — можно ли их удалять или нужна реанимация и привлечение внимания к этим объектам;
Проверка партиций в витринах с неэффективным хранением, чтобы уменьшить их объём и удалить неиспользуемое.
По результатам субботника:
⭐ Проверили/улучшили 605 витрин
⭐ Средний показатель здоровья поднялся примерно на 7 п.п.
⭐ Отдельные владельцы подняли средний HealthScore своих объектов на 25+ п.п.
⭐ Получили такую разбивку по зонам: 20% (зелёная), 37% (жёлтая), 17% (красная)
Это позволило замедлить рост объёма данных, перераспределить ресурсы и облегчить переезд витрин из Vertica в Trino, куда мы перевезли уже больше половины витрин.
Итоги и развитие экосистемы доверия. Этот проект подтвердил важную гипотезу: культуру работы с данными можно перевести на язык цифр. HealthScore помог нам выйти из области субъективных оценок в плоскость конкретных метрик.
⭐ Мы видим текущее состояние и проблемные зоны каждой из 6000+ витрин в реальном времени
⭐ Удаление сотен неиспользуемых объектов позволило разгрузить кластер и упростить навигацию для аналитиков
⭐ HealthScore — комплексная метрика, поэтому её значительный рост требует времени и системных усилий
⭐ Высокий уровень здоровья подтверждает надёжность процесса и соблюдение стандартов, но финальная валидация бизнес-логики всё ещё остаётся зоной ответственности экспертов
Но главный инсайт первой волны в том, что даже самый тщательный мониторинг — это лишь половина дела. Чтобы 6000+ витрин оставались здоровыми, поддержка качества должна стать естественной частью жизненного цикла данных на платформе.
Как мы переходим от мониторинга к автоматизации
Сейчас мы движемся от точечных субботников к выстраиванию процессов и среды, в которой поддерживать высокое качество данных станет технически проще и удобнее. Мы смотрим на HealthScore как на часть большого процесса создания Trusted Data в Авито.
Это сквозной процесс, объединяющий уровни: Витрины → Датасеты → Дашборды. Если у вас идеально протестированная витрина, но на ней построен медленный и непонятный отчёт — пользователь не будет доверять результату. И наоборот: визуально безупречный график на проблемных данных — риск для бизнеса.
Именно поэтому мы объединяем усилия: наши метрики здоровья витрин становятся фундаментом для сертификации отчётов. Об этом мой коллега Евгений Мичурин подробно рассказал в статье: «Как мы ввели автосертификацию дашбордов в Авито».
Дальше мы видим 3 вектора развития governance-культуры:
1. Сертификация и Core Data Layer. Вместо того чтобы пытаться навязать жёсткие SLA всему огромному массиву данных, мы фокусируемся на выделении ядра — Core-слоя. Кандидаты в Core-слой — это набор самых важных витрин (Presentation и Tech Layer), которые мы выделяем по фактическому использованию и дополняем ручной разметкой BI-партнёров в доменах (ключевые дашборды и бизнес-процессы).
Мы используем HealthScore как механизм автосертификации витрин-кандидатов: они проходят через набор управляемых assurance-критериев — бинарных порогов — и, либо становятся сертифицированными, либо нет. Такой формат делает статус прозрачным: видно, почему витрина не сертифицирована и как это исправить.
2. Интеграция в семантический слой. Мы стремимся к тому, чтобы здоровье данных использовалось на всех этапах. Переход к описанию логики в коде (Semantic Layer) позволяет автоматически наследовать оценки качества: статус витрины-источника становится прозрачным параметром для всех последующих датасетов и дашбордов.
Следующий слой поверх семантики — доменная база знаний (Knowledge Layer): курируемый набор ключевых витрин, метрик и дашбордов домена с интерпретацией, ограничениями и типовыми сценариями использования. По сути это curated-контент — человеческие аннотации: намерение, смысл и caveats, которые нельзя надёжно вывести ни из схемы таблицы, ни из истории запросов.
OpenAI прямо выделяет этот слой как отдельный уровень контекста для data-агента: Inside OpenAI’s in-house data agent.
3. Платформизация и развитие сервисов автоматизации. Мы расширяем возможности платформы, чтобы автоматизировать рутину. Наши инструменты, такие как Governance Bot, эволюционируют из систем уведомления в полноценных помощников. Они помогают владельцам вовремя актуализировать описания, находить дубли и бережно архивировать объекты, которые перестали приносить пользу, освобождая ресурсы для новых задач.
Ниже представлена схема того, как развитие инструментов платформы помогает автоматизировать управление качеством на разных этапах.
В 2026 году наша общая цель — перенести большую часть запросов аналитиков, как репортинг витрин, так и адхоки, на сертифицированный Core-слой. Это не только снизит нагрузку на инфраструктуру, но и существенно сократит Time-to-market: когда данным можно доверять по умолчанию, аналитики тратят время на инсайты, а не на поиск данных, проверку расчётов и генерацию новых объектов-дубликатов.
Вся статья кратко
Когда количество витрин DWH увеличивается до нескольких тысяч, стандартные способы контролировать качество данных перестают работать: возникает хаос с ответственностью, ресурсами и доверием к информации.
Чтобы решить несколько разных проблем, мы создали метрику здоровья HealthScore. Этот показатель ежедневно оценивает качество витрин по четырём направлениям:
качество данных (Data Quality);
эффективность расчётов и хранения (Performance);
архитектура и метаданные (Governance);
своевременность обновления (Freshness).
Параллельно мы выделяем самые важные для бизнеса витрины-кандидаты в Core-слой — на основе их использования и разметки BI-партнёров в доменах. Так мы фокусируем усилия на данных, которыми реально пользуются.
Также мы разработали конвейер сбора метаданных из разнородных источников. Например: логи запросов, каталог данных, статусы заданий, результаты проверок качества. Результаты агрегируются, сохраняются в Trino и визуализируются через Redash.
После первой итерации сбора данных мы увидели следующее:
формально 90% витрин имели владельцев, но многие из них были неактуальны;
лишь 48% витрин были документированы;
только 0,2% объектов соответствовали высоким стандартам (HS ≥ 90);
средний HS по компании — 63 из 100, при этом 23% витрин находятся в «красной зоне» (HS < 40).
Исходя из этого мы решили уйти от единого порога HS к сертификации витрин-кандидатов в Core-слой по набору управляемых assurance-критериев. Чтобы статус был прозрачным, и им можно было управлять конкретными действиями.
Мы запустили субботники чтобы повысить HealthScore объектов. На них аналитики компании дорабатывают описания, выбирают кандидатов на удаление, оптимизируют хранение витрин.
Благодаря таким субботникам, мы с коллегами проверили 605 витрин, повысили HS на 7 п. п., а доля «зелёной зоны» достигла 20%.
Дальше планируем переходить от точечных улучшений к системной автоматизации: выделим Core Data Layer — ядро самых важных витрин и внедрим автосертификацию витрин-кандидатов в Core-слой по набору управляемых assurance-критериев. Параллельно будем развивать инструменты вроде Governance Bot, чтобы актуализировать описания, показывать причины отсутствия сертификации и бережно архивировать устаревшие объекты.
Это же один из пререквизитов для AI-аналитики: чтобы ассистент давал воспроизводимые ответы, ему нужны:
Сертифицированные витрины Core-слоя как источники по умолчанию;
Семантический слой с логикой в коде;
Доменная база знаний (Knowledge Layer) — интерпретационный слой для ключевых метрик: определения, границы применимости и типовые сценарии.
Следите за обновлениями в наших новых статьях!
И подписывайтесь на коллективный телеграм-канал аналитиков Авито. Там ещё больше полезного о работе и не только: «Коммуналка аналитиков».
А как вы выстраиваете баланс между свободой создания данных и контролем их качества в ваших DWH? Буду рад обсудить в комментариях!
