Article de blog

Le DWH est mort, vive le DWH as a service

Article publié par Pierre Coste, Lead Tech – Manager chez Keyrus

Depuis quelques années, le monde de l’analyse de la donnée change énormément, par les concepts mais aussi par les technologies. Le but reste toujours le même, ingérer, traiter et analyser les données, mais avec quelques facteurs en plus : . plus de volume ; . plus souvent ; . avec des données moins structurées.

L’avènement du Cloud est un accélérateur avec l’effet “no limit” du stockage. Il est de plus en plus facile de stocker toutes ces données pour ensuite pouvoir les analyser. Dans ce même temps, beaucoup d’effets de modes, beaucoup de buzzword, beaucoup de nouvelles solutions arrivent sur le marché. On peut le constater avec les écosystèmes tels que Hadoop, qui a apporté plusieurs couches de logiciels afin de construire une plate-forme de données.

On constate aujourd’hui que ces solutions arrivent à bout de souffle, car très complexes à gérer, à maintenir et exploiter. Un des gros points noirs de ces solutions étaient aussi la complexité d’apprendre des nouveaux langages et concepts pour un gain en temps et en performance qui n’était pas toujours là au final. On notera par contre des solutions (comme Spark) qui ont su tirer leurs épingles du jeu pour le traitement parallélisé et qui ont su prendre le virage du Cloud.

En parallèle de ces solutions de Data Lake, Data Hub et autres acronymes, nous avons pu voir le retour en force des solutions de DWH, classiques mais sur-vitaminées par les capacités des technologies Cloud. Un objectif simple : disposer d’un système de base de données SQL avec la puissance et la flexibilité du Cloud.

On distinguera 2 grandes orientations : . les solutions OnPrem portées dans le Cloud qui se rapprochent plus du PaaS . les produits créés pour le Cloud qui sont des véritables SaaS

Cette différence est néanmoins assez structurante car les produits conçus pour le Cloud bénéficieront de fonctionnalités nouvelles et plus avancées à mon sens. Nous allons faire un focus sur ces solutions créées pour le Cloud, et en particulier Google Cloud BigQuery et Snowflake qui sont les produits les plus avancés à ce jour.

Note : Azure Synapse aurait pu rentrer dans cette catégorie au vu des dernières présentations de Microsoft Ignite en novembre 2019 mais les accès et le produit restent en preview. SQL DWH reposant plutôt dans la première catégorie au vu de la non séparation entre le “compute et storage”.

Les solutions Google BigQuery & Snowflake

Ces deux solutions reposent sur un choix de fournir un DWH en SQL pour lequel la maintenance et l’exploitation est réduite au minimum. Il n’est pas nécessaire de provisionner des infrastructures, mettre à jour les applications et systèmes, lancer des maintenances de bases et de tables. Autre point différenciant, le service est disponible tout de suite. Une fois vos accès et compte créés, il est possible d’ingérer ou de requêter vos données instantanément sans devoir à attendre un quelconque provisionnement.

C’est entre autre cette capacité à séparer le stockage du traitement (ou “compute”) qui fait la force de ces solutions. Ces solutions reposant sur des architectures distribuées et mutualisées montrent une vraie rupture technologique pour les bases de données versus les solutions classiques qui nécessitent un provisionnement des instances. En soit, ce n’est pas grave de devoir attendre 10 minutes pour avoir son environnement, cela montre par contre les limites de l’architecture et sa capacité à évoluer automatiquement et rapidement en fonction de l’usage de votre plate-forme. BigQuery et Snowflake ont des concepts proches mais ont aussi fait des orientations différentes sur le moyen de consommer le service.

Une scalabilité de 0 à sans limite

Point important et fondamental pour comprendre le fonctionnement de ces solutions : par défaut aucune ressource de calcul ne vous est allouée et il n’y a donc pas de coûts. Vous avez alors des systèmes capables de s’éteindre et s’allumer automatiquement, et de s’adapter à la hausse en cas de pic de charge mais aussi à la baisse jusqu’à s'éteindre. Une des premières remarques est souvent “ma base de données tourne toujours”. C’est effectivement un fait, mais aujourd’hui votre plate-forme sizée pour 100% de votre activité comprenant les pics est allumée et disponible tout le temps.

L’approche de BigQuery ou de Snowflake est de provisionner seulement quand vous avez besoin des unités de traitement. Dans les faits, votre DWH peut être allumé 24h/24 pour un usage ETL ou reporting par exemple, mais seulement pour 10% de sa capacité maximale. Cette logique vous permettra une réduction des coûts et surtout de ne pas devoir provisionner une architecture cible maximale pour prévoir des pics d’utilisation. Snowflake, par exemple, est dans une approche de ségrégation des usages via la création de “warehouse”, une entité logique correspondant physiquement à des VM (EC2 AWS, Azure VM, Google Compute Engine) mais qui sont allouées instantanément en fonction des besoins.

Ces warehouse ont une taille (XS à 4XL) et ont la capacité de s’adapter à la charge en démarrant automatiquement des nouveaux warehouse (sous réserve d’avoir l’édition Enterprise). Ces warehouse étant gérés automatiquement, ils s’allument, s’augmentent et s’éteignent en fonction de l’activité. Snowflake facture ensuite à la seconde en fonction de l’usage de ces warehouse.

De son côté, BigQuery a franchi une étape supplémentaire. En effet, il n’est pas nécessaire de définir une unité de calcul et d’allouer une certaine taille, c’est BigQuery qui gère cette étape. L’utilisateur a seulement à écrire et exécuter une requête. C’est le nombre de données consommées par la requête qui engendra une facturation. Le client pourra ensuite passer à un modèle au forfait et plus un coût à l’usage lorsqu’il aura atteint un certain niveau de consommation.

Les changements de paradigme avec des bases analytiques dans le Cloud

Avec ces nouvelles solutions, de nouveaux usages mais aussi une nouvelle façon d’aborder les données s’offrent à vous. Premier point, mais pas des moindres, les contraintes autres que “not null” ne seront pas contrôlées. Il est impossible de définir des clés primaires ou étrangères. C’est incompatible avec ces bases MPP. C’est à prendre en compte dans les migrations et dans le design des traitements.

Avez-vous déjà eu envie de retourner dans le temps ? 

Nous allons en quelque sorte utiliser la fonctionnalité qu’on aurait pu nommer “Dolorean as a service”. Il s’avère qu’on parlera plus de “Time Travel”, cette fonctionnalité qui permet de revenir dans le temps de votre base de données, à la fois en cas d’erreur et de fausse manipulation, mais aussi pour gérer vos backups. Cette fonctionnalité existe depuis SQL:2011, et est implémentée dans BigQuery et Snowflake pour gérer le retour en arrière. Qui n’a jamais fait un update en production... en oubliant la clause « where »…

Une requête sur votre table en rajoutant :

De 1 à 90 jours pour Snowflake et 7 jours pour BigQuery sont les plages pour lesquels il est possible de sélectionner les données de vos tables dans le passé à n’importe quel instant durant ce laps de temps.

Une marketplace des données

Comme présenté lors d’un dernier article, le data sharing est un moyen simple pour partager ses données sans les copier, les déplacer. Lorsque vous souhaitez mettre à disposition vos données, il est possible de réaliser des exports, voire la création des API. Une nouvelle alternative est de faire en sorte de partager ses données et de faire comme si les données étaient dans votre environnement. Avec Snowflake ou BigQuery il est facile de donner un accès à une table, voire un ensemble de tables, pour accéder en direct et sans copie aux données. L’objectif à terme est de pouvoir construire une vraie marketplace des données qui vous permettrait d’y accéder instantanément.

Du côté de Snowflake, une plate-forme “Data Exchange” commence à être disponible. Si vous souhaitez récupérer les données de météo pour vos analyses, vous pourrez directement requêter les données d’un fournisseur de données depuis votre environnement Snowflake sans avoir d’export/import, d’API, etc. Comme si les données étaient déjà dans votre DWH/Data Hub. Chez Google, globalement la même approche avec des dataset publics mais aussi des dataset payants. Demain, vous pourrez être des consommateurs de ces datasets, mais vous pourrez aussi devenir un fournisseur de données, pour vos clients actuels, partenaires...

Données semi-structurées

Les données semi-structurées sont de plus en plus présentes (exemple : JSON). Ces nouvelles bases de données vont être en capacité de les ingérer facilement avec néanmoins une différence. Snowflake a fait le choix de créer un nouveau type de colonne, le “VARIANT” pour stocker des données sous ce format et pouvoir requêter en JSON-SQL simplement.  Ce choix permet d’avoir des changements de structures (ajout de colonne par exemple) dans le fichier JSON sans devoir modifier la structure de la table car tout sera stocké dans la colonne VARIANT.

Coté BigQuery, le choix se porte plutôt sur le fait de pouvoir ingérer des données JSON et de les stocker dans un format multidimensionnel en acceptant des colonnes du type RECORD qui permettront d’avoir des lignes imbriquées entre elles et donc reproduire le format JSON en format tabulaire.

Cette approche de gestion des fichiers a pour vocation de faciliter l’accès à la donnée et de pouvoir ingérer le plus rapidement possible les données en base pour pouvoir les analyser et les traiter.

Ce n’est que le début

On pourra aussi parler des fonctionnalités de streaming et de Machine Learning à Bigquery ML, probablement dans un nouvel article... Ces bases analytiques restent assez récentes et se démocratisent petit à petit. Elles remettent au cœur de leur produit le SQL, langage datant de 1974 ! Elles évoluent rapidement et de nouvelles fonctionnalités voient le jour. Certains retards sont aussi comblés petit à petit (scripting, procédure stockées, etc.). Rien qu’à titre d’exemple, BigQuery a sorti 6 fonctionnalités en novembre.

De même, Snowflake met à jour chaque jeudi ou vendredi une nouvelle version du produit (correction de bugs, nouvelles fonctionnalités).

Cela peut sembler anecdotique mais c’est encore une fois un point fort de ces solutions : bénéficier des nouvelles fonctionnalités. Et c’est aussi rassurant sur la technologie sous-jacente car ces mises à jour sont réalisées sans coupure de service.

À retenir

Pour résumer, ces DWH - voire Data Platform, car plus complète qu’un simple DWH - évoluent vers le Cloud et prennent l’ascendant sur les technologies Hadoop qui ont été un moyen de repousser de quelques années le passage au Cloud en gardant des architectures OnPrem. Avec la facilité d’aller dans le Cloud pour stocker de plus en plus de données, BigQuery, Snowflake et sûrement d’autres produits permettront de répondre à de nouveaux usages, mais aussi de simplifier l’accès et la consommation de données. Ces solutions n’ont pas la prétention de remplacer toutes vos bases de données mais plutôt de vous apporter plus de souplesse et d’évolutivité de votre processus de traitement et analyse de données.

Pour finir cet article et cette année 2019, je vous laisse aussi lire un article mettant en avant la tendance serverless pour cette année à venir : https://www.zdnet.fr/actualites/cloud-computing-la-lourde-tendance-2020-le-serverless-progresse-39896487.htm