Биайщик: собрал требования, рассчитал данные, сделал красивый дэш
Заказчик:

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

То чувство, когда ты внёс мааааленькие правки в логику которые ни на что не должны были повлиять, а сломалось абсолютно все:

История в трех актах (трагическая) как я в несколько подходов расчитывал неаддитивные метрики для дашборда

Предисловие/ликбез
Некоторые метрики являются неаддитивными - то есть сумма их разрезов не равна самой метрике. Например у нас есть DAU сайта (количество активных пользователей на сайте)
И есть на сайте несколько страниц - на каждой из которой свое количество активных пользователей. В итоге нельзя так просто взять и сложить DAU каждой страницы и получить DAU сайта, потому что один пользователь может посетить несколько страниц, и при этом быть единственным посетителем сайта

Акт 1 «Выглядит все просто»

В принципе расчёт несложный - считаем агрегат для сайта и делаем union all агрегат для каждой из страниц. Общему DAU присваиваем значение page= 'Any' и вуаля - мы посчитали эту метрику.
Но вообще, в SQL предусмотрен очень мощный «синтаксический сахар» для таких расчётов - функционал GROUP BY GROUPING SETS (<перечисление необходимых агрегаций>), написав
GROUP BY GROUPING SETS ((event_dt), (event_dt, page)) мы как раз получим такой union all двух группировок, в которых недостающие разрезы будут null
Есть еще два вида этих функций, которые тоже своего рода синтаксический сахар над grouping sets - ROLLUP и CUBE: один для ступенчатого перебора разрезов, а второй перебирает вообще все возможные варианты группировок.

Вроде пока звучит просто? Но уже тут можно словить подвох - если у вас есть измерение NULL до группировки, то после неё вы не сможете отличить вышестоящий уровень агрегации от отсутствия разреза (в некоторых СУБД можно уровень агрегации выводить, но далеко не во всех). Так что если вы используете этот метод - запаситесь колясками! (COALESCE в разговорной речи:)

В акте 2 расскажу что делать если оказалась что не все так просто

Акт 2 - «Похоже все не так просто»
Акт 1 - https://t.me/withdata/134

Теперь допустим у нас не два измерения - дата и страница, а пять: дата, страница, тип пользователя, ОС с которого пользователь заходил, и его регион.
Так как мы уже на опыте и знаем про GROUP BY CUBE - хватаем его, запускаем, получаем свои 2^5 = 32 группировки и в принципе довольны. До тех пор пока не выясняется, что нам потребуется не только тип ОС пользователя, но ещё и версия приложения с которого он заходил. И не просто регион, а регион + город.
Запуская CUBE мы сходу ловим 128 группировок и идём грустить, потому что на больших объёмах данных (допустим десятки миллионов пользователей в день) такие расчёты вызывают лёгкое подергивание глаза. Что делать? Убирать лишние группировки. Два разреза у нас иерархические - регион+город и ОС + версия приложения. Получается нам нет смысла считать разрез вида «сколько людей из Сочи и Чукотки заходили на сайт». В итоге мы сидим, пишем разрезы которые нам нужны в огромном grouping sets и довольные запускаем скрипт. Экономия - космическая, у меня вместо 128 возможных разрезов получилось что требуется всего 18.

В чем проблема?
Их не 18.
При ревью отчёта уже на проде я обнаружил что в некоторых комбинациях фильтров у меня отсутствуют данные, хотя вроде должны быть. Пришлось идти думать (и напоминать себе что думать и полностью!!! тестировать надо до выкатки в прод)
Посидел, порисовал как формируются разрезы, и понял разрезов должно быть
1*2*2*(2+1) *(2+1)
Это все ещё лучше чем куб, когда
2*2*2*2*2*2*2.
Какие и как схлопываются разрезы?
Дата - нас не интересует метрика за весь период, поэтому 1 а не 2
Регион + город, нам не нужны все регионы для каждого города, а только родительский регион - значит вместо 2*2 получаем 2+1
И с ОС + версия аналогично.
В итоге получается 36 разрезов, что конечно лучше чем 128, но все равно сложнее и дольше чем 1 для стандартной метрики:)

В третьем акте будут подниматься экзистенциальные вопросы «зачем все это?» «как не страдать в таких ситуациях?» «почему я не пошёл в сварщики?»

Акт 3 "Зачем вообще все это?"

Акт 2 https://t.me/withdata/135
Акт 1 https://t.me/withdata/134

На фото - useless box, который выключает тумблер сразу после того как ты его включишь

Иногда такие упражнения приходится делать и для вполне себе аддитивных метрик (на самом деле в исходной задаче у меня была именно она, и где то на стадии «Акт 0» я написал group by 1,2,3,4,5,6,7 и успокоился). Но потом мне понадобилось добавить на дашборд ещё несколько метрик, включая ratio метрику, у которой в числителе была как раз неаддитивная метрика в готовом виде, которую посчитал другой человек. А потом еще на горизонте выплыли несколько финансовых метрик, которые надо было подружить с этим цирком, и у них разрезы совпадали только частично с исходной метрикой. В итоге волевым решением я решил усложнить жизнь всем кто будет разбираться в этом в будущем (коллеги подтвердят что я так частенько делаю) - но упростил добавление новых расчитанных метрик.
Оказалось что подобный метод расчёта хорошо подходит для стыковки между собой метрик разных типов.

Вообще у нас в Авито есть удобный инструмент под названием 3sigma (точнее нас интересует его компонент M42 для визуализации метрик) - куда можно положить скрипт метрики, задать конфиг и измерения, которые требуется рассчитать неаддитивно - и все, скрипты крутятся, разрезы мутятся.
Почему не воспользовался им? На то были объективные причины, но если бы я сразу корректно оценил трудоёмкость - пошёл бы договариваться с заказчиком о сокращении функционала в пользу более быстрой разработки и более простой поддержки (не факт что они бы согласились конечно)

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

Заключение (филосовское)

Решение может быть простым или сложным, быстрым или внедряемым через боль и N итераций. Но в любом случае полезно задавать себе вопрос - вы все еще решаете потребность пользователя или делаете сложность ради сложности?

Всем привет= )

upd: прием резюме завершен, пост оставляю для истории

У нас в Core BI Авито открылась новая ставка и мы ищем крутого спеца senior - lead уровня, который и швец и жнец и всем пиз и в датавиз и в инженерию и в построение BI процессов.
Цель амбициозная - строить вместе с нами крутую BI функцию во всем Авито с достаточно низкого старта.
Непосредственно тимлидом буду я, команда работает в прямом подчинении head of bi (@alexbarakov)
Задачи на любой вкус:
1) Можно заниматься построением высокоуровнего репортинга для всего Авито или C-level пользователей
2) Можно писать много SQL и выстраивать архитектуру витрин
3) Можно лидировать проекты развития всей фукнции BI (как пример: продумать и внедрить процессы сертификации отчетности, разработать концепцию и внедрить аналитические рабочие места для разных ролей не-аналитиков, разработать стандары репортинга BI)
Пропорции этих типов задач будут примерно 30/20/50

Автономность - высокая, свобода выбора интересных проектов - еще выше. Комьюнити BI ламповое и вовлеченное.

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

За подробностями - велкам в лс @astigo

Пятница? Пятничный мем!

Чтобы не собесить LLM надо собесить LLM

или что за тг канал без поста про AI

Думаю для всех тех, кто проводит собеседования по hard-скиллам актуален вопрос - что делать со списыванием из LLM любой вариации?
Конечно нельзя сбрасывать со счетов вопрос более верхнеуровневый - а надо ли что-то делать?
На него общепринятого ответа нет, но я вижу риски такого найма - кандидат который не может думать и решать без LLM качественно - будет хуже кандидата который способен это делать. Потому что когда эти два абстрактных кандидата воплотятся на работе и возьмут в руки LLM - мы получим из одного связку "Senior + junior AI" а из другого "Junior + intern AI". Ну либо Senior без AI если наняли луддита)

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

Вижу тут два основных направления:

1) Сделать так, чтобы LLM нельзя/сложнее было воспользоваться. Так сказать "ЕГЭобразный" подхож- ужесточаем контроль, закрываем кандидата в комнате с белыми стенами, даем ему карандаш и бумажку, запрещаем моргать чтобы не подал сигналы в космос
Понятно что я довел этот пример до абсурда, но сильными ужесточениями мы срежем себе воронку из приличных кандидатов, которые не захотят участвовать в этом перформансе. Ну и кто захочет - тот спишет, проверено в универе еще до всяких чатгптей)

2) Сделать так, чтобы LLM было пользоваться бессмысленно.
Нужен такой подход к собеседованию, когда использование LLM ухудшает результат собеседования.
Например: LLM-устойчивые задачи, специфичный бизнес контекст, хорошо воспринимаемый человеком но плохо распознаваемый и учитываемый моделью.
Таким образом, мы вынесем на первый план оценивания не написание кода, а более высокие уровни решения задач - аналитические выводы по коду, умение применить контекст, оценить сложность задачи, внести правки и корректно собрать требования (и какое совпадение - этого мы и ждем от кандидата, а вовсе не знания синтаксиса)

Остался основной вопрос - а как же построить такое "идеальное" собеседование - чтобы при адекватной трудоемкости проведения техсекций минимизировать ошибку определения подходящего кандидата?

Тут пока готового ответа у меня нет) А по поводу тезиса из заголовка - чтобы отладить такой подход я буквально собеседую ChatGPT на должность BI разработчика - чтобы понять с чем у него есть сложности и как это можно применить)

Что видит пользователь дэша когда биайщик насыпал море непонятных аббревиатур и технических полей

Пятничных мемов у меня для вас нет, есть понедельничный

BI стажеры и BI стажировка

Дисклеймер 1 - Мы не первый раз нанимаем стажеров, и они реально вырастают в крутых спецов
Дисклеймер 2 - Мы сейчас нанимаем стажеров BI - в том числе в мою команду. Стажировка интенсивная, задача за год вырасти intern-> junior->middle. Будем делать масштабные вещи и переворачивать BI на 360 градусов
Дисклеймер 3 - Да, у меня примерно такое чувство юмора и я не очень хорошо понимаю что такое дисклеймер

В процессе подготовки процесса специфичного BI найма для этой волны стажировок у меня возникли небольшие "философские" размышления

Кто такой идеальный стажер и как его найти? Основные критерии у меня получились вот такие:

Понимает кто такой BI разработчик и чем тот отличается от дата-аналитика.
Очень важный пункт, часто сталкивался с позицией "Биайщик это аналитик который не знает статистику" - от такого становится грустно. Как фильтровать это? Наверное только на скоринге уже спрашивать у кандидата и явно подсвечивать на входе в воронку найма

Уже работал с BI системой / делал дэши в учебных или пет проектах.
В прошлый раз когда я нанимал стажера этот пункт вызвал бурные обсуждения в некоторых профильных каналах "Почему вы требуете у стажеров опыт работы с биай системой?". Мой ответ остался тем же - это базовый навык для биайщика, человек который никогда не делал дашборды не может утверждать что он хочет этим действительно заниматься. Как проверять? Как и везде - с помощью портфолио

Знает SQL и понимает работу с табличными данными
BI разработчик в зависимости от команды и проекта от 30 до 70 процентов времени тратит на трансформацию данных в том или ином виде. Если кандидату сложно думать "таблицами" и абстрактными потоками данных, это не значит что он глупый или плохой. Просто другой склад ума. Я встречал людей, которые органически не могут понять как формируется сводная таблица в экселе, но при этом могут посмотреть на принципиальную схему платы и в уме прикинуть как она будет работать и какие токи выдавать. Проверить можно задачами на SQL, тут ничего нового

Понимает что такое хорошо и что такое плохо в визуале
Это из рубрики насмотренности и понимания восприятия визуальной информации, она развивается поэтапно. Первый этап - посмотреть на визуал и понять что он плохой. Второй этап - понимать почему он плохой. Третий - понимать почему именно эти решения не работают. Четвертый - как это исправить. Пятый этап - подбирать визуал с учетом всего бизнес и пользовательского контекста. Дальше идет дзен и отрицание визуальной кодировки данных как концепции, тут главное не проскочить (см. Дисклеймер 3) От стажера мы ожидаем хотя бы уровни 1 и 2 - осознанно различать ужасные и хорошие дэши. Проверяется это на техскоринге.

Как будто это основное и самое важное.

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

Как вы знаете, в Авито есть старая добрая традиция - публично выкладывать матрицы компетенций для основных профессий.
Не будем и мы исключением, актуальная версия матрицы BI аналитики теперь в открытом доступе на Github

Почему мы вообще регулярно меняем матрицу компетенций?
Есть два мотива:
1) Операционный
Какие критические замечания есть по итогам калибровок?
Каждая калибровка выявляет слабые места текущей матрицы и мы ее понемного отшлифовываем
2) Стратегический
Матрица должна создавать виденье: А какими должны быть специалисты в нашей функции через 2-3 года? Как мы будем нанимать и за что поощрять? Как отличим хорошего биайщика от плохого?
И если матрица начинает сильно расходиться с стратегическим виденьем, ей требуется уже более глобальная пересборка.

Филосовские мысли в качестве заключения.
Сейчас весь мир в целом и наша профессия в частности меняется очень быстро,и где-то в заметках уже лежат мысли-вопросы вида: А как нам оценивать биайщиков в будущем? А как повлияют LLM-агенты? Как вообще изменится BI и будет ли он нужен?
Готовых ответов у нас нет. Но когда появятся, будьте уверены мы сохраним традицию и поделимся своей версией)

На картинке - диаграмма-радар заполненной матрицы у одного из биайщиков Авито. Куда мы без визуализации= )

«Если в лесу падает дерево, и его никто не слышит - оно издаёт звук?»

Когда я только пришёл в Авито, меня удивило, что не было большого дашборда по всей возможной выручке. Такого, где можно посмотреть все виды и типы выручки, понять механику их сборки (да и просто отличить "пивас" от "бибип" - это реальные названия если что, PVAS и BBIP). Может сделать какой-то несложный факторный анализ. Спойлер - не просто так такой дэш отсутствовал.

Убедил руководителя что идея крутая и точно будет востребована. Сел делать. (Даже пользователей потенциальных опросил и требования собрал)

Задача оказалась нетривиальной. Выручка в большой компании это хаотичный лабиринт из источников, логик, исключений и договорённостей. Но сделал.

Вроде зашло, пользователи оценили, пошла обратная связь и доработки. Потом ещё доработки. Каждая казалась разумной.

И вот здесь я попал в петлю, которую еще тогда не умел решать: сложность растёт → дашборд ломается чаще → поддерживать тяжелее → пользователи уходят → приоритет починки падает → сложность продолжает расти.

Сейчас дашборд технически жив (зомби-дэш так сказать). Открыть можно. Его даже смотрят - часть функционала в нем еще работает (и даже MAU 37) На нём висит плашка:
«Накопились критические изменения в источниках. Дашборд нуждается в рефакторинге и починке. Срок 2025Q4..2026Q1»
Как вы бы могли догадаться, вскоре там будет 2026Q2

Второй квартал подряд этот срок съезжает, потому что находятся задачи приоритетнее.

Я всё ещё верю в идею этого дашборда. Поэтому план такой: найти свободный вечер пятницы, взять несколько бутылочек пива, открыть Claude и наконец отрефакторить. Когда-нибудь. В Q2 😄

Новая рубрика - BI ЧГК
Что изображено на этом графике?

Могу сказать, что существует правильный ответ и я до него догадался) Ну и возможно многие из вас строили аналоги таких графиков)

Всем привет!
Мой хороший товарищ и коллега Женя (@oblivionrrr) ищет себе в команду middle BI-разработчика — репощу с чистой совестью, реально топлю за этих ребят.

Команда — ASD Авито Работы, TL + 4 биайщика. Делают BI-продукты от идеи до поддержки. Self-Service развивают, AI-агентов в повседневку уже встроили. Адхоки не любят 😁

Кого ищут: драйвера и тащера, который закроет поддержку отдела продаж. Важны и харды, и софты — нужно балансировать между кодом и разговорами со стейкхолдерами. А их там 10+, так что скучно не будет.

Что такое ASD на пальцах: департамент продаж, где менеджеры разных грейдов ведут своих клиентов, плюс есть self-service сценарии. Глобальная цель — рост выручки через развитие текущих клиентов и новых проектов. И на каждом этапе работы менеджера отчётность — основной инструмент принятия решений. То есть зона ответственности команды — буквально нерв всего отдела продаж.

Что предстоит делать:
— работать с 10+ стейкхолдерами, выявлять боли
— делать BI проекты от идеи до поддержки
— рефакторить дашборды и участвовать в сертификации BI
— развивать Self-Service
— использовать AI-агентов
— быть полноценной частью команды — делиться опытом и перенимать его

На поддержке сейчас ~60 отчётов и 15 ключевых витрин. Простор для инициатив — огромный, и это правда: я знаю, как там устроено.

Стек: DWH (Trino/Vertica), Redash (ClickHouse/JS/HTML), Aviflow (Python), Jira, Confluence.

Если откликается — резюме Жене в TG: @oblivionrrr.
За репост — плюс в карму ❤️