La lame de fond Cloud touche tous les domaines et il n’y a pas de raison que le Data Warehouse y échappe.

Les Data Warehouses classiques ne sont pas bien adaptés pour le Cloud, c’est pourquoi des solutions spécifiques ont vu le jour.

Les principaux acteurs du Cloud public proposent chacun leur propre solution :

• AWS Redshift
• Azure SQL Data Warehouse
• Google BigQuery

Dans cet article nous allons comparer deux des systèmes les plus en vue du moment : Amazon Redshift et Snowflake.

Avantages du Cloud par rapport à un SI On-premise :

• Pas d’achat de matériel,
• Rapidité de mise en œuvre,
• Scalabilité quasi-infinie,
• Maintenance simplifiée,
• Coût maîtrisé.

Ce dernier point est crucial car le coût d’une infrastructure est souvent caché (matériel, humain, licence, …).

En plus des avantages vus précédemment, les services entièrement gérés vous facilitent la gestion des serveurs et des mises à jour logiciels. Leur version la plus aboutie, les services serverless, vous masquent complètement les serveurs et les logiciels utilisés et vous permettent d’obtenir une facturation à la seconde et vous ne payez que ce que vous consommez.

Définition d’un Data Warehouse

Afin de mieux comparer les solutions, il faut d’abord en comprendre le but.

Un Data Warehouse va regrouper une partie (le plus étant le mieux) des données métiers d’une entreprise, fournir les outils capables de les analyser et de construire des rapports, afin de favoriser la prise de décisions dans l’entreprise.

Un Data Warehouse est assez proche d’une base de données relationnelles classiques, mais là où un SGBDR va favoriser les transactions (OLTP), le Data Warehouse va favoriser les traitements d’analyse de données (OLAP).

Il y a donc trois éléments essentiels :

1. La capacité à ingérer des données,
2. La capacité à stocker des données,
3. La capacité à analyser des données.

Il permet de regrouper à un seul endroit les données et de ne pas perturber les bases opérationnelles avec des traitements lourds et complexes.

Différence avec un Data Lake ?

La confusion entre les deux est courante au point de retrouver les deux termes dans une même conversation, un même document.

Là où un Data Lake va stocker les données au format brut, le Data Warehouse va stocker des données structurées, agrégées et souvent regroupées par usage.

Les utilisateurs diffèrent aussi : Data Scientist, Data Engineer contre statisticien, actuaire, spécialiste métier.

Un Data Warehouse va être souvent couplé à un outil de transformation de données appelé ETL (Extract Transform Load) afin d’appliquer un schéma aux données avant leur insertion (schema-on-write).

A l’inverse, un Datalake ingère des données bruts et le schéma est appliqué à la lecture des données (schema-on-read).

Les Data Warehouse vont souvent proposer une modélisation en étoile ou en flocons (snowflakes), qui sont en partie dénormalisés.

Les Data Lake, car ils stockent les données au format brut et tels que fournis par la source, sont très souvent dénormalisés.

Sans entrer dans le détail, le modèle en étoile permet de réduire le nombre de jointures lors de l’interrogation en plaçant au centre du modèle les données variables (les faits) et tout autour les référentiels (les dimensions) ce qui le rend particulièrement optimisé pour les requêtes d'analyse.

Le modèle en flocons est une variante de la modélisation en étoile qui introduit la notion de hiérarchies de dimensions, de telle manière à avoir moins de lignes par dimensions.

C’est évidemment la théorie et la frontière est beaucoup plus perméable en réalité.

Présentation d’Amazon Redshift

Amazon Redshift a été annoncé en décembre 2012 et réellement disponible début 2013. La technologie s’appuie sur le produit ParAccel dont Amazon était un investisseur important.

Techniquement Amazon Redshift est basé sur PostgreSQL version 8 mais les différences sont nombreuses et il faut surtout retenir la compatibilité SQL et de certains outils.

Stockage

Le stockage d’Amazon Redshift diffère de manière importante par rapport à PostgreSQL dont il s’inspire. Redshift est une base de données orientée colonnes et par conséquent les données sont découpées en slices qui représentent un nombre de lignes d’une colonne plutôt que par lignes d’une table.

Les données peuvent être compressées et réparties sur l’ensemble des nœuds du cluster.

Les algorithmes de répartition des données au sein des nœuds proposés sont :

1. Even (Round Robin) : les données sont réparties sans affinité,
2. All : tous les nœuds portent l’ensemble des données,
3. Key : la clé de la ligne détermine le nœud de stockage.
4. Auto : Redshift détermine la meilleure répartition en fonction du type de données et de la volumétrie.

De plus pour chaque table, il est possible de définir une clé de tri (Sort Key).

Par défaut les données ne sont pas compressées, mais il est possible de définir un algorithme pour chaque colonne.

Les formats supportés sont nombreux car beaucoup sont spécialisés dans un certain type de donnée. On peut citer : Binaire, LZO, Mostlyn, …

Cf. https://docs.aws.amazon.com/redshift/latest/dg/c_Compression_encodings.html

À noter que même activée, la compression n’est pas systématique et Redshift analyse la volumétrie afin de déterminer si la compression est pertinente (ratio entre la consommation CPU, le temps nécessaire à la compression et le gain de stockage).

Enfin l’espace de stockage est découpé en slices. Le nombre de slices est figé et dépend de la classe d’instance des nœuds du cluster.

Par exemple un nœud de type ds2.8xlarge disposera de 16 slices.

De manière globale la taille des slices est la suivante :

• 1 To pour les nœuds de type Dense Storage,
• 80 Go pour les nœuds de type Dense Compute.

Capacité maximale de stockage :

• 128 nœuds,
• 10 clusters,
• 2,56 To par nœud,

soit 3,2 Po au total.

Pour faire évoluer la capacité de stockage ou de traitement de votre cluster, vous devez invariablement rajouter des nœuds. On ne peut pas faire évoluer une capacité sans l’autre.

Format des données supportées

Nativement Redshift ne supporte que les données structurées, dont le schéma est défini par SQL et stockées dans un format propriétaire.

Il est toutefois possible de pointer vers des données stockées dans S3 au format JSON et Ion.

Ion est une extension du format JSON développée par Amazon

Modélisation

Même si Redshift est une base orientée colonnes, cela ne transparaît pas dans la modélisation qui reste comparable à PostgreSQL.

Des ordres SQL (syntaxe PostgreSQL) permettent de créer des tables, des clés étrangères, des vues.

Métadonnées

Tout comme PostgreSQL les métadonnées sont stockées dans des tables systèmes (catalogue).

Les tables catalogue système ont un préfixe PG et sont requêtables.

En cas de données externes (Spectrum par exemple) la table pg_external_schema pointe vers les schémas sources (Athena ou Hive).

Traitements

Analyse des données

Les opérations sur les données sont exprimées en ordres SQL.

Redshift parallélise les traitements en utilisant le MPP (Massively Parallel Processing) à l’exception de certaines requêtes portant sur des métadonnées qui sont exécutées par un seul nœud : le leader.

Redshift va favoriser la co-localisation des traitements et des données et c’est pourquoi le choix d’une clé de distribution performante est très important.

Import de données

L’import de données en masse (commande COPY) est possible depuis :

• S3,
• DynamoDB,
• EMR,
• Tunnel SSH pour un hôte distant.

Les formats suivants sont supportés : AVRO, CSV, JSON, Parquet, ORC et TXT.

L’import de données utilise l’architecture hautement parallèle de Redshift afin de multiplier les imports concurrents en se basant sur la clé de distribution et le nombre de fichiers en entrée.

Export de données

L’export de données (commande UNLOAD) est possible vers S3 avec ou sans chiffrement des données.

Une requête SQL permet de sélectionner les données à exporter.

Les formats de sortie sont CSV ou TSV.

Un fichier ne peut pas excéder 6,2 Go ou une valeur définie par l’utilisateur.

L’export de données utilise l’architecture hautement parallèle de Redshift afin de multiplier les exports concurrents en se basant sur le nombre de slices.

Redshift Spectrum

Redshift Spectrum, annoncé en avril 2017, permet de requêter des données externes, c’est à dire stockées dans S3, sans avoir à les charger dans des tables Redshift.

Le même langage SQL et les mêmes drivers de connexion seront utilisés, ce qui permet d’utiliser les mêmes outils pour consommer les données qu’elles soient stockées dans tables Redshift ou à l’extérieur.

Redshift Spectrum est excellent moyen pour les requêtes ponctuelles de forte volumétrie qui nécessiteraient de sur-dimensionner le cluster.

Pour décrire les données externes, on peut s’appuyer le data catalog d’AWS Glue, celui d’Amazon Athena ou un Hive Metastore.

Interfaçage

Données

L’accès aux données se fait soit avec un client compatible PostgreSQL, soit au travers des drivers JDBC et ODBC.

L’accès peut donc se faire grâce :

• à un éditeur SQL,
• au client psql,
• à une application (Java, .Net, Python, NodeJS, GO),
• à des frameworks compatibles (Spark, Flink, …),
• aux outils de BI ou d’analytiques.

Administration

En ce qui concerne le management, Redshift est accessible avec les outils suivants :

• AWS Cli : outils d’administration en ligne de commande,
• Redshift API : Acces REST pour l’administration d’un cluster Redshift,
• AWS SDK : SDK (Java et Python),
• outil pgAdmin.

Sauvegarde et restauration

La sauvegarde des données peut être automatisée :

• Toutes les 8 heures,
• Tous les 5 Go de données.

Par défaut la période de rétention est courte : une journée.

Ces snapshots sont conservés dans S3.

La restauration est simple puisqu’il suffit de sélectionner un snapshot à restaurer.

Architecture

Un cluster Amazon Redshift est constitué de deux types de nœuds.

Un nœud principal (Leader) :

• Sert uniquement de point d'accès SQL,
• Stocke les métadonnées,
• Optimise le plan d'exécution,
• Coordonne le bon déroulement des requêtes.

Des noeuds de traitement (Compute) :

• Stockage local des données au format colonne
• Exécution distribuées :
• Des requêtes,
• Des imports/exports,
• Des sauvegardes/restaurations,
• Des redimensionnements (redistribution des données).

Un cluster Redshift peut être constitué d’un seul nœud qui jouera alors les deux rôles.

Si plusieurs noeuds sont utilisés, le leader n’est pas facturé.

Elasticité

En novembre 2018, AWS a annoncé la fonctionnalité Elastic Resize. Elle permet d’ajouter ou supprimer des nœuds en quelques minutes.

Lorsqu’une opération d’Elastic Resize est lancée :

• un snapshot est créé,
• le cluster redistribue ses metadata sur tous les nœuds, ce qui le rend inaccessible pendant quelques minutes,
• puis les sessions sont reconnectées,
• et les données sont finalement redistribuées sur tous les nœuds en tâche de fond.

Présentation Snowflake

Snowflake a été créé en 2012 par deux ingénieurs Français qui étaient Lead Architects chez Oracle Teradata. Il a été développé pendant 3 ans puis mis sur le marché en 2015 uniquement sur AWS dans un premier temps (lancement sur Azure en janvier 2019).

Ils avaient sans doute compris avant les autres l’apport du Cloud pour les plateformes analytiques :

1. Un nombre quasi-infini de ressources,
2. Élasticité sans pareil grâce à la séparation du stockage et du compute, et ce en leur évitant d'avoir à provisionner et administrer des machines,
3. Une amélioration continue du produit (Snowflake revendique une version par semaine).

Snowflake a ouvert une filiale française en novembre 2017.

Région Européennes proposées :

• AWS : Francfort & Dublin,
• Azure : Pays-Bas.

Stockage

Snowflake n’intègre pas de stockage et s’appuie donc sur le datastore natif du fournisseur Cloud (S3, Azure Blob Storage).

De plus, il utilise des micro-partitions pour des raisons de disponibilité, de performances et de sécurité.

La taille de ces micro-partitions est comprise entre 50 et 500 Mo avant compression.

Tout comme Redshift, Snowflake est une base de données orientée colonnes. Les données sont donc regroupées par colonnes dans chaque micro-partition.

Les données sont automatiquement compressées par Snowflake qui détermine l’algorithme le plus adapté en fonction du type et de la volumétrie. Le facteur de compression varie de 3 à 5.

La jonction entre le stockage et les services Snowflake (traitements, métadonnées, …) se fait grâce à un service nommé Snowpipe.

Snowpipe est un service REST qui permet à Snowflake d’avertir de l’arrivée de nouvelles données.

La capacité de stockage est infinie car basée sur S3/Azure (mais 128 * 10 nœuds de traitement).

Format des données supportées

Les formats suivants sont nativement supportés : JSON, AVRO ou XML.

Modélisation

Tout comme Redshift, Snowflake est une base orientée colonnes et la modélisation se fait à travers la création de bases, de tables et de vues.

Métadonnées

À l’image des bases de données relationnelles, les méta-données sont stockées dans des tables et des vues systèmes.

Ces objets sont basés sur la norme SQL-92 Information Schema sans être toutefois entièrement compatibles.

Ces informations sont communes à l’ensemble des entrepôts virtuels et sont requêtables comme n’importe quelle donnée.

Traitement

Analyse des données

Les opérations sur les données sont exprimées en ordres SQL.

Snowflake parallélise les traitements en utilisant l’architecture MPP.

Snowflake dépend d’un stockage commun distant et l’affectation (pour traitement) des données au sein des nœuds d’un cluster utilise les micro-partitions.

Les micro-partitions sont créées à l’aide de la clé de partition (cluster keys) définie au moment de la création de la table.

La clé de partition est un élément fondamentale du bon fonctionnement de Snowflake et doit faire l’objet d’une attention particulière afin de favoriser :

• l’homogénéité de la répartition des données,
• la co-localisation des données stockées dans différentes tables mais liées d’un point de vue métier.

Import de données

L’import de données en masse (commande COPY INTO ou Snowpipe) est possible depuis :

• S3,
• Azure,
• fichiers d’un hôte distant (en passant par des stages).

Un traitement Snowpipe est lancé depuis une interface REST et peut s’intégrer à AWS Lambda.

Les formats suivants sont supportés : AVRO, CSV, TSV, JSON, Parquet, ORC et XML.

Les fichiers peuvent être dans une archive GZIP (mais un seul schéma de table par archive pour le moment).

L’import de données utilise l’architecture hautement parallèle de Snowflake afin de multiplier les imports concurrents en se basant sur la clé de distribution et le nombre de fichier en entrée.

Contrairement à Redshift, il est possible de transformer les données pendant le chargement.

Export de données

Il est possible d'exporter le contenu d'une ou plusieurs tables Snowflake en utilisant la commande "COPY INTO", c’est la même commande que pour l’import. L’origine et la destination étant inversées.

La destination peut être :

• AWS S3,
• Azure Blob Storage,
• Table de Staging Snowflake.

Filtrage des données : il est possible d'indiquer un ordre SQL afin de filtrer les données à exporter ou de sélectionner le contenu de plusieurs tables.

Taille et nombre de fichiers d’export

il est possible d'exporter les données vers un fichier unique ou bien plusieurs (par défaut) et dans ce cas le nombre de fichiers est déterminé par la valeur MAX_FILE_SIZE.

Time Travel

Derrière ce nom se cache une fonctionnalité intéressante de Snowflake : la possibilité d’accéder à toutes les données modifiées ou supprimées pendant un certain délai.

Pendant ce temps les données sont toujours accessibles avec possibilité de requête ou de jointure.

Il existe trois critères de sélection :

• TIMESTAMP : date et heure,
• OFFSET : nombre de secondes jusqu’à la date courante,
• STATEMENT : identifiant unique d’une opération sur la base.

Il est aussi possible d’annuler une suppression (commande UNDROP) d’une table, d’un schéma, d’une base de données. Cette commande est quasi instantanée car l’opération est logique et non physique. C’est la commande dont tous les DBA ont rêvés.

Interfaçage

Données

L’accès aux données se fait de manière classique au travers des drivers JDBC et ODBC.

L’accès peut donc se faire grâce :

• à l’interface web de Snowflake,
• une CLI (c.f. paragraphe ci-dessous),
• à un éditeur SQL,
• à une application (Java, .Net, Python, NodeJS, GO),
• à des frameworks compatibles (Spark, H2o, …),
• aux outils de BI ou d’analytiques.

Administration

SnowSQL est le client officiel de Snowflake, il permet de soumettre des ordres SQL (y compris DDL) et de charger/décharger les données.

Il existe le client web officiel qui permet l’accès aux données mais aussi le management des clusters et des accès.

Sauvegarde et restauration

En ce qui concerne la sauvegarde et la restauration, l’approche de Snowflake est originale et liée à leur architecture.

Étant donné que le stockage est disjoint du système et que la fonctionnalité de Time Travel offre la possibilité de restaurer des données effacées ou corrompues, il n’y a pas de sauvegarde au sens strict du terme mais une offre appelée Fail-Safe.

Il s’agit d’une période (entre 1 jour par défaut et 90 pour la souscription Enterprise) durant laquelle les données sont conservées après leur suppression/modification.

Cette période n’est pas modifiable et seul le support de Snowflake peut restaurer les anciennes données.

Ces données sont archivées par Snowflake dans plusieurs Data Center afin d’en assurer la pérennité.

En plus de dispenser les clients de cette gestion des sauvegardes tout en offrant le même niveau de service, un autre avantage est le coût de stockage qui n’est pas supporté par les clients.

Architecture

Snowflake possède trois composants principaux :

1. Stockage : système externe de collecte des données dans le Cloud (S3/Azure Blob Storage),
2. Traitements : ensemble de clusters manipulant les données,
3. Services : fonctionnalités communes (sécurité, transactions, métadonnées, …).

Pour pouvoir accéder aux données, il faut d’abord créer des entrepôts virtuels (Virtual Warehouses) qui correspondent à des nœuds de traitements et auxquels on donne accès à des données stockées sur un système de stockage.

Ces entrepôts virtuels peuvent servir à isoler certains types de traitements ou à gérer le multi-tenant.

Il existe un certain nombre de services techniques communs à tous les entrepôts virtuels.

Chaque “virtual warehouses” possède son propre cache qui permet :

• d’améliorer les performances
• d’isoler les données entre les entrepôts virtuels

Le service de métadonnées est partagé entre tous les entrepôts virtuels, ce qui permet à un nouvel entrepôt virtuel de connaître et donc d’utiliser très rapidement les données déjà connues.

L’édition Virtual Private Snowflake (VPS), qui est la plus sécurisée dans l’offre, ne partage aucune infrastructure avec d’autres clients et dispose donc de ses propres instances pour les métadonnées.

Techniquement les métadonnées sont stockées dans une base clé/valeur (foundationDB).

Concrètement, tous les serveurs sont hébergés dans le même provider que le système de stockage. C’est à dire soit AWS soit Azure.

Comparaison des deux solutions

Écosystèmes

Une solution n’a de sens que si elle s’intègre au SI et aux outils de la société.

Redshift

Redshift s’intègre évidemment avec les autres solutions de l’écosystème AWS :

Kinesis Data Firehose, SageMaker, EMR, Glue, DynamoDB, Athena, Database Migration Service (DMS), Schema Conversion Tools (SCT), CloudWatch, etc.

Intégration de données : Talend, Matillion, Attunity, Snaplogic, …

Décisionnel : Alteryx, Microstrategy, QlikView, Tableau, …

Snowflake

Snowflake ne dispose évidemment pas d’un écosystème équivalent. On peut y souscrire directement auprès de l’éditeur ou sur les plateformes AWS et Azure au travers du marketplace.

Même l’intégration avec les solutions natives de stockage des provider n’offre pas une intégration à minima avec certains outils puisque le format de stockage utilisé par Snowflake est propriétaire.

Toutefois Snowflake s'intègre avec IBM Cognos, Informatica, Matillion, Power BI, Qlik, Apache Spark, Tableau, MicroStrategy et quelques autres.

Support SQL

Les deux solutions clament un support important de la norme ANSI-SQL et une conformité ACID.

Toutefois Snowflake offre un support un peu plus étendu que Redshift.

Redshift

Redshift supporte les notions suivantes :

• Transactions
• Database, Schema, Table, Vue, ...
• Fonction utilisateur et procédure stockée
• Numéro de séquence automatique (identity)
• Librairies (module Python utilisé par les fonctions utilisateurs)
• Utilisateurs et groupe d'utilisateurs

Les contraintes d'unicité, de clé primaire et de clé étrangère existent et peuvent caractériser une donnée mais ont un but informatif uniquement.

Par contre les contraintes de colonne NOT NULL sont supportées et appliquées.

Parmi les notions absentes, on peut noter le non-support de trigger et d’index.

Enfin parmi les types notables SQL non supportés (notamment par rapport à PostgreSQL), il y a les types suivants :

• BLOB (Bytea),
• INTERVAL,
• ENUM,
• JSON,
• IP,
• MONEY,
• XML.

Liste complète : https://docs.aws.amazon.com/fr_fr/redshift/latest/dg/c_Supported_data_types.html et https://docs.aws.amazon.com/fr_fr/redshift/latest/dg/c_unsupported-postgresql-datatypes.html

Timestamp (Timezone) : La gestion des fuseaux horaires est classique dans Redshift. Soit un timestamp à un fuseau horaire défini, soit il n’en a pas et dans ce cas c’est UTC qui est utilisé par défaut.

Snowflake

Snowflake supporte les notions suivantes :

• Transactions,
• Tables,
• Views,
• Schémas,
• Stages,
• Séquences.

Les contraintes d'unicité, de clé primaire et de clé étrangère existent et peuvent caractériser une colonne mais ont un but informatif uniquement.

Clonage : il est possible de cloner une table, un schéma ou même une base entière. L’énorme avantage de Snowflake tient encore à son architecture particulière. Cette copie se produisant sans copie de données, une table étant en effet un pointeur vers des données S3 ou Azure.

La copie est donc instantanée et peut même pointer vers une version historisée des données.

C’est donc idéal pour monter un environnement de test rapidement et avec un coût maîtrisé (passé le clonage, les tables de références et les tables clonées sont indépendantes et des données peuvent être ajoutées).

Variant : Ce type est utilisé pour stocker des données semi-structurées dans Snowflake.

Par exemple pour stocker une donnée au format JSON. L’avantage par rapport à une simple chaine de caractère est la possibilité de faire du ‘schema-on read’.

Au moment du chargement d’un type Variant, Snowflake va analyser sa structure et tenter de découvrir automatiquement sa structure.

Stage : Les stages sont en général associés aux phases de chargement/déchargement de données.

Ils correspondent à des fichiers stockés au format CSV | JSON | AVRO | ORC | PARQUET | XML soit en interne (sur les serveurs Snowflake) ou en externe (S3/Azure).

Parmi les types notables SQL non supportés, il y a : BLOB, CLOB et ENUM

Timestamp : La gestion des fuseaux horaires est source d’erreurs dans Snowflake. Un timestamp peut avoir 3 configurations différentes.

• Avec TimeZone,
• Sans TimeZone,
• Avec la TimeZone locale (celle du serveur).

Fonctions utilisateur

Redshift

Les fonctions utilisateur peuvent être développées en SQL ou en Python.

Concernant Python, la version 2.7 est supportée.

Même s’il est possible d’installer une librairie externe, les librairies suivantes sont pré installées : numpy, pandas, scipy, …

Les limitations sont peu nombreuses et évidentes : accès réseau, accès au système de fichiers.

Snowflake

Snowflake supporte deux langages pour le développement des fonctions utilisateurs SQL et JavaScript.

Lorsqu’elles sont écrites en JavaScript les fonctions utilisateur subissent les limitations suivantes :

• Mémoire : sans que l’on connaisse la valeur exacte, les fonctions Javascript sont limitées dans leur consommation mémoire.
• Durée : sans que l’on connaisse la valeur exacte, les fonctions Javascript sont limitées dans leur durée.
• Récursivité : les appels récursifs sont limités et peuvent entraîner une erreur.

Audit (traçabilité)

L’audit peut être une exigence légale d’un système de stockage d’information : être capable de tracer toutes les modifications des données et leur auteur.

Redshift

Il est possible d'activer l'audit dans Redshift et de stocker toutes les informations d'audit dans S3

Amazon Redshift utilise trois journaux différents :

• Journal de connexion : trace les tentatives d'authentification, les connexions et les déconnexions.
• Journal de l'utilisateur : trace les modifications apportées aux définitions d'utilisateur de base de données.
• Journal d'activité utilisateur : trace toutes les requêtes (avant d'être exécutées).

Snowflake

Snowflake ne propose pas d'Audit même si c'est une fonctionnalité qui est dans la roadmap du produit.

Toutefois des informations s'en rapprochant sont disponibles dans des tables système :

• query_history : texte de la requête, date et utilisateur)
• login_history : toutes les connexions à la base)
• Information schema : date de la dernière modification du schéma d'une table

Gestion des ressources et priorisation

La gestion des ressources matérielles (mémoire et cpu) est une problématique courante des Data Warehouses puisqu’elle peut permettre :

1. de garantir une exécution prioritaire pour certains traitements.
2. d’éviter la congestion du cluster à cause de la consommation excessive de certains traitements.

Redshift

Redshift propose une option appelée WorkLoad Management (WLM) afin de permettre de lier des utilisateurs et des groupes d’utilisateurs à des queues.

Ces queues ont des limites de consommation mémoire et de CPU.

Même si Redshift ne propose pas de système de priorisation, ces limites permettent tout de même de s’assurer que certaines requêtes soient favorisées et aient plus de chances d’aboutir au plus tôt.

Il existe aussi une autre fonctionnalité qui impacte la priorisation des requêtes :

• Short Query Acceleration (SQA)

Comme son nom l’indique, cette fonctionnalité permet de prioriser les requêtes courtes par rapport aux requêtes longues.

Ces requêtes disposent de leur propre système d’orchestration et n’utilisent donc pas le système de files d'attente habituel.

Un algorithme de Machine Learning permet à Redshift d’estimer le temps d’exécution des requêtes.

Snowflake

L’approche de Snowflake est radicalement différente puisqu’il repose sur un système d’entrepôt virtuel qui peut être vu comme un système de priorisation.

En affectant les traitements les plus critiques à un entrepôt dédié et dimensionné en conséquence, on peut augmenter leurs probabilités d’aboutir rapidement.

Une bonne pratique est de créer autant de virtual warehouses qu’il y a de familles de traitements différentes (chargement, exploration, data science, …).

Éditions

Il n’y a pas d’éditions différentes d’AWS Redshift. On peut simplement parler de deux versions différentes d’un même produit : Redshift et Redshift Spectrum

Concernant Snowflake, les choses sont différentes puisque l’on a pas moins de 5 éditions différentes.

Performances

Les entreprises ont aujourd’hui besoin d’analyser leurs données quasiment en temps réel et sur des volumétries très importantes.

De plus nous avons vu que contrairement à un datalake, les données d’un Data Warehouse sont souvent transformées et modélisées de manière à faciliter leur analyse (modèle en étoile, en flocon). La capacité des solutions à transformer les données est donc aussi importante que les performances d’accès.

Les deux solutions ont adopté des principes similaires afin de garantir un haut niveau de performances :

• Stockage orientée colonnes,
• Compression des colonnes en fonction du type de données,
• Découpage des données en partitions y compris au sein d’un nœud,
• Système de cache afin d'accélérer les accès répétés.

Ces performances ont aussi un impact sur la maintenance puisque les deux systèmes n’ont pas jugé nécessaire la mise en place d’index.

En ce qui concerne les performances, les benchmarks divergent puisque l’on en trouve aussi bien qui donnent Snowflake gagnant que l’inverse.

La difficulté de la comparaison vient du fait que les offres de dimensionnement des deux solutions sont différentes et que le seul critère de comparaison pertinent est dans ce cas le coût.

A coût égal, Redshift a un avantage sur son concurrent.

De toute façon il faut faire ses propres benchmarks en fonction de ses données et de ses cas d’usage.

Scalabilité

La scalabilité est évidemment un énorme avantage des solutions Cloud surtout parce qu’elle est couplée à une élasticité qui permet à un client d’adapter l’infrastructure en fonction de ses besoins.

Redshift

Voici tout d’abord les types de nœuds disponibles :

Nœuds de type “Dense Storage”

Nœuds de type “Dense Compute”

*: la gamme dc1 est remplacée par dc2

AWS Redshift offre plusieurs choix afin de dimensionner au mieux un cluster en fonction des exigences :

1. Redimensionnement Classique
2. Redimensionnement Élastique
3. Concurrence élastique

Redimensionnement classique

Ce redimensionnement cache en réalité une migration entre deux clusters. Un cluster cible est créé avec le nouveau dimensionnement désiré.

Les données sont copiées depuis l’ancien cluster vers le nouveau, et en fonction du volume de données, cette opération prend classiquement quelques heures mais peut durer plusieurs jours.

Redimensionnement élastique

Ce redimensionnement est beaucoup plus rapide que la version classique.

En effet le cluster est directement modifié (ajout ou suppression de nœud) et les données re-balancées entre les nœuds.

Cette opération prend en général quelques minutes et n’impose pas d’interruption de service.

Concurrence élastique

Avec cette option Redshift adapte automatiquement les capacités de traitement du cluster en fonction des requêtes et de la charge soumises.

De manière complètement transparente Redshift démarre et arrête de nouveaux nœuds très rapidement.

Il est possible de limiter cette fonctionnalité à des groupes d’utilisateur de Redshift et à des charges de requêtes spécifiques.

De même on peut limiter l’élasticité au travers d’un nombre maximal de clusters à utiliser.

Le système de facturation est original :

• Pour 24 heures d’utilisation de Redshift, vous gagnez une heure de concurrence élastique.
• Au-delà de ce crédit, la facturation s’effectue à la seconde.

Par défaut cette option n’est pas activée.

Snowflake

Contrairement à Redshift, il n’est pas possible de choisir le dimensionnement des nœuds mais simplement la taille des clusters. Cette approche est une conséquence liée à l’architecture particulière de Snowflake et la séparation entre traitement et stockage.

Voici les offres disponibles :

A chaque palier, le nombre de nœuds double.

Entrepôt virtuel (Virtual Warehouse)

Le premier élément de scalabilité proposé par Snowflake est le découpage en virtual warehouse.

Cela permet de séparer le type de charge en fonction de certains critères :

• priorité,
• consommation,
• criticité.

Mais aussi de séparer logiquement les traitements et donc d’offrir une meilleur isolation des données au cours de leur analyse et accès.

Cela permet surtout de dimensionner ces entrepôts en fonction du besoin réel et de manière plus fine qu’avec une solution mutualisée.

Il est évidemment possible de créer plusieurs clusters avec Redshift afin d’offrir la même granularité mais contrairement à Snowflake, les données étant hébergées sur les serveurs, cela pose la question de la sécurité et de la multiplication des copies.

Mise en veille Automatique

Il est possible de configurer le cluster (Virtual Warehouse) pour qu’il se mette en veille automatiquement après un délai d’inactivité. On peut alors configurer son redémarrage automatique en cas de soumission d’une requête. Cette opération est extrêmement rapide et ne sera pas perceptible par l’utilisateur.

Concurrence élastique

Il est possible de configurer le cluster (Virtual Warehouse) pour qu’il ajuste le nombre de clusters en fonction de la charge.

On peut définir un nombre minimal et maximal de clusters à démarrer/arrêter.

C’est le nombre de requêtes en attente qui donne l’ordre à Snowflake de démarrer un nouveau cluster.

Maintenance

Tâches de maintenance

Il s’agit des tâches récurrentes qui vont permettent de garantir le bon fonctionnement d’un Data Warehouse.

Redshift

Il y a trois tâches qui permettent de garantir le bon fonctionnement d’un cluster Redshift :

• Compression des données
• Vacuum (suppression des données, réorganisation des fichiers)
• Analyse (mise à jour des statistiques)

Ces trois tâches sont effectuées automatiquement si l’on utilise l'outil standard pour l’alimentation du cluster (à savoir la commande COPY).

Ainsi la compression n’interviendra que si la table atteint une certaine taille et donc que le ratio coût CPU/Taille sur le disque est avantageux.

Snowflake

Il n’y a officiellement aucune tâche de maintenance liée à l’utilisation de Snowflake.

On peut toutefois noter que la gestion des utilisateurs, de la sécurité et des différents environnements revient aux clients.

Montée de version

Redshift et Snowflake en tant que service managés gèrent la montée de version de leur produit respectif de manière quasi transparente pour l’utilisateur.

Leur but est évident :

1. éviter de maintenir un trop grand nombre de versions,
2. proposer une amélioration continue des fonctionnalités du produit,
3. fournir un service performant et sécurisé.

Redshift

AWS permet de configurer la mise à jour automatique de Redshift suivant une plage horaire hebdomadaire à définir (fenêtre de maintenance).

L’interruption de service est connue mais sa durée n’est pas maîtrisée.

On peut choisir une politique plus ou moins agressive de mise à jour :

• Current : la dernière version est installé automatiquement
• Trailing : l’avant dernière version est installée automatiquement

En cas de problème, Il est possible de revenir à une version précédente dans la console.

Snowflake

Avec Snowflake les mises à jour sont entièrement transparentes et le plus souvent sans aucune interruption.

C’est rendu possible grâce à l’architecture de Snowflake qui sépare données et traitements.

Des instances avec la nouvelle version sont lancées et une fois ces dernières validées, la bascule peut opérer. Les données ne sont pas impactées dans le process.

Il reste bien évidemment les mises à jour du système de stockage qui ne sont pas maîtrisées par Snowflake (S3/Azure Blob Storage).

Les deux opérateurs Cloud minimisent l’interruption de service au maximum et l’opération est majoritairement transparente pour les utilisateurs.

Sécurité

Lorsqu'il s'agit de données d’entreprise, la sécurité est un fondement essentiel. Et il y a d’ailleurs un certain nombre de normes qui la régisse (données médicales, données bancaires, …)

Le Cloud n’est pas obligatoirement moins sécurisé que le on-premise mais les scandales récents ont montré des failles au retentissement et aux conséquence énormes pour l’image de l’entreprise (Cf. https://blog.ippon.fr/2018/08/02/la-securite-du-cloud/).

Redshift et Snowflake prennent la sécurité très au sérieux.

Redshift

On peut distinguer :

1. sécurité du service
2. sécurité de la base de données

Concernant la sécurité de l’accès au service Redshift, elle est similaire à toutes les autres solutions natives d’AWS basées sur IAM (AWS Identity and Access Management).

Voici les principaux points pour l’accès aux clusters :

• Identifiants de connexion,
• Support des rôles,
• Support des Security Group,
• Redshift peut être intégré à un VPC (Virtual Private Cloud),
• Chiffrement des données,
• Utilisation de SSL pour les échanges entre les client (driver) et Redshift,
• Chiffrement des données entre S3/DynamoDB et Redshift.

Amazon Redshift utilise l’accélération matérielle pour la gestion du SSL.

Conformité

Redshift est conforme aux exigences SOC1, SOC2, SOC3, PCI DSS niveau 1, FedRAMP, et est éligible HIPAA.

Hébergeur de Données de Santé (HDS) : disponible sur certaines régions (dont Paris).

Il est possible d’activer le chiffrement des données des métadonnées et des sauvegardes.

La gestion de l’accès aux données est gérée dans Redshift de la même manière que dans un SGBD.

Snowflake

Le niveau de sécurité exigé va directement conditionner le choix de l’édition du logiciel Snowflake.

Plus le niveau d’exigence est élevé, plus le coût sera important.

Authentification :

• Multi-facteur
• Fédération d’identité (active directory, OAuth)

Autorisation

• Restriction IPs possible

Communication privée/directe entre Snowflake et vos autres VPC via AWS PrivateLink.

Contrôle des accès :

L’accès à tous les objets du compte (utilisateurs, entrepôts, bases de données, tables, etc.) est contrôlé  grâce à des rôles.

Sécurité des données :

• Toutes les données sont automatiquement chiffrées.
• Tous les fichiers stockés par étapes (pour le chargement/déchargement des données) sont automatiquement chiffrés.
• Clés gérées par le client.

Conformité

• Conformité Soc 2 Type II.
• Prise en charge de la conformité HIPAA.
• Conformité PCI DSS.

Coûts

Les deux systèmes proposent un système de facturation à la demande, fortement modulable en fonction du besoin.

Il est difficile de comparer les deux offres car :

1. Leur architecture est différente :

• Snowflake facture le traitement et le stockage séparément
• Snowflake ne facture pas les périodes d’inactivité

2. Le dimensionnement des instances est difficilement comparable (RAM/CPU, nombre de nœuds)

3. Le système d’instances réservées d’AWS permet de réduire de manière substantielle la facture de Redshift (75 % pour un engagement sur trois ans).

Nous allons donc présenter séparément les coûts des deux solutions mais sur une base de dimensionnement commune :

• un besoin de stockage de 8 To de données,
• un cluster de 8 nœuds,
• le tout basé à Dublin.

Redshift

Redshift charge par heure et par nœud en fonction du dimensionnement de ces derniers, ce qui couvre à la fois la puissance de calcul et le stockage des données.

Avec Redshift, le prix mensuel est donc obtenu en multipliant le prix horaire par la taille du cluster et le nombre d'heures dans un mois.

Snowflake

Snowflake charge par seconde et par entrepôt virtuel en fonction de la fonction du dimensionnement de ces derniers.

Avec Snowflake, le prix mensuel est donc obtenu en multipliant le prix horaire par la taille du cluster et le nombre d'heures d’utilisation réelle dans un mois.

Contrairement à Redshift, tous les nœuds ont la même capacité et seul leur nombre peut varier.

Enfin le choix de l’édition a un impact non négligeable puisque le coût varie du simple au double.

NB : le coût de transfert des données n’est pas pris en compte ici mais à ne pas négliger dans une estimation réelle.

Constats et remarques :

1. Redshift est particulièrement moins cher que Snowflake
2. Le coût de stockage est beaucoup moins élevé que le coût de traitement
3. En condition réelle et avec la mise en veille automatique, le coût de Snowflake pourrait baisser drastiquement (facture divisée par trois avec une utilisation de 12 heures par jour et quasi nulle les week-end).
4. Le coût de Redshift peut être réduit grâce à l’utilisation d’instances réservées (engagement sur un ou trois ans).

Monitoring

Redshift

Sur AWS, chaque service propose une interface de surveillance basique, directement intégrée à la console de chacun de ces services.

Pour une surveillance plus poussée et surtout pour une vision globale du fonctionnement des services, AWS propose un outil spécialisé : CloudWatch.

Cloudwatch permet :

• De consulter les métriques pré-définis
• De définir des métriques personnalisés
• De définir un tableau de bord personnalisé
• L’alerting (mail) en cas de dépassement de certains seuils
• De dimensionner automatiquement la plateforme lorsqu’il est couplé avec Amazon Auto Scaling.

La version de base de CloudWatch est gratuite mais les points suivants peuvent entraîner un surcoût :

• Fréquence de rafraîchissement plus élevée.
• Métrique supplémentaire (en général à un niveau plus fin du service, c’est à dire par nœud plutôt que global).

Écran de suivi des requêtes :

La vue détaillée est très complète et permet de comprendre a posteriori la performance d’une requête.

​Les logs Redshift sont consultables au sein de 3 tables systèmes :

• STL_ERROR : ne concerne pas les erreurs SQL mais les erreurs internes au cluster
• STL_QUERY : texte de la requête, début, fin, statut
• STL_QUERY_METRICS : nombre de lignes, utilisation CPU, disque, entrées/sorties, ...

Snowflake

L’interface de monitoring de Snowflake est plus succincte et très orientée sur les performances des requêtes.

La charge globale d’un Virtual Warehouse est visible dans l’interface Web grâce au graphique suivant :

L’écran de suivi des requêtes donne une vision plus précise des performances d’une requête :

Voici l’écran détaillé des performances d’une requête :

Synthèse

Conclusion

Il y a beaucoup de points communs entre les deux solutions qui vont adresser un même besoin : pouvoir analyser un volume important de données structurées ou semi-structurées d’entreprise.

Pour les nombreuses entreprises qui hébergent déjà leurs applications sur l'infrastructure AWS, l'adoption de Redshift comme entrepôt de données serait naturelle.

L’architecture de Snowflake met en avant la séparation entre capacité de calcul et de stockage, ce qui a des avantages et des inconvénients.

Le parti pris de Snowflake est de pousser le concept de service managé au maximum puisque les opérations de gestion et de maintenance sont quasi nulles.

Enfin Snowflake peut être vu comme un remède contre le vendor lock-in, puisque l’offre est disponible à la fois sur AWS et sur Azure Cloud. Ce qui peut permettre l’hybridation multi-cloud.

Sur ce dernier point et même si Snowflake revendique une base de code commune, il y a des développements propres à Azure/AWS (réseau, sécurité et évidemment stockage).

Aller plus loin

Documentation officielle :

https://docs.snowflake.net/manuals/index.html

https://docs.aws.amazon.com/redshift/index.html

Benchmarks :

https://fivetran.com/blog/warehouse-benchmark

https://azure.microsoft.com/mediahandler/files/resourcefiles/date-warehouse-Cloud-benchmark/Data%20Warehouse%20Cloud%20Benchmark.pdf

https://www.periscopedata.com/blog/interactive-analytics-redshift-bigquery-snowflake

Divers :

https://statsbot.co/blog/modern-data-warehouse/

https://panoply.io/data-warehouse-guide/redshift-architecture-and-capabilities/