Passer au contenu principal
L’échantillon de données des taxis new-yorkais comprend plus de 3 milliards de trajets de taxis et de véhicules de transport avec chauffeur (Uber, Lyft, etc.) au départ de New York depuis 2009. Ce guide de prise en main utilise un échantillon de 3 millions de lignes. Le jeu de données complet peut être obtenu de plusieurs façons :
  • insérer directement les données dans ClickHouse Cloud depuis S3 ou GCS
  • télécharger des partitions préparées
  • vous pouvez également interroger le jeu de données complet dans notre environnement de démonstration sur sql.clickhouse.com.
Les requêtes d’exemple ci-dessous ont été exécutées sur une instance Production de ClickHouse Cloud. Pour plus d’informations, voir “Spécifications du Playground”.

Créer la table trips

Commencez par créer la table des trajets en taxi :

Charger les données directement depuis le stockage objet

Les utilisateurs peuvent récupérer un petit sous-ensemble de données (3 millions de lignes) pour se familiariser avec lui. Les données se trouvent dans des fichiers TSV stockés dans le stockage objet, et peuvent être facilement transférées en flux vers ClickHouse Cloud à l’aide de la table function s3. Les mêmes données sont stockées à la fois dans S3 et dans GCS ; choisissez l’onglet de votre choix.
La commande suivante transfère en flux trois fichiers depuis un bucket S3 vers la table trips_small (la syntaxe {0..2} est un joker pour les valeurs 0, 1 et 2) :

Exemples de requêtes

Les requêtes suivantes sont exécutées sur l’échantillon décrit ci-dessus. Vous pouvez exécuter ces requêtes d’exemple sur l’ensemble du jeu de données dans sql.clickhouse.com, en modifiant les requêtes ci-dessous pour utiliser la table nyc_taxi.trips. Voyons combien de lignes ont été insérées : Chaque fichier TSV contient environ 1 M de lignes, et les trois fichiers contiennent 3 000 317 lignes. Examinons-en quelques-unes : Notez qu’il existe des colonnes pour les dates de prise en charge et de dépose, les coordonnées géographiques, les informations tarifaires, les quartiers de New York, etc. Exécutons quelques requêtes. Cette requête affiche les 10 quartiers où les prises en charge sont les plus fréquentes : Cette requête affiche le tarif moyen en fonction du nombre de passagers :
runnable
Voici la corrélation entre le nombre de passagers et la distance du trajet :
runnable

Téléchargement des partitions préparées

Les étapes suivantes fournissent des informations sur le jeu de données d’origine, ainsi qu’une méthode pour charger des partitions préparées dans un environnement de serveur ClickHouse autogéré.
Consultez https://github.com/toddwschneider/nyc-taxi-data et http://tech.marksblogg.com/billion-nyc-taxi-rides-redshift.html pour obtenir une description du jeu de données et les instructions de téléchargement. Le téléchargement représente environ 227 Go de données non compressées dans des fichiers CSV. Il faut compter environ une heure sur une connexion à 1 Gbit (le téléchargement en parallèle depuis s3.amazonaws.com permet d’exploiter au moins la moitié d’un lien à 1 Gbit). Il est possible que certains fichiers ne soient pas téléchargés بالكامل. Vérifiez la taille des fichiers et retéléchargez ceux qui semblent incomplets.
Si vous exécutez les requêtes décrites ci-dessous, vous devez utiliser le nom complet de la table, datasets.trips_mergetree.

Résultats sur un seul serveur

Q1:
0,490 seconde. Q2:
1,224 secondes. Q3:
2,104 secondes. Q4:
3,593 secondes. La configuration de serveur suivante a été utilisée : Deux Intel(R) Xeon(R) CPU E5-2650 v2 @ 2.60GHz, 16 cœurs physiques au total, 128 GiB de RAM, 8x6 TB de disques durs sur RAID-5 matériel Le temps d’exécution indiqué correspond au meilleur des trois essais. Mais à partir du deuxième essai, les requêtes lisent les données depuis le cache du système de fichiers. Il n’y a pas d’autre mise en cache : les données sont relues et traitées à chaque essai. Création d’une table sur trois serveurs : Sur chaque serveur :
Sur le serveur source :
La requête suivante redistribue les données :
Cela prend 2454 secondes. Sur trois serveurs : Q1 : 0.212 seconde. Q2 : 0.438 seconde. Q3 : 0.733 seconde. Q4 : 1.241 seconde. Rien de surprenant ici, puisque le temps des requêtes évolue linéairement. Nous avons également les résultats d’un cluster de 140 serveurs : Q1 : 0.028 s. Q2 : 0.043 s. Q3 : 0.051 s. Q4 : 0.072 s. Dans ce cas, le temps de traitement de la requête est déterminé avant tout par la latence réseau. Nous avons exécuté les requêtes à l’aide d’un client situé dans un centre de données différent de celui où se trouvait le cluster, ce qui a ajouté environ 20 ms de latence.

Résumé

Dernière modification le 25 juin 2026