Clickhouse Flashcards
Приходилось ли работать с внешними сервисами (Kafka, S3) через ClickHouse? Как настраивать?
Теги: #wildberries #x5
Для интеграции с внешними сервисами в ClickHouse используются специальные типы таблиц-движков.
- Kafka:
o Создаётся таблица с движком Kafka, в параметрах указывается адрес брокера, топик, настройки десериализации (JSON, Protobuf и т. д.).
o Обычно создают «промежуточную» таблицу на движке Kafka и «финальную» на MergeTree (или другом подходящем движке).
o Для загрузки данных используется Materialized View (материализованное представление), которое «слушает» таблицу Kafka и складывает данные в финальную таблицу.
o Важно следить за параметрами max_block_size, max_insert_block_size, настройками ретеншена в Kafka и количеством потребителей (если их несколько). - S3:
o Можно подключить S3 как внешний источник или использовать движок S3:
CREATE TABLE s3_table (…) ENGINE = S3(‘https://s3.endpoint/bucket/file.csv’, ‘CSV’, ‘structure’);
o Или использовать провайдер внешних данных для чтения/записи.
o Часто применяется для хранения бэкапов, больших дампов, архивов, из которых потом загружают данные в MergeTree-таблицы.
Настройка сводится к указанию соответствующих параметров (адреса, форматов данных, учетных данных) в DDL запроса при создании таблицы или при использовании плагинов.
wildberries #x5 #okko
Какие существуют движки в ClickHouse? Какие из них использовали, что с ними делали?
Основные типы движков (table engines) в ClickHouse:
* MergeTree и его варианты: MergeTree, ReplacingMergeTree, SummingMergeTree, AggregatingMergeTree, CollapsingMergeTree, VersionedCollapsingMergeTree, ReplicatedMergeTree и т. д.
o Это основа для хранения больших объёмов данных с быстрыми аналитическими запросами.
* Distributed: позволяет «проксировать» запросы на несколько шардов и собирать результаты, используется для кластеризации.
* Memory: хранение данных в оперативной памяти, подходит для временных и очень быстрых таблиц.
* Log / TinyLog / StripeLog: простые форматы без сложных оптимизаций, обычно для небольших тестовых задач.
* Kafka, HDFS, S3: для чтения (и иногда записи) данных напрямую из внешних систем.
* Buffer: буферизация записей в памяти перед тем, как отправить их в основную таблицу.
* Dictionary: движки для справочников, чтобы быстро подключать внешние словари в запросы.
На практике чаще всего используют семейство MergeTree (обычный MergeTree или его реплицированные варианты) для аналитики и Distributed, если есть несколько инстансов (нод) в кластере. Kafka — для потоковой загрузки данных, Memory — для быстрого кэширования или временных вычислений.
Какие есть особенности JOIN-ов в ClickHouse (справочники, avoidance shuffle/долгие джоины)? В каких случаях ClickHouse не может выполнять JOIN?
Теги: #мир #wildberries #okko
- Механика JOIN: По умолчанию ClickHouse не оптимизирован под большие распределённые JOIN-ы «как в классических СУБД». Он пытается загрузить данные «маленькой» таблицы в оперативную память и сопоставить с «большой» таблицей построчно. Если обе таблицы слишком большие, может возникнуть недостаток памяти.
- Distributed JOIN: При работе с кластером и движком Distributed нужно учитывать, что джоины могут «ходить» между шардовыми нодами, что приводит к высокой сетевой загрузке.
- Справочники (Dictionary): Чтобы уменьшить нагрузку при JOIN-ах, часто делают внешний словарь (например, из файлов CSV, из MySQL или HTTP-источников) и используют функцию dictGet(). Это быстрее, чем хранить большую вспомогательную таблицу и делать обычный JOIN.
- Ситуации, когда JOIN не выполняется:
o Если обе таблицы слишком велики для согласованной обработки в памяти (и нет достаточных ресурсов).
o Если ClickHouse не умеет «распараллеливать» JOIN и настраивается broadcast join, тогда при превышении лимита по памяти запрос упадёт с ошибкой.
o Для очень больших (много миллиардов строк) таблиц может потребоваться особая архитектура: предварительное агрегирование или использование иных схем (например, ReplacingJoin — но это более специальный случай).
MergeTree vs ReplacingMergeTree — в чём разница и когда какой использовать?
Теги: #ПетровичТех
- MergeTree – базовый движок, который просто хранит данные в сегментах и периодически мёрджит их.
- ReplacingMergeTree – расширение MergeTree с дополнительной логикой «замены» дубликатов во время слияний.
o В таблице можно указать столбец «версия» (version_col), при совпадении ключа (Primary Key/ORDER BY) во время мерджа остаётся самая новая запись по этому столбцу.
o Если version_col не указан, то при совпадении ключа случайно выбирается одна запись (чаще всего последняя вставленная).
Когда использовать: - ReplacingMergeTree применяют для дедупликации или «актуализации» данных, когда одна и та же строка может приходить несколько раз и требуется хранить только самую последнюю версию.
- Обычный MergeTree используют, если дубликаты сами по себе не мешают и нужны именно все вставленные данные (или вы будете управлять дубликатами на уровне приложения).
Update и Delete в ClickHouse: как это работает и в каких случаях применяется?
Теги: #ПетровичТех
- В классическом понимании «UPDATE» и «DELETE» (как в PostgreSQL/MySQL) в ClickHouse долгое время отсутствовали. Сейчас есть ALTER UPDATE / ALTER DELETE, но они работают иначе:
o При запросе ALTER TABLE … DELETE WHERE … или ALTER TABLE … UPDATE … WHERE … данные не удаляются/обновляются моментально на месте.
o Вместо этого формируется «задание» (mutation), и при последующих слияниях сегментов данные физически перезаписываются или удаляются. - Это означает, что:
o Операция не моментальна: изменения становятся видны сразу в query (за счёт версионности), но физически обновление произойдёт только при мёрдже кусков данных.
o Производительность: частое использование таких команд может перегрузить систему мёрджами. Лучше стараться проектировать систему так, чтобы операций UPDATE/DELETE было как можно меньше (ClickHouse — прежде всего аналитическая СУБД). - Применяется в случаях, когда нужно редактировать часть уже загруженных данных (например, GDPR, удаление ошибочных вставок, обновление статусов), но это не рекомендуется использовать часто.
Сравнение ClickHouse и PostgreSQL: основные особенности, в каких случаях предпочтительнее использовать каждую?
Теги: #🐺
- ClickHouse
o Колоночное хранение, оптимизировано под аналитические запросы с большими сканированиями (OLAP).
o Очень быстрая агрегация, сжатие, работа с time-series, логами, метриками.
o Не полностью поддерживает транзакции (ACID) в классическом виде, ограниченные возможности по Update/Delete.
o Идеален там, где нужно обрабатывать большие объёмы и делать сложные аналитику/отчётность. - PostgreSQL
o Строчно-ориентированное хранение, классическая реляционная СУБД (OLTP).
o Хорошо поддерживает транзакции, сложные JOIN-ы, богатый SQL-синтаксис, хранимые процедуры.
o Подходит для веб-приложений, систем, где требуется частое обновление/удаление строк.
o Может использоваться в аналитике, но на очень больших объёмах будет проигрывать ClickHouse по скорости.
Что выбрать?
* Если вам нужно хранить и обрабатывать миллиарды строк для аналитических запросов и получать ответы «в реальном времени» — ClickHouse.
* Если нужны OLTP-сценарии, сложная бизнес-логика транзакций, постоянные INSERT/UPDATE/DELETE, согласованность данных — PostgreSQL.
Что именно сортируется в секции ORDER BY у MergeTree и как правильно подобрать ключ?
Теги: #x5
- В движках семейства MergeTree данные физически сортируются и хранятся по заданному ключу (из ORDER BY).
- Это значит, что при INSERT в таблицу новые данные записываются в файлы (part/куски) уже отсортированными по ключу, а во время мерджей поддерживается заданный порядок.
- Выбор ключа:
o Обычно включает колонки, по которым чаще всего фильтруются данные (WHERE) и которые помогают эффективно «пропускать» ненужные блоки (т. н. skip indices).
o Важно учитывать кардинальность и порядок полей. Например, для данных о логах часто ключом делают (timestamp, some_id). Это позволяет эффективно работать с запросами по времени и ID.
Таким образом, ORDER BY определяет физическую структуру хранения, и от этого сильно зависит производительность запросов.
Есть ли в ClickHouse PRIMARY KEY и как он связан с ORDER BY?
Теги: #x5
- В ClickHouse PRIMARY KEY существует как логическая конструкция, но фактически он не гарантирует уникальность, а определяет те же поля, что указаны в ORDER BY.
- Другими словами, PRIMARY KEY = ORDER BY (или подмножество) в MergeTree-таблицах.
- Уникальность строк не контролируется (нет механизма блокировок в классическом понимании).
- Главное назначение PRIMARY KEY в ClickHouse — ускорять поиск (данные по этому ключу отсортированы), а не обеспечивать целостность.
Архитектура ClickHouse: как устроены шарды и реплики, сколько их обычно бывает?
Теги: #x5
- Шард — это узел или группа данных в кластере ClickHouse, предназначенная для распределения нагрузки по горизонтали (шардирование). При запросах движок Distributed может рассылать запросы на разные шарды и собирать результаты.
- Реплика — это копия данных на разных серверах, используемая для отказоустойчивости и/или чтения без нагрузки на основной узел.
- В типичной конфигурации может быть, например, 2–4 шарда (зависит от объёмов данных и нагрузки), и у каждого шарда — 2–3 реплики. Итого в кластере бывает от нескольких до нескольких десятков машин.
- ReplicatedMergeTree-таблицы используют ZooKeeper для координации: при вставках и мерджах данные синхронизируются между репликами.
x5
Что такое View и Materialized View в ClickHouse? Как происходит автообновление материализованных представлений?
- View (Простое представление): в ClickHouse — это фактически сохранённый SQL-запрос. Данные не хранятся, а при каждом обращении к представлению выполняется исходный запрос. Подходит, когда нужен преднастроенный селект с каким-то сложным условием или объединениями.
- Materialized View (Материализованное представление): это физическая таблица, которая автоматически обновляется при вставке данных в «исходную» таблицу.
o Создаётся командой CREATE MATERIALIZED VIEW … TO table_name AS SELECT ….
o При вставке данных в исходную таблицу, движок автоматически «триггерит» вставку результата SELECT в связанную таблицу или саму MV.
o Можно использовать для агрегаций, преобразования данных «на лету» или организации потоковой нагрузки (например, с Kafka).
x5
Настройка TTL в ClickHouse: для чего нужен и как правильно конфигурируется?
- TTL (Time To Live) в ClickHouse позволяет автоматически удалять или перемещать (например, в более дешёвое хранилище) «старые» данные по заданному условию (обычно по дате/времени).
- Настраивается внутри DDL таблицы:
CREATE TABLE example
(
date DateTime,
…
)
ENGINE = MergeTree()
PARTITION BY toYYYYMM(date)
ORDER BY (date)
TTL date + INTERVAL 30 DAY - o Можно указать несколько правил TTL, например, сначала «переместить» (Move) в другой диск, а потом «удалить».
o Происходит во время слияний (merge). Если не было мерджа, физически данные могут ещё «лежать»,
x5 #okko
Мутации в ClickHouse: как они работают “под капотом”, почему относительно быстрые, как регулируется их выполнение и как обеспечивается консистентность?
- Мутации (mutations) — это механизм, с помощью которого реализуются ALTER UPDATE и ALTER DELETE.
- При выполнении ALTER TABLE … DELETE WHERE … или ALTER TABLE … UPDATE … WHERE … создаётся «задание на мутацию».
o ClickHouse не сразу «правит» данные в файлах. Он готовит новый партиальный кусок данных на основе старого (в процессе мерджа) и заменяет старый сегмент новым.
o Изменения видны почти сразу в плане логики (через версионность данных), хотя физически перезапись происходит во время мерджа. - Почему быстро:
o Нет построчного удаления: вместо этого идёт «ленивая» перекомпоновка данных на уровне сегментов (частей).
o Это масштабируется лучше, чем классические строчные апдейты. - Регулировка:
o Количество параллельных мутаций, лимиты по памяти и по времени, приоритеты — всё это настраивается в merge settings и параметрах сервера. - Консистентность:
o За счёт версионного чтения (не MVCC в классическом виде, но похожий подход): пока мутация не завершена, запросы читают старую версию, затем плавно переключаются на новую.
Основные отличительные особенности ClickHouse как СУБД: в чём его главная «фишка»?
Теги: #okko
- Колоночное хранение: отлично подходит для аналитических запросов (OLAP).
- Очень быстрая агрегация: за счёт сжатия, пропуска ненужных данных, SIMD-инструкций.
- Высокая масштабируемость: можно создавать распределённые кластеры, шардировать и реплицировать данные.
- Сегментная структура (MergeTree) с партиционированием и сортировкой по ключу.
- Низкая стоимость хранения больших объёмов: эффективное сжатие, возможность использовать HDD для холодных данных.
- Быстрые чтения, относительно сложные (и редкие) обновления: ориентирован на аналитику, статистику, мониторинг, логи.
Что такое шардирование в ClickHouse, как грамотно шардировать таблицы, какие тонкости и польза?
Теги: #okko
- Шардирование — это распределение данных по разным узлам (шардам) в кластере для горизонтального масштабирования.
- В ClickHouse обычно создаётся Distributed-таблица, указываются шарды и реплики. При вставке/запросе данные автоматически распределяются по «нижележащим» MergeTree-таблицам на узлах.
- Как грамотно шардировать:
o Выбрать ключ шардирования (в sharding_key), чтобы данные распределялись максимально равномерно и чтобы часто запрашиваемые данные не собирались все на одном шарде.
o Например, шардирование по user_id, session_id, если запросы более-менее равномерно «бьют» по этим ключам. - Тонкости:
o Следить, чтобы шардирование не приводило к «горячему» шару, когда большая часть запросов уходит в один узел.
o При join-ах между шардированными таблицами важно, чтобы ключ шардирования совпадал или подходил, иначе будет много сетевых обменов (shuffle). - Польза:
o Увеличение пропускной способности на записи и чтении, масштабирование под большие объёмы.
Как грамотно партиционировать таблицы в ClickHouse (и других MPP-системах)?
Теги: #okko
- Партиционирование (PARTITION BY) — это логическое разбиение данных на «партиции» (разделы), обычно по дате или другим крупным категориям.
- Зачем нужно:
o Ускорение запросов по «массовому отсечению» больших кусков данных (например, запрос по одному месяцу не будет сканировать все партиции за год).
o Удобство управления «жизненным циклом» (TTL), удаления или архивирования целых партиций. - Как выбрать поле:
o Чаще всего это дата (year-month, year-week, и т. д.), если много запросов «по времени».
o Если нет явной временной аналитики, выбирают поле, которое наиболее часто фигурирует в фильтре (например, регион, тип). - Важно:
o Не делать слишком мелкие партиции (иначе будет слишком много файлов и overhead).
o Не делать слишком крупные партиции (теряется польза от партиционирования). Обычно оптимально — партиция на 1 месяц или на 1 день, в зависимости от объёмов. - В других MPP-системах (Greenplum, Hive, Spark SQL) подходы схожи, но могут отличаться детали реализации (физическое vs логическое партиционирование).
Что такое кликхаус?
- ClickHouse — это колоночная СУБД с открытым исходным кодом, разработанная для высокопроизводительной аналитики на больших объёмах данных (OLAP).
- Главные особенности:
o Семейство MergeTree: специальный движок, который хранит данные в отсортированных сегментах с эффективным сжатием и быстрыми операциями чтения/агрегации.
o Масштабирование: можно строить кластеры со шардированием и репликацией.
o Фокус на аналитические запросы (большие сканирования, агрегации, группировки), при этом ограниченная поддержка транзакций.
o Реальное время: позволяет обрабатывать потоки данных и получать аналитические результаты практически мгновенно.
Расскажи мне про архитектуру кликхауса #Я
ClickHouse — это аналитическая СУБД, ориентированная на высокопроизводительную обработку больших объемов данных. Ее архитектура включает несколько ключевых компонентов:
1. Колонночное хранение данных
Данные хранятся по колонкам, а не по строкам, что значительно ускоряет аналитические запросы. Используется эффективное сжатие (LZ4, ZSTD) и специальные форматы хранения (Compressed Marks, Granules).
- Шардирование и репликацияПоддерживает горизонтальное масштабирование с помощью Distributed таблиц.
Репликация на основе ZooKeeper обеспечивает отказоустойчивость и балансировку нагрузки. - Механизм хранения и индексацииMergeTree — основная движковая структура с фоновым мержингом.
Primary Key (ORDER BY) — не классический индекс, а механизм сортировки данных внутри партиций.
Materialized Views — ускоряют выполнение повторяющихся запросов. - Функционал и обработка запросовИспользует vectorized execution, что дает высокую скорость обработки.
Поддерживает JOIN, но они менее эффективны по сравнению с реляционными СУБД.
Materialized Columns и Projections — позволяют улучшить производительность запросов. - Интеграции и коннекторыПоддержка Kafka, S3, HDFS, MySQL, PostgreSQL.
Инструменты для инкрементальной загрузки данных.
ClickHouse идеально подходит для аналитики, логов, BI и мониторинга, но требует продуманной схемы хранения и использования подходящих таблиц.
