Image tirée de slon.pics Suite
Il a été rédigé par Micha Kunze qui nous a très aimablement autorisé à le traduire.
Cet article a été originellement publié ici : https://towardsdatascience.com/develop-your-data-as-a-product-f9ba268c4e20
De nombreuses entreprises investissent dans leur lac de données de nouvelle génération, dans l'espoir de démocratiser les données à grande échelle pour fournir des informations commerciales et, en fin de compte, prendre des décisions intelligentes automatisées. Les plateformes de données basées sur l'architecture du lac de données ont des modes de défaillance communs qui conduisent à des promesses non tenues à grande échelle. Pour faire face à ces modes de défaillance, nous devons passer du paradigme centralisé d'un lac ou de son entrepôt de données prédécesseur. Nous devons passer à un paradigme qui s'inspire de l'architecture distribuée moderne: considérer les domaines comme la préoccupation de premier ordre, appliquer la pensée de plate-forme pour créer une infrastructure de données en libre-service et traiter les données comme un produit.
Face à la pandémie du COVID-19, c’est une véritable course aux essais thérapeutiques qui s’est engagée depuis quelques mois avec actuellement un grand nombre de laboratoires pharmaceutiques mobilisés sur le sujet. A ce jour, c’est plus d’une cinquantaine de demandes d’autorisations d’essais cliniques sur le Covid-19 qui ont été soumises rien qu’en France ! Mais qu’est-ce exactement qu’un essai clinique ?
Nous arrivons à la fin de cette série de “10 conseils pour être un super data engineer”, nous avons abordés ensemble différentes techniques afin de rendre vos traitements plus performants, efficaces et scalables. Nous allons conclure avec “Everything as code” qui vous permettra de versionner vos traitements, les partager, les réutiliser et les affiner par le biais de la collaboration.
Les Traces vous aident à mieux comprendre l'état d’avancement de vos traitements. Continuons cet échange avec les traitements et regardons leur fonctionnement en profondeur afin de les rendre plus efficaces.
Dans les articles précédents nous avons abordé différentes bonnes pratiques autour de la taille et du rôle des jobs, et de l’automatisation de l'exécution de vos jobs à l’aide d’un orchestrateur. Et si vous laissiez vos jobs vous informer, à l’aide de traces, dans quelle étape du traitement sont-ils ?
Les bonnes pratiques peuvent parfois nous échapper. Pensez à séparer la logique d’orchestration de la logique de traitement et gardez vos données en parfaite harmonie. Nous allons continuer avec un axe majeur pour une architecture data réussie et durable : la scalabilité.
Qui ne cherche pas à gagner en efficacité ? Pour cela, pensez à découper systématiquement vos jobs en “petites” tailles et vous gagnerez en efficacité, en temps d'exécution et une facilité de maintenance. Nous allons donc continuer avec une autre bonne pratique qui est l’automatisation de l'exécution de nos jobs à l’aide d’un orchestrateur.
Le conseil précédent avait pour but de rappeler la responsabilité d’un job sur son propre environnement de travail, ce que l’on oublie assez facilement lorsqu’on code. Nous allons maintenant voir comment et pourquoi il faut découper ses traitements, simple, mais tellement évident et efficace en pratique.
L’idempotence n’a plus secret pour vous, alors on continue ? Ce conseil peut-être vu comme un complément au conseil précédent. C’est une recommandation assez technique mais souvent oubliée lorsqu’on implémente “sur-son-environnement-et-que-tout-fonctionne”.