This repository is Derivitec's fork of Apache Druid. It is a full product source tree, not a thin integration layer: it contains the query engine, indexing services, SQL layer, web console, packaging logic, extension modules, documentation, integration tests, and the Kubernetes operator.

The intent of this README is to describe the repository itself: what it is for, how it is structured, what it produces, and where the ARM64-related container behavior lives.

At a high level, this repository exists to do four things:

1. Build the Druid server-side runtime from source.
2. Bundle the web console and extension set into a distributable release.
3. Produce container images and Kubernetes operator assets for deployment.
4. Carry documentation, examples, and test harnesses needed to operate and evolve the platform.

If you are reviewing this repository as part of a transaction or handover, the key point is that this is the build and packaging system for Druid itself. It is not merely environment-specific deployment manifests.

flowchart LR
  A["Core engine modules<br/>processing, server, indexing-service,<br/>indexing-hadoop, sql, multi-stage-query"] --> B["services<br/>assembled server runtime"]
  C["web-console<br/>React / TypeScript UI"] --> D["distribution<br/>release assembly"]
  E["extensions-core<br/>supported integrations"] --> D
  F["extensions-contrib<br/>optional/community integrations"] --> D
  G["cloud/*<br/>shared cloud support code"] --> D
  B --> D
  D --> H["Binary release tarball<br/>apache-druid-&lt;version&gt;-bin.tar.gz"]
  H --> I["distribution/docker/Dockerfile<br/>container image build"]
  J["druid-operator<br/>operator image + Helm chart"] --> K["Kubernetes deployment path"]
  L["docs, website, examples"] --> M["Human documentation and tutorials"]
  N["integration-tests, embedded-tests,<br/>quidem-ut, benchmarks"] --> O["Verification and performance coverage"]

The repository builds the standard Druid distributed runtime. The exact deployment shape varies by environment, but the logical architecture is:

flowchart TB
  U["Users / applications"] --> R["Router / Web console"]
  R --> B["Broker<br/>query routing"]
  B --> H["Historical<br/>segment serving"]
  B --> M["Middle Manager / Indexer<br/>task execution"]
  B --> Q["MSQ tasks<br/>distributed SQL ingestion/query work"]
  C["Coordinator / Overlord"] --> H
  C --> M
  C --> Q
  M --> K["Streaming / batch inputs"]
  Q --> K
  H --> S["Deep storage"]
  M --> S
  Q --> S
  C --> Z["Metadata store"]
  B --> Z
  H --> Z
  M --> Z

The main build is Maven-based. The root pom.xml is the aggregator for the full monorepo and currently declares version 36.0.0-SNAPSHOT.

Typical source build:

mvn clean install -Pdist,bundle-contrib-exts -DskipTests

Notes:

• JDK 11 or JDK 17 is required to build Druid.
• The distribution/ module assembles the binary release and bundles the web console.
• The release tarball is emitted under distribution/target/ as apache-druid-<version>-bin.tar.gz.

The main container build lives in distribution/docker/Dockerfile. The Docker build can either:

• build the release tarball inside Docker, or
• consume a tarball that was built beforehand with Maven.

Typical image build:

DOCKER_BUILDKIT=1 docker build -t apache/druid:tag -f distribution/docker/Dockerfile .

This repository does include ARM64-aware container packaging, but the behavior is important to understand precisely:

• The Docker builder stage is explicitly pinned to linux/amd64.
• The reason is documented in the Dockerfile itself: building the full distribution inside Docker on ARM64 is avoided because of a web-console dependency issue.
• The final runtime image is still architecture-aware and selects the correct static bash binary for amd64 or arm64.
• The documented Apple Silicon workflow is therefore:

mvn clean package -DskipTests -Pdist
DOCKER_BUILDKIT=1 docker build \
  -t apache/druid:tag \
  -f distribution/docker/Dockerfile \
  --build-arg BUILD_FROM_SOURCE=false .

So the repo currently supports ARM64 as a deployment target for the final image, while the in-Docker source-build stage remains intentionally amd64.

From an ownership and maintenance perspective, the main deliverables produced from this repository are:

• Java server artifacts for the Druid runtime.
• Bundled release tarballs.
• Docker images assembled from the release tarball.
• Web console static assets embedded in the distribution.
• Extension artifacts and dependency bundles.
• Kubernetes operator images and Helm/chart assets.

As checked on 2026-04-07:

• local HEAD matches derivitec/master
• upstream origin/master is 1 commit ahead

That means this checkout is very close to current upstream Apache Druid, but it is not identical to the latest upstream master.

For a new maintainer or buyer, the fastest orientation path is:

1. pom.xml for the module map and version line.
2. distribution/pom.xml for release assembly behavior.
3. distribution/docker/Dockerfile and distribution/docker/README.md for container packaging, including ARM64 handling.
4. druid-operator/README.md if Kubernetes operation is in scope.
5. docs/ for product-level operational and architectural documentation.

This repository remains Apache 2.0 licensed under the Apache Druid project lineage. See LICENSE, NOTICE, and README.BINARY for the applicable source and binary distribution notices.