Аналитика в реальном времени должна оставаться быстрой по мере поступления новых данных. CostBench тестирует это в условиях непрерывной ингестии: запросы выполняются по мере роста набора данных. Эффективная подготовка снижает затраты на приведение данных в состояние готовности к запросам и уменьшает объем работы для самих запросов, снижая их стоимость и время выполнения.
Колоночное хранение позволяет запросам пропускать неиспользуемые поля; упорядочивание позволяет детализации пропускать несвязанные котировки; современные преагрегации позволяют интерактивным агрегациям объединять подготовленные сводки. На диаграмме ниже показано, как этот путь свежих данных определяет сканирование и агрегацию, остающиеся для запросов по мере того, как подготовка успевает за данными или отстает от них.
CostBench измеряет ① затраты на подготовку, ② затраты на запросы и ③ время выполнения, а затем объединяет их в единый комплексный показатель эффективности на доллар.
В этой статье рассматриваются эти три эффекта при сравнении ClickHouse и Databricks — от подготовки поступающих данных до обслуживания запросов.
В данном сравнении для обслуживания запросов используется Databricks Serverless SQL. Lakehouse//RT, новое хранилище Databricks для работы в реальном времени, находящееся в настоящее время в стадии бета-тестирования, не включено.
В этой рабочей нагрузке с непрерывной ингестией ClickHouse Cloud обеспечила в 752 раза лучшую комплексную производительность на доллар по сравнению с Databricks.
В этой рабочей нагрузке с непрерывной ингестией ClickHouse Cloud обеспечила в 752 раза лучшую комплексную производительность на доллар по сравнению с Databricks.
Обе системы использовали рекомендуемые пути ингестии с низкими задержками и встроенные функции подготовки: асинхронные вставки в ClickHouse; Zerobus Ingest, жидкостную кластеризацию (liquid clustering) и инкрементальные материализованные представления в Databricks. CostBench передала в потоковом режиме 113,2 миллиарда котировок фондового рынка с целевым показателем 1 миллион строк в секунду, используя соответствующие ключи сортировки или кластеризации и ежедневные преагрегации по символу акции. Во время ингестии каждые десять минут выполнялись четыре интерактивных агрегатных запроса; каждый час выполнялись два запроса с детализацией. Запросы охватывали растущую историю через исходные таблицы или поддерживаемые сводки. Вычислительные мощности на стороне чтения были сопоставимы и составляли 16 ЦП, кэширование результатов запросов было отключено.
CostBench вычисляет комплексный показатель эффективности на доллар по формуле, приведенной ниже: Оценка = (① затраты на подготовку + ② нормализованные затраты на запросы) × ③ накопленное время выполнения запросов.
Затраты на подготовку охватывают весь путь свежих данных. Нормализованные затраты на запросы оценивают зарегистрированное время выполнения запросов по применимым тарифам на вычисления на стороне чтения. Накопленное время выполнения запросов — это сумма длительностей запросов. Меньшие значения оценки лучше.
ОБЩАЯ СРЕДА ТЕСТИРОВАНИЯ
Обе системы использовали один и тот же исходный набор данных, схему, определения рабочей нагрузки, модель темпа, расписание запросов и формат результатов. Адаптеры для конкретных хранилищ обрабатывали доставку и синхронизацию. Часть 1 описывает общую методологию; соглашение о бенчмарке Databricks фиксирует реализацию для этого провайдера.
НАБОР ДАННЫХ И ПОДГОТОВКА
Полный набор данных NBBO содержит 113 219 565 734 узких 12-колоночных строк. Исходные таблицы использовали (sym, t) — символ акции и временную метку события; ежедневные сводки использовали (sym, day) — символ акции и день UTC. Сводки поддерживали счетчики, суммы, а также минимальные и максимальные цены, используемые агрегатными запросами.
НЕПРЕРЫВНАЯ РАБОЧАЯ НАГРУЗКА
Поток свежих строк приближался к 1 миллиону в секунду, в то время как агрегатные запросы и запросы с детализацией выполнялись по своему расписанию (каждые десять минут и каждый час). Это моделирует непрерывную генерацию данных и их подготовку по мере поступления, а не измерение того, насколько быстро существующий набор данных может быть загружен пакетом или дозагружен. Путь материализованных представлений Databricks сохранял свою исходную семантику снимков; совпадение прогресса ингестии не делает сводки обеих систем одинаково свежими.
РЕКОМЕНДУЕМЫЙ СТЕК И РАЗМЕРЫ
ClickHouse Cloud использовала узел чтения с 16 ЦП и 64 ГиБ памяти. Databricks использовала хранилище X-Small Serverless SQL, закрепленное за одним кластером (приблизительно 16 виртуальных ЦП воркеров); этот размер не подразумевает идентичное аппаратное обеспечение или память. Были включены жидкостная кластеризация, предиктивная оптимизация (Predictive Optimization) и триггерное обновление инкрементальных материализованных представлений. Lakehouse//RT была недоступна в тестовом рабочем пространстве, поэтому принятое сравнение использует базовые возможности Serverless SQL.
① ЗАТРАТЫ НА ПОДГОТОВКУ
Полная ингестия включает в себя полностью двух узловую службу высокодоступной ингестии ClickHouse, а также ингестию Zerobus, асинхронную кластеризацию и обновление материализованных представлений в Databricks. Ингестия и обновление в Databricks используют выделенное потребление DBU; кластеризация использует принятое распределение DBU для предиктивной оптимизации. Все три компонента отражены в модели затрат на подготовку.
② ЗАТРАТЫ НА ЗАПРОСЫ И ③ ВРЕМЯ ВЫПОЛНЕНИЯ
Зарегистрированная длительность каждого принятого запроса оценивается по тарифу вычислений на стороне чтения и добавляется к накопленному времени выполнения. В Databricks используется общая длительность из истории запросов (Query History), исключая выборку результатов; в ClickHouse используется зарегистрированная длительность выполнения. Эти нормализованные затраты представляют собой принятую работу запросов, а не полные счета хранилища данных. Примечания к сравнению запросов и ценообразованию ниже подробно описывают тайминг и границы.
ЦЕЛЕВОЙ ПОКАЗАТЕЛЬ ПРОТИВ ФАКТИЧЕСКОГО
Databricks завершила окно надежной ингестии примерно за 31,5 часа, со средней скоростью около 1 миллиона строк/с. ClickHouse завершила ингестию примерно за 36,75 часа, со средней скоростью около 0,86 миллиона строк/с. Целевой показатель был общим, но фактический прогресс различался. Итоговая сверка в Databricks подтвердила все 113 219 565 734 строки без избыточных дубликатов. Подтверждение надежности и видимость таблиц для запросов — это отдельные этапы.
ОКНО ОТЧЕТНОСТИ
Графики задержки для отдельных запросов останавливаются на отметке в 100 миллиардов строк. Затраты на подготовку охватывают всю активную ингестию; накопленные затраты на запросы и время их выполнения используют принятые наблюдения активной ингестии, заканчиваясь на общем горизонте сравнения для каждой рабочей нагрузки. Запросы и обслуживание после ингестии не входят в итоговый показатель. Отображаемые итоговые значения округлены.
ClickHouse Cloud лидировала по всем трем измеряемым компонентам:
① Затраты на подготовку: $28,69 против $695,60. ② Нормализованные затраты на запросы: около $0,05 против $2,65. ③ Накопленное время выполнения запросов: 56,39 секунды против 29,10 минуты.
Приведенные ниже графики отслеживают эти затраты и время выполнения по мере продвижения ингестии.
Приведенная ниже разбивка оценки объединяет два преимущества: в 24,3 раза меньшие комбинированные затраты на подготовку и нормализованные затраты на запросы, помноженные на в 31 раз меньшее накопленное время выполнения запросов, дают ClickHouse Cloud общее преимущество по производительности на доллар.
ОСНОВА ЦЕНООБРАЗОВАНИЯ
ClickHouse Cloud использует $0,3903 за вычислительную единицу (CU) в час. Databricks использует актуальные публичные прейскурантные тарифы для региона AWS eu-west-1, тарифный план Premium: $0,39 за DBU для выделенной ингестии и обслуживания и $0,91 за DBU для Serverless SQL. Принятая сводка сохраняет полную точность; это смоделированные прейскурантные затраты, а не реконструкция исторических счетов.
① ПОЛНЫЕ ЗАТРАТЫ НА ПОДГОТОВКУ
Это охватывает активную ингестию всех 113 219 565 734 строк, включая необходимые компоненты подготовки.
CLICKHOUSE CLOUD
2 CU × 36,75 часа × $0,3903/CU-час = $28,68705, включая оба узла высокодоступной ингестии (HA).
ИНГЕСТИЯ DATABRICKS
Выделенное использование Zerobus, 1 098,9261167 DBU × $0,39 = $428,58119. Это принятое распределение DBU используется в заголовке, а не конвертация объема байтов источника в ценовой эквивалент.
КЛАСТЕРИЗАЦИЯ DATABRICKS
Распределение Predictive Optimization составляет 151,8613011 DBU × $0,39 = $59,22591. Этот компонент использует распределение DBU на уровне операций Predictive Optimization. Это смоделированная плата за обслуживание, а не выставленная сумма.
DATABRICKS MV REFRESH
532,8145064 выделенных DBU × $0,39 = $207,79766. В совокупности прием, кластеризация и обновление составляют $695,60475 в принятой модели подготовки.
② НОРМАЛИЗОВАННЫЕ ЗАТРАТЫ НА ЗАПРОСЫ
Записанная длительность каждого принятого запроса умножается на секундную ставку вычислительных ресурсов на стороне чтения. Это моделирует принятую работу; простаивающие мощности и минимальная тарификация хранилища исключаются.
CLICKHOUSE CLOUD
8 CU × $0,3903/CU-час × (10,312 с совокупных + 46,074 с детализированных) ÷ 3600 = $0,04890.
DATABRICKS SERVERLESS SQL
Размер X-Small оценивается в 6 DBU/час × $0,91/DBU = $5,46/час. Совокупная работа: 613,164 с × $5,46/час ÷ 3600 = $0,92997.
РАБОТА ДЕТАЛИЗАЦИИ DATABRICKS
1133,002 с × $5,46/час ÷ 3600 = $1,71839. Итоговые нормализованные затраты на запросы: $2,64835.
ГРАНИЦА РАСПРЕДЕЛЕНИЯ
Прием данных и обслуживание в Databricks распределяются на активное окно производителя с 2026-09-18 17:04:53 UTC по 2026-09-20 00:33:42.627 UTC, с исключением конечной точки. Последующее обслуживание, SQL проверки/управления, хранилище базы данных, инфраструктура производителя, сетевые расходы и затраты на простаивающие / минимальные мощности хранилища исключаются. Обслуживание наблюдалось после приема, но эта последующая работа не включается в данный счет.
③ НАКОПЛЕННОЕ ВРЕМЯ ВЫПОЛНЕНИЯ ЗАПРОСОВ
ClickHouse: 10,312 с совокупных + 46,074 с детализированных = 56,386 с. Databricks: 613,164 с совокупных + 1133,002 с детализированных = 1746,166 с.
ГРАНИЦА СРАВНЕНИЯ
① охватывает полный активный прием. ② и ③ используют 189 пакетов совокупных запросов из четырех и 32 пакета детализированных запросов из двух. Их горизонты сравнения по количеству строк отличаются от графиков задержки для 100 миллиардов строк. Выравнивание по надежности не гарантирует идентичность видимых для запросов строк или свежести материализованного представления. Это полный путь смоделированной подготовки плюс нормализованные запросы, а не полный счет провайдера.
ИТОГОВЫЙ СЧЕТ
ClickHouse: ($28,68705 + $0,04890) × 56,386 = 1620,30528. Databricks: ($695,60475 + $2,64835) × 1746,166 = 1 219 265,82646. Соотношение составляет 752,491x, с округлением до 752x, при использовании входных данных высокой точности.
Весь код бенчмарка и результаты доступны в репозитории CostBench. Набор данных котировок акций требует отдельной лицензии на данные, поэтому сами данные не могут быть перераспределены.
Чтобы объяснить этот результат, мы пройдем по тому же пути, что и данные: сначала подготовка, затем обслуживание запросов.
В бенчмарке использовалась выделенная служба приема ClickHouse Cloud с двумя узлами по 2 CPU для обеспечения высокой доступности — минимальная конфигурация HA, выдержавшая целевую нагрузку при калибровке. Общий клиент отправлял строки посредством асинхронных вставок, встроенных в каждый узел.
На диаграмме ниже показано, как те же узлы обрабатывают ① колонночное хранение, ② упорядочивание сырых данных и ③ упорядоченную предварительную агрегацию, а также фоновые слияния в общей сложности на четырех ядрах CPU.
① Хранение в столбцах и ② упорядочивание данных: когда узел приема сбрасывает свой буфер асинхронной вставки, он сортирует сырые котировки по ключу таблицы MergeTree (sym, t) — символу акции и временной метке события — и записывает упорядоченную часть данных.
③ Упорядочивание и предварительная агрегация данных: тот же узел выполняет инкрементальный запрос материализованного представления по входящему блоку в памяти, вычисляет агрегированные состояния и сортирует результаты по ключу таблицы AggregatingMergeTree (sym, day) перед записью упорядоченной части, содержащей сводные данные.
Фоновые слияния консолидируют части в обеих таблицах.
Результат: сырые данные и предварительные агрегации продвигаются вместе из одного и того же сброшенного блока вставки без отдельного цикла обновления.
Результат: сырые данные и предварительные агрегации продвигаются вместе из одного и того же сброшенного блока вставки без отдельного цикла обновления.
Результаты использования писателя ClickHouse показывают, что прием продолжается параллельно с фоновым обслуживанием. Использование CPU оставалось на уровне около 3,1 из 4 доступных ядер, отслеживаемая память оставалась в пределах емкости, фоновые слияния обрабатывали несколько миллионов строк в секунду, а максимальное количество активных частей на партицию оставалось на уровне около 100. Эти диагностические данные описывают тестовый запуск ClickHouse, используемый повторно для данного сравнения.
Оба узла были сохранены для обеспечения высокой доступности, поэтому затраты на подготовку включают развертывание на двух узлах целиком.
Теперь пройдем те же три задачи подготовки в Databricks, где прием, кластеризация и обновление материализованного представления используют разные службы.
В бенчмарке использовался Zerobus Ingest, управляемый инструмент Databricks для прямой отправки строк в таблицы Delta через потоки Arrow Flight.
Как показано ниже, Zerobus обрабатывает ① колонночное хранение; асинхронная бессерверная кластеризация обрабатывает ② упорядочивание сырых данных; отдельный бессерверный конвейер материализованного представления обрабатывает ③ предварительную агрегацию.
① Хранение в столбцах: Zerobus буферизует входящие строки и публикует их в управляемой таблице Delta, поддерживаемой колонночными файлами Parquet. Подтверждение надежности подтверждает, что Zerobus надежно принял данные; оно не гарантирует их немедленную видимость в таблице.
② Упорядочивание данных: в сырой таблице использовалась жидкая кластеризация по (sym, t), соответствующая ключу сортировки ClickHouse. Predictive Optimization выполняла кластеризацию асинхронно на бессерверных вычислениях, поэтому новые опубликованные файлы можно было запрашивать до завершения этой работы по макетированию.
③ Упорядочивание и предварительная агрегация данных: отдельный бессерверный конвейер инкрементально обновлял ежедневные сводные данные, сгруппированные по (sym, day). В протестированном определении использовались параметры REFRESH POLICY INCREMENTAL STRICT и TRIGGER ON UPDATE AT MOST EVERY INTERVAL 1 MINUTE. Триггер использует платформы Databricks; он ограничивает запуски обновления, а не время завершения.
ТА ЖЕ ПРОБЛЕМА ПРИЕМА
Приложения генерируют частые записи, которые должны преобразовываться в эффективные записи в хранилище. Оба пункта назначения использовали прямой прием данных из приложения в таблицу с управляемой буферизацией. Никаких брокеров Kafka, промежуточных этапов выгрузки файлов или заданий Auto Loader в измеренный путь добавлено не было.
УПРАВЛЯЕМЫЙ ПУТЬ DATABRICKS
Принятый исполнитель использовал интерфейс Zerobus Arrow Flight DoPut с 16 параллельными потоками и клиентскими пакетами по 50 000 строк. Потоки ротировались каждые десять минут; были включены восстановление с помощью SDK и ограниченные повторные попытки. Вычислительные ресурсы приема Zerobus выделялись и оценивались отдельно от кластеризации, обновления материализованного представления и обслуживания SQL.
СОБСТВЕННЫЙ ПУТЬ CLICKHOUSE
Обычные запросы INSERT с включенным параметром async_insert буферизовались на каждом принимающем узле. Тайм-аут адаптивного сброса реагировал на входящий трафик. Упорядочивание и предварительная агрегация выполнялись на узлах приема; выделенная служба приема разделяла хранилище с независимо масштабируемой службой чтения.
ОБЩИЕ ТЕМПЫ
Оба адаптера читали один и тот же набор данных Parquet и декодировали одну и ту же схему в рамках одной и той же модели целевой скорости. Параллелизм и размеры клиентских пакетов адаптировались под API каждого пункта назначения; они не принуждались к идентичности.
ПАКЕТЫ CLICKHOUSE
Клиент отправлял пакеты по 3000 строк посредством асинхронных вставок. Буферизация по умолчанию срабатывала при достижении первого из трех пороговых значений: 100 МиБ в буфере, адаптивный тайм-аут в диапазоне от 50 миллисекунд до 1 секунды либо 450 запросов вставки в очереди.
ПАКЕТЫ DATABRICKS
Каждый поток Arrow Flight отправлял пакеты по 50 000 строк с отключенным сжатием IPC. Целевая интенсивность рассчитывалась на основе логических исходных строк, а подтвержденный надежный прогресс фиксировался отдельно от видимости таблиц. Эти пакеты не сохранялись во временные файлы для последующей массовой загрузки.
ГРАНИЦА РАЗМЕРА ПАКЕТА
Указаны размеры пакетов доставки на стороне клиента. Обе системы буферизуют доставку при записи в хранилище, поэтому 3000 и 50000 строк не определяют окончательные размеры партов или файлов Parquet.
ПОВТОРНЫЕ ПОПЫТКИ И СВЕРКА
Zerobus использовал надежные смещения потоков и восстановление через SDK. Проверка подтверждения гарантировала точную сверку строк и отсутствие дублирующегося избытка. ClickHouse поддерживает дедупликацию вставок для повторных попыток, включая зависимые материализованные представления. Финальная проверка строк подтверждает факт доставки, а не равенство свежести сводных данных в процессе приема.
ИНКРЕМЕНТНОЕ ОБСЛУЖИВАНИЕ
Исходная таблица Delta поддерживала отслеживание строк, ленту изменений данных и векторы удаления. МВ прошла проверки на инкрементную пригодность и использовала INCREMENTAL STRICT. В данных омоложения зафиксировано 1 028 инкрементных групповых агрегатных обновлений и ноль полных обновлений за весь собранный прогон, включая период наблюдения после приема данных.
ЧТО ИССЛЕДОВАЛОСЬ
Службой обслуживания выступал Serverless SQL X-Small. Решение Lakehouse//RT было недоступно в рабочем пространстве и не тестировалось. В этой статье описывается принятая конфигурация и ее результаты, а не прогнозируется производительность недоступного продукта.
Результат: Databricks может предоставлять доступ к сырым данным до завершения кластеризации, в то время как ее предварительные агрегаты обрабатываются в отдельном цикле обновления.
Результат: Databricks может предоставлять доступ к сырым данным до завершения кластеризации, в то время как ее предварительные агрегаты обрабатываются в отдельном цикле обновления.
ClickHouse обновляет сводные данные в процессе вставки; Databricks обновляет их асинхронно. Наведенная ниже диаграмма отражает цикл обновления Databricks: в среднем зафиксированные завершенные обновления разделял интервал примерно в 1,8 минуты, достигая около 2,0 минут на построенном тренде.
Здесь представлены интервалы между зафиксированными завершениями обновлений, а не точное измерение того, насколько каждая сводка отстает от исходной таблицы. Между обновлениями запросы к МВ Databricks могут возвращать более старые сводные данные.
СЕРИЯ DATABRICKS
История свежести опрашивалась раз в минуту. Отображаемой метрикой является время между отдельными зафиксированными идентификаторами завершенных обновлений: floor(текущее completed_at — предыдущее зафиксированное completed_at) в секундах. Выбранные данные активного приема содержат 1 021 такой интервал; сокращенный опрос может пропускать промежуточные завершения.
СГЛАЖИВАНИЕ И ПОКАЗАНИЯ
Скользящее среднее по 61 наблюдению с центрированием составляет около 1,8 минуты в рамках интервальных наблюдений. Дополнительное отображаемое среднее по 11 наблюдениям и интерполяция с сохранением формы дают построенный пик на уровне около 2,0 минут. Показания соответствуют этой отображаемой кривой. Это прокси-интервал обновления, а не напрямую опрашиваемый лаг водяного знака от сырых данных до МВ или количество устаревших строк на один запрос.
БАЗОВАЯ ЛИНИЯ CLICKHOUSE
Нулевая линия представляет собой эталонную смысловую базу, а не отдельно опрашиваемую метрику поставщика. Исходная таблица и инкрементная МВ используют один и тот же сброшенный блок вставки без независимого интервала обновления сводных данных между ними. Это не означает нулевую задержку приема от источника до запроса.
ClickHouse поддерживал актуальность сводных данных в процессе приема; зафиксированные обновления Databricks происходили примерно каждые 1,8 минуты, из-за чего запросы могли считывать более старые сводки.
ClickHouse поддерживал актуальность сводных данных в процессе приема; зафиксированные обновления Databricks происходили примерно каждые 1,8 минуты, из-за чего запросы могли считывать более старые сводки.
Эта разница в свежести данных переносится на запросы. Во-первых, следующая диаграмма учитывает затраты на каждый путь подготовки.
ClickHouse обрабатывает ① колонковое хранение, ② упорядочивание сырых данных и ③ упорядоченную предварительную агрегацию прямо внутри своего движка. Databricks распределяет эту работу между приемом, бессерверной кластеризацией и обновлением МВ. На диаграмме ниже сравниваются их совокупные затраты на подготовку.
Полная стоимость службы приема ClickHouse составила 28,69 долл. США. Смоделированные затраты Databricks на подготовку составили в сумме 695,60 долл. США: 428,58 долл. США за прием Zerobus (①), 59,23 долл. США за асинхронную кластеризацию (②) и 207,80 долл. США за обновление МВ (③). Прием и обновление используют выделенное потребление DBU; границы указаны в свернутом примечании о ценообразовании.
ClickHouse выполнил колонковое хранение, упорядочивание и предварительную агрегацию с затратами на подготовку в 24,2 раза ниже в данном прогоне.
ClickHouse выполнил колонковое хранение, упорядочивание и предварительную агрегацию с затратами на подготовку в 24,2 раза ниже в данном прогоне.
Теперь проследим путь сырых данных и сводок до обслуживания запросов.
Упорядоченные сырые данные позволяют детализации пропускать несвязанные строки; предварительные агрегаты позволяют интерактивным агрегациям объединять подготовленные результаты вместо их пересчета по отдельным котировкам. На диаграмме ниже показаны оба пути через службу чтения ClickHouse Cloud: один узел с 16 ЦП и 64 ГиБ памяти, что соответствует количеству ЦП рабочих узлов X-Small в Databricks.
Детализация: запросы отсекают несвязанные упорядоченные сырые данные в таблице MergeTree на уровне событий. Фильтрация по символу (символ — ведущая колонка ключа сортировки (sym, t)) позволяет службе чтения пропускать несвязанные котировки.
Интерактивные агрегации: запросы считывают актуальные предварительные агрегаты из таблицы AggregatingMergeTree, объединяя подготовленные количества, суммы, минимумы и максимумы из гораздо меньшего набора ежедневных сводных строк. Здесь нет независимого обновления, которого нужно ждать.
Результат: детализация отсекает упорядоченные сырые данные; интерактивные агрегации считывают сводки, поддерживаемые в актуальном состоянии во время приема.
Результат: детализация отсекает упорядоченные сырые данные; интерактивные агрегации считывают сводки, поддерживаемые в актуальном состоянии во время приема.
Databricks использует те же два пути запросов, но асинхронная подготовка изменяет то, что могут считывать запросы.
На диаграмме ниже показано бессерверное хранилище SQL размера X-Small, обслуживающее обе рабочие нагрузки, зафиксированное на одном кластере с 16 worker vCPUs.
Решение Lakehouse//RT в настоящее время находится на стадии бета-тестирования. Мы запросили доступ, но еще не получили его.
Как только Lakehouse//RT станет общедоступным и мы получим к нему доступ, мы планируем повторить весь рабочий процесс CostBench, используя Lakehouse//RT для обслуживания запросов, и опубликовать результаты.
Детализация: запросы напрямую считывают таблицу Delta и выполняют фильтрацию по символу. Жидкая кластеризация по (sym, t) помогает пропускать несвязанные файлы после выполнения кластеризации, однако вновь опубликованные файлы могут оставаться некластеризованными до тех пор, пока не завершится асинхронное обслуживание.
Интерактивные агрегации: запросы считывают ежедневные сводки из инкрементной МВ. Они видят последний снимок завершенного обновления; новые сырые строки не объединяются с ним автоматически во время выполнения запроса. Таким образом, ответ может не содержать данные, которые уже поступили в исходную таблицу.
Разница между двумя путями: детализированные запросы (drill-downs) могут сканировать данные, кластеризация которых еще не завершена; интерактивные агрегации могут читать сводные данные, обновление которых еще не завершено. И то, и другое обеспечивается подготовкой, которая выполняется независимо от приема данных.
КОНТРАКТ SNAPSHOT
A обновляет материализованное представление (MV) из исходной таблицы. Измеренные запросы агрегации читают этот материализованный результат напрямую. Они не принудительно вызывают синхронное обновление перед каждым запросом и не объединяют дельту исходной таблицы в конечный ответ. Таким образом, измеренная задержка учитывает заложенное в Databricks допустимое отставание устаревших сводных данных.
КОНТРАКТ TRIGGER
TRIGGER ON UPDATE планирует обновления при изменении исходных данных. Условие AT MOST EVERY INTERVAL 1 MINUTE задает минимальный интервал между срабатываниями триггеров, а не одноминутный максимум для возраста данных или завершения обновления.
КОНТРАКТ INCREMENTAL
INCREMENTAL STRICT управляет методом обслуживания: подходящие под критерии изменения обрабатываются инкрементально, а не незаметно переключаются на полный пересчет. Этот параметр не связывает видимость материализованного представления с каждым принятым блоком данных и не делает материализованное представление непрерывно актуальным.
КОНТРАКТ VISIBILITY
Записи raw_rows средства выполнения фиксируют подтвержденный прогресс надежного приема данных. Zerobus может надежно принимать строки до того, как они будут опубликованы в таблице Delta. Следовательно, пара запросов, сопоставленная по прогрессу надежного приема данных, не доказывает, что оба запроса увидели ровно одинаковое количество исходных строк или одинаково свежий снимок сводных данных.
ГРАНИЦА СРАВНЕНИЯ
Главный показатель сохраняет проверенный путь обслуживания материализованных представлений, включая особенности поведения свежести данных. Проектирование, которое принудительно вызывало бы обновление либо выполняло запрос и повторную агрегацию исходной таблицы, имело бы другой профиль задержки и стоимости; эта работа не включена в данный результат.
Результат: детализированные запросы Databricks могут сканировать только что поступившие некластеризованные данные; интерактивные агрегации могут читать сводные данные из предыдущего обновления.
Результат: детализированные запросы Databricks могут сканировать только что поступившие некластеризованные данные; интерактивные агрегации могут читать сводные данные из предыдущего обновления.
В обеих системах использовались ключи (sym, t), однако ClickHouse упорядочивал строки во время вставки, в то время как Databricks выполняла кластеризацию файлов асинхронно. Запросы D1 и D2 напрямую обращаются к растущей истории акций: часовым сводкам цен и профилю риска и ликвидности. Диаграмма ниже демонстрирует этот путь работы с сырыми данными, минуя материализованные представления.
ClickHouse Cloud — желтым; Databricks — красным.
ОПРЕДЕЛЕНИЯ ЗАПРОСОВ
В Части 1 описываются A1–A4 и D1–D2. В обеих системах использовались одинаковая аналитическая рабочая нагрузка и расписание, причем SQL был адаптирован под каждый движок. Точно сравнивались количества, суммы и экстремумы; часть D2 с приближенными процентилями использовала явный допуск контракта. Свежесть материализованных представлений не предполагалась идентичной.
ПОЛИТИКА КЭШИРОВАНИЯ
Кэширование результатов запросов было отключено. В отчетах о выполнении запросов Databricks отсутствовали попадания в кэш результатов для принятых запросов. Кэшам базовых данных разрешалось прогреваться в обычном режиме; бензочмарк не выполнял их очистку между запросами.
ВРЕМЯ ВЫПОЛНЕНИЯ
Задержка Databricks использует значение Query History total_duration_ms ÷ 1,000, исключая время получения результатов. ClickHouse использует зафиксированную длительность запроса. Эти соглашения об измерении времени сохраняются в нормализованной стоимости запросов. Медиана, P99 и максимальная статистика объединяют несглаженные наблюдения по каждому запросу на объеме до 100 миллиардов строк; для P99 используется линейная интерполяция.
ГРАФИКИ ЗАДЕРЖЕК
ИНТЕРАКТИВНЫЕ ВЫВОДЫ
ПРИНЯТАЯ НАКОПЛЕННАЯ РАБОЧАЯ НАГРУЗКА
НАКОПЛЕННЫЕ ГРАФИКИ
ClickHouse Cloud:
- медиана 722.5 мс — в 22.1 раза быстрее, чем Databricks
- P99 1.15 с — в 42.7 раза быстрее
- максимум 1.18 с — в 48.2 раза быстрее
Databricks:
