🤔 2/2, какие ещё задачи решал недавно

🔸 Развернуть новые инстансы легаси-сервиса на python, один на новой инфраструктуре, другой рядом с текущим.

Несмотря на применение технологий контейнеризации и сборку через gitlab CI, много неявных настроек и зависимостей, которые не описаны в документации. Поэтому приходится глубоко закапываться в код и проявлять зависимости, где-то экспериментировать.

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

Много проблем из-за сетевых ограничений -- то добавят прокси, то отберут какие-то доступы к внешним ресурсам, то для развёртывания сервиса нужно "ковырять дырки" (открывать порты) между серверами. On-premise это весело, говорили они.

🔸 Перераспределить пулы в Yarn между пользовательскими и технической учётками.

Аналитики негодуют, что в рабочее время часто не хватает ресурсов для выполнения ad-hoc запросов через Hive к данным в data lake (hadoop). По мониторингу в Cloudera manager выяснил, что память кластера улетает в потолок и из 6-8 ТБ остаётся пара десятков ГБ. Это мало для биг-дата задач. В том же менеджере посмотрел текущие настройки пулов.

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

🔸 Неделя дежурств.

Выдаю доступы пользователям, реагирую на инциденты, отвечаю на вопросы в чатах с командами. Пользуюсь заботливо созданной документацией по инцидентам и доступам, дополняю и уточняю. По мониторингу слежу за текущими загрузками и стабильностью работы сервисов. Заполняю лог с падениями и ошибками, в котором можно понять, насколько часто проблема возвращается, и в связи с этим выставить приоритет. Да, вручную, но падений не так много.

Так как DWH это центральный элемент всей компании, много общения с самыми разными людьми. Если сам не знаю ответ, стараюсь найти максимально релевантный контакт и подключить коллегу к обсуждению. Часто бывают вопросы по определению времени доставки данных, можно ли что-то из загрузок ускорить.

Иногда новые аналитики просят помочь разобраться с сервисом или оптимизировать запросы. Иногда они меняют что-то на своей стороне, не предупреждая нас, и все весело бегают и пытаются определить корень проблемы. По окончании дежурства с большим удовольствием отправляю эти чатики в mute ещё на месяц и передаю дела следующему "on duty".

🔸 Документирование текущего состояния.

Подготавливаем хранилище к перевозке в другую страну -- проводим ревизию и отсекаем лишнее. Так как data catalog пока ещё не внедрён, всё через поиск по ключевым словам в репозиториях и изъятие ценной информации из светлых голов.

Data lineage вручную это нудно, но помогает быстро познакомиться с уголками системы, куда ещё не заводили таски. Здесь "workflow as a code" подход Airflow и спасает, и портит жизнь, т.к. всё хранится в гите, но гибкость решений ограничивается только кодстайлом и фантазией разработчика.

---

Если хотите, чтобы раскрыл что-то подробнее, -- пишите в комментарии, постараюсь на всё ответить.
Для вопросов, которые стесняетесь оставить в комментариях, пишите в личку.
О моём дата инженерном опыте можно почитать в этом же канале по тегам и в моём телеграмм-канале.
Могу быть полезен как ментор, смотри условия здесь.
В репозитории можно попробовать решить дата-инженерную задачу с разным уровнем сложности и посмотреть на рабочий код.

#data #de #data_engineer

Вступай в сообщество | Расти в IT | Присылай историю