Как Т1.Техногильдии помогли моей команде решить технический кейс

Надеюсь, что количество опечаток будет минимальным, а статья будет полезной и интересной. Если, что это будет на совести DevRela (менеджера развитию сообществ). 😊
Коллеги, братья по IT-цеху и техногильдийцы, меня зовут Владимир Ловцов, я IT-лидер и автор проекта по Техногильдиям Группы «Иннотех» (Холдинг Т1) и хочу поделиться с вами как техногильдии (внутренние сообщества) помогли нам в решении сложных технических кейсов, когда требуется глубокая экспертиза определенных инструментов и технологий. На тот момент инженеру данных казалось, что мы в тупике, дата релиза близка и уже чувствовалось недовольство...

Ну что же, хватит красивых слов, пора нам с тобой познакомитьcя, уважаемый читатель этой статьи.

Моя команда разрабатывает сложные решения и сервисы в BigData для бизнеса с профильным направлением графового анализа и геоанализа данных, также мы предлагаем и ML-сервисы (Machine learning): один из которых для разметки аудио, текста и изображений (назовем его «Маркер»), а другие за NER-направление (Named Entity Recognition, это направление технологии обработки человеческого языка, программная реализация которой позволяет находить в речи и тексте определённые категории слов и словосочетаний). Соответственно моя команда специалистов могут решить любой кейс бизнеса, соответствующий нашему направлению: от выявления бизнес-потребностей до конечной реализации в виде сервиса в любом удобном для бизнеса представлении. Ну что же, представление, как ритуал знакомства, на данной ноте, я думаю, можно считать завершенным, надеюсь ты не против, и мы можем двигаться дальше, а если тебе хочется познакомиться с нами поближе, оставляй комментарии внизу статьи, будет интересно узнать твое мнение и, если поделишься опытом.

Теперь поговорим о кейсе, который совсем недавно приключился с одним из членов моей команды. Для бизнеса мы разрабатываем сервис пакетного геокодирования данных (не буду погружаться особо в нюансы и детали реализации, но поверхностно напишу про их), который позволяет производить нормализацию «грязных» адресов с приведением их к каноническому виду (собственный формат, формат Яндекса или других сервисов), определению геокоординат, записи дополнительных метаданных, аналитик по выбору заказчика.

Архитектурно наше решение реализовано следующим образом: входным триггером для нас является появление в таблице статусов (витрина Hadoop) записи о том, что данные появились в нужной нам витрине - источнике определенной схемы, после чего срабатывает сенсор оркестратора - Airflow - и запускается каскад нужных DAG-ов. Далее один из DAG-ов запускает процесс трансформации записей витрины Hadoop в сообщении брокера Kafka в определённый топик с помощью Spark, отвечающего за «грязные» данные, на другой стороне Kafka стоит приёмник, который прослушивает топик и начинает процесс геокодирования адресов каждого сообщения, также через Spark, после чего укладывает в другой топик брокера Kafka.

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

Присмотревшись на архитектуру, концептуально, кажется проблем быть не должно нигде, если вы уже не первый год работаете с BigData, стек привычный и даже классический: нет новых инструментов в данной реализации, но дьявол зарыт всегда в нюансах конкретной реализации, в деталях... А как мы сообщения парсим? Spark. А нет ли проблем и тонкостей тут?

Оказалось, есть, мой DE пытался запустить парсинг таблицы и укладку в Kafka в новой среде, но все безуспешно, хотя в данном варианте сборки не ожидалось никаких проблем. После того, как инженер решал данную проблему несколько дней и все безуспешно, мне пришло понимание, что следующие итерации лишь потратят в разы больше времени, и не принесут ожидаемого результата, поэтому я настоятельно порекомендовал обратиться к команде экспертов в нашей компании, которые объединены под общим концептом - Т1.Техногильдии – это наше внутреннее сообщество (комьюнити) специалистов и профессионалов, которые поддерживают технологии, инструменты, продукты и решения ключевого стека компании, и как оказалось не зря!

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

И так, вот что предложили коллеги из нашего комьюнити Т1.Техногильдии:

Небольшой совет при работе со Spark: если запускается локальный Spark или Spark-shell, нужно указать полный путь до файлов, если Spark-submit, то в качестве пути нужно указать только имя файла и расширение.

Эксперт потратил лишь пару часов, отработав пошагово все возможные варианты проблем и достаточно быстро нашёл решение. Соответственно, если ты разработчик, то не бойся спрашивать, проблемы не всегда тривиальны, решив её самостоятельно ты получишь конечно больший опыт, но времени не всегда много. Если ты тимлид или IT-лид, то знай, что в твоих руках есть крутая команда экспертов (а если ты не из Холдинга Т1, то задумайтесь о создании сообществ), готовая помочь тебе с любой проблемой в рамках технологий, инструментов и продуктов. Все остались рады, бюджет проекта был сэкономлен, решение реализовано.

В больших IT-компаниях создание сообществ жизненно важно, и если у вас нет внутреннего сообщества, то обязательно стоит про это задуматься. Проект создания сообщества (в нашем случае Техногильдии) полностью оправдан: это не только профессиональная помощь и поддержка, но и возможность делиться новыми IT-трендами, уточнить на какие конференции стоит сходить и даже как написать интересную статью! Как например, эту! 😊