Pular para o conteúdo principal
A amostra de dados de táxi de Nova York consiste em mais de 3 bilhões de viagens de táxi e de veículos de transporte por aplicativo (Uber, Lyft etc.) com origem na cidade de Nova York desde 2009. Este guia de primeiros passos usa uma amostra de 3 milhões de linhas. O conjunto completo de dados pode ser obtido de algumas maneiras:
  • inserir os dados diretamente no ClickHouse Cloud a partir do S3 ou GCS
  • baixar partições preparadas
  • Como alternativa, você pode consultar o conjunto completo de dados em nosso ambiente de demonstração em sql.clickhouse.com.
As consultas de exemplo abaixo foram executadas em uma instância de Produção do ClickHouse Cloud. Para mais informações, consulte “Especificações do Playground”.

Crie a tabela trips

Comece criando a tabela para as corridas de táxi:

Carregue os dados diretamente do armazenamento de objetos

Os usuários podem obter um pequeno subconjunto dos dados (3 milhões de linhas) para se familiarizar com ele. Os dados estão em arquivos TSV no armazenamento de objetos e podem ser facilmente carregados por streaming no ClickHouse Cloud usando a função de tabela s3. Os mesmos dados estão armazenados tanto no S3 quanto no GCS; escolha qualquer uma das abas.
O comando a seguir carrega por streaming três arquivos de um bucket do S3 para a tabela trips_small (a sintaxe {0..2} é um curinga para os valores 0, 1 e 2):

Consultas de exemplo

As consultas a seguir são executadas na amostra descrita acima. Você pode executar as consultas de exemplo no conjunto de dados completo em sql.clickhouse.com, modificando as consultas abaixo para usar a tabela nyc_taxi.trips. Vamos ver quantas linhas foram inseridas: Cada arquivo TSV tem cerca de 1 milhão de linhas, e os três arquivos têm 3.000.317 linhas. Vamos ver algumas delas: Observe que há colunas para as datas de embarque e desembarque, coordenadas geográficas, detalhes da tarifa, bairros de Nova York e muito mais. Vamos executar algumas consultas. Esta consulta mostra os 10 bairros com maior frequência de embarque: Esta consulta mostra a tarifa média com base no número de passageiros:
runnable
Veja a correlação entre o número de passageiros e a distância da viagem:
runnable

Download das partições preparadas

As etapas a seguir fornecem informações sobre o conjunto de dados original e um método para carregar partições preparadas em um ambiente autogerenciado do servidor ClickHouse.
Consulte https://github.com/toddwschneider/nyc-taxi-data e http://tech.marksblogg.com/billion-nyc-taxi-rides-redshift.html para ver a descrição do conjunto de dados e as instruções de download. O download resultará em cerca de 227 GB de dados não compactados em arquivos CSV. O download leva cerca de uma hora em uma conexão de 1 Gbit (o download paralelo de s3.amazonaws.com aproveita pelo menos metade de um canal de 1 Gbit). Alguns dos arquivos podem não ser baixados por completo. Verifique os tamanhos dos arquivos e baixe novamente aqueles que parecerem duvidosos.
Se você for executar as consultas descritas abaixo, deverá usar o nome completo da tabela, datasets.trips_mergetree.

Resultados em um único servidor

Q1:
0,490 segundos. Q2:
1,224 segundos. Q3:
2,104 segundos. Q4:
3,593 segundos. O servidor a seguir foi usado: Dois Intel(R) Xeon(R) CPU E5-2650 v2 @ 2.60GHz, 16 núcleos físicos no total, 128 GiB de RAM, 8 HDs de 6 TB em RAID-5 por hardware O tempo de execução corresponde ao melhor de três execuções. Porém, a partir da segunda execução, as consultas leem os dados do cache do sistema de arquivos. Não há outro tipo de cache: os dados são lidos e processados em cada execução. Criando uma tabela em três servidores: Em cada servidor:
No servidor de origem:
A consulta a seguir redistribui os dados:
Isso leva 2454 segundos. Em três servidores: Q1: 0.212 segundos. Q2: 0.438 segundos. Q3: 0.733 segundos. Q4: 1.241 segundos. Nada surpreendente aqui, já que as consultas escalam linearmente. Também temos os resultados de um cluster com 140 servidores: Q1: 0.028 s. Q2: 0.043 s. Q3: 0.051 s. Q4: 0.072 s. Nesse caso, o tempo de processamento da consulta é determinado principalmente pela latência de rede. Executamos consultas usando um cliente localizado em um datacenter diferente daquele em que o cluster estava, o que acrescentou cerca de 20 ms de latência.

Resumo

Última modificação em 2 de julho de 2026