Вы аналитик? Расскажите, как вам работается
Старые добрые осенние традиции: готовиться к Хеллоуину (если отмечаете), пересматривать «Сумерки» (если любите такое), участвовать в опросе NEWHR про рынок труда аналитиков (если вы аналитик).

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

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

🔜 Опрос

Valiotti Analytics — 6 лет! 🥳
Наш канал существует не сам по себе — это один из проектов дата-консалтинга Valiotti Analytics.
Мы, конечно, уже про это писали, но вдруг вы пропустили или забыли

🔜 И вот сегодня Valiotti Analytics исполняется 6 лет. За эти годы мы успели поработать над десятками проектов для заказчиков со всего мира, строили системы аналитики с нуля и разбирали тысячи строк legacy кода, радовались успехам и учились на ошибках.

В общем, это были насыщенные 6 лет, за которые компания выросла и сильно изменилась, но суть осталась та же — делать данные ближе и понятнее для бизнеса. Намерены продолжать делать это и дальше, только еще лучше. ❤️

Вайб-кодинг против вайб-инжиниринга
Все мы уже поняли, что такое «вайб-кодинг» — это человек генерирует код с помощью нейросетей, иногда даже не особо вникая, что они ему там пишут. Код работает, и ладно. Быстро, просто, но результат может быть непредсказуем.

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

Есть вариант называть это «вайб-инжиниринг».

В чем суть?
🔵Чтобы от ИИ получать реальную пользу (а не только едва жизнеспособный код), надо хорошо разбираться, как он работает, понимать его ограничения и выстраивать процесс.
🔵Под «выстраиванием» процесса мы понимаем использование старых добрых практик, которые применяются в нормальной, «безвайбовой» разработке. Составление грамотного плана работы и документации, настройка автоматических тестов, вдумчивое тестирование вручную, код-ревью — это все помогает не только людям, но и ИИ.
🔵Вайб-инженеру также важно реально оценивать возможности ИИ: что ему можно доверить, а что лучше сделать самому, как корректно поставить задачу и проверить качество выполнения. Человек в каком-то смысле занимает роль лида или менеджера, контролирующего своего ИИ-подчиненного.

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

Вопрос только в названии — как вам оно? Как думаете, пойдет «вайб-инжиниринг» в народ?

OpenAI представила ChatGPT Atlas
Вы никогда не думали, как было бы удобно, если бы кто-то за вас покидал покупки в корзину в онлайн-магазине, а перед этим еще сравнил, чем отличаются два на первый взгляд идентичных товара? Прочитал длинную статью и пересказал содержание? Придумал остроумный ответ в дискуссии в соцсети?

В общем, взял на себя эту сложную, нудную задачу сидения в интернете?

🔜 Что ж, если вы пользуетесь Mac’ом (остальным придется подождать), то теперь можете обзавестись таким помощником. OpenAI представила браузер ChatGPT Atlas, с прикрученным к нему ИИ-ассистентом. На картинке выше вы можете увидеть пример задачи для него — выбрать товары для похода на пляж с семьей.

Пользователь может ограничить доступ ИИ к отдельным сайтам, попросить сделать саммари написанного на экране или «покопаться» в истории браузера и найти там ссылку, которую посещал ранее.

Владельцам платных подписок доступен еще и агентский режим, в котором ИИ может совершать какие-то действия на сайте. Например, не только придумать остроумный ответ, но и отправить его, а потом еще наставить оппоненту дизлайков.

Ну что скажете — будете пользоваться Atlas’ом? Или может уже пользуетесь каким-то другими ИИ-браузерами? 👀

«Мало получить инсайт — надо еще донести его понятным языком»
И другие вызовы в работе аналитика в большой компании.

В подкасте «Потом доделаю» вышел выпуск как раз для нас с вами: Роман Халкечев, руководитель аналитики Яндекс Поиска и Рекламы, рассказал, как в корпорации работают с данными. Многие компании об этом либо ничего не рассказывают, либо говорят насколько общими фразами, что лучше бы ничего не говорили. Что-то реально интересное и полезное на эту тему — как этот подкаст — появляется не так уж и часто.

Про что говорили?
🔵С какими сложностями приходится сталкиваться, как доносить ценность данных до коллег и что делать, если ваши инсайты идут вразрез с решениями бизнеса.
🔵Как ИИ влияет на работу, меняет и продукты Яндекса, и рабочие процессы внутри.
🔵Сколько у него сотрудников в управлении (спойлер: 400), чем все эти люди занимаются и как управлять такой БОЛЬШОЙ командой.
🔵Как в реальности выглядит тот самый data-driven подход, к которому все так стремятся: как принимать решения, когда данных недостаточно (да, и у Яндекса такое бывает) или слишком много.

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

🔜 Слушаем на Яндекс Музыке.

dbt 101: что нужно знать на старте и лучшие практики
dbt — отличный тул для трансформации данных и заслуженный стандарт индустрии. Мы его часто используем, потому что он сильно упрощает работу на проектах со сложной аналитикой и множеством SQL-скриптов.

Кое-что из своего опыта собрали в новой статье. Это не инструкция, как настроить dbt и начать работу, а вводный материал, где мы решили поделиться, а что это вообще такое: зачем нужно, какие функции выполняет, какие задачи решает.

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

🔜 Статья уже на Хабре!

Viz of the Day во всем многообразии
Tableau любит показывать возможности своего тула и самые крутые датавизы выставляет на всеобщее обозрение как Viz of the Day, чтобы все смотрели, впечатлялись и вдохновлялись. Эти визы дня бывают кардинально разные: про бизнес, экологию, социальные вопросы, поп-культуру. Визуально они тоже отличаются — от классических лаконичных дашбордов до дизайнерских интерактивных инфографик. Отследить какие-то закономерности в этом разнообразии раньше было не просто, но теперь эта задача стала попроще.

Амбассадор Tableau Хидеаки Ямамото собрал данные о 600 последних Viz of the Day и отобразил на инфографике. И вот на ней тренды уже видны:
🔵Большинство авторов Viz of the Day — из США и Англии, а большая часть работ — на английском языке. Есть только одно исключение на португальском.
🔵2 трети работ принадлежат людям, у которых в портфолио уже есть Viz of Day. У рекордсменки из Англии таких работ аж 11 штук.
🔵Самые популярные цвета — синий, голубой, белый и серый.

К сожалению, выделить конкретные темы по описаниям, которыми сопровождаются визы, сложно — в основном там на все лады повторяются слова «data», «viz», «explore» и так далее. Так что сказать, на какую тему надо сделать дашборд, чтобы повысить шансы засветиться в категории Viz of the Day, не получится. 😕

Очистка ИИ-слопа: современные решения современных проблем
Что мы все о плохом — ИИ отнимает работу, из-за ИИ компании реже нанимают джунов, списки профессий, которые к (тут вставить какой-нибудь год) уничтожит ИИ и так далее. Он вообще-то еще и создает рабочие места вполне успешно.

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

🔜 И именно это и привело к появлению новой ниши — очистка ИИ-слопа: так называют низкокачественный контент, сделанный с помощью искусственного интеллекта. Авторы вычитывают и переписывают ИИ-тексты, дизайнеры исправляют картинки, а программисты правят код. Уже даже появился сайт Vibecodefixers.com для поиска специально обученных людей, которые могут навести порядок в чужом вайб-коде.

Так что одну дверь ИИ закрывает, но зато открывает другую. Ждет ли нас за этой дверью что-то хорошее — время покажет.

Как выглядит кошмар аналитика
В честь Хеллоуина решили обсудить с вами кое-что действительно жуткое — страшнее приведений или клоунов.

Плохой SQL. 👻

Потому что приведений не существует, а вот кривой код очень даже реален и иметь с ним дело приходится регулярно. Для затравки нашли для вас целую подборку примеров, среди которых:
🔵нагромождение CASE WHEN, создающее хаос, в котором может разобраться только автор кода (но это не точно),
🔵несколько уровней подзапросов, разобраться в которых не может даже сам автор,
🔵вьюхи поверх вьюх поверх других вьюх — сначала это может быть удобно и красиво, но со временем система рискует стать слишком непонятной, еще и создает нагрузку на базу,
🔵попытки «подчистить» результат запроса с помощью DISTINCT для того, которые прячут проблему вместо того, чтобы ее решать.

Встречались с чем-то подобным? Или даже видели что-нибудь похуже? Делитесь в комментариях! 👀

Сделай сам: БД ключ-значение своими руками
База данных нужна, чтобы было куда удобно и компактно сложить данные, а потом — чтобы было где быстро и легко их найти.

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

Как только находите ответ на один вопрос, тут же появляются новые. Это хорошо видно на примере статьи про создание БД с нуля: автор начинает с простого файлика с ключами и значениями и, постепенно дорабатывая его, доходит до создания LSM-дерева с индексами и сегментацией. И все это с интерактивным визуалом для наглядности.

Отличный материал для тех, кто хочет начать с азов, узнать, какие задачи встают перед создателями БД и как их можно решить.

Ваш PostgreSQL больше читает или пишет?
Одна из причин, почему Postgres так популярен — это его универсальность и гибкость. Мало того, что он прекрасно встроится почти в любой проект, так еще и можно оптимизировать и докрутить под свои запросы, чтобы поднять и без того высокую производительность.

Как именно его оптимизировать и докручивать, зависит от совокупности факторов, среди которых — то, каким операциям отдается приоритет: чтению или записи.

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

Операции чтения и записи «стоят» неодинаково — вторые дороже, сложнее и дольше. Следовательно, если оптимизировать PostgreSQL под свой проект, то это надо учитывать.
🔵Так, там, где больше чтения, принципиальна скорость, чтобы обеспечить пользователю максимально быстрый доступ к информации, которую он ищет. А это оптимизация индексов, кэширования и «тяжелых» SQLзапросов.
🔵А там, где нужно больше делать новые записи, важнее обеспечить вычислительные мощности, быстрое хранилище и большой объем оперативки, а еще не злоупотреблять индексами.

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

OR или не OR?
Представим, что у вас есть большая таблица applications, в которой хранятся данные о заявках пользователей, а также о людях, которые их подают (они указаны в столбце submitter_id) или рассматривают (reviewer_id). Вам нужно посчитать, со сколькими заявками взаимодействовал пользователь — неважно, отправлял или рецензировал.
Какой запрос, на ваш взгляд сработает быстрее?

SELECT COUNT(*)
FROM application
WHERE submitter_id = :user_id
   OR reviewer_id  = :user_id;

или

SELECT (
  SELECT COUNT(*) FROM application WHERE reviewer_id  = :user_id
)
+ (
  SELECT COUNT(*) FROM application WHERE submitter_id = :user_id
)
- (
  SELECT COUNT(*) FROM application WHERE submitter_id = :user_id
    AND reviewer_id = :user_id
);

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

По той же ссылке есть объяснение, почему так получается, но если кратко:
🔵Оператор AND уменьшает выборку данных, а индексы и статистика БД помогают оптимизировать его выполнение. Когда вам нужно отобрать данные по двум условиям, движок ищет сначала ищет записи, где выполняется более редкое условие и затем проходится по второму.
🔵Оператор OR либо последовательно проходится по всем данным в таблице, либо целиком одной колонке, затем по второй, чтобы их объединить. Оба варианта более «дорогие», чем просто просканировать столбец и отфильтровать лишнее

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

CREATE TABLE application_user (
  user_id        int8 NOT NULL,
  application_id int8 NOT NULL,
  user_type      enum('submitter','reviewer') NOT NULL
);

И свой изначальный запрос переделать через JOIN:

SELECT * FROM application a
  JOIN application_user au USING (application_id)
WHERE au.user_id = :user_id;

Это все не повод отказываться от использования OR совсем и в любой непонятной ситуации создавать и джойнить новые таблицы. Но особенности этого оператора стоит иметь в виду, особенно, когда вы работаете с большими объемами данными.