Apache Doris

Redaktion: Axel Schweizer · Profil aus Herstellerangaben · kein eigener Praxistest

Apache Doris ist eine verteilte SQL-Datenbank für analytische Abfragen, die Daten aus Dateien, Streams und operativen Systemen aufnehmen kann. Für ein Dashboard mit häufigen Joins und fortlaufend korrigierten Bestellzuständen ist vor allem das Tabellenmodell entscheidend. Doris ist eine sinnvolle Pilotoption, wenn mehrere Teams gleichzeitig auf aktualisierte Daten zugreifen und du einen Cluster betreiben kannst. Bei wenigen täglichen Auswertungen genügt oft ein vorhandenes Warehouse oder eine kleinere Lösung. Dieses Profil beruht auf Apache-Dokumentation; wir haben Doris dafür nicht selbst installiert oder gemessen.

Wann Apache Doris passt – und wann nicht

Prüfe Doris, wenn ein gemeinsamer analytischer Datenbestand aus Ereignissen und änderbaren Geschäftsdaten entstehen soll: Bestellungen, Kundenmerkmale und Nutzungsereignisse werden regelmäßig geladen und von vielen Lesern per SQL ausgewertet. Doris unterstützt mehrere Tabellenmodelle, weil Append-only-Ereignisse andere Schreibregeln brauchen als per Schlüssel korrigierte Zustände. Der Nutzen hängt davon ab, dass Import, Modell und Abfrage zusammenpassen. Die Apache-Dokumentation zu Datenupdates grenzt Unique-, Duplicate- und Aggregate-Key-Tabellen ausdrücklich ab.

Ein kleineres Setup reicht, wenn ein nächtlicher Export, wenige Gigabyte und einzelne Berichte die Anforderung erfüllen. Dann vermeidet etwa DuckDB einen dauerhaften Datenbankcluster. Falls ein bestehendes Warehouse den Fall bereits abdeckt, rechne zuerst dessen Mehrkosten durch. Doris ist keine Ersatzdatenbank für transaktionale Bestellschreibvorgänge: Der Shop bleibt im OLTP-System, Doris verarbeitet eine analytische Kopie. Die Unterschiede erläutert OLAP versus OLTP; der OLAP-Vergleich ordnet Alternativen ohne Leistungsrangliste ein.

Frontend, Backend und messbare Datenfrische

Im klassischen Doris-Aufbau verwaltet das Frontend (FE) Metadaten, nimmt SQL entgegen und plant Abfragen; Backends (BE) speichern Daten und führen Arbeit aus. Für Doris 3.x beschreibt Apache daneben einen entkoppelten Modus mit Meta Service und anderen Betriebsanforderungen. Das sind verschiedene Architekturen, deren Kapazitäts- und Wiederherstellungspläne du getrennt kalkulieren musst. Die Apache-Bereitstellungsdoku nennt für den entkoppelten Modus FE, BE und Meta Service sowie FoundationDB als Abhängigkeit. Für einen ersten Pilot kann der klassische Modus übersichtlicher sein, sofern er die eigene Last erfüllt.

Apache dokumentiert in Doris 3.x mehrere Ladewege: Stream Load per HTTP, Routine Load für Kafka, Flink-Konnektor für Streams sowie Batchimporte. „Nahe Echtzeit“ entsteht aus diesem gesamten Pfad. Messe Quellzeit, Kafka-Offset beziehungsweise CDC-Position, erfolgreiches Load-Commit, Query-Sichtbarkeit und Antwortzeit separat. Ein erfolgreicher SQL-Query beweist nicht, dass der Stream aktuell ist. Setze Fehlerschwellen für Importfehler und Rückstand und prüfe die Behandlung verspäteter Daten. Die Dokumentation beschreibt jeden Import standardmäßig als implizite Transaktion; daraus folgt keine Ende-zu-Ende-Garantie vom Quellsystem bis zum Dashboard.

Parallelität ist ebenfalls ein Betriebswert statt ein Produktetikett. Die Workload Groups können Ressourcen und Query-Gleichzeitigkeit begrenzen; Warteschlangen und Timeout müssen bewusst gesetzt werden. Die Apache-Dokumentation weist darauf hin, dass eine Isolation innerhalb eines BE-Prozesses andere Abfragen nicht vollständig vor Einfluss schützt. Teste deshalb einen teuren Fach-Join und viele kurze Dashboard-Queries zugleich und beobachte Antwortzeit, Speicher, Warteschlange und Ablehnungen.

Tabellenmodell, SQL und Joins vor dem Import festlegen

Bei Doris 3.x ist das Duplicate-Key-Modell für angehängte Ereignisse geeignet: gleiche Schlüssel können mehrfach vorkommen. Das Unique-Key-Modell bildet den aktuellen Zustand je Schlüssel ab und unterstützt Upserts, partielle Updates und Löschungen. Das Aggregate-Key-Modell fasst Zeilen anhand gewählter Aggregationsfunktionen zusammen. Ein Ereignisprotokoll mit jeder historischen Änderung gehört nicht unbesehen in eine Unique-Key-Tabelle, weil diese alte Zustände logisch ersetzt. Bewahre bei Bedarf Rohereignisse separat auf. Apache: Modelle und Änderungswege.

Doris unterstützt SQL-Joins, darunter INNER-, LEFT- und RIGHT-JOIN. Damit kannst du Bestellereignisse mit einer Kundendimension verbinden, ohne jedes Merkmal im Ereignis zu duplizieren. Die Join-Dokumentation beschreibt die Syntax; sie garantiert keine Antwortzeit für einen großen Many-to-many-Join. Definiere Kardinalitäten, Filter, Datenverteilung und ein erwartetes Ergebnis, bevor du eine Query abnimmst. Für wiederkehrende aggregierte Sichten kann ein OLAP-Modell fachlich einfacher sein als jeder Bericht mit einem neuen Join.

CDC: Reihenfolge, Updates und Löschung

Für das Unique-Key-Modell ist seit Doris 2.1 Merge-on-Write standardmäßig vorgesehen: neue Versionen eines Schlüssels werden beim Schreiben aufgelöst. Eine spätere Query soll den gültigen Zustand sehen, doch die Reihenfolge eintreffender Nachrichten bleibt dein Problem. Konfiguriere für außer der Reihenfolge eintreffende CDC-Ereignisse eine belastbare Sequence-Spalte, etwa eine monotone Quellposition. Sonst kann ein verspäteter alter Zustand einen neueren überschreiben. Eine Quellzeit mit gleichen oder rückdatierten Werten reicht dafür nicht zuverlässig. Apache: Unique Key und Sequence.

Volle Upserts ersetzen die Zeile; partielle Spaltenupdates im Unique-Key-Merge-on-Write-Modell sind seit Version 2.0 dokumentiert, müssen aber je Ladeweg aktiviert werden. Bei Stream Load geschieht das über partial_columns, bei INSERT INTO über eine Sessionvariable. Fehlende Spalten behalten dann ihren bisherigen Wert. Für CDC ist besonders wichtig, ob ein fehlendes Feld „unverändert“ oder „bewusst NULL“ bedeutet. Diese Semantik muss im Payload und Mapping eindeutig sein. SQL-UPDATE und DELETE sind ebenfalls vorhanden; die Apache-Empfehlung sieht hochfrequente Änderungen eher als gebündelte Ingestion statt als viele einzelne DML-Transaktionen.

Ein CDC-Delete kann im Unique-Key-Modell über einen Löschmarker, __DORIS_DELETE_SIGN__, angeliefert werden. Doris blendet die Zeile aus der aktuellen Sicht aus; die physische Bereinigung läuft über Compaction. Alternativ kann DELETE Bedingungen ausführen. Das ist noch kein vollständiger Nachweis für eine rechtliche Löschung: Kopien, Backups, Quellstream, Aufbewahrung und Wiederherstellung müssen zum Löschkonzept passen. Prüfe bei Replay, dass ein alter Upsert den Löschstand nicht zurückdreht. Apache: Löschpfade.

Lizenz, Gesamtkosten und Zugriffsgrenzen

Apache Doris steht im Projekt-Repository unter der Apache License 2.0. Das selbst betriebene Open-Source-System hat keine Lizenzgebühr pro Leser. Bezahlt werden Infrastruktur und Arbeit: FE/BE beziehungsweise Meta Service, Speicher samt Replikation, CDC-/Kafka-Betrieb, Netzwerk, Backups, Monitoring und Upgrades. Ein kommerziell gehosteter Doris-Dienst ist ein gesonderter Vertrag mit eigener Preisliste und eigenen Regionsbedingungen. Setze für den Vergleich eine Lastannahme an: gespeicherte und täglich geänderte Daten, parallele Leser, Replikationsfaktor, Aufbewahrung und Wiederherstellungsziel. Ohne diese Größen ist „kostenlos“ keine Kostenprognose.

Die Doris-3.x-Dokumentation zu Authentifizierung und Berechtigungen beschreibt Nutzer, Rollen, Tabellen- und Spaltenrechte sowie Row Policies. Rechte müssen pro Datenpfad abgenommen werden: Leserkonto, Schreibkonto, Administrationskonto und verwendete externe Datenquellen. Für Mandantentrennung teste ausdrücklich eine Abfrage mit fremder tenant_id; ein Dashboard-Filter allein ist kein Zugriffsschutz. Open Source legt weder Hosting-Ort noch Supportregion fest. Für EU-Daten gehören Cluster, Kafka, Backups, Logs und externe Dienste in dieselbe Datenflussprüfung.

Synthetischer Event-/CDC-Fall als Abnahmematrix

Gemeinsamer synthetischer Sollfall, kein Produkttest: Der Schlüssel ist (tenant, id); seq steigt je Schlüssel. Zuerst stehen (nord,1) = 100 EUR, (nord,2) = 200 EUR und (sued,1) = 300 EUR: drei Zeilen und 600 EUR. Danach folgen (nord,1) mit seq=2 und 120 EUR, (nord,2) als Delete mit seq=2, (nord,3) neu mit 80 EUR sowie (sued,1) mit seq=2 und 350 EUR trotz älterer Ereigniszeit. Ein altes (nord,1,seq=1)-Ereignis folgt im Paket. Soll: nur (nord,1), (nord,3) und (sued,1), insgesamt 550 EUR (Nord 200 EUR, Süd 350 EUR). Ein exakter Replay ändert nichts; ein Tombstone muss (nord,2) vor einem später erneut gesendeten alten Ereignis schützen. Für Doris ist die aktuelle Sicht als Unique-Key-Tabelle mit zusammengesetztem Schlüssel und Sequence-Spalte nachzuweisen; die Rohereignisse können getrennt im Duplicate-Key-Modell liegen. Die gemeinsame OLAP-Prüfvorlage enthält Eingaben, Sollwerte und leere Ergebnisfelder.

Prüfe jede ID, Sequenz und jeden Betrag einzeln. Die Summe kann trotz einer fehlenden und einer doppelt gezählten Zeile zufällig stimmen. Das gemeinsame OLAP-Prüfpaket gibt den Fall zur eigenen Durchführung vor. Ergebnisse oder Leistungswerte für Doris liegen hier nicht vor. Für andere Betriebsprofile siehe Apache Pinot, ClickHouse und DuckDB.

Quellenstand und nächster Schritt

Quellenstand: 26.10.2026. Die Produktclaims beruhen auf Apache-Doris-3.x-Dokumentation zu Ladewegen, Update und Delete, Joins, Workload Groups, Rechten und dem Repository-Lizenztext. Konkrete Konfigurationsnamen und Verhalten sind mit der später gewählten Releaseversion zu bestätigen. Herstellerangaben sind keine eigene Lastprüfung; die BIS-Methodik erläutert die Trennung.

Wenn Doris in die engere Wahl kommt, beginne mit dem Tabellenmodell und dem Lösch-/Sequenzpfad. Danach miss Join-Queries und gleichzeitige Leser am synthetischen Fall. Für Auswahl und Einrichtung bietet die Schwesterseite BIC eine BI-Beratung an. BIS und BIC werden von Axel Schweizer betrieben; das wirtschaftliche Interesse ist unter Finanzierung erläutert.