Антон С. Java разработчик, Lead
ID 20245
АС
Антон С.
Мужчина, 33 года
Армения, Ереван, UTC+4
Ставка
4 495,67 Р/час
вкл. НДС 5% (166.67 Р)
Специалист доступен с 30 июня 2025 г.
Добавьте подходящих специалистов в список и оформите заявку для предварительного бронирования времени специалистов. После оформления заявки ваш персональный менеджер организует прохождение всех необходимых проверок с вами и каждым кандидатом из заявки. Специалист привлекается к проекту только после окончательного подтверждения его выхода с вашей стороны.
Подробнее
О специалисте
Специализация
Java разработчик
Грейд
Навыки
Отрасли
Знание языков
Английский — B1
Проекты
(10 лет)
Прослеживаемость производства слябов
Роль
Backend разработчик
Обязанности
Краткое описание проекта:
Глобальная задача проекта - предоставить аналитикам данные (табличные отчеты, графики) о производстве слябов из двух систем-источников.
Данные передаются через kafka и проходят через несколько промежуточных точек сохранения и контроля (spring-сервисы с postgresql, nifi, airflow, postgresql БД-накопители вне сервисов).
В конечном итоге данные попадают в clickhouse и извлекаются оттуда по запросу пользователей в различных форматах (табличные отчеты UI + xlsx, графики UI + png) в spring-сервисе с GraphQL API и REST API.
Роль в проекте и выполняемые задачи:
1) Разработка (в рамках уже развернутых сервисов и решений) нового функционала, обеспечивающего передачу потока данных на всей цепочке от систем-источников до конечной БД clickhouse*
2) Анализ и проектирование различных аспектов реализации функционала на уровне сервисов (архитектура классов и модулей, структура новых таблиц БД, REST/GraphQL API, JSON-схемы, конкретные решения по реализации)
3) Рефакторинг легаси кода.
4) Описание значимых деталей реализации в confluence.
5) Ревью кода внутри команды.
6) Взаимодействие с соседними командами и отдельными специалистами, в основном по вопросам интеграций.
Достижения
1)* - Прием и агрегация данных от kafka в NIFI (json+avro, 6 парных топиков (всего 12 потоков)), JOLT трансформации - срез нужных полей, выкидывание не нужных, преобразование в структуру принимающего сервиса, передача в REST API сервиса-агрегатора первичных данных. Разработан NIFI-flow (группа процессоров обработки) для приема и передачи на вход в REST API, само API.
- Валидация (JSR 303 + соответствие postgresql справочникам) и UPSERT в сервисе-агрегаторе первичных данных (postgresql, около 12 таблиц для бизнес данных и технических нужд, примерно столько же справочников). Разработан код описанной валидации и сохранения.
- Передача данных дальше в kafka с преобразованием в промежуточный формат (json+avro) в 4 топиках. Разделение на топики продиктовано необходимостью соблюдать ограничение на размер передаваемых сообщений на каждом топике. Разработаны новые avro, конвертеры в avro-DTO всех необходимых сущностей.
- Прием данных от kafka в NIFI, сохранение в промежуточную postgresql БД (не прикрепленную к сервису). Разработаны NIFI-flow для приема и передачи в БД, структура 4 таблиц для сохранения.
- Обработка данных из промежуточной БД postgresql по расписанию через airflow (SQL агрегация данных обратно в единый JSON с учетом возможности неравномерного поступления данных из kafka, передача данных в приемочную таблицу сырых данных в clickhouse). Были реализованы с нуля несколько airflow DAG-ов (airflow-граф с группой задач) на python скриптах c основным функционалом обработки и всеми SQL запросами и побочным функционалом (transactional-outbox, обработка и нотификация об ошибках, запрос свежих данных по определенному условию через REST-API от предыдущего сервиса-агрегатора напрямую). Предъявлялись требования к повышенной нагрузке именно на этот узел, т.к. в эту же промежуточную БД сливаются потоки и от других команд, которые также обрабатываются теми же DAG-ми.
- Парсинг JSON из приемочной таблицы clickhouse в конечную таблицу (витрину) посредством clickhouse materialized view (вьюха берет данные от приемочной таблицы с преобразованием структуры JSON и тут же маппит данные на колонки витрины). Реализованы вьюха и витрина.
- Реализация GraphQL API получения данных из витрины для пользователя (комплексный сбор данных из витрины clickhouse и postgresql) - табличный отчет в json с постраничностью и динамичными фильтрами, REST API скачивания того же отчета в xlsx (уже без постраничности).
Из интересного, мною был спроектирован, согласован с solution-архитектором и далее реализован функционал:
- Функционал отслеживания времени прихода данных из разных топиков одной и той же бизнес сущности (postgresql лог времени обновлений с разбивкой по топикам) и алгоритм разрешения/запрета обновления/очистки различных полей сущности в зависимости от факта наличия одних и тех же полей в разных топиках (перекрытия полей) и времени доставки рассматриваемого сообщения по сравнению с логом. В рез-те была исключена возможность потери части данных или их затирание старыми значениями из-за разной скорости прихода данных от разных топиков. Мы были первые, кому пришлось обрабатывать данные сущности из нескольких параллельных топиков с наличием перекрытий по полям. Решением потенциально могут воспользоваться и другие команды в контексте других потоков данных.
- Функционал асинхронной обработки и последующей отправки вниз по течению данных в сервисе-агрегаторе первичных данных (взамен легаси - синхронного решения). В рез-те была решена проблема lost update в контексте обработки данных от одной и той же сущности, данные о которой приходят параллельно из нескольких топиков. В ходе проработки анализировались плюсы-минусы-трудности вариантов перехода на repeatable read, на оптимистичные блокировки, на event sourcing, но в итоге остановились на буфере-накопителе в postgresql, который накапливает сырые данные от kafka и затем по расписанию обрабатывает по паттерну transactional-inbox, в конце работы формируя задания в похожий буфер заданий на отправку в kafka вниз по течению (который также обрабатывается асинхронно по принципу transactional-outbox по расписанию). Также в обоих буферах реализована система обработки ошибок и нотификации о них (решение на базе kafka+NIFI). Решением потенциально могут воспользоваться и другие команды в контексте других потоков данных.
- Очень похожие проблемы и способы решения были использованы и при обработке данных в airflow, только уже в python скриптах и c другой структурой таблиц postgresql - тот же transactional-outbox только теперь с агрегацией данных из 4-х таблиц + анализ перекрывающихся полей.
Стек специалиста на проекте
PostgreSQL, Docker, GraphQL, REST API, Spring Boot, Avro, ClickHouse, Kafka, NiFi
Отрасль проекта
Manufacturing
Период работы
Январь 2023 - Декабрь 2024
(2 года)
Сопровождение и развитие системы audatex для немецкого и швейцарского региона
Роль
Fullstack разработчик
Обязанности
Краткое описание проекта:
Аudatex - комплексная система для автобизнеса, предоставляющая такие функциональности как:
- инструменты для точного определения стоимости восстановительного ремонта транспортных средств
- автоматизация процессов, связанных с урегулированием убытков в автостраховании
- предоставление клиентам единого информационного пространства для любых согласований в рамках единых стандартов
- оценка и реализация годных остатков транспортных средств
- оценка стоимости технического обслуживания и слесарного ремонта транспортных средств
- интернет-решения для профессионалов рынка автомобилей с пробегом
Обязанности:
- Разработка нового функционала и поддержка старого
- Code-review
- Системная аналитика
Примеры выполненных задач:
- Интеграция с системой для поиска информации при расчете стоимости ремонта автомобиля, в том числе реализация UI в системе audatex для аутентификации пользователя repair-pedia
- Генерация pdf счета оплаты для швейцарских банков с QR кодом согласно спецификации (реализовано в виде отдельного нового микросервиса)
- Интеграции с различными отдельными внутренними сервисами audatex через REST / SOAP API
- Изменение конфигурационных настроек управляющих различными бизнес-процессами в системе audatex
- Исправление дефектов на бекенде и фронтенде
Стек специалиста на проекте
Docker, JavaScript, JUnit, Mockito, Spring Boot, Jackson, Redux, Java 8, React, Less.js
Отрасль проекта
Logistics & Transport
Период работы
Апрель 2022 - Декабрь 2022
(9 месяцев)
Система лидогенерации потенциальных клиентов крупнейшего банка России
Роль
Tech Lead
Обязанности
Краткое описание проекта:
Система предназначена для регистрации потенциальных агентов, управления данными агентов и их сотрудников, электронный документооборот (ЭДО), а также единая точка входа для агентов и партнеров
Обязанности / Задачи на проекте:
- Проектирование архитектуры в рамках подотчетного блока микросервисов,
- Проектирование архитектуры внутри отдельных микросервисов,
- Проектирование архитектуры БД,
- Реализация функционала (написание кода),
- Настройка системы безопасности
- Настройка взаимодействия с внешними системами, в том числе при помощи брокеров сообщений
- Анализ баг-репортов, ревью кода
- Первичный системный анализ, написание документации
- Согласование всех финальных артефактов команды (сборок, сопроводительной документации, макетов, тест-кейсов)
- Согласование функционала и интеграций с окружающими командами
- Определение и согласование сроков выполнения этапов проекта на разных масштабах планирования (от отдельных спринтов до roadmap)
- Обеспечение процесса доставки приложения до рабочих контуров
- Определение и внедрение общего процесса бекенд разработки
Стек специалиста на проекте
JUnit, Mockito, Spring Boot, Jackson, JPA, Hibernate, Kafka, Spring Data, Java 11, OpenAPI
Отрасль проекта
FinTech & Banking
Период работы
Ноябрь 2020 - Апрель 2022
(1 год 6 месяцев)
Формат работы
Тип занятости
Фулл-тайм
Формат работы
Удаленно
Командировки
Не готов
Релокация
Не готов
Готов работать на зарубежных проектах
Да
Образование
Высшее
Учебное заведение
Тольяттинский государственный университет
Специальность
Прикладная математика и информатика
Завершение учебы
2015 г.
