apache-airflow-providers-notebook¶

Operators

SparkNotebookOperator draait een Jupyter-notebook als een geplande, cluster-mode Spark-job: het checkt een notebook uit een git-repository uit, dient een SparkApplication custom resource in (onder de motorkap via SparkKubernetesOperator/SparkKubernetesSensor), en de resulterende driver-pod draait het notebook via papermill_runner.py tegen dezelfde platform-image en Hive Metastore catalog die interactieve JupyterHub-sessies gebruiken.

Gebruik¶

from airflow.providers.notebook.operators.spark_notebook import (
    SparkNotebookOperator,
)

run_notebook = SparkNotebookOperator(
    task_id="run_notebook",
    repo_url="https://dev.azure.com/<org>/<project>/_git/example-dags",
    repo_branch="main",
    notebook_path="open_data_notebook.ipynb",
    notebook_parameters='{"a": 1}',  # optional, passed to papermill
    # + optional driver/executor sizing knobs, extra_spark_conf
)

Alles voorbij task_id/repo_url/repo_branch/notebook_path is bewust geen parameter die vanuit een DAG in te stellen is. Het publieke oppervlak van de operator is agressief geminimaliseerd, zodat een DAG-auteur niet per ongeluk kan afwijken van hoe het platform daadwerkelijk is gedeployed. In plaats daarvan:

Instelling	Bron
Container-image	Env var `DATAPROCESSING_IMAGE` op de Airflow-deployment
Kubernetes-namespace	Automatisch gedetecteerd uit de ServiceAccount-projectie van de pod — nooit vanuit de DAG in te stellen
Spark-versie, Hive Metastore-connectie, checkout-image, `imagePullSecrets`	Hardgecodeerde module-constanten, één per Airflow-deploymentversie
Delta Lake warehouse dir / S3A-endpoint	Env vars `LAKE_WAREHOUSE_DIR` / `CUBEFS_S3_ENDPOINT` op de Airflow-deployment (verplicht — de operator werpt bij constructie een fout op als een van beide ontbreekt)
S3A access/secret key	Een vaste Kubernetes Secret-naam (`cubefs-lakehouse-credentials`), aangesloten op de driver-/executor-podspec via `secretKeyRef`. Deze wordt nooit ingelezen in de eigen procesomgeving van Airflow, wat de blast radius van een credential-lek beperkt tot dit ene Secret in plaats van de Python-code van elke DAG.
Git checkout-credentials	De Airflow-connectie `git_default` (via `GitHook`), geen handmatig aangemaakt Secret

Zowel de taak-pod die de SparkApplication indient als de resulterende driver-pod draaien onder het namespace-gebonden spark-driver-ServiceAccount van de klant, dezelfde identiteit die een JupyterHub-notebookkernel in client mode gebruikt. De Airflow-instantie van een klant heeft geen breder bereik in het cluster dan dat.

Vereisten voor de Airflow-deployment¶

Iedereen die Airflow met deze provider deployt moet ervoor zorgen, in de namespace waarin de workers van Airflow draaien:

Drie env vars ingesteld op de Airflow-deployment: DATAPROCESSING_IMAGE, LAKE_WAREHOUSE_DIR, CUBEFS_S3_ENDPOINT.
Een Kubernetes Secret genaamd cubefs-lakehouse-credentials met de keys CUBEFS_ACCESS_KEY / CUBEFS_SECRET_KEY.
Het spark-driver-ServiceAccount met RBAC op sparkapplications en sparkapplications/status (een aparte sub-resource).
Een Airflow-connectie git_default (type git) met leestoegang tot welke repo_url een DAG ook doorgeeft.

Zie de eigen deployment-repo van het platform voor hoe deze worden geprovisioned.