Hintergrundeinführung
ByConity eignet sich für eine Vielzahl von Geschäftsszenarien und bietet eine sehr gute Leistung beim Echtzeit-Datenzugriff, bei Aggregationsabfragen für große und breite Tabellen, bei komplexen Analysen und Berechnungen unter großen Datenmengen sowie bei Korrelationsabfragen für mehrere Tabellen. Lassen Sie uns dieses Verhaltensanalysesystem anhand eines tatsächlichen Geschäftsszenarios vorstellen. Dieses Verhaltensanalysesystem basiert auf einer mehrdimensionalen Benutzerverhaltensanalyseplattform und bietet mehrere Analysemethoden und -szenarien wie Ereignisanalyse, Aufbewahrungsanalyse, Konvertierungsanalyse, Benutzergruppierung usw Benutzerbindung. In diesem Artikel werden die Probleme und Herausforderungen vorgestellt, auf die diese mehrdimensionale Plattform zur Analyse des Benutzerverhaltens bei Verwendung des ursprünglichen ClickHouse-Clusters stößt, und wie diese Probleme gelöst und dem Unternehmen nach der Migration von ByConity Vorteile gebracht werden können.
Abbildung 1:
Entwurf
der Systemarchitektur für die Verhaltensanalyse
Probleme und Herausforderungen
In der Anfangszeit wurde dieses System im ClickHouse-Cluster eingesetzt. Einerseits wuchs die Datenmenge von Tag zu Tag. Die maximale tägliche Datenmenge überstieg 320 TB Neue Zeilen überstiegen 2,3 Billionen und die Benutzerdatendimensionen überstiegen 20.000. Andererseits sind die Anforderungen an Benutzerabfragen flexibler und vielfältiger und müssen gleichzeitig detaillierte Abfragen, aggregierte Abfragen und interaktive Analyseabfragen unterstützen. und liefern schnelle Reaktionsergebnisse. Da die Datenmenge weiterhin zunimmt (jährliches Wachstum von 35 %), müssen wir außerdem nicht nur in der Lage sein, die Herausforderungen zu bewältigen, die ein solch großer Datenanstieg mit sich bringt, sondern auch die Kostenwachstumsrate innerhalb eines bestimmten Bereichs zu kontrollieren.
Auf dem bestehenden ClickHouse-Cluster ist es für uns jedoch schwierig, dies zu tun. Der Grund dafür ist, dass ClickHouse auf einer Shared-Nothing-Architektur basiert. Jeder Knoten ist unabhängig und teilt keine Speicherressourcen. Daher sind Computerressourcen und Speicherressourcen eng miteinander verbunden, was zu den folgenden Problemen führt:
-
Die Kosten für das Hoch- und Herunterskalieren werden höher und erfordern eine Datenmigration, die uns daran hindert, je nach Bedarf in Echtzeit hoch- und herunterzuskalieren, was ebenfalls zu einer Verschwendung von Ressourcen und unkontrollierbaren Kosten führt.
-
Eine eng gekoppelte Architektur führt dazu, dass mehrere Mandanten in einer gemeinsam genutzten Clusterumgebung miteinander interagieren, was dazu führt, dass Benutzerabfragen sich gegenseitig beeinflussen.
-
Da das Lesen und Schreiben von Knoten im Cluster auf demselben Knoten abgeschlossen wird, beeinflussen sich Lesen und Schreiben gegenseitig.
-
Die Leistungsunterstützung für komplexe Abfragen wie Multi-Table-Join-Vorgänge ist nicht sehr gut und kann den unterschiedlichen Anforderungen der Benutzer an Abfragen nicht gerecht werden.
Technologieauswahl
Daher begann das Unternehmen Anfang 2022, ByConity mit einer Rechen- und Speichertrennungsarchitektur als Haupt-OLAP-Engine zu verwenden. ByConity ist ein cloudnatives Open-Source-Data-Warehouse, das eine Architektur zur Trennung von Computer und Speicher verwendet und mehrere Schlüsselfunktionen unterstützt, wie z. B. Trennung von Computer und Speicher, elastische Erweiterung und Kontraktion, mandantenfähige Ressourcenisolierung und starke Konsistenz beim Lesen und Schreiben von Daten . Durch die Nutzung gängiger OLAP-Engine-Optimierungen wie Spaltenspeicherung, vektorisierte Ausführung, MPP-Ausführung, Abfrageoptimierung usw. kann ByConity eine hervorragende Lese- und Schreibleistung bieten.
Abbildung 2
Diagramm der dreischichtigen technischen Architektur
von ByConity
ByConity ist ein Upgrade, das auf der Open-Source-ClickHouse-Architektur basiert. Es führt eine Architektur ein, die Computer und Speicher trennt. Es wandelt die ursprüngliche Architektur, in der Computer und Speicher lokal auf jedem Knoten verwaltet werden, in eine einheitliche Verwaltung aller Aufgaben im gesamten Cluster um Verteilter Speicher macht jeden Rechenknoten zu einem zustandslosen reinen Rechenknoten und nutzt die Erweiterungsmöglichkeiten des verteilten Speichers und die zustandslosen Eigenschaften von Rechenknoten, um eine dynamische Erweiterung und Kontraktion zu erreichen. Gerade aufgrund dieser Verbesserung verfügt ByConity über die folgenden wichtigen Funktionen:
-
Ressourcenisolation : Isolieren Sie Ressourcen für verschiedene Mandanten, damit sich die Mandanten nicht gegenseitig beeinflussen.
-
Lese- und Schreibtrennung : Rechenressourcen und Speicherressourcen werden entkoppelt, um sicherzustellen, dass sich Lese- und Schreibvorgänge nicht gegenseitig beeinflussen.
-
Elastische Expansion und Kontraktion : Unterstützt die elastische Expansion und Kontraktion und kann Rechenressourcen in Echtzeit und bei Bedarf erweitern und kontrahieren, um eine effiziente Ressourcennutzung sicherzustellen.
-
Starke Konsistenz der Daten : Eine starke Konsistenz beim Lesen und Schreiben von Daten stellt sicher, dass die Daten immer auf dem neuesten Stand sind und es keine Inkonsistenz zwischen Lesen und Schreiben gibt.
-
Hohe Leistung : Übernimmt die gängige OLAP-Engine-Optimierung wie Spaltenspeicherung, vektorisierte Ausführung, MPP-Ausführung, Abfrageoptimierung usw., um eine hervorragende Lese- und Schreibleistung bereitzustellen
geschäftliches Einkommen
Nachdem wir ByConity eingeführt haben, kann die Gesamtleistung 91 % erreichen und alle Benutzeranfragen können innerhalb von 10 Sekunden abgeschlossen werden. Durch Feedback-Recherche von Benutzern liegt dieser Leistungsindikator ebenfalls im akzeptablen Bereich der Benutzer. Hier ist eine Zusammenfassung der allgemeinen Vorteile und Erfahrungen, die unsere Migration zu ByConity mit sich gebracht hat:
-
Vermeiden Sie die vorzeitige Belegung von Ressourcen und stellen Sie sicher, dass die Abfrageleistung zu 100 % stabil ist :
Beim ursprünglichen ClickHouse-Cluster stießen wir häufig auf das Problem der Ressourcenüberfüllung. Da ClickHouse keine Ressourcenisolation und Mandantenisolation erreichte, war der Overhead sehr hoch, wenn mehrere Benutzer den Cluster für Abfragen gemeinsam nutzten Die Bevorzugung von Ressourcen führt dazu, dass alle gemeinsam genutzten Benutzerabfragen in diesem Cluster instabil sind und die Servicequalität nicht erfüllt werden kann. Da die Computergruppe jedoch nach der Migration vollständig physisch isoliert ist, können die Abfragen verschiedener Benutzer nicht voneinander beeinflusst werden. Die Gesamtabfrageleistung kann 91 % erreichen kann innerhalb von 10 Sekunden abgeschlossen werden. Darüber hinaus bietet ByConity selbst entwickelte komplexe Abfragelinks, einen selbst entwickelten Festplatten-Cache zur Reduzierung des Lesens kalter Daten und die Indizierung häufig verwendeter Arrays. Darüber hinaus ist die Effizienz des heißen Lesens im Vergleich zum Original besser ClickHouse-Cluster, ByConity Der Leistungsverlust im Cluster liegt innerhalb von 10 %.
-
Geringe Betriebs- und Wartungskosten und fehlerhafte Knoten können in Sekundenschnelle ausgetauscht werden :
Wenn im Clickhouse-Cluster festgestellt wird, dass ein Knoten im Cluster defekt ist, muss die gesamte Maschine zur Reparatur heruntergefahren werden. Dies liegt daran, dass sich die Rechenressourcen, Speicherressourcen und Metadateninformationen von ClickHouse alle auf diesem Knoten befinden entspricht einem Verlust einer Rechenressource und einer Speicherkopie. Vor dem Ersetzen eines neuen Knotens muss die lokale Festplatte des defekten Knotens gesichert und auf den neuen Knoten migriert werden hoch und die Datenkonsistenz ist schwer zu gewährleisten. Wenn die Computergruppe defekt ist, muss sie nur durch eine neue Computergruppe ersetzt werden, da sie keine Daten speichert und nur zustandslose Computerknoten enthält. Die Zuverlässigkeit und Konsistenz der Daten wird von HDFS bereitgestellt Stellen Sie sicher, dass der Verlust des lokalen Hot-Read-Datencaches durch die Leistung von Geschäftsabfragen kontrollierbar ist. Dieser Teil profitiert hauptsächlich von der ByConity-Speicher- und Computing-Trennarchitektur.
-
Sensorlose Expansion und Kontraktion , wodurch Ressourcenkosten gespart werden:
ByConity kann eine nahtlose Erweiterung und Kontraktion erreichen. Es handelt sich um eine modulare und containerisierte Bereitstellung, die auf der elastischen Skalierbarkeit von Kubernetes basiert und gleichzeitig unbegrenzt erweitert werden kann Grund zur Sorge, da der ByConity-Knoten nur ein zustandsloser Rechenknoten ist und das direkte Entfernen kaum Auswirkungen auf den gesamten Cluster hat. Darüber hinaus wird adaptives Scheduling verwendet, um langsame Knoten zu vermeiden, die Durchsatzfähigkeiten zu verbessern und die Ressourcennutzung der Knoten zu verbessern. Gleichzeitig ist die Komprimierungsrate von ByConity extrem hoch. Am Beispiel eines seiner Unternehmen werden täglich 460 TB an Daten hinzugefügt, was einer Komprimierungsrate von 65 % entspricht. ZSTD und andere Komprimierungsmethoden, die im Extremfall mehr Speicher verbrauchen als Parkett.
-
Die Datenkonsistenz ist stark gewährleistet und die Wartungskomplexität liegt nahe bei Null :
Nach der Migration zu ByConity haben wir das Datenkonsistenzproblem vollständig gelöst, da ByConity kein lokales Master-Slave-Synchronisationsproblem hat und das Datenkonsistenzproblem direkt durch den zugrunde liegenden Objektspeicher wie HDFS/S3 usw. gelöst wird. Auf diese Weise wird die Komplexität der Konsistenzpflege erheblich reduziert und auch die Fehlerwahrscheinlichkeit ist geringer. Derzeit melden nur wenige Benutzer Probleme mit der Datenkonsistenz. Dies ist jedoch bereits häufig aufgetreten, da der ClickHouse-Cluster durch die Kommunikation zwischen Knoten durch mehrere Kopien verwaltet wird und Konsistenzprobleme durch Konsistenzwarteschlangen aufrechterhalten werden. Die Implementierung ist ebenfalls sehr kompliziert und fehleranfällig. Darüber hinaus kann ByConity über HDFS direkt auf Datendateien zugreifen. Verschiedene Computer-Engines passen sich zum Lesen von Daten an unterschiedliche Konnektoren an und verfügen über universelle Funktionen.
Zukunftsausblick
Nach anderthalb Jahren praktischer Erkundung hat sich ByConity zur wichtigsten intern verwendeten OLAP-Engine entwickelt. Eine große Anzahl von Benutzern und Daten wird später verschoben und wird schließlich den ursprünglichen ClickHouse-Cluster ersetzen. Es ist ersichtlich, dass ByConity als OLAP-Engine mit getrennter Berechnung und Speicherung die Vorteile hoher Leistung, hoher Skalierbarkeit und hoher Stabilität bietet und die Anforderungen einer groß angelegten Datenverarbeitung und -analyse erfüllen kann. Gleichzeitig wird sich ByConity durch die Kommunikation in der Community und die von der Community veröffentlichte Roadmap-Diskussion https://github.com/ByConity/ByConity/issues/26 in Zukunft hauptsächlich auf die folgenden Richtungen konzentrieren:
-
Unterstützt mehrstufige Ausführung, ETL-Funktionen usw. der Ausführungsschicht
-
Unterstützen Sie föderierte Data-Lake-Abfragen wie Hudi, Iceberg usw.
Die ByConity-Community hat eine große Anzahl von Benutzern und ist eine sehr offene Community. Wir laden alle ein, mit uns auf Github zu diskutieren. Sie können auch unserer WeChat-Gruppe, der Feishu-Gruppe oder Discord beitreten, um an der Kommunikation teilzunehmen.
GitHub:https://github.com/ByConity/ByConity
{{o.name}}
{{m.name}}