Акт 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.
За репост — плюс в карму ❤️