Sicara devient Theodo Data & AI ! Nous sommes ravis de vous annoncer que Sicara évolue pour devenir l’entité Data & AI de Theodo.
Adopt
1BigQuery
BigQuery est l’entrepôt de données entièrement géré de Google Cloud. Il permet le stockage et l’analyse interactive massive de grands ensembles de données. C’est le centre névralgique analytics de la proposition. Les principales alternatives que nous utilisons sont :
• Amazon Redshift, le précurseur
• Snowflake • Azure Synapse
• Databricks
BigQuery est une solution complète et efficace, largement adoptée, mais l’offre est aussi très proche de ses principaux concurrents.
Le classement en termes de performance dépend des conditions dans lesquelles le benchmark a été effectué, alors que l’avantage est cependant du côté de BigQuery et Snowflake en nombre de fonctionnalités. Le choix dépendra d’un ensemble de critères liés aux contraintes et à l’usage : cela ne se limitera pas à l’aspect data warehouse, mais englobera tous les besoins en infrastructure. La force de BigQuery réside dans sa simplicité d’utilisation et sa flexibilité. La tarification à la demande est la tarification par défaut : le montant de la facture de compute dépend de la quantité de données parcourues dans les tables en entrée de chaque requête. La puissance allouée et le coût s’ajustent en fonction des requêtes.
C’est aussi le risque d’une facture hors de contrôle, mais Google met à disposition les outils permettant la mise en place de quotas, de dashboards de suivi et d’alerting. Pour garder la maîtrise du budget et un bon niveau de performance, il faut veiller à coupler ces mesures avec le respect de bonnes pratiques et d’optimisations. Par ailleurs, pour une meilleure prédictibilité, il est aussi possible d’opter pour la tarification par capacité, à condition que le besoin soit stabilisé et qu’une équipe puisse opérer les réservations de slots. Côté machine learning, il permet de créer, d’entraîner et d’exécuter des modèles, et BigQuery Dataframes fournit une API compatible pandas pour l’analytics et une API scikit-learn-like.
Côté BI, l’espace de travail permet d’accéder directement à des visualisations Looker Studio. Enfin, BigQuery, comme ses concurrents, évolue constamment et suit les tendances du marché, tout en s’ouvrant de plus en plus à l’extérieur, notamment avec les tables BigLakes qui permettent le support des formats Delta Lake, Iceberg et Hudi. Avec la fonctionnalité Omni il est aussi possible d’exécuter des requêtes sur des sources externes telles qu’Amazon S3 ou Azure Blob storage.
LE POINT DE VUE MDN
Très bonne technologie de data warehouse similaire à Snowflake dans l'approche. Pour l'instant limité à l'écosystème GCP. Permet de traiter les données disponibles sans gestion d'index sur les tables, mais offre des possibilités de configuration plus poussées dans certains cas. Facturation à la query (dans ce dernier cas, attention au budget) + stockage des tables + ingestion.
LE POINT DE VUE THEODO
Nous recommandons BigQuery pour sa flexibilité, la richesse des fonctionnalités et ses possibilités en matière de BI et de ML. Il est adapté pour traiter des petits comme des grands volumes de données et il s’intègre aussi parfaitement avec les autres services Google Cloud. Il peut être un bon argument pour privilégier ce cloud provider.
2Apache Iceberg
Apache Iceberg est un format de table open-source créé chez Netflix. Son objectif principal est de résoudre les problèmes de gestion des grands ensembles de données stockées sur des systèmes de fichiers distribués comme S3 ou HDFS. Iceberg a été créé pour s’affranchir des limitations de formats de table traditionnels comme Hive, facilitant les opérations complexes de modification et d'accès aux données, tout en garantissant une meilleure isolation des transactions, en raison de :
• sa compatibilité native avec le SQL pour la lecture/écriture
• sa capacité à supporter des évolutions complètes de schéma • sa capacité à gérer des datasets massifs jusqu’à l’échelle du pétaoctet
• sa granularité très fine sur les versions avec les notions de timetravel et rollback
• sa garantie de transactions ACID dans un environnement multi-utilisateurs
• son système de partitionnement et de compaction, évolutif et performant à la lecture Iceberg permet véritablement d’adopter le paradigme du datalakehouse, qui consiste à structurer son datalake pour y exploiter directement ses données.
Il peut cependant rendre les pipelines de données plus complexes, notamment pour la configuration, la gestion des partitions et la maintenance, surtout pour les équipes peu habituées à ce format. Son adoption peut nécessiter une phase d'apprentissage intense pour les organisations qui n'ont pas encore une maturité suffisante dans la gestion de datalakes.
LE POINT DE VUE MDN
Iceberg est au cœur des tendances en 2024, initialement créé chez Netflix, le format de tables open-source est en train de s’imposer en tant que standard interopérable de fichier pour gérer des tables dans les architectures data lakes. Si vous êtes en train de créer votre data lake aujourd’hui, vous devez vous y intéresser sans réfléchir.
LE POINT DE VUE THEODO
Chez Theodo nous pensons qu’Iceberg est une bonne solution pour optimiser performance et stockage en cas de forte volumétrie. Il nous semble prendre l’ascendant sur les alternatives comme Delta Lake ou Apache Hudi par sa flexibilité dans l’évolution de schéma et de partitions, mais aussi une meilleure intégration dans les architectures modernes telles que BigQuery ou Snowflake.
3Databricks Data Platform
Lors de sa création en 2013, Databricks s’est donné pour mission de démocratiser l’accès aux traitements big data. Pour cela, Databricks a développé la Databricks Data Platform, un service SaaS propriétaire s’installant au-dessus d’un cloud et rendu disponible en 2015. La plateforme a ensuite été enrichie par du machine learning avec MLFlow, un data catalog avec Unity Catalog et un orchestrateur avec Delta Live Tables. Avant Databricks, un data engineer devait configurer lui-même son cluster, Hadoop ou autre, pour utiliser Spark.
Il ne pouvait pas explorer sa donnée directement avec Spark (voir page 53) et devait passer par des outils supplémentaires comme Zeppelin. Grâce à Databricks, les data engineers peuvent mettre en place des transformations Spark sans se préoccuper de l’infrastructure. Une fois la plateforme installée et les clusters type configurés, les data engineers sont autonomes pour exécuter leurs transformations. Les Databricks Notebooks permettent également d’explorer leurs données directement sur la plateforme.
Enfin, il est possible de documenter et de contrôler les accès aux données grâce à Unity Catalog. Databricks est idéal pour les entreprises devant traiter un fort volume de données mais aussi pour permettre aux data engineers et data scientists de collaborer au mieux. C’est aussi une solution de data platform clé en main, ce qui facilite la maintenance, et s’avère judicieux lorsqu’il est complexe d’installer des nouveaux outils dans le SI existant. Néanmoins, la plateforme Databricks est très liée à Spark, et ne révèle son plein potentiel que lorsque les volumes de données traitées deviennent assez importants pour que le calcul parallélisé soit intéressant.
LE POINT DE VUE THEODO
Chez Theodo, nous recommandons Databricks Data Platform, en particulier pour traiter de fortes volumétries : c’est une technologie mature, performante et complète.
4dlt
dlt (ou Data Load Tool) est un outil open-source qui permet de créer des ingestions de données. En tant que librairie Python, DLT est composable et ne nécessite pas d’architecture lourde, un simple pip install dlt suffit. Pour charger des données, il faut initialiser la source, fournir les credentials, et paramétrer les endpoints nécessaires. Le code est ensuite exécutable directement dans l’orchestrateur de votre choix. DLT s’intègre aussi bien dans les projets analytiques qu’en IA, pour l’ingestion de données nécessaire aux agents ou modèles plus traditionnels.
Par défaut, dlt est capable de charger les données dans DuckDB, mais il fonctionne également avec toutes les destinations standards. Sa légèreté en fait un outil à moindre coût pour la construction d’EL dans des data lakes ou data warehouses. L’ingestion peut être facilement lancée dans des containers Cloud Run ou même dans une CI/CD. Avec la standardisation d’Iceberg et le support de DuckDB, DLT facilite aussi le passage entre l’environnement de travail local et les environnements de production, simplifiant ainsi un processus souvent complexe.
DLT fournit également des contrats sémantiques (data contracts) qui se superposent aux différentes sources, permettant de générer de manière programmatique tout ce qui est en aval de l’ingestion.
Le point de vue MDN
L’ingestion de données a toujours été un sujet complexe, qu’il s’agisse d’outils custom ou d’outils sur étagère. dlt apporte une structure pour définir des ingestions en combinant les avantages des solutions sur étagère tout en facilitant leur personnalisation pour chaque cas d’usage. Grâce au combo dlt + DuckDB, il est désormais possible de mettre en place des ELT avec très peu de lignes de code.
5Pub/Sub
Google Cloud Pub/Sub est un service de messagerie asynchrone qui permet d'échanger des messages entre différentes applications de manière fiable et évolutive.
Il est conçu pour connecter des composants hétérogènes, tels que des microservices, des applications web et des appareils IoT, en facilitant le transfert de messages en temps réel. Son fonctionnement repose sur un modèle de publishers et subscribers : les éditeurs publient des messages à un sujet, tandis que les abonnés s'abonnent à ce sujet pour recevoir ces messages.
Les principaux avantages de Pub/Sub incluent son évolutivité, grâce à une gestion automatique de l’échelle, ainsi que son intégration simplifiée avec d’autres services GCP (comme Google Cloud IAM pour la sécurité ou Cloud Functions et Dataflow pour le traitement des données). Entièrement managé, Pub/Sub est également plus simple à mettre en place que Kafka, son principal concurrent, souvent autogéré. Cependant, Pub/Sub offre moins de contrôle et de personnalisation, notamment en termes de gestion des flux de données : il ne prend pas en charge les schémas JSON et limite les révisions de schémas à 20.
Par ailleurs, pour de très forts volumes de données, une solution Kafka autogérée peut s’avérer plus économique.
Le point de vue Theodo
Nous recommandons d’adopter Pub/Sub si votre entreprise est déjà intégrée dans l'écosystème Google Cloud ou si vous recherchez une solution managée pour réduire la charge opérationnelle liée à la gestion de l'infrastructure de messagerie. Google Cloud Pub/Sub est une option robuste et performante pour les organisations souhaitant mettre en place une infrastructure de messagerie fiable et évolutive.
Le point de vue MDN
Cette technologie de queuing auto-managée par Google est très bien intégrée avec tout l'écosystème GCP. Plus simple qu’un Kafka, mais avec beaucoup moins d’options paramétrables (comme le nombre d’ack au niveau des replicas), elle est géodistribuée sur plusieurs régions GCP pour éviter les pertes de messages. Toutefois, il convient de prévoir des coûts additionnels liés à l’egress/ingress et à la réplication des messages entre régions.
6Snowflake Data Warehouse
Créée en 2014, Snowflake est une solution propriétaire de Data Warehousing conçue pour le stockage, la gestion et l’analyse de grands volumes de données et fut, avec BigQuery, parmi les premiers à découpler les ressources de calcul et de stockage. Offrant la flexibilité de mettre à l'échelle ces ressources de manière indépendante, elle améliore ainsi les performances et l'optimisation des coûts. Les forces principales de Snowflake sont la performance de requêtes sur données structurées et la gestion de nombreux utilisateurs. En effet, avec son système de micro-partitionnement unique et le parallélisme qu’il permet, Snowflake peut rafraîchir un dashboard en quelques secondes sur de la donnée de plusieurs centaines de gigaoctets. Des outils de gestion d’accès à la donnée par groupe d’utilisateurs pouvant aller jusqu’à la colonne et la ligne permettent de gérer aisément de nombreux utilisateurs avec différents niveaux d’accès. On peut également citer la facilité de prise en main de l’interface utilisateur, la possibilité d’explorer des données avec des notebooks Python, et le fait qu’il puisse tourner sur les trois grands Cloud Providers de manière agnostique.
Néanmoins, Snowflake possède quelques limitations. Tout d’abord, la plateforme est peu adaptée au streaming, car son architecture est optimisée pour le traitement analytique plutôt que pour les charges de travail transactionnelles en temps réel. Ensuite, malgré un modèle de facturation transparent, les coûts de la solution peuvent rapidement devenir conséquents par rapport à ses concurrents.
Le point de vue Theodo
Aujourd’hui, nous conseillons l’utilisation de Snowflake comme solution de Data Warehouse facile à prendre en main, lorsque les volumes de données sont importants, qu’il existe de nombreux utilisateurs analytiques potentiels. C’est aussi la bonne solution pour ne pas être spécifiquement lié à un cloud provider.
Le point de vue MDN
Snowflake est un data warehouse particulièrement performant. Grâce à des concepts comme le partitionnement et les clones, l’utilisation et le partage de gros volumes de données sont facilités. Il est possible d’interroger des données issues de fichiers plats ou bases de données comme PostgreSQL ou MySQL. Je recommande Snowflake comme point central d’accès à la donnée dans un contexte analytique.
Trial
7DuckDB
Créé en 2019 à Amsterdam, DuckDB peut être utilisé comme moteur analytique mono-nœud, pouvant remplacer Spark, ainsi que comme base de données mutable orientée colonne. Compatible avec les principaux langages (Python, Java, R, Node, ODBC) et utilisable en backend ou frontend via WASM, c’est une technologie open-source qui est non seulement une base de données, mais aussi un outil de calcul. DuckDB est devenu mature avec sa version 1.0, apportant des innovations qui sont en train de changer l’écosystème data. La technologie s’inscrit dans la mouvance du “big data is dead” : la plupart des jeux de données ne sont pas suffisamment larges pour justifier des technologies de calcul distribué. DuckDB enlève la nécessité d’une communication client <> serveur, qui selon les créateurs est une des raisons de la latence des bases de données traditionnelles, et ses performances sont alléchantes. Couplé à la puissance des ordinateurs personnels récents, cela signifie que beaucoup de traitements peuvent dès aujourd’hui se faire en local plutôt que dans le cloud.
Il est important de noter la limitation principale de DuckDB : c'est une technologie single node (sur une seule machine) et mono-connexion (un seul utilisateur à la fois peut se connecter).
Le point de vue MDN
DuckDB est ma technologie favorite des deux dernières années : là où la philosophie “modern data stack” pousse à exécuter du SQL sur une connexion cloud, avec DuckDB tout tourne en local de manière simple et performante. DuckDB vient avec des limitations, mais pourra vous permettre de réduire vos coûts de traitement.
8Star Schema
Le star schema est une méthode de modélisation de données couramment utilisée dans les entrepôts de données et les systèmes de business intelligence (BI). Ce modèle simple organise les données autour d'une table centrale de faits, reliée à des tables de dimensions. Cela facilite la création de requêtes SQL efficaces et permet une analyse rapide via des outils BI optimisés pour requêter rapidement (et donc rafraîchir) des données qui utilisent le star schema, comme PowerBI. Le star schema est idéal pour les systèmes décisionnels où la simplicité des requêtes et l'efficacité des traitements sont primordiaux. Les requêtes sont plus faciles à écrire et à exécuter, ce qui réduit la complexité et les risques d'erreurs dans le reporting.
Cependant, le star schema présente des limitations. L’absence de dénormalisation systématique peut entraîner une redondance des données dans les tables de dimensions et donc un plus grand volume à stocker. De plus, les évolutions des règles métiers peuvent être difficiles à implémenter, nécessitant des ajustements complexes des tables de faits et de dimensions.
Parmi les alternatives au star schema :
- Data Vault : plus flexible pour gérer les changements fréquents dans les règles métiers.
- One Big Table (cf blip One Big Table) : simplifie l'accès aux données mais peut aussi entraîner beaucoup de complexité dans les traitements de maintenance lors de changements dans les données.
Le point de vue Theodo
Nous recommandons le star schema et les modèles dimensionnels en général pour modéliser des données complexes à l’échelle. Ils sont flexibles et éprouvés. Mais d’autres modèles peuvent être privilégiés selon les besoins, comme le Data Vault ou One Big Table pour l'analyse de grandes quantités de données IoT sans dimensions claires.
9Airbyte
Créé en 2020, Airbyte est une solution permettant d’ingérer et de charger des données dans une plateforme data, facilitant ainsi le déplacement des données en standardisant les sources et les destinations. Il n’y a pas de connecteurs end-to-end (par exemple un connecteur GCS → BigQuery), mais plutôt une liste de connecteurs source et une autre de connecteurs destination, n’importe quelle source pouvant être mise en face de n’importe quelle destination. Cette flexibilité est permise par le protocole Airbyte, qui définit strictement le contrat que doivent remplir les sources et les destinations.
La principale différence avec Fivetran, acteur historique de l’ingestion par connecteurs modulaires, réside dans le fonctionnement open-source : plus de 350 connecteurs sont mis à disposition, en majorité développés par la communauté. Le développement de connecteurs custom est grandement simplifié par l’existence de ce protocole, ainsi que par la mise à disposition de SDKs. Ainsi, on peut assez facilement créer un connecteur source adapté à une API spécifique, par exemple. Il sera alors compatible avec l’ensemble des connecteurs destination existants.
Airbyte est disponible sous différentes formes, adaptées à différents cas d’usage :
- Airbyte OSS (open-source) : ne comporte aucun coût de licence et permet une grande flexibilité dans la manière d’installer et de configurer votre instance, mais impose de gérer soi-même le déploiement et l’hébergement. Ceux-ci sont relativement complexes, car ils nécessitent de gérer séparément la machine exécutant Airbyte et la base de données associée.
- Airbyte Cloud : version managée offrant sensiblement les mêmes fonctionnalités, avec en plus l’accès à un support technique, mais sans les contraintes liées à la gestion d’une instance on-premise. Le coût est calculé en fonction du volume de données déplacé et du nombre de lignes traitées.
- PyAirbyte : un package Python donnant accès à la majorité des connecteurs source d’Airbyte directement au sein de scripts, en se passant des fonctionnalités d’orchestration proposées par les autres solutions. PyAirbyte sert de point d’entrée pour le traitement des données, et pas de solution bout en bout comme Airbyte OSS ou Airbyte Cloud. On peut donc l’utiliser conjointement avec un orchestrateur, comme Airflow.
Malgré ses atouts, Airbyte n’est pas dénué de défauts : le protocole a le mérite d’être généralisé, mais impose un transfert séquentiel de l’information, parfois insuffisamment efficace sur des ingestions volumineuses. Airbyte peut être déployé et configuré automatiquement, mais cela reste expérimental, en particulier pour les connecteurs custom.
Le point de vue Theodo
Nous vous recommandons d’essayer Airbyte, que ce soit en cloud ou en managé, si vous n’ingérez pas de forts volumes de données : même si la technologie présente certaines faiblesses, elle est robuste et bien conçue, et profite d’une communauté dynamique qui assure une évolution rapide du produit, ainsi qu’un support précieux en cas de difficultés.
10One Big Table
La modélisation de données One Big Table (OBT) consiste à stocker toutes les données pertinentes dans une seule grande table dénormalisée, plutôt que réparties dans plusieurs, ce qui simplifie les modèles de données et facilite leur exploitation. Nous utilisons OBT pour simplifier l'accès aux données, ce qui est bénéfique pour les analyses rapides ou pour les équipes moins techniques, n’ayant pas à gérer la complexité des jointures ou des relations entre tables.
Avec l'avènement des LLMs (Large Language Models), nous avons recours à l’approche OBT pour traiter efficacement de vastes ensembles de données, facilitant notamment le Text-to-SQL (voir page 68) en simplifiant les requêtes à créer.
Les redondances causées par la dé normalisation ne sont pas un problème majeur avec l’utilisation de bases orientées colonnes comme Snowflake et BigQuery, et le stockage peu coûteux permet de se concentrer sur la réduction du coût de calcul (compute).
Cependant, l’inconvénient en termes de maintenance réside dans la gestion d’une table unique et massive, ce qui peut devenir complexe, surtout lorsque les données évoluent fréquemment ou que de nouvelles sources sont ajoutées. La dé normalisation peut également entraîner des incohérences si elle n'est pas gérée avec soin, nécessitant la mise en place de processus robustes pour assurer la cohérence des données.
Le point de vue Theodo
Nous recommandons de bien considérer l'impact à long terme : les défis liés à la maintenance et à la qualité des données peuvent devenir complexes. One Big Table peut être combiné avec des structures normalisées en fonction des cas d'utilisation. Cela permet de bénéficier de la simplicité d'accès tout en conservant la flexibilité et la maintenabilité offertes par une base de données relationnelle traditionnelle.
Le point de vue MDN
“One Big Table” simplifie l’accès à la donnée pour rendre les équipes métiers autonomes. C’est une solution essentielle pour améliorer l’adoption et l’usage de la couche sémantique (gold layer). En choisissant de faire des OBTs, on évite les jointures et on calcule les indicateurs à la granularité la plus fine nécessaire à leur consommation.
Hold
11Standalone Apache Parquet
Introduit en 2013, Apache Parquet est un format de fichier open source orienté colonnes, devenu standard pour le stockage et la gestion des données à grande échelle. Conçu pour optimiser les performances de lecture et d'écriture sur de grands ensembles de données tout en réduisant l'espace de stockage nécessaire, il a supplanté en data engineering les formats de fichiers plats comme le CSV.
Parquet présente de nombreux avantages :
- Une compression significative des fichiers (facteur dix par rapport aux CSV),
- Des performances élevées : 30x plus rapide que les CSV en lecture/écriture de requêtes analytiques,
- La gestion des types de données complexes, notamment les structures imbriquées (listes, dictionnaires…),
- Ainsi qu’une bonne intégration avec les principaux cloud providers et une compatibilité étendue avec de nombreux outils open source.
Toutefois, Parquet n'est pas idéal pour les écritures fréquentes ou le streaming de données en temps réel, où un format orienté lignes comme Avro est plus judicieux.
On préfèrera également s’appuyer sur des formats de tables comme Delta Lake ou Apache Iceberg pour garantir une meilleure gouvernance des données, une meilleure gestion des changements de structure des tables et l'intégrité des données en cas d'écritures concurrentes.
Le point de vue Theodo
Parquet reste une bonne technologie qui présente des avantages pour les workloads analytiques en raison de ses performances et de l'optimisation de son stockage. Notre positionnement en hold vise à marquer notre recommandation d’adopter des surcouches comme Iceberg pour bénéficier de capacités transactionnelles et de l’évolutivité des données.
Le point de vue MDN
Parquet est devenu le format de référence pour faire de l’analytique. Compressé, orienté colonne, avec une compatibilité étendue, il y a énormément de points positifs à utiliser Apache Parquet en 2024. Il est à préférer aux formats plats comme le CSV ou le JSON. Incontournable pour économiser de l’argent et gagner en performance. Le seul désavantage est que c’est moins pratique à ouvrir dans une interface graphique (sauf à utiliser DuckDB).