Comments 9
Наверное, вот почему сервера Пятерочки раньше хранили историю покупок "пожизненно", а теперь 4 месяца.
В первой таблице напутаны как раз даты валидности записей для Галины.
Спасибо за вашу обратную связь и, что обратили внимание на этот важный момент.
В таблице с примером про Степана и Галину всё верно. Так и задумано, что 2025-03-10 была добавлена запись о том, что запись о Галине была удалена 2025-03-09. Мы это обнаружили при очередной сверке среза за 2025-03-10 со срезом за 2025-03-09, которую мы делали 2025-03-10. Таким образом, мы понимаем, что история взаимодействия с Галиной завершилась 2025-03-09.
Это важно учитывать при построении среза на заданную дату. У меня в примере функции и запроса для получения среза даты начала и окончания включены в диапазон (поэтому там используются операторы >= и <=).
Вы добавили таблице темпоральность вместо того, что бы хранить снимки данных на каждый день так, что ли? Что за очередной велосипед? Последнее время появилась куча людей, которая с опытом в три года не зная теории изображает из себя архитекторов. Жесть.
Интересно, а что бы вы предложили для этой задачи по уменьшению объема накопленных исторических данных в виде срезов (снимков) для того же окружения (Hadoop и PySpark)?
При этом нужно сохранить всю историю изменений и вы не можете быстро перейти на какую-то другую новую платформу/технологию из-за различных технических и организационных ограничений.
Спасибо за статью.
А алгоритм отличает, если значение колонки стало NULL? То есть, было в колонке значение XXX и поменялось на NULL. Что будет записано в SCD-таблицу?
Если в колонку valid_to_dt всегда пишется максимальная дата кроме удалённых строчек, так может и заполнять её только для удалённых строчек, а для других случаев писать NULL?
Если значение в какой-либо колонке станет NULL, то добавится новая запись в таблицу уже с NULL. Исходные данные никак не модифицируются при записи в SCD-2 таблицу.
Пустые значения заменяются в колонках только при расчете хеш сумм и подготовке первичного ключа.
По поводу заполнения valid_to_dt - так можно делать, конечно, но, это нужно будет потом обязательно учитывать при построении срезов данных на заданную дату (функция get_data_slice_on_target_date). Вместо простого условие отбора filter(F.col("valid_to_dt") >= F.to_date(F.lit(target_dt)) нужно будет использовать более сложное filter((F.col("valid_to_dt") >= F.to_date(F.lit(target_dt))) | (F.col("valid_to_dt").isNull())). А это уже становится не так очевидно для конечных пользователей, следовательно, растет вероятность ошибки.
Повышаем эффективность хранения данных до 300 раз с помощью таблиц SCD-2