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 в дополнение есть криптобонус и опционы, которых мы даем даже чуть больше ФБ в абсолютах и это при текущей оценке! Можно податься здесь

чувствую себя тупым

Почему? Вижу два фактора:
1. В Яндексе в принципе всё непросто: как в силу технологичности, так и из-за большого размера.
2. Почти все инструменты — внутренние, то есть нельзя просто загуглить ошибку из логов.

Раньше же было как: вот есть, например, Airflow и Docker. В интернете уже все проблемы давно порешали и на всё есть детальные инструкции (в основном на английском, правда).

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

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

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

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

Вроде у стартапов есть такой подход — fail fast. Надо быстро-быстро пробовать новое и искать работающие варианты: пускай на один работающий будет девять неудач, но чем быстрее эти девять случатся, тем быстрее найдём тот один работающий вариант.

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

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

машинное обучение: финальное решение состоит настолько же из кода, сколько из данных

Андрей Татаринов — ко-фаундер Epoch8 и Agima.ai — пришёл в гости к Moscow Python рассказать чем отличается «хайповый МЛ из рекламы» и реальные задачи.

За время работы в Epoch8 я больше всего любил встречи, где участвовал Андрей. У него всегда было чёткое видение проблем и точные формулировки для любых тезисов: одно удовольствие слушать (и потом делать, хе-хе)

⌘⌘⌘

В отличие от конкурсов на Kaggle, в реальном мире задача сформулирована крайне куце: найти все склады на спутниковой карте Москвы. А все данные — это два скриншота таких складов.

Чаще всего данные нужно откуда-то достать, а потом ещё и разметить. Разметка — дорогая процедура; например, чтобы опознать и разметить 2000 деталей на ОДНОЙ фотографии с рассыпанным Лего, может уйти неделя чистого времени одного специалиста.

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

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

Подкаст в Apple Podcasts и Overcast

#подкаст

🤓 Прошёл курс «Python-разработчик» от Практикума

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

Где-то год я каждый день писал код на питоне, но не считал себя настоящим программистом. Старался чаще к ним «подглядывать через плечо», чтобы узнать тайные знания их гильдии. В итоге решил закрыть гештальт и записался на курс Практикума по бэкенд-разработке.

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

⌘⌘⌘

Сам курс делится на три неравные части:
⁃ 6 месяцев по Джанго;
⁃ 2 месяца алгоритмы;
⁃ 1 месяц по инфраструктуре и деплою.

В конце три недели на диплом — полноценный бэк для сайта с рецептами (фронт давали готовый).

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

Наконец-то разобрался с классами: сразу после этого на работе породил первый собственный класс — коннектор с BigQuery. Потом сразу написал такой же для GoogleAnalytics. И потом ещё третий — отнаследовал от первых двух и получил етл-класс по экстракту из GA и заливке данных в BQ (идемпотентной, естественно).

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

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

В Джанге же несколько независимых модулей, которые должны друг с другом работать. В итоге пишешь-пишешь, а оно не работает! И непонятно, какой из модулей виноват — просто в общего грендайзера они собираться отказываются. И сиди разбирайся, переписывай всё с нуля =/

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

⌘⌘⌘

Хотя я слежу за успехами Практикума и благодарен им за пройденный опыт, в целом, у меня как-то мало поводов писать про них, а сейчас получилось сразу два: рассказать про прохождение курса по разработке ↑ и про повышение цен с 1 марта ↓

Практикум поднимает цены на часть курсов, в т.ч. и на анализ данных (70 → 84К), и на пайтон-разработчика (90 → 126К). Если давно хотели, то сейчас самое время.

Для тех, кто прошёл бесплатную вводную часть, у меня есть промокод на 7% скидки — @sashamikhailov

Туда же можно направлять вопросы про Практикум и обучение там — всегда рад поболтать про них ^_^

😱 ААА! Код-ревью

Прошёл тут эпичный код-ревью: 20 комментов в самом пулл-реквесте и ещё 43 сообщения в соответствующем треде в Слаке. Было жёстко, но интересно!

Всё началось как приключение на 20 минут: поправить в двух сущностях поля партиционирования и добавить ключей. А потом оказалось, что их в принципе неправильно спроектировали при создании и мои изменения порождают Х2 дублей в продовых таблицах.

Если раньше было достаточно просто скопировать код загрузчика у соседней сущности, запустить, проверить и сдать, то в этот раз ревьюер спросил меня за каждую строку:
⁃ а почему здесь ключи такие, а там другие?
⁃ а почему здесь период партиционирования такой?
⁃ а зачем вообще эта историзированная сущность, если там строки не меняются?

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

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

🎉 Новый курс «Инженер данных» на Яндекс Практикуме

Ура! Дождались) Выкатили курс по нашей специализации.

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

программа

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

Нравится, что программа начинается не с ETL-скриптов, а с моделей данных: как забрать с источника и как положить к себе в DWH. Вижу отдельные спринты по проектированию слоёв в хранилище и мониторингу за качеством данных (<3)

И потом весь топовых текущих технологий (место для шутки про Modern Data Stack):
⁃ Airflow, кажется это сейчас стандарт на рынке;
⁃ PostgreSQL, ClickHouse, MongoDB — основные типы баз данных;
⁃ ещё ElasticSearch, LogStash и Kibana для многообразия вариантов хранения данных;
⁃ Hadoop и Spark для распределенных хранения и вычисления;
⁃ Celery и Kafka для real-time стриминга данных (потоковой обработки);
⁃ В конце чуток про GCP и AWS; и много про Яндекс Облако (видимо, первые два для ознакомления, но деплоить надо будет на «своём» облаке)

И через 6.5 месяцев обучения должен получиться такой многорукий инженер-данных-всё-могу =)

Я пока прохожу бесплатный вводный спринт ради любопытства, там предлагают собрать базовый инженерский сетап из Airflow и Metabase на Докере — кажется закончу ближе к выходным. Если справитесь быстрее, напомню, что у меня есть промокод на 7% — @sashamikhailov

Стоит 95 000 ₽, первый запуск 21 марта
https://practicum.yandex.ru/data-engineer/