📢 6 вредных привычек для потери времени в Data Engineering

Собрал несколько плохих привычек, которые когда-то были у меня самого. Некоторые стоили пары часов, некоторые целого вечера, а одна чуть не снесла всё Docker-окружение.

1️⃣ Делать красиво раньше, чем правильно

Раньше я мог добавить ещё один CTE, переименовать все поля и начать оптимизацию до того, как проверил сам расчёт.

Проблема в том, что красивый запрос тоже может считать ерунду. Только место ошибки в нём искать сложнее.

Сейчас сначала собираю простой рабочий вариант, запускаю на небольшом сэмпле, проверяю количество строк, уровень данных и контрольные суммы, а потом уже можно рефакторить и оптимизировать.

2️⃣ Менять во время отладки сразу всё

Однажды я одновременно правил docker-compose, переносил WSL, чистил диск и переустанавливал окружение. В итоге потерял контейнеры, образы и случайно снёс Java runtime.

Когда меняешь пять вещей сразу, невозможно понять, какая из них помогла, а какая всё окончательно сломала.

Лучше поменять что-то одно, одну переменную, снять метрики, потом заново. И это правда работает, потому что получаешь одно изменение и можешь его объяснить.

3️⃣ Оставлять полезный код в tmp и ноутбуках

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

Теперь даже черновые скрипты стараюсь отправлять в Git. Пусть файл пока некрасивый, зато он не исчезнет вместе с окружением.

4️⃣ Доверять автоматически определённым типам

У меня разваливалась вставка из-за того, что один из выходных типов не совпал со схемой целевой таблицы. Логов было мало, поэтому до причины я дошёл далеко не сразу.

С тех пор в важных местах явно задаю схему, использую CAST и даже для пустых колонок фиксирую ожидаемый тип. Особенно при чтении CSV, перед INSERT и UNION.

5️⃣ Проверять всё руками и не оставлять след

Раньше я мог скопировать несколько запросов, руками заменить таблицы и даты, посмотреть результат и закрыть вкладку. Через неделю приходилось вспоминать, что именно я сверял.

Повторяющиеся проверки теперь стараюсь параметризовать, а важные результаты записывать в DQ-журнал: дата, таблица, название проверки, статус и значение.

6️⃣ Лечить медленный Spark добавлением ресурсов

Первая реакция на медленную или падающую Spark job понятная: дать больше памяти и ядер. Иногда это помогает. Иногда job просто дольше ждёт ресурсы, которых в очереди нет, а настоящая проблема остаётся в shuffle, перекосе данных или неудачном числе партиций.

Поэтому сначала смотрю план выполнения, Spark UI и ограничения кластера. И только потом добавляю ресурсы.

Все эти привычки поначалу выглядят как экономия времени.

⬇️ Делитесь своими плохими привычками, которые когда-то были.