FerroDruid

FerroDruid prend en charge l'API REST de Druid, le JSON des requêtes natives et Druid SQL, et lit les segments v9 sur disque d'Apache Druid — vérifié localement sur des segments écrits par Druid 31.0.2 / 35.0.1 (les segments écrits par FerroDruid utilisent son propre format). 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%). Un flux de bout en bout avec Apache Superset 4.1.4 — Test Connection, synchronisation automatique des datasets, graphiques, filtres de plage temporelle, SQL Lab — est vérifié contre la v1.2.0, dont les post-agrégations multi-segments correspondent à Apache Druid 36.0.0 sur 13 cas audités sur 13. Périmètre honnête : la vérification couvre le mode binaire unique ; la lecture des segments est vérifiée octet par octet sur disque local (contre Druid 31.0.2 et 35.0.1) et de bout en bout depuis un deep storage S3 réel d'AWS (un segment Druid 31, aller-retour avec le même nombre de lignes et le même ensemble de colonnes) ; les encodages de segment non par défaut sont rejetés avec des erreurs explicites ; et le SQL JOIN/CTE échoue de manière fermée au lieu de s'exécuter.

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.

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.

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.

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 de FerroDruid pour une version figée. Le code source est disponible sous la Business Source License 1.1 (BUSL-1.1) : l’usage en production est permis, sauf pour le proposer à des tiers comme un service concurrent de base de données/analytique/OLAP hébergé, géré ou embarqué ; chaque version passe sous Apache License 2.0 quatre ans après sa publication (licence commerciale : [email protected]). L'AMI est mesurée automatiquement par AWS par heure d'instance active, sans aucun code de mesure dans le produit.