от пословного перевода очень больно, не надо так делать

ну добавьте конструктива - допишу, перформулирую.  Можете в личку.

я бесплатным редактором не работаю. бесплатно только советы даю.
например, «не умеешь писать на техническом английском — тренируйся на кроликах. а ещё побольше читай носителей.»

Администратор, администратору рознь. Какой сервер, какие задачи. Хотя, здесь, думаю Вы не найдете. Это не те люди :)

Простите, дальше спор на таком уровне без меня.

Коллеги, добрый день извините что не по теме, у кого нибудь есть опыт перехода с 2 мониторов на 1 ultrawide?

Пользуюсь ultrawide (даже двумя, мне нравиться)

двумя?

пользуюсь одним, хватает

Друг над другом (старый переехал наверх)

крут

Так а фиг ли, спарком там три строчки )

Зачем? Надо копиэдиторов просить переделать!

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

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

Ну как бэ это зависит от семантики ваших данных. Может быть это прогнозы какие-то и будущие даты - это норма. Я вот высекаю все, что старше 2105 года.

Что в сентенциях-то было?

"Данные удалять нельзя"

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

А плодить 100500 партиций по килобайту на фейковые даты из 33567 года можно.