L’ingénierie Data ne cesse d’évoluer et s’éloigne du traditionnel ETL.

Historiquement, les ingénieurs data se concentraient essentiellement sur la mise en place d’un pipeline ETL (extract, transform, load) pour déplacer les données issues de diverses sources vers un référentiel de données centralisé tel qu’un data warehouse. Cette tâche était particulièrement chronophage, nécessitait beaucoup de codage et de configurations manuelles.

Avec l’arrivée d’outils tels que Archi (Open Source), PowerDesigner de SAP, SqlDBM (Online Data Modeling Tool), IDERA ER/Studio ou encore Erwin Data Modeler de Quest, il est dorénavant possible d’automatiser l’ensemble de ce processus.

Résultat ?
Les ingénieurs data sont en capacités d’extraire les données et de les charger rapidement alors que les volumes collectés et stockés sont exponentiels. Ils peuvent se concentrer sur des tâches plus complexes et à plus forte valeur ajoutée, la modélisation des données.

La modélisation de données est le processus qui permet de créer une vue conceptuelle des données et leur relation entre elles. Elle permet de définir la structure des données, ses attributs, les liens entre elles et donc d’organiser leur stockage de manière optimale. C’est indispensable pour tout projet analytique car cela permet de s’assurer que les données sont correctes, cohérentes, organisées et facilement accessibles.

Trois type de modélisation de données :
👉 Modélisation conceptuelle : Il s’agit de créer une représentation de haut niveau des données, y compris les relations entre les entités, afin de déterminer la structure globale des données.
👉 Modélisation logique : Il s’agit de créer une représentation plus détaillée des données, y compris les attributs de chaque entité et les relations entre les entités.
👉 Modélisation physique: Il s’agit de concevoir la base de données physique et de déterminer la meilleure façon de stocker les données en termes de structures de données, d’indexation et de partitionnement.

Non seulement la modélisation de données permet d’améliorer le Data Management et Data Warehousing mais cela ouvre aussi de nouvelles perspectives en Data Science et en Machine Learning. En effet, comme les données sont stockées de manière cohérente et organisée, les data scientists y ont accès plus facilement et peuvent mieux les exploiter. Les résultats sont d’autant améliorés et beaucoup plus fiables.

En rationalisant le pipeline de données et en permettant aux ingénieurs data de se concentrer sur des tâches plus complexes, la modélisation des données peut aider les organisations à mieux utiliser leurs données et à libérer tout le potentiel de la data science et de l’apprentissage automatique.

Sources :

https://www.guru99.com/data-modelling-conceptual-logical.html

https://publication.hikmahtechnologies.com/data-engineering-evolves-from-etl-to-the-world-of-data-modelling-2175c8083f31

Dans la data, c’est exactement comme dans le développement logiciel de produits ! Avant, il y avait des développeurs spécialisés front et d’autres back-end, d’autres chargés que de la mise en production, d’autres des tests, etc. En data, on avait aussi des DBA. Chacun avait un rôle bien précis. Mais depuis les pratiques Agile, le DevOps, le CI/CD et l’automatisation des tests se sont démocratisés en même temps que la course à l’innovation et les contraintes de time-to-market se sont accentuées.

Être ingénieur data aujourd’hui ne se résume plus à la conception de Datawarehouse, la mise en place d’ETL, le lancement de requêtes SQL et la restitution dans des tableaux de bord. Certes, il ne s’agit pas d’être spécialiste en tout mais un ingénieur data fullstack a désormais des connaissances étendues dans de nombreux domaines.

Yazid Nechi, Président de Smartpoint

Comment reconnaitre un bon ingénieur Data ?

• Il sait programmer ! Il maîtrise en effet au moins un langage de programmation et chez smartpoint, c’est plusieurs : Java, Python, Scala pour les incontournables.
• Il connait les outils du big data comme Hadoop, Hive, Spark, Pig Sqoop
• Il sait concevoir et exploiter un Data Warehouse et pour ce faire, les meilleurs outils à maîtriser sont Amazon Redshift, Google Big Query et bien entendu Snowflake. Mener des actions d’ETL étant indispensables à sa fonction, il a également des compétences en Talend, informatica entre autres.
• C’est un expert en bases de données relationnelles (SQL) qu’elles soient analytiques ou transactionnelles (OLTP, OLAP).
• Il maîtrise aussi les bases de données en NoSQL qui sont de différentes natures en fonction du modèle de données

Architecture

C’est la base, il doit comprendre comment sont organisées les données et quels sont les objectifs en termes de traitement et de gestion des données. Cela suppose aussi d’avoir une bonne culture générale sur les nouvelles méthodes de data ingestion (comme Kafka), les différentes alternatives de stockage ainsi que les normes de sécurité pour la protection des données (dont la gestion des droits et des authentifications).

SQL

C’est une compétence certes traditionnelle mais toujours indispensable !

ETL (ou ELT)

C’est la base du métier : mettre en place le pipeline de données pour capturer, transformer et charger dans le système cible. Cela demande des compétences en modélisation des données mais aussi la connaissance d’un ou plusieurs outils. Citons évidemment Talend, Informatica mais aussi des nouveaux entrants comme Fivetran ou Stitch.

Visualisation de données

C’est un incontournable même si historiquement, c’est une compétence davantage attendue chez les analystes de données mais dans le même logique de maîtrise du flux de données de bout en bout, nous encourageons nos ingénieurs data à connaître au moins un des outils comme Tableau ou plus récemment Looker ou ThoughtSpot.

Spark

C’est un must-have en ingénierie des données, Spark est le framework open source désormais incontournable en raison notamment de sa très riche bibliothèque pour le traitement par lots, le streaming, les analytics, le ML, la datascience, etc. 

Connaissances en programmation

Avant SQL et un outil comme Informatica suffisait. Aujourd’hui un ingénieur data intervient dans le pipeline CI/CD et pour le maîtriser, il est nécessaire aujourd’hui d’avoir aussi des compétences en langages de programmation comme Java, Python ou encore Scala.

Expériences en développement

L’intégration et le développement continus (CI/CD) sont aujourd’hui la norme (ou presque) ainsi que le DevOps et cela vaut également pour l’ingénieur Data. Il doit avoir des connaissances en gestion de la base de code, en testing, etc. La connaissance d’outils tels que Jenkins, DataDog, Gitlab, Jira sont donc un vrai plus !

L’incontournable cloud !

Impossible aujourd’hui de passer à côté de cette compétence alors que les entreprises ont de plus en plus recours au cloud pour accéder, traiter, gérer, stocker et sécuriser leurs données. Cela permet de bénéficier de puissance de traitement et de calcul inégalé sans parler de la scalabilité. Chaque ingénieur Data se doit de connaître au moins un cloud provider comme GCP ou Azure.

Vous cherchez un Data engineer fullstack avec toutes ces compétences ? Il est surement chez Smartpoint 🤩 Vous voulez gagnez en compétences et vous investir dans de supers projets data ? Nous recrutons aussi aujourd’hui nos futurs talents !

Sources :

• Comparatif d’Airbyte entre Fivetran et Sticth : https://airbyte.com/etl-tools/fivetran-vs-stitch
• Article de Gururaj Kulkarni https://blog.devgenius.io/who-is-full-stack-data-engineer-fsde-b997ce0cafd8
• Spark https://spark.apache.org/

indétrônable Python en ingénierie de la Data ? la langage de programmation Rust pourrait bien lui voler la vedette !

Au niveau des langages de programmation, Python reste incontournable mais Rust intéresse de plus en plus d’ingénieurs data … D’ailleurs Meta le recommande désormais avec C++ et Python qui est désormais davantage cantonné aux applications de Data Science ou de Machine Learnings. Microsoft estime quant à lui que C et C++ ne sont pas assez sûrs pour les logiciels critiques et investit de plus en plus dans Rust.

Pourquoi cet engouement ?

• Rust permet de garantir un haut niveau de performance dans le traitement de larges volumes de données et offre un bien meilleur niveau de sécurité et de contrôle de qualité du code.
• Il revient moins cher que Python qui est beaucoup lourd lors de la mise en production. Python nécessite en effet plus de tests et peut générer des interruptions en production. C’est plus facile – et plus précoce – d’identifier d’éventuel bugs avec Rust !
• Il permet aussi de mieux optimiser le stockage des données et l’usage en mémoire. Il a en effet la particularité d’allouer la mémoire par un système de gestion de la propriété au moment de la compilation. Ainsi, les données inutilisées sont nettoyées automatiquement sans que personne n’ait besoin de penser à allouer ou libérer de la mémoire. Alors que les cloud providers appliquent des tarifs élevés lorsque les entreprises nécessitent plus de mémoires ou de nœuds, c’est un vrai avantage !

Certes la communauté est encore un peu réduite mais elle est très active.

Un inconvénient ? Oui, la courbe d’apprentissage est plus longue que les autres langages (partez sur deux semaines !) et comme Rust reste tout de même encore récent, vous n’avez pas encore toutes les ressources et autres bibliothèques dont vous pourriez avoir besoin (cf STACK OVERFLOW).

Trois raisons pour lesquels vous devriez sérieusement envisager de passer à Rust ?

1. Vous avez besoin de traiter de grandes quantités de données
2. Votre projet exige des performances élevées
3. Vous menez des opérations très gourmandes en CPU comme l’exécution d’algorithmes

Et trois raisons pour lesquelles vous avez bien raison d’utiliser ce bon vieux Python (il remonte à 1991)

1. Vous avez besoin d’un langage simple, flexible et facile à coder (accessible même aux débutants)
2. Votre projet consomme beaucoup d’IA et de ML
3. Vous êtes davantage dans la data science et les performances ne sont pas l’enjeu principal

Sources :

• Rust est approuvé pour une utilisation côté serveur chez Meta, Les principaux langages côté serveur supportés par Meta sont Hack, C++, Rust et Python : https://rust.developpez.com/actu/335394/Rust-est-approuve-pour-une-utilisation-cote-serveur-chez-Meta-les-principaux-langages-cote-serveur-supportes-par-Meta-sont-Hack-Cplusplus-Rust-et-Python/#:~:text=Meta%20s’est%20engag%C3%A9%20%C3%A0,adoption%20de%20Rust%20par%20Facebook.
• Comment expliquer le succès de Rust : https://www.getpro.co/expliquer-succes-rust#:~:text=Google%2C%20Microsoft%2C%20Dropbox%2C%20ou,l’utilisent%20pour%20leurs%20projets
• Pourquoi les factures des cloud providers explosent : https://www.lemondeinformatique.fr/actualites/lire-7-noirs-secrets-derriere-les-tarifs-du-cloud-79497.html
• Rust, une communauté toujours plus active et engagée ! https://www.rust-lang.org/fr/community

En introduction, rappelons qu’un data mesh (ou maillage de données) ne remplace absolument pas un data warehouse ou un data lake mais qu’en quelque sorte, il étend leurs capacités dans un contexte où les volumes, les formats, les sources, les localisations et les usages d’exploitation des données continuent à croitre de manière exponentielle.

Un Data Mesh, c’est d’abord un concept architectural qui se rapproche d’une architecture microservice dans sa conception avec des composants qui peuvent être modifiés ou mis à jour individuellement, et être utilisés par plusieurs équipes.

Un Data mesh se base sur 4 principes fondamentaux qui sont :

1. La propriété des données est orientée domaine donc les données sont décentralisées car elles sont exploitées dans chaque unité business (ou sujet restreint) qui en a besoin pour fonctionner. Chaque domaine peut donc avoir un schéma spécifique. Chaque domaine gère ses propres pipelines de données et en a la responsabilité.
2. La gouvernance des données est fédérée afin que le système soit viable dans la durée (normes d’intéropérabilité et de qualité, culture DevOps, sémantique, etc.). Sans gouvernance inter-domaines, les données se retrouvent cloisonnées et on perd l’intérêt de cette architecture en termes d’agilité et d’évolutivité.
3. Le Product Thinking ou Data as product. Chaque équipe, au sein de chaque domaine, considère que les différentes ressources de données dont elle a besoin sont les différents composants qui forment un produit. Chaque produit de données est donc créé par les équipes des domaines et consommé par des clients qui peuvent être des ingénieurs data, des data scientists, des développeurs, etc. Chaque produit de données doit donc être accessible, adressable, fiable, définissable et intéropérable.
4. Self-service via une infrastructure de données en tant que plateforme. Ainsi tous les utilisateurs peuvent s’approvisionner en données exploitables selon leurs besoins. Cela permet également de s’affranchir de la complexité et de rationaliser les processus de stockage et de traitement.

Est-ce que vous avez besoin d’un data mesh ? Est-ce que votre data warehouse suffit pour gérer et exploiter convenablement votre écosystème de données ? Est-ce qu’un data lake est plus approprié ?

Nous partageons avec vous cet article d’Actualité Informatique qui a mis en place un sondage simple qui va vous donner un score. Si vous obtenez une note supérieure à 30, il serait judicieux d’étudier cette solution ensemble !

Pour aller plus loin, voici également un article intéressant publié par Terradata.

Cette année aura été marquée par les consolidations entre les éditeurs, les rachats ou le développement de fonctionnalités pour des outils existants pour couvrir de nouvelles briques de la data stack. Détails.

Ingestion

Cette couche couvre le streaming de données et les services SaaS qui permettent de mettre en place des pipelines de données des systèmes opérationnels jusqu’au stockage. Airbyte (open source) sort du lot avec une croissance exponentielle en termes d’entreprises utilisatrices (plus de 15 000) et le lancement d’un outil de Reverse ETL (via acquisition de Grouparoo).

Datalakes

Dans cette segmentation de technologies, on part du principe qu’un datalake est un moteur d’analyse (bien que dans Databricks, cela inclut à la fois le data lake et le moteur d’analyse). Cette architecture permet d’optimiser Spark SQL pour créer un moteur analytique sur le format de table Delta. Cette même logique s’applique à Dremio sur Iceberg, ou à Snowflake supportant Iceberg comme tables externes à sa base de données.

Gestion des métadonnées

Dans cette couche, on retrouve les formats Open Table qui sont en train de devenir la norme pour prendre en charge les données structurées dans un datalake. Il y a un an, Delta Lake était un projet de Databricks avec un produit commercialisé sous le nom de Delta. Aujourd’hui, nous avons Apache Hudi commercialisé par Onehouse et Apache Iceberg commercialisé par Tabular. Ces deux sociétés ont été fondées par les créateurs de ces deux projets open-source.

Git pour la data

Le concept de Git pour les données s’installe dans la communauté des ingénieurs data. dbt encourage les analystes à utiliser les meilleures pratiques sur différentes versions de données (dev, stage et production), mais ne prend pas en charge la création et la maintenance de ces jeux de données dans les data lakes.

Les équipes DataOps cherchent de plus en plus à avoir un contrôle de version des données inter-organisations afin de mieux contrôler les différents jeux de données qui ont différentes révisions au fil du temps. Pour exemples de révisions courantes de jeux de données : le recalcul nécessaire pour les algorithmes et les modèles ML, ou de backfills provenant de systèmes opérationnels comme cela arrive souvent en BI, ou la suppression d’un sous-ensemble en raison de réglementations telles que le droit à l’oubli dans le cadre du GDPR.

Computing

Dans ce tableau, la partie virtualisation a été supprimée car elle a moins de vent en poupe ! On y retrouve les technologies de calculs distribués et les moteurs d’analyse.

La principale différence entre ces deux catégories est comment ces outils positionnement leur couche de stockage :

• Les moteurs de calcul distribué traditionnels permettent aux ingénieurs de distribuer tout ce qui est SQL ou tout autre code. Au-delà de Spark, les deux outils à suivre dans cette catégorie sont Ray et Dask. Ray est un projet open-source qui permet aux ingénieurs de mettre à l’échelle toute charge de travail Python à forte intensité de calcul, utilisée principalement pour l’apprentissage automatique. Dask est également un moteur Python distribué basé sur Pandas.
• La catégorie des moteurs d’analyse comprend tous les entrepôts de données tels que Snowflake, BigQuery, Redshift, Firebolt et toujours PostgreSQL. Elle contient également des entrepôts de données comme Databricks lakehouse, Dremio, ou Apache Pinot. Tous les moteurs d’analyse utilisent le datalake comme leur source de stockage. Il est à noter que Snowflake prend désormais en charge Apache Iceberg comme l’un des formats de table externe qui peut être lu par Snowflake directement à partir du datalake.

Orchestration

Airflow reste le plus produit open-source le plus populaire. Astronomer le talonne depuis quelques années déjà et depuis que la société a sauté dans le train du cloud, elle est maintenant en concurrence directe avec les principaux fournisseurs de cloud. À noter que Astronomer a également fait l’acquisition de Datakin qui fournit du data lineage. Que se passe t’il lorsqu’un outil d’orchestration a des capacités de lignage ? En théorie, cela pourrait permettre de construire des pipelines plus sûrs et plus résilients. En comprenant quels sont les ensembles de données qui sont impactés par des données manquantes, corrompues ou de mauvaise qualité, cela faciliterait considérablement l’analyse d’impact en liant la logique (gérée par les outils d’orchestration) et la sortie (gérée dans les outils de lignage). À suivre donc !

Observabilité

Cette catégorie est dominée par Monte Carlo qui a effectué plusieurs levées de fonds.  Ce produit ne cesse d’évoluer, offrant davantage d’intégrations notamment avec l’écosystème databricks.

Data science

Cette catégorie comprend trois grandes familles d’outils :

• Les end-to-end ML Ops. Il semble que dans les faits, aucun de ces outils ne soient vraiment « de bout en bout » du pipeline de ML mais certains sont sur la bonne voie dont Comet.
• Data centric ML. Deux nouveaux entrants à suivre (toujours selon LakeFS) en termes d’outils avec Activeloop et Graviti.
• L’ observabilité et monitoring ML, il s’agit de tous les outils orientés suivi et observabilité de la qualité des modèles. Tout comme la catégorie de l’observabilité des données, c’est une catégorie d’outils en plein développement. A noter que début de 2022, Deepchecks est devenu open source et a rapidement gagné en adoption.

Data Catalog

C’est devenu un incontournable ! On retrouve les désormais acteurs de longue date comme Alation et Collibra. À suivre Immuta qui se concentre sur le contrôle de l’accès aux données mais qui a fait une importante levée de fonds pour accélérer sa croissance.

Article source https://lakefs.io/the-state-of-data-engineering-2022/

Vous cherchez un outil d’intégration de données ? Smartpoint vous propose une rapide comparaison entre deux outils d’ETL qui ont actuellement le vent en poupe.

Les entreprises stockent leurs données dans différents endroits en interne mais aussi désormais de plus en plus dans le cloud. Pour disposer d’une vision unifiée de vos activités et être en capacité de les analyser, vous devez rassembler toutes ces data dans un entrepôt de données ou un data lake.

On utilise un ETL pour différents usages comme classiquement l’extraction, la transformation et le chargement dans des entrepôt de données. Ils sont aussi utilisés pour redresser la qualité des données afin qu’elles soient exploitables en data visualisation.

LEURS POINTS COMMUNS

Ils se connectent tous deux à de nombreuses sources de données (env 150 connecteurs pré-paramétrés chacun), ils sont RGPD et SOC 2 compliant. Les deux sont de purs ETL, ils ne transforment pas les données avant de les charger. Enfin, ils proposent tous deux un essai gratuit pendant 14 jours.

FIVETRAN

C’est un outil cloud destiné aux ingénieurs data et aux data analysts. Il est opérable avec tous les principaux entrepôts de données, bases de données… mais pas les data lakes. On peut difficilement personnaliser les connecteurs depuis le cloud … mais vous pouvez demander à l’éditeur de créer une nouvelle source de données. Cependant, vous ne pourrez pas le faire vous-même, ni modifier les sources existantes. Ainsi, si vous avez des besoins spécifiques, mieux vaut vous entourer d’un ingénieur data ! Fivetran ne transforme pas les données avant de les charger mais il permet désormais de faire à postériori via un copier-coller SQL.

STITCH

C’est également un outil dans le cloud. Il fait désormais partie de Talend Data Fabric. En termes de destinations, via l’API Rest, il est capacité de déplacer les données dans tous les principaux entrepôts de données et bases de données mais aussi les data lakes. On peut rajouter de nouvelles sources en utilisant Singer (open source) pour réaliser des scripts mais ce n’est pas encore optimal en termes qualité, il faut tester ;-). Il ne permet pas non plus de transformer les données mais, via les outils proposés par Talend, il est possible de le faire soit au sein de l’entrepôt de données, soit via des moteurs de traitement externes tels que Spark et MapReduce. Les transformations peuvent être définies en SQL, Python ou Java.

Pour aller plus loin : https://www.techrepublic.com/article/stitch-vs-fivetran/ et https://airbyte.com/etl-tools/fivetran-vs-stitch

Les technologies open source comme propriétaires sont pléthores. Certains éditeurs affirment qu’ils prennent en charge toutes les couches nécessaires, d’autres outils sont quant à eux plus spécialisés sur une brique en particulier.  Par ailleurs, vous avez aussi des actifs technologiques, des investissements passés et des spécificités propres à votre activité qui vous impose un choix best-of-breed.

Bien entendu en fonction de votre secteur d’activité, la structure de votre entreprise, votre consommation de données et l’exploitation que vous souhaitez en faire, la combinaison des outils et des technologies ne sera pas la même ! Et non, Il n’existe pas de solution « standard »…

Une plateforme de données se décompose dans les faits en différents composants essentiels ou couches : la capture des données, le stockage et le traitement, la transformation, la modélisation, la BI et les Analytics, l’observabilité et enfin la data discovery. Voici un rapide état des lieux.

1. L’ingestion des données ou process d’extraction des données (structurées ou non) à partir de multiples sources de données. Même s’il est possible de développer votre propre framework spécifique, il existe aujourd’hui pléthore de solutions reconnues comme Informatica, Talend, IBM (Datastage) Fivetran, Denodo (…) mais aussi des outils en open source comme Stitch, Airbyte, Apache Kafka (event streaming). Il est également recommandé de mettre en place une orchestration des tâches et une automatisation des flux de travail avec Apache Airflow et Dagster par exemple.
2. Le stockage et le traitement des données. Avec le move-to-the-cloud, de nombreuses alternatives au stockage on-premise existent désormais pour plus de flexibilité et d’évolutivité dans la durée avec les data Warehouses cloud natifs, les data lakes et les data lakehouses. Entre d’ailleurs Snowflake et Databricks, qui choisir, nous vous invitons à lire https://www.smartpoint.fr/choisir-snowflake-databricks/. L’architecture serverless de BigQuery (Google) est également intéressante pour la rapidité des requêtes et des traitements sans compter que Google vient de lancer BigLake pour la gouvernance et l’analyse de données en provenance de DW et de datalakes répartis sur différents clouds. Citons également Microsoft Azure, Amazon Redshift et à suivre Firebolt (SQL) pour les performances.
3. La transformation puis la modélisation des données. Oracle, IBM et SSIS (Microsoft) sont incontournables en termes de solutions proposées ainsi que l’outil leader en open source, dbt (data build tool). Dataform (qui fait partie de GCP depuis 2 ans) est également un outil intéressant pour cette étape qui permet de préparer les données pour l’étape la plus importante pour vos utilisateurs : l’analyse !
4. La BI et les analytics. Cette couche est le graal de toute Data Cloud Platform car c’est ici que les données vont prendre du sens. Les outils sont de plus en plus visuels, intuitifs et interactifs. Citons les incontournables Power BI (MS), Qlik, Tableau et Microstrategy mais aussi Looker (environnement big data / google), Mode (Datascience avec R), ThoughtSpot et Yellowfin. Les solutions sont très nombreuses et la bonne solution dépend surtout des choix que vous avez fait dans la stack technologique qui constitue votre plateforme de données … Voici le classement de Gartner https://www.gartner.com/reviews/market/analytics-business-intelligence-platforms
5. L’observabilité des données. Vous devez pouvoir compter sur des données de confiance, fiables et exploitables. Cette couche de monitoring des données vous permet de surveiller et d’être alertés sur les anomalies : la fraicheur, la manière dont elles sont distribuées, le respect du format, si elles ont été altérées, le lineage, etc. Cela vous permet également de cartographier les incidents. En termes de solutions, les acteurs sont nombreux entre ceux qui viennent des solutions de surveillance de l’infrastructure IT ou des failles de sécurité, sans parler des pure players. Citons les solutions d’IBM, Dynatrace, Splunk, DataDog, Microsoft et encore AWS.
6. La data discovery. Cette nouvelle génération d’outils vient remplacer le fameux dictionnaire ou catalogue de données qui historiquement était fait de manière manuelle donc par nature peu évolutif et qui a atteint ses limites. En effet, les flux de données se multiplient, elles sont de plus en complexes, volumétriques, en temps réel et non structurées. La data discovery permet d’explorer vos données pour trouver des dépendances, faire émerger des tendances, des modèles ou au contraire identifier des anomalies qui vont demander une exploration plus approfondie. Ces solutions sont désormais enrichies en machine learning pour une vue exhaustive et en temps réel de l’ensemble de vos actifs … alors même que vos données évoluent. Chez Smartpoint, nous utilisons les solutions de SAS Visual Analytics et de Tibco.

Pour aller plus loin :

https://towardsdatascience.com/the-quick-and-dirty-guide-to-building-your-data-platform-2f21dc4b7c94

C’est la révolution annoncée dans la collecte de données via une intégration facilitée avec un niveau de simplicité jamais atteint jusqu’alors. Les outils offrent toujours plus de vitesse dans l’accessibilité aux données via la mise en place de pipelines de données automatisés avec des outils comme le ELT (Extract Load Transform) qui charge les données dans leur format brut directement dans le système cible (environnement Big Data, Apache Hadoop, Data lake) ou le Reverse ETL, idéal pour alimenter des outils métiers opérationnels comme un CRM ou un outil financier (stockage en BDD SQL qui a l’avantage de ne stocker que les données utiles, déjà transformées).
En savoir plus sur la différence entre ETL, Reverse ETL et ELT ?
👉  Qlik : https://www.qlik.com/us/etl/etl-vs-elt
👉  Talend : https://www.talend.com/fr/resources/elt-vs-etl/
👉  Hightouchen Reverse ETL https://hightouch.io/blog/reverse-etl/ ou Census

Toujours plus de performance et de vitesse attendues au niveau des data warehouses avec notamment les entrepôts de données dans le cloud comme Snowflake, Azure Synape, Redshift de AWS, BigQuery de Google ou encore DeltaLake de Databricks. Et oui, la bonne nouvelle pour 2022 c’est que qualité et rapidité ne sont plus synonymes de coûts prohibitifs pour les entreprises !

Data Mesh (ou maillage de données) ou data as a product, le sujet HOT de 2021 qui devrait rester tout aussi hype cette année (nous en avons déjà parlé chez Smartpoint comme un des principaux nouveaux chantiers de l’année dernière) et pour cause, c’est toute l’approche de l’architecture de données qui est remise en question !

Rappelons les 4 principes du Data Mesh et son architecture décentralisée et distribuée selon sa créatrice, Zhamak Dehghani :

1. Domain driven design
2. Data as a product que l’ont peut partager à l’intérieur et à l’extérieur de l’organisation
3. Infrastructure en libre-service ou IaaS pour permettre une plus grande autonomie et une démocratisation plus large des données
4. Gouvernance dite fédérée pour équilibrer l’indépendance de chaque équipe, tout en harmonisant les normes de qualité et de contrôle au sein de l’organisation

Pour aller plus loin ? Nos data pure players vous recommandent ces articles :

🔎 Flash back sur la guerre des databases de 2021 : https://ottertune.com/blog/2021-databases-retrospective/

🔎 Data stack moderne, les tendances : https://towardsdatascience.com/trends-that-shaped-the-modern-data-stack-in-2021-4e2348fee9a3/

Data Fabric, une des dernières innovations dans l’ingénierie de la data promise à un bel avenir ! Selon Gartner, une Data Fabric permettrait de réduire les temps d’intégration et de déploiement de 30% … et la maintenance de 70%.

Concrètement, il s’agit d’une architecture qui permet de collecter des jeux de données (assets) et des databases.

La finalité est d’obtenir une vue unifiée des données dans un seul environnement, indépendamment de leur emplacement réel, de leur structure ou de leur appartenance à telle ou telle base de données.
Une data fabric permet de simplifier l’analyse des données (BI) et elle est devenue incontournable en IA et en ML. Couche unique d’accès aux données, les data fabrics permettent de faciliter le développement applicatif par API et de casser le phénomène des silos de données avec des structures et des formats différents.

Chez Smartpoint, nous privilégions les solutions de Teradata, Denodo, Informatica et Talend.

90% des 44 zettaoctets des données mondiales ont été créées ces deux dernières années ! Personne n’échappe à la data mais elle reste difficile à traiter, à gérer, à stocker et à exploiter à grande échelle.

Historiquement (cela date déjà des année 90), le stockage était géré par un SGBD connecté via des pipelines à des sources globalement statiques et des outils (réalisés sur mesures et assez simples) permettaient de les consulter. Puis les données distribuées en volume sont apparues ainsi que les outils open-source pour les traiter (Hadoop, Hive, etc.).

Amazon Web Services (AWS) a été le premier à déplacer l’ensemble de la Data Stack dans le cloud, à rendre l’infrastructure et le calcul élastiques, et à les proposer As a service.
Aujourd’hui, stocker dans le cloud est la base, les pipelines se sont transformés (de l’ETL à l’ELT) et l’orchestration a gagné en maturité. En revanche, même si la pile technologique a beaucoup évolué ces dernières années, de nombreux problèmes liés au traitement des données ne sont pas toujours pas résolus, voire de nouveaux sont apparus ! 

Excell reste toujours indétrônable dans la plupart des pipelines de données et gérer des datasets toujours plus volumétriques rajoute encore de la complexité … Et à la dimension technologique s’ajoute le facteur humain ! Les populations qui interviennent sur les données sont elles-aussi de plus en plus nombreuses et les équipes travaillent encore (trop) en silos.

Dans toutes les architectures data, on constate que de nombreux composants sont redondants. Pour répondre aux enjeux de demain, plusieurs chantiers sont lancés pour repenser la stack technologique :

• De nouvelles conceptions des référentiels de données vers un lakehouse (notamment avec Databricks) alors qu’aujourd’hui les données sont réparties dans des datalakes ou des entrepôts de données.
• Des data fabrics sur des référentiels spécialisés qui visent à extraire la valeur des relations entre les data sets ; ou des référentiels optimisés pour les séries chronologiques afin de mieux gérer les informations temps réel
• Des plateformes de BI dites « actionnables » pour réduire le temps entre l’analyse et l’action au plus près des systèmes opérationnels voir l’apparition de plateforme verticales dédiées
• Une couche de DataOps avec des plateformes qui vont gérer les catalogues de données, assurer le monitoring, la qualité, la sécurité et une utilisation toujours plus responsable des actifs de données

Et vous, quelle piste explorez-vous pour repenser l’architecture data de demain ?
Source : Thinking the modern data stack