Короткий ответ Единственного правильного решения нет: можно добавить явные assert на количество строк до/после merge и validate на тип связи в каждом критичном месте пайплайна, либо выстроить более общий слой автоматических проверок инвариантов данных — выбор зависит от того, сколько таких критичных мест в пайплайне и насколько высока цена ошибки. Как это работает подробнее точечная защита — это assert len(result) == len(left) сразу после merge, где ожидается связь один-к-одному или один-ко-многим без изменения числа "главных" записей, плюс validate в самом merge; более общая защита — отдельный модуль проверок данных (data quality checks), который прогоняется после каждого значимого шага пайплайна и логирует/останавливает выполнение при нарушении инварианта. Пример кода Что использовать на практике На практике. для критичных финансовых и управленческих отчётов стоит добавлять проверки в тех местах, где исторически уже случались инциденты, и в местах, где ключ объединения потенциально может перестать быть уник
Загрузка…
