Article très intéressant (bien qu'assez long) sur le concept de distributed data mesh : le but est en gros de ne plus faire un datalake monolithique, mais de le séparer entre toutes les teams. En gros, chaque product team devient responsable de la mise à disposition de ses datasets (comme elle l'est de ses APIs), grâce à un data engineer dans sa team et des outils mis à disposition par une autre équipe centrale de data engineer. Le concept est intéressant mais demande un gros changement de paradigme, et n'est utile selon moi que dans les grosses entreprises

Deux articles (celui-là et le suivant) sur le principe de DataOps. En gros, l'idée c'est de s'inspirer de la mouvance Devops pour l'appliquer à la donnée. Ça consiste à automatiser un maximum, et donner pas mal de pouvoirs aux utilisateurs qu'il puisse créer lui-même les tables qui l'intéresse. Ça englobe aussi la validation automatique de schéma, la reproductibilité, la simplicité... Pas mal de bon sens mais c'est toujours mieux de le voir expliciter

Brève explication de l'utilisation de dbt. En gros, ça permet de pouvoir observer facilement des changements de données dans une base, et de créer un pipeline de récupération et validation de données à partir de ça. Ou comment créer un ETL très facielement à partir de pas grand chose.

Explications du rôle de data-engineer selon Maxime Beauchemin (créateur d'Airflow). Globalement d'accord sur sa vision (me considérant moi-même comme tel), même si je suis réticent sur certains détails.

Comment pouvoir tester efficacement ses pipelines airflow. Pas mal de choses et d'aspect intéressant, et dont je compte bien m'inspirer, travaillant actuellement intensément sur Airflow