FerroDruid
OLAP compatible Apache Druid natif Rust
Une base de données OLAP temps réel native Rust, compatible avec la spécification Apache Druid. Elle parle la Druid REST API, le JSON de requêtes natives et Druid SQL, et lit/écrit les binaires de segments Druid v9/v10 — sans JVM, sans ZooKeeper et sans plan de contrôle à six processus. Le binaire unique démarre en moins d’une seconde avec moins de 200 MB de RAM.
Un cluster Apache Druid classique nécessite au moins six processus JVM, ZooKeeper, une base de métadonnées externe et 16 GB+ de RAM avant de servir une seule requête ; le mode binaire unique de FerroDruid remplace tout cela par un processus livré comme AMI autonome. v0.2.0 sert les huit types de requêtes natives (timeseries, topN, groupBy, scan, search, segmentMetadata, dataSourceMetadata, timeBoundary) ; exécute Druid SQL (SELECT, WHERE, GROUP BY, HAVING, ORDER BY, LIMIT, 30+ fonctions, EXPLAIN PLAN FOR, endpoint de tâche MSQ, ~95% de parité SQL cœur) ; expose 40+ endpoints REST compatibles Druid ; lit/écrit les segments Druid v9/v10 ; et ingère depuis des supervisors Kafka et Kinesis et du batch natif. Basic auth (Argon2id) + RBAC est activé par défaut, TLS via rustls, avec un mot de passe admin aléatoire unique généré au premier démarrage.
Le problème
Apache Druid est un puissant moteur OLAP en temps réel, mais un cluster classique nécessite au moins six processus JVM, plus ZooKeeper, plus une base de données de métadonnées externe, et 16 GB de RAM ou plus, avant de pouvoir servir une seule requête. Mettre en place, exploiter et surveiller ce plan de contrôle à six processus est lourd, et c'est surdimensionné pour les environnements d'évaluation et les petits déploiements. Vous souhaitez utiliser l'API et le format de segment de Druid, mais sans la contrainte de gérer une flotte de JVM et ZooKeeper.
Fonctionnement
- 1
Démarre sous forme de binaire unique
Le mode binaire unique exécute un seul processus — sans JVM, ni ZooKeeper, ni base de données de métadonnées externe — qui démarre en moins d'une seconde et utilise moins de 200 MB de RAM. Il utilise SQLite pour les métadonnées et le système de fichiers local pour le stockage profond, et est livré sous forme d'AMI autonome.
- 2
Prend en charge le protocole de communication de Druid
Il prend en charge l'API REST de Druid, le JSON des requêtes natives et Druid SQL, et lit et écrit les fichiers binaires de segment Druid v9/v10. Il traite les huit types de requêtes natives et expose plus de 40 endpoints REST compatibles avec Druid, vous permettant d'y diriger directement les clients Druid existants ou un connecteur Apache Superset.
- 3
Démarre sécurisé, changement de mot de passe à la première connexion
L'authentification Basic (Argon2id) et le RBAC sont activés par défaut, avec TLS via rustls. Au premier démarrage, il génère un nouveau mot de passe admin aléatoire unique à cette instance (jamais de mot de passe par défaut ou partagé) et l'écrit une seule fois dans le journal système de l'instance. Le compte admin est marqué comme devant être modifié (must-change), ainsi chaque endpoint d'API renvoie HTTP 403 jusqu'à ce que l'opérateur envoie un nouveau mot de passe par POST, forçant le changement lors de la première connexion.
Points forts
Compatible filaire avec la spécification Druid (REST + JSON natif + Druid SQL, segment v9/v10) — les clients et requêtes Druid existants fonctionnent.
Un binaire, pas de JVM / ZooKeeper / plan de contrôle à six processus ; démarrage en moins d’une seconde avec moins de 200 MB RAM.
8 types de requêtes natives + Druid SQL (~95% de parité cœur) + ingestion Kafka / Kinesis ; auth + RBAC activés par défaut.
Ce qui est inclus
- AMI Amazon Linux 2023 autonome (Graviton / arm64, prenant en charge les instances des classes t4g, c7g, m7g et r7g)
- Mode binaire unique — un seul processus sans JVM, ZooKeeper ni base de données de métadonnées externe, démarrant en moins d'une seconde avec moins de 200 MB de RAM (métadonnées SQLite et stockage profond sur le système de fichiers local)
- Les huit types de requêtes natives Druid (timeseries, topN, groupBy, scan, search, segmentMetadata, dataSourceMetadata, timeBoundary) et plus de 40 endpoints REST compatibles avec Druid
- Druid SQL (SELECT / WHERE / GROUP BY / HAVING / ORDER BY / LIMIT, plus de 30 fonctions, EXPLAIN PLAN FOR, un endpoint de tâche MSQ et une parité SQL de base d'environ 95%)
- Lecture et écriture des fichiers binaires de segment Druid v9/v10, avec ingestion depuis les superviseurs Kafka et Kinesis et via batch natif
- Sécurité activée par défaut — authentification Basic (Argon2id) plus RBAC, TLS via rustls, et un mot de passe admin aléatoire par instance généré au premier démarrage devant être modifié à la première connexion
- Modèle CloudFormation pour un déploiement derrière un ALB (marketplace/cloudformation/ami.yaml), avec single-binary single-node comme topologie prise en charge (le multi-nœud échoue en mode fermé par défaut)
Cas d'usage
Les équipes qui souhaitent un OLAP en temps réel compatible avec Druid sans exploiter un cluster à six processus JVM et ZooKeeper
Un backend pour les clients existants utilisant l'API REST de Druid, le JSON des requêtes natives, Druid SQL ou un connecteur Apache Superset
Environnements d'évaluation et de développement pour les fonctionnalités de Druid, utilisant un binaire léger qui démarre en moins d'une seconde avec moins de 200 MB
Analyses de streaming et de séries temporelles sur un seul nœud, avec ingestion depuis des superviseurs Kafka et Kinesis ou via batch natif
FAQ
Dans quelle mesure est-il compatible avec le véritable Apache Druid ?
FerroDruid prend en charge l'API REST de Druid, le JSON des requêtes natives et Druid SQL, et lit et écrit les segments v9/v10. Il couvre les huit types de requêtes natives et plus de 40 endpoints REST compatibles avec Druid, avec une parité SQL Druid de base d'environ 95% (pas 100%). Le deep-match réseau en direct était de 5 sur 5 contre Apache Druid 30.0.1 et de 5 sur 5 avec un connecteur Apache Superset. Périmètre honnête : la validation en direct concerne Druid 30.0.1 et le mode binaire unique ; les versions Druid 31 à 36 constituent un objectif de conception basé sur les spécifications, non encore validé par rapport à un cluster en cours d'exécution.
Ai-je besoin d'une JVM, de ZooKeeper ou d'une base de données de métadonnées externe ?
Pas en mode binaire unique. Un seul processus démarre en moins d'une seconde et utilise moins de 200 MB de RAM — contrairement à un cluster Druid classique, qui nécessite au moins six processus JVM, plus ZooKeeper, plus une base de données de métadonnées externe et 16 GB de RAM ou plus. L'approche binaire unique prise en charge utilise SQLite pour les métadonnées et le système de fichiers local pour le stockage profond.
Puis-je exécuter une configuration multi-nœuds ?
La topologie prise en charge est single-binary single-node ; les configurations multi-nœuds échouent en mode fermé par défaut. Pour être honnête, la validation en direct concerne uniquement le mode binaire unique, et nous ne l'avons pas validé en tant que cluster multi-nœuds actif à ce jour. Consultez docs/KNOWN_LIMITATIONS.md pour plus de détails.
Comment la sécurité est-elle gérée, et comment se déroule la première connexion ?
L'authentification Basic (Argon2id) et le RBAC sont activés par défaut, avec TLS via rustls. Au premier démarrage, l'AMI génère un nouveau mot de passe admin aléatoire unique à cette instance (jamais de mot de passe par défaut ou partagé) et l'écrit une seule fois dans le journal système de l'instance. Le compte admin est marqué comme devant être modifié (must-change), ainsi chaque endpoint d'API renvoie HTTP 403 jusqu'à ce que l'opérateur envoie un nouveau mot de passe par POST à /druid-ext/basic-security/authentication/db/basic/users/admin/credential. Les informations d'identification après rotation sont persistées et survivent aux redémarrages.
Comment le déployer, et comment fonctionnent la licence et la facturation ?
Déployez-le avec le modèle CloudFormation fourni (marketplace/cloudformation/ami.yaml) derrière un Application Load Balancer ; terminez le TLS au niveau de l'ALB et n'exposez pas directement le port de service sur Internet. Dirigez vos clients (API REST, JSON des requêtes natives, Druid SQL ou un connecteur Apache Superset) vers l'endpoint du load balancer. Cette fiche produit vend une distribution sécurisée, scannée et supportée, construite à partir du code source Apache-2.0 pour une version spécifique ; le code lui-même reste sous licence Apache-2.0. L'AMI est mesurée automatiquement par AWS par heure d'instance active, sans aucun code de mesure dans le produit.
Modèle de tarification
Frais logiciel horaires + EC2 (classe t4g / c7g / m7g / r7g, Arm). Facturation à l’usage par type d’instance.
Autres produits S4
S4 — Squished S3
Gateway transparent de compression S3 par GPU
S4 Logs
Archiver CloudWatch Logs vers S3 zstd
S4 Metrics
Gouverner la cardinalité des métriques CloudWatch