data будни

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

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

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

2022-06-28 14:52:38 Работа идёт только вперёд →→→

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

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

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

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

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

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

2022-06-01 11:53:51 Вакансии аналитиков март-май 2022
Количество вакансий аналитиков относительно прошлого года упало не на много, всего на 14%. Но по сравнению с предыдущими тремя месяцами сократилось на более значительную цифру в 27%. Это можно было бы списать на сезонность и меньшую активность весной. Она и вправду есть, но в прошлом году весной вакансий в сумме было больше, чем зимой.

Зарплаты относительно прошлого года выросли на приличные 20%. И рынок при этом всё ещё перегрет — на одно активное резюме на сайте приходится в среднем две вакансии.

В разбивке по срезам просели все типы вакансий, кроме удалённых. Таких стало на 16% больше даже с учетом отступающего ковида. Больше всего упали позиции младших аналитиков, на целых 40%, получить первую работу, к сожалению, станет сложнее. Зарплаты выросли больше всего у инженеров данных и дата саентистов.

Данные и обзор подготовили:
@revealthedata @leftjoin Открыть/Комментировать

2022-05-06 07:37:15 Marc Lamberti написал короткий и понятный пост про путь данных из источников к Data Mart через Data Lake.

а Руслан Фатхутдинов перевёл его. Получилось интересно. Открыть/Комментировать

2022-05-05 13:27:55 Хочешь научиться — попробуй научить В этот раз я решил не записываться студентом на новый курс от Практикума (двух, пожалуй, хватит). Вместо этого зашёл с «черного хода» и записался туда ревьюером — буду проверять домашки у студентов. С уважением и немного… Открыть/Комментировать

2022-05-01 12:13:20 #подкаст про работу программистом в Гугле

Послушал интервью Ларисы Агарковой — менеджера и техлида уровня 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/titles/tpp20/the-pragmatic-programmer-20th-anniversary-edition/

Naval Ravicant (просто умный дядя из Долины)
https://www.navalmanack.com/ Открыть/Комментировать

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

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

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

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

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

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

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

2022-04-23 13:18:56 Продолжение...
В качестве замеров используем 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 Открыть/Комментировать