메인 콘텐츠로 건너뛰기
뉴욕 택시 데이터 샘플은 2009년 이후 뉴욕시에서 출발한 30억 건 이상의 택시 및 차량 호출 서비스(Uber, Lyft 등) 이용 데이터를 포함합니다. 이 시작하기 가이드에서는 300만 행 샘플을 사용합니다. 전체 데이터셋은 다음과 같은 몇 가지 방법으로 구할 수 있습니다:
  • S3 또는 GCS에서 데이터를 ClickHouse Cloud에 직접 삽입합니다
  • 준비된 파티션을 다운로드합니다
  • 또는 sql.clickhouse.com 데모 환경에서 전체 데이터셋을 쿼리할 수 있습니다.
아래 예시 쿼리는 ClickHouse Cloud의 운영 인스턴스에서 실행되었습니다. 자세한 내용은 “Playground 사양”을 참조하십시오.

trips 테이블 생성

먼저 택시 운행용 테이블을 생성합니다:

객체 스토리지에서 데이터를 직접 로드하기

데이터를 익히는 용도로는 일부 부분 집합(300만 행)을 가져와 사용할 수 있습니다. 데이터는 객체 스토리지의 TSV 파일로 제공되며, s3 테이블 함수를 사용해 ClickHouse Cloud로 쉽게 스트리밍할 수 있습니다. 동일한 데이터가 S3와 GCS 모두에 저장되어 있으므로 원하는 탭을 선택하십시오.
다음 명령은 S3 버킷에서 파일 3개를 trips_small 테이블로 스트리밍합니다({0..2} 구문은 0, 1, 2 값을 나타내는 와일드카드입니다):

샘플 쿼리

다음 쿼리는 위에서 설명한 샘플을 기준으로 실행됩니다. 아래 쿼리에서 테이블을 nyc_taxi.trips로 바꾸면 sql.clickhouse.com에서 전체 데이터셋으로 샘플 쿼리를 실행할 수 있습니다. 삽입된 행 수를 확인해 보겠습니다: 각 TSV 파일에는 약 100만 개의 행이 있으며, 세 파일을 합치면 총 3,000,317개의 행이 있습니다. 몇 개의 행을 살펴보겠습니다: 픽업 및 하차 날짜, 지리 좌표, 요금 세부 정보, 뉴욕 지역명 등을 위한 컬럼이 있는 것을 확인할 수 있습니다. 몇 가지 쿼리를 실행해 보겠습니다. 다음 쿼리는 픽업이 가장 자주 발생한 상위 10개 지역을 보여줍니다: 이 쿼리는 승객 수에 따른 평균 요금을 보여줍니다:
runnable
다음은 승객 수와 이동 거리 사이의 상관관계입니다:
runnable

준비된 파티션 다운로드

다음 단계에서는 원본 데이터셋에 대한 정보와 준비된 파티션을 자가 관리형 ClickHouse 서버 환경에 로드하는 방법을 안내합니다.
데이터셋 설명과 다운로드 지침은 https://github.com/toddwschneider/nyc-taxi-datahttp://tech.marksblogg.com/billion-nyc-taxi-rides-redshift.html를 참조하십시오. 다운로드하면 CSV 파일로 약 227 GB의 비압축 데이터가 생성됩니다. 1 Gbit 연결에서는 다운로드에 약 1시간이 걸립니다(s3.amazonaws.com에서 병렬 다운로드를 수행하면 1 Gbit 채널의 최소 절반 이상을 활용할 수 있습니다). 일부 파일은 완전히 다운로드되지 않을 수 있습니다. 파일 크기를 확인하고 의심스러운 파일은 다시 다운로드하십시오.
아래에서 설명하는 쿼리를 실행하려면 전체 테이블 이름인 datasets.trips_mergetree를 사용해야 합니다.

단일 서버 결과

Q1:
0.490초. Q2:
1.224초. Q3:
2.104초. Q4:
3.593초. 다음 서버를 사용했습니다: Intel(R) Xeon(R) CPU E5-2650 v2 @ 2.60GHz 2개, 총 16개의 물리 코어, 128 GiB RAM, 하드웨어 RAID-5의 6 TB HD 8개 실행 시간은 3회 실행한 결과 중 가장 좋은 값입니다. 다만 2회차 실행부터는 쿼리가 파일 시스템 캐시에서 데이터를 읽습니다. 추가적인 캐싱은 발생하지 않으며, 각 실행마다 데이터를 읽어 처리합니다. 3대의 서버에 테이블 생성: 각 서버에서:
소스 서버에서:
다음 쿼리는 데이터를 재분배합니다:
이는 2454초가 소요됩니다. 서버 3대에서는 다음과 같습니다: Q1: 0.212초. Q2: 0.438초. Q3: 0.733초. Q4: 1.241초. 쿼리가 선형적으로 확장되므로 이는 예상 가능한 결과입니다. 서버 140대로 구성된 클러스터의 결과도 있습니다: Q1: 0.028초. Q2: 0.043초. Q3: 0.051초. Q4: 0.072초. 이 경우 쿼리 처리 시간은 무엇보다도 네트워크 지연 시간에 의해 결정됩니다. 클러스터가 위치한 데이터 센터와 다른 데이터 센터에 있는 클라이언트로 쿼리를 실행했으며, 이로 인해 약 20 ms의 지연 시간이 추가되었습니다.

요약

마지막 수정일 2026년 6월 29일