Journal d’un architecte 101 : les grands défis d’une plateforme Big Data

De plus en plus d’entreprises commencent à comprendre que l’essence même de leur parc applicatif repose sur la donnée. Ainsi, la comprendre est capitale si elle veut perdurer et pouvoir, par exemple, se projeter et tenir ses objectifs à court et long terme.

Pour ce faire, une réflexion profonde est à mener sur la vision data de l’entreprise, notamment sur son acquisition, sa persistance, son authenticité et son exploitation. Cet article résume en quelque sorte les challenges que nous rencontrons au quotidien dans nos missions d’expertises autour de plateforme Big Data.

Le Big Data, kesako ?

Définir le Big Data comme étant « un stockage important de données » ou encore utiliser des raccourcis comme « Big Data égal datalake » est assez réducteur et même incorrecte dans l’absolu. Pour ma part, je considère qu’on peut parler de Big Data lorsque la donnée nous arrive à grande vitesse (mais pas que) , qu’elle est multiforme (structurée ou non) et donc qu’elle entraîne logiquement un stockage important dans le temps (court et long). Le datalake n’est finalement qu’une solution technique apportée à une problématique bien plus évoluée.

Cela soulève donc plusieurs questions importantes que tout architecte Data doit se poser à savoir :

• Comment j’adsorbe tout ce débit de données en étant résilient ?
• Comment je garantis (ou pas) la « véracité » de cette donnée aux équipes d’exploitations (Datascience, BI, …) ?
• Comment je m’assure de son intégrité et sa cohérence dans le temps ?

Ces questions se suffisent à elles mêmes pour décrire le niveau de complexité du problème car elles dépendent toutes d’une variable complexe : le temps. En effet, le maîtriser ou du moins limiter ses effets indésirables permet d’aborder la problématique « Big Data » avec sérénité.

Pour résumer, lorsque vous avez à absorber et traiter par exemple plusieurs Giga de données par jour, arrivant sous forme de fichiers plats, parquets, images ou tout autre format, vous êtes bien sur des problématiques Big Data. Voyons maintenant comment les aborder d’un point de vue technique.

Aux armes

Aujourd’hui, il existe plusieurs types d’architecture de plateforme Big Data, chacun ayant un mode de fonctionnement distinct (Lambda, Kappa, etc.). Ce n’est jamais aussi simple de choisir son type d’architecture dans la réalité car tout est contextualisé et se rapporte aux politiques de sécurité en vigueur, aux coûts financiers et humains impliqués, au niveau de maturité de l’entreprise, à l’existant, etc.

Tout cela pour dire que certaines architectures fonctionneront parfaitement bien sur des projets « from scratch » mais auront plus de mal à s’intégrer avec du legacy par exemple.

En fonction du contexte dans lequel vous êtes, ce sera donc à vous d’orienter la stratégie à adopter sur du court et long terme. Découvrons maintenant les différents scénarios envisageables.

Je suis on-premise, je veux y rester mais avec une plateforme Data moderne

Cas typique d’une entreprise réfractaire au Cloud pour des raisons assumées, en général liées aux normes de sécurité, au manque de compétence, au coût de migration, j’en passe… La bonne nouvelle c’est que le Cloud n’a pas l’apanage de la « modernité » mais doit être vu en quelque sorte comme un accélérateur dans votre processus de modernisation. En effet, il existe de très bons outils « Open source » qui permettent de monter une plateforme Data moderne d’un point de vue conceptuel. De plus, ces derniers répondent, en partie, aux problématiques évoquées au début de cet article.

Citons, par exemple, la suite Apache Hadoop sous son packaging Hortonworks (HDP) qui est actuellement l’une des plus utilisées sur le marché Big Data. Nous y reviendrons plus en détail plus bas.

Je suis on-premise , je veux moderniser ma plateforme Data dans le Cloud

La première erreur que je rencontre très souvent c’est l’approche. Certaines entreprises se lancent précipitamment dans du « lift and shift » (littéralement soulever et déplacer) de VM (Virtual Machine) on premise vers le cloud. Voilà ce que cela signifie : on prend nos serveurs (Spark, Kafka, Hive, …), on les migre sur des VM Cloud, on connecte le tout, boom ça marche. En somme, on fait du IaaS. Cette solution s’avère être coûteuse pour les entreprise car elles se retrouvent à payer des sommes faramineuses sans tirer pleinement du profit du Cloud. A défaut d’autres possibilités, il faut donc l’envisager dans le pire des cas.

Il faut aussi retenir que de nos jours, tous les grands fournisseurs Cloud tels que Azure, GCP ou AWS fournissent à minima des services Data managés. Ils sont très souvent sur la base de travaux open source pour le stockage low cost et le traitement des data par lot ou en streaming. Cela vous épargne des coûts de mise en place d’infrastructure. A noter que certains services managés seront plus matures que d’autres, d’un point de vue automatisation par exemple. Il peuvent aussi être moins flexible en terme d’utilisation. Finalement, il faut donc trouver le juste milieu en fonction des critères d’acceptance de l’entreprise.

Je suis déjà dans le Cloud , j’ai un POC fonctionnel et je veux aller en production

Tout d’abord, c’est très bien de faire la distinction entre un environnement de Lab (POC) de la Production ! Bien trop souvent nous voyons des POC finir en « Prod » et qui cessent de fonctionner par la suite. Passer en Production nécessite d’avoir assez de recul pour voir l’échiquier dans son ensemble et anticiper tous les coups possibles. Cela permet de se pencher sur des questions d’infrastructure, de résilience, de transactions sur des systèmes distribués (bon courage) , d’authentification, d’autorisation, etc. On est donc plus attentif aux détails afin de délivrer le meilleur produit ou service. Pour ma part, je le résume en trois niveaux d’attention :

• Niveau Infrastructure : les ressources que vous allouez pour faire tourner vos applications ont des spécificités et vous devez les connaître afin de vous prémunir des éventuels problèmes de Run. Par exemple, quelle est la capacité maximale lors d’une mise à l’échelle d’un cluster Azure Databricks ? A cette question, vous apporterez des éléments de réponse au business sur votre capacité maximale **théorique** de distribution de calcul et donc sur le temps de traitement dans le pire et meilleur cas.

• Niveau Applicatif : le code que vous écrivez est avant tout fait pour des humains et donc se doit de respecter les règles de l’état de l’art. Il doit être testable et testé, automatisable dans son déploiement, sécurisé d’un point vu authentification et autorisation, surveillez pendant le Run. De nos jours, Python et Scala sont les langages les plus utilisés dans le monde de la Big Data notamment pour leurs communautés de contributeurs grandissantes. A noter également, la présence de connecteurs Spark en Java et .NET, offrent de nouvelles perspectives à plusieurs développeurs en restant dans leur zone de confort et donc de livrer de l’applicatif de qualité.

• Niveau Data : les data manipulées par vos applicatifs sont potentiellement sensibles et soumises dans certains cas à une législation très ferme. Je pense notamment aux exigences RGPD (Règlement Général sur la Protection des Données). Aussi, assurez vous d’en garantir le sens par des moyens techniques éprouvés tels que le chiffrement de la donnée au stockage, la sécurisation du tunnel de communication (SSL, TLS, etc), par l’utilisation de certificats. Si vous êtes animés par des challenges techniques, notamment sur comment garantir la data privacy lorsque des datascientists doivent  faire des analyses sur des données du personnel, je vous conseille de vous documenter sur les techniques d’offuscation des données sans altération (sans perte de variance par exemple) notamment sur les chiffrements homomorphiques et autres. Certaines bibliothèques, telle que Microsoft Seal, commencent à aborder le problème mais ne sont pas encore matures pour répondre pleinement à cette problématique.

Je suis déjà dans le Cloud et On Premise, je suis en « prod » mais ma plateforme n’arrête pas de tomber

Les architectures hybrides sont souvent les plus complexes car elles nécessitent une infrastructure plus réfléchie d’un point de vue sécurité (différentes couches d’abstraction) et multiplie les points de complexités notamment sur la communication au niveau infra  (express Route, VPN, …). Il existe plusieurs accélérateurs d’audit permettant de trouver les problèmes les moins évidents. Par exemple, vous ne comprenez pas pourquoi votre job spark schedulé quotidiennement prend maintenant 6 heures de temps pour au final se planter sans raisons évidentes ? Commencez par identifier et catégoriser vos récents changements, par exemple, si vous venez de migrer une partie de vos applications dans le Cloud et que vous communiquez avec des serveurs On Premise via une express route, commencez par inspecter la nouvelle infrastructure réseau puis montez progressivement au niveau applicatif en inspectant tous les relais de communication (gateway, proxy, oauth, etc).

Si le problème persiste, c’est potentiel des changements applicatifs ou de son environnement d’exécution qui en sont la cause. Cela peut venir d’installation de mauvaises versions de dépendances applicatives ou d’une désactivation d’option d’optimisation dans la cible. Cela arrive très souvent lorsqu’on ne maîtrise pas assez pleinement le contexte de migration dans lequel on opère.

Je suis nul part, tout est à faire

Jackpot ! Vous n’aurez aucune excuse sur l’existant, tout comme les développeurs Java l’ont eu sur la fameuse rétro compatibilité (troll) pendant longtemps. Vous devez donc prendre pleinement conscience de votre contexte opérationnel et connaître les forces et faiblesses de ce dernier. Pour ma part je me pose plusieurs questions de cadrage qui me permettent de définir une architecture cible.

En voici une ébauche :

• Quel besoin a été formulé ? Par exemple : donner accès à l’ensemble des données de l’entreprise en toute sécurité aux datascientists.
• Quelles en sont les raisons ? Par exemple : innover dans nos produits et services.
• Où en êtes-vous actuellement ? Par exemple : phase de cadrage.
• Qu’attendez-vous de nous ? C’est une question très importante car elle permettra de dissiper tout doute ou incompréhension sur le besoin initial en laissant le porteur de projet le formuler tel qu’il l’envisage.
• Qu’en pense l’IT ?  Par exemple : Elle pointe du doigt les potentiels failles de sécurité, donc respecter les protocoles en vigueur.
• Qu’en pense les potentiels utilisateurs finaux (interne ou externe) ?
• Etc.

Ces questions, pour certaines si évidentes, vous permettront petit à petit de schématiser votre solution technique en éliminant tous les composants qui ne rentrent pas dans votre contexte opérationnel. Prenons cet exemple, vous devez faire du streaming sur un contenu produit au fil de l’eau. Les équipes IT vous imposent de cloisonner les différents consommateurs par groupe d’utilisateurs authentifiés avec un contrôleur de domaine spécifique. Cela va donc éliminer d’office toutes les solutions de streaming ne supportant pas un protocole d’authentification tel que Kerberos par exemple.

Tout cela pour dire, qu’un contexte bien compris permet non seulement de passer moins de temps en conception et en implémentation mais aussi de garantir en quelque sorte la phase de run.

Gouverner sans régner

Une plateforme Data vit en continue, elle génère sans cesse de la donnée et nécessite une organisation stricte pour permettre aux nouveaux besoins métiers de s’y greffer sans cassure. Il faut donc mettre en place des politiques d’accès aux données en conformités aux différents rôles présents dans l’entreprise. Par exemple, attribuer un rôle de Data Owner au responsable d’une source de données et lui laisser le droit d’en attribuer l’accès comme il le souhaite.

Vous devez donc penser datasets (jeu de données) et non plus base de données uniquement. Les datasets doivent être référencés de sorte à ce que tous les porteurs de projets au sein de l’entreprise aient connaissance des différents jeu de données à leur disposition sans pour autant avoir un accès implicite. On parle alors très souvent de Data Catalog.

Pour terminer, je dirai que la seule vérité dans un mensonge c’est qu’il a existé. Alors si vous le pouvez, vous devez absolument garantir l’immutabilité de vos données brutes afin de rejouer vos scénarios business à la volée. Cela augmentera progressivement votre capacité à être résilient et donc assurer vos SLA.

Delta Lake : 101

S’il vous est déjà arrivé de travailler sur des architectures lambda avec 2 couches d’ingestion ou de traitements de données (une en streaming et une autre en batch) vous avez pu remarquer à quel point il est difficile de garantir l’intégrité des données. Notamment lorsque vous avez plusieurs data pipelines concurrents qui lisent et écrivent en parallèle.

Le projet Delta Lake est un projet Open Source qui fourni une couche de stockage abstraite permettant de reproduire des transactions ACID telles qu’on les connait dans le domaine du Big Data. Il utilise du parquet et est donc compatible avec la grande majorité des Datalake sur le marché. Je vous conseille vivement de lire l’article « Pourquoi utiliser Delta Lake » pour en savoir.

Le principe général est assez simple, on part de la donnée brute dite « Bronze Data » sur laquelle on effectue quelques traitements de conformité (nettoyage de colonnes, etc) pour obtenir des « silver data« . Enfin, chacun des downstreams (consommateurs finaux ) peut appliquer des traitements métiers spécifiques (agrégats, sélection, projection , etc) sur ces Data pour obtenir des « Gold Data« . D’autres features intéressantes tels que le schema enforcement ou le versioning permettent d’aller beaucoup plus loin.

Apache Foundation : leader incontesté ?

Beaucoup de choses ont été dites, notamment sur les aspects opérationnels et techniques d’un besoin Big Data. L’Apache Software Foundation, avec sa grande communauté de contributeurs, a développé plusieurs outils opensource éprouvés, largement utilisés dans les entreprises faisant du Big Data.

Voici une liste non exhaustive des composants à absolument connaître :

On peut également mentionner que, la plupart des formats de stockage de données optimisés et utilisés dans le monde du Big Data, tels que les formats parquet, ORC, … ont été développés par Apache. Le principal avantage de ces types de format, en l’occurrence le format parquet, c’est la prise en charge native de la compression des données mais aussi le fait de garder le typage des données. C’est un problème que l’on peut rencontrer lorsqu’on travaille avec des fichiers plats par exemple. Il est donc fortement recommandé d’utiliser ces types de stockage au maximum.

Le Cloud et l’opensource : Microsoft Azure

Dans Azure, vous avez deux grandes implémentations qui se basent en quelque sorte sur les travaux de l’Apache Foundation pour fournir, tout ou en partie, les principaux composants Big Data : Azure Databricks et Azure HdInsight. Ces derniers se rejoignent principalement dans l’intention du calcul distribué mais présentent des contraintes opérationnelles différentes. Par exemple, la prise en main d’un Azure Databricks est très simple d’un point de vue infrastructure et permet de se concentrer uniquement sur ce qui produit réellement de la valeur : l’applicatif. En revanche, dans un contexte stricte en terme de sécurité, d’automatisation, de monitoring et gouvernance, il manque encore de flexibilité et de souplesse pour l’instant. Ce qui n’empêche pas d’aller en production du moment, qu’une fois de plus, vous maîtrisez parfaitement votre contexte opérationnel.

Pour ce qui est du stockage et du calcul distribué dans sa version entreprise, HdInsight permet d’obtenir ce niveau de détail que manque pour l’instant Azure Databricks. Il utilise la distribution Hadoop, basée sur Hortonworks Data Plaform, et permet donc d’utiliser nativement la plupart des services que je vous ai présenté précédemment. On peut donc plus finement gérer les droits d’accès sur l’ensemble des clusters, avoir une intégration native entre le service Ranger et Azure AD pour la version entreprise, se connecter en « ssh » sur les nœuds , etc. Les raisons qui font que certains préfèrent Azure Databricks sont principalement liés au coût financier, à la simplicité d’utilisation, à un besoin spécifique en l’occurrence Spark. C’est à vous, Architecte Data de contextualiser votre réponse technique en prenant compte de tous les paramètres opérationnels dont vous disposez.

Azure Synapse is the new brain

Je vous conseille vivement de vous documenter sur cet outil qui est annoncé comme étant une évolution d’Azure SQL Data Warehouse et qui très prometteur. En effet, la promesse faite par Microsoft est de fournir un service quasiment « ALL-IN-ONE » pour tout travaux autour de la data. C’est à dire en quelque sorte regrouper Datalake, DatawareHouse, BI et Datascience sous un même toit pour simplifier la mise en oeuvre des projets.

Pour conclure

S’il fallait retenir quelques mots de cet article, ce serait principalement que :

• Le Big Data ce n’est pas que du Datalake.
• Une architecture qui fonctionne chez Alice ne fonctionnera pas forcement chez Bob.
• Le Cloud n’a pas l’apanage de la modernité mais est en quelque sorte un bon vecteur.
• Apache Foundation dispose d’une suite logicielle vous permettant de produire une plateforme Big Data de qualité.
• Tout dépend encore une fois du contexte opérationnel dans lequel vous évoluez !

One more thing…

Dans cet article, nous nous sommes purement penchés sur des questions Data autour du Cloud mais pas que. La suite logique serait donc de voir comment les downstreams exploitent votre plateforme (Big) Data au quotient . Je vous donne déjà rendez-vous pour la suite intitulé Journal d’un Architecte 102: Une plateforme Data vue par les Downstreams !