Moteur de table HDFS

Ce moteur assure l’intégration avec l’écosystème Apache Hadoop en permettant de gérer des données sur HDFS via ClickHouse. Il est similaire aux moteurs File et URL, mais offre des fonctionnalités propres à Hadoop.

Cette fonctionnalité n’est pas prise en charge par les ingénieurs ClickHouse et sa qualité est réputée incertaine. En cas de problème, corrigez-le vous-même et soumettez une pull request.

ENGINE = HDFS(URI, format)

Paramètres du moteur

• URI - URI complète du fichier dans HDFS. La partie chemin de URI peut contenir des globs. Dans ce cas, la table sera en lecture seule.
• format - spécifie l’un des formats de fichier disponibles. Pour exécuter des requêtes SELECT, le format doit être pris en charge en entrée, et pour exécuter des requêtes INSERT – en sortie. Les formats disponibles sont répertoriés dans la section Formats.
• [PARTITION BY expr]

PARTITION BY — Facultatif. Dans la plupart des cas, vous n’avez pas besoin de clé de partition et, si c’est nécessaire, vous n’avez généralement pas besoin d’une clé de partition plus fine qu’un partitionnement mensuel. Le partitionnement n’accélère pas les requêtes (contrairement à l’expression ORDER BY). N’utilisez jamais un partitionnement trop fin. Ne partitionnez pas vos données par identifiant ou nom de client (faites plutôt de l’identifiant ou du nom du client la première colonne de l’expression ORDER BY).

Pour un partitionnement par mois, utilisez l’expression toYYYYMM(date_column), où date_column est une colonne de type Date. Les noms de partition sont ici au format "YYYYMM".

Exemple :

1. Configurez la table hdfs_engine_table :

CREATE TABLE hdfs_engine_table (name String, value UInt32) ENGINE=HDFS('hdfs://hdfs1:9000/other_storage', 'TSV')

2. Renseigner le fichier :

INSERT INTO hdfs_engine_table VALUES ('one', 1), ('two', 2), ('three', 3)

3. Interrogez les données :

SELECT * FROM hdfs_engine_table LIMIT 2

┌─name─┬─value─┐
│ one  │     1 │
│ two  │     2 │
└──────┴───────┘

• Les lectures et les écritures peuvent être parallèles.
• Non pris en charge :
  • les opérations ALTER et SELECT...SAMPLE.
  • les index.
  • La réplication zero-copy est possible, mais n’est pas recommandée.

Globs dans le chemin

Plusieurs composants du chemin peuvent contenir des globs. Pour être traité, un fichier doit exister et correspondre à l’intégralité du motif de chemin. La liste des fichiers est établie lors du SELECT (et non au moment du CREATE).

• * — Remplace n’importe quel nombre de caractères, sauf /, y compris la chaîne vide.
• ? — Remplace n’importe quel caractère unique.
• {some_string,another_string,yet_another_one} — Remplace l’une des chaînes 'some_string', 'another_string', 'yet_another_one'.
• {N..M} — Remplace n’importe quel nombre dans l’intervalle de N à M, bornes incluses.

Les constructions avec {} sont similaires à la fonction de table remote.

Exemple

1. Supposons que nous ayons plusieurs fichiers au format TSV avec les URI suivantes sur HDFS :

   • 'hdfs://hdfs1:9000/some_dir/some_file_1'
   • 'hdfs://hdfs1:9000/some_dir/some_file_2'
   • 'hdfs://hdfs1:9000/some_dir/some_file_3'
   • 'hdfs://hdfs1:9000/another_dir/some_file_1'
   • 'hdfs://hdfs1:9000/another_dir/some_file_2'
   • 'hdfs://hdfs1:9000/another_dir/some_file_3'

2. Il existe plusieurs façons de créer une table constituée de ces six fichiers :

CREATE TABLE table_with_range (name String, value UInt32) ENGINE = HDFS('hdfs://hdfs1:9000/{some,another}_dir/some_file_{1..3}', 'TSV')

Autre méthode :

CREATE TABLE table_with_question_mark (name String, value UInt32) ENGINE = HDFS('hdfs://hdfs1:9000/{some,another}_dir/some_file_?', 'TSV')

La table comprend tous les fichiers des deux répertoires (tous les fichiers doivent respecter le format et le schéma décrits dans la requête) :

CREATE TABLE table_with_asterisk (name String, value UInt32) ENGINE = HDFS('hdfs://hdfs1:9000/{some,another}_dir/*', 'TSV')

Exemple

Créer une table avec des fichiers nommés file000, file001, … , file999:

CREATE TABLE big_table (name String, value UInt32) ENGINE = HDFS('hdfs://hdfs1:9000/big_dir/file{0..9}{0..9}{0..9}', 'CSV')

Comme GraphiteMergeTree, le moteur HDFS prend en charge une configuration étendue via le fichier de configuration de ClickHouse. Vous pouvez utiliser deux clés de configuration : une globale (hdfs) et une au niveau utilisateur (hdfs_*). La configuration globale est appliquée en premier, puis celle au niveau utilisateur est appliquée (si elle existe).

<!-- Global configuration options for HDFS engine type -->
<hdfs>
<hadoop_kerberos_keytab>/tmp/keytab/clickhouse.keytab</hadoop_kerberos_keytab>
<hadoop_kerberos_principal>clickuser@TEST.CLICKHOUSE.TECH</hadoop_kerberos_principal>
<hadoop_security_authentication>kerberos</hadoop_security_authentication>
</hdfs>

<!-- Configuration specific for user "root" -->
<hdfs_root>
<hadoop_kerberos_principal>root@TEST.CLICKHOUSE.TECH</hadoop_kerberos_principal>
</hdfs_root>

La référence de configuration HDFS peut fournir des explications sur certains paramètres.

• hadoop_security_kerberos_ticket_cache_path et libhdfs3_conf ne peuvent être définis qu'au niveau global, et non au niveau de l'utilisateur

Si le paramètre hadoop_security_authentication a pour valeur kerberos, ClickHouse s’authentifie via Kerberos. Les paramètres sont disponibles ici, et hadoop_security_kerberos_ticket_cache_path peut s’avérer utile. Notez qu’en raison des limitations de libhdfs3, seule l’approche traditionnelle est prise en charge : les communications avec le datanode ne sont pas sécurisées par SASL (HADOOP_SECURE_DN_USER est un indicateur fiable de cette approche de sécurité). Utilisez tests/integration/test_storage_kerberized_hdfs/hdfs_configs/bootstrap.sh comme référence.

Si hadoop_kerberos_keytab, hadoop_kerberos_principal ou hadoop_security_kerberos_ticket_cache_path sont spécifiés, l’authentification Kerberos sera utilisée. Dans ce cas, hadoop_kerberos_keytab et hadoop_kerberos_principal sont obligatoires.

libhdfs3 prend en charge la haute disponibilité du namenode HDFS.

• Copiez hdfs-site.xml d’un nœud HDFS vers /etc/clickhouse-server/.
• Ajoutez l’extrait suivant au fichier de configuration de ClickHouse :

<hdfs>
    <libhdfs3_conf>/etc/clickhouse-server/hdfs-site.xml</libhdfs3_conf>
</hdfs>

• Utilisez ensuite la valeur de dfs.nameservices dans hdfs-site.xml comme adresse du namenode dans l’URI HDFS. Par exemple, remplacez hdfs://appadmin@192.168.101.11:8020/abc/ par hdfs://appadmin@my_nameservice/abc/.

• _path — Chemin d’accès au fichier. Type : LowCardinality(String).
• _file — Nom du fichier. Type : LowCardinality(String).
• _size — Taille du fichier en octets. Type : Nullable(UInt64). Si la taille est inconnue, la valeur est NULL.
• _time — Date et heure de la dernière modification du fichier. Type : Nullable(DateTime). Si l’heure est inconnue, la valeur est NULL.
• _etag — ETag du fichier. Type : LowCardinality(String). HDFS ne dispose pas d’ETag natif ; la valeur est donc synthétisée à partir de l’heure de modification et de la taille du fichier, sous la forme <mtime_seconds>_<size>. Étant donné que libhdfs3 n’expose l’heure de modification qu’avec une précision d’une seconde, une réécriture effectuée au cours de la même seconde et conservant la même taille produit la même valeur ; c’est pourquoi cet ETag synthétisé n’est pas utilisé comme clé de cache de contenu.

• hdfs_truncate_on_insert - permet de tronquer le fichier avant d’y insérer des données. Désactivé par défaut.
• hdfs_create_new_file_on_insert - permet de créer un nouveau fichier à chaque insertion si le format comporte un suffixe. Désactivé par défaut.
• hdfs_skip_empty_files - permet d’ignorer les fichiers vides lors de la lecture. Désactivé par défaut.

Voir aussi

• Colonnes virtuelles