data будни

Каким-то образом удалось затесаться одним из гостей в подкаст Data Heroes от команды Николая Валиотти. Вчерашний джун попал в компанию матёрых сеньоров, хе-хе. Тем не менее постарался поделиться своими мыслями о работе инженером данных.

Опытом делились Семён Осипов из Gett, Ксения Томак из Dodo Brands и Сергей Бойцов; их и приглашаю послушать, получилось разносторонне, у всех свой опыт и итоговые советы получились довольно уникальными.

Ссылки где послушать в канале Left Join:
https://t.me/leftjoin/841

про Data Contracts в подкасте dbt

Chad Sanderson из Convoy (heavy modern data staсk users 🥸) делится своим кейсом: занимаются бизнесом, который truly ML driven, т.е. эм-эль не просто где-то сбоку, а без него не было бы самого бизнеса.

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

И так из других отделов тоже, общий тренд такой, что «мы не доверяем данным». Так начали развивать Data Quality (и до сих пор в этом процессе).

⌘⌘⌘

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

С другой стороны, разработчики — не демоны. У них нет цели сломать процессы, нижестоящие по пайплайну данных. Они могут быть просто не в курсе, что ИХ ДАННЫМИ пользуется кто-то ещё.

С источниками надо коммуницировать. Причём делать это лучше заранее, а не так чтобы прибегать к ним с криками «ВЫ ЛОМАЕТЕ НАМ ДЕШИ!», когда уже всё сломалось. На это они могут резонно ответить, что типа с чего это вы вешаете продакшен-критичные зависимости без предупреждения, мы не подписывались на это.

Ещё обсуждали, что дата-контракты могут «подписывать» только со стороны источника. Это в ответ на реплику в дбт-шном Слаке, что бывают producer-side и consumer-side контракты. Участники подкаста сходятся в том, что пользователи могут только обвешать входные данные чеками и алертами, но влиять на них не могут.

Ссылки на послушать на сайте подкаста:
https://roundup.getdbt.com/p/ep-34-why-youll-need-data-contracts

#послушано

Год в Яндексе

Тут в октябре случилась первая годовщина.

Из этого времени:
⁃ посидеть полгода в другом офисе от всей команды >_>
⁃ три месяца поработать удалённо из другого города
⁃ зайти на экскурсию в три офиса Яндекса в Москве
⁃ проехать мимо трёх офисов в других городах (жаль, не сложилось зайти — но бейджик был наготове!)
⁃ пройти два перфоманс ревью (пока вроде не выгнали)

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

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

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

План дальше выглядит как-то так:
⁃ записаться в ШАД;
⁃ дорасти до собеседующего;
⁃ поработать из офиса в другом городе.

Закрывая тему подкастов: оказывается, у Max Beauchemin (Бьюшемин?) тоже есть «свой» подкаст. Макс — автор Airflow и Superset, а подкаст они делают от имени Preset (платная версия их опенсорсного Superset).

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

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

Если кто-то коллекционирует тематические подкасты, добавляйте к себе. А пока продолжаем наблюдение.

https://podcasts.apple.com/us/podcast/the-analytics-everywhere-podcast/id1612532253

Ещё из новостей подкастов: у Самата Галимова вышли два интересных выпуска в подкасте «Запуск завтра»:

1. про российский StackOverflow — как студент сделал сайд-проект в универе, получилось хорошо и это стало основной работой. А потом продал его основателю «основного» StackOverflow — легендарному Джоелю Спольски.
2. про язык Kotlin, который был признан Google основным языком для разработки на Android. Как(и зачем!) в 2010 году в JetBrains захотели сделать свой язык программирования на замену стагнирующей в то время Java. И причём тут Андроид.

Оба выпуска слушаются как аудио-книга — невероятная история с поворотами и техническими деталями. Тут вроде нечего конспектировать, надо слушать)

Очереди сообщений

В подкасте Podlodka вышел выпуск про менеджеры очередей. Зашли с основных понятий и дальше по всем аспектам до антипаттернов проектирования. Рассказывал Владимир Перепелица, архитектор и продакт-менеджер из Tarantool.

До сих пор не сталкивался ни с Kafka, ни RabbitMQ, поэтому мне было интересно послушать. Что-то из выпуска записал (как мог):

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

⌘

В целом, чем-то похоже на базы данных: тоже запись и чтение. Иногда даже отдельные бд используют как очередь — в Яндекс GO используют Mongo в сервисе репликации данных от источников в DWH.

Отличие от баз данных: чтение — модифицируащая операция. Получатель сообщения подтверждает факт получения и брокер удаляет это сообщения у себя.

⌘

Антипаттерны — когда лучше не использовать очереди:
⁃ очереди добавляют латенси к работе как асинхронный инструмент по своей идее;
⁃ когда данные нужны прям сейа и нет смысла ждать (например посмотреть баланс в приложении: лучше сразу отдать ошибку, если не грузится)

⌘

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

⌘⌘⌘

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

в iTunes и Overcast

#послушано

Выпуск Data Coffee про собеседования

Три лида́ обсуджают как они проводят собеседования для инженеров данных:

⁃ Сколько по времени должно быть собеседование — нормально ли заканчивать их досрочно, если по кандидату точно «да» или точно «нет».

⁃ Сколько вообще может быть этапов у процесса найма.

⁃ Чем отличаются задачи для джунов, мидлов и синьоров. С какого-то уровня помимо основных инструментов (SQL+Python/Scala) требуется понимать и общую архитектуру (и альтернативные варианты с их плюсами и минусами).

⁃ Зачем сотруднику присоединятся к клубу собеседующих — прокачивает техническую насмотренность и помогает точнее сориентировать свой уровень относительно других.

⁃ И отдельно про навык проговаривания будущего решения на собеседованиях. Не меньше чем на само умение решать задачи собеседующие смотрят на умение снять требования, предусмотреть корнер-кейсы, согласовать решение и его имплементировать, итеративно сверяя направление с «заказчиком».


Слушать в iTunes и Overcast
Ещё ссылки в канале подкаста

🥸 короткий и дельный совет от Игоря Мосягина — добавлять эмоджи в отладочные логи, чтобы было заметнее

это из доклада на конференции SmartData — там сегодня community day, можно посмотреть доклады бесплатно 👀

Каюты с муми-троллями

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

По факту оказалось, что у кают и расположение похуже, и общее состояние можно описать как «пошарпанное». У нас, как клиентов, опыт использования обычной каюты оказался лучше, чем «особенной» — кажется, это не тот результат, на который рассчитывали.

Пока плыли, пришёл к тому что фичу с тематической каютой неправильно зарелизили в прод!

Допустим, на корабле обычных кают такого класса 1000, из них 10 с муми-троллями. При этом заполняемость парома не 100% (в непиковые дни по ощущениям ниже 50%), то есть «обычные» каюты вполне можно ротировать: заселять пассажиров в разные каюты при каждом рейсе.

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

Это как «горячая нода» в распределённых системах, когда данные между узлами распределены неравномерно и общая эффективность системы снижается.

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

А если идеологически нельзя наживаться на национальном достоянии, то впилить туда телик побольше и набор мультиков (тех самых!) — и чарджить экстра уже за технику, а не за мумиков.

Есть ли смысл переезжать?
— Senior Software Vlogger

Посмотрел ёмкий ролик про релокацию айтишника в другую страну. Записал себе такие пункты:
• Для переезда нужно большая сумма: 5-10К $
• Снять жилье — как неместного попросят предоплату за 1-3 месяца
• Экономить не получится — местные-то знают где что и как, а вы — пока нет
• Две средних зарплаты — больше чем одна синьорская. Сколько членов вашей семьи будет работать? Если на текущем месте работают двое, а будет только один — это точно будет даунгрейд
• Внимательно выбирать страну по набору критериев (учитывая их динамичность)


https://www.youtube.com/watch?v=Xh5kzxvONtw

Это был «нулевой» урок из курса «Вы приняты», который Дима делает совместно с Фёдором Брощёвым и Марьяной Онысько (под видео в первом комменте есть промокод)

Английский в вакууме не котируется

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

Поработав какое-то время, понял, что за всё время никто меня так и не попросил поговорить по английски или прочитать что-то. Так это не работает.

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

То есть я думал, что связь прямая:
английский → больше зарплата

А на самом деле она косвенная:
английский → изучаешь новое в первоисточниках → применяешь на практике → прокачиваешь навыки → больше зарплата

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

подкаст Data Heroes о релокейте и переезде в другую страну

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

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

Уехавшие сталкиваются со сложностями во всём:
⁃ найти жильё по приемлемой цене
⁃ перевести рубли в местные деньги
⁃ привыкнуть к другому уровеню жизни и сервиса

Цены на жильё подскочили из-за возвросшего спроса (где-то звучат оценки типа в 3-5 раз).

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

Жителям Москвы тяжело привыкать к тому, что нельзя заказать продукты с доставкой за 15 минут или ждать такси больше трёх минут.

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

ссылки на подкаст-платформы в канале Left Join:
https://t.me/leftjoin/617
https://t.me/leftjoin/662

#послушано

Данные как продукт

На прошлом Матемаркетинге был доклад типа «как научить всех SQL», чтобы разгрузить дата-инженеров от выгрузок а-ля select * from table в эксель.

Представьте ситуацию, когда все вокруг действительно знают SQL (и иногда даже лучше инженеров).

Добавьте к этому SQL-диалект, где можно задавать переменные и писать кастомные функции.

Плюс общедоступные запускаторы кастомных скриптов с низким порогов входа (всё настраивается через кубики в веб-админке).

И мы получаем глобальную песочницу, где стопицот аналитиков и менеджеров создали over 9000 выгрузок, таблиц и витрин, где потом сами считают нужные показатели с нужными разрезами к нужному часу.

Мы тут это называем «теневым» DWH.

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

И теперь данные превращаются в продукт, пользователи — в клиентов, а команда DWH становится продакт-менеджерами посередине: нужно общаться с людьми, собирать требования, расставлять приоритеты в работе и «продавать» объекты в контуре DWH, приводя как аргументы их преимущества по сравнению с наколеночными сущностями. Заодно выясняя есть ли такие и нужно ли отдельно DWH в принципе =)

Про отношения с источниками

Работа с источниками — это не только написать пайплайн, который забирает данные.

Иногда перед экстрактом надо доработать схему данных на источнике: например, добавить created_ts/updated_ts или проставлять флаг удаления вместо бесследного уничтожения строки.

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

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

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


спасибо Семёну Осипову за поднятую тему дата-контрактов
https://t.me/ohmydataengineer/245

Послушать:


Про сложность работы с медицинскими данными

Сложность начинается с самого начала: тяжело даже начать, придумать архитектуру и определить основные сущности. Например, «запись к врачу», это ещё не сам «визит».

Каждая информационная система пытается разработать свою схему для передачи данных ( шутка про «Было 14 стандартов…»).

Масштаб: 10 толковых программистов могут поддерживать работу ит-системы крупной больницы.

Интересно, что небольшие страны проще цифровизировать — там просто меньше элементов в системе. В таких странах гораздо проще достичь 100% цифровизации всей системы здравоохранения (в т.ч. задать стандарт).

Слушать в iTunes и Overcast

Тг-канал подкаста https://t.me/ctodaily/1564


⌘⌘⌘


Про ML Art

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

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

Слушать в iTunes и Overcast

Канал Алексея — @pathetic_low_freq


→ разметил посты про подкасты тэгом #подкаст (добавил #послушано)

↑ год назад кидал ссылку на описание урвоней аналитиков в Яндексе

сейчас наткнулся на похожий материал про разработчиков в Авито, аккуратно оформленный в Гитхабе
https://github.com/avito-tech/playbook/blob/master/developer-profile.md

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

вот все:
- Экспертность.
- Инженерная культура.
- Ответственность за результат.
- Ориентация на бизнес.
- Agile Mindset.
- Коммуникация.
- Развитие себя и обучение других.

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

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

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

- 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

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 часов по крону).

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

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

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

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

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

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

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

Самое вкусное это конечно 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 открытых вакансий.”

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