メインコンテンツへスキップ
ClickHouseは、サポートされているほぼすべての入力フォーマットで、入力データの構造を自動的に判定できます。 このドキュメントでは、どのような場合にスキーマ推論が使用されるのか、各種入力フォーマットでどのように機能するのか、またそれを制御する設定について説明します。

使用

スキーマ推論は、ClickHouse が特定のデータフォーマットのデータを読み込む必要があり、その構造が不明な場合に使用されます。

テーブル関数 file, s3, url, hdfs, azureBlobStorage.

これらのテーブル関数には、入力データの構造を表す省略可能な引数 structure があります。この引数を指定しないか、auto に設定した場合は、構造がデータから推論されます。 例: user_files ディレクトリに、以下の内容を持つ JSONEachRow フォーマットのファイル hobbies.jsonl があるとします。
ClickHouseは、このデータの構造を指定しなくても読み取れます。
注: フォーマット JSONEachRow は、ファイル拡張子 .jsonl に基づいて自動的に判定されました。 自動的に判定された構造は、DESCRIBE クエリで確認できます:

テーブルエンジン File, S3, URL, HDFS, azureBlobStorage

CREATE TABLE クエリでカラムの一覧を指定しない場合、テーブルの構造はデータから自動的に推論されます。 例: ファイル hobbies.jsonl を使用します。このファイルのデータを使って、File エンジンのテーブルを作成できます:

clickhouse-local

clickhouse-local には、入力データの構造を指定するオプションのパラメーター -S/--structure があります。このパラメーターを指定しない場合、または auto に設定した場合は、構造がデータから推論されます。 例: ファイル hobbies.jsonl を使ってみましょう。clickhouse-local を使うと、このファイルのデータに対してクエリを実行できます。

挿入先テーブルの構造を使用する

テーブル関数 file/s3/url/hdfs を使用してテーブルにデータを挿入する場合、 データから構造を抽出する代わりに、挿入先テーブルの構造を使用するオプションがあります。 スキーマ推論には時間がかかることがあるため、これにより挿入性能を向上させることができます。また、テーブルに最適化されたスキーマが定義されている場合にも有効で、 型変換は行われません。 この動作を制御する特別な設定 use_structure_from_insertion_table_in_table_functions があります。これには 3 つの設定可能な値があります。
  • 0 - テーブル関数はデータから構造を抽出します。
  • 1 - テーブル関数は挿入先テーブルの構造を使用します。
  • 2 - ClickHouse が、挿入先テーブルの構造を使用できるか、またはスキーマ推論を使用するかを自動的に判定します。デフォルト値です。
例 1: 次の構造でテーブル hobbies1 を作成します。
次に、ファイル hobbies.jsonl からデータを挿入します:
この場合、ファイル内のすべてのカラムがそのままテーブルに挿入されるため、ClickHouse はスキーマ推論ではなく、挿入先テーブルの構造を使用します。 例 2: 次の構造でテーブル hobbies2 を作成してみましょう。
次に、hobbies.jsonl ファイルからデータを挿入します:
この場合、SELECT クエリ内のすべてのカラムがテーブルに存在するため、ClickHouse は挿入先テーブルの構造を使用します。 これは、JSONEachRow、TSKV、Parquet など、カラムの一部を読み取れる入力フォーマットでのみ機能する点に注意してください (したがって、たとえば TSV フォーマットでは機能しません) 。 例 3: 次の構造でテーブル hobbies3 を作成しましょう。
次に、ファイル hobbies.jsonl からデータを挿入します:
この場合、SELECT クエリではカラム id が使われていますが、テーブルにはこのカラムがありません (identifier という名前のカラムがあります) 。 そのため、ClickHouse は挿入先テーブルの構造を利用できず、スキーマ推論が使用されます。 例 4: 次の構造でテーブル hobbies4 を作成しましょう。
次に、hobbies.jsonl ファイルからデータを挿入します:
この場合、テーブルに挿入するために SELECT クエリ内でカラム hobbies に対していくつかの操作が行われているため、ClickHouse は挿入先テーブルの構造を利用できず、スキーマ推論が行われます。

スキーマ推論キャッシュ

ほとんどの入力フォーマットでは、スキーマ推論のためにデータの一部を読み取ってその構造を判定する必要があり、この処理には時間がかかることがあります。 ClickHouse が同じファイルからデータを読み取るたびに毎回同じスキーマを推論しないよう、推論されたスキーマはキャッシュされます。そのため、同じファイルに再度アクセスした場合、ClickHouse はキャッシュ内のスキーマを使用します。 このキャッシュを制御する特別な設定があります:
  • schema_inference_cache_max_elements_for_{file/s3/hdfs/url/azure} - 対応するテーブル関数についてキャッシュされるスキーマの最大数です。デフォルト値は 4096 です。これらの設定はサーバー設定で指定する必要があります。
  • schema_inference_use_cache_for_{file,s3,hdfs,url,azure} - スキーマ推論でキャッシュを使用するかどうかをオン/オフできます。これらの設定はクエリで使用できます。
ファイルのスキーマは、データの変更やフォーマット設定の変更によって変わる場合があります。 このため、スキーマ推論キャッシュでは、ファイルソース、フォーマット名、使用されているフォーマット設定、およびファイルの最終更新時刻によってスキーマを識別します。 注: url テーブル関数で URL 経由でアクセスされる一部のファイルには、最終更新時刻の情報が含まれていない場合があります。このケースのために、特別な設定 schema_inference_cache_require_modification_time_for_url があります。この設定を無効にすると、そのようなファイルでも最終更新時刻がなくてもキャッシュ内のスキーマを使用できます。 現在キャッシュ内にあるすべてのスキーマを確認できるシステムテーブル schema_inference_cache と、SYSTEM CLEAR SCHEMA CACHE [FOR File/S3/URL/HDFS] というシステムクエリもあり、これによりすべてのソース、または特定のソースのスキーマキャッシュをクリアできます。 例: S3 上のサンプル dataset github-2022.ndjson.gz の構造を推論し、スキーマ推論キャッシュがどのように動作するかを見てみましょう:
ご覧のとおり、2回目のクエリはほぼ瞬時に成功しました。 それでは、推論されるスキーマに影響する可能性のある設定をいくつか変更してみましょう。
ご覧のとおり、推論されるスキーマに影響する可能性のある設定が変更されたため、同じファイルに対しては cache 内のスキーマは使用されませんでした。 system.schema_inference_cache テーブルの内容を確認してみましょう。
ご覧のとおり、同じファイルに対して 2 つの異なるスキーマがあります。 システムクエリを使って、スキーマ cache をクリアできます。

テキストフォーマット

テキストフォーマットでは、ClickHouse はデータを1行ずつ読み取り、フォーマットに従ってカラムの値を抽出した後、再帰的なパーサーやヒューリスティクスを使って各値の型を判定します。スキーマ推論でデータから読み取る最大行数と最大バイト数は、 設定 input_format_max_rows_to_read_for_schema_inference (デフォルトは 25000) および input_format_max_bytes_to_read_for_schema_inference (デフォルトは 32Mb) で制御されます。 デフォルトでは、推論されたすべての型は Nullable ですが、schema_inference_make_columns_nullable を設定することで変更できます (例は 設定 セクションを参照してください) 。

JSON フォーマット

JSON フォーマットでは、ClickHouse は JSON 仕様に従って値を解析し、最も適切なデータ型を見つけようとします。 ここでは、その仕組み、推論できる型、およびJSON フォーマットで使用できる具体的な設定について説明します。 以降の例では、format テーブル関数を使用します。 整数、浮動小数点数、Bool、String:
日付、DateTime 型:
Arrays:
Arrayにnullが含まれている場合、ClickHouseは他のArray要素の型を使用します:
配列に異なる型の値が含まれており、設定 input_format_json_infer_array_of_dynamic_from_array_of_different_types が有効な場合 (デフォルトで有効) 、その型は Array(Dynamic) になります:
名前付きタプル: 設定 input_format_json_try_infer_named_tuples_from_objects が有効な場合、スキーマ推論時に ClickHouse は JSON オブジェクトから名前付き Tuple を推論します。 生成される名前付き Tuple には、サンプルデータ内の対応するすべての JSON オブジェクトに含まれる全要素が含まれます。
名前のない Tuple: 設定 input_format_json_infer_array_of_dynamic_from_array_of_different_types が無効な場合、JSON フォーマットでは、要素の型が異なる Array は名前のない Tuple として扱われます。
いずれかの値がnullまたは空の場合は、他の行にある対応する値の型を使用します。
Map型: JSON では、値の型がすべて同じオブジェクトを Map 型として読み取ることができます。 注: これは、設定 input_format_json_read_objects_as_stringsinput_format_json_try_infer_named_tuples_from_objects が無効になっている場合にのみ機能します。
ネストされた複合型:
データに null のみ、空のオブジェクト、または空の配列しか含まれていないために、ClickHouse が一部のキーの型を判定できない場合、設定 input_format_json_infer_incomplete_types_as_strings が有効であれば型 String が使用され、そうでなければ例外がスローされます:

JSON設定

input_format_json_try_infer_numbers_from_strings
この設定を有効にすると、文字列の値から数値を推論できるようになります。 この設定はデフォルトで無効です。 例:
input_format_json_try_infer_named_tuples_from_objects
この設定を有効にすると、JSON オブジェクトから 名前付き Tuple を推論できるようになります。生成される 名前付き Tuple には、サンプルデータ内の対応するすべての JSON オブジェクトに含まれる全要素が含まれます。 これは、JSON データがスパースではなく、データのサンプルに取り得るすべてのオブジェクトキーが含まれている場合に有用です。 この設定はデフォルトで有効になっています。
Query
Response
Query
Response
input_format_json_use_string_type_for_ambiguous_paths_in_named_tuples_inference_from_objects
この設定を有効にすると、input_format_json_try_infer_named_tuples_from_objects が有効な場合、JSON オブジェクトから名前付き Tuple を推論する際に、あいまいなパスで例外を発生させる代わりに String 型を使用できるようになります。 これにより、あいまいなパスが存在する場合でも、JSON オブジェクトを名前付き Tuple として読み取ることができます。 デフォルトでは無効です。 設定が無効な場合:
Query
Response
有効時:
Query
Response
input_format_json_read_objects_as_strings
この設定を有効にすると、ネストされた JSON オブジェクトを文字列として読み込めるようになります。 この設定を使うと、JSON オブジェクト型を使用せずにネストされた JSON オブジェクトを読み込めます。 この設定はデフォルトで有効です。 注: この設定の有効化が反映されるのは、設定 input_format_json_try_infer_named_tuples_from_objects が無効になっている場合のみです。
input_format_json_read_numbers_as_strings
この設定を有効にすると、数値を文字列として読み込めるようになります。 この設定はデフォルトで有効になっています。
input_format_json_read_bools_as_numbers
この設定を有効にすると、Bool 型の値を数値として読み取れます。 この設定はデフォルトで有効です。 例:
input_format_json_read_bools_as_strings
この設定を有効にすると、Bool 型の値を文字列として読み取れるようになります。 この設定はデフォルトで有効です。 例:
input_format_json_read_arrays_as_strings
この設定を有効にすると、JSON array の値を文字列として読み込めるようになります。 この設定はデフォルトで有効です。
input_format_json_infer_incomplete_types_as_strings
この設定を有効にすると、スキーマ推論時に、データのサンプル内で Null/{}/[] のみを含む JSON キーに対して String 型を使用できます。 JSON フォーマットでは、対応する設定がすべて有効になっていれば任意の値を String として読み取ることができ (これらはすべてデフォルトで有効です) 、型が不明なキーに String 型を使用することで、スキーマ推論時に Cannot determine type for column 'column_name' by first 25000 rows of data, most likely this column contains only Nulls or empty Arrays/Maps のようなエラーを回避できます。 例:
Query
Response

CSV

CSVフォーマットでは、ClickHouse は区切り文字に従って行からカラムの値を抽出します。ClickHouse では、数値と文字列を除くすべての型が二重引用符で囲まれていることを前提としています。値が二重引用符で囲まれている場合、ClickHouse は再帰的なパーサーを使って 引用符内のデータをパースし、その後、それに最も適したデータ型を見つけようとします。値が二重引用符で囲まれていない場合、ClickHouse はそれを数値としてパースしようとし、 数値でなければ文字列として扱います。 ClickHouse が一部のパーサーやヒューリスティクスを使って複雑な型を判定しないようにしたい場合は、設定 input_format_csv_use_best_effort_in_schema_inference を無効にできます。そうすると、ClickHouse はすべてのカラムを String として扱います。 設定 input_format_csv_detect_header が有効な場合、ClickHouse はスキーマ推論時に、カラム名 (場合によっては型も含む) を持つヘッダーを検出しようとします。この設定はデフォルトで有効です。 例: 整数、浮動小数点数、Bool、String:
引用符で囲まれていない文字列:
日付、DateTime 型:
Array:
配列にNULLが含まれている場合、ClickHouseは他の配列要素の型を使用します:
Map:
入れ子になった Array と Map:
データに null しか含まれていないため、ClickHouse が引用符で囲まれた値の型を判定できない場合、ClickHouse はそれを String として扱います:
input_format_csv_use_best_effort_in_schema_inference 設定を無効にした例:
ヘッダーの自動検出の例 (input_format_csv_detect_header が有効な場合) : 列名のみ:
名前とデータ型:
少なくとも1つのカラムがString type以外である場合にのみ、ヘッダーを検出できることに注意してください。すべてのカラムがString typeである場合、ヘッダーは検出されません。

CSV の設定

input_format_csv_try_infer_numbers_from_strings
この設定を有効にすると、文字列の値から数値を推定できるようになります。 この設定はデフォルトで無効です。 例:

TSV/TSKV

TSV/TSKVフォーマットでは、ClickHouse は表形式の区切り文字に従って行からカラムの値を抽出し、その後、 再帰的なパーサーを使用して抽出した値を解析し、最も適切な型を判定します。型を判定できない場合、ClickHouse はその値を String として扱います。 ClickHouse に一部のパーサーやヒューリスティクスを使って複雑な型を判定させたくない場合は、設定 input_format_tsv_use_best_effort_in_schema_inference を無効にできます。 その場合、ClickHouse はすべてのカラムを String として扱います。 設定 input_format_tsv_detect_header が有効な場合、ClickHouse はスキーマ推論時にカラム名 (場合によっては型も含む) を持つヘッダーの検出を試みます。この設定はデフォルトで有効です。 例: 整数、浮動小数点数、Bool、文字列:
Date、DateTime 型:
Array:
配列にNULLが含まれている場合、ClickHouse は他の配列要素の型を使用します:
タプル:
Map:
ネストされたArray、Tuple、Map:
データに NULL しか含まれていないため ClickHouse が型を判定できない場合、ClickHouse はそれを String として扱います。
設定 input_format_tsv_use_best_effort_in_schema_inference を無効にした場合の例:
ヘッダー自動検出の例 (input_format_tsv_detect_header が有効な場合) : 名前のみ:
名前とデータ型:
少なくとも1つのカラムがString型以外である場合にのみ、ヘッダーを検出できる点に注意してください。すべてのカラムがString型の場合、ヘッダーは検出されません。

Values フォーマットでは、ClickHouse は行からカラムの値を抽出し、リテラルのパース時と同様の再帰的なパーサーを使用してパースします。 例: 整数、浮動小数点数、Bool、String:
日付、DateTime 型:
Arrays:
ArrayにNULLが含まれる場合、ClickHouseは他のArray要素の型を使用します:
タプル:
Map型:
ネストされたArray、Tuple、Map:
データに NULL しか含まれていないため ClickHouse が型を判定できない場合は、例外がスローされます:
input_format_tsv_use_best_effort_in_schema_inference 設定を無効にした例:

CustomSeparated

CustomSeparated フォーマットでは、ClickHouse はまず、指定された区切り文字に従って行からすべてのカラム値を抽出し、その後、エスケープ規則に基づいて各値のデータ型を推定します。 設定 input_format_custom_detect_header が有効な場合、ClickHouse はスキーマ推論時に、カラム名 (場合によっては型も含む) を持つヘッダーの検出を試みます。この設定はデフォルトで有効です。
ヘッダーの自動検出の例 (input_format_custom_detect_header が有効になっている場合) :

Template

Templateフォーマットでは、ClickHouse はまず指定されたテンプレートに従って行からすべてのカラムの値を抽出し、その後、各値のエスケープ規則に基づいてそれぞれのデータ型を推定します。 次の内容のファイル resultset があるとします。
そして、内容が次のとおりのファイル row_format
次に、以下のクエリを実行できます。

Regexp

Template と同様に、Regexp フォーマットでは、ClickHouse はまず指定された正規表現に従って行からすべてのカラム値を抽出し、その後、指定されたエスケープ規則に基づいて各値のデータ型を推論します。

テキストフォーマットの設定

input_format_max_rows_to_read_for_schema_inference/input_format_max_bytes_to_read_for_schema_inference

これらの設定は、スキーマ推論時に読み取るデータ量を制御します。 読み取る行数/バイト数が多いほど、スキーマ推論にかかる時間は長くなりますが、型を正しく判定できる可能性も高くなります (特に、データに NULL が多く含まれる場合) 。 デフォルト値:
  • input_format_max_rows_to_read_for_schema_inference25000
  • input_format_max_bytes_to_read_for_schema_inference33554432 (32 Mb)

column_names_for_schema_inference

明示的なカラム名がないフォーマットで、スキーマ推論に使用するカラム名の一覧です。指定した名前は、デフォルトの c1,c2,c3,... の代わりに使用されます。形式: column1,column2,column3,...

schema_inference_hints

自動判定された型の代わりに、スキーマ推論で使用するカラム名と型の一覧です。フォーマット: ‘column_name1 column_type1, column_name2 column_type2, …’。 この設定は、自動では判定できなかったカラムの型を指定したり、スキーマを最適化したりする際に使用できます。

schema_inference_make_columns_nullable $

null許容性に関する情報を持たないフォーマットのスキーマ推論において、推論された型をNullableにするかどうかを制御します。設定可能な値:
  • 0 - 推論される型が Nullable になることはありません。
  • 1 - 推論される型はすべて Nullable になります,
  • 2 または ‘auto’ - テキストフォーマットでは、スキーマ推論時に解析されるサンプル内のカラムに NULL が含まれている場合にのみ、推論される型は Nullable になります。厳密に型付けされたフォーマット (Parquet、ORC、Arrow) では、NULL 許容性の情報はファイルのメタデータから取得されます。
  • 3 - テキストフォーマットでは Nullable を使用し、厳密な型情報を持つフォーマットではファイルメタデータを使用します。
デフォルト: 3。

input_format_try_infer_integers

この設定は JSON データ型には適用されません。
有効にすると、ClickHouse はテキストフォーマットのスキーマ推論で、浮動小数点数ではなく整数型を推論しようとします。 サンプルデータ内のそのカラムのすべての数値が整数である場合、結果の型は Int64 になります。少なくとも 1 つの数値が浮動小数点数である場合、結果の型は Float64 になります。 サンプルデータに整数しか含まれておらず、かつ少なくとも 1 つの整数が正の値で Int64 の範囲を超える場合、ClickHouse は UInt64 を推論します。 デフォルトで有効です。

input_format_try_infer_datetimes

有効な場合、ClickHouse はテキストフォーマットのスキーマ推論で、文字列フィールドから DateTime または DateTime64 型の推論を試みます。 サンプルデータ内のあるカラムについて、すべてのフィールドが日時として正常に解析された場合、結果の型は DateTime または DateTime64(9) になります (いずれかの日時に小数部が含まれている場合) 。 1 つでも日時として解析されないフィールドがある場合、結果の型は String になります。 デフォルトで有効です。

input_format_try_infer_datetimes_only_datetime64

有効な場合、input_format_try_infer_datetimes が有効になっていれば、日時の値に小数部が含まれていなくても、ClickHouse は常に DateTime64(9) を推論します。 デフォルトでは無効です。
注意: スキーマ推論時に日時をパースする際は、設定 date_time_input_format に従います

input_format_try_infer_dates

有効にすると、ClickHouse はテキストフォーマットのスキーマ推論で、文字列フィールドから Date 型を推論しようとします。 サンプルデータ内のあるカラムのすべてのフィールドが日付として正常に解析された場合、結果の型は Date になります。 1 つでも日付として解析されないフィールドがある場合、結果の型は String になります。 デフォルトで有効です。

input_format_try_infer_exponent_floats

有効にすると、ClickHouse はテキストフォーマットで指数表記の数値を浮動小数点数として推論しようとします (JSON を除く。JSON では指数表記の数値は常に推論されます) 。 デフォルトでは無効です。

自己記述フォーマット

自己記述フォーマットでは、データの構造に関する情報がデータ自体に含まれています。 たとえば、説明を含むヘッダー、バイナリの型ツリー、あるいは何らかのテーブルです。 ClickHouse は、このようなフォーマットのファイルからスキーマを自動推論するために、型に関する情報を含む データの一部を読み取り、それを ClickHouse テーブルのスキーマに変換します。

-WithNamesAndTypes 接尾辞付きフォーマット

ClickHouse は、-WithNamesAndTypes という接尾辞が付いた一部のテキストフォーマットをサポートしています。この接尾辞は、実際のデータの前に、カラム名と型を示す 2 行が追加で含まれることを意味します。 このようなフォーマットでスキーマ推論を行う際、ClickHouse は最初の 2 行を読み取り、カラム名と型を抽出します。

メタデータを含む JSON フォーマット

一部の JSON 入力フォーマット (JSONJSONCompactJSONColumnsWithMetadata) には、カラム名や型のメタデータが含まれています。 このようなフォーマットのスキーマ推論では、ClickHouse はこのメタデータを読み取ります。

Avro

Avroフォーマットでは、ClickHouse はデータからスキーマを読み取り、以下の型対応に従って ClickHouse のスキーマに変換します。 その他の Avro 型はサポートされていません。

Parquet

Parquet フォーマットでは、ClickHouse はデータからスキーマを読み取り、以下の型対応に基づいて ClickHouse のスキーマに変換します。 その他の Parquet 型はサポートされていません。

Arrow

Arrow フォーマットでは、ClickHouse はデータからスキーマを読み取り、次の型対応に基づいて ClickHouse のスキーマへ変換します。 そのほかの Arrow 型はサポートされていません。

ORC

ORCフォーマットでは、ClickHouseはデータからスキーマを読み取り、次の型対応に従ってClickHouseのスキーマへ変換します。 そのほかのORC型はサポートされていません。

Native

Native フォーマットは ClickHouse 内部で使用され、データ自体にスキーマが含まれています。 スキーマ推論では、ClickHouse は変換を行わずにデータからスキーマを読み取ります。

外部スキーマを使用するフォーマット

この種のフォーマットでは、データを記述するスキーマを、特定のスキーマ言語で別ファイルに定義する必要があります。 この種のフォーマットのファイルからスキーマ推論を行うため、ClickHouse は別ファイルから外部スキーマを読み取り、ClickHouse のテーブルスキーマに変換します。

Protobuf

Protobuf フォーマットのスキーマ推論では、ClickHouse は以下の型対応を使用します。

CapnProto

CapnProto フォーマットのスキーマ推論では、ClickHouse は以下のように型対応します。

厳密に型付けされたバイナリ形式

このようなフォーマットでは、シリアル化された各値にその型 (場合によっては名前も) に関する情報は含まれますが、テーブル全体に関する情報は含まれません。 このようなフォーマットのスキーマ推論では、ClickHouse はデータを行単位で読み取り (最大 input_format_max_rows_to_read_for_schema_inference 行または input_format_max_bytes_to_read_for_schema_inference バイトまで) 、各値の型 (場合によっては名前も) をデータから抽出し、 それらの型を ClickHouse の型に変換します。

MsgPack

MsgPack フォーマットでは行の間に区切り文字がないため、このフォーマットでスキーマ推論を使用するには、設定 input_format_msgpack_number_of_columns でテーブルのカラム数を指定する必要があります。ClickHouse では、次のように型対応します。 デフォルトでは、推論されたすべての型は Nullable になりますが、設定 schema_inference_make_columns_nullable で変更できます。

BSONEachRow

BSONEachRow では、各行のデータが BSON ドキュメントとして表されます。スキーマ推論では、ClickHouse は BSON ドキュメントを 1 つずつ読み取り、データから値、名前、型を抽出したうえで、以下の型対応に基づいてそれらを ClickHouse の型に変換します。 デフォルトでは、推論されたすべての型は Nullable でラップされますが、設定 schema_inference_make_columns_nullable を使って変更できます。

固定スキーマのフォーマット

このようなフォーマットでは、データは常に同じスキーマになります。

LineAsString

このフォーマットでは、ClickHouse はデータの1行全体を String データ型の単一カラムとして読み込みます。このフォーマットで推論される型は常に String で、カラム名は line です。

JSONAsString

このフォーマットでは、ClickHouse はデータ内の JSON オブジェクト全体を String データ型の 1 つのカラムに読み込みます。このフォーマットで推論される型は常に String で、カラム名は json です。

JSONAsObject

このフォーマットでは、ClickHouse はデータ内の JSONオブジェクト全体を、JSON データ型の単一のカラムに読み込みます。このフォーマットで推論される型は常に JSON で、カラム名は json です。

スキーマ推論モード

データファイルの集合に対するスキーマ推論は、defaultunion の 2 つの異なるモードで動作します。 このモードは、設定 schema_inference_mode で制御されます。

デフォルトモード

デフォルトモードでは、ClickHouse はすべてのファイルが同じスキーマを持つとみなし、スキーマを推定できるまでファイルを 1 つずつ読み取ります。 例: data1.jsonldata2.jsonldata3.jsonl の 3 つのファイルがあり、内容は次のとおりだとします。 data1.jsonl:
data2.jsonl:
data3.jsonl:
これら3つのファイルに対してスキーマ推論を試してみましょう:
Query
Response
ご覧のとおり、ファイル data3.jsonlfield3 は含まれていません。 これは、ClickHouse がまずファイル data1.jsonl からスキーマを推論しようとしたものの、フィールド field2 がすべて NULL だったために失敗し、 その後 data2.jsonl からのスキーマ推論には成功したため、ファイル data3.jsonl のデータは読み込まれなかったためです。

ユニオンモード

ユニオンモードでは、ClickHouse はファイルごとに異なるスキーマを持つ可能性があるとみなし、すべてのファイルのスキーマを推論したうえで、それらを 1 つの共通スキーマにユニオンします。 次の内容を持つ 3 つのファイル data1.jsonldata2.jsonldata3.jsonl があるとします。 data1.jsonl:
data2.jsonl:
data3.jsonl:
次の3つのファイルに対して、スキーマ推論を試してみましょう:
Query
Response
ご覧のとおり、すべてのファイルのすべてのフィールドが含まれています。 注:
  • 一部のファイルには、推論後のスキーマに含まれるカラムの一部が存在しない場合があるため、ユニオンモードはカラムの部分集合の読み取りをサポートするフォーマット (JSONEachRow、Parquet、TSVWithNames など) でのみサポートされます。その他のフォーマット (CSV、TSV、JSONCompactEachRow など) では動作しません。
  • ClickHouse がいずれかのファイルからスキーマを推論できない場合は、例外がスローされます。
  • ファイル数が多い場合、それらすべてからスキーマを読み取るのにかなり時間がかかることがあります。

フォーマットの自動検出

データのフォーマットが指定されておらず、ファイル拡張子からも判断できない場合、ClickHouse は内容に基づいてファイルのフォーマットを自動検出しようとします。 例: 次のような内容の data があるとします。
フォーマットや構造を指定しなくても、このファイルを確認してクエリを実行できます。
ClickHouseが検出できるのは一部のフォーマットだけで、この検出には多少時間もかかるため、フォーマットは常に明示的に指定することをおすすめします。
最終更新日 2026年6月10日