FerroDruid
Rust-natives Apache-Druid-kompatibles OLAP
Eine Rust-native, mit der Apache-Druid-Spezifikation kompatible Real-time-OLAP-Datenbank. Sie spricht die Druid REST API, native Query JSON und Druid SQL und liest/schreibt Druid-Segment-Binaries v9/v10 — ohne JVM, ohne ZooKeeper und ohne Control Plane aus sechs Prozessen. Das einzelne Binary startet in unter einer Sekunde mit weniger als 200 MB RAM.
Ein klassischer Apache Druid-Cluster benötigt sechs oder mehr JVM-Prozesse plus ZooKeeper plus eine externe Metadata-Datenbank und 16 GB+ RAM, bevor er eine einzelne Query bedient; der Single-Binary-Modus von FerroDruid ersetzt all das durch einen Prozess, der als eigenständige AMI geliefert wird. v0.2.0 bedient alle acht nativen Query-Typen (timeseries, topN, groupBy, scan, search, segmentMetadata, dataSourceMetadata, timeBoundary); führt Druid SQL aus (SELECT, WHERE, GROUP BY, HAVING, ORDER BY, LIMIT, 30+ Funktionen, EXPLAIN PLAN FOR, ein MSQ-Task-Endpoint, ~95% Core-SQL-Parität); stellt 40+ Druid-kompatible REST-Endpoints bereit; liest/schreibt Druid-Segmente v9/v10; und nimmt Daten über Kafka- und Kinesis-Supervisors sowie native Batch-Ingest auf. Basic Auth (Argon2id) + RBAC ist standardmäßig aktiv, TLS über rustls, mit einem eindeutigen zufälligen Admin-Passwort beim ersten Start.
Das Problem
Apache Druid ist eine leistungsstarke Echtzeit-OLAP-Engine, aber ein klassischer Cluster benötigt sechs oder mehr JVM-Prozesse plus ZooKeeper plus eine externe Metadaten-Datenbank sowie 16 GB oder mehr RAM, bevor er auch nur eine einzige Abfrage beantwortet. Das Bereitstellen, Betreiben und Überwachen dieser Control Plane aus sechs Prozessen ist aufwendig und für Evaluierungsumgebungen sowie kleinere Deployments oft überdimensioniert. Sie möchten die API und das Segment-Format von Druid nutzen, aber nicht die Last haben, eine JVM- und ZooKeeper-Flotte zu betreiben.
Funktionsweise
- 1
Startet als einzelnes Binary
Der Single-Binary-Modus führt einen einzigen Prozess aus — ohne JVM, ohne ZooKeeper und ohne externe Metadaten-Datenbank —, der in unter einer Sekunde startet und weniger als 200 MB RAM benötigt. Er verwendet SQLite für Metadaten und das lokale Dateisystem für Deep Storage und wird als in sich geschlossenes AMI ausgeliefert.
- 2
Spricht das Druid-Wire-Protokoll
Es spricht die Druid-REST-API, natives Query-JSON sowie Druid-SQL und liest und schreibt binäre Druid-Segmentdateien (v9/v10). Es bedient alle acht nativen Abfragetypen und stellt mehr als 40 Druid-kompatible REST-Endpunkte bereit, sodass Sie bestehende Druid-Clients oder einen Apache Superset-Connector direkt anbinden können.
- 3
Startet im gesperrten Zustand, Passwortänderung bei der ersten Anmeldung
Basic Auth (Argon2id) und RBAC sind standardmäßig aktiviert, mit TLS über rustls. Beim ersten Booten wird ein neues, für diese Instanz eindeutiges Zufalls-Admin-Passwort generiert (niemals ein Standard- oder gemeinsam genutztes Passwort) und einmalig in das System-Log der Instanz geschrieben. Das Admin-Konto ist als „must-change“ markiert, sodass jeder API-Endpunkt HTTP 403 zurückgibt, bis der Operator ein neues Passwort per POST übermittelt, was eine Änderung beim ersten Login erzwingt.
Highlights
Druid-spec wire-kompatibel (REST + native JSON + Druid SQL, Segment v9/v10) — bestehende Druid-Clients und Queries funktionieren.
Ein Binary, kein JVM / ZooKeeper / Control Plane aus sechs Prozessen; Start unter einer Sekunde mit weniger als 200 MB RAM.
8 native Query-Typen + Druid SQL (~95% Core-Parität) + Kafka / Kinesis-Ingest; Auth + RBAC standardmäßig aktiv.
Lieferumfang
- In sich geschlossenes Amazon Linux 2023 AMI (Graviton / arm64, unterstützt Instanzen der Klassen t4g, c7g, m7g und r7g)
- Single-Binary-Modus — ein Prozess ohne JVM, ZooKeeper oder externe Metadaten-Datenbank, der in unter einer Sekunde startet und weniger als 200 MB RAM benötigt (SQLite-Metadaten plus Deep Storage auf dem lokalen Dateisystem)
- Alle acht nativen Druid-Abfragetypen (timeseries, topN, groupBy, scan, search, segmentMetadata, dataSourceMetadata, timeBoundary) und mehr als 40 Druid-kompatible REST-Endpunkte
- Druid SQL (SELECT / WHERE / GROUP BY / HAVING / ORDER BY / LIMIT, mehr als 30 Funktionen, EXPLAIN PLAN FOR, ein MSQ-Task-Endpunkt und etwa 95% Core-SQL-Parität)
- Liest und schreibt binäre Druid-Segmentdateien (v9/v10), mit Ingestion über Kafka- und Kinesis-Supervisors sowie via Native Batch
- Sicherheit standardmäßig aktiviert — Basic Auth (Argon2id) plus RBAC, TLS über rustls und ein beim ersten Booten generiertes, instanzspezifisches Zufalls-Admin-Passwort, das beim ersten Login geändert werden muss
- CloudFormation-Template für das Deployment hinter einem ALB (marketplace/cloudformation/ami.yaml) mit Single-Binary Single-Node als unterstützter Topologie (Multi-Node verhält sich standardmäßig fail-closed)
Anwendungsfälle
Teams, die Druid-kompatibles Echtzeit-OLAP ohne den Betrieb eines aus sechs Prozessen bestehenden JVM- und ZooKeeper-Clusters wünschen
Ein Backend für bestehende Clients, die die Druid REST API, natives Query-JSON, Druid SQL oder einen Apache Superset-Connector verwenden
Evaluierungs- und Entwicklungsumgebungen für Druid-Features unter Verwendung eines leichtgewichtigen Binarys, das in unter einer Sekunde startet und weniger als 200 MB benötigt
Single-Node-Streaming- und Zeitreihenanalysen mit Ingestion über Kafka- und Kinesis-Supervisors oder via Native Batch
FAQ
Wie kompatibel ist es mit dem echten Apache Druid?
FerroDruid spricht die Druid REST API, natives Query-JSON sowie Druid SQL und liest und schreibt die Segmente v9/v10. Es deckt alle acht nativen Abfragetypen sowie mehr als 40 Druid-kompatible REST-Endpunkte ab, bei einer Core-Druid-SQL-Parität von ca. 95% (nicht 100%). Der Live-Wire-Deep-Match betrug 5 von 5 gegen Apache Druid 30.0.1 und 5 von 5 mit einem Apache Superset-Connector. Ehrlicher Scope: Die Live-Validierung erfolgte gegen Druid 30.0.1 und den Single-Binary-Modus; Druid 31 bis 36 ist ein spezifikationsbasiertes Designziel, das noch nicht an einem laufenden Cluster kreuzvalidiert wurde.
Benötige ich eine JVM, ZooKeeper oder eine externe Metadaten-Datenbank?
Nicht im Single-Binary-Modus. Ein einzelner Prozess startet in unter einer Sekunde und benötigt weniger als 200 MB RAM — im Gegensatz zu einem klassischen Druid-Cluster, der sechs oder mehr JVM-Prozesse plus ZooKeeper plus eine externe Metadaten-Datenbank und mindestens 16 GB RAM benötigt. Der unterstützte Single-Binary-Pfad verwendet SQLite für Metadaten und das lokale Dateisystem für Deep Storage.
Kann ich eine Multi-Node-Konfiguration betreiben?
Die unterstützte Topologie ist Single-Binary Single-Node; Multi-Node-Konfigurationen verhalten sich standardmäßig fail-closed. Ehrlich gesagt wurde die Live-Validierung für den Single-Binary-Modus durchgeführt, und wir haben es zum jetzigen Zeitpunkt nicht als laufenden Multi-Node-Cluster validiert. Siehe docs/KNOWN_LIMITATIONS.md für Details.
Wie wird die Sicherheit gehandhabt und wie läuft der erste Login ab?
Basic Auth (Argon2id) und RBAC sind standardmäßig aktiviert, mit TLS über rustls. Beim ersten Booten generiert das AMI ein neues, für diese Instanz eindeutiges Zufalls-Admin-Passwort (niemals ein Standard- oder gemeinsam genutztes) und schreibt es einmalig in das System-Log der Instanz. Das Admin-Konto ist als „must-change“ markiert, sodass jeder API-Endpunkt HTTP 403 zurückgibt, bis der Operator ein neues Passwort per POST an /druid-ext/basic-security/authentication/db/basic/users/admin/credential übermittelt. Die rotierten Zugangsdaten werden dauerhaft gespeichert und bleiben auch nach Neustarts erhalten.
Wie stelle ich es bereit und wie funktionieren Lizenzierung und Abrechnung?
Stellen Sie es mit dem bereitgestellten CloudFormation-Template (marketplace/cloudformation/ami.yaml) hinter einem Application Load Balancer bereit; terminieren Sie TLS am ALB und geben Sie den Service-Port nicht direkt für das Internet frei. Richten Sie Ihre Clients (REST API, native query JSON, Druid SQL oder einen Apache Superset-Connector) auf den Load-Balancer-Endpunkt aus. Dieses Listing vertreibt eine gehärtete, gescannte und unterstützte Distribution, die aus der Apache-2.0-Quelle mit einer festen Release-Version erstellt wurde; der Code selbst bleibt unter Apache-2.0. Das AMI wird von AWS automatisch pro laufender Instanzstunde erfasst, ohne dass sich im Produkt selbst Code für die Verbrauchsmessung befindet.
Preismodell
Stündliche Softwaregebühr + EC2 (t4g / c7g / m7g / r7g-Klasse, Arm). Abrechnung pro Instance-Typ.
Weitere S4-Produkte
S4 — Squished S3
Transparenter GPU S3-Komprimierungs-Gateway
S4 Logs
CloudWatch Logs nach zstd S3 archivieren
S4 Metrics
CloudWatch Metric-Cardinality steuern