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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

⁉️ BI-боль: почему мой дашборд никто не смотрит?

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

Весной все начинают генеральную уборку — BI-разработчики же проводят ревизию своих дашбордов: изучают пользователей, смотрят, кто из заказчиков и с какой периодичностью заходит в отчёты.

Но вот незадача: дашборд создавался для 50 пользователей в месяц, а в аналитике — всего два просмотра. И один из них — твой…

Появляется мысль: удалить всё и сделать вид, что ничего не было. Но, может попробуем вдохнуть в дашборд новую жизнь? Добавить понятные подписи, убрать лишнее, заменить длиннющие таблицы на наглядные диаграммы. В общем, немного магии BI-стилиста!

Что делать, если твой дашборд игнорируют?

1️⃣ Упрости интерфейс

Если твой отчёт требует 100-страничного мануала, им будут пользоваться только самые отчаянные)) Дашборд должен быть понятным с первого взгляда. Покажи макет коллеге, который в BI понимает столько же, сколько улитка в квантовой физике. Если он разберётся — ты на верном пути!

2️⃣ Ускорь работу отчетности

Статистика гласит, что 47% пользователей ожидают загрузку страницы меньше, чем за 2 секунды. Посмотри, как можно оптимизировать запросы, чтобы всё летало. Быстрый дашборд — это дашборд, к которому хочется вернуться.

3️⃣ Добавь подписи и контекст

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

4️⃣ Сделать красиво

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

5️⃣ Проверь доступ

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

6️⃣ Проведи обучение

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

А если после всего этого на твой отчёт всё равно никто не смотрит?… Возможно, стоит отпустить его с миром. Но, уверена, что до этого не дойдёт!

#Redash #BI

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

Сегодня у меня была эталонная задача на доработку дашборда (желаю всем таких задач)

Сел разобрать переписки в корпоративном мессенджере, а там череда непрочитанных сообщений:
- Дима привет! Нам нужна вот такая-то доработка дашборда
Спустя час:
- Подожди, сейчас с командой обсудим что конкретно нам надо
Спустя еще час:
- Отмена, пока ничего не надо)

Трудная рабочая неделя закончилась, и мне хочется поделиться с вами практически не-биайной историей
Не так давно я стал тимлидом (пока acting, это нечто вроде испытательного срока внутри компании) и понял что количество встреч резко выросло, и под конец дня у меня не остаётся сил не то что на работу IC, но и на те проекты, которые я хочу реализовать в качестве тимлида. Спустя пару месяцев шока и прочитанных материалов по тайм-менеджменту я начал вырабатывать какое то подобие своей системы работы с календарём, и хотел бы вынести ее на вашу критику.
Последние пару недель я классифицировал свои встречи по тому, насколько они меня выматывают и сколько мне надо приходить в себя чтобы вдумчиво сесть и поработать, и в итоге у меня получилась определённая шкала стрессовости встреч. Я раскрасил её от зелёного к красному и превратил свой календарь в хитмап😅 Я предупреждал, что чуть чуть биая все равно будет)
Теперь буду экспериментировать с тем, чтобы перемещая встречи внутри дня попробовать получить побольше эффективности на единицу времени календаря.
А как вы решаете проблему с множеством встреч?

Хочу поделиться опытом проведения собеседований по SQL в формате лайфкодинга. За последний год у меня была возможность оценить множество кандидатов, и я заметил несколько общих признаков, которые бы хотел обсудить и дать небольшие советы.
Дисклеймер: Я понимаю скептицизм многих по поводу корректности проверки навыков SQL путем лайфкодинга на нескольких задачах. Мы в Авито на основании SQL скоринга не выставляем грейд, а просто принимаем решение hire/no hire. Соответственно и оцениваем мы больше подход к решению, а не знание синтаксиса

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

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

Иногда ставит в тупик кандидатов вопрос "Как ты думаешь, какой способ решения задачи будет оптимальнее?" Тут основной пункт - просто почитать статьи о том как работают разные СУБД и какие есть основные ошибки и альтернативные решения. Почитайте про индексацию и анализ планов выполнения запросов. Попробуйте использовать на практике если не пользовались раньше. Но конечно все зависит от СУБД.

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

Что вообще думаете про sql- скрининг биайщиков?

Просто интересный пример скаттерплот диаграммы)

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

Недавно была на работе нестандартная задача - сделать дашборд с максимально закрытым доступом. Настолько закрытым чтобы ни один инженер/админ bi системы/аналитик (включая автора) не смог увидеть что там.
Было у меня несколько предварительных вариантов, например питоновский скрипт в файле, в который кидаешь таблицу с данными а он на выходе отправляет рассылку по заданному списку адресов, или отдельный лендинг развернутый на изолированной виртуалке, но все упиралось в то, что с ростом сложности обеспечения доступа и сложности продукта в целом естественно росли возможные затраты на его поддержку и соответственно появлялись дополнительные люди в починке задействованные.
В итоге я вспомнил что все новое это хорошо забытое старое и предложил заказчику максимально секьюрный вариант - эксель с шаблоном дашборда, в который будут забивать данные, потом распечатывать/делать скрин и адресно отдавать пользователю😅
Неканонично и нетипично? Да.
Заказчик доволен при минимальных вложениях ресурса аналитиков? Тоже да.

Конечно в полной мере реализовать принцип «лучший дашборд это отсутствие дашборда» не получилось, но все равно опыт интересный:)

Если вы все еще путаете барчарт и горизонтальный барчарт, то я спешу на помощь)
В русскоязычной литературе приняты более интуитивно понятные названия - столбчатая диаграмма и линейчатая диаграмма (столбики сверху вниз или линии слева направо, изи)
Но когда мы переходим к принятым в англоязычной среде терминам, то там скорее встретите bar chart (bar graph, column chart) и horizontal bar chart, horizontal bars (или просто bar chart, без указания подробностей - как правило нет никаких уточнений, барчарт и барчарт). И horizontal это именно направление элементов графика, то есть "горизонтальные столбики"
В качестве иллюстрации приложил именно горизонтальный барчарт (просто потому что использую их чаще)
Есть еще гистограммы как близкий родственник барчарта предназначенный для отображения непрерывных данных, но это совсем другая история..
Источники из которых уточнял англоязычную терминологию: Stephen Few "Show me your numbers", Tufte E.R. "The visual display of quantitative information", блог Aurélien Vautier

Открывем поиск нового middle BI разработчика в мою команду (Core BI Avito). Если вкратце - надо будет делать дэши для топов компании, кросс-функциональных дэши для всего Авито и вносить свой вклад в развитие BI и его процессов всей компании. Вобщем делать прекрасное и полезное)
В чем интерес?
1) Делать ключевую отчетность для менеджмента и аналитиков.
2) Стоять у истоков развития крутого BI, который мы сейчас реализуем под руководством нашего Head of BI Саши Баракова (думаю вы знаете его в том числе по каналу Data Nature)
Подробное описание можно посмотреть на нашем карьерном портале или поспрашивать меня в личке @astigo

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

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

Заказчик - А давай визуализируем наши процессы
Тем временем процессы:

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

Уже второй год работаю в Авито. И недавно пытался вспомнить, а как же давно я с Авито как пользователь - и отправился искать в базе (а потом обнаружил что мог не включать аналитика а просто посмотреть в разделе "Управление профилем" личного кабинета) Оказывается, я пользуюсь Авито как пользователь уже на протяжении 14 лет (с ноября 2010 года) - когда это еще не было мейнстримом так сказать= )

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

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

Вас ждет продукт с 50+ миллионами пользователей в месяц, удаленка по всей России, сильное IT-комьюнити, которое любит опенсорс, а также возможность попасть в одну из пяти команд.

Использовать опыт в Big Data можно на одном из масштабных проектов:

развивать умный алгоритм проверки объявлений;
внедрять ML-модели в процессы монетизации;
писать микросервисы для улучшения поискового ранжирования;
оказывать DS-поддержку всем командам Авито.
Ищите точки роста бизнеса и развивайте крупнейший в мире сервис объявлений! Пройдите ускоренный отбор и выходите на работу уже в начале марта.

Как говорится "У самурая нет цели, ссылка туть"

По крайней мере мы точно знаем о каком тысячелетии речь