🤌 Цели как инструмент приоритезации задач

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

Ещё одна полезная заметка Жени Козлова (автора поста про грейды аналитиков ↑). В ней приводятся примеры как цели помогли наладить работы отделов BI и DWH в Яндекс GO.

про BI:
> Мы решили, что работаем для того, чтобы в компании лучше принимались решения: более объективно, с опорой на данные. Посчитать долю качественных решений от всех решений — невозможно, поэтому мы придумали прокси-метрику. Это DAU отчетов, обладающих некоторым набором свойств, которые характеризуют качество этого отчета. Мы назвали такие отчеты сертифицированными.

про DWH:
> … в хорошем хранилище, аналитик пишет мало кода в SQL-запросах, делает минимум джойнов и вообще почти все запросы у него идут к красивому, причесанному, задокументированному слою витрин, а не к сырым слоям данных.

https://telegra.ph/Pochemu-ne-tonut-korabli-ili-chto-takoe-horosho-sformulirovannaya-cel-12-23

Нет войне!

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

В детстве у меня были сны о том что в наш небольшой город пришёл Годзилла; и это ощущение беспомощности и неотвратимости перед большой угрозой вызывало у меня буквально панический страх. Война — это как Годзилла, только на самом деле.

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

Больше всего пугает, что это осознанное и просчитанное решение. Где-то там существует документ, где строились эти планы и обсуждались альтернативы: « … а чтобы достичь ключевых подателей в 2022 предлагаем напасть на Украину … » и внизу печать УТВЕРЖДЕНО.

про рынок найма в IT

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

⌘⌘⌘

С одной стороны после локдауна везде пришла удалёнка. Больше нет «региональной» разработки — к спецам Новосибирске сначала пришли столичные рекрутеры со своими предложениями, а следом за ними уже стучались их зарубежные коллеги с ещё большими зарплатами.

в подкасте звучали зарплаты 300-500 у синьоров на нашем рынке и 500-700 на западном (просто для ориентира, без контекста)

С другой — удалёнка пришла не только к нам. Фейсбуки с гуглами могут выбирать людей со всего мира. И тот же спец из Новосибирска будет конкурировать за место с ребятами из Индии или Аргентины. Возьмут не всех.

Это простые тезисы, жизнь получается сложнее. Есть люди, которые предпочитают офис рядом, дружных коллег и зарплату на 30% меньше, а не удалёнку / релокацию в далёкие непонятные земли. Есть люди, которые возвращаются назад с опытом в FAANG и приносят сюда забугорный опыт.

⌘⌘⌘

Немного статистики про рынок найма:
⁃ если раньше разработчики хорошо шли на зарплату в 180К, то теперь «начинают думать» от 300К ₽.
⁃ чтобы вывести разработчика на вакансию рекрутер сейчас отправляет ~700 холодных сообщений потенциальным кандидатам (раньше было ~300)
⁃ чтобы расширить воронку найма некоторые компании нанимают местного англоговорящего лида, который потом набирает себе команду разработчиков без знания английского. Профит!

⌘⌘⌘


Слушать в iTunes и Overcast

#подкаст #послушано

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

Лучший пример сторителлинга данных, который я знаю, — проект Fallen 2015 года (интерактив и видео) про потери второй мировой войны. За счет изложения фактов визуализация объясняет происходившее и тоже вызывает эмоции. В основном страх, но в конце и надежду. Но помимо эмоций визуализация вызывает доверие за счет использования данных, а не уловок и фейков. Покажите эту визуализацию тем, кто забыл к каким жертвам приводит война.

Три недели спустя. HR-сводки.

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

⌘⌘⌘

Компании срезают профессии «жирного времени», которые могут совмещать другие сотрудники:
⁃ тестировщики (разработчики могут тестить сами)
⁃ UI/UX дизайнеры (есть и другие дизайнеры более широкого профиля)
⁃ продуктовые аналитики (сейчас не до анализа продуктов; сохранить бы что есть)

⌘⌘⌘

«Астрологи Армении объявили неделю IT — количество специалистов в удвоилось». По официальным данным 25к специалистов прибыло в Армению и ещё 60к — в Грузию.

Для сравнения — до этого в Армении было около 15 тысяч айтишников. Но нет никакого местного «IT-рынка». Нельзя будет найти «местную» вакансию. Это только как база для работы на какую-то мировую компанию.

Сайдэффект: приехавшие заддосили инфраструктуру Еревана; всем нужно открыть юрлица и счета в банках, но количество «окон» не рассчитана на такой поток.

Кто-то вывозит сотрудников отдельными чартерами (как Миро). Кира сняла большой дом для команды; получился такой коливинг.

⌘⌘⌘

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

Был рынок кандидата, стал рынок работодателя (адекватного). Раньше количество вакансий было больше кандидатов, сейчас — наоборот.

⌘⌘⌘

«Джуны не нужны» (( Компании лучше будут вкладывать в удержание текущих сотрудников, чем в образование стажёров.

Джунам и так было непросто найти работу, а стало в 10 раз сложнее.

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

⌘⌘⌘

Будет ли русофобия в зарубежных компаниях? В общем нет, а в частности может быть всякое.

Точно нельзя будет физически платить в России. Если надо работать на зарубежную компанию, надо физически релоцироваться в нейтральные земли.

⌘⌘⌘

Обидно за державу. За последние годы наши специалисты стали цениться в мировых компаниях. Для примера топовые отрасли:
⁃ финтех
⁃ тревел
⁃ крипта

⌘⌘⌘

У кого всё будет хорошо?

⁃ диджитал- и перфоманс-маркетологи. По-прежнему надо покупать рекламу. Кто знает какую и почём — в шоколаде.
⁃ ДС и МЛ всё ещё в шоколаде.
⁃ Девопсы (настоящие) и SRE всегда нужны.
⁃ У айти-рекрутеров тоже работы будет достаточно.

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

⌘⌘⌘

Кира и команда NewHR стараются помогать в это непростое время и сделали цикл мероприятий: от горячей hr-линии до разбора резюме в прямом эфире.

Больше подробностей в их блоге https://blog.newhr.ru/

⌘⌘⌘

Слушать подкаст в iTunes и Overcast

#подкаст

Хочешь научиться — попробуй научить

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

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

Зафиксирую свои ожидания, чтобы потом можно было сверить с фактическим результатам (да, как в настоящих АБ-тестах):

⁃ развить техническую насмотренность;
⁃ прокачать навык код-ревью;
⁃ посмотреть чему там учат.

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

П.С.: ещё работает как метод эскапизма — найти вторую работу, придумать себе занятие, чтобы меньше времени оставалось читать новости.

Не доверять проду

Когда начинал джуном, всё было просто: чужой код, который ты видишь в проде 100% лучше твоего. Смотри, вникай, учись.

Но дальше всё стало сложнее. Оказывается, в продет тоже может быть плохой код (отдельная история, как он туда попал, но всё же). Делаешь ПР на основе текущего кода и на ревью узнаешь, что сделал плохо, хотя просто повторил что уже есть.

И теперь прошлое правило не работает. Приходится читать текущий код и понимать: где написано хорошо,  а где — так себе. Ведь код после тебя должен становиться лучше, чем до.

Такой вопрос я задал Фёдору Борщёву, а он ответил, что любой код — это компромисс между хотелками и временем. К каждой строке кода надо подходить с подозрением и критическим восприятием: почему здесь сделано именно так? Какие цели решал автор? Какие у него были ограничения?

https://news.1rj.ru/str/pmdaily/937

Сравнение даты и строки в Postgres

Первый «улов» с поля проверок заданий студентов на курсе по DE. Коллега-ревьюер заметил, что у студента в работе теряются часть записей, когда в SQL запросе идёт проверка даты и строки:
<..>
WHERE created <= '2022-04-03'

Короткий поиск подкинул вопрос со StackOverflow. Оказывается, чтобы сравнить время со строкой, под капотом Постгрес приводит строку ко времени; тогда он наивно из ‘2022-04-03’ получается '2022-04-03 00:00:00’, то есть начало суток, а не конец, как ожидалось.

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

Filter: (created <= '2022-04-03 00:00:00'::timestamp without time zone)

Как решение предлагают в запросах явно приводить дату-время к дате перед сравнением со строкой
WHERE created::date <= '2022-04-03'

тогда под капотом будет сравнение дат с ожидаемым результатом:

Filter: ((сreted)::date <= '2022-04-03'::date)

———
Продолжение: Олег Юрьев проверил через EXPLAIN

#подкаст про распределенные вычисления

Егор Хайруллин из Яндекса пришёл рассказать что там есть кроме «мап-редьюс». Ниже мои заметки, что я услышал:


Зачем нужны распределённые вычисления

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

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


Почему у всех «свой» Hadoop
Например, у Гугла, Фейсбука, Яндекса. Почему не сделать «единый» опенсорсный. У всех свои проблемы: на 100 машинах — одни, на 10 000 — уже другие.


Что там есть кроме мап-редьюс
⁃ Файловая система, где хранятся данные.
⁃ Шедулер, который планирует джобы (тысячи их) для работы с этими данными.
⁃ Интерфейс управления (SQL-like), откуда приходят задачи для шедулера.


Почему плохо работают джойны?
Удобно джйонить, когда данные на одной машине. Если данные разложены по кластеру, уже всё сложнее.

Таблицы должны быть отсортированы одинаково и (их части) должны оказаться на одинаковых машинах, чтобы провести джойн

Сами джойны тоже можно написать по-разному — какой применить именно тут?


Чем отличаются операции класса мап-редьюс от реал-тайм?
МР — операции могут занимать десятки минут
РТ — «реалтайм»; пользователь кликнул на сайте, информация залилась в базу

МР — загрузки большими кусками, последовательное чтение и запись
РТ — много случайных записей и чтений. На каждое действие своя запись.

МР — если упало, можно просто пересчитать последний кусок
РТ — если упало, всё пропало, надо выискивать по кускам последние записи и исправлять.


Мап-редьюс подход меняет мышление

Удобно дебажить, когда у тебя одна машина и один лог. Когда машин несколько, начинается тёмная магия — куча логов, записей, связей по сети. Если упало, всё просто не работает. (А может оказаться, что на машину №ХХ данные пришли на секунду позже).


Слушать в iTunes и Overcast

К прошлой заметке про сравнение даты и строки неравнодушный читатель оставил комментарий, что лучше не применять функции к полю, используемому в фильтрации. Спасибо Михаилу за развёрнутое пояснение — я узнал новое и стал чуток умнее =)

Применение любых функций к полям, участвующим в фильтрации или условии джойна, приводит к проблемам производительности. Оптимизатор не может использовать индексы или, в случае аналитических СУБД, ключи дистрибуции и секционирования. В результате производится полное сканирование таблицы, или большое перераспределение данных, что плохо по определению, для больших таблиц. А предотвратить это достаточно просто — не изменять данные, по которым производишь поиск

Олег Юрьев погонял проверочные запросы через EXPLAIN ANALYZE. И на реальных данных проверил как влияет изменение поля фильтрации на скорость запроса.

С Олегом мы вместе учились в Практикуме. Он уже давно ревьюит работы студентов и набил на этом руку. Это насмотревшись на него, я тоже решил пойти в ревьюеры.

Подписывайтесь, уверен, что будет ещё много интересного:
https://news.1rj.ru/str/double_data/52

Продолжение...
В качестве замеров используем EXPLAIN Postgres - если, его выполнять как EXPLAIN ANALYZE, то получим фактическое время выполнения запроса - пример на первом рисунке.

Далее формируем два запроса:
Первый - в условии указываем полное время без преобразований

explain analyze select *
from sensors.weather w 
where w.ts between '2021-01-01 00:00:00' and now();

Второй - в условии экстрактим год и берем всё больше 2021

explain analyze select *
from sensors.weather w 
where extract ('year' from w.ts) >= 2021;

В исходной таблице есть индекс по полю ts.

Добавим щепотку статистики, чтобы не сравнивать два случайных времени, выполним и тот и другой 100 раз, строим боксплоты. Вперед.


Основной результат: отсуствие преобразований в WHERE дает 4х прирост к скорости выполнения запрос (естественно на этих данных и таком кол-ве, можно будет проверить как зависит от объема данных)

Детальный результат - 2 рисунка плана выполнения запросов, как только появляется преобразование в WHERE то мы имеем дело с SeqScan, без EXTRACT планировщик использует Bitmap Heap Scan \ Bitmap Index Scan

Вот такая арифметика, используйте SQL c умом

#de #sql #lifehacks

В соседний отдел «внедрения запрещенных технологий» ищут коллегу, кто будет помогать прикручивать всякие распространённые штуки типа Flink и Spark к внутренним велосипедам Яндекса.

Вижу тут два жирных плюса:
⁃ работать с известными «открытыми» инструментами отрасли инженерии данных;
⁃ работать в Яндексе: крутые технологии, куча данных, высокая экспертиза, толковые люди.

Такое пересечение не часто встретишь =)

То есть работа не про написание пайплайнов, как у «обычного» инженера данных, а именно про инструменты для написания пайплайнов.

В описании пишут, что ищут разработчика с опытом инженерии данных, но, может, подойдёт и сильный инженер с опытом промышленной разработки:

> Нам нужны сильные разработчики на Python/Java/Scala, которые готовы осваивать новые языки и технологии. Хорошо, если есть опыт работы с хранилищами данных, стримингом или батч-обработкой.

Если интересно, откликайтесь на вакансию; или пишите мне @SashaMikhailov — могу переслать вопросы прямо ребятам или закинуть ваше резюме напрямую рекрутерам (понадобится короткое сопроводительное сообщение)

#подкаст про работу программистом в Гугле

Послушал интервью Ларисы Агарковой — менеджера и техлида уровня 6 в Гугле.

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

- Онкол всегда два человека: даже если вдруг один недоступен, второй должен оперативно отреагировать.

- Если обсуждать проблемы в личке, то вокруг этого человека формируется Silo (замкнутая автономная экспертиза). Когда этот человек уйдет, и экспертиза тоже уйдет вместе с ним. Поэтому нужна документация на все действия (и обсуждение проблем через публичные каналы связи).

- Работа в «рекламах» (Ads) учит налаживать процессы по стабильности. Если вдруг что-то упало, то через 5 минут CEO Ebay звонит твоему вице-президенту и тот приходит в твой кубикал, и не уходит пока ты не пофиксишь баг. Вице-президент — человек, конечно, приятный, но часто бывает его видеть у себя не хочешь, поэтому строят процессы и потом ещё процессы на процессы.

- Всё обмазывается юнит-тестами и интеграционными тестами.

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

Слушать в Overcast и iTunes

Рекомендуемое чтение:

SRE Book
https://sre.google/sre-book/table-of-contents/

The Pragmatic Programmer
https://pragprog.com/noscripts/tpp20/the-pragmatic-programmer-20th-anniversary-edition/

Naval Ravicant (просто умный дядя из Долины)
https://www.navalmanack.com/

#послушано

проверить на одном айдишнике

На одном из первых боевых проектов делал дашборд по когортному анализу на данных клиента. И вот вроде всё посчитал, получились когорты, время и метрики. Вывел на стандартный треугольный график с хитмапом — вроде похоже на правду. Уже можно показывать клиенту? Спросил совета у коллеги.

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

Метод — универсальный. Студенты-инженеры с курса Практикума делают RFM анализ. Должны получиться айди пользователе и для каждого — метрики от 1 до 5. Написали запрос, получили результат; вроде похоже на правду. И сдают.

А в результате расчёта пользователи с недавним заказом получают худшую метрику. И наоборот. А можно было проверить результат расчёта метрик на паре пользователях и увидеть ошибку.

—-
Ещё на тему:
- Сравнение даты и строки в Postgres

Работа идёт только вперёд →→→

В книге «проект „Феникс“» был эпизод когда гуру рассказывал о правильной работе завода. Он говорил, что продукция должна двигаться только в одну сторону: со склада сырья до отгрузки конечной продукции. С той мыслью, что всякие доработки и брак ломают этот процесс — когда деталь возвращается назад, это замедляет всю работу.

Ощутил эту мудрость в деле. Делали оперативный слой данных в ДВХ: сущность, мета, загрузчик, релиз, бекфил → и погнали к следующей сущности. В итоге подготовили слой, чтобы прорастить нужные колонки в большую витрину.

В витрине внесли новый код в уже имеющееся SQL-полотно на две тысячи строк. Запускаем в прод, всё вроде норм.

Потом приходят пользователи и говорят, что в одной колонке пропали данные за декабрь 2021; а в другой некорректные статусы за прошлый июнь =(

Оказалось, что в оперативном слое часть данных не доехала, а в другом месте формат не совпал. И чтобы выяснить почему в витрине не хватает данных, ушло много времени, которое можно было потратить с бо́льшeй пользой 🥲

Теперь вот у нас есть отдельный трек по data governance, различным мониторингам и алертам на качество данных (типа как тесты у разработчиков). Предотвращать получается дешевле, чем чинить.