Зачем в ClickHouse 25.4 добавлена отложенная материализация и как ленивые вычисления позволяют ускорить работу аналитической СУБД благодаря сокращению объемов читаемых данных и снижению количества операций дискового ввода-вывода.
Еще раз о пользе ленивых вычислений
Отложенные или ленивые вычисления (lazy evaluation), которые выполняются не сразу, а откладываются до момента, когда их результат действительно необходим, считаются довольно популярным подходом оптимизации производительности. Причем, этот подход работает не только для кода приложения, но и для баз данных. Например, эта оптимизация добавлена в релиз ClickHouse 25.4, вышедший в мае 2025 года. Lazy materialization откладывает чтение данных в столбцах до тех пор, пока они действительно не понадобятся. Это очень эффективно в реальных рабочих нагрузках, особенно для запросов, сортирующих большие наборы данных с ограничением LIMIT.
Отложенная материализация гармонично дополняет уже существующие в ClickHouse методы сокращения объема читаемых данных, такие как разреженные первичные индексы, вторичные индексы пропуска данных и проекции. Все они отсекают нерелевантные данные, определяя, какие гранулы (блоки строк) соответствуют фильтрам в индексированных столбцах. Также сократить объем сканируемых данных помогает условие PREWHERE, о котором мы писали здесь и здесь. Оно проверяет совпадения для фильтров в неиндексированных столбцах, чтобы заранее пропустить нерелевантные строки, работая независимо или уточняя гранулы, выбранные индексами.
Эти оптимизации ввода-вывода могут значительно сократить чтение данных, но они предполагают, что все столбцы для строк, соответствующих условию WHERE, должны быть загружены до выполнения таких операций, как сортировка, агрегация или ограничение вывода LIMIT. Но при этом для вычислений могут понадобиться не все столбцы. Отложенная материализация как раз позволяет сократить объем читаемых данных в этом случае. Индексирование совместно с PREWHERE гарантирует, что будут обработаны только строки тех столбцов, которые соответствуют фильтрам условия WHERE. Ленивая материализация откладывает их чтение до тех пор, пока они фактически не потребуются планом выполнения запроса. Даже после фильтрации немедленно загружаются только столбцы, необходимые для следующей операции, например сортировки. Другие откладываются и, благодаря ограничению LIMIT, считываются только частично, чего как раз достаточно для получения окончательного результата. Это возможно благодаря колоночной природе ClickHouse, которая хранит каждый столбец данных независимо. В строковых базах данных, где данные хранятся и считываются целой строкой за раз, т.е. из всех столбцов, такой сценарий отложенного ввода-вывода просто невозможен.
Как именно отложенная материализация помогает ClickHouse
Бенчмаркинговый тест, проведенный разработчиками ClickHouse 25.4, развернутой на Ubuntu Linux 24.04 на m6i.8xlarge-экземпляре AWS EC2 с 32 виртуальными ЦП, 128 ГБ ОЗУ и 1 ТБ gp3 SSD с настройками по умолчанию 3000 IOPS и максимальной пропускной способностью 125 МБ/с, показал ускорение SQL-запросов более чем в 1500 раз. В качестве тестового датасета использовалась широкая таблица из 150 миллионов строк, содержащая около 70 ГБ несжатых данных в формате Parquet и примерно 30 ГБ данных, сжатых с помощью кодека ZSTD(1). Вообще такие объемы данных не критичны для ClickHouse: эта СУБД может отсортировать все 150 миллионов значений в столбце, который не является частью ключа сортировки таблицы, и вернуть первые 3 результата всего за 70 миллисекунд. В большинстве случаев скорость выполнения работы ограничивается не только движком хранения и объемом данных, а пропускной способностью диска. Например, на сервере с медленным диском и несколькими ядрами ЦП, ClickHouse использовал несколько параллельных потоков для чтения данных, по числу ядер ЦП. При этом большая часть времени выполнения SQL-запроса потрачена на ожидание системного вызова read, который является фундаментальной операцией чтения данных с диска. Когда ClickHouse работает с медленными дисками, возникают следующие проблемы:
- блокировка потоков выполнения, т.к. вызов read является блокирующим, т.е. поток, ожидающий чтения данных с диска, простаивает и не может выполнять другую полезную работу;
- неэффективное использование даже многоядерного ЦП, ресурсы которого простаивают, когда потоки находятся в состоянии ожидания I/O операций;
- ограничение параллелизма – хотя ClickHouse запускает несколько потоков по числу ядер ЦП, все они могут одновременно оказаться в состоянии ожидания чтения данных с одного диска, создавая узкое место;
- увеличение задержки выполнения запросов из-за ожидания системных вызовов read;
- накладные расходы на переключение контекста, т.к. каждый системный вызов требует переключения из пространства пользователя в пространство ядра, добавляя дополнительные накладные расходы.
Отложенная материализация позволяет избежать этих проблем. Прежде всего, вместо полной блокировки потоков управления, потоки читают только необходимый минимум данных, проводят фильтрацию, и затем небольшое количество строк требует дополнительного чтения. Это значительно сокращает время блокировки потоков. Также отложенная материализация повышает эффективность утилизации ЦП, который теперь не простаивает, ожидая завершения больших операций чтения с диска, а может обрабатывать фильтрацию, пока читаются только нужные для фильтрации столбцы. Без отложенной материализации все потоки одновременно конкурируют за доступ к диску для чтения больших объемов данных, а с ней чтение разбивается на параллельные этапы для разных потоков. Время выполнения запроса сокращается, поскольку основной объем данных (ненужные столбцы) не читается для отфильтрованных строк. Это сокращает количество системных вызовов read, поскольку большое количество данных вообще не читается. В итоге накладных расходов на переключение контекста становится меньше.
Для использования отложенной материализации ее надо включить в параметрах SQL-запроса, добавив в настройки query_plan_optimize_lazy_materialization = true:
SETTINGS query_plan_optimize_lazy_materialization = true;
Отложенная материализация применяется автоматически для запросов с ограничением вывода LIMIT, но только до порогового значения. Это контролируется параметром query_plan_max_limit_for_lazy_materialization, по умолчанию равным 10. Если установить эту конфигурацию в значение 0, отложенная материализация будет применена ко всем значениям LIMIT без верхней границы.
Хотя наибольшее ускорение дает совмещение lazy materialization с другими способами оптимизации, например, индексация и фильтрация с помощью PREWARE, она может быть использована и сама по себе, т.к. не нуждается в фильтрах столбцов. В то время как индексация и PREWHERE полагаются на предикаты запроса для пропуска данных, отложена материализация повышает производительность исключительно за счет откладывания вычислений, загружая только то, что нужно и когда это действительно нужно.
На практике разница с включенной и отключенной отложенной материализацией становится заметнее в следующих случаях:
- много столбцов в исходной таблице;
- использовании небольшого количества столбцов в запросе;
- сложные условия фильтрации;
- большой объем исходных данных.
Таким образом, ленивая материализация в ClickHouse особенно полезна, когда столбцы имеют сложные типы данных и/или большой размер, а SQL-запросы включают вычисления с данными, которые потом могут быть отфильтрованы. Это особенно важно для аналитических запросов, которые работают с широкими таблицами, но читают только малое подмножество столбцов. Поэтому отложенная материализация в ClickHouse устраняет ограничения диска, повышая эффективность утилизации оборудования и производительность всей аналитической системы.
Освойте ClickHouse на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
Источники
