Привет, Хабр! На связи Александр Курносов, руководитель группы платформы данных, и Андрей Двинских, инженер больших данных. Мы работаем в Lenta Tech (ИТ-бренд «Группы Лента») и занимаемся развитием и поддержкой онлайн-сервисов «Ленты».
В ежедневной работе мы используем несколько инструментов. Чтобы разобраться с очередной задачей, приходится переключаться между ними, искать нужную информацию и собирать общую картину буквально по частям.
В какой-то момент мы поняли, что большинство таких действий повторяются каждый день. Поэтому решили собрать самые востребованные сценарии в одном внутреннем инструменте. Так появился ETL log. Сегодня он объединяет в одном интерфейсе самые востребованные сценарии ежедневной работы команды.
В статье расскажем, почему решили его создать, какие задачи он помогает решать и как устроена работа с ним.
Оглавление
С чего начинается работа команды
Прежде чем говорить про сам инструмент, стоит немного рассказать о том, как организована работа инженеров данных в нашей команде. Все задачи можно условно разделить на две большие группы:
Первая — запросы от пользователей внутри дата-офиса. Это могут быть новые выгрузки, доработки существующих процессов, исправление данных, предоставление доступов и другие задачи, которые приходят от аналитиков и внутренних заказчиков.
Вторая группа — задачи, которые команда ставит себе самостоятельно. Помимо выполнения пользовательских запросов, мы постоянно развиваем собственную платформу и поддерживаем существующие процессы.
Как задачи попадают в работу
Есть несколько способов передать задачу команде.
Чаще всего заявки приходят от аналитиков: по электронной почте или через Mattermost.
Используется бот, который автоматически создает тикет в Jira и переносит в него всю историю обсуждения из треда.
Через ETL log, хотя этим способом в основном пользуется сама команда.
Каждое утро проходит стендап, где команда разбирает новые задачи, проверяет инциденты и оценивает текущее состояние процессов. При этом мы смотрим не только на список тикетов.
Не менее важно понимать общее состояние платформы. Если какой-то процесс завершился с ошибкой или возник инцидент, который может повлиять на пользователей, об этом нужно узнать как можно раньше. Бизнес начинает активно работать с отчетами примерно к десяти утра, поэтому наша задача — успеть обнаружить и устранить проблему еще до этого момента.
Помимо ежедневного стендапа, два раза в неделю команда проходит по доске задач, обсуждает сложные случаи и при необходимости пересматривает приоритеты.
Еще одна постоянная точка — пятничный релиз. В конце недели мы подводим итоги, обсуждаем выполненные задачи, разбираем интересные кейсы и смотрим, что вошло в очередной релиз.
Чтобы работать с большим количеством задач было проще, мы группируем их по эпикам:
инфраструктура;
доступы;
оптимизация;
инциденты и другие направления.
В результате весь процесс можно описать достаточно коротко: поступление задачи, определение эпика, работа, релиз и завершение.
Почему появился ETL log
Весь этот рабочий процесс подразумевает постоянную работу сразу с несколькими системами:
для запуска и выполнения процессов используется Airflow;
информация о датасетах и зависимостях хранится в DataHub;
отдельно используются Power BI, базы данных, Jira и различные внутренние сервисы.
О том, как наша команда подходила к выбору системы логирования и какие решения мы принимали по ходу роста инфраструктуры — мы рассказывали в отдельном материале.
Ежедневно инженеру приходится переходить из одного интерфейса в другой, искать нужную информацию и выполнять часть действий вручную. Особенно это заметно при диагностике инцидентов, когда важно быстро понять, что именно произошло.
Именно поэтому мы начали развивать ETL log. Мы не ставили перед собой задачу заменить существующие системы. Airflow остается Airflow, DataHub — DataHub, а Power BI продолжает выполнять свою роль. ETL log работает поверх них и объединяет самые востребованные сценарии повседневной работы в одном интерфейсе.
Что инженер видит сразу после открытия ETL log
Главная страница показывает текущее состояние процессов Airflow. Ее задача — быстро ответить на вопрос: что происходит прямо сейчас?
Основной блок — трансформации, которые завершились с ошибкой и требуют внимания команды. При этом отображаются только те процессы, которые находятся в нашей зоне ответственности. Если DAG отключен и его состояние уже известно, он не отвлекает инженеров и не появляется на главном экране.
Кроме этого отображаются:
процессы, которые выполняются в данный момент;
процессы, ожидающие запуска;
информация о длительных задачах, которые могут сигнализировать о проблемах с очередями или ограничениями пулов.
Такой экран позволяет за несколько секунд понять общую картину и определить, требует ли что-то немедленного вмешательства.
История ошибок: чтобы ничего не потерялось
Когда инцидент устранен, он исчезает с главной страницы. Это удобно: экран не перегружен уже решенными проблемами. Но возникает другой вопрос. Как понять, что происходило несколько часов назад? Или обсудить на стендапе ошибку, которую уже успели исправить?
Для этого в ETL log есть отдельная страница с историей ошибок. Она хранит информацию о сбоях по датам, поэтому команда может вернуться к любому периоду и посмотреть, какие процессы завершились с ошибкой. Это полезно, если один из инженеров уже успел разобраться с инцидентом, а остальные коллеги еще не знают, что произошло.
Во время ежедневного стендапа мы просматриваем эту историю. Если встречаются интересные или нестандартные случаи, обсуждаем их всей командой. Такой подход помогает нам держать процессы под контролем и делиться опытом решения инцидентов.
Еще один полезный раздел — проблемные задачи. Здесь можно увидеть процессы, которые не обязательно завершились ошибкой, но ведут себя подозрительно. Например, слишком долго выполняются или регулярно требуют повторного запуска. Иногда эти ситуации не приводят к падению процесса, но уже сигнализируют, что стоит разобраться, пока проблема не стала критичной.
Работать с зависимостями стало проще
Еще один сценарий, которым инженеры пользуются практически каждый день, — анализ зависимостей. В DataHub эта информация уже есть. Но когда связей становится слишком много, быстро разобраться в них становится не очень удобно. Поэтому в ETL log появился собственный виджет для работы с lineage. Он показывает зависимости между таблицами в табличном виде и позволяет выгружать информацию в Excel.
Источник данных при этом остается прежним — ETL log не хранит собственную копию зависимостей, а лишь представляет уже существующие данные в более удобном формате. Но на этом возможности не заканчиваются. Если необходимо перезагрузить конкретную таблицу, это можно сделать прямо из интерфейса ETL log. Причем есть возможность перезапустить как одну таблицу, так и все зависимые процессы по всему дереву.
Инженер выбирает нужную таблицу, просматривает цепочку зависимостей и при необходимости запускает повторное выполнение связанных процессов.
ETL log и DataHub: тот же источник данных, но другой пользовательский сценарий
При работе с DataHub мы решали две задачи:
1. Первая — контроль новых датасетов. Когда появляется новая таблица, важно назначить ответственного, заполнить описание и поддерживать информацию в актуальном состоянии. ETL log показывает недавно созданные объекты, чтобы команда могла увидеть, какие из них еще не оформлены полностью, и при необходимости напомнить коллегам или создать соответствующую задачу.
2. Вторая задача оказалась еще более практичной. Редактировать описания таблиц непосредственно через интерфейс DataHub удобно, если изменений немного. Но когда приходится обновлять сразу несколько объектов, процесс становится довольно трудоемким: нужно последовательно открывать каждую колонку, вносить изменения и сохранять их по отдельности.
Для этого в ETL log тоже есть отдельный виджет. Он позволяет выгрузить описание таблицы в формате JSON, отредактировать его и отправить обратно в DataHub. При этом сам источник данных не меняется — описание по-прежнему хранится в DataHub. ETL log позволяет массово обновлять описания и сокращает количество ручных действий.
Быстрые проверки PostgreSQL и ClickHouse
Иногда инженеру нужно быстро проверить текущее состояние базы данных. Например, посмотреть активные сессии, обнаружить блокировки или понять, каким таблицам требуется VACUUM.
Конечно, для глубокой диагностики существуют специализированные инструменты администрирования. ETL log не пытается их заменить. Его задача намного проще — предоставить быстрый доступ к самым востребованным проверкам, которые регулярно используются в работе инженеров данных.
Поэтому в сервисе появились небольшие виджеты для поверхностного мониторинга PostgreSQL и ClickHouse. Через них можно посмотреть активные сессии, блокировки, процессы VACUUM и некоторые другие показатели без необходимости каждый раз подключаться к базе и выполнять запросы вручную. Причем этими возможностями пользуются не только инженеры данных, но и аналитики дата-офиса.
Как ETL log помогает работать с Power BI
Еще один блок ETL log посвящен Power BI. Здесь инструмент закрывает сразу несколько задач:
помогает контролировать состояние отчетов;
отслеживает их готовность;
связывает отчеты с процессами Airflow, которые отвечают за их обновление.
В одном окне можно увидеть название отчета, дату последнего изменения, автора изменений, расписание обновлений, время последнего запуска и текущий статус. Вся эта информация сопоставляется с соответствующим DAG в Airflow.
При необходимости инженер может сразу перейти к нему и посмотреть, что произошло, не тратя время на поиск нужного процесса вручную. Когда отчет перестает обновляться вовремя, обычно приходится проверять сразу несколько систем, чтобы понять причину. ETL log позволяет собрать эту информацию в одном месте и быстрее перейти к диагностике.
Небольшие утилиты, которые экономят время каждый день
Со временем вокруг ETL log также появился набор небольших инструментов. Каждый из них решает довольно узкую задачу, но именно из таких мелочей и складывается ежедневная работа инженера.
Контроль готовности процессов
Одна из таких утилит — Process Control. Она позволяет настроить контроль готовности процессов и отчетов. Для объекта можно указать ожидаемое время завершения, ответственного, каналы уведомлений и другие параметры. Если процесс не успел выполниться к назначенному времени, пользователи и команда получают уведомление.
SQL-парсер для генерации DAG
Еще один инструмент помогает автоматизировать создание новых процессов. Во многих случаях витрина данных представляет собой отдельный DAG, который собирается на основе большого SQL-запроса. Обычно подготовка такого DAG требует большого количества однотипных действий.
Чтобы сократить эту работу, в ETL log появился SQL-парсер. Инженер загружает SQL-запрос, после чего инструмент автоматически формирует заготовку DAG: определяет зависимости, добавляет сенсоры, формирует lineage и подготавливает структуру процесса. Остается указать название и описание.
Быстрое создание задач
Через виджет «создание задачи» можно за несколько секунд отправить новую задачу прямо на командную доску. Этой возможностью инженеры пользуются, когда по ходу работы возникает необходимость что-то доработать или исправить позже.
Немного порядка в Jira
Отдельный раздел посвящен работе с Jira. Например, ETL log показывает задачи, которые давно никто не обновлял. Такие карточки легко теряются среди остальных, поэтому инструмент помогает поддерживать доску в актуальном состоянии.
Кроме этого, здесь есть возможность автоматически сформировать описание очередного релиза. Информация собирается по эпикам и выводится в готовом текстовом виде. Также предусмотрена административная панель с ролевой моделью, где в зависимости от прав пользователю доступны разные действия.
Архитектура ETL log
ETL log — полностью внутренний сервис, который команда разрабатывает и поддерживает самостоятельно. В его основе лежит несколько компонентов. Основной из них — веб-приложение, через которое инженеры работают с сервисом.
Кроме него, в архитектуру входят:
Worker — отвечает за выполнение длительных операций;
Scheduler — запускает пользовательские задачи, например Process Control;
Message Consumer — распределяет сообщения между задачами воркера через брокер сообщений.
В качестве собственных хранилищ используются PostgreSQL и Redis. Redis выполняет роль кэша и транспорта сообщений, PostgreSQL используется как основная база данных сервиса. С архитектурной точки зрения ETL log представляет собой распределенный монолит.
Такой подход выбрали сознательно: большая часть кода используется сразу несколькими компонентами, поэтому отдельные сервисы в данном случае оказались менее удобным решением.
Другими историями из практики нашей команды — уже на стыке разработки и DevOps — мы делились в статье: Spark on Kubernetes: наш путь к автоматизации через кастомный оператор Airflow.
Что в итоге получила команда
Изначально ETL log выглядел совсем иначе. Первая версия умела показывать только трансформации, завершившиеся ошибкой. В ней не было ни дополнительных кнопок, ни просмотра логов, ни большинства возможностей, которые появились позже. Постепенно сервис развивался вместе с потребностями команды: добавлялись новые виджеты, автоматизировались повторяющиеся действия, появлялись новые сценарии работы.
Сегодня сервис помогает инженерам быстрее понимать текущее состояние процессов, тратить меньше времени на рутинные операции и быстрее переходить к диагностике возникающих проблем. Именно эти задачи — главный результат развития инструмента.
При этом мы не считаем ETL log завершенным проектом. Он развивается вместе с потребностями инженеров: если возникает задача, которую приходится выполнять снова и снова, появляется повод автоматизировать и ее.
Вместо заключения
Мы не стремились создать еще одну замену Airflow, DataHub или Power BI. Наша цель была — собрать в одном месте те действия, которые инженеры данных выполняют ежедневно.
Постепенно набор отдельных виджетов вырос в полноценный рабочий инструмент, который помогает быстрее ориентироваться в состоянии процессов, работать с зависимостями, поддерживать актуальность метаданных и избавляться от части рутинных операций.
И нам интересно узнать, как похожие задачи решаются в других командах. Используете ли вы собственные внутренние инструменты поверх Airflow, DataHub и других сервисов? Или предпочитаете работать только со штатными возможностями этих систем? Делитесь своим опытом в комментариях!
