Einführung der Cloudflare Data Platform zum Erfassen, Speichern und Abfragen von Daten direkt in Cloudflare

Während der Developer Week im April 2025 haben wir die Public Beta-Version des R2 Data Catalog vorgestellt. Dieser vollständig verwaltete Apache Iceberg-Katalog beruht auf dem R2-Objektspeicher von Cloudflare. Heute präsentieren wir Ihnen drei neue, auf diesem Fundament beruhende Produkte:

• Cloudflare Pipelines empfängt per Workers oder HTTP übermittelte Ereignismeldungen, wandelt sie mit SQL um und sendet sie an Iceberg oder in Form von Dateien an R2

• R2 Data Catalog übernimmt die Verwaltung der Iceberg-Metadaten und die laufende Pflege, einschließlich Verdichtung, zur Abfrage-Optimierung

• Unsere interne, verteilte SQL-Engine R2 SQL wurde für Abfragen im Petabyte-Maßstab von Daten in R2 entwickelt

Gemeinsam bilden diese Lösungen die Cloudflare Data Platform, eine Komplettlösung zur Befüllung, Speicherung und Abfrage von Analysedaten-Tabellen.

Wie alle Produkte der Entwicklerplattform von Cloudflare laufen sie auf unserer globalen Recheninfrastruktur. Da sie auf offenen Standards und Interoperabilität beruhen, können Sie Ihre eigene Iceberg-Abfrage-Engine – ob PyIceberg, DuckDB oder Spark – mit anderen Plattformen wie Databricks und Snowflake verbinden, ohne für den Datenzugriff Egress-Gebühren zahlen zu müssen.

Analysedaten sind für moderne Unternehmen unverzichtbar, weil damit das Nutzerverhalten und die eigene Performance besser verstanden und Probleme erkannt werden können. Doch konventionelle Dateninfrastruktur ist kostspielig und aufwendig im Betrieb, da sie eine fest zugeordnete Cloud-Infrastruktur und internes Know-how erfordert. Cloudflare Data Plattform ist bedienungsfreundlich, erschwinglich und bietet nutzungsbasierte Tarife.

Wenn Sie direkt loslegen möchten, finden Sie in unserem Data Platform-Tutorial eine Schritt-für-Schritt-Anleitung zur Erstellung einer Pipeline, die Ereignismeldungen verarbeitet und an eine R2 Data Catalog-Tabelle schickt, die dann per R2 SQL abgefragt werden kann. Wie wir an diesen Punkt gekommen sind und wie das Ganze funktioniert, erfahren Sie im folgenden Text.

Bei der Einführung des R2-Objektspeichers im Jahr 2021 haben wir eine radikale Preisstrategie verfolgt, da wir beschlossen haben, keine Egress-Gebühren zu erheben. Diese Bandbreitenkosten werden von Cloud-Dienstleistern normalerweise für den Datenexport berechnet, sodass die Daten praktisch „freigekauft“ werden müssen. Möglich war dies, weil wir bereits eines der größten globalen Netzwerke der Welt aufgebaut hatten, das mit Tausenden von Internetdienstanbietern, Cloud-Diensten und anderen Unternehmen verbunden ist.

Unser Objektspeicher unterstützt eine Vielzahl von Anwendungsfällen, von Medieninhalten über statische Assets bis hin zu KI-Trainingsdaten. Doch wir haben festgestellt, dass mit der Zeit immer mehr Unternehmen begonnen haben, zur Speicherung ihrer Warehouses für Analysedaten quelloffene Daten- und Tabellenformate zu verwenden.

Möglich wird das durch die Technologie Apache Iceberg. Es handelt sich dabei um ein Tabellenformat, das zusätzlich zu den Datendateien im Objektspeicher datenbankähnliche Funktionen (wie Updates, ACID-Transaktionen und Schemaentwicklung) bietet – mit anderen Worten: eine Metadatenebene, die Clients darüber informiert, aus welchen Datendateien eine bestimmte logische Tabelle besteht, um welche Schemata es sich handelt und wie diese effizient abgefragt werden können.

Aufgrund einer branchenweiten Akzeptanz von Iceberg sind die Nutzer inzwischen nicht mehr an eine bestimmte Abfrage-Engine gebunden. Daten für mehrere Weltregionen und Clouds abzufragen, ist aufgrund der damit verbundenen Egress-Gebühren aber auch weiterhin extrem kostspielig. Dieses Problem wird aber durch R2 gelöst, da hier ausgehender Traffic kostenlos ist. Somit sind die Nutzer auch nicht mehr an bestimmte Clouds gebunden. Sie können ihre Daten an einem herstellerneutralen Ort speichern und Teams die Verwendung einer für ihre Daten und Abfragemuster geeigneten Abfrage-Engine ihrer Wahl ermöglichen.

Allerdings müssen die Nutzer dann weiterhin alle Metadaten und die übrige Infrastruktur selbst verwalten. Uns ist klargeworden, dass wir die Gelegenheit hatten, ein großes Problem zu lösen und Reibungsverluste bei der Speicherung von Data Lakes auf R2 zu reduzieren. Daraus ist unser verwalteter Iceberg-Katalog, R2 Data Catalog, hervorgegangen.

Nach der Speicherung der Daten auf R2 und der Verwaltung der Metadaten mussten die Nutzer immer noch einige Lücken schließen.

Wie lassen sich Daten in Iceberg-Tabellen übertragen? Und wenn das geschafft ist: Wie kann die Abfrage-Performance optimiert werden? Und wie lässt sich schließlich aus den Daten ein Mehrwert gewinnen, ohne eine Abfrage-Engine selbst zu hosten oder eine andere Cloud-Plattform zu verwenden?

Im Folgenden wird darauf eingegangen, wie sich diese Herausforderungen mit den drei Produkten von Cloudflare Data Platform meistern lassen.

Analysedatentabellen bestehen aus Ereignissen, also Dingen, die zu einem bestimmten Zeitpunkt vorgefallen sind. Diese können von Serverprotokollen, Mobilgeräte-Anwendungen oder IoT-Geräten stammen und in Datenformaten wie JSON, Avro oder Protobuf kodiert sein. Im Idealfall verfügen sie über ein Schema – einen standardisierten Satz von Feldern. Es kann sich aber um alles handeln, was dem betreffenden Team vorschwebt.

Doch bevor sich Ereignisse mit Iceberg abfragen lassen, müssen sie erst erfasst, gemäß einem Schema strukturiert und in den Objektspeicher geschrieben werden. An dieser Stelle kommt Cloudflare Pipelines ins Spiel.

Die Lösung basiert auf Arroyo, einer Stream-Processing-Engine, die wir Anfang des Jahres übernommen haben. Sie empfängt Ereignisse, wandelt sie mit SQL-Abfragen um und leitet sie an R2 und R2 Data Catalog weiter.

Pipelines ist um drei zentrale Objekte herum aufgebaut:

Über Streams werden Daten bei Cloudflare eingespeist. Es handelt sich um robuste, gepufferte Warteschlangen, die Ereignisse empfangen und zur Verarbeitung speichern. Sie können Ereignisse auf zwei Arten entgegennehmen: über einen HTTP-Endpunkt oder eine Cloudflare Worker-Bindung.

Sinks definieren das Ziel der Daten. Wir unterstützen das Einlesen bei R2 Data Catalog sowie das Schreiben von Rohdateien in R2 im JSON- oder Apache Parquet-Format. Sinks kann so konfiguriert werden, dass Dateien häufig geschrieben werden und somit dem latenzarmen Datenimport Vorrang eingeräumt wird. Alternativ können größere Dateien seltener geschrieben werden, um eine bessere Abfrage-Performance zu erreichen. In beiden Fällen erfolgt der Import genau einmal. Das heißt, dass Ereignisse auf dem Weg zu R2 niemals dupliziert oder verworfen werden.

Pipelines verbindet Streams und Sinks per SQL-Transformationen, die Ereignisse ändern können, bevor sie in den Speicher geschrieben werden. Dadurch können Validierung, Schematisierung und Verarbeitung nach dem Shift-Left-Prinzip zur Importebene verlagert werden. So wird eine einfache, schnelle und korrekte Abfrage gewährleistet.

Es folgt eine Beispiel-Pipeline, die Ereignisse aus einer Clickstream-Datenquelle empfängt und diese in Iceberg speichert:

INSERT into events_table
SELECT
  user_id,
  lower(event) AS event_type,
  to_timestamp_micros(ts_us) AS event_time,
  regexp_match(url, '^https?://([^/]+)')[1]  AS domain,
  url,
  referrer,
  user_agent
FROM events_json
WHERE event = 'page_view'
  AND NOT regexp_like(user_agent, '(?i)bot|spider');

SQL-Transformationen sind sehr leistungsstark und geben Ihnen die volle Kontrolle darüber, wie Daten strukturiert und in die Tabelle geschrieben werden. Sie haben zum Beispiel folgende Möglichkeiten:

• Daten schematisieren und normalisieren – sogar mit JSON-Funktionen zum Extrahieren von Feldern aus beliebigem JSON-Dateien

• Ereignisse herausfiltern oder in gesonderte Tabellen mit eigenen Schemata aufteilen

• Sensible Informationen vor der Speicherung mit regulären Ausdrücken unkenntlich machen

• Verschachtelte Arrays und Objekte in separate Ereignisse entfalten

Pipelines unterstützt vorerst zustandslose Transformationen. In Zukunft werden wir die zustandsbehafteten Verarbeitungsfunktionen von Arroyo stärker nutzen, um Aggregationen, inkrementell aktualisierte materialisierte Ansichten und Joins zu unterstützen.

Cloudflare Pipelines ist ab sofort als Open Beta-Version verfügbar. Sie können eine Pipeline über das Dashboard, Wrangler oder die REST-API erstellen. Wenn Sie direkt loslegen möchten, lohnt ein Blick in unsere Entwicklerdokumentation.

Derzeit fallen während der Open Beta-Phase keine Gebühren für Pipelines an. Für R2-Speicherung und -Vorgänge, die dadurch veranlasst werden, dass Sinks Daten in R2 schreiben, werden jedoch Standardtarife berechnet. Wenn wir mit der Abrechnung beginnen, wird die Berechnung voraussichtlich auf Grundlage der gelesenen Datenmenge, der Datenmenge, die per SQL-Transformationen verarbeitet wird, und der bereitgestellten Daten erfolgen.

Wir haben im April die Open Beta-Version von R2 Data Catalog eingeführt und waren von der Resonanz sehr beeindruckt. Abfrage-Engines wie DuckDB haben native Unterstützung hinzugefügt und wir haben nützliche Integrationen wie marimo notebooks verzeichnet.

All dies erleichtert den Einstieg in Iceberg. Es ist nicht nötig, einen Datenbankcluster einzurichten, sich mit einem Objektspeicher zu verbinden oder eine Infrastruktur zu pflegen. Ein Katalog lässt sich schon mit wenigen Wrangler-Befehlen erstellen:

$ npx wrangler bucket create mycatalog 
$ npx wrangler r2 bucket catalog enable mycatalog

Dadurch wird ein Data Lake bereitgestellt, der auf Speicherkapazitäten im Petabyte-Bereich skaliert und mit jeder beliebigen Engine abgefragt werden kann, ohne dass dabei Egress-Gebühren anfallen.

Das bloße Speichern der Daten reicht aber nicht aus. Beim Import von Daten wächst mit der Zeit die Zahl der zugrunde liegenden Datendateien, aus denen eine Tabelle besteht, wodurch sich die Abfrage auf Dauer verlangsamt.

Dies ist besonders beim latenzarmen Import ein Problem, da in diesem Fall Ereignisse so schnell wie möglich abfragbar sein sollten. Häufiges Schreiben von Daten bedeutet eine größere Menge kleinerer Dateien. Jede für eine Abfrage benötigte Datei muss aufgelistet, heruntergeladen und gelesen werden. Die Beanspruchung durch zu viele kleine Dateien kann die Gesamtabfragezeit beeinträchtigen.

Lösen lässt sich dieses Problem mit Verdichtung, einer vom Katalog regelmäßig durchgeführten Instandhaltungsmaßnahme. Dabei werden kleine Dateien in größere umgeschrieben. Dies reduziert den Metadaten-Overhead und steigert die Abfrageperformance. 

Ab sofort wird Verdichtung von R2 Data Catalog unterstützt. Sie können diese Funktion für Ihren Katalog ganz leicht aktivieren:

$ npx wrangler r2 bucket catalog compaction enable mycatalog

Die Unterstützung der Verdichtung gilt zunächst für kleine Dateien, wird aber zu gegebener Zeit auf zusätzliche Verdichtungsstrategien ausgeweitet. In der zugehörigen Dokumentation erfahren Sie mehr darüber, wie Verdichtung funktioniert und aktiviert werden kann.

Während der aktuellen Open Beta-Phase werden für R2 Data Catalog keine Gebühren erhoben. Vorläufig stellen wir uns die künftige Preisgestaltung folgendermaßen vor:

* Wir behalten uns Preisänderungen bis zur allgemeinen Verfügbarkeit vor.

Wenn das Produkt kostenpflichtig wird oder im Fall von Änderungen informieren wir Sie mindestens 30 Tage im Voraus.

Die Aufnahme von Daten in den R2 Data Catalog ist nur der erste Schritt. Das eigentliche Ziel besteht darin, daraus Erkenntnisse zu gewinnen und einen Mehrwert zu ziehen. Üblicherweise erfordert das die Einrichtung und Verwaltung einer Abfrage-Engine wie DuckDB, Spark oder Trino und somit zusätzlichen Betriebsaufwand. Doch was wäre, wenn Abfragen direkt in Cloudflare ausgeführt werden könnten?

Das ist jetzt möglich, denn wir haben eine Abfrage-Engine speziell für R2 Data Catalog und die Edge-Infrastruktur von Cloudflare entwickelt. Sie heißt R2 SQL und ist ab sofort als Open Beta-Version verfügbar.

Mit Wrangler ist das Ausführen einer Abfrage in einer R2 Data Catalog-Tabelle ganz unkompliziert:

$ npx wrangler r2 sql query "{WAREHOUSE}" "\
  SELECT user_id, url FROM events \
  WHERE domain = 'mywebsite.com'"

Unsere Fähigkeit, die zeitliche Ausführung von Rechenvorgängen überall im globalen Cloudflare-Netzwerk zu planen, bildet das Grundgerüst von R2 SQL. Dadurch können wir Daten direkt dort verarbeiten, wo sie sich befinden, anstatt von Ihnen zu verlangen, zentrale Cluster für Ihre Analyse-Workloads zu verwalten.

R2 SQL ist eng in R2 Data Catalog und R2 integriert. Dadurch kann der Abfrage-Planer über einfaches Speicher-Scanning hinausgehen und die aufschlussreichen Statistiken in den Metadaten von R2 Data Catalog umfassend nutzen. Das bietet eine leistungsstarke Grundlage für eine neue Klasse von Abfrageoptimierungen, z. B. Hilfsindizes oder die Aktivierung komplexerer Analysefunktionen in der Zukunft.

Das Ergebnis ist ein vollständig serverloses Nutzererlebnis. Sie können sich also ganz auf SQL konzentrieren, ohne die Engine aus dem Effeff zu beherrschen. Alle, die mehr wissen möchten, finden hier eine ausführliche Beschreibung dazu, wie die verteilte Abfrage-Engine von R2 SQL maßstabsgerecht funktioniert.

Die Open Beta-Version vermittelt einen ersten Eindruck von den R2 SQL-Abfragefunktionen und konzentriert sich zunächst auf Filterabfragen. Zu einem späteren Zeitpunkt werden wir weitere SQL-Funktionen wie komplexe Aggregationen aufnehmen.

Wir sind schon gespannt darauf, wofür unsere Nutzer R2 SQL einsetzen werden. Wenn Sie die Lösung ausprobieren möchten, werfen Sie doch einen Blick in die zugehörige Dokumentation oder schauen Sie sich die Tutorials dazu an. Während der Beta-Phase werden für die Nutzung von R2 SQL derzeit keine Gebühren in Rechnung gestellt. Für R2-Speicherung und durch Abfragen verursachte Vorgänge werden aber Standardpreise berechnet. In der Zukunft planen wir, für das im Rahmen von Abfragen gescannte Datenvolumen Gebühren zu berechnen. Wir werden Sie aber vor der Umstellung benachrichtigen.

Aktuell können Sie mit der Data Platform von Cloudflare Ereignisse in den R2 Data Catalog aufnehmen und sie über R2 SQL abfragen. In der ersten Jahreshälfte 2026 werden wir die Funktionen dieser Produkte erweitern. Dazu gehören folgende Neuerungen:

• Integration bei Logpush, sodass Protokolle direkt in Cloudflare umgewandelt, gespeichert und abgefragt werden können

• Benutzerdefinierte Funktionen über Workers und Unterstützung zustandsbehafteter Verarbeitung für Streaming-Transformationen

• Erweiterung des Funktionsumfangs von R2 SQL zur Abdeckung von Aggregationen und Joins

In der Zwischenzeit können Sie Cloudflare Data Platform ausprobieren. Folgen Sie dafür dem Tutorial, um ein Ende-zu-Ende-System für Analysedaten zu erstellen – von der Erfassung mit Pipelines über die Speicherung im R2 Data Catalog bis hin zur Abfrage mit R2 SQL.  Wir sind schon gespannt darauf, was Sie sich einfallen lassen! Sie haben Feedback für uns? Teilen Sie es uns auf unserem Entwickler-Discord-Kanal mit.