web-dev-qa-db-fra.com

Structure du flux d'air / organisation des Dags et des tâches

Mes questions :

airflowapache-airflow
18
nono

J'aimerais également comparer la structure des dossiers avec d'autres personnes. Cela dépendra peut-être de ce à quoi vous utilisez Airflow, mais je partagerai mon cas. Je fais des pipelines de données pour construire un entrepôt de données, donc à un niveau élevé, j'ai essentiellement deux étapes:

  1. Vider beaucoup de données dans un data-lake (directement accessible à quelques personnes seulement)
  2. Charger les données du lac de données dans une base de données analytique où les données seront modélisées et exposées aux applications de tableau de bord (de nombreuses requêtes SQL pour modéliser les données)

Aujourd'hui, j'organise les fichiers en trois dossiers principaux qui tentent de refléter la logique ci-dessus:

├── dags
│   ├── dag_1.py
│   └── dag_2.py
├── data-lake
│   ├── data-source-1
│   └── data-source-2
└── dw
    ├── cubes
    │   ├── cube_1.sql
    │   └── cube_2.sql
    ├── dims
    │   ├── dim_1.sql
    │   └── dim_2.sql
    └── facts
        ├── fact_1.sql
        └── fact_2.sql

C'est plus ou moins ma structure de dossiers de base.

10
fernandosjp

J'utilise quelque chose comme ça.

  • Un projet est normalement quelque chose de complètement séparé ou unique. Peut-être des DAG pour traiter les fichiers que nous recevons d'un certain client qui seront complètement indépendants de tout le reste (presque certainement un schéma de base de données distinct)
  • J'ai mes opérateurs, crochets et certains scripts d'aide (supprimer toutes les données Airflow pour un certain DAG, etc.) dans un dossier commun
  • Auparavant, j'avais un seul référentiel git pour l'ensemble du dossier Airflow, mais maintenant j'ai un git séparé par projet (ce qui rend plus organisé et plus facile d'accorder des autorisations sur Gitlab car les projets sont si indépendants). Cela signifie que chaque dossier de projet également en tant que .git et .gitignore, etc.
  • J'ai tendance à enregistrer les données brutes, puis à "reposer" une copie modifiée des données qui est exactement ce qui est copié dans la base de données. Je dois modifier fortement certaines des données brutes en raison de différents formats de différents clients (Excel, Web scraping, HTML email scraping, flat files, queries from SalesForce or other database sources ...)

Exemple d'arbre:

├───dags
│   ├───common
│   │   ├───hooks
│   │   │       pysftp_hook.py
│   │   │
│   │   ├───operators
│   │   │       docker_sftp.py
│   │   │       postgres_templated_operator.py
│   │   │
│   │   └───scripts
│   │           delete.py
│   │
│   ├───project_1
│   │   │   dag_1.py
│   │   │   dag_2.py
│   │   │
│   │   └───sql
│   │           dim.sql
│   │           fact.sql
│   │           select.sql
│   │           update.sql
│   │           view.sql
│   │
│   └───project_2
│       │   dag_1.py
│       │   dag_2.py
│       │
│       └───sql
│               dim.sql
│               fact.sql
│               select.sql
│               update.sql
│               view.sql
│
└───data
    ├───project_1
    │   ├───modified
    │   │       file_20180101.csv
    │   │       file_20180102.csv
    │   │
    │   └───raw
    │           file_20180101.csv
    │           file_20180102.csv
    │
    └───project_2
        ├───modified
        │       file_20180101.csv
        │       file_20180102.csv
        │
        └───raw
                file_20180101.csv
                file_20180102.csv
15
trench