Интернет — полезная штука, там можно найти всё что угодно.

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

Хочу подсветить пару годных штук на этом бесконечном конвейере (на конфе как раз спрашивали):

Как стать Data Engineer от Адиля Хаштамова
https://khashtamov.com/ru/data-engineer/

Годная заметка с обзором набора технологий и навыков для инженера данных:
⁃ SQL
⁃ Python
⁃ Основы BI
⁃ Облака
⁃ Алгоритмы и структуры данных
⁃ Распределённые системы

Если достаточно погрузиться в каждую из этих областей, то там уже бац! — и миддл.


Видео от проекта DataLearn Дмитрия Аношина и его команды
https://www.youtube.com/channel/UCWki7GBUE5lDMJCbn4e1XMg/playlists

Дмитрий потихоньку записывает свой «видео-учебник» DE-101 по дата инжинирингу: постепенно разбирает тему за темой. Удобно, что есть общая линия, то есть все нужные темы разберут.

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

Плюс про реальные кейсы часто приходят рассказать крутаны с рынка: Роман Бунин, Николай Голов, Роман Зыкина, Евгений Кудашёв и другие. Получается отдельный трек с прокладными вебинарами (типа лекции и семинары)).


Если есть что-нибудь, что вам сильно помогло на пути дата инженерии или аналитики, поделитесь, пожалуйста :-) можно @sashamikhailov или в комменты ↓

Infomate.club/de

Знаете кто такой vas3k? Это который автор культовой околоайтишной рассылки (†) и чьи статьи собирают миллионы просмотров (мой топ — вычислительная фотография и машинное обучение для людей)

В обычной жизни Вастрик работает питон-программистом (вроде какое-то время даже работал в той самой Anaconda) и делает всякие штуки. Одна из таких штук — простенькая rss-читалка с web-интерфейсом. Называется Infomate.club

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

У меня был какой-то набор ссылок на профильные ресурсы, плюс ещё пачку досмотрел в посте Дмитрия Аношина, и засунул всё это в этот Infomate в виде отдельной страницы — получилась такая веб-газета для дата инженеров:

⁃ %company% Engineering — техно-блоги компаний
⁃ Dmitry Anoshin recommends — одноимённая подборка
⁃ Infrastructure — Amazon, DBT, DataBricks, Astronomer, Fivetran
⁃ [Data] Mix — /r/DataEngineering, TowardsDataScience, Monte Carlo Data
⁃ DE Telegram — если вдруг лень читать в приложении))
⁃ Podcasts — что послушать
⁃ и чуток Software Engineering

http://infomate.club/de

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

Weekend Offer от Яндекс GO

В это воскресение можно попасть на собеседование в Яндекс (и даже сразу на два, если повезёт). Для этого до четверга надо решить два задания на Контесте.

Там понадобится шарить в алгоритмах, поэтому подойдёт тем, кто решает алгоритмы для фана вместо кроссвордов и судоку; или уже месяц не вылезает из LeetCode и щёлкает easy и medium оттуда ))

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

https://yandex.ru/promo/events/fasttrack-taxi-analytics

Я как раз недавно прошёл этот путь (не в рамках Weekend Offer, а просто) и теперь вот датаинженерю в Яндекс GO; поэтому могу ответить на вопросы или рассказать что-то подробнее, если интересно.

почему мне тут нравится:
⁃ есть воля сделать хорошо (выше постил конспект выступления Head of DWH — Феди Лаврентьева)
⁃ есть ресурс на это всё (Федя уже договорился с бизнесом)
⁃ уже влито куча энергии в инфраструктуру и в планах продолжать
⁃ все сущности задокументированы — нет боли неведения
⁃ крутые крутаны за соседними столами (ну или в чате в Слаке / ревью в Гитхабе)

плюс известная атмосфера Яндекса с кучей плюшек.

кароч, GO к нам

Кстати, об алгоритмах — вот Антон Жиянов коротко и чётко описал в чём там суть, зачем вообще понимать сложность какого-то алгоритма.

Там серия из 4 постов, вот первый:
https://news.1rj.ru/str/ohmypy/114

BREAKING: всея отечественного дата сайенса — Валерий Бабушкин — завёл свой канал. Стопудов там будет интересно.

https://news.1rj.ru/str/cryptovalerii/3

П.С.: не могу пройти мимо упоминания «пирамиды» — это та самая пирамида, на которую я опирался, когда приходил в инжиниринг данных ^_^
https://news.1rj.ru/str/data_days/159

Датаи́зм (data-ism) — философская парадигма, провозглашающая, что Вселенная состоит из потоков данных и что ценность всякого явления или сущности определяется их вкладом в обработку данных.

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

https://ru.wikipedia.org/wiki/Датаизм

===

Узнал о новой «религии» (?). Не знаю пока, что с этим делать, но лучше быть в курсе 🙂

Увидел такую визуализацию и залип (спасибо каналу Data-comics)

Как автор так удачно разместил все горы в аккуратные треугольники? Какое красивое естественное распределение получается: 1 уровень — одна гора (Фуджи); 2 уровень — три; и дальше по нарастающей.

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

И, кажется, всё равно пришлось немного округлить высоту каждой горы до какого-то значения. А потом вспомнил, что это карта 1886 года и вряд ли они тогда знали, что высота Фуджи именно 3 776 метра. Так что автору скорее всего и округлять не пришлось :-)

Но на этом остановиться я не мог и сделал чарт в Гугл-таблицах (да простят меня коллеги из BI), чтобы узнать как на самом деле выглядит распределение высот гор в Японии.

Взял список гор с высотами (спасибо Википедии и стандартной формуле IMPORTHTML), округлил значения до 100 и в сводной таблице посчитал количество гор для каждого такого «бакета».

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

Гугл-таблица с данными, вдруг вам тоже интересно

Подглядывать через плечо к программистам

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

https://news.1rj.ru/str/data_days/46

Это получился такой прикладной уровень

Чем дальше подсматриваю, тем более высокоуровневые вещи открываются.

Например, есть проблема скорости разработки: легко пилить новые фичи, когда кода немного; но потом система становится сложнее и каждая новая фича затрагивает всё больше её частей. Если не прикладывать усилий, то скорость разработки будет стремиться к нулю.

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

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

Нравится слушать ребят из Moscow Python подкаста ↓

тимлид и ответственность

Плоская структура без руководителей и менеджеров хорошо работает в небольших системах. При росте системы растёт и сложность; и появляется свой «налог» — должен кто-то отдельный заниматься процессами и рулить этим хаосом.

Правильный тимлид — это не просто прораб, который утром раскидал задачки рабочим, а потом весь день покуривает сигару в тенёчке.

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

На примере гостя подкаста хорошо видно, что тимлидом можно стать ещё до официального назначения. Надо просто постепенно брать больше ответственности, разгружая своего руководителя («есть тимлида по кусочкам», хе-хе). Вспоминается фраза, что «ответственность нельзя дать, её можно только взять самому».

Слушать в Overcast и iTunes

#подкаст

Внимание, опрос!

Не так давно попал в DWH Яндекс GO: тут ребята идут в data mesh со своим гибридом Anchor Modeling и Data Vault. Каждый день крутятся несколько тысяч ЕТЛ-процессов, обновляя сколько-то там сущностей. А в конце всего этого пайплайна находится отдел Ромы Бунина (@revealthedata) со своей космической BI-системой и стайл-гайдами.

Кажется, можно было бы больше рассказывать про разную местную внутрянку. Что думаете? Что было бы интересно узнать?

Про процесс собеседований

Так, отлично! Опрос ↑ показал, что можно писать про Яндекс. Я то я переживал, что будет неинтересно 🙂

Не знаю с чего начать — пожалуй, начну с начала, т.е. с собеседований

Общий порядок для инженера данных выглядел так:
0. Знакомство и скрининговое интервью с рекрутером
1. Секция про SQL + программирование
2. Секция про SQL + программирование
3. Секция про алгоритмы
4. Знакомство с командами (1-3)
5. Оффер

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

0. Рекрутер

В прошлом году я сам откликался, и на первом созвоне рекрутер спросила в общем об опыте работы и про цели. Потом задала базовые вопросы про питон: про иммутабельные типы и что может быть ключем словаря. Тогда я не ответил, и дальше не прошёл.

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

Рекрутер — это связующее звено между кандидатом и компанией. Он назначает следующие встречи, отвечает на вопросы по статусу и любые другие. У меня получился очень комфортный процесс: если вопрос был на их стороне, то рекрутер всегда держал связь и ориентировал, когда ждать ответа (Никита, привет!).


Собеседования по коду

Дальше были две секции по SQL и программированию:
- сначала простая задача на джойн (связать две таблицы без потерь),
- потом задача на программирование (отсортировать чётные/нечётные, рассадить зрителей в кинотеатре)
- плюс в конце общий вопрос: у меня было про возрастание долей (типа парадокса Симпсона) и верхнеуровнево прикинуть структуру рекламных доходов РСЯ.


Собеседование на алгоритмы

Третьим собеседованием были АЛГОРИТМЫ! Тут обычно дают две-три задачи. Длительность ограничена 90 минутами, а задачи подбираются так, что можно было бы их решить за 10-30 минут. То есть гуру решают три задачи и ещё остаётся время на поговорить. А кто-то останавливается на первой.


Финалы

Если проходишь алгоритмы, то следующий этап — знакомство с командами (помните, что «трек» общий и до этого собеседовались во весь Яндекс). Во внутренней системе появляется кандидат и команды могут проявить к нему интерес. Назначаются 1-3 встречи с командами (т.н. «финалы»), где общаешься с потенциальными начальниками и коллегами.

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


Оффер

Оффер будет только один — от команды, которую ты выбрал. Оффер готовят вообще другие ребята: не те, которые тебя собесили, не твой руководитель и даже не рекрутер. Специальные математики в недрах Яндекса готовят предложение о работе по единым стандартам.

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

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

Если оффер принят, согласуешь дату выхода и приходишь. Дальше получаешь ноут, доступы, проходишь онбординг и начинаешь перформить 🙂


----
Получилось коротко, но обо всех этапах. Если что-то забыл, пишите в комментах или спрашивайте в личку @sashamikhailov

Инженеры данных и аналитики

В небольших компаниях инженеры данных как человек-пароход: сам данные достал из источника, сам спроектировал слои и сущности в двх, сам сделал графики и положил их на дашборды (может, это и называют Analytics Engineer?)

То есть тут роль меньше человека: один человек включает в себя несколько ролей.

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

Есть выделенная роль аналитика (в Яндексе их называют «партнёры по данным») — они разговаривают с бизнесом, изучают предметную область и отвечают за качество и консистентность данных. Это к ним потом приходят с вопросами «а как мне сджойнить водителей с географией?» или «где мне найти суммы заказов по пешим курьерам без НДС?»

И отдельно работают инженеры данных. На вход им подаётся уже довольно детализированная задача: откуда что достать, как назвать и куда положить; как же удобно работать, когда на новую пачку данных у тебя уже есть готовая ER-диаграмма связей!

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

Ну и где-то дальше по конвейеру сидят мастера BI, готовые из сырых данных делать полезную красоту.


----
интересно, а как у вас? чем обычно занимается инженер данных? а аналитики?

DWH Яндекс GO нанимает…

… всех 🙂

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

⁃ можно в зрелые Такси или Маркет
⁃ можно в молодые и дерзкие Лавку или Драйв
⁃ а можно в девственный «стартап» — Доставку (← я тут)

А над этим всем есть ещё отделы по инфраструктуре — пилят hNhM (свой аналог Anchor Modelin / Data Vault) и помогают с проектированием; плюс отдельные ребята, которые занимаются платформой — свой аналог распределённого ETL-оркестратора на основе Luigi.

Все вместе мы пробуем в Data Mesh (пока вроде получается).

И везде есть свободные места, все нанимают:
⁃ Инженеров данных (хе-хей!)
⁃ ETL-разработчиков (это лайт-версия инженеров по данным, насколько я понял)
⁃ Партнёров по данным ( ~ аналитики данных )
⁃ Системных аналитиков (общаться с бизнесом, думать СИСТЕМНО)

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

https://go.yandex/ru_ru/promo/join-dmp-team

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

В опросе лидируют BI-разработчики, что в принципе логично 🙂

Рассказываю, как это было у нас: собрались, значит, все отделы вместе, чтобы рассказать кто что делает, какие есть успехи, в чём возникают проблемы и с чем надо помочь.


Выходят продакты
… делаем приложение удобным для заказа, проводим кастдевы, ездим в поля, а ещё активно считаем ретеншен и хотели бы получать валидные данные из источников в ДВХ!


Выходят маркетинговые аналитики
… значит, у нас тут перформанс, бюджеты, сегментация. Хотим, чтобы все расходы были в одном месте и подтягивались автоматически, чтобы мы могли сравнить их с выручкой — рассчитываем здесь на помощь ДВХ!


Выходит отдел b2b продаж
… в общем, у нас тут много продажников, у каждого есть клиенты в работе, они идут по воронке. А ещё есть несколько источников с ручным импортом, которые часто ломаются.
Вот бы ДВХ нам всё настроил по красоте и вывел данные по клиентам и менеджерам на единый дашборд!


Выходят BI-разработчики
… короче, есть куча дашбордов, часть метрик между ними повторяется, но почему-то значения у них различаются. Было бы классно, если бы ДВХ сделал так, чтобы одни и те же метрики на разных дашбордах показывали одинаковые значения 🙂


Я почему-то раньше думал, что ДВХ это где-то сбоку, а настоящая работа происходит где-то на уровне сайта-приложения или в районе бэкенда. Получается, что на ДВХ завязана куча процессов и в целом он важен для всех.

🧪 ЭКСПЕРИМЕНТ! 👨‍🔬 пятничная флудилка

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

или скинуть последний мем…
или поделиться интересной ссылкой…
или спросить за жизнь…

ну или просто поздороваться с товарищами-читателями 👋

Head of ML в Blockchain.com готовит ЕТЛ-инфраструктуру. Интересно почитать рассуждения со стороны МЛ плюс тред на 100+ комментов.

А ещё там вакансии для инженеров данных с релокейтом в Лондон

Одной из задач, стоящих перед мной в Blockchain.com, является подготовка инфраструктуры к росту объемов хранимых и используемых данных, деплоя моделей машинного обучения, работающих как в риалтайме так и по батчам и инфраструктуры для финансовых данных.

Будь я в России, то наверное пошел бы по проторённой дорожке: Hadoop, Postgres, Spark, Clickhouse,Kafka

Но так как я имею преимущество нахождения текущей инфры в хорошем облаке, почему бы этим не воспользоваться?
Тем более что от нескольких друзей я услышал про новый паттерн Data Lakehouse.

В классической истории есть Data Lake где хранится всякое и есть DWH где хранится всякое обработанное, вытащенное и очищенное из Data Lake

Что предлагает Data Lakehouse?
В существующих дата лейках, чтобы использовать какое-то BI или ML приложение, нужно под них налаживать ETL
LakeHouse позволяет всем приложениям (ML, BI, ...) иметь постоянный доступ ко всем данным без отладки ETL каждый раз заного, что гарантирует консистентные данные, собранные из различных источников в даталейке.

ETL встроен в мета слой. Без data management/governance слоя каждая команда к источникам подрубается своими etl процессами и создает свои датамарты, затем непонятно как их поддерживает что создает проблемы с переиспользованием и дупликацией.

Вторая часть приятных вещей - транзакционность, для этого вводится delta tables/files/transaction log/engine/storage layer

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


Из того что я видел, Lakehouse предлагает Google (на Bigquery к которому я подозрительно отношусь), Databricks и AWS
С ребятами из Датабрикс мне советовали встретиться давно, тем более что основатели Датабрикс - создатели Spark. В итоге они сами на меня вышли и на этой неделе я планирую провести с ними уже вторую встречу и послушать их Solution Architect

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

Кстати мне сейчас нужны дата инженеры, заниматься этим и многим другим. RVожно как фул ремоут, так и с релокейтом в Лондоне. Есть офисы в Майами и Буэнос Айресе. Платим мы примерно как ФБ, если говорить про зарплату про и бонус, смотри #BigTechLevelsCompensation в дополнение есть криптобонус и опционы, которых мы даем даже чуть больше ФБ в абсолютах и это при текущей оценке! Можно податься здесь