Lacs de données, entrepôts de données, centres de données : en avons-nous besoin ?
Un débat de longue date, qui remonte aux débuts de Hadoop, porte sur le type de dépôt de données dépôt mieux dépôt à un cas d'usage donné en matière d'analyse de données. Un lac de données ? Un hub de données ? Un entrepôt de données ? Malgré le déclin de Hadoop, ce débat non seulement persiste, mais devient de plus en plus complexe. Les référentiels actuels basés sur le cloud, notamment AWS S3, Microsoft Azure ADLS et Google Cloud Storage, ressemblent fortement à des lacs de données dans le cloud. De même, les offres cloud telles que Snowflake s’apparentent fortement à des entrepôts de données d’entreprise, mais dans le cloud. Certes, pour une comparaison à périmètre égal avec les lacs de données, il faudrait réduire Hadoop à son seul HDFS ou y ajouter les outils de dépôt de données, requête, etc., associés aux offres des trois fournisseurs de cloud public.
Par ailleurs, il convient de noter qu’aucun des fournisseurs proposant ces offres n’utilise ces termes… Microsoft, Amazon et Google qualifient leurs référentiels cloud de « hubs de données d’entreprise ». Snowflake se positionne comme un entrepôt de données cloud évolue désormais vers une « plateforme de données cloud » grâce à son écosystème en pleine expansion ; toutefois, pris isolément, il s’agit en réalité d’un « moteur d’analyse ».
La vérité est qu'aucun lac de données, hub de données ou entrepôt de données - sur site ou dans le cloud - n'a jamais été en mesure de support efficacement toutes les équipes multidisciplinaires d'analystes commerciaux, d'ingénieurs de données, de data scientists et d'utilisateurs chevronnés au sein des différents secteurs d'activité. C'était évident avant l'existence du cloud, et cela ne fait que s'accentuer à mesure que les équipes tentent d'intégrer de nouveaux ensembles de données (pensez aux services web et à l'IoT) et de fusionner des données semi-structurées dans des référentiels structurés. Ne me parlez même pas du flux de feuilles de données Excel qui était censé disparaître (mais qui n'a jamais disparu) lorsque nous sommes devenus plus sophistiqués en matière d'analyse et de gestion des données.
Mais voilà le problème : il existe de réelles différences entre ces plateformes, et il est important de bien les comprendre. Au final, cependant — attention —, plateformes les différences opérationnelles entre ces plateformes qui expliquent pourquoi elles n'apportent pas le support attendu support l'ensemble des parties prenantes.
Réglage du niveau
Commençons par parler de ce dont nous parlons réellement :
Centre de données
Nous définirons ici un hub de données comme une passerelle par laquelle des données virtuelles ou physiques peuvent être fusionnées, transformées et mises en file d'attente pour être acheminées vers une autre destination. Cette destination peut être une application, une base de données ou un autre type de dépôt (comme un lac de données ou un entrepôt de données). En tout état de cause, les données d'un hub de données sont transitoires ; elles ne sont pas stockées localement et n'ont pas de persistance.
Informatica, par exemple, est un « hub de données » capable de prendre en charge tous les types de données imaginables et de relier à la fois les sources et les destinations de données en amont et en aval. Historiquement, les hubs de données étaient gérés et utilisés par des informaticiens qui travaillaient avec en silo isolés en silo au sein de l'entreprise afin de créer des intégrations là où il n'en existait naturellement aucune.
Data Lake
Contrairement à un hub de données, un lac de données sert de dépôt les données persistantes. Il ne s'agit pas simplement d'un point de transit. Les lacs de données peuvent généralement ingérer et gérer presque tous les types de données et, comme l’illustre Hadoop (qui a longtemps été le type de lac de données le plus populaire), ils fournissent des outils permettant d’enrichir, d’interroger et d’analyser les données qu’ils contiennent. Le problème est que les lacs de données constituent généralement des environnements de test destinés à stocker de grands ensembles de données utilisés dans le cadre de projets expérimentaux menés par des ressources techniques hautement qualifiées, principalement des informaticiens et des développeurs.
Entrepôt de données
Un entrepôt de données se distingue d’un lac de données en ce qu’il sert de dépôt des données persistantes et principalement structurées, constituées de manière incrémentielle au fil du temps à partir de multiples silos de sources de données en aval. Un entrepôt de données se distingue également d’un lac de données en ce qu’il nécessite une technologie de hub de données pour préparer les données en vue de leur ingestion. Les entrepôts de données sur site, tels que ceux proposés par les grands acteurs historiques comme Oracle, IBM et Teradata, sont très centrés sur l’informatique et gérés par un ou plusieurs administrateurs de bases de données (DBA). Bien que la majeure partie des données utilisées par les utilisateurs métier puisse finalement résider dans un entrepôt de données, la plupart de ces utilisateurs n’ont aucune interaction directe avec celui-ci et peuvent même ignorer son existence ou sa nature.
Le caoutchouc virtuel rencontre la route virtuelle
D'un point de vue historique, les hubs de données, les lacs de données et les entrepôts de données présentent tous plusieurs points communs : ils nécessitent chacun du personnel doté de compétences spécialisées pour les mettre en place, les entretenir et les gérer. Il s'agit d'experts capables de traduire les demandes des utilisateurs métier et des analystes non techniciens en requêtes et en rapports pouvant être exécutés sur ces référentiels de données.
Soit dit en passant, la complexité de ces plateformes l’une des raisons du déclin de Hadoop. Les lacs de données Hadoop avaient tendance à devenir de véritables dépotoirs de données, et seuls les développeurs et le personnel informatique hautement qualifié (et coûteux) étaient en mesure de les gérer, ce qui limitait la valeur commerciale qu’un lac de données Hadoop pouvait générer. Il n’est donc pas tout à fait surprenant que, parmi les trois grands fournisseurs qui prenaient autrefois en charge Hadoop, Cloudera soit désormais le seul à rester en lice.
Ce besoin en ressources spécialisées a également eu d’autres répercussions sur l’utilisation des hubs de données, des lacs de données et des entrepôts de données, ce qui a encore compliqué la question initiale : quelle plateforme est la mieux adaptée aux différents cas d’utilisation ? Avec le passage des sur site infrastructures dans le cloud, la demande pour toutes ces ressources spécialisées a diminué. Les fournisseurs de cloud support plus en plus support opérationnel, ce qui a contribué à réduire les coûts d’exploitation. De plus, les changements architecturaux apportés aux dernières générations d’offres cloud (séparation des offres de calcul et de stockage, facturation à l’utilisation, etc.) ont créé des incitations supplémentaires à migrer vers le cloud afin de réduire les coûts.
Accroître encore la complexité
Cependant, alors que tous ces changements structurels se sont opérés, la demande fondamentale d’informations issues des données n’a pas changé. La réponse à la question de savoir comment obtenir au mieux ces informations n’en est devenue que plus difficile à formuler. Les données qui étaient auparavant stockées dans des lacs de données ou des entrepôts de données sur site (via des hubs de données) sont désormais transférées vers le cloud, mais les offres disponibles dans le cloud ne sont pas tout à fait les mêmes que celles proposées sur site. Leurs modèles de stockage d’objets diffèrent. Microsoft, Amazon et Google proposent des référentiels de données persistants et, en ce sens, peuvent s’apparenter à un lac de données, mais ils s’appuient sur d’autres outils pour assurer les fonctions de hub de données et ne peuvent donc être définis que comme de simples référentiels de données. Ils nécessitent toujours une intégration des données ou des fonctionnalités de hub de données, et leur valeur métier reste aussi limitée qu’auparavant. Les personnes qui génèrent directement de la valeur métier — les analystes métier, data scientists et (faute d’un titre spécifique) les autres utilisateurs avancés des métiers — ne peuvent toujours pas accéder facilement aux informations contenues dans les données ni les exploiter.
De nos jours, la plupart des analystes métier et des utilisateurs avancés ont recours aux fonctionnalités d’analyse et de visualisation intégrées à en silo telles que Salesforce, Marketo ou toute autre plateforme ERP dont ils ont besoin pour comprendre les opérations commerciales ou les résultats historiques. Parallèlement, ils cherchent à aller plus loin. Les utilisateurs métier peuvent tenter d’intégrer des données issues de fichiers plats tels qu’Excel ou des données JSON semi-structurées exposées via des API de services web. Souvent, ils font appel au service informatique pour exporter des données depuis un ou plusieurs systèmes, les combiner avec des feuilles de calcul Excel et les envoyer périodiquement vers un cube. Le résultat est bien connu : des pipelines en silo liés à des résultats en silo et de visualisation en silo . À l’insu de ces utilisateurs métier, lorsqu’ils font appel au service informatique, ils peuvent en réalité exploiter un hub de données, car il n’y a pas de persistance des données dans ce hub ; ils l’ont simplement utilisé comme un commutateur pour relier un ensemble de silos de données et un silo d’analyse afin de créer un silo organisationnel ou de projet ad hoc.
Data scientists les ingénieurs de données peuvent utiliser bon nombre des mêmes silos de données, mais ils peuvent également exploiter des données issues d'ensembles semi-structurés, tels que les flux de clics, l'IoT et les services web. Leurs destinations peuvent inclure les mêmes outils de visualisation, mais aussi, bien sûr, analytique avancée destinés à support . Ils peuvent faire appel au service informatique pour les support ces données et, ce faisant, créer le même réseau « spaghetti » de connexions point à point.
En d'autres termes, le dépôt unique et partagé de données promis par les lacs de données, les entrepôts de données et les centres de données reste un rêve irréalisable. Un véritable centre d'analyse n'a pas encore vu le jour - ni sur site, ni dans le nuage.
Et pourtant.
Changement d'orientation
Les fournisseurs d'informatique en nuage commencent à prendre conscience du problème et certains s'efforcent rapidement de le résoudre. Cependant, la plupart d'entre eux le font en s'assurant qu'un entrepôt de données cloud peut agir comme un dépôt données en amont pour tout outil d'analyse, de reporting et de visualisation en aval. Souvent, cela se fait par le biais d'un écosystème de partenaires, comme dans le cas de Snowflake. Cela est nécessaire mais insuffisant pour créer le centre d'analyse dont nous avons tous réellement besoin.
Mais attendez. Un centre d'analyse ? Où était-ce dans les définitions ci-dessus ?
Le fait est que entrepôt de données cloud actuellement un moteur d’analyse, mais sans hub de données intégré en arrière-plan et axé sur des connexions point à point distinctes vers divers outils de BI et d’analyse en avant-plan. Des fournisseurs comme Snowflake ne mentionnent pas les hubs d’analyse, et encore moins ne prétendent en être un. De plus, sans la capacité d’extraire facilement des données depuis des sources de données et de relier des éléments de données composites provenant de ces différentes sources pour les présenter aux outils d’analyse, on ne dispose pas réellement d’un hub d’analyse, principalement parce qu’on ne dispose pas d’un hub de données.
Au lieu d'un simple hub de données ou d'un hub d'analyse, tous deux réservés au service informatique, ce dont on a réellement besoin, c'est d'un hub d'analyse de données pouvant être utilisé par un large éventail d'utilisateurs, tant au sein du service informatique que des différents services de l'entreprise. Nous reviendrons plus en détail sur ce concept et sur son importance dans le prochain article de blog.
Restez connecté
Des informations tirées des données, à votre service.
(par exemple : sales@..., support)
