Moteur de table HDFS

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

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.

​

Utilisation

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

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 │
└──────┴───────┘

​

Détails d’implémentation

• 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.

La réplication zero-copy n’est pas prête pour la production

La réplication zero-copy est désactivée par défaut dans ClickHouse 22.8 et les versions ultérieures. Cette fonctionnalité n’est pas recommandée pour une utilisation en production.

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')

Si la liste des fichiers contient des plages de nombres avec des zéros non significatifs, utilisez une construction avec des accolades pour chaque chiffre séparément, ou utilisez ?.

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')

​

Configuration

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>[e-mail]</hadoop_kerberos_principal>
  <hadoop_security_authentication>kerberos</hadoop_security_authentication>
</hdfs>

<!-- Configuration specific for user "root" -->
<hdfs_root>
  <hadoop_kerberos_principal>[e-mail]</hadoop_kerberos_principal>
</hdfs_root>

​

Options de configuration

​

Pris en charge par libhdfs3

paramètre	valeur par défaut
rpc_client_connect_tcpnodelay	true
dfs_client_read_shortcircuit	true
output_replace-datanode-on-failure	true
input_notretry-another-node	false
input_localread_mappedfile	true
dfs_client_use_legacy_blockreader_local	false
rpc_client_ping_interval	10 * 1000
rpc_client_connect_timeout	600 * 1000
rpc_client_read_timeout	3600 * 1000
rpc_client_write_timeout	3600 * 1000
rpc_client_socket_linger_timeout	-1
rpc_client_connect_retry	10
rpc_client_timeout	3600 * 1000
dfs_default_replica	3
input_connect_timeout	600 * 1000
input_read_timeout	3600 * 1000
input_write_timeout	3600 * 1000
input_localread_default_buffersize	1 * 1024 * 1024
dfs_prefetchsize	10
input_read_getblockinfo_retry	3
input_localread_blockinfo_cachesize	1000
input_read_max_retry	60
output_default_chunksize	512
output_default_packetsize	64 * 1024
output_default_write_retry	10
output_connect_timeout	600 * 1000
output_read_timeout	3600 * 1000
output_write_timeout	3600 * 1000
output_close_timeout	3600 * 1000
output_packetpool_size	1024
output_heartbeat_interval	10 * 1000
dfs_client_failover_max_attempts	15
dfs_client_read_shortcircuit_streams_cache_size	256
dfs_client_socketcache_expiryMsec	3000
dfs_client_socketcache_capacity	16
dfs_default_blocksize	64 * 1024 * 1024
dfs_default_uri	”hdfs://localhost:9000”
hadoop_security_authentication	”simple”
hadoop_security_kerberos_ticket_cache_path	""
dfs_client_log_severity	”INFO”
dfs_domain_socket_path	""

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

​

Options supplémentaires de ClickHouse

paramètre	valeur par défaut
hadoop_kerberos_keytab	""
hadoop_kerberos_principal	""
libhdfs3_conf	""

​

Limites

• 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

​

Prise en charge de Kerberos

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.

​

Prise en charge de la haute disponibilité du namenode HDFS

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/.

​

Colonnes virtuelles

• _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.

​

Paramètres de stockage

• 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