Как мы решали технологический кейс с привлечением технологического комьюнити (полная версия)

Введение

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

Знакомство

Ну что же, хватит красивых слов, пора нам с тобой познакомить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.Техногильдии:

Шаг 1

Надо было убедиться, что все сертификаты, пароли правильные и нет межсетевых проблем и блокировок, поэтому настроили соединение с Kafka без привязки к Spark, всё заработало.

Шаг 2

Перепроверили все пароли и на всех контурах (dev, ift и т.п.) - на одном из контуров действительно был некорректный пароль.

Шаг 3

Далее надо было убедиться, что все библиотеки, параметры конфигураций с их версиями дружат, собрал на коленке приложение и проверил, все хорошо.

Шаг 4

Поскольку все пункты выше проверены, остаётся последний вариант - правильно подать в Spark все параметры и файлы. Оказалось, что для Spark в данном исполнении на данной среде и конфигурации нужно указывать префикс «kafka» перед всеми параметрами, кроме топиков, иначе он просто не видит их. После этого соединение прошло и сообщения были отправлены. Ого, успех!

Небольшая ремарка, в принципе тут для старших специалистов нет ничего нового, данный подход важен именно для молодых специалистов до уровня middle и middle+, а также их руководителей, чтобы понимать как действовать в аналогичной ситуации.

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

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