Почему пайплайн работает в dev, но падает или тормозит в prod?

Это скорее не одна конкретная ошибка, а целая категория, и почти каждый её случай сводится к одному из нескольких конкретных расхождений между dev и prod.

Объём данных, очевидно — но и форма данных тоже

Самый очевидный разрыв — объём: dev-выборка из 10 000 строк не нагружает сброс при shuffle, перекос или давление на память так, как это делают 500 миллионов строк. Менее очевидно: форма данных тоже отличается — dev-выборка часто берётся равномерно или из недавних данных, что может случайно обойти именно то перекошенное распределение ключей или столбец с обилием null, которые есть в продакшен-данных. Различия в объёме проявляются как замедление; различия в форме — как задачи, которые вообще падают на паттернах данных, которых dev никогда не видел.

Конкуренция за кластер, которой нет в dev-окружениях

Dev-кластер обычно выделен одному человеку, запускающему одну задачу. Продакшен-кластеры часто общие, мультитенантные или подвержены эффекту «шумных соседей» от других задач, конкурирующих за те же ресурсы. Задача, получающая полное, безраздельное выделение executor'ов в dev, может заметно деградировать в prod исключительно из-за конкуренции за ресурсы, никак не связанной с логикой самой задачи.

Дрейф конфигурации между окружениями

Память executor'а, число shuffle-партиций и число инстансов часто настраиваются вручную один раз для теста на dev-масштабе и больше никогда не пересматриваются для prod-развёртывания — или наоборот, prod-конфигурация без нужды копируется в dev. В любом случае конфигурация, которая «работала», никогда фактически не проверялась на реальных характеристиках другого окружения.

Как реально закрыть этот разрыв до деплоя

Самый надёжный подход: экстраполировать, а не гадать. Возьмите реальные метрики dev-прогона — длительность задач, объём shuffle, использование памяти на строку — и масштабируйте их линейно (или с известными нелинейными коэффициентами, например, стоимость shuffle растёт хуже линейной с ростом числа строк) до оценённого продакшен-объёма до первого прогона в продакшене. Это превращает «узнаем в проде» в проверяемое предсказание, которое можно сверить с тем, что происходит на самом деле.