Auteur
L'édition de cette année s'est déroulée à la Nouvelle-Orléans. Et comme lors des éditions précédentes, nous avons appris beaucoup de choses sur le paysage de l'ingénierie analytique.
L'événement organisé par dbt était de retour cette année. Vous pouvez y assister physiquement à la Nouvelle-Orléans ou regarder les conférences en ligne.
L'adoption de la dbt étant en hausse, nous attendions beaucoup de cette conférence. Des sessions sur différents sujets ne se limitant pas à l'utilisation de la dbt ont été proposées. Par exemple, il y a eu des sessions sur les parcours de carrière pour les équipes data.
Sans plus attendre, voici les principaux enseignements de cette édition selon moi :
Entrons dans les détails.
Les modèles Python, enfin !
C'était certainement la fonctionnalité la plus attendue. Vous pouvez désormais exécuter des modèles Python. Le comportement est très similaire à celui des modèles SQL.
Cette fonctionnalité change la donne. Je pense que nous sommes nombreux à rencontrer le même problème avec un flux de travail que nous ne pouvons pas exécuter de bout en bout à cause d'une ou deux opérations qui sont très délicates à réaliser en SQL. C'est pénible parce que nous avons besoin d'une couche supplémentaire. Nous ne voulons pas gérer ce va-et-vient entre dbt et un autre composant.
C'était le cas en particulier pour les statistiques avancées, la manipulation de texte et tout ce qui est lié au ML (feature engineering, enrichissement data ...). Ces cas limites sont les cas d'utilisation cibles des modèles Python. Les chefs de produit ont été très clairs lors de la keynote sur le fait qu'il s'agira de les cas d'utilisation de base qui impliquent des transformations data. Il n'est pas recommandé d'appeler des API externes.
Comment cela fonctionne-t-il ?
Premièrement, comme les modèles SQL, le code sera exécuté sur votre cloud data platform.
Deuxièmement, de la même manière que pour les modèles SQL, vous devez adapter votre syntaxe en fonction de la plateforme cloud sous-jacente. En SQL, vous devez utiliser le dialecte SQL approprié. En Python, vous disposez d'un un ensemble différent de bibliothèques qui seront disponibles.
Cette fonctionnalité est disponible sur trois data platforms dès aujourd'hui :
Par exemple, si vous utilisez Snowflake, vous pouvez utiliser Snowpark pour vos transformations. Notez que cette fonctionnalité n'en est qu'à ses débuts, comme l'ont mentionné Eda Johnson et Venkatesh Sekar dans leur présentation “Empowering pythonistas with dbt and snowpark”. snowpark est encore en phase d'aperçu public.
Comme indiqué lors de la conférence de presse, il y a une marge d'amélioration pour se rapprocher de l'expérience d'un ingénieur logiciel Python (faciliter la réutilisation du code à travers les modèles, fournir des capacités de test, et utiliser des docstrings pour la documentation...).
Beaucoup d'améliorations pour dbt cloud
Il y a quelques mois, un billet de blog intitulé “Nous devons parler de la dbt”, L'article intitulé "L'avenir de l'Europe", écrit par Petram Navid, a fait des vagues. Tristan Handy, PDG de dbt labs, a répondu aux préoccupations de Pedram, en particulier celles concernant le dbt cloud. En effet, dans le billet de blog original, le praticien de longue date de dbt a souligné la mauvaise expérience qu'il a eue avec dbt cloud. Tristan a convenu qu'ils devraient travailler dur pour améliorer l'expérience des développeurs.
Et ils l'ont fait ! Cette semaine, dbt Labs a annoncé une refonte complète de l'IDE cloud, des améliorations de l'interface utilisateur et une réduction de la latence pour les opérations courantes telles que l'enregistrement d'un fichier.
C'est une bonne nouvelle pour les utilisateurs de dbt cloud !
La couche sémantique est un changement structurel dans la façon dont vous gérez votre data
C'est un sujet brûlant !
Au cours de la conférence, les orateurs ont défini la couche sémantique comme suit “la “plateforme de compilation et d'accès aux actifs de la dbt dans les outils en aval”.
La couche sémantique vise à résoudre les problèmes courants liés à la data governance :
L'objectif est d'étendre le champ d'application de dbt. Pour l'instant, le champ d'application est limité à la couche de transformation. Nous pourrions ajouter cette couche sémantique au-dessus de la couche de transformation.
C'est logique. Dans la version 1.0, les métriques ont été introduites. C'était le premier pas vers la vision d'une couche sémantique.
dbt au cœur de l'écosystème moderne de la pile data
Ce qui m'a frappé lors de cette conférence, c'est le nombre de partenariats annoncés. De plus, la majorité des exposés ont été donnés par des partenaires.
Les fournisseurs de logiciels comme Atlan, Collibra ou MonteCarlo doivent s'intégrer à dbt parce que leurs clients le leur ont demandé. dbt devient lentement la norme pour la transformation data. Vous voulez voir vos transformations dans votre lignée data globale qui pourrait être gérée avec un outil externe comme Collibra. Vous souhaitez également contrôler les résultats de vos tests dbt avec votre outil préféré, etc. Vous avez besoin d'une intégration entre vos outils.
Contrairement à dataform, le seul concurrent de dbt à ce jour, j'ai le sentiment que dbt labs souhaite rester neutre en matière de cloud. Ils proposent de nombreuses intégrations avec des solutions de niche pour mieux gérer la qualité de votre data ou votre metadata par exemple.
Conclusion
C'est terminé ! Cette édition a été très riche. Et nous terminons cette semaine avec beaucoup de discussions sur les annonces. C'est ce qui rend ce travail passionnant !
À ce propos, nous embaucher à Artefact ! Je suis sûr que vous ne l'avez pas vu venir 😉
