Мы в 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, тоже сбоку. Есть простой, есть сложный. Условия: Гибкий график и удаленную работу (команда распределена по всей России, и процессы налажены сквозь часовые пояса); Высокую зарплату (готовы идти навстречу сильному кандидату), систему бонусов; Оплату обучения внутри и вне компании; Отсутствие лишней бюрократии и сложных согласований.