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

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

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

Юля собрала полезные советы для собирающихся в Яндекс

П.С.: подписывайтесь на Юлю — там весело (а не то что тут)

Самое вкусное это конечно V2: Советы, ссылки и всяческая польза.
Я на себя взяла смелость оформить в двух вариантах: вот этим постом, тут чуть сокращенно и следующим также в телеграфе. На вкус и цвет как говорится.
“…Как попасть в Яндекс
Всем доступный путь - это откликнуться на вакансию на официальном сайте Яндекса. Но вы сами понимаете, сколько людей туда откликается каждый день, поэтому шансы, что именно ваше резюме заметят и выделят - наверное не очень высокие.

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

Еще один путь - участвовать в маркетинговых мероприятиях типа One Day Offer или Fast track - https://yandex.ru/jobs/hiring-events (ближайший). Все, кто сможет пройти входной контест, будет приглашен на собеседование.

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

Как готовиться к собеседованиям
Лучший источник задач и решений - это литкод. Для Яндекса нужно прорешивать задачи уровня Easy и Medium.

Если у вас есть подписка - то обратите внимание на штатные подборки задач, если нет - то много классных сборников есть в сети (например).

Старайтесь минимизировать попытки сабмита задачи и учитесь дебажить код в уме - на собесе прогнать тесты вам никто не даст.

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

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

Очень рекомендую тренировки по алгоритмам:
https://yandex.ru/yaintern/algorithm-training_1
и https://yandex.ru/yaintern/algorithm-training#schedule
решайте домашки, смотрите разборы.

Попробуйте решить контест для Weekend offer. Если получится - то там уже и до офера недалеко)

Важное
Об этом нигде не пишут, но я крайне рекомендую: изучите и напишите с нуля все популярные алгоритмы сортировки: quick sort, merge sort, heap sort. Они все пишутся за 20 (heap sort - 40) строчек кода на питоне и легко гуглятся. Изучите, какая сложность у этих алгоритмов: в лучшем случае, в худшем, в среднем. Для каких случаев какой алгоритм предпочтительней.

Напишите сортировку пузырьком. Найдите 3 способа ее улучшить. Убедитесь, что сложность все равно осталась квадратичной. Найдите кейс, когда пузырек будет работать быстрее, чем quick sort.

Несколько лайфхаков для алго-этапа от меня:

1. Пишите на том языке, на котором вам удобно, даже если он отличается от языка, на котором вам потом придется работать

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

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

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

5. Называйте переменные осмысленно, но без фанатизма.

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

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

Напоследок
В Яндексе сейчас около 2000 открытых вакансий.”

#отдушидушевновдушу

Как минимум это интересно: GoogleDocs научились ходить в BigQuery

Вроде логичная интеграция: есть неограниченное хранилище и интерфейс к данным, к которому все привыкли; осталось только соединить одно с другим.

(если учесть, что BQ тарифицирует за чтение данных, то продакты Гугла должны быть довольны: проще читать данные → больше подключений → больше профит!)

https://support.google.com/docs/answer/9703000

Я попробовал по-быстрому зайти и открыть какой-то публичный датасет — например какие-то данные Википедии. Можно увидеть что к IP 68.39.174.238 приписано 12455 уникальный айди страниц.

Осталось получить от data steward ссылку на data catalog, чтобы проследить data lineage и узнать что за данные лежат в этом data source.

Reversed Orchestration

Ben Stancil в очередном выпуске свой рассылки рассуждает о недостатках текущего подхода к оркестрации как цепочек зависимых тасков, начиная от входных слоёв и заканчивая витринами.

https://benn.substack.com/p/down-with-the-dag

Одна из проблем — в увеличивающимся количестве графов, тасков и сущностей:

> In 2022, data engineers manage forests, not trees

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

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

Автор предлагает подойти с другой стороны — проставить всем сущностями требования по свежести данных: например, по 4 часа на главные витрины , на промежуточные сущности 12, вспомогательные справочники и того меньше. И пускай там под капотом система сама решает когда какую сущность грузить.

Из преимуществ такого подхода — сглаживание пиков по нагрузке на вычислительные мощности. Система сама должна прикидывать когда что запускать, чтобы попасть в ожидаемые границы SLA по всем сущностям (а не просто все считать раз в N часов по крону).

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

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

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

Отдельно зашёл с компа и протыкал все ссылки. Мемчики с тиктоками оставил в авторском оригинале, а отдельно собрал ссылки на всякие статьи-заметки:

- Moving past Airflow: Why Dagster is the next-generation data orchestrator
- Why Not Airflow?
- The Unbundling of Airflow
- Airflow's Problem
- Data plane activation
- Either-or decisions
- The powder keg of the modern data stack
- The data OS
- Data Traffic Control with Apache Airflow
- (Re)Introducing Prefect: The Global Coordination Plane