الاستخدام
structure الذي يحدد بنية بيانات الإدخال. وإذا لم يُحدَّد هذا الوسيط أو ضُبط على auto، فستُستنتَج البنية من البيانات.
مثال:
لنفترض أن لدينا الملف hobbies.jsonl بتنسيق JSONEachRow داخل الدليل user_files وبالمحتوى التالي:
JSONEachRow تلقائيًا استنادًا إلى امتداد الملف .jsonl.
يمكنك الاطلاع على البنية التي جرى تحديدها تلقائيًا باستخدام استعلام DESCRIBE:
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 تلقائيًا ما إذا كان من الممكن استخدام البنية من جدول الإدراج أو اللجوء إلى استنتاج المخطط. هذه هي القيمة الافتراضية.
hobbies1 بالبنية التالية:
hobbies.jsonl:
hobbies2 بالبنية التالية:
hobbies.jsonl:
SELECT موجودة في الجدول، لذا سيستخدم ClickHouse البنية من جدول الإدراج.
لاحظ أن هذا سيعمل فقط مع تنسيقات الإدخال التي تدعم قراءة مجموعة فرعية من الأعمدة، مثل JSONEachRow وTSKV وParquet وغيرها. (لذلك، لن يعمل مثلًا مع تنسيق TSV).
مثال 3:
لننشئ الجدول hobbies3 بالبنية التالية:
hobbies.jsonl:
id في استعلام SELECT، لكن الجدول لا يحتوي على هذا العمود (بل يحتوي على عمود باسم identifier)،
لذلك لا يمكن لـ ClickHouse استخدام بنية جدول الإدراج، وسيُستخدَم استنتاج المخطط.
Example 4:
لنُنشئ الجدول hobbies4 بالبنية التالية:
hobbies.jsonl:
hobbies في استعلام SELECT لإدراجه في الجدول، لذلك لا يمكن لـ ClickHouse استخدام البنية الخاصة بجدول الإدراج، وسيُستخدم استدلال المخطط.
ذاكرة التخزين المؤقت لاستنتاج المخطط
schema_inference_cache_max_elements_for_{file/s3/hdfs/url/azure}- الحد الأقصى لعدد المخططات المخزنة مؤقتًا لوظيفة الجدول المقابلة. القيمة الافتراضية هي4096. يجب ضبط هذه الإعدادات في إعدادات الخادم.schema_inference_use_cache_for_{file,s3,hdfs,url,azure}- يتيح تشغيل استخدام ذاكرة التخزين المؤقت لاستنتاج المخطط أو إيقافه. يمكن استخدام هذه الإعدادات في الاستعلامات.
url على معلومات عن وقت التعديل الأخير؛ وفي هذه الحالة، يوجد إعداد خاص
schema_inference_cache_require_modification_time_for_url. يتيح تعطيل هذا الإعداد استخدام المخطط من ذاكرة التخزين المؤقت دون وقت التعديل الأخير لمثل هذه الملفات.
يوجد أيضًا جدول نظام schema_inference_cache يضم جميع المخططات الحالية في ذاكرة التخزين المؤقت، وكذلك استعلام النظام SYSTEM CLEAR SCHEMA CACHE [FOR File/S3/URL/HDFS]
الذي يتيح تنظيف ذاكرة التخزين المؤقت للمخطط لجميع المصادر أو لمصدر محدد.
أمثلة:
لنجرب استنتاج البنية لمجموعة بيانات تجريبية من S3 باسم github-2022.ndjson.gz ونرى كيف تعمل ذاكرة التخزين المؤقت لاستنتاج المخطط:
system.schema_inference_cache:
تنسيقات النص
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
null، فسيستخدم ClickHouse الأنواع المستمدة من عناصر المصفوفة الأخرى:
input_format_json_infer_array_of_dynamic_from_array_of_different_types مُفعَّلاً (وهو مُفعَّل افتراضياً)، فسيكون نوعها Array(Dynamic):
input_format_json_try_infer_named_tuples_from_objects ممكّنًا، سيحاول ClickHouse أثناء استنتاج المخطط استنتاج Tuple مُسمّى من كائنات JSON.
وسيحتوي الـ Tuple المُسمّى الناتج على جميع العناصر من كل كائنات JSON المقابلة في بيانات العينة.
input_format_json_infer_array_of_dynamic_from_array_of_different_types معطّلًا، فنعتبر المصفوفات التي تتكوّن من عناصر ذات أنواع مختلفة Tuples غير مسماة في تنسيقات JSON.
null أو فارغة، فإننا نستخدم أنواع القيم المناظرة من الصفوف الأخرى:
input_format_json_read_objects_as_strings وinput_format_json_try_infer_named_tuples_from_objects.
String إذا كان الإعداد input_format_json_infer_incomplete_types_as_strings مفعّلًا، وإلا فسيُطلق استثناء:
إعدادات JSON
input_format_json_try_infer_numbers_from_strings
input_format_json_try_infer_named_tuples_from_objects
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 باعتبارها Tuples مُسمّاة حتى عند وجود مسارات غير واضحة.
يكون معطّلًا افتراضيًا.
أمثلة
عند تعطيل الإعداد:
Query
Response
Query
Response
input_format_json_read_objects_as_strings
input_format_json_try_infer_named_tuples_from_objects معطّلًا.
input_format_json_read_numbers_as_strings
input_format_json_read_bools_as_numbers
input_format_json_read_bools_as_strings
input_format_json_read_arrays_as_strings
input_format_json_infer_incomplete_types_as_strings
Null/{}/[].
في تنسيقات JSON، يمكن قراءة أي قيمة باعتبارها 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 أثناء استنتاج المخطّط
باستخدام النوع String للمفاتيح ذات الأنواع غير المعروفة.
مثال:
Query
Response
CSV
input_format_csv_use_best_effort_in_schema_inference
وعندها سيتعامل ClickHouse مع جميع الأعمدة على أنها Strings.
إذا كان الإعداد input_format_csv_detect_header ممكّنًا، فسيحاول ClickHouse اكتشاف صف العناوين الذي يتضمن أسماء الأعمدة (وربما الأنواع أيضًا) أثناء استنتاج المخطط. وهذا الإعداد مفعّل افتراضيًا.
أمثلة:
الأعداد الصحيحة، والأعداد العائمة، والقيم المنطقية، والسلاسل النصية:
input_format_csv_use_best_effort_in_schema_inference:
input_format_csv_detect_header ممكّنًا):
الأسماء فقط:
String. وإذا كانت جميع الأعمدة من النوع String، فلن يتم التعرّف على صف العناوين:
إعدادات CSV
input_format_csv_try_infer_numbers_from_strings
TSV/TSKV
input_format_tsv_use_best_effort_in_schema_inference
وعندها سيتعامل ClickHouse مع جميع الأعمدة على أنها Strings.
إذا كان الإعداد input_format_tsv_detect_header مُمكّنًا، فسيحاول ClickHouse اكتشاف صف العناوين الذي يحتوي على أسماء الأعمدة (وربما الأنواع) أثناء استنتاج المخطط. وهذا الإعداد مُمكّن افتراضيًا.
أمثلة:
الأعداد الصحيحة، الأعداد ذات الفاصلة العائمة، القيم المنطقية، السلاسل النصية:
input_format_tsv_use_best_effort_in_schema_inference:
input_format_tsv_detect_header ممكّنًا):
الأسماء فقط:
القيم
input_format_tsv_use_best_effort_in_schema_inference:
CustomSeparated
input_format_custom_detect_header مُمكّنًا، فسيحاول ClickHouse اكتشاف صف العناوين الذي يحتوي على أسماء الأعمدة (وربما الأنواع) أثناء استنتاج المخطط. ويكون هذا الإعداد مُمكّنًا افتراضيًا.
مثال
input_format_custom_detect_header مفعّلًا):
Template
resultset بالمحتوى التالي:
row_format بالمحتوى التالي:
Regexp
إعدادات تنسيقات النص
input_format_max_rows_to_read_for_schema_inference/input_format_max_bytes_to_read_for_schema_inference
25000لـinput_format_max_rows_to_read_for_schema_inference.33554432(32 Mb) لـinput_format_max_bytes_to_read_for_schema_inference.
column_names_for_schema_inference
c1,c2,c3,.... التنسيق: column1,column2,column3,....
مثال
schema_inference_hints
schema_inference_make_columns_nullable $
Nullable في استنتاج المخطط للتنسيقات التي لا تحتوي على معلومات حول قابلية القيم الفارغة. القيم المحتملة:
- 0 - لن يكون النوع المُستنتَج
Nullableأبدًا، - 1 - ستكون جميع الأنواع المُستنتَجة
Nullable، - 2 or ‘auto’ - بالنسبة إلى التنسيقات النصية، سيكون النوع المُستنتَج
Nullableفقط إذا كان العمود يحتوي علىNULLضمن عيّنة جرى تحليلها أثناء استدلال المخطط؛ أما في التنسيقات ذات الأنواع الصريحة (Parquet وORC وArrow)، فتُستمد معلومات قابلية القيم الفارغة من البيانات الوصفية للملف، - 3 - بالنسبة إلى التنسيقات النصية، استخدم
Nullable؛ أما في التنسيقات ذات الأنواع الصريحة، فاستخدم البيانات الوصفية للملف.
input_format_try_infer_integers
لا ينطبق هذا الإعداد على نوع البيانات
JSON.Int64، أما إذا وُجد رقم عائم واحد على الأقل، فسيكون النوع الناتج Float64.
إذا كانت بيانات العينة تحتوي على أعداد صحيحة فقط، وكان هناك عدد صحيح موجب واحد على الأقل يتجاوز Int64، فسيستنتج ClickHouse النوع UInt64.
مُمكَّن افتراضيًا.
أمثلة
input_format_try_infer_datetimes
DateTime أو DateTime64 من الحقول النصية أثناء استدلال المخطط في تنسيقات النص.
إذا جرى تحليل جميع الحقول في عمود من بيانات العينة بنجاح على أنها قيم تاريخ/وقت، فسيكون النوع الناتج هو DateTime أو DateTime64(9) (إذا كانت أي قيمة تاريخ/وقت تحتوي على جزء كسري)،
وإذا تعذّر تحليل حقل واحد على الأقل على أنه قيمة تاريخ/وقت، فسيكون النوع الناتج هو String.
مفعّل افتراضيًا.
أمثلة
input_format_try_infer_datetimes_only_datetime64
DateTime64(9) عند تفعيل input_format_try_infer_datetimes حتى إذا كانت قيم التاريخ والوقت لا تحتوي على جزء عشري.
يكون معطّلًا افتراضيًا.
أمثلة
input_format_try_infer_dates
Date من الحقول النصية عند استدلال المخطط في التنسيقات النصية.
إذا جرى تحليل جميع الحقول في عمود من البيانات العيّنية بنجاح على أنها تواريخ، فسيكون نوع النتيجة Date،
أما إذا تعذّر تحليل حقل واحد على الأقل على أنه تاريخ، فسيكون نوع النتيجة String.
مفعّل افتراضيًا.
أمثلة
input_format_try_infer_exponent_floats
التنسيقات ذاتية الوصف
التنسيقات ذات اللاحقة -WithNamesAndTypes
تنسيقات JSON مع البيانات الوصفية
Avro
أنواع Avro الأخرى غير مدعومة.
Parquet
أنواع Parquet الأخرى غير مدعومة.
Arrow
أنواع Arrow الأخرى غير مدعومة.
ORC
أنواع ORC الأخرى غير مدعومة.
Native
التنسيقات ذات المخطط الخارجي
Protobuf
CapnProto
التنسيقات الثنائية ذات الأنواع المحددة بصرامة
input_format_max_rows_to_read_for_schema_inference صفًا أو input_format_max_bytes_to_read_for_schema_inference بايتًا)، ويستخرج
النوع (وربما الاسم) لكل قيمة من البيانات، ثم يحوّل هذه الأنواع إلى أنواع ClickHouse.
MsgPack
input_format_msgpack_number_of_columns. يستخدم ClickHouse تطابقات الأنواع التالية:
افتراضيًا، تكون جميع الأنواع المستنتجة ضمن
Nullable، ولكن يمكن تغيير ذلك باستخدام الإعداد schema_inference_make_columns_nullable.
BSONEachRow
افتراضيًا، تكون جميع الأنواع المستنتجة ضمن
Nullable، ولكن يمكن تغيير ذلك باستخدام الإعداد schema_inference_make_columns_nullable.
التنسيقات ذات المخطط الثابت
LineAsString
String. ويكون النوع المُستنتَج لهذا التنسيق دائمًا String، ويكون اسم العمود line.
مثال
JSONAsString
String. ويكون النوع المُستنتَج لهذا التنسيق دائمًا String، ويكون اسم العمود json.
مثال
JSONAsObject
JSON. ويكون النوع المستنتج لهذا التنسيق دائمًا JSON، ويكون اسم العمود json.
مثال
أوضاع استنتاج المخطط
default وunion.
ويُتحكَّم في هذا الوضع عبر الإعداد schema_inference_mode.
الوضع الافتراضي
data1.jsonl وdata2.jsonl وdata3.jsonl بالمحتوى التالي:
data1.jsonl:
data2.jsonl:
data3.jsonl:
Query
Response
field3 من الملف data3.jsonl.
يحدث ذلك لأن ClickHouse حاول أولًا استنتاج المخطط من الملف data1.jsonl، لكنه فشل بسبب احتواء الحقل field2 على قيم null فقط،
ثم حاول استنتاج المخطط من data2.jsonl ونجح، لذلك لم تُقرأ البيانات من الملف data3.jsonl.
وضع union
data1.jsonl وdata2.jsonl وdata3.jsonl بالمحتوى التالي:
data1.jsonl:
data2.jsonl:
data3.jsonl:
Query
Response
- نظرًا إلى أن بعض الملفات قد لا تحتوي على بعض الأعمدة في المخطط الناتج، فإن وضع union مدعوم فقط للتنسيقات التي تدعم قراءة مجموعة فرعية من الأعمدة (مثل JSONEachRow وParquet وTSVWithNames وما إلى ذلك)، ولن يعمل مع التنسيقات الأخرى (مثل CSV وTSV وJSONCompactEachRow وما إلى ذلك).
- إذا تعذّر على ClickHouse استنتاج المخطط من أحد الملفات، فسيُطرَح استثناء.
- إذا كان لديك عدد كبير من الملفات، فقد تستغرق قراءة المخطط من جميعها وقتًا طويلًا.
الكشف التلقائي عن التنسيق
data بالمحتوى التالي:
لا يستطيع ClickHouse اكتشاف سوى بعض التنسيقات، كما أن هذا الاكتشاف يستغرق بعض الوقت، لذلك من الأفضل دائمًا تحديد التنسيق صراحةً.