Practical Experience with Druid SQL and Security at Meituan: Challenges, Improvements, and Best Practices

Meituan has been using Apache Druid since 2016, operating two clusters with over 70 nodes, more than 500 tables, 100 TB of storage, and handling over 17 million queries per day, achieving sub‑second latency for the majority of workloads.

The deployment faced three main challenges: usability (high learning curve of JSON‑based queries), security (lack of authentication and authorization in early versions), and stability (handling schema changes and multi‑tenant troubleshooting).

Druid SQL, introduced in version 0.10, provides a translation layer from standard SQL to native JSON queries, offering HTTP and JDBC interfaces, automatic query type selection, and support for common patterns such as approximate TopN, semi‑joins, and nested GroupBy.

The architecture places the SQL layer inside the Broker, using Calcite for parsing and logical optimization, and a Server module for request handling. Improvements include optimizing schema inference by limiting the segment window, adding detailed request logging with unique sqlQueryId, and enforcing time‑range filters to prevent full‑table scans.

Security enhancements in versions 0.11/0.12 added TLS, extensible authentication (Basic, Kerberos) and role‑based access control. Meituan extended this with DB‑level access control, automated DB‑to‑DataSource mapping, and a custom SSO filter to support both authenticated and unauthenticated access.

Deployment guidelines recommend using Druid 0.13+, enabling basic‑security with an allow‑all fallback, initializing the permission DB, and gradually tightening permissions while following a specific node upgrade order.

The conclusion emphasizes that Druid SQL is a lightweight translation layer with minimal performance impact, that security features are mature but require careful configuration, and that large‑scale schema inference and broker startup times remain areas to monitor.