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

Аналитик, который не работает с данными, — не аналитик

Апрель 2023-го, Москва, Analyst Days 15. Зал человек на двести, третий доклад после обеда — время, когда аудитория обычно клюёт носом в телефоны. Я выхожу на сцену и первым слайдом кидаю тезис: «Аналитик, который не работает с данными руками, — не аналитик». Тишина на полсекунды. Потом — шум. Кто-то в первых рядах кивает. Кто-то на галёрке краснеет и скрещивает руки. Вижу, как девушка в третьем ряду открывает Telegram — видимо, уже строчит возмущённый пост в чат конференции. Значит, попал в нерв. Значит, можно продолжать.

Повторю этот тезис здесь, в начале, чтобы сразу было понятно: это не мотивационная статья про «данные — новая нефть». Это разговор о том, что ты обязан уметь, если называешь себя аналитиком.

Аналитик — это не человек, который рисует схемы в Miro и пишет user stories в Jira. Аналитик — это человек, который понимает данные. Умеет прочитать SQL-запрос и понять, что он делает. Может открыть лог и найти аномалию. Знает, чем отличается LEFT JOIN от INNER JOIN не по определению из учебника, а по эффекту на бизнес-отчёт — когда один даёт 10 000 строк, а другой 8 500, и эти пропавшие 1 500 — клиенты без транзакций, которых ты молча выкинул из аналитики.

Если ты не работаешь с данными руками — ты менеджер, который говорит словами про данные. Это другая профессия. Она тоже нужна. Но это не аналитика.

После доклада ко мне подошёл парень лет двадцати пяти, представился системным аналитиком из финтеха и спросил: «А что, прямо SQL надо знать? У нас для этого дата-инженеры есть». Я ответил вопросом: «А когда дата-инженер в отпуске и бизнес просит срочно проверить цифру в отчёте — ты что делаешь? Ждёшь?» Он замолчал. Вот ради этой паузы и стоит выходить на сцену.

Держи эту мысль в голове — она будет лейтмотивом всего, что ниже.

IT как кровеносная система

Бизнес любит метафоры. Data-driven, digital transformation, AI-first — красивые слова на слайдах стратегий. Но за каждым стоит простая вещь: данные должны течь. Из точки A в точку B, в нужном формате, в нужное время, с нужным качеством.

IT-системы — это кровеносная система организма-бизнеса. Данные — кровь. Если где-то тромб — участок отмирает. Если кровь загрязнена — страдает весь организм. Метафора банальная, но точнее я так и не встретил.

На проекте в ВТБ я это прочувствовал буквально. Мы строили систему персонализированных предложений для клиентов — на тот момент в batch-режиме, но уже тогда закладывали фундамент для того, что позже стало real-time движком. Если данные о клиенте приходят с задержкой — предложение уже нерелевантно. Если данные грязные — предложение не просто нерелевантно, а оскорбительно. Представь: клиент только что закрыл кредит и получает SMS с предложением рефинансирования. Тромб в кровеносной системе.

Три агрегатных состояния

Данные существуют в трёх состояниях, и переходы между ними — суть работы любой IT-системы. Коротко: логи и клики → сигналы и метрики → основания для решений.

Data — сырой материал. Логи, транзакции, сигналы датчиков, клики. Строка в логе user_id=12345, action=click, timestamp=1681548000 ничего не значит вне контекста.

Information — данные в контексте. Когда ты знаешь, что user_id=12345 — это VIP-клиент, action=click — это клик на кнопку «закрыть счёт», а timestamp — это 10 минут после неудачного звонка в поддержку, строка из лога превращается в сигнал тревоги.

Knowledge — информация, подкреплённая опытом и паттернами. Ты знаешь, что за последний квартал 40% клиентов, кликнувших «закрыть счёт» после звонка в поддержку, действительно ушли. И ты знаешь, что удержание обходится в пять раз дешевле привлечения. Теперь у тебя не сигнал, а основание для действия.

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

Четыре роли — одна таблица

Одна и та же таблица в базе выглядит совершенно по-разному в зависимости от того, кто на неё смотрит.

Роль	Видит	Ключевой вопрос	Мыслит категориями
Аналитик	Бизнес-сущности	«Что данные значат для бизнеса?»	Связи, закономерности
Разработчик	Структуры, индексы	«Как эффективно записать/прочитать?»	Производительность
Тестировщик	Граничные случаи	«Что сломается при плохих данных?»	Отказы, исключения
DevOps	Потоки, объёмы	«Данные вообще доходят?»	Инфраструктура

Сухая таблица. Давай наполню её жизнью.

Один пример: таблица транзакций

Возьмём transactions — стандартная таблица в банковской системе. Поля: id, client_id, amount, currency, timestamp, status, merchant_id, category.

Аналитик смотрит и думает: «Средний чек по категории groceries за Q3 вырос на 12%. Это инфляция или изменение поведения? Надо кросс-табулировать с client_segment и посмотреть, кто именно стал тратить больше». Он видит бизнес-историю в числах.

Разработчик смотрит и думает: «Запрос с JOIN на merchants и GROUP BY по category за квартал — это full scan на всю таблицу. Нужен партишн по timestamp и составной индекс (category, timestamp). Иначе дашборд будет грузиться минутами». Он видит производительность.

Тестировщик смотрит и думает: «А что если amount отрицательный? А если currency = NULL? А если timestamp в будущем? А если status = 'pending' уже три дня?» Он видит всё, что может сломаться.

DevOps смотрит и думает: «Таблица растёт каждые сутки — через пару месяцев упрёмся в дисковое пространство. Репликация отстаёт — для real-time дашборда это критично». Он видит инфраструктуру.

Одна таблица — четыре мира. Проблемы начинаются, когда эти миры не пересекаются. Аналитик проектирует модель, не думая о производительности. Разработчик оптимизирует запросы, не понимая бизнес-смысла. Тестировщик проверяет форматы, не зная, какие данные критичны. DevOps мониторит доступность, не видя, что данные текут, но уже невалидные.

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

Когда данные врут: история из банковского мира

Начало 2022-го. Мы запускаем новый модуль персонализированных предложений. Всё протестировано, всё вылизано. Первая неделя в проде — метрики красивые. Конверсия растёт. Руководство довольно.

Вторая неделя — аномалия. Один из сегментов клиентов показывает конверсию в три раза выше ожидаемой. Звучит как победа? Мы тоже так подумали. Секунд на тридцать.

Потом полезли в данные. Оказалось, что ETL-процесс, загружающий клиентские сегменты, при ошибке парсинга молча проставлял дефолтный сегмент — «VIP». Молча. Без ошибок в логах, без алертов. Просто тихо превращал обычных клиентов в VIP-ов.

Итог: часть клиентов получила VIP-предложения, на которые не имела права. Кто-то успел ими воспользоваться. Откат занял неделю, разбор полётов — ещё две. Финансовый ущерб озвучивать не буду, но измерялся он не в тысячах.

Мораль: данные не врут. Данные — это то, что в них записали. Врут процессы, которые эти данные обрабатывают. (Подробнее о рисках и управлении данными — в докладе про BANI-мир.) И если ты, аналитик, не понимаешь, как данные попали в таблицу — ты не можешь интерпретировать то, что в ней лежит.

Четыре паттерна: карта территории

За годы работы с data-intensive системами я выделяю четыре фундаментальных паттерна. Это не теория — это ежедневная реальность.

Хранение. Где живут данные, как долго, в каком формате. Реляционные базы, документные хранилища, озёра данных, in-memory кэши. Выбор хранилища определяет 80% архитектурных решений дальше по цепочке. Ошибка здесь — самая дорогая.

Обработка. Batch или stream, ETL или ELT, SQL или код. У каждого подхода своя ниша: batch — для аналитики за период, stream — для реакции в реальном времени, а когда нужно и то и другое сразу — гибрид вроде Lambda или Kappa. Натянуть batch на real-time задачу — классический антипаттерн, который я видел минимум в пяти проектах. Каждый раз заканчивается одинаково: переписыванием с нуля.

Передача. API, очереди сообщений, файловый обмен, репликация. Каждый стык между системами — потенциальная точка отказа. В enterprise-интеграции это главный источник боли. Интеграционных потоков у нас на проекте десятки, и каждый хотя бы раз ломался в самый неудобный момент.

Документирование. Метаданные, data lineage, каталоги данных, data contracts. Без документации данные превращаются в чёрный ящик. Через полгода никто не помнит, что значит поле flag_3 в таблице temp_data_final_v2. Я не шучу — я видел такие таблицы. В продакшене. В банке.

Тезис, с которого начали

Аналитик, который плохо работает с данными, — не аналитик. Я начал с этого и закончу этим, только жёстче.

Рынок полон людей, которые называют себя аналитиками и при этом не могут написать SQL-запрос сложнее SELECT * FROM. Которые не знают, что такое индекс. Которые не понимают разницу между batch и stream. Которые рисуют красивые диаграммы, но не могут объяснить, откуда взялись числа на дашборде.

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

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

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

---

По мотивам доклада на Analyst Days 15, 2023.

Ваш ДПУПП