TSV を CSV に置き換えるだけです。
このガイドでは、次のことを行います。
- 調査する: TSV ファイルの構造と内容をクエリします。
- 対象の ClickHouse スキーマを決定する: 適切なデータ型を選び、既存のデータをそれらの型に対応付けます。
- ClickHouse テーブルを作成する。
- データを前処理してストリーミングする: ClickHouse にデータを取り込みます。
- いくつかのクエリを実行する: ClickHouse に対してクエリを実行します。
前提条件
- NYPD Complaint Data Current (Year To Date) のページにアクセスし、
Exportボタンをクリックして TSV for Excel を選択し、データセット をダウンロードします。 - ClickHouse server とクライアント をインストールします
このガイドで説明するコマンドについて
- 一部のコマンドは TSV ファイルに対してクエリを実行するもので、コマンドプロンプトで実行します。
- 残りのコマンドは ClickHouse に対してクエリを実行するもので、
clickhouse-clientまたは Play UI で実行します。
このガイドの例では、TSV ファイルを
${HOME}/NYPD_Complaint_Data_Current__Year_To_Date_.tsv に保存していることを前提としています。必要に応じてコマンドを調整してください。TSVファイルの内容を把握する
ソースTSVファイルのフィールドを確認する
Query
clickhouse-local を使用します。
Query
Response
Nullable(Float64) に設定され、その他のフィールドはすべて Nullable(String) になっています。データを保存するための ClickHouse テーブル を作成する際は、より適切でパフォーマンスの高い型を指定できます。
適切なスキーマを決める
JURISDICTION_CODE は数値です。UInt8 にすべきか、Enum にすべきか、あるいは Float64 が適切なのかを検討する必要があります。
Query
Response
JURISDICTION_CODE は UInt8 にうまく収まることがわかります。
同様に、いくつかの String フィールドについても、それらが DateTime フィールドや LowCardinality(String) フィールドに適しているか確認します。
たとえば、フィールド PARKS_NM には “該当する場合、発生場所となった NYC の公園、遊び場、または緑地の名称 (州立公園は含まれません) ” とあります。ニューヨーク市内の公園名は、LowCardinality(String) の有力な候補といえるでしょう。
Query
Response
Query
Response
PARK_NMカラムに含まれる公園や遊び場の異なる値は数百件しかありません。これは、LowCardinality(String)フィールドでは異なる文字列を 10,000 未満に抑えるというLowCardinalityの推奨に照らすと、少ない数です。
DateTime フィールド
CMPLNT_FR_DT と CMPLT_TO_DT の最小値および最大値を確認すると、これらのフィールドが常に入力されているかどうかの見当をつけられます。
Query
Response
Query
Response
Query
Response
Query
Response
方針を立てる
JURISDICTION_CODEはUInt8に CAST する必要があります。PARKS_NMはLowCardinality(String)に CAST する必要がありますCMPLNT_FR_DTとCMPLNT_FR_TMには常に値が入っています (デフォルト時刻の00:00:00が入っている可能性があります)CMPLNT_TO_DTとCMPLNT_TO_TMは空の場合があります- ソースでは、日付と時刻は別々のフィールドに格納されています
- 日付は
mm/dd/yyyyフォーマットです - 時刻は
hh:mm:ssフォーマットです - 日付と時刻は連結して DateTime 型にできます
- 1970年1月1日より前の日付がいくつかあるため、64ビットの DateTime が必要です
型については、さらに多くの変更が必要ですが、いずれも同じ調査手順で判断できます。フィールド内の異なる文字列の数、数値の最小値と最大値を確認して、判断してください。ガイドの後半で示すテーブルスキーマには、低カーディナリティの文字列と符号なし整数フィールドが多く、浮動小数点の数値はごくわずかしかありません。
日付フィールドと時刻フィールドを連結する
CMPLNT_FR_DT と時刻フィールド CMPLNT_FR_TM を連結して、DateTime にキャスト可能な 1 つの String にするには、連結演算子でつないだ 2 つのフィールド CMPLNT_FR_DT || ' ' || CMPLNT_FR_TM を選択します。CMPLNT_TO_DT フィールドと CMPLNT_TO_TM フィールドについても同様です。
Query
Response
日付と時刻の String を DateTime64 型に変換する
MM/DD/YYYY から YYYY/MM/DD フォーマットに変換する必要があります。これらはどちらも parseDateTime64BestEffort() で行えます。
Query
DateTime64 にパースしています。苦情の終了時刻が必ず存在するとは限らないため、parseDateTime64BestEffortOrNull を使用します。
Response
上に
1925 と表示されている日付は、データ内の誤りに起因するものです。元のデータには、本来 2019 - 2022 であるべき年が 1019 - 1022 になっているレコードがいくつかあります。64 ビットの DateTime で扱える最も古い日付が 1925 年 1 月 1 日であるため、それらは 1925 年 1 月 1 日として保存されています。テーブルを作成
ORDER BY と PRIMARY KEY も決める必要があります。ORDER BY または PRIMARY KEY の少なくとも一方を指定しなければなりません。以下に、ORDER BY に含めるカラムを決める際の指針をいくつか示します。詳細については、このドキュメントの末尾にある 次のステップ セクションを参照してください。
ORDER BY 句と PRIMARY KEY 句
ORDER BYタプルには、クエリのフィルタで使用されるフィールドを含めるべきです- ディスク上での圧縮を最大化するには、
ORDER BYタプルをカーディナリティの昇順に並べるべきです PRIMARY KEYタプルが存在する場合は、ORDER BYタプルの部分集合でなければなりませんORDER BYのみが指定されている場合は、同じタプルがPRIMARY KEYとして使用されます- 主キーの索引は、指定されていれば
PRIMARY KEYタプルを使用して作成され、そうでない場合はORDER BYタプルを使用して作成されます PRIMARY KEY索引は主記憶に保持されます
ORDER BY に
含めることになります。
3 つの候補カラムのカーディナリティを調べるために、TSVファイルに対してクエリを実行します。
Query
Response
ORDER BY は次のようになります:
以下のテーブルでは、より読みやすいカラム名を使用します。上記の名前は次のようにマッピングされます。
ORDER BY のタプルを合わせると、テーブル構造は次のようになります:
テーブルの主キーを確認する
system データベース、特に system.table には、先ほど作成したテーブルに関する情報がすべて含まれています。このクエリを実行すると、ORDER BY (ソートキー) と PRIMARY KEY が表示されます。
データの前処理とインポート
clickhouse-local ツールを使用し、アップロードには clickhouse-client を使用します。
使用している clickhouse-local の引数
データを確認する
このデータセットは年に1回以上更新されるため、件数がこのドキュメントに記載されている内容と一致しない場合があります。
Query
Response
Query
Response
クエリをいくつか実行する
クエリ1. 月ごとの苦情件数を比較する
Query
Response
クエリ 2. 行政区ごとの苦情総数を比較する
Query
Response