Подскажите, как вы относитесь к бесчеловечной кастрации мусора из сырых

данных ?
У нас в поступающих данных были обнаружены 4 строки с датами операций на полгода-год вперед. В операционной базе и в приложении не настроены ограничения ручного ввода. За 7 лет из 10 млрд строк. Я забросил в общий чат предложение дропать эти строки, предварительно скопировав в отдельную таблицу looking2future.
На что услышал кучу эмоциональных сентенций от части коллег.
Смысл переноса-удаления, снижение риска ошибок при инкременте, дублированном на неск. десятков витрин.
Как у вас с присмотром за качеством данных ?

В целом это всегда больно) Но по нашему опыту, это выглядит примерно так. Видишь какие то выбросы в данных. Идешь в бизнес, уточняешь что это. Какая то аномалия, баг или фича процесса? Либо согласовываешь фильтрацию таких аномалий с бизнесом, либо волевым решением на уровне аналитик*архитектор. Итого: допиливаешь фильтры в витринах, либо на более ранних "сырых" уровнях. Или, если это какая то фича процесса, и данные считаются валидными. Пилишь обработку этих данных, чтобы не ломались витрины.

в слое сырых данных их лучше оставить как есть. Дальше у вас могут быть настроены процессы DQ, которые будут фильтровать данные не соответвующие DQ правилам (в вашем случае не корректная дата), а после уже расситываться витрины. Отфильтрованные записи можно складывать в отдельную таблицу для последующего разбора Data steward