Feuille de route ODP 1.3.2.0
Cette page présente les priorités fonctionnelles d'ODP 1.3.2.0. Il s'agit d'une feuille de route produit, et non d'un calendrier de publication.
En bref
ODP 1.3.2.0 prolonge la dynamique de la gamme 1.3 avec une ambition claire : consolider la fondation lakehouse, élargir l'offre analytique SQL et moderniser le pilotage de la plateforme, sur des clusters classiques comme dans des scénarios hybrides avec Kubernetes.
- une gouvernance Iceberg de bout en bout entre Hive, Spark, Impala, Trino, Atlas, Ranger et Polaris
- une couche SQL interactive renforcée avec Impala et Kudu comme services gérés
- un modèle d'exploitation plus souple grâce à OIDC, à une gestion plus fine des runtimes Java, à une meilleure prise en compte d'Ozone et à des workflows Kubernetes
Trajectoire des versions
La feuille de route 1.3.2.0 s'articule notamment autour des évolutions de versions suivantes :
| Composant | 1.3.1.0 | Cible 1.3.2.0 | Apport attendu |
|---|---|---|---|
| Socle Hadoop | 3.4.1 | 3.4.2 | maintenance de plateforme et mises à jour de compatibilité |
| Hive | 4.0.1 | 4.2.0 | surface d'API Hive plus récente pour les moteurs et intégrations |
| Iceberg | 1.6.1 | 1.10.1 | maturité accrue du format de table et meilleur alignement moteur |
| HBase | 2.6.1 | 2.6.4 | stabilité et alignement de plateforme |
| Ozone | 2.0.0 | 2.1.0 | intégration renforcée pour l'objet et les HCFS |
| Ranger | 2.6.0 | 2.7.0 | gouvernance élargie et support plugin renforcé |
| NiFi | 1.28.1 | 2.8.0 | rafraîchissement majeur du runtime dataflow |
| Livy | 0.8.0 | 0.9.0 | couche de soumission Spark modernisée |
| Phoenix | 5.2.1 | 5.3.0 | évolution du moteur SQL pour les charges HBase |
| TEZ | 0.10.4 | 0.10.5 | mises à jour de compatibilité du moteur d'exécution |
| ZooKeeper | 3.9.3 | 3.9.4 | maintenance et corrections de runtime |
| Zeppelin | 0.11.1 | 0.12.0 | runtime notebook plus récent et intégrations étendues |
| Impala | 4.5.0 | 5.0.0 | moteur SQL haute performance renforcé |
| Kudu | non livré comme service géré | 1.18.1 | stockage analytique à faible latence pour les usages Impala |
| Polaris | non présent | 1.3.0 | service de catalogue Iceberg et de contrôle d'accès |
Axes structurants
1. Une fondation lakehouse gouvernée de bout en bout
ODP 1.3.2.0 renforce nettement la plateforme autour d'Iceberg et de la gouvernance des métadonnées :
- Hive évolue vers 4.2.0 et Iceberg vers 1.10.1
- Atlas étend la couverture des métadonnées et de la traçabilité pour Hive, Spark, Impala et Trino
- Polaris apporte une couche de catalogue gérée, avec outillage d'exploitation, support TLS et intégration de service
- Ranger 2.7.0 consolide la gouvernance avec l'intégration Polaris, l'évolution du mapping Atlas et la synchronisation des tags OpenMetadata
L'objectif n'est pas seulement de mettre à jour les composants, mais de proposer une base lakehouse gouvernée de manière cohérente.
2. Une offre SQL plus complète pour l'analytique
ODP 1.3.2.0 élargit sensiblement le périmètre analytique interactif :
- Impala 5.0.0 rejoint les services gérés de la plateforme
- Kudu 1.18.1 complète Impala pour les usages analytiques à faible latence
- Trino conserve un rôle central dans la stratégie d'accès SQL et bénéficie du renforcement de la gouvernance
- Superset enrichit la couche BI et la restitution autour des moteurs SQL
La plateforme gagne ainsi en cohérence pour les usages batch, interactifs et décisionnels.
3. Un plan de contrôle Ambari plus souple
Par rapport au socle 1.3 actuel, ODP 1.3.2.0 étend ce que le plan de contrôle peut administrer et gouverner :
| Périmètre du plan de contrôle | Situation actuelle | Orientation 1.3.2.0 |
|---|---|---|
| Services gérés | périmètre historique ODP | ajoute CORE, IMPALA, KUDU, OIDC et POLARIS |
| Architecture de stockage | HDFS reste le modèle dominant | introduit CORE comme abstraction de système de fichiers et améliore la prise en charge d'Ozone |
| Identité et accès | fonctionnement d'abord centré sur Kerberos | ouvre la plateforme à OIDC et à des parcours d'authentification plus souples |
| Stratégie Java | séparation limitée entre le runtime Ambari et celui des composants | clarifie les besoins Ambari et composants avec une gestion plus fine des JDK |
| Mises à niveau | couverture centrée sur le périmètre 1.3 existant | étend les mécanismes de mise à niveau et le packaging au nouveau périmètre 1.3.2.0 |
Concrètement, Ambari ne se limite plus au périmètre historique : il prépare un pilotage plus large et plus flexible de la plateforme.
4. Une plateforme modernisée
ODP 1.3.2.0 fait également progresser la base technique de la distribution :
- progression de la compatibilité JDK 21 sur plusieurs services, notamment Knox, Oozie, Atlas, Spark et Zeppelin
- renforcement du support système sur Ubuntu 22/24, RHEL 9 et aarch64
- alignement du packaging et des dépendances avec des piles runtime plus récentes
- amélioration du comportement des installations côte à côte et des mises à niveau entre 1.2 et 1.3
5. Une trajectoire hybride avec Kubernetes
ODP 1.3.2.0 ouvre aussi la voie à un mode d'exploitation hybride pour certains services analytiques déployés sur Kubernetes :
- des workflows Helm pour l'installation, la mise à jour, le rollback et la désinstallation
- des opérations en arrière-plan avec suivi de la progression
- la supervision des releases orientée GitOps et Flux
- des modèles de services pour Trino et Superset
- l'intégration de Ranger, de LDAP, de Vault et des mécanismes keytab pour des déploiements sécurisés
Cette trajectoire prépare des environnements où une partie de la couche analytique est opérée sur Kubernetes tout en restant alignée avec les exigences de gouvernance et de sécurité de la plateforme.
Ce que cela change pour les équipes plateforme
- une stack lakehouse gouvernée plus forte autour d'Iceberg, Atlas, Ranger et Polaris
- un portefeuille SQL plus large avec Impala, Kudu, Trino et Superset
- des topologies de sécurité et de stockage plus souples grâce à OIDC et CORE
- une trajectoire plus lisible vers un mode d'exploitation hybride entre infrastructure classique et Kubernetes
Positionnement recommandé
ODP 1.3.2.0 doit être présenté comme la prochaine grande étape fonctionnelle après 1.3.1.0 : une version pensée pour accélérer l'adoption d'un lakehouse gouverné, enrichir les services analytiques et moderniser le modèle d'exploitation.