XCom и data passing — обзор модуля

XCom (cross-communication) — механизм передачи данных между tasks. По умолчанию хранится в metadata DB, имеет практический лимит 48KB. Для production data engineering этого мало — модуль учит, как масштабировать XCom через custom backends на S3/GCS/Object Storage abstraction.

Уроки модуля

Ключевые концепты

• Default storage: таблица xcom в metadata DB, колонка value (bytea/mediumblob). Практический лимит ~48KB, выше — scheduler тормозит из-за раздутых select-ов
• Сериализация: JSON (default через XComEncoder) или pickle (legacy, security risk)
• Custom Backend: subclass airflow.models.xcom.BaseXCom, override serialize_value / deserialize_value. В DB сохраняется ссылка, blob — на S3/GCS
• Object Storage XCom (2.8+): готовый XComObjectStorageBackend через провайдер common.io. URL: xcom_objectstorage_path = s3://conn_id@mybucket/key
• В Mapped tasks: каждая mapped TI хранит XCom отдельно (map_index column). xcom_pull(task_ids='x') без map_index агрегирует всё

Killer takeaway

100MB pandas DataFrame через default XCom = error/timeout. Через S3 backend = работает прозрачно. Migration на S3 backend — одна из первых вещей при выходе в production.

Production gotchas

1. do_xcom_push=True для всех PythonOperators по умолчанию → раздутые xcom-ы. Установить False, если return не используется.
2. xcom_pull без task_ids подтянет всё из upstream — expensive.
3. Pickle security — never enable_xcom_pickling=True если есть user-submitted code. Deserialization attack.
4. Custom backend обязателен для production с pandas/numpy объектами.