Compatibilité HiveQL

Un job de type hive exécute votre script HiveQL avec Spark SQL 3.5, dans un seul pod, sur le catalogue Apache Iceberg du locataire. Il n’y a ni HiveServer2, ni Tez, ni métastore Thrift à exploiter : les tables que le script crée sont des tables Iceberg de votre stockage objet, lisibles ensuite par Trino, Spark et les autres jobs du projet.

Cette page dit ce qui passe tel quel, ce qui se réécrit, et comment reprendre les tables qui vivent encore dans un métastore Hive. Les listes de compatibilité viennent de la documentation de Spark et d’Iceberg, citées et datées en bas de page.

Comment le script s’exécute

Étape	Ce qui se passe
Catalogue par défaut	`graal`, le catalogue Iceberg du locataire
Base courante	la base du projet (`USE graal.<base>` est posé avant votre script)
Moteur	`spark-sql` en mode local, cœurs et mémoire du type d’instance choisi
Configuration	les clés `conf` du job passent en `--conf` ; celles qui n’ont pas de sens dans un pod sont écartées
Journal et état	le journal du run porte la sortie de `spark-sql` ; l’état vient du code de sortie

Ce qui passe tel quel

Spark SQL reprend la grande majorité du langage de requête de Hive :

SELECT, GROUP BY, ORDER BY, DISTRIBUTE BY, CLUSTER BY, SORT BY ;
les opérateurs relationnels, arithmétiques et logiques, les constructeurs de types complexes, les fonctions mathématiques et de chaînes ;
les jointures (JOIN, jointures externes, LEFT SEMI JOIN, LEFT ANTI JOIN, CROSS JOIN), les UNION, les sous-requêtes dans FROM, WHERE (IN, EXISTS) et les conditions de jointure ;
les fonctions de fenêtre, l’échantillonnage, EXPLAIN ;
les vues (avec des alias de colonnes explicites pour une vue créée par Hive) ;
les types TINYINT à BIGINT, FLOAT, DOUBLE, DECIMAL, STRING, BINARY, BOOLEAN, TIMESTAMP, DATE, ARRAY<>, MAP<>, STRUCT<> ;
CREATE TABLE … AS SELECT, INSERT INTO, INSERT OVERWRITE, ALTER TABLE.

Ce qui se réécrit

Les tables sont des tables Iceberg : la partie « stockage » du DDL de Hive change de forme.

HiveQL d’origine	Dans graal
`STORED AS ORC` / `PARQUET`, `ROW FORMAT SERDE`	`USING iceberg`, format choisi par `TBLPROPERTIES ('write.format.default'='orc')`
`PARTITIONED BY (dt STRING)`	`PARTITIONED BY (dt)` sur une colonne de la table, ou une transformation : `days(ts)`, `months(ts)`
`CLUSTERED BY (id) INTO 16 BUCKETS`	`PARTITIONED BY (bucket(16, id))`
`LOCATION 'hdfs://…'`	rien à écrire : la table vit dans le stockage objet du catalogue ; les fichiers HDFS se copient avant
`CREATE TABLE … LIKE`	`CREATE TABLE … AS SELECT … LIMIT 0`, ou un DDL explicite
`SET hive.exec.`, `SET mapreduce.`	sans effet : Spark ne lit pas les réglages de Hive ni de MapReduce

INSERT OVERWRITE sur une table partitionnée suit le mode de Spark, statique par défaut : sans clause PARTITION, c’est la table entière qui est remplacée. Pour retrouver le comportement de Hive (seules les partitions produites par la requête sont remplacées), commencez le script par SET spark.sql.sources.partitionOverwriteMode=dynamic;, le mode que recommande Iceberg. Les transformations de partition d’Iceberg (years, months, days, hours, bucket, truncate) remplacent les colonnes de partition calculées à la main.

Différences de comportement à connaître

Ces fonctions de Hive existent dans Spark SQL mais rendent un autre résultat :

Expression	Hive	Spark SQL
`SQRT(n)` avec `n < 0`	`NULL`	`NaN`
`ACOS(n)`, `ASIN(n)` hors de `[-1, 1]`	`NULL`	`NaN`
`CAST(n AS TIMESTAMP)`, `n` entier	`n` en millisecondes	`n` en secondes

Et ces fonctions de Hive n’ont pas d’équivalent dans Spark SQL : le type UNIONTYPE, la clause UNIQUEJOIN, les index bitmap et les colonnes virtuelles, l’indication de jointure STREAMTABLE, la lecture des archives Hadoop (HAR). Les optimisations propres à Hive (nombre de reducers, fusion des petits fichiers en sortie, indicateur de données asymétriques) sont remplacées par celles de Spark. Une fonction Java écrite pour Hive (UDF, UDAF, UDTF) s’appelle depuis Spark SQL, à l’exception de quelques méthodes de l’API Hive que Spark n’appelle pas (getRequiredJars, getRequiredFiles, configure, close, reset, getWindowingEvaluator).

Reprendre les tables d’un métastore Hive

Besoin	Ce qu’on utilise
Lire les tables existantes en place	une connexion de données `hive_metastore`, citée par le job
Copier des fichiers HDFS vers S3	le type de job `hdfs-copy`, qui vérifie fichiers et octets après la copie
Convertir une table Hive en table Iceberg	le type de job `iceberg-migration` (`snapshot`, `migrate`, `add_files`)
Inventorier un cluster avant de migrer	le type de job `hadoop-assess`, qui produit un rapport du parc

Sources

Apache Spark 3.5.6, « Compatibility with Apache Hive », consulté le 29 octobre 2026.
Apache Iceberg 1.10.0, « Spark DDL », consulté le 29 octobre 2026.