FerroDruid
OLAP compatible con Apache Druid nativo en Rust
¿Cuándo se amortiza?
Ejemplo: 5.000 $/mes en observabilidad gestionada
Con 5.000 $/mes en observabilidad gestionada, una reducción conservadora del 40% equivale aproximadamente a 2.000 $/mes de cargo bruto de uso evitado — antes de la tarifa de software de S4, EC2 y diferencias de carga de trabajo.
Estime su ahorro
Introduzca su gasto o uso mensual relevante para una estimación aproximada — sin subir factura.
Base de datos OLAP en tiempo real nativa en Rust y compatible con la especificación de Apache Druid. Habla Druid REST API, native query JSON y Druid SQL, y lee binarios de segmento Druid v9 — sin JVM, sin ZooKeeper y sin plano de control de seis procesos. El binario único arranca en menos de un segundo con menos de 200 MB de RAM.
Un clúster clásico de Apache Druid necesita seis o más procesos JVM, además de ZooKeeper, una base de datos de metadatos externa y 16 GB+ de RAM antes de servir una sola consulta; el modo de binario único de FerroDruid sustituye todo eso por un proceso que se entrega como AMI autocontenida. Sirve los ocho tipos de consulta nativa (timeseries, topN, groupBy, scan, search, segmentMetadata, dataSourceMetadata, timeBoundary); ejecuta Druid SQL (SELECT, WHERE, GROUP BY, HAVING, ORDER BY, LIMIT, 30+ funciones, EXPLAIN PLAN FOR, un endpoint de tarea MSQ, ~95% de paridad con SQL core); expone 40+ endpoints REST compatibles con Druid; lee segmentos Druid v9 (verificado localmente con segmentos escritos por Druid 31.0.2 / 35.0.1, y de extremo a extremo desde S3 deep storage real de AWS: un segmento de Druid 31, ida y vuelta); e ingiere desde supervisores Kafka y Kinesis y batch nativo. Basic auth (Argon2id) + RBAC está activado por defecto, TLS mediante rustls, con una contraseña de administración aleatoria única generada en el primer arranque.
El problema
Apache Druid es un potente motor OLAP en tiempo real, pero un clúster clásico necesita seis o más procesos JVM, además de ZooKeeper, una base de datos de metadatos externa y 16 GB o más de RAM antes de servir una sola consulta. Desplegar, operar y monitorear ese plano de control de seis procesos es una tarea pesada, y resulta excesivo para entornos de evaluación y despliegues pequeños. Quiere la API y el formato de segmentos de Druid, pero no la carga de gestionar una flota de JVM y ZooKeeper.
Cómo funciona
- 1
Se inicia como un único binario
El modo single-binary ejecuta un solo proceso — sin JVM, ni ZooKeeper, ni base de datos de metadatos externa — que se inicia en menos de un segundo y consume menos de 200 MB de RAM. Utiliza SQLite para los metadatos y el sistema de archivos local para el almacenamiento profundo, y se distribuye como una AMI autocontenida.
- 2
Soporta el protocolo de red de Druid
Soporta la API REST de Druid, JSON de consultas nativas y Druid SQL, y lee archivos binarios de segmentos v9 de Druid (verificado localmente con segmentos escritos por Druid 31.0.2 / 35.0.1, y de extremo a extremo desde S3 deep storage real de AWS: un segmento de Druid 31, ida y vuelta). Ofrece los ocho tipos de consultas nativas y expone más de 40 endpoints REST compatibles con Druid, de modo que puede apuntar los clientes de Druid existentes o un conector de Apache Superset directamente a él.
- 3
Se inicia bloqueado, con cambio de contraseña en el primer inicio de sesión
La autenticación básica (Argon2id) y RBAC están activados por defecto, con TLS a través de rustls. En el primer inicio, genera una contraseña de administrador aleatoria única para esa instancia (nunca una predeterminada o compartida) y la escribe una vez en el registro del sistema de la instancia. La cuenta de administrador está marcada como de cambio obligatorio, por lo que cada endpoint de la API devuelve HTTP 403 hasta que el operador envía una nueva contraseña por POST, lo que obliga a cambiarla en el primer inicio de sesión.
Características destacadas
Compatible a nivel wire con la especificación de Druid (REST + native JSON + Druid SQL, segmento v9) — los clientes y consultas Druid existentes funcionan.
Un binario, sin JVM / ZooKeeper / plano de control de seis procesos; arranque en menos de un segundo con menos de 200 MB de RAM.
8 tipos de consulta nativa + Druid SQL (~95% de paridad core) + ingesta Kafka / Kinesis; auth + RBAC activados por defecto.
Qué incluye
- AMI de Amazon Linux 2023 autocontenida (Graviton / arm64, compatible con instancias de las clases t4g, c7g, m7g y r7g)
- Modo single-binary — un solo proceso sin JVM, ZooKeeper ni base de datos de metadatos externa, que se inicia en menos de un segundo con menos de 200 MB de RAM (metadatos de SQLite más almacenamiento profundo en el sistema de archivos local)
- Los ocho tipos de consultas nativas de Druid (timeseries, topN, groupBy, scan, search, segmentMetadata, dataSourceMetadata, timeBoundary) y más de 40 endpoints REST compatibles con Druid
- Druid SQL (SELECT / WHERE / GROUP BY / HAVING / ORDER BY / LIMIT, más de 30 funciones, EXPLAIN PLAN FOR, un endpoint de tareas MSQ y aproximadamente un 95% de paridad con SQL principal)
- Lectura de archivos binarios de segmentos v9 de Druid (verificada localmente con segmentos escritos por Druid 31.0.2 / 35.0.1, y de extremo a extremo desde S3 deep storage real de AWS: un segmento de Druid 31, ida y vuelta), con ingesta desde supervisores de Kafka y Kinesis y mediante lotes nativos
- Seguridad activada por defecto — autenticación básica (Argon2id) más RBAC, TLS mediante rustls y una contraseña de administrador aleatoria por instancia generada en el primer inicio que se debe cambiar en el primer inicio de sesión
- Plantilla de CloudFormation para el despliegue detrás de un ALB (marketplace/cloudformation/ami.yaml), con la topología single-binary single-node como compatible (las configuraciones multinodo fallan en modo cerrado por defecto)
Casos de uso
Equipos que quieren un OLAP en tiempo real compatible con Druid sin tener que operar un clúster de seis procesos JVM y ZooKeeper
Un backend para los clientes existentes que utilizan la API REST de Druid, el JSON de consultas nativas, Druid SQL o un conector de Apache Superset
Entornos de evaluación y desarrollo para funcionalidades de Druid utilizando un binario ligero que se inicia en menos de un segundo con menos de 200 MB
Configuración de un solo nodo para análisis de series temporales y streaming con ingesta desde supervisores de Kafka y Kinesis o mediante lotes nativos
Preguntas frecuentes
¿Qué nivel de compatibilidad tiene con el Apache Druid real?
FerroDruid soporta la API REST de Druid, el JSON de consultas nativas y Druid SQL, y lee los segmentos v9 en disco de Apache Druid — verificado localmente con segmentos escritos por Druid 31.0.2 / 35.0.1 (los segmentos que FerroDruid escribe usan su propio formato). Cubre los ocho tipos de consultas nativas y más de 40 endpoints REST compatibles con Druid, con aproximadamente un 95% de paridad con Druid SQL principal (no el 100%). Un flujo de extremo a extremo con Apache Superset 4.1.4 — Test Connection, sincronización automática de datasets, gráficos, filtros de rango temporal, SQL Lab — está verificado contra v1.2.0, cuyas post-agregaciones multi-segmento coinciden con Apache Druid 36.0.0 en 13 de 13 casos auditados. Alcance honesto: la verificación cubre el modo single-binary; la lectura de segmentos está verificada byte a byte en disco local (contra Druid 31.0.2 y 35.0.1) y de extremo a extremo desde S3 deep storage real de AWS (un segmento de Druid 31, ida y vuelta con el mismo número de filas y conjunto de columnas); las codificaciones de segmento no predeterminadas se rechazan con errores explícitos; y el SQL con JOIN/CTE falla cerrado en lugar de ejecutarse.
¿Necesito una JVM, ZooKeeper o una base de datos de metadatos externa?
No en el modo single-binary. Un solo proceso se inicia en menos de un segundo y consume menos de 200 MB de RAM — en contraste con un clúster clásico de Druid, que necesita seis o más procesos JVM, además de ZooKeeper, una base de datos de metadatos externa y 16 GB o más de RAM. La ruta single-binary admitida utiliza SQLite para los metadatos y el sistema de archivos local para el almacenamiento profundo.
¿Puedo ejecutar una configuración multinodo?
La topología compatible es single-binary single-node; las configuraciones multinodo fallan en modo cerrado por defecto. Sinceramente, la validación en vivo se realiza contra el modo single-binary y no lo hemos validado como un clúster multinodo en ejecución en este momento. Consulte docs/KNOWN_LIMITATIONS.md para obtener más detalles.
¿Cómo se maneja la seguridad y cuál es el flujo del primer inicio de sesión?
La autenticación básica (Argon2id) y RBAC están activados por defecto, con TLS a través de rustls. En el primer inicio, la AMI genera una contraseña de administrador aleatoria única para esa instancia (nunca una predeterminada o compartida) y la escribe una vez en el registro del sistema de la instancia. La cuenta de administrador está marcada como de cambio obligatorio, por lo que cada endpoint de la API devuelve HTTP 403 hasta que el operador envía una nueva contraseña por POST a /druid-ext/basic-security/authentication/db/basic/users/admin/credential. La credencial rotada se persiste y sobrevive a los reinicios.
¿Cómo lo despliego y cómo funcionan las licencias y la facturación?
Despliéguelo con la plantilla de CloudFormation proporcionada (marketplace/cloudformation/ami.yaml) detrás de un Application Load Balancer; finalice TLS en el ALB y no exponga el puerto del servicio directamente a Internet. Apunte sus clientes (API REST, JSON de consultas nativas, Druid SQL o un conector de Apache Superset) al endpoint del balanceador de carga. Esta oferta vende una distribución endurecida, escaneada y con soporte de FerroDruid en una versión de lanzamiento fija. El código fuente está disponible bajo la Business Source License 1.1 (BUSL-1.1): puede usarlo en producción, salvo ofrecerlo a terceros como un servicio competidor de base de datos/analítica/OLAP alojado, gestionado o embebido; cada versión se convierte a la Apache License 2.0 cuatro años después de su publicación (licencias comerciales: [email protected]). La AMI es medida automáticamente por AWS por cada hora de instancia en ejecución, sin código de medición en el producto.
Por qué es más barato
Supone un backend OLAP en tiempo real con ~1k eventos/seg y respuestas de consulta sub-segundo (us-east-1).
- m5.xlarge × 3 (broker / coord / historical)
- $525 / mes
- ZooKeeper (t3.medium)
- $30 / mes
- RDS PostgreSQL metadatos
- $150 / mes
- Total mensual
- $705 / mes
- Instancia FerroDruid (m5.large + tarifa de software)
- $120 / mes
- Total mensual
- $120 / mes
Dimensionar la instancia FerroDruid según QPS de ingesta
| QPS de ingesta | Instancia recomendada | Coste de la instancia FerroDruid | Total mensual vs. clúster Druid |
|---|---|---|---|
| ~100 events/s | t3.medium | $45 / mes | $45 / mes (Druid $400, −89 %) |
| ~1k events/s | m5.large | $120 / mes | $120 / mes (Druid $705, −83 %) |
| ~10k events/s | m5.2xlarge | $400 / mes | $400 / mes (Druid $1.800, −78 %) |
Ejemplo ilustrativo. El baseline de Apache Druid ejecuta broker / coordinator / historical como JVMs separados (m5.xlarge × 3) más ZooKeeper y RDS PostgreSQL como metadatos, un despliegue mínimo típico. FerroDruid es un binario único compatible con el protocolo wire de Druid, sin ZooKeeper externo ni DB de metadatos; secure-by-default fuerza cambio de contraseña en el primer login.
Modelo de precios
Tarifa horaria de software + EC2 (clase t4g / c7g / m7g / r7g, Arm). Medición por tipo de instancia.
Otros productos S4
S4 — Squished S3
Gateway transparente de compresión S3 con GPU
S4 Logs
Archiva CloudWatch Logs en S3 con zstd
S4 Metrics
Gobierna la cardinalidad de métricas de CloudWatch