Аналитика данных / Data Study

Код-ревью как индивидуальная обратная связь

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

Все скрипты комитятся в GitHub репозитории, а там уже настроен целый CI/CD чтобы код попадал в Airflow и работал, а не просто хранился.

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

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

Ни у каждого на работе есть коллеги, которые сделают вам код-ревью или подскажут, а здесь такой опыт появляется.

Кто я | Навигация | Обучение

Почему важно учитывать Timezone в SQL запросах

Покажу на наглядном и реальном примере. У нас есть дата и время в UNIX-формате, которое выглядит изначально как целое число: 1776373200

А теперь представляем, я подготовил данные для дашборда, написал SQL-запрос и пошел создавать отчет.

Запрос один и тот же, но стоит его запустить в разных местах и можно получить разные даты.
Мой запрос

SELECT
to_timestamp(1776373200) AS dt,
(to_timestamp(1776373200) AT TIME ZONE 'UTC') AS dt_utc,
(to_timestamp(1776373200) AT TIME ZONE 'Europe/Moscow') AS dt_msk

1-й скрин показывает результат когда пишу запрос в DBeaver. 2-й скрин когда тот же самый запрос запускаю в Datalens под созданием датасета.

В поле dt разные даты!

Почему так получается?
Это не ошибка, а разница часовых поясов, который в случае запуска в DBeaver учитывает мой текущий часовой пояс, а в случае запуска в Datalens дата и время отображаются в UTC. Если оставить запрос как есть в поле dt мы получим расхождение и неправильные метрики в отчете и в базе данных просто потому, что будем как-будто работать в разных часовых поясах. Поэтому важно приводить все временные поля к одному единому часовому поясу, а в запросах лучше указывать его в явном виде, чтобы он не зависел от системных настроек сервера. Ну и не забываем что поля с датами могут сравниваться между собой и также важно чтобы сравниваемые даты были в одном часовом поясе

Ставьте реакции, если теперь будете думать про таймзоны 😉

Кто я | Навигация | Обучение