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-системы — это кровеносная система организма-бизнеса. Данные — кровь. Если где-то тромб — участок отмирает. Если кровь загрязнена — весь организм страдает. Метафора банальная, но я за годы работы не нашёл более точной.

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

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

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

  DATA                INFORMATION              KNOWLEDGE
  (сырьё)             (контекст)               (решения)
 ┌─────────┐   структура   ┌─────────────┐   аналитика   ┌──────────────┐
 │ Логи    │──────────────>│ Сигналы     │──────────────>│ Основания    │
 │ Клики   │   + контекст  │ Метрики     │  + экспертиза │ для действий │
 │ События │               │ Алерты      │               │              │
 └─────────┘               └─────────────┘               └──────────────┘
      90% компаний               ▲
      застревают здесь ──────────┘

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 на 200 млн строк. Нужен партишн по timestamp и составной индекс (category, timestamp). Иначе дашборд будет грузиться три минуты». Он видит производительность.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Выбор хранилища = 80% архитектурных решений далее
Ошибка в хранении = самая дорогая ошибка
Batch + Real-time = гибридная архитектура (Lambda/Kappa)
Документирование = то, что все пропускают и все потом жалеют

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

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

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

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

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

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

---

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

Ваш ДПУПП