Data engineer\ETL developer (Москва ) Lead

Должность: Data Engineer

Уровень:senior/middle

Формат работы: офисный: МСК (Кутузовский, 32 / Поклонная, 3к1), СПБ (Уральская, 1А)

Занятость: Полная

Заработная плата: 330 000

Компания: Сбербанк

Работодатель: ООО "Глобус-ИТ"

Проект: ЕПКАП Единое приложение корпоративной аналитической платформы

Прикладная аналитическая платформа Сбер B2C — это решение, позволяющее создавать аналитические витрины на Облаке Данных по различным направлениям бизнеса.

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

Мы начинаем трансформацию внутреннего хранилища B2C, что по сути является его разработкой «с нуля». Сейчас мы в поиске Владельца системы (внутреннее хранилище B2C).

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

Требования:

• Уверенное владение фреймворком Spark и опыт разработки приложений на Spark от 2х лет

• Знание и опыт программирования на Scala/Java, готовы рассмотреть Python

• Знание основных компонент инфраструктуры Hadoop, понимание принципов их работы (HDFS, YARN, Spark, Oozie)
  Опыт работы со стриминговым ETL: Flink/Kafka

Будет плюсом:

• Знание конвейеров и инструментов CI/CD (например, Jenkins, Git, Docker) для автоматизации процессов сборки, тестирования и развертывания программного обеспечения

• Понимание SQL и NoSQL баз данных

От нас:

● Трудоустройство по ТК РФ (обсуждаемо);

● Работа в аккредитованной ИТ компании;

● Адаптивные бизнес-процессы внутри компании;

● Достаточная степень независимости в принятии решений;

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

● Расширенный ДМС;

● Скидки на обучение английскому языку;

● Комфортабельное рабочее место, необходимое оборудование.

Дополнительная информация:

Мы b2c, сейчас реализуем большой проект. По сути что мы делаем: мы создаём единое хранилище детальных данных как всего b2c (по 25 предметным областям). Назовём это базовый изолированный слой. И решаем задачи по миграции всех потребителей b2c на эти данные. Если мы говорим про задачи конкретно Глобуса, то в основном это задачи именно по миграции текущего функционала, созданного b2c, который там раньше как-то был реализован (на репликах, на ещё каких-то данных и так далее) на Единый базовый слой. Это концептуально основная задача.

Хранилище очень большое, наверное одно из самых крупных в Европе.

Тех. стек у нас в основном: хранилище на Hadoop, горячий слой в потенциале будет в том числе и на Greenplum.

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

Объём Витрин к миграции очень большой, объём данных тоже очень большой.

Стек Хранилища сейчас в моменте: Hadoop, возможно в потенциале горячий слой мы сделаем на Greenplum, но сейчас в моменте это Hadoop, Spark, Scala, SQL

Конечно в основном большой объём задач можно закрыть с помощью SQL, потому что у нас есть определённые фреймворки, которые позволяют это сделать. Это точно чёткое понимание как работает и как строить, двигать процессы на Scala/Spark в Hadoop. Это однозначно должно быть, потому что без этого работать очень сложно. Хотя бы у лида эта история должна быть.

Если мы говорим про обычных разработчиков, про аналитиков, то в какой-то ближайшей перспективе для аналитика достаточно SQL понятный, т.е. чтобы человек прям чётко понимал, как устроены Хранилища. Лид аналитиков должен понимать как выстраивается архитектура Хранилища, как выстраиваются какие-то логические, физические модели данных и т.д.

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

Задачи для DE: задача по миграции в целом сведётся к выполнению 2-мя компетенциями. 1ое - это аналитик, который в принципе разбирается в алгоритмах, которые реализованы на текущий момент. После реализации этих алгоритмов DE, он соответственно должен

Аналитик готовит прототипы какие-то, т.е. из того, что есть сейчас готовит прототипы на необходимых инструментах и в необходимом качестве или необходимой логической структуре. Отдаёт это DE, DE реализует. Реализует либо на чистом SQL с использованием фреймворка, либо с использованием Scala/Spark, оптимизирует эту историю и выкатывается всё в предпрод состояние, на котором аналитику необходимо будет выполнить реконсиляцию. Т.е. по сути приниматься задача миграции будет каким образом: есть витрина сейчас, в моменте, она выдаёт определённый результат. В параллель реализуется целевая витрина по алгоритму, который мы по сути дублируем. На целевом инструменте с целевой архитектурной логикой.

Далее у нас на выходе есть по сути 2 витрины, между которыми необходимо провести реконсиляцию. В случае проведения реконсиляции и объяснения всех расхождения, задача считается принятой/сделанной. В случае, если у нас данные не бьются, нам необходимо либо это объяснить, либо это чинить.

Для аналитика предпочтительнее SQL

Для лида DE: Scala/Spark, SQL

Для обычного DE и обычного аналитика: понимать SQL, с реляционными данными данных или просто с Hadoop и какой-то опыт возможно со Spark, возможно не на Scala, а на Python, PySpark, Java. Это тоже релевантная история

Используется spark api, он у нас не супер большой, не супер сложный, всегда можно адаптироваться, развиваться.