День из жизни Senior Data engineer. 4 года опыта в мире data на разных позициях, $4500 на руки.

Идёт 2 неделя испытательного срока в компании видеоигрового издателя, отдел DWH и BI. В качестве онбординга только исходный код и часовое видео с описанием сервиса на Python для парсинга данных от клиентов, который торжественно вручили мне на поддержку и развитие. Клиентами у нас выступают игровые студии-партнёры, для которых наш отдел разрабатывает аналитические сервисы.

Сегодня утром произошёл инцидент - стало известно, что несколько дней назад сервис парсинга данных и раскладывания по директориям в HDFS не отработал, и в табличках Impala у клиента данные не отобразились. Уже начал истекать TTL у данных в Kafka, клиент нервничает, т.к. за эти аналитические данные заплатили, и если они пропадут, убыток будет сложно компенсировать.
Цепочка парсинга сложная, доступы есть не ко всем хостам, сервисам и чатикам алёртинга, так что вооружаюсь звонками с коллегами, которые хоть что-то слышали о сервисе, поиском по confluence, командной строкой, исходниками сервиса, и иду разбираться.

Вначале пробую раскрутить цепочку с конца, написав SHOW CREATE TABLE в Impala для view на основе таблиц в схеме A, в которых клиент ожидал увидеть данные. Определил местоположение parquet'ов в HDFS, проверил - данных в партициях за нужные даты нет, хотя Airflow за эти даты отработал. Полез в директорию с "сырыми" данными - там лежат сотни файлов без привязки к клиентам, т.к. client_id определяется только после парсинга, - быстро не определить, есть ли там нужные файлы. На всякий случай проверил директорию garbage с отброшенными файлами, которую определил по видеогайду, - там пусто. Узнал у клиента, через какие API-методы и в какие endpoint'ы они отправляли данные - эндпоинты жёстко связаны с топиками в кафке, должно помочь при расследовании. Закопался в код сервиса, нашёл описание разбирающего Kafka воркера, но не смог понять по коду и логам, на каком этапе что-то пошло не так.

В итоге решил, что сам быстро не разберусь, а время поджимает. У лида получил контакт бывшего разработчика, который с этим сервисом плотно работал, и связался с ним. Написал ему в тг сообщение с коротким запросом и перечислением всех сделанных шагов, чтобы сэкономить ему время на анализ. Он предложил проверить таблицы в схеме B вместо схемы А и коротко описал связь между тем, в какие топики кафки пишут клиенты, и тем, в какие таблицы в результате данные попадают. Также рассказал о том, чем различаются старая и новая версия сервиса и как с этим связаны разные топики.
Проверил эту таблицу в схеме B - какие-то данные есть. Прислал клиенту, попросил просмотреть, позапускать ad-hoc запросы для анализа. Оказалось, что клиент использовал промежуточный сервис для интеграции с нами, а в этом сервисе случайно использовали старый эндпоинт. Данные как-то разобрались, но попали не в ту таблицу, в которой ожидал увидеть клиент.

Пока запросы для проверки сохранности данных отрабатывали, вернулся к Kafka. Вместе с короткими советами от бывшего разработчика, ChatGPT и --help в консоли, удалось составить команду-consumer для kafkacat. Для отладки использовал echo и awk, соединённые через pipe |, - пригодились базовые знания Linux.
В этом консьюмере я итеративно прошёлся через Bash цикл по всем десяти партициям топика для определения offset'ов, считал сообщения от них и до конца топиков, отфильтровал сообщения через awk по timestamp и клиенту и сделал dump в текстовые файлы на мастер-ноду. Данные спасены, теперь можно их проанализировать и вручную подложить парсеру, даже если из кафки они удалятся.

Собрался пойти спокойно пить чай, но тут клиент пишет, хотя они переключили эндпоинт со своей стороны, и данные в нужную таблицу полились, это ещё не всё. Для аналитики нужно мигрировать данные за последние несколько дней из таблиц схемы B в таблицы схемы A. Этим и займусь завтра, так как рабочий день подошёл к концу. Под завершение дня коротко описываю в confluence результаты сегодняшнего анализа, делаю пометку о статусе задачи в jira и закрываю ноутбук.

Присылай историю | Голосуй за канал