Version note: Rebuilt September 4, 2026. Druid is an ingestion and analytical query system; model training and serving require separately designed components.
A defensible pattern uses Druid to query governed historical features and monitor scored outcomes. Training occurs offline with chronological evaluation. A versioned service scores validated feature contracts, and predictions or anomaly evidence are written to an observable store. “Real time” must be defined and measured across every stage.
Extract bounded, authenticated data
import requests
sql = """
SELECT TIME_FLOOR(__time, 'PT1H') AS hour,
SUM(metric_value) AS value
FROM telemetry
WHERE __time >= TIMESTAMP :start_time
AND __time < TIMESTAMP :end_time
GROUP BY 1
ORDER BY 1
"""
response = requests.post(
DRUID_SQL_URL,
json={"query": sql, "parameters": PARAMETERS, "resultFormat": "object"},
headers={"Authorization": AUTH_HEADER},
timeout=(5, 60),
)
response.raise_for_status()
rows = response.json()
Use an authenticated TLS endpoint, secret-backed credentials, least privilege, bounded time ranges, explicit result formats, timeouts, status handling, pagination or limits where needed, and query/resource controls. Parameter support and syntax depend on the deployed Druid version; integration-test them.
Build time-correct features
Define event time, availability time, forecast origin, horizon, label window, late-data policy, missing intervals, and entity grain. Aggregate only information available at prediction time. Version SQL, datasource, schema, transformations, and snapshots so training can be reproduced.
Evaluate without leakage
- Use chronological or rolling-origin splits, not a random split for time-dependent forecasting.
- Fit preprocessing and thresholds only on each training/reference window.
- Compare simple seasonal or persistence baselines.
- Report horizon-specific error, uncertainty, subgroup/entity results, and performance across regimes.
- Reserve later data for final assessment and document every tuning decision.
Treat anomalies as evidence
An isolation-based score or forecast residual is not proof of an incident. A fixed contamination value encodes an expected alert fraction; it is not ground truth. Define operational anomalies, calibrate thresholds on an approved reference period, and evaluate labeled events, detection delay, false positives/negatives, alert volume, and missed-event severity. Corroborate with other telemetry and human investigation.
Serve and observe
Package the preprocessing, feature contract, model, threshold, and version together. Validate inputs, authenticate callers, limit rate and permissions, log decisions with privacy controls, and provide fallback and rollback. Store event time, feature/data version, model version, score/prediction, threshold, generated time, outcome, and review disposition.
Measure event delay, Druid ingestion/queryability, feature query, model inference, result write, and consumer refresh separately. Monitor drift, missing features, latency, errors, costs, outcomes, and feedback loops; retraining remains an approved, evaluated release rather than automatic learning.
Use anomaly detection techniques, operationalize through MLOps best practices, and review the Apache Druid series summary.

Historical comments from Datanizant
No public comments on this article
No approved public comments were included in the WordPress export for this article.