Interview animé par François DORLEANS et répondu par Raphaël COMBAUD.
L’éditeur Cloudera organisait le 5 septembre dernier un atelier d’une demi-journée à propos de Apache Iceberg.
Notre collègue, Raphaël Combaud, tech leader Big Data, était présent. Voici son retour d’expérience sur cet atelier.
L’éditeur Cloudera organisait le 5 septembre dernier un atelier d’une demi-journée à propos de Apache Iceberg.
Notre collègue, Raphaël Combaud, tech leader Big Data, était présent. Voici son retour d’expérience sur cet atelier.
Peux-tu nous situer cette brique technologique dans le paysage du big data ?
Apache Iceberg est un nouveau format de table hive qui vise à répondre à un ensemble de besoin (performance, résilience, faciliter les tests, faciliter le maintien de version concurrentes des données …).
Elle apparait dans le cadre de l’offre Datalakehouse (contraction de datalake et warehouse) dévelopée par Cloudera.
Elle apparait dans le cadre de l’offre Datalakehouse (contraction de datalake et warehouse) dévelopée par Cloudera.
Quelles sont les origines d' Apache Iceberg ? Quand a-t-il été intégré par Cloudera ?
Ce format a été développé à l’origine par Netflix, qui en a ensuite fait don à la fondation open source Apache en 2018.
Son intégration par Cloudera à son écosystème est quant à elle beaucoup plus récente.
Son intégration par Cloudera à son écosystème est quant à elle beaucoup plus récente.
Comment Cloudera justifie son intégration dans leur stack ?
Il s’agit de ne pas se laisser distancer par la concurrence.
L’éditeur a-t-il partagé des retours d’expériences ?
Non, pas encore. C’est très prometteur, mais le lancement vient seulement d’avoir lieu.
Des fonctionnalités importantes sont encore attendues soit pour la fin de cette année soit au début de l’année prochaine (notamment le « linéage »).
Des fonctionnalités importantes sont encore attendues soit pour la fin de cette année soit au début de l’année prochaine (notamment le « linéage »).
Quelle est la maturité de cette solution ?
Je dirais « production grade » (bon pour de la production) ?
Enfin, avec des réserves toutefois.
Il y a un « vieux » problème « connu et non résolu » qui perdure.
Lorsqu’une compaction et une requête s’exécute sur la même table, l’une de deux échouera.
Si c’est la compaction : on n’aura pas le gain en performance qu’on peut attendre d’une « table compactée ».
Si c’est la requête, il faudra la relancer, ce qui est gênant pour l’utilisateur.
Mais bon, ce problème n’est pas nouveau, il n’est pas introduit avec ce nouveau format de table.
Enfin, avec des réserves toutefois.
Il y a un « vieux » problème « connu et non résolu » qui perdure.
Lorsqu’une compaction et une requête s’exécute sur la même table, l’une de deux échouera.
Si c’est la compaction : on n’aura pas le gain en performance qu’on peut attendre d’une « table compactée ».
Si c’est la requête, il faudra la relancer, ce qui est gênant pour l’utilisateur.
Mais bon, ce problème n’est pas nouveau, il n’est pas introduit avec ce nouveau format de table.
Comment comprends-tu le ROI ?
L’investissement sera certainement justifié si l’on est dans l’une des problématiques suivantes :
Si les clients se plaignent de lenteur à l’exécution de leur requête hive et le service Hivemetastore est clairement un goulet d’étranglement en termes de performances.
Ici, c’est le format de table Iceberg (qui inclut les méta-informations au même endroit que les données) qui va résoudre ce problème de performance.
Si le rythme des évolutions est élevé ; les modifications sont fréquentes et chaque erreur qui entraine un retour arrière s’avère très couteuses.
Ici, la résilience, les snapshots et la possibilité de branching et de tagging va apporter des solutions nouvelles et élégantes à l’ensemble de ces problèmes.
Si on a besoin d’avoir une granularité fine en terme de date, et que la possibilité de « naviguer », de se déplacer rapidement d’une date à une autre présente un avantage pour le client.
Ici, c’est la timeline ou encore le « lineage » qui permettra de répondre à ce besoin.
Si les clients se plaignent de lenteur à l’exécution de leur requête hive et le service Hivemetastore est clairement un goulet d’étranglement en termes de performances.
Ici, c’est le format de table Iceberg (qui inclut les méta-informations au même endroit que les données) qui va résoudre ce problème de performance.
Si le rythme des évolutions est élevé ; les modifications sont fréquentes et chaque erreur qui entraine un retour arrière s’avère très couteuses.
Ici, la résilience, les snapshots et la possibilité de branching et de tagging va apporter des solutions nouvelles et élégantes à l’ensemble de ces problèmes.
Si on a besoin d’avoir une granularité fine en terme de date, et que la possibilité de « naviguer », de se déplacer rapidement d’une date à une autre présente un avantage pour le client.
Ici, c’est la timeline ou encore le « lineage » qui permettra de répondre à ce besoin.
Que représente, en terme d’effort, une migration vers Apache Iceberg ?
Cloudera a envisagé deux types de migration : avec duplication des données et sans duplication des données.
Selon le type de table Hive (externe ou ACID) on choisira l’une ou l’autre stratégie.
Lors de l’atelier, nous avons pu tester la migration « in-place » : c’était d’une facilité déconcertante.
Par exemple, en partant de la table existante, on crée une nouvelle table au format iceberg en une seule ligne de commande :
Selon le type de table Hive (externe ou ACID) on choisira l’une ou l’autre stratégie.
Lors de l’atelier, nous avons pu tester la migration « in-place » : c’était d’une facilité déconcertante.
Par exemple, en partant de la table existante, on crée une nouvelle table au format iceberg en une seule ligne de commande :
Attention : les données ne sont pas dupliquées! Les informations du métastore hive sont « rapatrié avec les données ».
Cette migration n’occupe donc que très peu d’espace supplémentaire et soulage le service Hivemetastore lors de l’exécution des requêtes sql.
Si sa mise en route s’apparente à un jeu d’enfant alors ce sera clairement un autre atout de ce nouveau format.
CTAS = Create Table As Select
RTAS = Read Table As Select
Est-ce que je peux utiliser Apache Iceberg sans CDP ?
Ce format est disponible à partir de CDP 7.1.9.
Mais comme c’est un format opensource on le retrouve dans d’autres offres, comme par exemple Snowflake.
Mais comme c’est un format opensource on le retrouve dans d’autres offres, comme par exemple Snowflake.
A quels besoins répond Iceberg ? Autrement dit, quelles sont ses principales fonctionnalités ?
Quitte à me répéter, on trouve :
- La colocalisation des métadonnées avec les données elles-mêmes, ce qui améliore les performances des requêtes.
- Les snapshots : c’est-à-dire la possibilité de réaliser un instantané des données à une date précise, à un moment précis dans le temps.
- Le versioning : qui comme pour git, consiste à pouvoir de créer des branches et merger vers la branche « master ».
- La timeline qui offre la possibilité de naviguer dans les snapshots et les branches.
As-tu eu l’occasion de pratiquer ? Quelles sont tes premières impressions ?
J’ai fait tous les labs, donc j’ai une vue d’ensemble des principales possibilités offertes. Mais ce n’est pas comparable à « une expérience au quotidien ».
Sinon, mon impression est très positive. Il y a vraiment un avantage à avoir des snapshots des tables, une « timeline », des branches (comme avec git par exemple !).
Ces fonctionnalités facilitent grandement le travail.
Sinon, mon impression est très positive. Il y a vraiment un avantage à avoir des snapshots des tables, une « timeline », des branches (comme avec git par exemple !).
Ces fonctionnalités facilitent grandement le travail.
Dans quel environnement a eu lieu cet atelier ?
2 vms de taille moyenne. Une s’appuyant sur hue; l’autre sur impala.
Par rapport à ta mission actuelle, vois-tu une réponse Iceberg pour ton client ?
Oui. Pour une amélioration des performances ainsi qu’une plus grande souplesse de gestion pour tout ce qui concerne les données conservées sous hive.
Quels sont les pré-requis pour adopter Iceberg en termes d’infra, de compétences, de data management et d’organisation ?
Pour dire les choses très simplement, s’il y a déjà toute une solution en place pour Hive ; alors tous les prérequis sont là pour passer à Iceberg.
Si le client part de zéro, il faut étudier la question et donc passer par la case « Architecture » avant de se lancer…
Merci Raphaël pour ce partage.
François DORLEANS
