Analyst Days 16: Узри, падаван, путь данных

В апреле 2023 года я выступил на Analyst Days 16 с докладом «Узри, падаван, путь данных».

Этот текст реконструирует основные идеи выступления, но не является стенограммой. Примеры сокращены и адаптированы для статьи; внутренние показатели и детали корпоративных систем я не привожу.

Главный тезис был простым: аналитику полезно понимать путь данных глубже готового отчёта. Требуемая глубина зависит от роли. Бизнес-аналитику и data-аналитику не нужен один набор инструментов, но оба должны уметь проверить происхождение и смысл числа, на котором строится решение.

Контекст, который важно не смешивать

В 2021–2022 годах я работал с банковскими data-платформами и видел, насколько качество и свежесть данных важны для последующих решений. Этот опыт предшествовал раннему real-time продукту 2023–2024 годов и не относится к новому Decision Engine, начатому осенью 2024 года.

Задача доклада была шире одного проекта: показать данные как цепочку преобразований, у каждого звена которой есть владелец, смысл и риск потери качества.

От записи к основанию для решения

В докладе я использовал упрощённую модель из трёх уровней.

Данные — зафиксированное событие или значение: строка лога, транзакция, статус заявки, показание датчика. Без контекста запись может быть корректной, но бесполезной.

Информация — данные, связанные с сущностью, временем, источником и бизнес-событием. Теперь можно понять, что именно произошло и насколько записи можно доверять.

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

Модель не претендует на универсальную теорию. Она помогает задать два вопроса: какой контекст был добавлен на каждом переходе и кто отвечает за правильность интерпретации?

Одна таблица — несколько профессиональных взглядов

Один набор транзакций выглядит по-разному для участников команды.

Роль	Основной вопрос	Типичный риск
Бизнес- или системный аналитик	Что запись означает для процесса и правила?	Верная структура, но неверный бизнес-смысл
Data-аналитик	Какая закономерность подтверждается данными?	Ошибка выборки или интерпретации
Разработчик	Как хранить и обрабатывать набор надёжно?	Производительность и некорректная трансформация
Тестировщик	Какие значения и переходы нарушат сценарий?	Непроверенные границы и исключения
Инженер эксплуатации	Доходит ли поток вовремя и полностью?	Потеря, задержка или незаметная деградация

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

Иллюстративный пример

Представим таблицу транзакций с клиентом, суммой, валютой, временем и статусом.

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

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

Когда данные выглядят убедительно, но ошибаются

Ниже — обезличенный составной пример типового инцидента качества данных, а не описание конкретного банковского контура.

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

Для обнаружения и разбора такого случая полезны несколько дополняющих проверок:

• доля значений по умолчанию контролируется как data quality метрика;
• изменение распределения сравнивается с историей;
• у сегмента есть владелец и понятное бизнес-определение;
• источник и преобразования можно проследить через lineage;
• результат расчёта проверяется не только на тестовом наборе, но и после поставки.

Данные не обладают намерением «врать». Ошибается процесс сбора, преобразования или интерпретации. Поэтому вопрос «откуда взялась цифра?» важнее уверенного вида самого дашборда.

Четыре части пути данных

Хранение. Где находится исходная и производная запись, как долго она живёт, кто может её менять и какой источник считается эталонным?

Обработка. Какие правила применяются, в каком порядке, можно ли повторить расчёт и получить тот же результат? Выбор batch или stream следует из требуемой своевременности, а не из моды на технологию.

Передача. Какие контракты связывают системы, что происходит при повторе, задержке, изменении схемы или частичной недоступности?

Описание происхождения. Где зафиксированы смысл поля, владелец, источник, преобразования и критерий качества? Документация полезна, только если меняется вместе с системой.

Минимальная data-грамотность аналитика

Набор зависит от специализации, но я ожидаю способности:

1. объяснить бизнес-смысл ключевых сущностей и показателей;
2. проверить выборку базовым запросом или вместе с профильным специалистом;
3. отличить отсутствие значения от нуля и неизвестного статуса;
4. спросить о свежести, полноте и источнике;
5. увидеть, где соединение или фильтр меняют состав набора;
6. связать критерий приёмки с проверкой данных;
7. зафиксировать ограничение, если точный вывод невозможен.

Это не требование превратить каждого аналитика в data-инженера. Это способность не передавать ответственность за смысл числа целиком инструменту или соседней роли.

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

---

Реконструкция материала доклада «Узри, падаван, путь данных», Analyst Days 16, 2023.

Подтверждение выступления: карточка доклада в программе Analyst Days 16. Номер конференции уточнён по странице организатора.

Ваш ДПУПП