Java ETL Developer

Мы в deeplay решаем задачи игровой индустрии с использованием искусственного интеллекта и big data. Наша продуктовая команда разрабатывает мобильное приложение для международного рынка. Для усиления наших задач мы ищем в команду Java ETL developer.

У нас есть довольно много данных. Не с точки зрения байтового объёма, тут до BigData пока не дотягиваем, в теребайты всё ещё помещаемся. А вот с точки зрения смысловых байтов уже что-то нормальное выходит, RPS в десятки на вечное хранение всё-таки присутствует. Очень хотим, чтобы данные поступали хорошо, поломки быстро чинились, хранилось всё в удобном для потребления виде и всё прочее что обычно хотят от ETL. Для этого наконец-то оградили ETL от всего остального, что делается, и формируем команду.

Обязанности:

• Делать хорошую поставку данных. Тут есть дотягивание существующего кода до приличного состояния; допиливание модных классных фич типа пересесть на стриминг; организация поставки новых вещей, которых никто раньше не трогал;
• Поддержка поставки. Надо реагировать на алёрты, и быстро чинить. Для этого надо писать правильные алёрты, включая дописывание в места, где их не хватает;
• Формирование витрин. Есть кучка разных потребителей, которым нужны данные (BI, аналитики, ML, бухшалтерия, вообще говоря вся компания). Хочется, чтобы им было удобно, причём достигать это не только их руками.

Требования:

• внезапно, опыт разработки на Java;
• знание ООП. Что-то из шаблонов проектирования, паттернов хорошего кода и цитат из книжек по чистому коду;
• знание теории хранения данных. Всякое про CAP теоремы, как жить если хранилище медленное, но нужны данные от 2 минут назад, чем отличается OLAP от LDAP;
• терпимость к legacy коду. Ультимативного "работает — не трожь" нету, но при этом множить на ноль весь накопленный код и писать вообще всё с нуля тоже не будем;
• уметь писать код, который легко поддерживать. Написанное здесь будет жить долго (а в идеале вечно), поэтому скилл про навесить алёрты и юнит-тесты обязателен;
• знаешь, как выглядит хороший рабочий процесс. Не в плане поспорить за Канбан против Скрама, а понимание что заказчик, не получивший ответа про точность поставки, попробует угадать её сам.

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

• готов делать как реально надо, а не как хочется кому-то там;
• знаешь кучу баек с предыдущих мест работы;
• задаешь правильные вопросы, умеешь донести и обосновать свою позицию;
• видел ТЗ длиной в 20 символов (или меньше) и тебя не смущает помогать думать заказчику;
• умеешь в архитектуру. Нарисовать схемку так, что реально написанное через полгода имеет что-то похожее с нарисованным;
• понимаешь диалектичность бытия, умеешь балансировать между «работает» и «красиво»;
• в состоянии прочитать и понять хотя бы общий смысл определенного раздела документации на английском языке;
• просто сокровище, а не кандидат.

Что есть в стеке?

• Clickhouse как основной Data Lake, PostgreSQL как популярный выбор вторичных хранилищ;
• Airflow как главный шедулер;
• Kafka как почти шина данных;
• Java, как ни странно. В частности, очень много хорошего легаси кода;
• Кучка всякого на питоне сбоку, что творит как-то Transform, а иногда и полный ETL;
• Всякий ML, тоже сбоку. Есть простой, есть сложный.

Условия:

• Гибкий график и удаленную работу (команда распределена по всей России, и процессы налажены сквозь часовые пояса);
• Высокую зарплату (готовы идти навстречу сильному кандидату), систему бонусов;
• Оплату обучения внутри и вне компании;
• Отсутствие лишней бюрократии и сложных согласований.