Как избежать потери данных при асинхронной вставке в Clickhouse при сбое сервера и зачем в версию 24.2 добавлен адаптивный тайм-аут очистки буфера: тонкости ETL с колоночной СУБД.
Асинхронная вставка с возвратом подтверждения
Недавно мы рассказали, чем хороши асинхронные вставки в ClickHouse и отметили, что при их использовании можно настроить параметр возврата подтверждения wait_for_async_insert. Напомним, в отличие от синхронной вставки, при асинхронной данные сперва вставляются в буфер, а затем записываются в хранилище базы данных позже. Это переносит пакетирование данных со стороны клиента на сторону сервера, т.е. самого ClickHouse, который оптимизирован для пакетных вставок большими порциями данных.
Параметр wait_for_async_insert определяет, нужно ли возвращать подтверждение после вставки данных в буфер, или делать это по умолчанию после записи части данных после очистки буфера. Рекомендуется установить wait_for_async_insert=1, т.к. значение 0 имеет риск перегрузки ClickHouse при интенсивной записи. Это происходит, когда клиентское приложение, публикующее данных в ClickHouse, делает это с высокой производительностью и не получает ответа об ошибках сервера.
При wait_for_async_insert = 1, когда ClickHouse получает запрос на вставку, данные запроса немедленно записываются в буфер в памяти. Когда происходит следующая очистка буфера, данные буфера сортируются и записываются как одна или несколько частей данных в хранилище базы данных. Перед очисткой буфера данные из других запросов на вставку могут быть собраны в буфере. Только после того, как произойдет следующая регулярная очистка буфера, клиент-отправителю данных возвращается ответ с подтверждением вставки. Это означает, что вызов на стороне клиента, который отправляет запрос на вставку, блокируется до момента, пока не произойдет следующая очистка буфера. Поэтому вставки из разных многопоточных параллельных потоков или программ возможны, а из одного потока или приложения — нет.
Главным преимуществом такого режима является гарантия долговечности и простой способ выявления бракованных пакетов:
- когда клиент получает подтверждение на вставку, данные гарантированно записываются в хранилище базы данных и становятся доступными для поиска по запросам;
- если во время очистки буфера возникают ошибки вставки, отправитель запроса получает подробное сообщение об ошибке вместо подтверждения, т.к. ClickHouse ждет, чтобы вернуть подтверждение вставки, пока буфер не очищен;
- благодаря оперативному возврату ошибок, легко определить и, при необходимости повторить, вставку данных.
Недостаток режима wait_for_async_insert = 1 – риск возникновения обратного давления, где используется один клиент с однопоточной вставкой данных. Впрочем, в ClickHouse 24.2 и выше этот недостаток устранен с помощью адаптивных асинхронных вставок, о которых мы поговорим далее. Кроме того, повысить пропускную способность приема можно за счет соответствующей пакетной обработки данных на стороне клиента и использования многопоточных параллельных циклов вставки.
Поскольку параметры async_insert_max_data_size и async_insert_max_query_number могут вызвать очистку буфера раньше, чем нужно, особенно при большом количестве данных и клиентов, им рекомендуется задать высокое значение. Это позволит гарантировать, что только настройка времени запускает очистку буфера, поскольку надо временно буферизировать больше данных.
Асинхронная вставка без возврата подтверждения
При wait_for_async_insert = 0 для асинхронных вставок, когда ClickHouse получает запрос на вставку, данные запроса немедленно записываются в буфер памяти. После этого запрос на вставку возвращается отправителю с подтверждением вставки. Когда происходит следующая регулярная очистка буфера, данные буфера сортируются и записываются как одна или несколько частей данных в хранилище базы данных. Перед очисткой буфера данные из других запросов на вставку могут быть собраны в буфере.
Преимущество этого режима в том, что для клиентов с одним потоков вставки достигается очень высокая пропускная способность приема при минимальном использовании ресурсов кластера. Однако, установка wait_for_async_insert = 0 имеет следующие недостатки:
- отсутствие гарантий долговечности – даже когда клиент получает подтверждение выполненного запроса на вставку, это не обязательно означает, что данные запроса записаны в хранилище базы данных. Ошибка вставки может возникнуть позже во время очистки буфера. Например, работа узла ClickHouse была завершена с помощью команды SYSTEM, которая очищает все асинхронные буферы вставки. Потеря данных может произойти, когда узел ClickHouse выйдет из строя или отключится до того, как произойдет следующая регулярная очистка буферов памяти. А, поскольку клиенты получили подтверждения об успешной записи данных, обнаружить такие потери довольно сложно.
- ошибки вставки не возвращаются- когда во время очистки буфера возникают ошибки, клиенту-отправителю данных все равно уходит успешное подтверждение. Обнаружить эти ошибки можно, только специально проверив файлы журналов и системные таблицы.
Таким образом, выявление некорректных наборов данных тоже становится сложнее. Поэтому задавать wait_for_async_insert = 0 рекомендуется только в сценариях, где допустима потеря данных.
Адаптивные асинхронные вставки
По умолчанию, при возврате подтверждения, т.е. когда wait_for_async_insert=1, вызов на стороне клиента, отправляющий запрос на вставку, блокируется до тех пор, пока не произойдет следующая очистка буфера. Поэтому нечастые вставки имеют более высокую задержку. Чтобы исправить это, в релизе ClickHouse 24.2 был добавлен адаптивный тайм-аут очистки буфера асинхронной вставки. Он использует адаптивный алгоритм для автоматической настройки тайм-аута очистки буфера на основе частоты вставок. Счетчик тайм-аута очистки буфера теперь начинается с минимального значения, поэтому данные из этих запросов записываются на диск гораздо раньше. Это позволяет почти сразу записывать небольшие объемы данных на диск, снижая риск возникновения ошибки Too many parts. Вставки с высокой частой работают по-прежнему: буферизируются и объединяются.
Когда ClickHouse получает запрос на вставку после периода отсутствия активности вставки в таблицу, счетчик времени ожидания очистки буфера начинается с минимального значения, которое автоматически корректируется до максимального значения, когда дополнительные вставки происходят часто. Аналогичная коррекция происходит и в обратную сторону, когда частота вставок уменьшается.
Освойте ClickHouse на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
Источники
