Еще одна история о потере данных ✍️
Прилетела задача от аналитика - сделайте витрину, вот вам готовый запрос.
В запросе не очень сложный расчет, но там джоинится несколько больших витрин. А мы стараемся не создавать витрину из витрин.
Поэтому мне надо было повторить запрос аналитика, но из таблиц в ядре (слой dds). Тоже все это не очень сложно, переделал запрос, вроде сходится.
Подготовил тестовую витрину в песочке для аналитика, чтоб сверил данные из своего запроса. Все ок - сходится.
Сделал MR (merge request), внедрили обновление в прод. Смотрим данные в новой витрине, что-то не так.. Небольшой процент данных не сходится с данными из тестовых запросов..
И вот начинается суета на пару дней 😔 Снова проверяю запрос аналитика, мой запрос - сходится. Что-то с дбт..
Разбираюсь с дбт, что по итогу он генерит, как он создает темповые таблицы. Нахожу запросы, которые запускались прям в БД (это было не просто).
Запускаю запрос - тоже все ок. Но почему в базе данные другие🤔
Нашел ошибку в запросе аналитика и в моем. * Немного неправильная группировка. Думаем в этом косяк. Снова сверил запросы - все ок, одинаковый правильный результат.
Внедряем в прод - снова данные не сходятся))
Снова подозреваю дбт, что-то не то запускается. Позвал шарящего коллегу DE - теперь вместе не понимаем что за магия)) Мой запрос отрабатывает также как и аналитика. И данные верные. И тестовая витрина тоже с правильными данными.
Другой DE тоже не понял в чем косяк. Но предполагаем или косяк в моем запросе или в дбт. Самое главное мы не можем получить данные, которые прогружаются в базу.
вот маленький кусочек этого запроса
case when code = 'x'
then lag(case when code = 'xxx' then create_date end)
over(partition by yyy, date_trunc('day',dea.create_date) order by create_date)
end as zzz
Я предложил проверить тайм зоны, но мы конечно же забили, подумали вряд ли в этом дело🥲
Далее подключилась еще коллега DE. Запускает запрос и сразу получает такие же данные как и в БД. То есть она одна видит косячные данные, а мы все нет)
Я подготовил маленький скриптик, который у нее запрос выдает несколько строк, а у нас у всех такой же запрос выдает 0 строк.
Уже очевидно, что-то с настройками наших IDE.
В общем, в чем проблема - у меня, аналитика и еще одного DE в настройках таймзоны было utc +3.
А у другого DE и главное в БД таймзона была просто utc (на 3 часа меньше чем мск).
И косяк вроде бы был как раз в sql кусочке, который я выше прикрепил. Если время около 12 ночи, то дата по-разному обрезается. Для нас было час ночи 29 декабря, а для БД это 28 декабря 22 часа. Или может еще дальше был косяк, там еще куча разных джоинов и фильтров с датами.
Поменял таймзону на соответствующую БД - все сошлось. Теперь я выполняю запросы и тоже вижу некорректные данные, как и в БД. Дальше уже было легко найти причину. Косяк есть и в запросе аналитика, как следствие и в моем. Все поправили. Новый MR, данные в проде сошлись 🎉
Сейчас кажется очевидной такая ошибка. Я и знал про настройки в БД, но не подумал что так может меняться результат.
Теперь у меня в датагрип таймзона utc +3, а в дбивере utc. Если что в двух местах чекну запросы. *Я знаю что таймзону можно в прям в запросе прописывать.
Мораль: всегда проверяйте настройки timezone в IDE перед дебагом дат. Это может сэкономить пару дней головной боли.
Прилетела задача от аналитика - сделайте витрину, вот вам готовый запрос.
В запросе не очень сложный расчет, но там джоинится несколько больших витрин. А мы стараемся не создавать витрину из витрин.
Поэтому мне надо было повторить запрос аналитика, но из таблиц в ядре (слой dds). Тоже все это не очень сложно, переделал запрос, вроде сходится.
Подготовил тестовую витрину в песочке для аналитика, чтоб сверил данные из своего запроса. Все ок - сходится.
Сделал MR (merge request), внедрили обновление в прод. Смотрим данные в новой витрине, что-то не так.. Небольшой процент данных не сходится с данными из тестовых запросов..
И вот начинается суета на пару дней 😔 Снова проверяю запрос аналитика, мой запрос - сходится. Что-то с дбт..
Разбираюсь с дбт, что по итогу он генерит, как он создает темповые таблицы. Нахожу запросы, которые запускались прям в БД (это было не просто).
Запускаю запрос - тоже все ок. Но почему в базе данные другие🤔
Нашел ошибку в запросе аналитика и в моем. * Немного неправильная группировка. Думаем в этом косяк. Снова сверил запросы - все ок, одинаковый правильный результат.
Внедряем в прод - снова данные не сходятся))
Снова подозреваю дбт, что-то не то запускается. Позвал шарящего коллегу DE - теперь вместе не понимаем что за магия)) Мой запрос отрабатывает также как и аналитика. И данные верные. И тестовая витрина тоже с правильными данными.
Другой DE тоже не понял в чем косяк. Но предполагаем или косяк в моем запросе или в дбт. Самое главное мы не можем получить данные, которые прогружаются в базу.
вот маленький кусочек этого запроса
case when code = 'x'
then lag(case when code = 'xxx' then create_date end)
over(partition by yyy, date_trunc('day',dea.create_date) order by create_date)
end as zzz
Я предложил проверить тайм зоны, но мы конечно же забили, подумали вряд ли в этом дело🥲
Далее подключилась еще коллега DE. Запускает запрос и сразу получает такие же данные как и в БД. То есть она одна видит косячные данные, а мы все нет)
Я подготовил маленький скриптик, который у нее запрос выдает несколько строк, а у нас у всех такой же запрос выдает 0 строк.
Уже очевидно, что-то с настройками наших IDE.
В общем, в чем проблема - у меня, аналитика и еще одного DE в настройках таймзоны было utc +3.
А у другого DE и главное в БД таймзона была просто utc (на 3 часа меньше чем мск).
И косяк вроде бы был как раз в sql кусочке, который я выше прикрепил. Если время около 12 ночи, то дата по-разному обрезается. Для нас было час ночи 29 декабря, а для БД это 28 декабря 22 часа. Или может еще дальше был косяк, там еще куча разных джоинов и фильтров с датами.
Поменял таймзону на соответствующую БД - все сошлось. Теперь я выполняю запросы и тоже вижу некорректные данные, как и в БД. Дальше уже было легко найти причину. Косяк есть и в запросе аналитика, как следствие и в моем. Все поправили. Новый MR, данные в проде сошлись 🎉
Сейчас кажется очевидной такая ошибка. Я и знал про настройки в БД, но не подумал что так может меняться результат.
Теперь у меня в датагрип таймзона utc +3, а в дбивере utc. Если что в двух местах чекну запросы. *Я знаю что таймзону можно в прям в запросе прописывать.
Мораль: всегда проверяйте настройки timezone в IDE перед дебагом дат. Это может сэкономить пару дней головной боли.