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

Когда начинал джуном, всё было просто: чужой код, который ты видишь в проде 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, различным мониторингам и алертам на качество данных (типа как тесты у разработчиков). Предотвращать получается дешевле, чем чинить.

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

Я, когда у меня не работает таск: наверное я что-то не так делаю, 2 часа изучают документацию, пробую по-разному, потом спрашиваю совета у коллег. Не исключено, что в результате у меня будут лапки.

Синьор, когда у него не работает: приносит ишью в разработку инструмента «тут ваш таск падает, вот логи, вот контекст; а давайте сделаем так, чтобы он падал пораньше? а не в самом конце, когда проработал два с лишним часа». (И ещё сразу прикладывает пулл-реквест с нужной доработкой, типа «посмотрите я тут начал делать» =)

Нужен ли английский разработчикам?

Чтобы серьёзно обсудить этот вопрос в Moscow Python позвали двух филологов (Youtube, iTunes и Overcast)

Недавно столкнулся с кейсом «зачем нужен английский». Даже не для того, чтобы читать документацию или статьи в оригинале. Ещё на несколько уровней ниже:

Как. Называть. Переменные.

Разбираем с приятелем его код на Джанго для курсовой работы. Вроде всё работает, но собрано из разных частей. Надо понять КАК оно работает. Доходим до стандартной функции get_or_create — название вроде говорит само за себя. Спрашиваю его «что происходит в этом кусочке?», в ответ задумчивость.

И тут до меня доходит, что не все умеют читать на английском. Тогда я его прошу перевести название функции и он по очереди забивает в словарь get и потом create, чтобы понять предназначение функции, которой он воспользовался.

Без знания английского действительно тяжело даже просто писать и читать код.

послушал два подкаста на схожую тему — про профессиональный путь в дата-отрасли:

1. Валерий Бабушкин про технический путь

Кулстори из рабочих будней про командировки по колхозам и молокозаводам. Плотный график разных проектов с жёсткими сроками и требованиям по точности расчётов даёт +100 к опыту.

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

Про мэтчинг грейдов между компаниями: когда миддлы из Х5 или Яндекса идут синьорами-хедами в другие компании; или мега-синьор из вне тянет в Х5 только джуна.

Про общую оценку кадров в Х5: 10 профильных докладов на последнем Датафесте (видео от мая 2021) как итог работы Валерия директором по данным.

https://youtu.be/hfrNLA-cHqo

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

2. Семён Осипов про работу и рост инженера данных

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

Про рост зарплаты: первым делом договариваешься с лидом о встрече через Х месяцев, потом приходишь на неё готовый с результатами своей работы с прошедший период. Повторить итерацию.

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

iTunes, Overcast, Youtube

Канал Семёна про инжиниринг

#подкаст

Spotify Engineering Culture

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

Часть 1 https://youtu.be/Yvfz4HGtoPc
Часть 2 https://youtu.be/vOt4BbWLWQw

много можно применять к работе и инженеров данных: у нас тоже есть команды, цели, релизы и гильдии. Да мы практически software engineers ^_^

==[=====>


Минимальная организационная единица — автономный сквад из 6 человек. Внутри сквада люди сами решают как делать, как взаимодействовать.

Офис утроен под сквады: рабочие места рядом + место для обсуждения со стенами-досками для письма.

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

«Как вы планируете спринты? Какой IDE используете?» — зависит от сквада — везде по-разному.

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

Трайб — группа сквадов.

Горизонтально между собой отдельные специалисты из разных сквадов собираются в гильдии — например, бэкендеры или дизайнеры (или ИНЖЕНЕРЫ ДАННЫХ, хе-хе).


Релизы

Чем больше релиз, тем труднее его выкатить → больше боли → реже релизы → релизы всё больше → круг замыкается

Проще делать небольшие релизы и катить их чаще. Релиз должен быть повседневной рутиной, а не эпическим квестом.

Отдельные релизы для разных кусков приложения, чтобы не зависеть друг от друга и не синхронизировать выкатки.

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



<====]==

Ещё по теме: тот беглый поиск в начале подсветил, что в когда-то давно я кидал ссылку подкаст с разработчицей из Спотифай, так что можно сравнить информацию из видео с отчётом из первых рук
https://news.1rj.ru/str/data_days/66

Выдрал кадр из ролика про культуру в Спотифай про «гильдии» внутри организационной структуры.

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

Получается в два раза больше коллег, всяких активностей и чатиков с мемами!

А в «гильдии» всегда можно спросить совета или подсмотреть полезные практики из нашей сферы. Особенно радует количество синьоров в шаговой доступности (или на расстоянии одного сообщения в Слаке).