Apache Doris: MPP-Analytik, Lakehouse-Abfragen und Hybridsuche in einer Engine
Apache Doris ist eine Echtzeitanalyse- und Hybridsuchdatenbank für KI-Agenten.
Auf einen Blick
- Was ist das?
- Apache Doris ist eine freie Echtzeit-Analysedatenbank auf MPP-Basis, die SQL über offene Tabellenformate und zugleich Suche über JSON, Volltext und Vektoren anbietet. Der Text ordnet Anwendungsfälle, Bereitstellungsmodi, Konnektoren, die beiden Release-Linien und den Lizenzvorbehalt ein.
- Für wen ist es gedacht?
- Doris passt zu Teams, die interaktive Analysen im Subsekundenbereich an externe Nutzer ausliefern oder Log- und Ereignisdaten in hohem Durchsatz per SQL auswerten wollen, und zu solchen, die Vektor- und Volltextsuche nicht als zweites System betreiben möchten.
- Darf ich es kommerziell nutzen?
- Ja. Apache-2.0 ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Das Repository hat innerhalb des letzten Tages neue Commits erhalten.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Java, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Was Doris unter MPP-Analyse und Hybridsuche versteht
Doris beschreibt sich als freie Datenbank für Echtzeitanalyse und Suche, aufgebaut auf einer MPP-Architektur. Das Repository apache/doris führt Java als Hauptsprache, steht unter Apache-2.0 und entwickelt auf dem Branch master. Der letzte aufgezeichnete Push stammt vom 14. August 2026. Die Kurzbeschreibung in den Metadaten spitzt das auf eine Echtzeit-Analyse- und Hybridsuchdatenbank für KI-Agenten zu.
Drei Leistungen stehen im Mittelpunkt. Geboten werden schnelle SQL-Analysen, beschleunigte Abfragen auf Lakehouse-Beständen und Hybridsuche über strukturierte Daten, Text und Vektoren. Diese Kombination ist der Kern des Ansatzes: Nicht drei Systeme für drei Datensorten, sondern eine Engine.
Zum Versionsstand fällt eine Besonderheit auf. Am 14. August 2026 erschien 4.0.8, am 13. Juli 2026 bereits 4.1.3 und am 12. Juli 2026 die 4.0.7. Beide Linien werden also parallel gepflegt, und die jüngere Veröffentlichung trägt die niedrigere Hauptversionsnummer. Wer eine Linie wählt, sollte das anhand der Release-Notizen unter doris.apache.org/releases/all-release tun und nicht nach der Zahl.
Vier Anwendungsfälle von Kundenanalytik bis Observability
Das README fasst den Einsatzbereich in vier Fälle. Kundenorientierte Analytik bedeutet, externen Nutzern interaktive Auswertungen im Subsekundenbereich zu liefern, also Analysen als Teil eines eigenen Produkts. Data Warehousing zielt auf ein einziges Echtzeit-Warehouse über Geschäftsbereiche hinweg.
Der dritte Fall ist Beobachtbarkeit: Logs, Ereignisse und Kennzahlen mit hohem Durchsatz per SQL auswerten. Das ist eine Ansage gegen getrennte Spezialsysteme für Metriken und für Logs, und sie ist für Betriebsteams die interessanteste Zeile der Tabelle.
Der vierte Fall heißt Doris for AI und bündelt Vektor-, Text-, JSON- und Struktursuche in einer SQL-Engine. Wer heute eine Ähnlichkeitssuche über Einbettungen aufbauen will und dafür ein zweites System einführt, findet hier den Versuch, diesen Schritt einzusparen. Wie gut die Vektorsuche im Vergleich zu einem darauf spezialisierten Speicher arbeitet, sagt das Material nicht; es nennt keine Messwerte.
Iceberg, Delta Lake und Hudi unter einer SQL-Oberfläche
Die drei Kernfähigkeiten sind im README sauber getrennt. Echtzeitanalyse umfasst die Aufnahme aus Strömen, inkrementelle Umwandlung und Abfragen im Subsekundenbereich unter hoher Parallelität. Lakehouse-Analytik bietet SQL über offene Tabellenformate, namentlich Iceberg, Delta Lake und Hudi. Hybridsuche erlaubt SQL-native Auswertung über JSON, Volltext und Vektordaten.
Für Bestandslandschaften ist der mittlere Punkt der wichtige. Daten liegen heute häufig in einem offenen Tabellenformat in Objektspeicher, und die Frage ist, welche Engine darauf zugreift. Doris beansprucht diese Rolle selbst, womit ein zusätzlicher Kopiervorgang in ein eigenes Format entfällt.
An dieser Stelle setzt das README eine Grenze, die man ernst nehmen sollte: Als Quelle der Wahrheit für detaillierte Produktbeschreibungen und Beispiele nennt es ausdrücklich die Website. Die Tabelle im Repository ist eine Übersicht, keine Spezifikation. Wer wissen will, welche Operationen auf welchem Format unterstützt werden, muss in die Dokumentation.
Gekoppelte und entkoppelte Bereitstellung im Doris-Cluster
Bei der Architektur nennt das README zwei Bereitstellungsarten: gekoppelt und entkoppelt, bezogen auf das Verhältnis von Rechenleistung und Speicher. Im entkoppelten Betrieb laufen zustandslose Rechengruppen über gemeinsam genutztem Objektspeicher. Das erlaubt, Rechenleistung bei Bedarf zu skalieren und Arbeitslasten voneinander zu trennen.
Diese Wahl ist keine Formalie. Gekoppelt bedeutet, dass Speicher und Rechenleistung zusammen wachsen, was bei ungleichen Anforderungen teuer wird. Entkoppelt erlaubt es, eine Analysegruppe hochzufahren und danach wieder abzubauen, ohne Daten zu bewegen, verlagert aber die Abhängigkeit auf den Objektspeicher.
Weiter in die Interna geht das Material nicht. Es beschreibt weder Abfrageplanung noch Speicherlayout noch Replikation und verweist stattdessen auf einen Bereitstellungsleitfaden und einen Leitfaden zur Wahl des Bereitstellungsmodus. Installationsbefehle enthält das README keine; es verlinkt auf Schnellstart, Download, Installation und den Bau aus dem Quellcode.
Flink-, Spark- und Kafka-Konnektor sowie der Kubernetes-Operator
Für den Anschluss an bestehende Landschaften listet das README fünf Komponenten. Der Doris Flink Connector bindet Flink-Streams an, der Doris Spark Connector entsprechend Spark, der Doris Kafka Connector liest aus Kafka. Hinzu kommen der Doris Stream Loader für das Laden von Datenströmen und der Doris Kubernetes Operator für den Betrieb auf Kubernetes.
Die Einordnung im README ist aufschlussreich: Doris versteht sich als Mitte eines Datenstapels, die vorgelagerte Datenbanken, Streamingsysteme und Lakehouse-Speicher mit nachgelagerten Werkzeugen für BI, KI, Analyse und Beobachtbarkeit verbindet. Damit ist die Datenbank ausdrücklich nicht als alleiniger Speicher gedacht.
Was die Konnektoren im Einzelnen leisten, steht nicht im Material. Unterstützte Versionen, Konfigurationsoptionen und Installationsschritte sind hier nicht belegt und müssen in der jeweils verlinkten Dokumentation nachgelesen werden. Wer einen Konnektor in Produktion nimmt, kommt an dieser Lektüre nicht vorbei.
Nicht Apache-2.0-kompatible Abhängigkeiten in thirdparty/LICENSE.txt
Ein Hinweis im README verdient mehr Aufmerksamkeit, als ihm üblicherweise zuteil wird. Doris steht unter der Apache License 2.0, aber einige Lizenzen der mitgelieferten Drittanbieter-Abhängigkeiten sind damit nicht vereinbar. Bestimmte Funktionen müssen deshalb abgeschaltet werden, um die Apache-2.0-Lizenz einzuhalten. Die Einzelheiten liegen in der Datei thirdparty/LICENSE.txt.
Die praktische Folge ist eine Prüfpflicht vor dem Einsatz. Wer eine Funktion nutzt, die auf einer solchen Abhängigkeit beruht, bewegt sich außerhalb der reinen Apache-2.0-Verteilung. Für Unternehmen mit eigener Lizenzprüfung ist das keine Nebensache, sondern eine Aufgabe für die Rechtsabteilung und nicht für diesen Text.
Zur Projektgeschichte nennt das Material den Weg durch den Apache-Inkubator und die Erhebung zum Top-Level-Projekt im Juni 2022. Die Gemeinschaft arbeitet über GitHub Issues, Discussions und Pull-Requests, veröffentlicht einen wöchentlichen Gemeinschaftsbericht und diskutiert den Fahrplan 2026 im Issue 60036, gegliedert in KI und Hybridsuche, Abfrage-Engine, Speicher und Data-Lake-Arbeit. Kontakt läuft über Slack und eine Entwickler-Mailingliste.
Release-Linien 4.0 und 4.1, und wo Doris die falsche Wahl ist
Zur Verbreitung behauptet das README den produktiven Einsatz bei Tausenden Unternehmen weltweit, über Branchen von Internetdiensten über Finanzen und Einzelhandel bis Energie und Telekommunikation. Konkrete Namen nennt es nicht, Betriebe können sich über einen Diskussionsfaden selbst eintragen. Die Angabe ist eine Selbstauskunft und ohne überprüfbare Unterlage.
Als falsches Werkzeug ist Doris dort zu nennen, wo transaktionale Last im Vordergrund steht. Die eigene Beschreibung spricht von Analyse und Suche, nicht von Buchungssystemen. Wer viele kleine Schreibzugriffe mit Transaktionsgarantie braucht, sucht etwas anderes. Ein zweiter Fall ist ein Team ohne Kapazität für den Betrieb einer verteilten Datenbank; die beiden Bereitstellungsmodi bringen Freiheit, aber auch Entscheidungszwang.
Die Alternative liegt in der Aufteilung, die Doris gerade vermeiden will: ein offenes Tabellenformat im Objektspeicher, abgefragt von einer eigenen Engine, dazu ein zweites System für Volltext und Vektoren. Der Unterschied zur gebündelten Fassung ist der Aufwand an Schnittstellen und Datenabgleich gegen den Gewinn, pro Teilaufgabe das spezialisiertere Werkzeug zu haben. Das Material nennt keine Vergleichsprodukte; welche Namen dafür in Frage kommen, müsste außerhalb des Repositories recherchiert werden.
Redaktionelles Fazit
Doris passt zu Teams, die interaktive Analysen im Subsekundenbereich an externe Nutzer ausliefern oder Log- und Ereignisdaten in hohem Durchsatz per SQL auswerten wollen, und zu solchen, die Vektor- und Volltextsuche nicht als zweites System betreiben möchten. Es passt nicht für transaktionale Arbeitslasten, weil die Beschreibung des Projekts ausdrücklich von Analyse und Suche spricht, und nicht für Vorhaben, bei denen schon der Einstieg belastbare Vergleichszahlen verlangt, denn das Material nennt keine einzige Messung. Vor einer Entscheidung sollten der Bereitstellungsmodus nach dem Leitfaden unter doris.apache.org gewählt und die betroffenen Funktionen gegen thirdparty/LICENSE.txt geprüft werden, weil dort die Abhängigkeiten stehen, die unter Apache-2.0 abgeschaltet werden müssen.
Community-Notizen