Введение

В современном мире объемы данных растут экспоненциально, и хранение петабайтов информации в объектных хранилищах (как Amazon S3 или Cloudflare R2) стало стандартом. Однако просто хранить данные мало — их нужно анализировать. Традиционно для этого требовалось поднимать сложные кластеры (например, Spark или Trino), что долго и дорого.

Компания Cloudflare представила R2 SQL — бессерверный (serverless) движок, который позволяет выполнять SQL-запросы прямо к данным, лежащим в объектном хранилище R2, без необходимости управлять инфраструктурой. Эта статья подробно описывает архитектуру этого решения: как они добились высокой скорости, используя формат таблиц Apache Iceberg, умное планирование запросов и свою глобальную сеть.

Ссылка на оригинал статьи А ранее я уже писал про их анонс тут https://gavrilov.info/all/cloudflare-anonsiruet-platformu-dannyh/

---

R2 SQL: Глубокое погружение в наш новый движок для распределенных запросов

Авторы: Yevgen Safronov, Nikita Lapkov, Jérôme Schneider. ( Привет Никита и Евген :)

Как выполнить SQL-запросы над петабайтами данных… без сервера?
У нас есть ответ: R2 SQL, бессерверный движок запросов, который может просеивать огромные наборы данных и возвращать результаты за секунды.

В этом посте подробно описывается архитектура и методы, которые делают это возможным. Мы пройдемся по нашему Планировщику запросов (Query Planner), который использует `R2 Data Catalog` для отсечения терабайтов данных еще до чтения первого байта, и объясним, как мы распределяем работу по глобальной сети Cloudflare, используя `Workers` и `R2` для массивного параллельного выполнения.

От каталога к запросу

Во время Developer Week 2025 мы запустили `R2 Data Catalog` — управляемый каталог `Apache Iceberg`, встроенный непосредственно в ваш бакет Cloudflare R2. Iceberg — это открытый формат таблиц, который предоставляет критически важные функции баз данных (такие как транзакции и эволюция схемы) для объектного хранилища петабайтного масштаба. Он дает вам надежный каталог ваших данных, но сам по себе не предоставляет способа их запрашивать.

До сих пор чтение вашего каталога `R2 Data Catalog` требовало настройки отдельного сервиса, такого как `Apache Spark` или Trino. Эксплуатация этих движков в большом масштабе непроста: вам нужно создавать кластеры, управлять использованием ресурсов и отвечать за их доступность — ничто из этого не способствует главной цели: получению ценности из ваших данных.

`R2 SQL` полностью устраняет этот этап. Это бессерверный движок запросов, который выполняет SQL-запросы на чтение (retrieval) к вашим таблицам Iceberg прямо там, где живут ваши данные.

поясненИИе: Что такое Apache Iceberg?

Представьте, что у вас есть огромная куча файлов (CSV, Parquet, JSON) в облачном хранилище. Это “озеро данных”. Проблема в том, что если вы начнете менять один файл, пока кто-то другой его читает, все сломается. Трудно понять, какая версия данных актуальна.

Apache Iceberg — это слой управления поверх этих файлов. Он работает как библиотекарь: он не хранит сами книги (данные), но ведет идеальный учет (метаданные). Он точно знает: “Таблица ‘Пользователи’ сейчас состоит из вот этих 100 файлов”.
Это позволяет делать с обычными файлами в облаке то, что раньше умели только дорогие базы данных:

1. ACID-транзакции: Гарантия того, что данные не запишутся “наполовину”.
2. Time Travel: Возможность сделать запрос “Как выглядела таблица вчера в 14:00?”.
3. Ecosystem: Единый стандарт, который понимают разные инструменты аналитики.

Проектирование движка запросов для петабайтов

Объектное хранилище фундаментально отличается от хранилища традиционной базы данных. База данных структурирована по своей природе; `R2 `— это океан объектов, где одна логическая таблица может состоять из миллионов отдельных файлов, больших и маленьких, и новые поступают каждую секунду.

Apache Iceberg предоставляет мощный слой логической организации поверх этой реальности. Он работает, управляя состоянием таблицы как неизменяемой серией мгновенных снимков (snapshots), создавая надежное, структурированное представление таблицы путем манипулирования “легкими” файлами метаданных вместо перезаписи самих файлов данных.

Однако эта логическая структура не меняет физической проблемы, лежащей в основе: эффективный движок запросов всё равно должен найти конкретные данные, необходимые ему, в этой огромной коллекции файлов. Это требует преодоления двух основных технических барьеров:

1. Проблема ввода-вывода (I/O problem): Главная проблема эффективности запросов — минимизация объема данных, считываемых из хранилища. Подход “в лоб” с чтением каждого объекта просто нежизнеспособен. Основная цель — читать только те данные, которые абсолютно необходимы.
2. Проблема вычислений (Compute problem): Объем данных, которые *действительно* нужно прочитать, все равно может быть огромным. Нам нужен способ выделить запросу, который может быть массивным, необходимое количество вычислительной мощности всего на несколько секунд, а затем мгновенно снизить его до нуля, чтобы избежать лишних трат.

Наша архитектура для `R2 SQL` разработана для решения этих двух проблем с помощью двухэтапного подхода: Планировщик запросов (Query Planner), который использует метаданные для интеллектуального отсечения (pruning) пространства поиска, и система Выполнения запросов (Query Execution), которая распределяет работу по глобальной сети Cloudflare для параллельной обработки данных.

Планировщик запросов (Query Planner)

Самый эффективный способ обработки данных — не читать их вовсе. Это ключевая стратегия планировщика `R2 SQL`. Вместо исчерпывающего сканирования каждого файла планировщик использует структуру метаданных, предоставляемую каталогом `R2 Data Catalog`, чтобы “подрезать” пространство поиска, то есть избежать чтения огромных массивов данных, не относящихся к запросу.

Это расследование “сверху вниз”, где планировщик перемещается по иерархии слоев метаданных Iceberg, используя статистику (stats) на каждом уровне для построения быстрого плана, точно указывающего, какие диапазоны байтов должен прочитать движок.

Что мы подразумеваем под “статистикой”?

Когда мы говорим, что планировщик использует “статы”, мы имеем в виду сводные метаданные, которые Iceberg хранит о содержимом файлов данных. Эта статистика создает грубую карту данных, позволяя планировщику принимать решения о том, какие файлы читать, а какие игнорировать, даже не открывая их.

Есть два основных уровня статистики, которые планировщик использует для отсечения (pruning):

1. Статистика уровня раздела (Partition-level stats): Хранится в списке манифестов (manifest list) Iceberg. Эти статы описывают диапазон значений разделов для всех данных в определенном файле манифеста Iceberg. Для раздела по `day(event_timestamp)` это будут самый ранний и самый поздний дни, присутствующие в файлах, отслеживаемых этим манифестом.
2. Статистика уровня столбца (Column-level stats): Хранится в файлах манифестов. Это более детальная статистика о каждом отдельном файле данных. Файлы данных в `R2 Data Catalog` отформатированы с использованием `Apache Parquet`. Для каждого столбца файла Parquet манифест хранит ключевую информацию, такую как:
   • Минимальное и максимальное значения. Если запрос запрашивает `http_status = 500`, а статистика файла показывает, что в столбце `http_status` минимум 200 и максимум 404, этот файл можно пропустить целиком.
   • Количество null-значений. Это позволяет планировщику пропускать файлы, когда запрос ищет конкретно non-null значения (например, `WHERE error_code IS NOT NULL`), а метаданные файла сообщают, что все значения для `error_code` являются null.

Отсечение пространства поиска (Pruning)

Процесс отсечения — это расследование “сверху вниз”, которое происходит в три основных этапа:

1. Метаданные таблицы и текущий снимок (snapshot):
   Планировщик начинает с запроса к каталогу о местоположении текущих метаданных таблицы. Это JSON-файл, содержащий текущую схему таблицы, спецификации разделов и журнал всех исторических снимков. Затем планировщик выбирает последний снимок для работы.

2. Список манифестов и отсечение разделов:
   Текущий снимок указывает на единый *список манифестов* (manifest list) Iceberg. Планировщик читает этот файл и использует статистику уровня разделов для каждой записи, чтобы выполнить первый, самый мощный шаг отсечения, отбрасывая любые манифесты, чьи диапазоны значений разделов не удовлетворяют запросу. Например, для таблицы, партиционированной по дням, планировщик может отбросить манифесты за ненужные даты.

3. Манифесты и отсечение на уровне файлов:
   Для оставшихся манифестов планировщик читает каждый из них, чтобы получить список фактических файлов данных Parquet. Эти файлы манифестов содержат более детальную статистику уровня столбцов. Это позволяет выполнить второй шаг отсечения, отбрасывая целые файлы данных, которые не могут содержать строки, соответствующие фильтрам запроса.

4. Отсечение групп строк (Row-group pruning) внутри файла:
   Наконец, для конкретных файлов данных, которые всё еще являются кандидатами, Планировщик использует статистику, хранящуюся внутри *футеров* (footers) файлов Parquet, чтобы пропускать целые группы строк (row groups).

Результатом этого многослойного отсечения является точный список файлов Parquet и групп строк внутри этих файлов. Они становятся рабочими единицами (work units), которые отправляются в систему Выполнения запросов.

поясненИИе: Формат Parquet и Row Groups

Apache Parquet — это колоночный формат хранения данных. В отличие от CSV, где данные хранятся строка за строкой, в Parquet данные хранятся столбец за столбцом. Это идеально для аналитики (когда вам нужно посчитать среднее по одной колонке, не читая остальные 50).

Внутри себя файл Parquet делится на Row Groups (группы строк). Представьте файл на 1 миллион строк. Он может быть разбит на 10 групп по 100,000 строк. У каждой группы есть свой мини-заголовок со статистикой (min/max значения).

Пример: Вы ищете `id = 950,000`.
Движок читает футер файла и видит:

• Row Group 1: id 1-100,000 -> Пропускаем.
• ...
• Row Group 10: id 900,001-1,000,000 -> Читаем только эту часть файла.

Это называется “I/O skipping” и экономит огромное количество времени и денег на трафике.

Конвейер планирования (The Planning pipeline)

В `R2 SQL` описанное выше многослойное отсечение не является монолитным процессом. Для таблицы с миллионами файлов метаданные могут быть слишком большими, чтобы обработать их полностью до начала реальной работы. Ожидание полного плана внесет значительную задержку (latency).

Вместо этого `R2 SQL` рассматривает планирование и выполнение как единый конкурентный конвейер (pipeline). Работа планировщика — производить поток рабочих единиц (work units), которые исполнитель (executor) потребляет, как только они становятся доступны.

Начало выполнения как можно раньше

С этого момента запрос обрабатывается в потоковом режиме. По мере того как Планировщик читает файлы манифестов (и, следовательно, файлы данных, на которые они указывают) и отсекает их, он немедленно отправляет любые подходящие файлы данных/группы строк как рабочие единицы в очередь выполнения.

Такая конвейерная структура гарантирует, что вычислительные узлы могут начать дорогую работу по вводу-выводу данных практически мгновенно, задолго до того, как планировщик закончит свое полное расследование.

На вершине этой модели конвейера планировщик добавляет критически важную оптимизацию: преднамеренное упорядочивание (deliberate ordering). Файлы манифестов не стримятся в случайной последовательности. Вместо этого планировщик обрабатывает их в порядке, соответствующем условию `ORDER BY` вашего запроса, руководствуясь статистикой метаданных. Это гарантирует, что данные, которые с наибольшей вероятностью содержат желаемые результаты, обрабатываются первыми.

Ранняя остановка: как закончить, не читая всё

Благодаря тому, что Планировщик передает рабочие единицы в порядке, соответствующем `ORDER BY`, система выполнения сначала обрабатывает данные, которые с наибольшей вероятностью попадут в итоговый набор результатов.

Например, для запроса типа `... ORDER BY timestamp DESC LIMIT 5`: по мере того как движок выполнения обрабатывает рабочие единицы и отправляет результаты обратно, планировщик одновременно делает две вещи:

1. Поддерживает ограниченную “кучу” (heap) из лучших 5 результатов, увиденных на данный момент.
2. Следит за “ватерлинией” (high-water mark) самого потока. Благодаря метаданным он всегда знает абсолютно самый поздний `timestamp` любого файла данных, который *еще не был* обработан.

В момент, когда самая старая временная метка в нашей “Топ-5 куче” оказывается новее, чем “ватерлиния” оставшегося потока (максимально возможная дата в еще не прочитанных файлах), весь запрос может быть остановлен.

В этот момент мы можем доказать, что ни одна оставшаяся рабочая единица не может содержать результат, который попал бы в топ-5. Конвейер останавливается, и пользователю возвращается полный, корректный результат, часто после чтения лишь крошечной доли потенциально подходящих данных.

---

Выполнение запросов (Query Execution)

Планировщик передает работу кусочками, называемыми Row Groups. Сервер, который получает запрос пользователя, берет на себя роль координатора запроса. Он распределяет работу между воркерами (query workers) и агрегирует результаты.

Сеть Cloudflare огромна. Координатор связывается с внутренним API Cloudflare, чтобы убедиться, что для выполнения выбираются только здоровые серверы. Соединения между координатором и воркерами проходят через `Cloudflare Argo Smart Routing` для обеспечения быстрой и надежной связи.

Серверы, получающие задачи от координатора, становятся воркерами. Они служат точкой горизонтального масштабирования в `R2 SQL`. При большем количестве воркеров `R2 SQL` может обрабатывать запросы быстрее, распределяя работу между множеством серверов. Это особенно актуально для запросов, охватывающих большие объемы файлов.

Внутреннее устройство: Apache DataFusion

Внутри каждый воркер использует `Apache DataFusion` для выполнения SQL-запросов к группам строк. `DataFusion` — это аналитический движок запросов с открытым исходным кодом, написанный на Rust.

Разделы (partitions) в `DataFusion` идеально ложатся на модель данных `R2 SQL`, поскольку каждая группа строк (row group) может рассматриваться как независимый раздел. Благодаря этому каждая группа строк обрабатывается параллельно.
Поскольку группы строк обычно содержат как минимум 1000 строк, `R2 SQL` выигрывает от векторизованного выполнения. Каждый поток DataFusion может выполнять SQL-запрос сразу на множестве строк за один проход, амортизируя накладные расходы на интерпретацию запроса.

Поддержка Parquet и Arrow

`DataFusion` имеет первоклассную поддержку Parquet. Используя ranged reads (чтение диапазонов) в R2, он способен считывать только части файлов Parquet, содержащие запрошенные столбцы, пропуская остальные.

Оптимизатор `DataFusion` также позволяет нам “проталкивать” фильтры (push down filters) на самые низкие уровни плана запроса. Другими словами, мы можем применять фильтры прямо в момент чтения значений из файлов Parquet.

Когда воркер заканчивает вычисления, он возвращает результаты координатору через протокол gRPC. `R2 SQL` использует `Apache Arrow` для внутреннего представления результатов. Это формат в оперативной памяти (in-memory), который эффективно представляет массивы структурированных данных. Arrow также определяет формат сериализации `Arrow IPC`, который идеально подходит для передачи данных между процессами по сети.

поясненИИе: Векторизация и Apache Arrow
Векторизованное выполнение (Vectorized execution): Традиционные базы данных обрабатывали одну строку за раз (Row-at-a-time). Это медленно, потому что процессор постоянно переключается. Векторизация означает обработку данных “пачками” (например, сложить сразу 1000 чисел из колонки А с 1000 чисел из колонки Б). Это использует современные возможности CPU (SIMD инструкции) и работает в разы быстрее.

Apache Arrow: Это стандарт того, как хранить эти “пачки” данных в оперативной памяти, чтобы процессору было максимально удобно их читать.
Главный плюс Arrow: Zero-copy. Если один инструмент (DataFusion) передает данные другому (по сети координатору), и оба понимают Arrow, им не нужно тратить время на перекодирование (сериализацию/десериализацию) данных. Они просто “передают указатель” или копируют сырые байты как есть.

Будущие планы

Хотя `R2 SQL` и так хорош в фильтрации, мы планируем быстро добавлять новые возможности:

• Поддержка сложных агрегаций (GROUP BY) в распределенном и масштабируемом виде.
• Инструменты для визуализации выполнения запросов (explain analyze), чтобы помочь разработчикам улучшать производительность.
• Поддержка многих конфигурационных опций Apache Iceberg.
• Возможность запрашивать каталоги прямо из панели управления Cloudflare (Dashboard).

Мы также исследуем различные виды индексов, чтобы сделать запросы еще быстрее, и планируем добавить полнотекстовый поиск, геопространственные запросы и многое другое.

Попробуйте сейчас!

Это ранние дни для `R2 SQL`, но он уже доступен в открытой бете! Переходите к нашему руководству по началу работы, чтобы создать сквозной конвейер данных. Мы ждем вашей обратной связи в нашем Discord для разработчиков.

***

Итог и СоображенИИя

Итог: Cloudflare выпустила мощный инструмент, который превращает их объектное хранилище (R2) в полноценную аналитическую базу данных. Используя открытые стандарты (Iceberg, Parquet, Arrow, DataFusion) и свою глобальную сеть периферийных вычислений (Edge), они решили главную проблему Big Data — необходимость платить за простой серверов. Здесь вы платите только за время выполнения конкретного SQL-запроса.

СоображенИИя:

1. Коммодитизация аналитики: Cloudflare делает с Big Data то же, что ранее сделала с CDN и защитой от DDoS — делает сложные энтерпрайз-технологии доступными “по кнопке”. Использование открытого стека (Rust + Arrow + DataFusion) — это сейчас золотой стандарт построения современных СУБД (по этому пути идут такие гиганты как InfluxDB 3.0, LanceDB и др.). Cloudflare не изобретает велосипед, а собирает очень быструю ракету из лучших деталей.
2. Убийца Snowflake/Databricks для “бедных”? Для огромных корпораций Snowflake и Databricks останутся стандартом из-за богатого функционала. Но для стартапов и среднего бизнеса, у которых данные лежат в R2 (чтобы не платить за egress трафик AWS), появление R2 SQL делает переезд на сторонние аналитические платформы бессмысленным. Зачем гонять данные туда-сюда, если можно выполнить SQL прямо “на месте”?
3. Синергия с ИИ: Упоминание планов на “индексы” и “геопространственные запросы” намекает на векторный поиск в будущем. Если Cloudflare добавит возможность делать векторный поиск по данным в R2 так же нативно, это станет киллер-фичей для всех, кто строит RAG (Retrieval-Augmented Generation) приложения на базе LLM. Хранишь документы в R2 -> R2 SQL ищет контекст -> Workers AI генерируют ответ. Весь цикл внутри одной экосистемы с минимальными задержками.

Еще можно почитать про https://vegafusion.io и про формат https://lance.org – он как раз и добавит векторочков.