🔒Открыть пост
и посмотреть медиа
и посмотреть медиа
Данные с запозданием в БД
Предположим, в базе данных случаются ситуации: операция была произведена 30-ого числа, а в DWH эта запись отразилась только 5-ого. В случае, если по таким данным строятся отчеты, то такие отчеты будут неполными, т.к. в них не будут входить подобные операции (если берем отчеты за месяц). Исправлять же уже готовые отчеты задним числом тоже не совсем правильно и допустимо.
И для того, чтобы избегать таких ситуаций и иметь корректные отчеты, было придумано несколько способов:
▶️Отчеты можно делать в виде Insert-only витрин. Это значит, что все факты добавляются новыми строками, а старые не перезаписываются. Отчёт считается и обновляется автоматически и является динамическим, при этом он защищен от удалений и включает все когда-либо пришедшие данные. Но такой способ подойдет далеко не всем и не всегда.
▶️Также в DWH можно ввести понятие "закрытый период", который учитывает этот самый пятидневный лаг. И сделать так, что отчет доступен для изменений, условно, до 5-ого числа, а после этого он фиксируется окончательно.
В случаях же, если данные из отчетного периода приходят после 5-ого числа, то они считаются "корректировками". Корректировки, в свою очередь, могут идти как в отдельную таблицу, так и в следующий отчетный период с пометкой "корректировка". В будущем они могут быть использованы и для пересчета старых отчетов, и для создания новых версий сданных отчетов, и для пересчета новых отчетов и т.д. Но, очевидно, такой способ подходит далеко не везде и не всегда.
▶️Еще один выход - это хранить в таблицах 2 даты: дату совершения операции (event_date) и дату загрузки в DWH (load_date). Для формирования классического отчёта на определённую дату идет агрегация по event_date, всё как и обычно. Но в случае, когда позже нужно будет найти и объяснить расхождения, потребуется уже load_date. Благодаря такой воспроизводимости будет видно, какие именно операции не были учтены в отчете по причине поздней загрузки. Довольно универсальный способ, хоть и потребует небольшую адаптацию архитектуры БД.