Saltar al contenido principal
La muestra de datos de taxis de Nueva York incluye más de 3 mil millones de viajes en taxi y vehículos de transporte con conductor (Uber, Lyft, etc.) originados en la ciudad de Nueva York desde 2009. Esta guía de inicio utiliza una muestra de 3 millones de filas. El conjunto de datos completo puede obtenerse de varias maneras:
  • insertar los datos directamente en ClickHouse Cloud desde S3 o GCS
  • descargar particiones preparadas
  • También puede consultar el conjunto de datos completo en nuestro entorno de demostración en sql.clickhouse.com.
Las consultas de ejemplo que aparecen a continuación se ejecutaron en una instancia de Production de ClickHouse Cloud. Para más información, consulte “Especificaciones de Playground”.

Crear la tabla trips

Comience creando una tabla para los viajes en taxi:

Carga los datos directamente desde el almacenamiento de objetos

Los usuarios pueden tomar un pequeño subconjunto de los datos (3 millones de filas) para familiarizarse con ellos. Los datos están en archivos TSV en el almacenamiento de objetos, desde donde se pueden transferir fácilmente en streaming a ClickHouse Cloud mediante la función de tabla s3. Los mismos datos se almacenan tanto en S3 como en GCS; elige cualquiera de las pestañas.
El siguiente comando transfiere en streaming tres archivos desde un bucket de S3 a la tabla trips_small (la sintaxis {0..2} es un comodín para los valores 0, 1 y 2):

Consultas de muestra

Las siguientes consultas se ejecutan sobre la muestra descrita anteriormente. Puede ejecutar las consultas de muestra en el conjunto de datos completo en sql.clickhouse.com, modificando las consultas siguientes para usar la tabla nyc_taxi.trips. Veamos cuántas filas se insertaron: Cada archivo TSV tiene aproximadamente 1 millón de filas, y los tres archivos tienen 3,000,317 filas. Veamos algunas: Tenga en cuenta que hay columnas para las fechas de recogida y descenso, coordenadas geográficas, detalles de la tarifa, barrios de Nueva York y más. Ejecutemos algunas consultas. Esta consulta muestra los 10 barrios con más recogidas: Esta consulta muestra la tarifa media en función del número de pasajeros:
runnable
Esta es la correlación entre el número de pasajeros y la distancia del viaje:
runnable

Descarga de particiones preparadas

Los siguientes pasos proporcionan información sobre el conjunto de datos original y un método para cargar particiones preparadas en un entorno de servidor ClickHouse autogestionado.
Consulta https://github.com/toddwschneider/nyc-taxi-data y http://tech.marksblogg.com/billion-nyc-taxi-rides-redshift.html para ver la descripción del conjunto de datos y las instrucciones de descarga. La descarga dará como resultado aproximadamente 227 GB de datos sin comprimir en archivos CSV. La descarga tarda alrededor de una hora con una conexión de 1 Gbit (la descarga en paralelo desde s3.amazonaws.com aprovecha al menos la mitad de un canal de 1 Gbit). Es posible que algunos archivos no se descarguen por completo. Comprueba el tamaño de los archivos y vuelve a descargar cualquier archivo que parezca dudoso.
Si va a ejecutar las consultas que se describen a continuación, debe usar el nombre completo de la tabla: datasets.trips_mergetree.

Resultados en un solo servidor

Q1:
0.490 segundos. Q2:
1,224 segundos. Q3:
2.104 segundos. Q4:
3,593 segundos. Se utilizó el siguiente servidor: Dos Intel(R) Xeon(R) CPU E5-2650 v2 a 2,60 GHz, 16 núcleos físicos en total, 128 GiB de RAM, 8 discos duros de 6 TB en RAID-5 por hardware El tiempo de ejecución es el mejor de tres ejecuciones. Sin embargo, a partir de la segunda ejecución, las consultas leen los datos desde la caché del sistema de archivos. No se realiza ningún almacenamiento en caché adicional: en cada ejecución, los datos se leen y se procesan. Creación de una tabla en tres servidores: En cada servidor:
En el servidor de origen:
La siguiente consulta redistribuye los datos:
Esto tarda 2454 segundos. En tres servidores: Q1: 0.212 segundos. Q2: 0.438 segundos. Q3: 0.733 segundos. Q4: 1.241 segundos. No hay sorpresas aquí, ya que las consultas escalan linealmente. También tenemos los resultados de un clúster de 140 servidores: Q1: 0.028 s. Q2: 0.043 s. Q3: 0.051 s. Q4: 0.072 s. En este caso, el tiempo de procesamiento de la consulta viene determinado, ante todo, por la latencia de red. Ejecutamos consultas con un cliente ubicado en un centro de datos distinto de aquel en el que se encontraba el clúster, lo que añadió unos 20 ms de latencia.

Resumen

Última modificación el 2 de julio de 2026