Дайджест №2

Приветствую любителей аналитики!
Давайте-ка немного вспомним, что было здесь интересного за последние пару недель.

Прошлые вспоминалки
Дайджест №1

Аналитика для бизнеса
Роли аналитиков
Пара слов о ETL-процессах
Цикл жизни витрины данных

Аналитика для жизни
Ритуалы для работы
Пара слов о самооценке
Как принимать решения

Техническое задание на витрину данных

Приветствую любителей аналитики!

Итак, витрина данных начинается с хорошего ТЗ.
Расскажу, исходя из своего опыта, каким оно должно быть, чтобы задача выполнилась без проволочек, а результат получился качественным.

В задаче на создание витрины должны быть отражены следующие сведения:
* Заказчик - какой отдел и какой сотрудник нуждаются в витрине.
* Назначение витрины - что ожидает выяснить потребитель, анализируя витрину.
* Перечень столбцов с описанием их смысла и логики их получения
* Фильтры: сегмент, период и т.д.
* Пример результата в виде небольшой таблицы с ожидаемыми значениями
* Дополнительные разъяснения: отсылки к другим витринам, ссылки на документацию, цитаты заинтересованных лиц и т.д.
* "Юнит-тесты" (по возможности) - правила, которые должны выполняться в витрине: диапазоны значений, взаимосвязь/согласованность полей, допустимость пустот, возможные тренды и т.д. То есть, всё что может помочь протестировать витрину, понять, что данные получились качественными. (К этому вопросу мы еще подойдем.)

Обычно ТЗ на витрину составляет бизнес-аналитик или сам дата-аналитик, словом, специалист, разбирающийся в сути исследуемого объекта, и представляющий техническую сторону.

Всем успешного взаимодействия!

А это пост для вопросов от участников вебинара Simulative)
Пишите в комментарий, друзья!

Напряжение или расслабление?

Приветствую любителей аналитики!

У достаточно активной и целеустремлённой личности в какой-то момент может возникнуть жизненное противоречие.

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

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

Как разрешить этот конфликт? Как найти грань между необходимостью работать и необходимостью отдохнуть?

Константин Николаич Дыкин, коуч, который мне когда-то очень помог, учил, что как только мы достигаем точки Z, в которой дело перестает нас энергонасыщать, вдохновлять, следует остановиться. Передохнуть, осмотреться, восстановиться.

Автор книги "Сила воли. Как развить и укрепить", Келли Макгонигал пишет, что сила воли - это "мышца", её можно тренировать; а также, что первый признак усталости - это еще не недостаток энергии.

То есть, имеем два подхода

К. Дыкин
Дело начинает истощать? Остановись и подумай, что не так:
* кончилась энергия?
* неверный путь?
* нет мотивации?
* нет инструментов или материалов?
Часто точка Z - это признак не столько упадка сил, сколько неверности цели.
Если цель не вдохновляет на продолжение, значит следует задуматься о ней.

К. Макгонигал
а) Мозг стремится сберечь энергию для трудных времён при достижении её порога.
Но трудных времён не будет! Можно тратить ещё!
б) Если чаще тренировать силу воли, то продолжение работы будет даваться легче.

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

Нюансы сбора данных

Приветствую любителей аналитики!

Сбор или досбор данных - зачастую самый непредсказуемый этап в разработке витрины. Потому что за данными приходится обращаться к неким источникам, которые мы не знаем и не контролируем.

Покажу-ка некоторые нюансы, с которыми мне приходилось сталкиваться.

Источник: базы данных
Требуемые данные находятся в базах приложения/продукта компании, на которую мы работаем. Казалось бы, в чем проблема, это же наши данные!
Как бы да, но нет.

* Разработчики БД - не аналитики, это другая команда. Получить информацию от них о том, где что лежит и как с чем связаны разные сущности, дата-инженеру бывает весьма непросто. Потому что время программистов дорогое, и их часто ограждают от действий, не связанных с разработкой продукта непосредственно. В том числе от консультаций просителям данных (ведь программисту нужно понять вопрос и покопаться в БД, чтобы найти ответ, а это займёт время).

* Документация к БД традиционно либо неполна, либо не актуальна, либо отсутствует, либо представлена в виде, понятном только самим разработчикам.
Именно добыча точных сведений о данных (т.е. метаданных) обычно занимает большую часть времени на этапе сбора. А дальше-то дело пойдет - настроил стандартный пайплайн или даг Airflow и готово. Ну, еще на мониторинг качества поставить хорошо бы, но это тоже стандартизированный процесс.

* Данные в БД часто неконсистентны, содержат баги, несогласованность, пропуски. За качеством данных, по идее, должны бы следить владельцы (оунеры) БД, но это уж насколько компания созрела для такой "роскоши".
Вот пример проблемы: произведено руками срочное изменение в БД каких-то строк по заказу руководства, а дату обновления строки исправить забыли. Значит, эти строки не будут выбраны при сборе как изменившиеся, не обновятся в аналитическом хранилище и в отчетности не отразятся эти изменения! И никто даже не узнает об этом!

Продолжение следует...

А чорт. Только щас пришло в голову, что аналогия между котлетой и сырыми данными некорректна. Ведь котлета уже готовая!

Нюансы сбора данных (продолжение)

Приветствую любителей аналитики!

Источник: API внешнего сервиса
Когда требуется тащить что-то из чужого веб-инструмента, встаёт, прежде всего два вопроса:

* отдаёт ли API требуемые данные? Например API Google Analytics 4 не отдает сырые хитовые данные. Только сводные и хоть ты тресни (ну или используй BigQuery как коннектор)

* насколько адекватна и внятна документация поставщика API? К сожалению, часто приходится добывать нужное методом тыка или в тягомотной переписке с техподдержкой сервиса.

Источник: Файлы (например, Яндекс.Таблицы)
Используется, когда автоматизация невозможна или неоправданно сложна/долга.
Очевидные задачи сбора данных через файлы:

* Организация регулярной поставки новых файлов. За это может отвечать конкретный человек или несколько человек, если файл имеет долгий путь еще до того как попадет в поле внимания дата-инженера.

* Корректность заполнения файлов, а также неизменность формата данных. Ручной ввод и слабо поддающиеся стандартизации процессы формирования и передачи файлов могут принести изрядно хлопот.

Причины проблем, вытекающих из этих задач, тривиальны: люди ненадёжны)

Короче, задачи дата-инженера, зависящего от поставщиков данных, наполняют его жизнь безудержным весельем и часто удлинняют time to market витрины.

Мотивация - одна из наиболее интересных для меня тем.
Что движет людьми?
Почему они тратят драгоценные энергию и время на некие дела?
И как их замотивировать?

Последний вопрос мне особенно интересен как руководителю команды.

Наткнулся в своих архивах на короткую выписку из книги "Драйв: Что на самом деле нас мотивирует" Дэниэла Пинка. Убей бог, не помню, читал её или нет, но пунктики мне понравились. Кажется, я стараюсь их применять в работе (получается или нет - об этом пусть расскажут мои ребята, если захотят). Вот эти пунктики:

Три компонента мотивации команды.

1. Автономность. Сотрудник должен понимать свою ответственность. Тимлид должен разрешить ему ошибаться в допустимых пределах.

2. Мотивирующая цель. Сотрудники должны понимать общую цель и осознавать, какой вклад они вносят в неё.

3. Мастерство. Должна быть возможность для людей проявить свои лучшие качества, узнать новое, в чём-то быть лучшим.

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

Разработка витрин данных

Под витриной данных мы понимаем таблицу с готовыми к анализу данными.

Витрина создаётся из сырых данных путём их преобразований. Бросим беглый взгляд на эту кухню.

Что реализуется в витринах
* очистка и починка данных
* бизнес-логика - процессы и алгоритмы и всяческие нюансы, описанные заказчиком
* расчет метрик
* организация данных удобным для анализа образом
* костыли для совсем частных случаев

(Пока не будем трогать всякое машинное обучение и прочий рокет-саенс)

Для решения этих задач используются различные операции:
* объединение данных из разных источников, для обогащения информации
* агрегация
* сегментация
* фильтрация
* вычисления
* "уплощение", т.е. преобразование полей с массивом к множеству строк
* сопоставление (мэппинг)
и другие.

В качестве инструментов используются обычно SQL и/или Python.

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

Частота обновления зависит от требовний к аналитике. Мы вот обновляемся раз в сутки.

Обновление каждой витрины производится одним из способов:
* полный перерасчет и перезапись всей таблицы
* дополнение таблицы новыми строками - возможно, если старые строки точно не должны меняться
* перезапись последних N периодов (например, 30 дней) - когда данные в источнике могут меняться задним числом некоторое время. Например, расходы в рекламных системах могут корректироваться - возвращаются деньги за фрод-клики.

Когда создан запрос, реализующий витрину, необходимо проверить корректность данных. Как это сделать - отдельный большой вопрос, о нем в следующий раз.

Короче,
рыжий котик - это будет дата-инженер,
белый котик - дата-аналитик,
полосатый - занимается вопросами саморазвития

Дайджест №3

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

Прошлые вспоминалки
Дайджест №1
Дайджест №2

Аналитика для бизнеса
Техническое задание на витрину данных
Нюансы сбора данных Часть 1 и Часть 2
Разработка витрин данных

Аналитика для жизни
Напряжение или расслабление?
Три компонента мотивации команды

Ну что, коллеги, отдохнули?
Время управлять временем!

Вторая маст-хэв книга наряду с "Потоком" Михая - это, конечно, знаменитый "Тайм-драйв" Глеба Архангельского. Если вы её еще не читали, найдите книжку сегодня же (она давно гуляет по интернету). А если читали - перечитайте еще раз и принимайте на вооружение!

Я внедрил в свою жизнь почти все советы из книги и постепенно буду их выдавать.

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

Глава 2. Мотивация: как справляться с неприятными задачами.
Освойте методы настройки на выполнение неприятных мелких дел - "лягушек".

2.1. Используйте якоря для настройки.
Якоря = материальные привязки — музыка, цвета, ритуалы.

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

2.3. Награждайте себя за выпонение маленьких дел.

2.4. Ежедневно съедайте с утра "лягушку", т.е. выполняйте мелкое неприятное дело, чтобы они не копились.

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

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

Но главное - внедряйте сразу!

Давеча писал о разработке витрин, а оказалось, что эта привычная мне сущность вызывает вопросы у читателей.

На днях опубликовалась моя статья о разработке витрины данных для анализа эффективности рекламных кампаний.

Взято из реальной жизни, поэтому приглашаю заценить: https://vaiti.io/oczenivaem-reklamnye-kampanii-s-pomoshhyu-sql/

Отгремели салюты в честь Великой Победы, отзвучали поздравления.
Но сегодня перед нашей страной стоят новые вызовы, к счастью, не такие страшные, как тогда.
И в том числе, в сфере айти, а значит, и дата-аналитики.

Многие вендоры ушли из России, забрав инструменты, на которых строились практически все этапы работы с данными.
Ушел Google с его колоночной СУБД BigQuery и всем Cloud-ом, ушел Amazon c его серверными мощностями, ушел Microsoft с его мощнейшим инструментом визуализации Power BI. Ушли Zapier, OWOX, Amplitude, Tableau и множество других полезных аналитику коммерческих продуктов.

Слава высшим силам, у нас была хоть какая-то своя альтернатива. За три минувших года российский бизнес перестроился на российский и/или опенсорсный стек.
Да, наши технологии во многом отстают от западных, проблем много, но это значит, нам есть чем заняться!

И российский инструментарий развивается, постепенно заполняя резко опустевшие ниши.

Яндекс развивает свои облачные сервисы и выкатывает свой Менеджер тэгов на замену Google Tag Manager, DIS Group представил Платформу по управлению данными IDP, CleverData совершенствует свою Платформу данных клиентов Join.

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

Еламе тоже пришлось съехать с западного стека, в чем я принимал живейшее участие.
Мы заменили BigQuery на яндексовый Managed Clickhouse, Google Analytics на Метрику, Google Workspace на Яндекс.Диск, Power BI на Data Lense и поменяли множество других инструментов.

Это было непросто, нервно, но мы выстояли.
Можно воспринимать эту работу по-разному - как борьбу, как возможности развития и интересное поле для самореализации, или вовсе отказаться от неё, отправившись следом за ушедшими поставщиками.

Я никого не оцениваю и вообще почти никогда не смешиваю работу с политикой. Но свой выбор сделал.

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

Этот этап занимает не меньше, а то и больше времени, чем разработка, т.к. ценность витрины - не в коде, а в результирующих данных.

Задачу на разработку или доработку витрины, в общем случае можно завершать следующими действиями:

Для проверки доработанной витрины:
* Проверяем ее на дубли подсчетом по уникальному составному ключу до группировки.
* Сравниваем старые поля новой версии с текущей с помощью EXCEPT DISTINCT.
* Новые поля проверяем так же, как при создании новой витрины.

Для проверки вновь создаваемой витрины:
* Проверяем ее на дубли.
* Находим лишние строки, фильтруя конечную витрину по «инвертированным» условиям ТЗ.
* Составляем на основе требований ТЗ примеры исходных данных и ожидаемых результатов для них — и убеждаемся, что запрос верно обрабатывает все варианты.

Читайте подробнее в моей статейке.