メインコンテンツへスキップ
ニューヨークのタクシーデータサンプルは、2009 年以降にニューヨーク市を出発地とした、30 億件超のタクシーおよび配車サービス車両 (Uber、Lyft など) の乗車記録で構成されています。この入門ガイドでは、300 万行のサンプルを使用します。 完全なデータセットは、以下のいずれかの方法で取得できます。
  • S3 または GCS から ClickHouse Cloud にデータを直接取り込む
  • 準備済みのパーティションをダウンロードする
  • または、sql.clickhouse.com のデモ環境で、完全なデータセットに対してクエリを実行できます。
以下のサンプルクエリは、ClickHouse Cloud の Production インスタンスで実行されています。詳細については “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 つのファイルを合わせると 3,000,317 行になります。まずは数行見てみましょう。 乗車日・降車日の日時、Geo 座標、運賃の詳細、ニューヨークの地区名などのカラムが含まれていることがわかります。 いくつかクエリを実行してみましょう。このクエリでは、乗車地点として最も頻繁に使われている地区名の上位 10 件を確認できます。 このクエリは、乗客数ごとの平均運賃を表示します。
runnable
乗客数と移動距離には、次のような相関が見られます:
runnable

準備済みパーティションのダウンロード

以下の手順では、元のデータセットに関する情報と、準備済みパーティションをセルフマネージドのClickHouseサーバー環境に読み込む方法を説明します。
データセットの説明とダウンロード手順については、https://github.com/toddwschneider/nyc-taxi-data および http://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 Seconds。 Q4:
3.593秒。 使用したserverは次のとおりです。 Intel(R) Xeon(R) CPU E5-2650 v2 @ 2.60GHz × 2、物理コア合計16、128 GiB RAM、ハードウェア RAID-5 構成の 6 TB HD × 8 実行時間は3回の実行のうち最良の値です。ただし、2回目以降の実行では、クエリ はファイルシステムキャッシュからデータを読み取ります。それ以上の Caching は発生せず、データは各実行で毎回読み出されて処理されます。 3台のserverでtableを作成します。 各serverで:
送信元サーバーで:
次のクエリでデータを再分散します。
これには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月10日