Die Apache Doris 2.0.0-Version wird offiziell veröffentlicht: 10-fache Verbesserung der Blindtestleistung, einheitlicheres und vielfältigeres, extrem schnelles Analyseerlebnis

Liebe Community-Freunde, wir freuen uns, Ihnen mitteilen zu können, dass Apache Doris Version 2.0.0 am 11. August 2023 offiziell veröffentlicht wurde und mehr als 275 Mitwirkende mehr als 4.100 Optimierungen und Korrekturen für Apache Doris eingereicht haben .

In Version 2.0.0 hat Apache Doris die Blindtest-Abfrageleistung gegenüber dem Standard-Benchmark-Datensatz um mehr als das Zehnfache verbessert, seine Fähigkeiten in Protokollanalyse- und Data-Lake-Föderationsanalyseszenarien vollständig erweitert und die Datenaktualisierungs- und Schreibeffizienz verbessert. Es ist stabil und unterstützt einen umfassenderen Mandantenfähigkeits- und Ressourcenisolationsmechanismus. Es hat eine neue Ebene in Richtung Ressourcenelastizität und Trennung von Speicher und Computer erreicht und eine Reihe benutzerfreundlicher Funktionen für Unternehmen hinzugefügt Benutzer. Nach fast einem halben Jahr Entwicklung, Tests und Stabilitätsoptimierung ist diese Version offiziell verfügbar und stabil. Sie können sie gerne herunterladen und verwenden.

GitHub-Download:

https://github.com/apache/doris/releases/tag/2.0.0-rc04

Offizielle Download-Seite der Website:

https://doris.apache.org/download

Veröffentlichungshinweis:

https://github.com/apache/doris/issues/22647

Die Leistung des Blindtests verbesserte sich um mehr als das Zehnfache

In Version 2.0.0 von Apache Doris haben wir einen neuen Abfrageoptimierer und ein adaptives paralleles Ausführungsmodell eingeführt, kombiniert mit einer Reihe von Leistungsoptimierungsmethoden auf der Speicherschicht, der Ausführungsschicht und dem Ausführungsoperator, um mehr als das Zehnfache des Blinds zu erreichen Verbesserung der Testleistung . Am Beispiel der SSB-Flat- und TPC-H-Standardtestdatensätze ist die Blindtestleistung der neuen Version unter derselben Cluster- und Maschinenkonfiguration 10-mal höher als die der Vorgängerversion für Szenarien mit breiten Tabellen und 13-mal höher für Assoziationsszenarien mit mehreren Tabellen. Es wurde ein enormer Leistungssprung erzielt.

01 Intelligenterer neuer Abfrageoptimierer

Der neue Abfrageoptimierer verwendet ein fortschrittlicheres Cascades-Framework, verwendet umfangreichere statistische Informationen und realisiert eine intelligentere adaptive Optimierung. In den meisten Szenarien kann die ultimative Abfrageleistung ohne Optimierung und SQL-Umschreiben erreicht werden und unterstützt gleichzeitig umfassendere Komplexität SQL und kann alle 99 SQLs von TPC-DS vollständig unterstützen. Mit dem neuen Abfrageoptimierer können wir die Herausforderungen realerer Geschäftsszenarien meistern, den durch manuelle Optimierung verursachten Personalverbrauch reduzieren und wirklich zur Verbesserung der Geschäftseffizienz beitragen.

Am Beispiel von TPC-H übertrifft der neue Optimierer ohne manuelle Optimierung und SQL-Umschreibung bei den meisten SQLs immer noch die Leistung des alten Optimierers nach manueller Optimierung! In realen Geschäftsszenarien, in denen mehr als Baijia 2.0-Benutzer zuvor erfahrene Benutzer waren, wurde jedoch die ursprüngliche SQL-Ausführungseffizienz größtenteils erheblich verbessert.

Referenzdokument: https://doris.apache.org/zh-CN/docs/dev/query-acceleration/nereids

So aktivieren Sie: SET enable_nereids_planner=trueDer neue Abfrageoptimierer wurde in Apache Doris 2.0.0 standardmäßig aktiviert

02 Invertierte Indexunterstützung

In Version 2.0.0 haben wir die vorhandene Indexstruktur bereichert und einen invertierten Index eingeführt, um den Anforderungen des mehrdimensionalen schnellen Abrufs gerecht zu werden. Er hat bemerkenswerte Ergebnisse in Szenarien wie Schlüsselwort-Fuzzy-Abfrage, äquivalenter Abfrage und Bereichsabfrage erzielt. Bezeichnenderweise verbesserte Abfrageleistung und Parallelität.

Nehmen Sie hier als Beispiel das Benutzerverhaltensanalyseszenario eines führenden Mobiltelefonherstellers. In der vorherigen Version ist der Trend zum Leistungsabfall mit der Zunahme der Parallelität und dem allmählichen Anstieg des Abfragezeitverbrauchs offensichtlicher. Nachdem jedoch der invertierte Index in Version 2.0.0 aktiviert wurde, bleibt die Abfrageleistung mit zunehmender Parallelität auf dem Millisekunden-Niveau. Bei gleicher Abfrageparallelität verbessert Version 2.0.0 die Leistung gleichzeitiger Abfragen in diesem Benutzerverhaltensanalyseszenario um das 5- bis 90-fache!

03 Die Fähigkeit zur Abfrage-Parallelität wird um das 20-fache erhöht

In Datenbereitstellungsszenarien wie der Abfrage von Banktransaktionsseriennummern, der Abfrage von Policen von Versicherungsagenten, der Abfrage historischer E-Commerce-Bestellungen und der Abfrage von Express-Frachtbriefnummern muss eine große Anzahl von Geschäftsmitarbeitern an vorderster Front und C-End-Benutzern das Ganze abrufen Datenreihe basierend auf der Primärschlüssel-ID. Gleichzeitig werden in Szenarien wie Benutzerporträts und Echtzeit-Risikokontrolle auch groß angelegte programmatische Abfragen von Maschinen auftreten. In der Vergangenheit erforderten solche Anforderungen häufig die Einführung von KV-Systemen wie Apache HBase zur Verarbeitung von Punktabfragen und Redis als Cache-Schicht zur gemeinsamen Nutzung hoher Parallelität. Kommender Systemdruck.

Für Apache Doris, das auf einer spaltenbasierten Speicher-Engine basiert, wird diese Art von Punktabfrage die zufälligen Lese-E/A für Hunderte von spaltenweiten Tabellen verstärken, und der Abfrageoptimierer und die Ausführungs-Engine werden auch Schwierigkeiten haben, solch einfaches SQL zu analysieren und zu verteilen unnötiger zusätzlicher Overhead, und das für die SQL-Analyse verantwortliche FE-Modul wird oft zu einem Engpass, der die Parallelität einschränkt, sodass eine effizientere und präzisere Ausführungsmethode erforderlich ist.

In Version 2.0.0 von Apache Doris haben wir einen brandneuen Zeilen-Spalten-Hybridspeicher und Cache auf Zeilenebene eingeführt, der das gleichzeitige Lesen der gesamten Datenzeile effizienter macht und die Anzahl der Festplattenzugriffe erheblich reduziert. und führt die Punktabfrage-Kurzpfadoptimierung ein, springt durch die Ausführungs-Engine und verwendet direkt den schnellen und effizienten Lesepfad, um die erforderlichen Daten abzurufen, und führt die Wiederverwendung vorbereiteter Anweisungen zum Ausführen der SQL-Analyse ein, um den FE-Overhead zu reduzieren.

Durch die oben genannte Reihe von Optimierungen konnte die Apache Doris 2.0.0-Version die Parallelitätsfähigkeiten um eine Größenordnung verbessern und eine Einzelknoten-Parallelitätsleistung von 30.000 QPS erreichen, was mehr als 20-mal höher ist als die Parallelitätsfähigkeiten bei Punktabfragen der Vorgängerversion !

Basierend auf den oben genannten Funktionen kann Apache Doris die Anforderungen von Datendienstszenarien mit hoher Parallelität besser erfüllen, die Funktionen von HBase in solchen Szenarien ersetzen und die Wartungskosten und die redundante Speicherung von Daten reduzieren, die durch komplexe Technologie-Stacks verursacht werden.

Referenzartikel: Interpretation der Funktionen für hohe Parallelität von Apache Doris 2.0, Abfrage-Parallelität um das 20-fache erhöht, Zehntausende QPS pro Knoten

04 Adaptives paralleles Ausführungsmodell

Während wir uns der extrem schnellen Analyseerfahrung bewusst waren, haben wir in Version 2.0.0 das Pipeline-Ausführungsmodell als Abfrageausführungs-Engine eingeführt, um die Ausführungseffizienz mehrerer gemischter Analyselasten und die Stabilität der Abfrage sicherzustellen. In der Pipeline-Ausführungs-Engine wird die Ausführung der Abfrage durch Daten gesteuert, um den Kontrollfluss zu ändern. Der Blockierungsoperator in jedem Abfrageausführungsprozess ist in verschiedene Pipelines aufgeteilt. Ob jede Pipeline die Ausführung der Ausführungsthread-Planung erhalten kann, hängt von den Vordaten ab Unabhängig davon, ob es bereit ist oder nicht, realisiert es die Asynchronisierung blockierender Vorgänge, verwaltet Systemressourcen flexibler, reduziert den durch häufiges Erstellen und Zerstören von Threads verursachten Overhead und verbessert die CPU-Auslastungseffizienz von Apache Doris. Daher wurden die Abfrageleistung und Stabilität von Apache Doris in gemischten Lastszenarien umfassend verbessert. Referenzdokument: https://doris.apache.org/zh-CN/docs/dev/query-acceleration/pipeline-execution-engine

wie Öffnen Set enable_pipeline_engine = true

• Diese Funktion ist in Apache Doris 2.0.0 standardmäßig aktiviert, und BE ändert das SQL-Ausführungsmodell standardmäßig in den Pipeline-Ausführungsmodus, wenn die Abfrageausführung ausgeführt wird.
• parallel_pipeline_task_numEs stellt die Anzahl gleichzeitiger Pipeline-Aufgaben für SQL-Abfragen dar. Apache Doris ist standardmäßig konfiguriert 0. Zu diesem Zeitpunkt erkennt Apache Doris automatisch die Anzahl der CPU-Kerne jedes BE und stellt die Parallelität auf die Hälfte der Anzahl der CPU-Kerne ein. Benutzer können sie auch entsprechend ihrer tatsächlichen Situation anpassen.
• Für Benutzer, die ein Upgrade von älteren Versionen durchführen, wird dieser Parameter automatisch auf parallel_fragment_exec_instance_numden Wert in der älteren Version gesetzt.

Einheitlichere und vielfältigere Analyseszenarien

Als OLAP-System, das ursprünglich im Berichtsanalyseszenario geboren wurde, hat Apache Doris das Nonplusultra in diesem Fachgebiet erreicht. Mit seiner hervorragenden Analyseleistung und minimalen Benutzererfahrung wurde es von vielen Benutzern anerkannt. Beispielsweise Echtzeit-Kanban ( Dashboard), Echtzeit-Berichtsszenarien wie Echtzeit-Großbildschirme, Geschäftsberichte und Management-Cockpits sowie spontane Abfrageszenarien wie Self-Service-BI-Plattformen und Benutzerverhaltensanalysen sind weit verbreitet.

Mit der raschen Ausweitung des Benutzerumfangs hoffen immer mehr Benutzer, Apache Doris zu verwenden, um den vorhandenen Technologie-Stack für umfangreiche Daten zu vereinfachen und die durch mehrere Systeme verursachten Nutzungs-, Betriebs- und Wartungskosten zu senken. Daher erweitert Apache Doris auch ständig die Grenzen von Anwendungsszenarien, von typischen OLAP-Szenarien wie Echtzeitberichten und Ad-hoc in der Vergangenheit bis hin zu mehr Geschäftsszenarien wie der Integration von Seen und Lagern, ELT/ETL, Protokollabruf usw Analyse und Datenbereitstellung mit hoher Parallelität. Die Protokollabrufanalyse und die Integration von Lake und Warehouse sind ebenfalls wichtige Durchbrüche in der neuesten Version von Apache Doris.

01 Eine Plattform zum Abrufen und Analysieren von Protokollen, die mehr als zehnmal kostengünstiger ist

In Version 2.0.0 von Apache Doris bieten wir native halbstrukturierte Datenunterstützung, fügen komplexe Typ-Map auf der Grundlage von vorhandenem JSON und Array hinzu und implementieren Schema Evolution basierend auf der Funktion von Light Schema Change. Gleichzeitig haben der neu eingeführte invertierte Index und der leistungsstarke Textanalysealgorithmus in Version 2.0.0 die Fähigkeiten von Apache Doris in Protokollabruf- und Analyseszenarien umfassend gestärkt und können eine effizientere Analyse beliebiger Dimensionen und Volltextabruf unterstützen . Die neue Generation der auf Apache Doris basierenden Plattform zum Abrufen und Analysieren von Protokollen kombiniert die bisherigen Vorteile beim Schreiben großer Datenmengen und der kostengünstigen Speicherung im Vergleich zu branchenüblichen Protokollanalyselösungen und hat eine mehr als zehnfache Kosten-Leistungs-Verbesserung erzielt.

02 Integrierter See und Lager

In Version 1.2 von Apache Doris haben wir die Multi-Catalog-Funktion eingeführt, die die automatische Metadatenzuordnung und Synchronisierung mehrerer heterogener Datenquellen unterstützt und eine praktische Metadaten- und Datenverbindung realisiert. In Version 2.0.0 haben wir die Datenföderationsanalysefähigkeit weiter verbessert, mehr Datenquellen eingeführt und viele Leistungsoptimierungen für die tatsächliche Produktionsumgebung der Benutzer vorgenommen, und die Abfrageleistung wurde unter realen Arbeitslastbedingungen erheblich verbessert.

In Bezug auf Datenquellen unterstützt Apache Doris Version 2.0.0 die Snapshot-Abfrage der Hudi-Copy-on-Write-Tabelle und die Read Optimized Query der Merge-on-Read-Tabelle. Bisher wurden Hive, Hudi und Iceberg unterstützt , Paimon, MaxCompute, Dutzende Datenquellen wie Elasticsearch, Trino und ClickHouse unterstützen fast alle Open-Lake-Warehouse-Formate und Metastores. Gleichzeitig unterstützt es auch die Authentifizierung des Hive-Katalogs über Apache Range, der sich nahtlos mit dem vorhandenen Berechtigungssystem des Benutzers verbinden kann. Gleichzeitig unterstützt es auch erweiterbare Authentifizierungs-Plug-ins, um benutzerdefinierte Authentifizierungsmethoden für jeden Katalog zu implementieren.

In Bezug auf die Leistung verwenden Sie das eigene effiziente verteilte Ausführungsframework, die vektorisierte Ausführungs-Engine und den Abfrageoptimierer von Apache Doris in Kombination mit der Leseoptimierung für kleine Dateien und große Tabellen in Version 2.0, dem lokalen Dateicache und der Effizienzoptimierung beim Lesen von ORC/Parquet-Dateien. Dank der elastischen Rechenknoten und der Statistikerfassung kann Apaceh Doris im TPC-H-Szenario externe Hive-Tabellen abfragen, und die Leistung beim Abfragen externer Hive-Tabellen ist drei- bis fünfmal höher als die von Presto/Trino .

Durch diese Reihe von Optimierungen wurde die Fähigkeit von Apache Doris zur Integration von Seen und Lagerhäusern erheblich erweitert, und seine hervorragenden Analysefunktionen können in den folgenden Szenarien besser genutzt werden:

• Lake Warehouse-Abfragebeschleunigung : Bietet hervorragende Abfragebeschleunigungsfunktionen für Data Lakes, Elasticsearch und verschiedene relationale Datenbanken und erreicht eine mehrfache Leistungsverbesserung im Vergleich zu Abfrage-Engines wie Hive, Presto und Spark.
• Datenimport und -integration : Basierend auf dem erweiterbaren Verbindungsframework werden die Funktionen von Apache Doris bei der Datenintegration erweitert, sodass Daten bequemer genutzt und verarbeitet werden können. Benutzer können über Apache Doris eine einheitliche inkrementelle und vollständige Synchronisierung verschiedener Upstream-Datenquellen durchführen und die Datenverarbeitungsfunktionen von Apache Doris nutzen, um die Daten zu verarbeiten und anzuzeigen oder die verarbeiteten Daten zurück in die Datenquelle zu schreiben oder sie dem Downstream-System bereitzustellen zum Verzehr.
• Einheitliches Datenanalyse-Gateway : Verwenden Sie Apache Doris, um ein vollständiges und skalierbares Datenquellenverbindungs-Framework zu erstellen, das für den schnellen Zugriff auf mehrere Arten von Datenquellen geeignet ist. Stellen Sie schnelle Abfrage- und Schreibfunktionen auf Basis verschiedener heterogener Datenquellen bereit und machen Sie Apache Doris zu einem einheitlichen Datenanalyse-Gateway.

effiziente Datenaktualisierung

In Echtzeit-Analyseszenarien ist die Datenaktualisierung eine sehr häufige Anforderung. Nutzer hoffen nicht nur, aktuelle Daten in Echtzeit abfragen zu können, sondern auch, die Daten flexibel in Echtzeit aktualisieren zu können. Typische Szenarien wie E-Commerce-Auftragsanalyse, Logistik-Frachtbriefanalyse, Benutzerporträt usw. müssen Datenaktualisierungstypen unterstützen, einschließlich der Aktualisierung ganzer Zeilen, teilweiser Spaltenaktualisierung, Stapelaktualisierung oder -löschung je nach Bedingungen und Neuschreiben der gesamten Tabelle oder der gesamten Tabelle Partition (Einfügen überschreiben) .

Effiziente Datenaktualisierung war schon immer ein Problem im Bereich der Big-Data-Analyse. Das Offline-Data-Warehouse Hive unterstützt normalerweise nur Datenaktualisierungen auf Partitionsebene, während Data Lakes wie Hudi und Iceberg Aktualisierungen auf Datensatzebene unterstützen, aber normalerweise Merge verwenden. on-Read oder Copy Die Methode -on-Write eignet sich nur für Batch-Updates mit niedriger Frequenz und nicht für hochfrequente Echtzeit-Updates.

In Version 1.2 von Apache Doris haben wir den Merge-on-Write-Datenaktualisierungsmodus im Unique Key-Primärschlüsselmodell implementiert. Die gesamte Datenzusammenführung kann während der Datenschreibphase abgeschlossen werden, sodass die Abfrageleistung um das 5- bis 10-fache verbessert wird. In Version 2.0 von Apache Doris haben wir die Datenaktualisierungsfunktion weiter verbessert, hauptsächlich einschließlich:

• Die Schreibleistung wurde erheblich optimiert und auch die Stabilität von Schreibszenarien mit hoher Parallelität und gemischter Last wurde erheblich verbessert. Beispielsweise konnte beim wiederholten Importtest eines einzelnen 7-GB-Tablets die Datenimportzeit von etwa 30 Minuten auf 90 Sekunden verkürzt und die Schreibeffizienz um das Zwanzigfache gesteigert werden; der Schreibdurchsatz von 300.000 Einträgen pro Sekunde kann unter erreicht werden bewältigt die Aufgabe und die Leistung ist auch nach mehr als zehn Stunden ununterbrochenem Schreiben immer noch sehr stabil.
• Unterstützt die teilweise Spaltenaktualisierungsfunktion. Vor Version 2.0.0 unterstützte Apache Doris nur eine teilweise Spaltenaktualisierung durch „Replace_if_not_null“ des Aggregate Key-Aggregationsmodells. In Version 2.0.0 haben wir eine teilweise Spaltenaktualisierung des Unique Key-Primärschlüsselmodells hinzugefügt und gleichzeitig eine Beim Erweitern einer breiten Tabelle geschrieben , Flink muss zum Erweitern keinen Multi-Stream-Join durchführen und kann direkt in die breite Tabelle schreiben, was den Verbrauch von Rechenressourcen reduziert und die Komplexität der Datenverarbeitungsverbindung erheblich verringert. Gleichzeitig ist es angesichts der Echtzeitaktualisierung der Beschriftungsspalte der Porträtszene und der Statusaktualisierung der Bestellszene bequemer als in der Vergangenheit, die angegebene Spalte direkt zu aktualisieren.
• Unterstützt komplexe bedingte Aktualisierungen und bedingte Löschungen. Vor Version 2.0.0 unterstützte das Unique Key-Primärschlüsselmodell nur einfache Aktualisierungs- und Löschvorgänge. In Version 2.0.0 implementierten wir Datenaktualisierungen und -löschungen mit komplexen Bedingungen basierend auf Merge-on-Write, und die Ausführungseffizienz war effizienter . Basierend auf den oben genannten Optimierungen bietet Apache Doris umfassende Unterstützung für verschiedene Datenaktualisierungsanforderungen!

Effizienteres und stabileres Schreiben von Daten

01 Die Importleistung wurde weiter verbessert

Wir konzentrieren uns auf Echtzeitanalysen und haben in den letzten Versionen die Echtzeitanalysefunktionen kontinuierlich verbessert. Die End-to-End-Echtzeit-Datenschreibfähigkeit ist eine wichtige Optimierungsrichtung. In Apache Doris 2.0 haben wir uns weiter verstärkt diese Fähigkeit. Durch Optimierungen wie Memtable ohne Skiplist, paralleles Herunterladen und Einzelkopieimport wurde die Importleistung erheblich verbessert:

• Verwenden Sie Stream Load, um drei Kopien der Originaldaten der TPC-H 144G-Lineitem-Tabelle zu erstellen und diese in die 48-Buckets-Duplicate-Tabelle zu importieren, wodurch der Durchsatz um 100 % erhöht wird.
• Verwenden Sie Stream Load, um drei Kopien der Originaldaten der TPC-H 144G-Lineitem-Tabelle zu erstellen und sie in die 48 Buckets Unique Key-Tabelle zu importieren, wodurch der Durchsatz um 200 % erhöht wird.
• Verwenden Sie insert into select, um die TPC-H 144G-Lineitem-Tabelle in die 48-Buckets-Duplicate-Tabelle zu importieren, und der Durchsatz erhöht sich um 50 %.
• Verwenden Sie insert in select, um die TPC-H 144G-Lineitem-Tabelle in die 48 Buckets Unique Key-Tabelle zu importieren, und der Durchsatz erhöht sich um 150 %.

02 Das Schreiben von Hochfrequenzdaten ist stabiler

Beim hochfrequenten Datenschreiben stellen die Probleme der Zusammenführung kleiner Dateien und der Schreibverstärkung sowie der daraus resultierende Festplatten-E/A- und CPU-Ressourcen-Overhead den Schlüssel zur Einschränkung der Systemstabilität dar. Deshalb haben wir in Version 2.0 Vertical eingeführt Komprimierung und Segmentkomprimierung werden verwendet, um das Problem der Speicherkomprimierung und zu vieler Segmentdateien während des Schreibvorgangs vollständig zu lösen. Der Ressourcenverbrauch wird um 90 % reduziert, die Geschwindigkeit wird um 50 % erhöht und die Speichernutzung beträgt nur 10 % Original .

Detaillierte Einführung: https://mp.weixin.qq.com/s/BqiMXRJ2sh4jxKdJyEgM4A

03 Automatische Synchronisierung der Datentabellenstruktur

In früheren Versionen haben wir Schemaänderungen auf Millisekundenebene eingeführt, aber in der neuesten Version von Flink-Doris-Connector haben wir eine Ein-Klick-Synchronisierung der gesamten Datenbank von relationalen Datenbanken wie MySQL bis Apache Doris erreicht. Im tatsächlichen Test kann eine einzelne Synchronisierungsaufgabe das parallele Schreiben von Tausenden von Tabellen in Echtzeit durchführen, wodurch der langwierige und komplizierte Synchronisierungsprozess in der Vergangenheit vollständig aufgegeben wird, und die Tabellenstruktur und Datensynchronisierung der vorgelagerten Geschäftsdatenbank kann durch einfache Befehle realisiert werden. Wenn sich gleichzeitig die Upstream-Datenstruktur ändert, kann die Schemaänderung automatisch erfasst und die DDL dynamisch mit Doris synchronisiert werden, um einen reibungslosen Geschäftsbetrieb sicherzustellen.

Detaillierte Einführung: https://mp.weixin.qq.com/s/Ur4VpJtjByVL0qQNy_iQBw

Vollständigere mandantenfähige Ressourcenisolierung

Der Hauptzweck der Multi-Tenant- und Ressourcenisolation besteht darin, die gegenseitige Bevorzugung von Ressourcen bei hoher Auslastung zu vermeiden. Apache Doris hat in der vergangenen Version das harte Isolationsschema für Ressourcengruppen (Ressourcengruppen) eingeführt. Durch die Kennzeichnung der BEs im selben Cluster werden BEs mit dem gleiche Bezeichnung bilden eine Ressourcengruppe. Beim Speichern von Daten in der Datenbank werden Datenkopien entsprechend der Ressourcengruppenkonfiguration in verschiedene Ressourcengruppen geschrieben. Bei der Abfrage werden die Rechenressourcen der entsprechenden Ressourcengruppen entsprechend der Aufteilung der Ressourcengruppen für die Berechnung verwendet. Beispielsweise die Lese- und Schreibverkehr werden in unterschiedlichen Kopien platziert. Um eine Lese-Schreib-Trennung zu erreichen oder Online- und Offline-Dienste in verschiedene Ressourcengruppen aufzuteilen, vermeiden Sie die Bevorzugung von Ressourcen zwischen Offline-Analyseaufgaben.

Durch das harte Isolationsschema von Ressourcengruppen kann die Ressourcenpräemption zwischen mehreren Unternehmen effektiv vermieden werden. In tatsächlichen Geschäftsszenarien sind jedoch einige Ressourcengruppen möglicherweise eng und einige Ressourcengruppen sind inaktiv. Zu diesem Zeitpunkt ist eine flexiblere Methode erforderlich. Gemeinsame Nutzung ungenutzter Ressourcen Reduzierung der Leerstandsquote bei Ressourcen. Daher haben wir in Version 2.0.0 die Soft-Limit-Lösung für Workload-Gruppenressourcen hinzugefügt und die Workload in Gruppen verwaltet, um die flexible Zuweisung und Kontrolle von Speicher- und CPU-Ressourcen sicherzustellen.

Indem Sie eine Abfrage einer Arbeitslastgruppe zuordnen, können Sie den Prozentsatz der CPU- und Speicherressourcen einer einzelnen Abfrage auf dem BE-Knoten begrenzen und das Speicher-Softlimit zum Öffnen der Ressourcengruppe konfigurieren. Wenn die Clusterressourcen knapp sind, werden mehrere Abfrageaufgaben, die den größten Speicher in der Gruppe belegen, automatisch beendet, um den Druck auf den Cluster zu verringern. Wenn die Clusterressourcen im Leerlauf sind und die von der Workload-Gruppe verwendeten Ressourcen den voreingestellten Wert überschreiten, teilen sich mehrere Workloads die verfügbaren Leerlaufressourcen des Clusters, überschreiten automatisch den Schwellenwert und nutzen weiterhin den Systemspeicher, um eine stabile Ausführung sicherzustellen Abfrageaufgaben. Die Workload-Gruppe unterstützt auch das Festlegen von Prioritäten und verwaltet die Ressourcenzuteilung durch voreingestellte Prioritäten, um zu bestimmen, welche Aufgaben normalerweise Ressourcen erhalten können und welche Aufgaben nur eine geringe Menge oder keine Ressourcen erhalten können.

Gleichzeitig haben wir auch die Abfragewarteschlangenfunktion in der Arbeitslastgruppe eingeführt. Beim Erstellen einer Arbeitslastgruppe können Sie die maximale Anzahl von Abfragen festlegen. Abfragen, die die maximale Parallelität überschreiten, werden zur Ausführung in die Warteschlange gestellt, um das System zu entlasten unter hoher Belastung. Druck.

Extreme Flexibilität und Trennung von Speicherung und Berechnung

In der Vergangenheit hat Apache Doris den Benutzern mit vielen Designs in Bezug auf Benutzerfreundlichkeit dabei geholfen, die Kosten für Rechen- und Speicherressourcen erheblich einzusparen, und wir haben einen soliden Schritt nach vorne in der zukunftsorientierten Cloud-nativen Architektur gemacht.

Ausgehend vom Trend der Kostensenkung und Effizienzsteigerung lassen sich die Nutzeranforderungen an Rechen- und Speicherressourcen wie folgt zusammenfassen:

• Elastizität der Rechenressourcen: Angesichts geschäftlicher Rechenspitzen können die Ressourcen schnell erweitert werden, um die Effizienz zu verbessern, und bei Rechentiefs können sie schnell verkleinert werden, um die Kosten zu senken;
• Geringere Speicherkosten: Angesichts der großen Datenmengen können billigere Speichermedien eingeführt werden, um die Kosten zu senken, während Speicher und Rechenleistung getrennt voneinander eingerichtet werden, ohne sich gegenseitig zu beeinträchtigen.
• Isolation der Geschäftslast: Unterschiedliche Geschäftslasten können unabhängige Rechenressourcen nutzen, um eine gegenseitige Ressourcenpräemption zu vermeiden.
• Einheitliche Datenverwaltung und -kontrolle: Ein einheitlicher Katalog und eine einheitliche Datenverwaltung ermöglichen eine komfortablere Datenanalyse.

Die integrierte Speicher-Computing-Architektur bietet den Vorteil, dass sie in Szenarien mit geringen elastischen Anforderungen einfach und leicht zu warten ist, weist jedoch in Szenarien mit hohen elastischen Anforderungen bestimmte Einschränkungen auf. Der Kern der Speicher-Computing-Trennarchitektur ist ein technisches Mittel zur Lösung der Ressourcenelastizität. Sie bietet offensichtlichere Vorteile bei der Ressourcenelastizität, stellt jedoch höhere Stabilitätsanforderungen an den Speicher, und die Stabilität des Speichers wirkt sich weiter auf die Stabilität von OLAP aus. Daher , Eine Reihe von Mechanismen wie Cache-Verwaltung, Rechenressourcenverwaltung und Mülldatenerfassung wurden eingeführt.

In der Kommunikation mit Benutzern in der Apache Doris-Community haben wir festgestellt, dass sich die Anforderungen der Benutzer an die Trennung von Speicherung und Berechnung in die folgenden drei Kategorien einteilen lassen:

• Derzeit wird die einfache und benutzerfreundliche integrierte Speicher- und Computerarchitektur ausgewählt, und es besteht vorerst kein Bedarf an Ressourcenflexibilität.
• Der Mangel an stabilem Großspeicher erfordert Elastizität, Lastisolation und niedrige Kosten auf Basis von Apache Doris;
• Bei stabiler Massenspeicherung ist eine äußerst flexible Architektur erforderlich, um das Problem der schnellen Ressourcenskalierung zu lösen. Daher ist auch eine gründlichere Architektur zur Trennung von Speicher und Computer erforderlich.

Um den Anforderungen der ersten beiden Benutzertypen gerecht zu werden, bietet Apache Doris 2.0 eine Speicher-Computing-Trennlösung, die mit Upgrades kompatibel ist:

Der erste Typ sind Rechenknoten. In Version 2.0 haben wir den Stateless-Computing-Knoten Compute Node eingeführt, der speziell für die Data-Lake-Analyse verwendet wird. Im Vergleich zum ursprünglichen Hybridknoten, der Speicher und Rechenleistung integriert, speichert der Compute Node keine Daten und muss keinen Lastausgleich der Datenfragmentierung durchführen, wenn der Cluster erweitert oder verkleinert wird. Daher in Szenarien mit offensichtlichen Spitzen wie der Data Lake-Analyse Es kann flexibel und schnell erweitert werden. Treten Sie dem Cluster bei, um den Rechendruck zu teilen. Da Benutzerdaten häufig in Remote-Speichern wie HDFS/S3 gespeichert werden, wird die Abfrageaufgabe gleichzeitig vorzugsweise zur Ausführung während der Abfrageausführung an den Rechenknoten gesendet, um eine Bevorzugung von Rechenressourcen zwischen internen und externen Abfragen zu vermeiden.

Referenzdokument: https://doris.apache.org/zh-CN/docs/dev/advanced/compute_node

Der zweite Typ ist die Schichtung heißer und kalter Daten. In Bezug auf die Speicherung unterliegen heiße und kalte Daten häufig unterschiedlichen Anforderungen an die Abfragehäufigkeit und Antwortgeschwindigkeit, sodass kalte Daten normalerweise in kostengünstigeren Speichermedien gespeichert werden können. In früheren Versionen unterstützt Apache Doris die Lebenszyklusverwaltung von Tabellenpartitionen und kühlt durch Hintergrundaufgaben automatisch heiße Daten von der SSD auf die Festplatte. Die Daten auf der Festplatte werden jedoch in mehreren Kopien gespeichert, was die Kosten nicht maximiert Es gibt viel Raum für Optimierungen bei den Kosten für die Speicherung kalter Daten. Die Hot- und Cold-Data-Tiering-Funktion wurde in Apache Doris 2.0 eingeführt . Die Hot- und Cold-Data-Tiering-Funktion ermöglicht es Apache Doris, kalte Daten mit geringeren Speicherkosten in den Objektspeicher zu verlagern. Gleichzeitig wird die Speichermethode für kalte Daten im Objektspeicher verwendet Außerdem wurde von Mehrfachkopie auf Einzelkopie umgestellt und die Speicherkosten wurden weiter auf ein Drittel der ursprünglichen Kosten gesenkt. Gleichzeitig wurden auch die zusätzlichen Kosten für Rechenressourcen und Netzwerk-Overhead-Kosten aufgrund der Speicherung reduziert. Aktuellen Berechnungen zufolge können die Lagerkosten um bis zu 70 % gesenkt werden!

Referenzdokument: https://doris.apache.org/zh-CN/docs/dev/advanced/compute_node

Angesichts der strengeren Anforderungen an die Trennung von Speicher und Datenverarbeitung hat das technische Team der Schwungradtechnologie (SelectDB) eine neue Cloud-native Speicher- und Datentrennungsarchitektur (SelectDB Cloud) entworfen und implementiert, die von einer großen Anzahl von Benutzern in großem Umfang eingesetzt wird Unternehmenskunden im vergangenen Jahr. Funktionsreife, Systemstabilität und andere Aspekte haben dem Test der realen Produktionsumgebung standgehalten. Anlässlich der Veröffentlichung von Apache Doris 2.0.0 gab Flywheel Technology bekannt, dass es diese ausgereifte Architektur nach umfassender Aufbereitung der Apache Doris-Community zur Verfügung stellen wird . Diese Arbeiten werden voraussichtlich im Oktober 2023 abgeschlossen sein. Zu diesem Zeitpunkt werden alle Speicher-Computing-Trennungscodes an den Hauptzweig der Apache Doris-Community übermittelt. Es wird erwartet, dass im September die Mehrheit der Community-Benutzer dazu in der Lage sein wird um die Storage-Computing-Trennarchitektur im Voraus zu erleben. Vorschauversion.

Benutzerfreundlichkeit weiter verbessert

Zusätzlich zu den oben genannten Funktionsanforderungen wurden Apache Doris zahlreiche Benutzererfahrungsverbesserungen für Funktionen auf Unternehmensebene hinzugefügt.

01 Unterstützt die Containerbereitstellung von Kubernetes

In der Vergangenheit basierte Apache Doris auf IP-Kommunikation. Bei der Bereitstellung in der K8s-Umgebung führt eine Pod-IP-Drift aufgrund eines Hostausfalls dazu, dass der Cluster nicht verfügbar ist. In Version 2.0 unterstützen wir FQDN, sodass Apache Doris ohne implementiert werden kann Manueller Eingriff. Selbstheilung des Knotens, sodass er besser mit der Bereitstellung der K8-Umgebung und der flexiblen Erweiterung und Kontraktion zurechtkommt.

02 Clusterübergreifende Datenreplikation

In Version 2.0.0 von Apache Doris können wir die CCR-Funktion verwenden, um die Datenänderungen des Quellclusters mit dem Zielcluster auf Datenbank-/Tabellenebene zu synchronisieren und den Umfang der Synchronisierung je nach Szenario genau zu steuern; Benutzer können dies auch Wählen Sie je nach Bedarf flexibel vollständig oder inkrementell. Durch die Synchronisierung wird die Flexibilität und Effizienz der Datensynchronisierung effektiv verbessert. Darüber hinaus unterstützt Dors CCR auch die DDL-Synchronisierung, und die vom Quellcluster ausgeführten DDL-Anweisungen können automatisch mit dem Zielcluster synchronisiert werden, um sicherzustellen Datenkonsistenz. Doris CCR ist außerdem sehr einfach zu konfigurieren und zu verwenden und kann mit einfachen Vorgängen schnell die Cluster-übergreifende Datenreplikation durchführen . Basierend auf den hervorragenden Fähigkeiten von Doris CCR kann es eine bessere Lese-/Schreiblasttrennung und Sicherung in mehreren Räumen erreichen und Cluster-übergreifende Replikationsanforderungen in verschiedenen Szenarien besser unterstützen .

03 Weitere Überlegungen zum Upgrade

• 1.2-lts erfordert Ausfallzeit für das Upgrade auf 2.0.0, 2.0-alpha erfordert Ausfallzeit für das Upgrade auf 2.0.0
• Der Abfrageoptimierungsschalter ist standardmäßig aktiviert. enable_nereids_planner=true;
• Der nicht vektorisierte Code wurde aus dem System entfernt, sodass der Parameter „enable_vectorized_engine“ nicht mehr wirksam ist.
• Neuer Parameter enable_single_replica_compaction;
• Standardmäßig werden datev2, datetimev2 und decimalv3 zum Erstellen von Tabellen verwendet, und datev1, datetimev1 und decimalv2 werden zum Erstellen von Tabellen nicht unterstützt.
• Decimalv3 wird standardmäßig in JDBC und Iceberg Catalog verwendet;
• Datumstyp hinzugefügt AGG_STATE;
• Entfernen Sie die Clusterspalte aus der Backend-Tabelle.
• Zur besseren Kompatibilität mit BI-Tools werden datev2 und datetimev2 als Datum und Datum/Uhrzeit angezeigt, wenn „Show Create Table“ angezeigt wird.
• Max_openfiles- und Swap-Prüfungen im BE-Startskript hinzugefügt, sodass der Start möglicherweise fehlschlägt, wenn die Systemkonfiguration unzumutbar ist.
• Es ist verboten, sich beim Zugriff auf FE auf localhost ohne Passwort anzumelden.
• Wenn im System ein Multi-Katalog vorhanden ist, zeigen die Daten des Abfrageinformationsschemas standardmäßig nur die Daten des internen Katalogs an;
• Begrenzen Sie die Tiefe des Ausdrucksbaums. Der Standardwert ist 200.
• Array-String-Rückgabewert: Einfache Anführungszeichen werden zu doppelten Anführungszeichen.
• Benennen Sie den Prozessnamen von Doris in DorisFE und DorisBE um.

Begeben Sie sich offiziell auf die 2.0-Reise

Während der Veröffentlichung von Apache Doris 2.0.0 haben wir Hunderte von Unternehmen eingeladen, sich an der Verfeinerung der neuen Version zu beteiligen, mit dem Ziel, allen Benutzern ein Datenanalyseerlebnis mit besserer Leistung, höherer Stabilität und besserer Benutzerfreundlichkeit zu bieten. In Zukunft werden wir weiterhin agile Versionen veröffentlichen, um dem Streben aller Benutzer nach höherer Funktionalität und Stabilität gerecht zu werden. Es wird erwartet, dass die erste Iterationsversion 2.0.1 der 2.0-Serie Ende August und Version 2.0 veröffentlicht wird. 2 erscheint im September. Während die Fehler schnell behoben werden, werden einige der neuesten Funktionen weiterhin zur neuen Version hinzugefügt. Im September werden wir eine Early-Adopter-Version von Version 2.1 veröffentlichen, die eine Reihe lang erwarteter neuer Funktionen hinzufügt, darunter Variant-Variablendatentypen, um die Analyseanforderungen von semistrukturierten Daten, Schema Free und Multi-Table-Materialized besser zu erfüllen Ansichten zur Erzielung einer Abfragebeschleunigung. Gleichzeitig können Datenplanungs- und Verarbeitungsverbindungen vereinfacht, die Importleistung kontinuierlich optimiert, neue und präzisere Datenimportmethoden hinzugefügt, das Schreiben von Daten in Echtzeit durch automatische Stapelverarbeitung und die Verschachtelungsfunktionen von Composite realisiert werden Datentypen usw.

Wir freuen uns auf die offizielle Veröffentlichung von Apache Doris 2.0, um mehr Benutzern in der Community ein einheitliches Echtzeit-Analyseerlebnis zu bieten. Wir glauben auch, dass Apache Doris 2.0 Ihre ideale Wahl für Echtzeit-Analyseszenarien sein wird.

Schließlich hat der Doris Summit 2023, das jährliche Gipfeltreffen der Apache Doris-Community, bereits begonnen, und wir gehen davon aus, dass alle Benutzer beim Doris Summit 2023 weitere bewährte Anwendungspraktiken der Version 2.0 sehen werden.