В честь 100 подписчиков на канале расскажу вам небольшую историю про пасхалку которая случайно получилась в канале.

Изначально я сделал этот канал как просто альтернативу избранным сообщениям, куда я скидываю всякие интересности и книги которые я когда-нибудь обязательно прочитаю (ага-ага).

Потом я из закрытого канала перевел его в открытый и у меня появилась опция - придумать никнейм для него. И я как истинный зануда начал придумывать как бы обыграть слово data. В итоге не был занят никнейм withdata ("c данными" если перевести буквально). Ну и название канала появилось примерно тогда же - как описание меня и моего профессионального проявления. Что я - не просто я, я делаю биай. Ну а пасхалку эту я сам обнаружил случайно когда прочитал вслух через какое то время вместе название и никнейм канала = )
Если игра слов осталась не ясна, попробуйте реально вслух это произнести. Или прочитать следующий абзац

Ну и собственно мораль - если можешь при тех же усилиях делать лучше - делай не просто лучше, делай пиздато

Как вы думаете, что может объединять дорожную разметку, классическую архитектуру, панораму городской улицы и проекции детали на чертеже?
Подсказка - везде используется свойства человеческого мозга достраивать прямые или плавные линии из разрозненных частей

Или если сформулировать получше - принцип непрерывности (continuity) в гештальте.

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

А началось все с того, что мы с сыном рисовали картинку по точкам (ту где надо объединить точки линиями и получить какое-то животное). И у нас завязался спор - Миша вполне обоснованно спросил меня - почему вот тут если сделать линию прямую - то ничего не получается, и почему папа утверждает что линию надо делат с углом, ведь видно что она должна быть прямой.

На что я ему резонно возразил: "Потому что папа блин знает как выглядит жираф надо обращать внимание не только на то как точки расположены, но и какие рядом с ними цифры, а линия выглядит прямой потому что человек любит в хаосе видеть порядок и продолжить точки в прямую линию человеку проще чем в два угла (условно X это скорее / + \ а не > + <)

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

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

Ну а еще этот принцип позволяет
- В наборе черточек на асфальте увидеть сложную разметку движения по полосам
- Увидеть красоту и прямые линии в нагромождении архитектурных элементов
- Идти от обратного - нарисовать сходящиеся в точку линии и на них расставить элементы городского пейзажа для четкой передачи перспективы
- ну и сопоставить между собой грани детали на разных проекциях чертежа

Так что когда вы будете маневрировать на огромном перекрестке с грамотной разметкой, сможете похвалить себя "Как хорошо что мой мозг умеет в непрерывность"😄

Оконки оконочки. Иногда у меня есть подозрение что я слишком часто их использую и "когда в руках молоток все кажется гвоздями"

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

Собственно пример данных и сама задача на скриншоте.

Здесь вы можете сделать паузу, заварить чаек и подумать как можно решить такую задачу .

А я под спойлером напишу мой вариант решения + в комментарии закину более явно объясняющий это скрин (увы мне для этого решения не были доступны процедурные способы)

спойлер: там четыре уровня оконных функций получилось

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

По сути здесь основная проблема - у нас нет на что опереться в построении окна, по которому мы будем "размазывать" значения. Кстати сам способ "размазывания" не так важен - можем джойном с группировкой, можем джойном по неравенству.
Если мы посмотрим на эти данные "сверху" то можем формализовать границы этого окна как "начиная со строки где статус поменялся (либо с первой строки) и заканчивая строкой, которая предшествует новому статусу"
После формализации уже становится проще - мы можем детектить строку изменения статуса с помощью lag или lead - а распределять их значение с помощью кумулятивной оконки (грубо говоря для каждой строки посчитать количество изменений статуса).
И потом уже сдвинув эти значения на строку вверх можно использовать эту нумерацию как окно и по нему распределить статусы.

Способ возможно выглядит переусложненным, но увы ничего лучше я не нашел (я еще пробовал различные вариации first_value(coalesce(status,'')) over(partition by id order by create_dttm desc range between unbounded precending and current row)
Но они мне не помогли). Буду рад если вы принесете другие варианты= )
UPD: в комментариях предложили вариант получше:)

Сегодня утром мне написали что "you fast and furious" и попросили взять в работу срочную задачку
Тем временем мои "Fast and furious" в середине спринта:
Задачу взял, не каждый день такие комплименты отвешивают😁

Каждый раз радуюсь когда в общеаналитических каналах Авито выходят посты от биайщиков= )
А если по теме - тут главное не переборщить с уточнениями, один раз я на заказчика выкатил бриф на 50 вопросов и он мне потом это на ревью припомнил😁

Сегодня встретил график настолько же гениальный, насколько пугающий

Нельзя просто так взять и рассортировать Лего. Профдеформация похоже)

Сегодня в МИРЭА читал небольшую лекцию об аналитике в целом, аналитике в Авито, и BI аналитике в частности. Очень отзывчивые и вовлеченные студенты были, две пары пролетели незаметно)
Чтобы не было так скучно и приторно, провел для них небольшой интерактив из двух частей - «Прожарка», где надо было критиковать и предлагать улучшения сомнительных визуализаций (спасибо за них каналу «Отвратительные графики» @awfulcharts ) и обзор нескольких видов графиков, где надо было поставить оценки по нескольким критериям типа понятности и применимости и придумать кейс к которому подходит тот или иной тип графиков (нетривиальность и остроумие приветствовалось)

Промежуточные выводы:
1) Абсолютно зря повально ругают зумеров
2) Когда на лекции появляется возможность поругать чужую работу - аудитория оживляется

Собственно слайд со второго интерактива на фото и вы в комментариях можете предложить свой вариант что можно изобразить с их помощью

Если московский ветер унёс вас в сторону кластера Ломоносова и вы тоже на Aha - пишите, встретимся поболтаем:)

«Все здоровые дашборды похожи друг на друга, каждый нездоровый нездоров по своему»
Раньше мы ориентировались на множество разрозненных дашбордов, у многих команд были свои «велосипеды» которые с разных сторон оценивали свои отчёты. А теперь есть единый «градусник», разве это не здорово)
Спасибо всем, кто вложился своим временем, идеями и усилиями в этот проект, а особенно спасибо Саше как идеологу и главному двигателю, Насте которая лидировала его создание и Айгуль, которая вложила в него много сил и времени)
Остальные участники тоже красавчики, но Настя и Айгуль из моей команды и на мой взгляд сделали наибольший вклад)
А я делал лучшее что может делать тимлид - не мешал 😄

Ревью близко!

Для многих компаний и команд с полугодовым циклом перф ревью этот мем становится актуален и добавляет стресса в текущей работе

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

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

Еще стрессовый момент- запрашивание отзыва о своей работе от коллег. Тут я могу поделиться маленьким лайфхаком - запрашивая отзыв, напишите человеку: объясните оценку каких качеств себя и своей работы вы бы хотели получить, какие проекты вы с ним сделали (помогите ему вспомнить и начать писать - не все набили руку на написании отзывов, и зачастую сами испытывают стресс). Так вы уменьшите вероятность получить неинформативный отзыв «Вася классный, все было супер»

Пожелаю вам терпения и выдержки для этого непростого периода, а также сознательности не использовать для всего этого LLM :)

Жизненная жиза от Aurélien Vautier

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

Приглашаю послушать и подискутировать)

PharmaDataMeeting №2

29 июня 2025, 15:00 (воскресенье)

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

1️⃣ Герингер Владимир - директор бизнес-аналитики, GLS pharmaceuticals: "Информационная система: архитектура решения"
Автор канала: PharmaDataLab

2️⃣ Снигирев Дмитрий - тимлид Core BI - Авито: "Как выглядит роль BI аналитика в требованиях разных компаний"
Автор канала: Делаю BI

3️⃣ Корнев Иван - аналитик данных: "Приблизительный подсчёт уникальных записей в SQL"
Автор канала: Откровенная аналитика

Приходите, будет интересно!

Ссылка для подключения: https://telemost.yandex.ru/j/65617501912823

🔥 - ставь, если придешь в эфир

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

Я сейчас провожу небольшое открытое исследование на тему "Как изменилась профессия BI аналитика/разработчика за последние годы"
Если у вас есть что сказать по этому поводу и поделиться своим мнением по трем открытым вопросам (Что было, что есть, что будет) то буду очень благодарен= )
https://forms.gle/xJNudQWXbfXAU4ge9

Чувство когда попал в пост к Роме Бунину @revealthedata
Да еще в такой приятной компании)

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

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

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

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

Предисловие/ликбез
Некоторые метрики являются неаддитивными - то есть сумма их разрезов не равна самой метрике. Например у нас есть 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://news.1rj.ru/str/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 для стандартной метрики:)

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