Big SQL prend en charge différents formats de fichiers. Lisez cet article pour plus d’informations sur les différents formats de fichiers pris en charge par Big SQL. La distinction du type de format de fichier à utiliser se fait lors de la création de la table. Big SQL prend en charge la création et la population de tables à partir de Big SQL et de Hive. L’un des plus grands avantages de Big SQL est que Big SQL se synchronise avec le Metastore de Hive. Cela signifie que les tables Big SQL peuvent être créées et alimentées dans Big SQL ou créées dans Big SQL et alimentées depuis Hive. Les tables Hive peuvent également être peuplées à partir de Hive, puis accessibles à partir de Big SQL après la synchronisation des catalogues.
Lorsque l’on charge des données dans des tables Parquet, Big SQL utilisera la compression SNAPPY par défaut. Pour Hive, par défaut la compression n’est pas activée, en conséquence la table pourrait être significativement plus grande si elle est créée et/ou peuplée dans Hive. Les sections suivantes décriront comment activer la compression SNAPPY pour les tables peuplées dans Hive sur IBM Open Platform (avant Big SQL v5) et HortonWorks Data Platform (à partir de Big SQL v5 et à venir).
Création d’une table Big SQL en utilisant le format Parquet
Lorsque des tables sont créées dans Big SQL, le format Parquet peut être choisi en utilisant la clause STORED AS PARQUET dans l’instruction CREATE HADOOP TABLE comme dans cet exemple:
jsqsh>CREATE HADOOP TABLE inventory ( trans_id int, product varchar(50), trans_dt date ) PARTITIONED BY ( year int) STORED AS PARQUET
Par défaut, Big SQL utilisera la compression SNAPPY lors de l’écriture dans les tables Parquet. Cela signifie que si les données sont chargées dans Big SQL à l’aide des commandes LOAD HADOOP ou INSERT…SELECT, alors la compression SNAPPY est activée par défaut.
Création d’une table Hive à l’aide du format Parquet
Si les tables Parquet sont créées à l’aide de Hive, alors la compression n’est pas activée par défaut. L’exemple suivant montre la syntaxe d’une table Parquet créée dans Hive:
hive> CREATE TABLE inv_hive ( trans_id int, product varchar(50), trans_dt date ) PARTITIONED BY ( year int) STORED AS PARQUET
Notez que la syntaxe est la même pourtant le comportement est différent. Par défaut, Hive n’utilisera aucune compression lors de l’écriture dans les tables Parquet.
Comparaison des tailles de table Big SQL et Hive Parquet
Le tableau suivant montre la taille d’une table utilisant le format de fichier Parquet lorsque la table est alimentée à l’aide de Big SQL LOAD HADOOP et Big SQL INSERT…SELECT par rapport à Hive INSERT…SELECT :
| Big SQL LOAD | Big SQL INSERT…SELECT | La table est remplie en utilisant Big SQL LOAD…SELECT..SELECT | Hive INSERT..SELECT |
|---|---|---|---|
| 164 GB | 165 GB | 280 GB |
Comme les fichiers Parquet créés avec Big SQL sont compressés, la taille globale de la table est beaucoup plus petite. La table créée et alimentée en Big SQL fait presque la moitié de la taille de la table créée en Big SQL puis alimentée depuis Hive.
Activer la compression SNAPPY dans Hive
À partir de Hive 0.13, la propriété de table ‘PARQUET.COMPRESS’=’SNAPPY’ peut être définie pour activer la compression SNAPPY. Vous pouvez également définir parquet.compression=SNAPPY dans la section « Custom hive-site settings » dans Ambari pour IOP ou HDP, ce qui garantira que Hive compresse toujours tout fichier Parquet qu’il produit. Voici un exemple d’utilisation de la propriété de table pendant une déclaration de création de table dans Hive:
hive> CREATE TABLE inv_hive_parquet( trans_id int, product varchar(50), trans_dt date ) PARTITIONED BY ( year int) STORED AS PARQUET TBLPROPERTIES ('PARQUET.COMPRESS'='SNAPPY');
Notez que si la table est créée dans Big SQL et ensuite peuplée dans Hive, alors cette propriété de table peut également être utilisée pour activer la compression SNAPPY. Par exemple, voici la syntaxe pour créer une table Big SQL avec la compression SNAPPY activée. Cela peut être utile si les instructions INSERT…SELECT doivent être pilotées depuis Hive.
jsqsh> CREATE HADOOP TABLE inv_bigsql_parquet( trans_id int, product varchar(50), trans_dt date ) PARTITIONED BY ( year int) STORED AS PARQUET TBLPROPERTIES ('PARQUET.COMPRESS'='SNAPPY');
Avec la compression snappy activée dans Hive, nous avons observé les tailles de table suivantes :
| Big SQL LOAD | Big SQL INSERT..SELECT | Hive INSERT..SELECT | 164 Go | 165 Go | 163 Go |
|---|
Avec cette propriété la taille de la table est passée de 280 Go à 163 Go, ce qui représente une compression approximative de presque deux fois. Non seulement la table prendra moins de place sur HDFS, mais il peut également y avoir un gain de performance significatif lors de l’accès aux données pour Big SQL ou Hive. La recommandation est soit de définir ‘parquet.compress=SNAPPY’ dans les TBLPROPERTIES lors de la création d’une table Parquet, soit de définir ‘parquet.compression.SNAPPY’ dans le site de ruche via Ambari. Cela garantit que tous les fichiers Parquet produits par Hive liés à cette table seront compressés.
Mon grand merci à Abhayan Sundararajan de l’équipe Big SQL Performance pour la découverte et les contributions à cet article.