Вопрос проверяет понимание архитектурных причин, по которым XCom нельзя использовать как транспорт данных.
XCom хранит данные в metadata database Airflow. Большие объёмы данных перегружают базу и замедляют работу системы. Это ухудшает scheduler, UI и выполнение DAG. XCom не оптимизирован для потоковой передачи или хранения данных. Поэтому его используют только для небольших значений.
Ограничение XCom — это не «случайное неудобство», а осознанное архитектурное решение Airflow.
XCom anti-pattern — использование XCom для передачи больших данных, что приводит к деградации Airflow.
XCom:
хранится в metadata database;
используется scheduler-ом и UI;
участвует в системных запросах.
Большие данные:
увеличивают размер таблиц;
замедляют все операции Airflow.
При передаче больших payload:
растёт время ответа БД;
scheduler начинает отставать;
увеличивается риск ошибок и timeouts.
В итоге страдает весь кластер Airflow.
XCom:
не потоковый;
не сжимает данные эффективно;
не предназначен для файлов или batch-данных.
Это принципиально не его задача.
Для больших данных:
сохраняйте их в БД или хранилище;
передавайте через XCom только путь или ID.
Пример подхода:
задача A пишет файл в S3;
через XCom передаётся путь;
задача B читает файл по этому пути.
XCom не подходит для больших данных, потому что он использует metadata database Airflow и влияет на работу всей системы. Его правильное назначение — передача метаданных, а не данных.
