Si vous utilisez ClickHouse Cloud sur Google Cloud, cette page ne vous concerne pas, car vos services utilisent déjà Google Cloud Storage. Si vous cherchez à SELECT ou INSERT des données depuis GCS, veuillez consulter la fonction de table gcs.
ClickHouse considère que GCS est une solution de stockage intéressante si vous souhaitez dissocier le stockage et la puissance de calcul. Pour cela, la prise en charge de GCS comme couche de stockage pour le moteur MergeTree est disponible. Vous pouvez ainsi bénéficier de la scalabilité et des avantages en termes de coût de GCS, tout en conservant les performances d’insertion et de requête du moteur MergeTree.
Pour utiliser un bucket GCS comme disque, il faut d’abord le déclarer dans la configuration de ClickHouse, dans un fichier situé sous conf.d. Un exemple de déclaration d’un disque GCS est présenté ci-dessous. Cette configuration comprend plusieurs sections permettant de configurer le « disque » GCS, le cache et la policy spécifiée dans les requêtes DDL lorsque des tables doivent être créées sur le disque GCS. Chacun de ces éléments est décrit ci-dessous.
Les politiques de stockage permettent de choisir où les données sont stockées. La politique mise en évidence ci-dessous permet de stocker les données sur le disque gcs en spécifiant la politique gcs_main. Par exemple, CREATE TABLE ... SETTINGS storage_policy='gcs_main'.
Si votre disque est configuré pour utiliser un bucket avec un accès en écriture, vous devriez pouvoir créer une table comme dans l’exemple ci-dessous. Par souci de concision, nous utilisons un sous-ensemble des colonnes des taxis de New York et envoyons les données directement vers la table adossée à GCS :
Selon la configuration matérielle, cette dernière insertion de 1m lignes peut prendre quelques minutes. Vous pouvez en suivre la progression dans la table system.processes. N’hésitez pas à ajuster le nombre de lignes jusqu’à 10m et à essayer quelques exemples de requêtes.
SELECT passenger_count, avg(tip_amount) AS avg_tip, avg(total_amount) AS avg_amount FROM trips_gcs GROUP BY passenger_count;
L’Cloud Storage XML API est compatible avec certains outils et certaines bibliothèques qui fonctionnent avec des services tels qu’Amazon Simple Storage Service (Amazon S3).Pour en savoir plus sur l’ajustement des threads, consultez Optimizing for Performance.
Ce tutoriel décrit un déploiement ClickHouse répliqué exécuté dans Google Cloud et utilisant Google Cloud Storage (GCS) comme « type » de disque de stockage ClickHouse.Dans ce tutoriel, vous déploierez des nœuds du serveur ClickHouse sur des VM Google Cloud Engine, chacun avec un bucket GCS associé pour le stockage. La réplication est coordonnée par un ensemble de nœuds ClickHouse Keeper, eux aussi déployés sous forme de VM.Exemples d’exigences pour assurer la haute disponibilité :
Deux nœuds du serveur ClickHouse, dans deux régions GCP
Deux buckets GCS, déployés dans les mêmes régions que les deux nœuds du serveur ClickHouse
Trois nœuds ClickHouse Keeper, dont deux sont déployés dans les mêmes régions que les nœuds du serveur ClickHouse. Le troisième peut se trouver dans la même région que l’un des deux premiers nœuds Keeper, mais dans une zone de disponibilité différente.
ClickHouse Keeper nécessite deux nœuds pour fonctionner, d’où la nécessité d’en prévoir trois pour assurer la haute disponibilité.
Déployez ClickHouse sur deux hôtes, appelés chnode1 et chnode2 dans les exemples de configuration.Placez chnode1 dans une région GCP et chnode2 dans une autre. Dans ce guide, us-east1 et us-east4 sont utilisés pour les VM Compute Engine ainsi que pour les buckets GCS.
Ne démarrez pas clickhouse server tant qu’il n’est pas configuré. Contentez-vous de l’installer.
Consultez les instructions d’installation lorsque vous effectuez les étapes de déploiement sur les nœuds serveur ClickHouse.
Déployez ClickHouse Keeper sur trois hôtes ; dans les configurations d’exemple, ils sont nommés keepernode1, keepernode2 et keepernode3. keepernode1 peut être déployé dans la même région que chnode1, keepernode2 avec chnode2, et keepernode3 dans l’une ou l’autre région, mais dans une zone de disponibilité différente de celle du nœud ClickHouse de cette région.Consultez les instructions d’installation lorsque vous effectuez les étapes de déploiement sur les nœuds ClickHouse Keeper.
Les deux serveurs ClickHouse seront situés dans des régions différentes pour assurer la haute disponibilité. Chacun disposera d’un bucket GCS dans la même région.Dans Cloud Storage > Buckets, choisissez CREATE BUCKET. Pour ce tutoriel, deux buckets sont créés, un dans us-east1 et un dans us-east4. Les buckets sont monorégionaux, de classe de stockage standard et non publics. Lorsque cela vous est demandé, activez la prévention de l’accès public. Ne créez pas de dossiers ; ils seront créés lorsque ClickHouse écrira dans le stockage.Si vous avez besoin d’instructions pas à pas pour créer des buckets et une clé HMAC, développez Create GCS buckets and an HMAC key et suivez les instructions :
Créer une clé HMAC et un secret pour un compte de service
Ouvrez Cloud Storage > Settings > Interoperability et choisissez soit une Access key existante, soit CREATE A KEY FOR A SERVICE ACCOUNT. Ce guide décrit la procédure de création d’une nouvelle clé pour un nouveau compte de service.
S’il s’agit d’un projet sans compte de service existant, cliquez sur CREATE NEW ACCOUNT.La création du compte de service se fait en trois étapes. Lors de la première, donnez au compte un nom, un ID et une description explicites.Dans la boîte de dialogue des paramètres Interoperability, le rôle IAM Storage Object Admin est recommandé ; sélectionnez-le à la deuxième étape.La troisième étape est facultative et n’est pas utilisée dans ce guide. Vous pouvez autoriser des utilisateurs à disposer de ces privilèges selon vos politiques.La clé HMAC du compte de service s’affichera. Enregistrez ces informations, car elles seront utilisées dans la configuration de ClickHouse.
Tous les nœuds ClickHouse Keeper utilisent le même fichier de configuration, à l’exception de la ligne server_id (première ligne mise en évidence ci-dessous). Modifiez le fichier en y indiquant les noms d’hôte de vos serveurs ClickHouse Keeper, puis, sur chacun des serveurs, définissez server_id de façon à ce qu’il corresponde à l’entrée server appropriée dans raft_configuration. Comme, dans cet exemple, server_id est défini sur 3, nous avons mis en évidence les lignes correspondantes dans raft_configuration.
Modifiez le fichier avec vos noms d’hôte et assurez-vous qu’ils sont résolus depuis les nœuds de serveur ClickHouse et les nœuds Keeper
Copiez le fichier à l’emplacement approprié (/etc/clickhouse-keeper/keeper_config.xml sur chacun des serveurs Keeper)
Modifiez server_id sur chaque machine en fonction de son numéro d’entrée dans raft_configuration
bonne pratiqueCertaines étapes de ce guide vous demanderont de placer un fichier de configuration dans /etc/clickhouse-server/config.d/. Il s’agit de l’emplacement par défaut, sur les systèmes Linux, des fichiers de surcharge de configuration. Lorsque vous placez ces fichiers dans ce répertoire, ClickHouse fusionne leur contenu avec la configuration par défaut. En plaçant ces fichiers dans le répertoire config.d, vous éviterez de perdre votre configuration lors d’une mise à niveau.
Par défaut, ClickHouse écoute sur l’interface de bouclage ; dans une configuration répliquée, la communication réseau entre les machines est nécessaire. Écoutez sur toutes les interfaces :
La réplication est coordonnée par ClickHouse Keeper. Ce fichier de configuration identifie les nœuds ClickHouse Keeper par leur nom d’hôte et leur numéro de port.
Modifiez les noms d’hôte pour qu’ils correspondent à ceux de vos hôtes Keeper
Ce fichier configure le nom d’hôte et le port de chaque serveur ClickHouse du cluster. Le fichier de configuration par défaut contient des définitions de cluster d’exemple ; pour n’afficher que les clusters entièrement configurés, l’attribut replace="true" est ajouté à l’entrée remote_servers afin que, lorsque cette configuration est fusionnée avec la configuration par défaut, elle remplace la section remote_servers au lieu de s’y ajouter.
Modifiez le fichier avec vos noms d’hôte et assurez-vous qu’ils peuvent être résolus depuis les nœuds serveur ClickHouse
Ce fichier configure les paramètres liés au chemin ClickHouse Keeper. Plus précisément, les macros utilisées pour identifier à quelle réplique appartiennent les données. Sur un serveur, la réplique doit être spécifiée comme replica_1, et sur l’autre serveur comme replica_2. Les noms peuvent être modifiés ; en reprenant notre exemple où une réplique est stockée en Caroline du Sud et l’autre en Virginie du Nord, les valeurs pourraient être carolina et virginia ; assurez-vous simplement qu’ils sont différents sur chaque machine.
La configuration de stockage de ClickHouse inclut disks et policies. Le disque configuré ci-dessous est nommé gcs et est de types3. Le type est s3, car ClickHouse accède au bucket GCS comme s’il s’agissait d’un bucket AWS S3. Deux copies de cette configuration seront nécessaires, une pour chacun des deux nœuds du serveur ClickHouse.Ces substitutions doivent être effectuées dans la configuration ci-dessous.Ces substitutions diffèrent entre les deux nœuds du serveur ClickHouse :
REPLICA 1 BUCKET doit être défini sur le nom du bucket situé dans la même région que le serveur
REPLICA 1 FOLDER doit être remplacé par replica_1 sur l’un des serveurs, et par replica_2 sur l’autre
Ces substitutions sont identiques sur les deux nœuds :
access_key_id doit être défini sur la clé HMAC générée précédemment
secret_access_key doit être défini sur le secret HMAC généré précédemment
Envoyez des commandes à ClickHouse Keeper avec netcat. Par exemple, mntr renvoie l’état du cluster ClickHouse Keeper. Si vous exécutez la commande sur chacun des nœuds Keeper, vous verrez que l’un est leader et que les deux autres sont des followers :
En examinant les buckets, vous verrez qu’un dossier a été créé dans chacun d’eux avec le nom utilisé dans le fichier de configuration storage.xml. Développez ces dossiers et vous verrez de nombreux fichiers, correspondant aux partitions de données.
