Autor｜Cheng Wei, MetaAPP-Big-Data-Forschungs- und Entwicklungsingenieur
ByConity ist das cloudnative Open-Source-Data-Warehouse von ByteDance. Es erfüllt die Anforderungen von Data-Warehouse-Benutzern nach elastischer Ressourcenerweiterung und -kontraktion, Lese-/Schreibtrennung, Ressourcenisolation, starker Datenkonsistenz usw. und bietet gleichzeitig eine hervorragende Abfrage- und Schreibleistung.
MetaApp ist ein führender Spieleentwickler und -betreiber in China, der sich auf die effiziente Verbreitung mobiler Informationen konzentriert und sich dem Aufbau einer virtuellen Welt für alle Altersgruppen verschrieben hat. Im Jahr 2023 hat MetaApp mehr als 200 Millionen registrierte Benutzer, hat an 200.000 Spielen mitgearbeitet und verfügt über ein kumuliertes Vertriebsvolumen von über 1 Milliarde.
MetaApp widmete ByConity in den frühen Tagen von Open Source Aufmerksamkeit und war einer der ersten Benutzer, der es in der Produktionsumgebung testete und startete. Mit der Idee, die Fähigkeiten von Open-Source-Data-Warehouse-Projekten zu verstehen, führte das MetaApp-Big-Data-Forschungs- und Entwicklungsteam einen vorläufigen Test auf ByConity durch. Seine Speicher-Rechen-Trennungsarchitektur und hervorragende Leistung, insbesondere in Protokollanalyseszenarien, sowie die Unterstützung komplexer Abfragen bei großen Datenmengen veranlassten MetaApp dazu, eingehende Tests von ByConity durchzuführen und schließlich ClickHouse in der Produktionsumgebung vollständig zu ersetzen, wodurch die Ressourcenkosten gesenkt wurden um mehr als 50 %.
In diesem Artikel werden hauptsächlich die Funktionen der MetaApp-Datenanalyseplattform, die in Geschäftsszenarien auftretenden Probleme und Lösungen sowie die Hilfe bei der Einführung von ByConity in sein Unternehmen vorgestellt.
Architektur und Funktionen der MetaApp OLAP-Datenanalyseplattform
Mit dem Wachstum des Geschäfts und der Einführung verfeinerter Abläufe stellen Produkte höhere Anforderungen an die Datenabteilung, einschließlich der Notwendigkeit, Echtzeitdaten abzufragen und zu analysieren und Betriebsstrategien schnell anzupassen, um AB-Experimente an einer kleinen Gruppe von Personen durchzuführen Überprüfen Sie die Wirksamkeit neuer Funktionen. Es reduziert die Zeit und den Schwierigkeitsgrad der Datenabfrage und ermöglicht es Laien, Daten unabhängig zu analysieren und zu untersuchen. Um den Geschäftsanforderungen gerecht zu werden, hat MateApp eine OLAP-Datenanalyseplattform implementiert, die Ereignisanalyse, Konvertierungsanalyse, benutzerdefinierte Aufbewahrung, Benutzergruppierung, Verhaltensflussanalyse und andere Funktionen integriert .
Dies ist eine typische OLAP-Architektur, die in zwei Teile unterteilt ist: Der eine ist offline und der andere ist in Echtzeit.
Im Offline-Szenario verwenden wir DataX, um Kafka-Daten in das Hive-Data-Warehouse zu integrieren und anschließend BI-Berichte zu generieren. BI-Berichte verwenden die Superset-Komponente, um Ergebnisse anzuzeigen.
In einem Echtzeitszenario verwendet eine Linie GoSink für die Datenintegration und integriert GoSink-Daten in ClickHouse, und die andere Linie verwendet CnchKafka, um Daten in ByConity zu integrieren. Schließlich werden die Daten über die OLAP-Abfrageplattform zur Abfrage abgerufen.
Funktionsvergleich zwischen ByConity und ClickHouse
ByConity ist ein cloudnatives Open-Source-Data-Warehouse, das auf der Grundlage des ClickHouse-Kerns entwickelt wurde und eine Architektur zur Trennung von Speicher und Berechnung verwendet. Beide haben folgende Eigenschaften:
- Die Schreibgeschwindigkeit ist sehr hoch und eignet sich zum Schreiben großer Datenmengen. Die geschriebene Datenmenge kann 50 MB bis 200 MB/s erreichen
- Die Abfragegeschwindigkeit ist sehr hoch. Bei großen Datenmengen kann die Abfragegeschwindigkeit 2-30 GB/s erreichen.
- Hohe Datenkomprimierungsrate, niedrige Speicherkosten, Komprimierungsrate kann 0,2 bis 0,3 erreichen
ByConity bietet die Vorteile von ClickHouse, behält eine gute Kompatibilität mit ClickHouse bei und wurde in Bezug auf Lese-/Schreibtrennung, elastische Expansion und Kontraktion sowie starke Datenkonsistenz verbessert. Beide gelten für die folgenden OLAP-Szenarien:
- Datensätze können groß sein – Milliarden oder Billionen Zeilen
- Die Datentabelle enthält viele Spalten
- Fragen Sie nur bestimmte Spalten ab
- Ergebnisse müssen in Millisekunden oder Sekunden zurückgegeben werden
In früheren Beiträgen verglich die ByConity-Community die beiden [aus Nutzungssicht]
Beim Aufbau der OLAP-Plattform haben wir uns hauptsächlich auf die Ressourcenisolierung, Kapazitätserweiterung und -verringerung , komplexe Abfragen und die Unterstützung verteilter Transaktionen konzentriert .
Bei der Verwendung von ClickHouse sind Probleme aufgetreten
Problem 1: Integriertes Lesen und Schreiben kann leicht Ressourcen beanspruchen und kann kein stabiles Lesen/Schreiben garantieren.
In Spitzenzeiten des Geschäftsverkehrs beansprucht das Schreiben von Daten eine große Menge an E/A- und CPU-Ressourcen, was zu einer Beeinträchtigung der Abfragen führt (die Abfragezeiten werden länger). Das Gleiche gilt für Datenabfragen.
Problem 2: Erweiterung/Verkleinerung ist mühsam und dauert lange
- Lange Erweiterungs-/Schrumpfungszeit: Da sich die Maschine in einem IDC befindet und zu einer privaten Cloud gehört, besteht eines der Probleme darin, dass der Zyklus zum Hinzufügen von Knoten extrem lang ist. Von der Ausgabe der Knotenanforderung bis zur tatsächlichen Hinzufügung guter Knoten, was sich auf das Geschäft auswirkt, dauert es ein bis zwei Wochen.
- Schnelles Hoch- und Runterskalieren nicht möglich: Die Daten müssen nach dem Hochskalieren neu verteilt werden, da sonst der Knotendruck sehr hoch ist.
Problem drei: Betrieb und Wartung sind umständlich und SLA kann in Spitzengeschäftszeiten nicht garantiert werden.
- Aufgrund von Ausfällen von Geschäftsknoten sind Datenabfragen oft langsam und das Schreiben von Daten verzögert sich (von einigen Stunden bis zu einigen Tagen).
- In Spitzenzeiten herrscht ein erheblicher Ressourcenmangel, und es ist unmöglich, die Ressourcen kurzfristig zu erweitern. Die einzige Möglichkeit besteht darin, die Daten einiger Dienste zu löschen, um Dienste für Dienste mit hoher Priorität bereitzustellen.
- In geschäftsschwachen Zeiten stehen viele Ressourcen ungenutzt und die Kosten steigen. Obwohl wir uns in IDC befinden, unterliegt der Kauf von IDC-Maschinen auch der Kostenkontrolle und die Knotenerweiterung kann nicht unbegrenzt sein. Darüber hinaus gibt es bei normaler Nutzung einen gewissen Kostenverbrauch.
- Interaktion mit Cloud-Ressourcen nicht möglich.
Verbesserungen nach der Einführung von ByConity
Erstens kann durch die Trennung von Lese- und Schreibrechenressourcen durch ByConity sichergestellt werden, dass Lese- und Schreibaufgaben relativ stabil sind. Wenn die Leseaufgaben nicht ausreichen, können die entsprechenden Ressourcen erweitert werden, um den Mangel auszugleichen, einschließlich der Nutzung von Cloud-Ressourcen zur Erweiterung.
Zweitens ist das Hoch- und Herunterskalieren relativ einfach und kann auf Minutenebene durchgeführt werden. Da verteilter HDFS/S3-Speicher verwendet wird und Rechenleistung und Speicher getrennt sind, ist nach der Erweiterung keine Datenumverteilung erforderlich und kann direkt nach der Erweiterung verwendet werden.
Darüber hinaus sind die Cloud-native Bereitstellung sowie der Betrieb und die Wartung relativ einfach.
- Die Komponenten von HDFS/S3 sind relativ ausgereift und stabil, mit Kapazitätserweiterung und -verringerung, ausgereiften Disaster-Recovery-Lösungen und Problemen, die schnell gelöst werden können;
- In Spitzenzeiten kann das SLA durch eine schnelle Ausweitung der Ressourcen gewährleistet werden;
- In Zeiten geringer Geschäftsspitzen können die Kosten durch die Reduzierung der Speicher-/Rechnerressourcen gesenkt werden.
Die Nutzung und der Betrieb von ByConity
Nutzung des ByConity-Clusters
Derzeit nutzt unsere Plattform ByConity stabil in Geschäftsszenarien. Durch aufeinanderfolgende Migrationen hat ByConity die Daten des ClickHouse-Clusters vollständig übernommen und begonnen, Dienste stabil bereitzustellen. Wir haben den ByConity-Cluster mit S3 plus K8s in der Cloud aufgebaut. Wir haben auch eine geplante Erweiterungs- und Kontraktionslösung verwendet, die an Wochentagen um 10 Uhr erweitert und um 20 Uhr reduziert werden kann Tag. . Berechnungen zufolge reduziert diese Methode die Ressourcen im Vergleich zur direkten Nutzung von Jahres- und Monatsabonnements um etwa 40–50 %. Darüber hinaus fördern wir auch die Kombination von Private Cloud + Public Cloud, um das Ziel zu erreichen, Kosten zu senken und die Servicestabilität zu verbessern.
Die folgende Abbildung zeigt unsere aktuelle Nutzung, bei der der OLAP-Server zum Durchführen gemeinsamer Abfragen auf dem ClickHouse-Cluster und ByConity im Offline-IDC-Computerraum verwendet wird. Kurzfristig wird der ClickHouse-Cluster weiterhin als Übergang für Unternehmen genutzt, die teilweise auf ClickHouse angewiesen sind.
In Zukunft werden wir Daten offline abfragen und zusammenführen, während die von Kafka verbrauchten Ressourcen online genutzt werden. Wenn Sie Ressourcen erweitern, können Sie die Ressourcen von vw_default und vw_write online erweitern und öffentliche Cloud-Ressourcen rational nutzen, um das Problem unzureichender Ressourcen zu lösen. Gleichzeitig wird die Kapazität während geringer Geschäftsspitzen reduziert, um den Verbrauch der öffentlichen Cloud zu reduzieren.
Vergleich von ByConity- und ClickHouse-Abfragen in Geschäftsdaten
Testdatensatz und Ressourcenkonfiguration
- Anzahl der Datenelemente: Partitioniert nach Datum, 4 Milliarden Elemente an einem einzigen Tag, insgesamt 40 Milliarden in 10 Tagen
- Tabellarische Daten: 2800 Spalten
Wie aus der obigen Tabelle ersichtlich ist:
Die von der ClickHouse-Clusterabfrage verwendeten Ressourcen sind: 400 Kerne und 2560 GB Speicher
Die von der ByConity 8-Worker-Cluster-Abfrage verwendeten Ressourcen sind: 120 Kerne und 880 G Speicher
Die von der ByConity 16-Worker-Cluster-Abfrage verwendeten Ressourcen sind: 240 Kerne und 1760 G Speicher
Zusammenfassung der Ergebnisse der Business-SQL-Abfrage
Die Zusammenfassung hier verwendet den Durchschnittswert, wie Sie sehen können:
- Herkömmliches OLAP – Deduplizierung, Aufbewahrung, Konvertierung und Aufzählung – kann bei relativ geringem Ressourcenaufwand (120C, 880G) den gleichen Abfrageeffekt wie der ClickHouse-Cluster (400C, 2560G) erzielen und durch Erweitern der Ressourcen (240C, 1760G) verdoppelt werden ), um den Effekt einer Verdoppelung der Abfragegeschwindigkeit zu erzielen. Wenn eine höhere Abfragegeschwindigkeit erforderlich ist, können mehr Ressourcen erweitert werden;
- Ohne Filterung sind möglicherweise moderate Ressourcenkosten (240C, 1760G) erforderlich, um ähnliche Effekte wie beim ClickHouse-Cluster (400C, 2560G) zu erzielen.
- Bitmap erfordert möglicherweise höhere Ressourcenkosten, um ähnliche Effekte wie ClickHouse-Cluster zu erzielen.
Allgemeine Abfrage/Ereignisanalyseabfrage
Wie aus der obigen Abbildung ersichtlich ist:
- Im Deduplizierungsabfrageszenario gibt es keinen großen Unterschied zwischen der Aktivierung der ByConity-Optimierung und der Nichtaktivierung der Optimierung.
- 8 Worker (120C 880G) erreichen grundsätzlich eine Abfragezeit, die ClickHouse nahe kommt;
- In Deduplizierungsszenarien kann die Abfragegeschwindigkeit durch die Erweiterung der Rechenressourcen beschleunigt werden.
Aufbewahrungsberechnung
Wie aus der obigen Abbildung ersichtlich ist:
- Im Retained-Computing-Szenario beträgt die Abfragezeit, nachdem ByConity die Optimierung aktiviert hat, 33 % der Abfragezeit ohne Aktivierung der Optimierung.
- 8 Worker (120C 880G) Die Abfragezeit bei aktivierter Optimierung beträgt 30 % der Abfragezeit;
- Im Retained-Computing-Szenario kann die Abfragegeschwindigkeit durch Erweiterung der Rechenressourcen + Optimierung auf 16 % der CK-Abfragezeit beschleunigt werden.
Umrechnungsberechnung
Wie aus der obigen Abbildung ersichtlich ist:
- Im Conversion-Berechnungsszenario beträgt die Abfragezeit nach der Aktivierung von ByConity zur Optimierung 60 % der Abfragezeit ohne Optimierung;
- Die Abfragezeit von 8 Workern (120C 880G) mit aktivierter Optimierung liegt nahe an der ClickHouse-Abfragezeit;
- Durch die Transformation von Computerszenarien kann die Abfragegeschwindigkeit durch Erweiterung der Computerressourcen + Optimierung auf 53 % der ClickHouse-Abfragezeit beschleunigt werden.
nicht im Filter
Nicht beim Filtern wird hauptsächlich in Benutzergruppierungsszenarien und Benutzer-Tagging-Szenarien verwendet.
Wie aus der obigen Abbildung ersichtlich ist:
- Im Szenario „Keine Filterung“ ist ByConity mit aktivierter Optimierung schlechter als ByConity mit nicht aktivierter Optimierung. Daher verwenden wir in diesem Szenario direkt die Methode, die Optimierung nicht zu aktivieren.
- Die Abfragezeit für 8 Worker (120C 880G) ohne Optimierung ist langsamer als die ClickHouse-Abfragezeit, aber nicht viel;
- In keinem Filterszenario kann die Abfragegeschwindigkeit durch Erweiterung der Rechenressourcen auf 86 % der ClickHouse-Abfragezeit beschleunigt werden.
Klicken Sie auf Berechnung 
Wie aus der obigen Abbildung ersichtlich ist:
- Nach der Überprüfung der Szene ist es besser, ByConity zu aktivieren und zu optimieren, als ByConity, die Optimierung nicht zu aktivieren.
- Die Abfragezeit von 8 Workern (120C 880G) ohne Optimierung liegt nahe an der ClickHouse-Abfragezeit;
- Im Click-Through-Szenario kann die Abfragegeschwindigkeit auf 26 % der ClickHouse-Abfragezeit beschleunigt werden, indem die Rechenressourcen erweitert und die Optimierung aktiviert wird.
Bitmap-Abfrage
Bitmap-Abfragen sind ein Szenario, das häufiger bei AB-Tests verwendet wird.
Wie aus der obigen Abbildung ersichtlich ist:
- In der Bitmap-Filterszene ist es besser, die ByConity-Optimierung zu aktivieren, als ohne ByConity-Optimierung;
- Die Abfragezeit für 8 Worker (120C 880G) ohne Optimierung ist viel langsamer als die ClickHouse-Abfragezeit.
- Die Bitmap-Filterszene, bei der die Ressourcen auf 16 Worker (240C 1769G) erweitert werden, ist langsamer als die ClickHouse-Abfrage.
Gewinne nach vollständiger Migration von ByConity
Reduzierte Ressourcen
Im Folgenden werden die CPU-Unterschiede nicht berücksichtigt, die Daten dienen nur als Referenz.
Nach vollständiger Migration mit ByConity
- Ein Vergleich des Abfrage- und Zusammenführungsressourcenverbrauchs zeigt, dass der CPU-Verbrauch im Vergleich zu zuvor um etwa 75 % reduziert wurde;
- Beim Vergleich der Datenschreibressourcen ist der CPU-Verbrauch im Vergleich zu zuvor um etwa 35 % reduziert;
- Es muss nur die Hälfte der festen Ressourcen gekauft werden, die verbleibende Hälfte hängt von der Flexibilität der Arbeitstage ab (10 bis 20 Uhr). Die Kosten reduzieren sich im Vergleich zum Kauf der gesamten Ressourcenmenge um etwa 25 %.
Aktueller Nutzungsverbrauch
Wie aus der aktuellen Ergebnistabelle hervorgeht, liegen die CPU- und Speicherverhältnisse von ByConity bei 34 % bzw. 48 % von ClickHouse.
Verbrauch nach dem Hinzufügen von Remote-Speicher
Wir verwenden minio für die Datenspeicherung in IDC und verwenden eine 640-Kern-CPU, 4096 G Speicher, 16 Knoten, einen einzelnen Knoten mit 40 Kernen, 256 G und eine Festplatte mit 36 T. Nach Addition dieser Kosten zu ByConity beträgt das CPU- und Speicherverhältnis von ByConity immer noch niedriger als ClickHouse, nämlich 48 % bzw. 68 % von ClickHouse. Man kann sagen, dass ByConity im Hinblick auf den Ressourcenverbrauch, wenn es auf Jahres- und Monatsbasis berechnet wird, mindestens etwa 50 % niedriger ausfällt als zuvor, wenn es bei Bedarf gestartet und gestoppt wird; die Kosten werden um etwa 25 % gesenkt; im Vergleich zum vollständigen Einkauf von Ressourcen .
Reduzierte Betriebs- und Wartungskosten
- Einfachere Möglichkeit, Konfigurationsdaten zu schreiben. In der Vergangenheit gab es bei dem von uns speziell konfigurierten Schreibdienst häufig Probleme wie „Zu viele Teile“.
- Die Erweiterung der Spitzenabfrage ist einfacher. Fügen Sie einfach die Anzahl der Pods hinzu und Sie können die Kapazität schnell erweitern. Niemand wird fragen: „Warum wurden die Daten nach einer halben Stunde nicht angezeigt?“
Vorschläge zum Ersetzen von ClickHouse durch ByConity
- Testen Sie, ob Ihr SQL auf der ByConity-Plattform in Ihrem Unternehmen normal ausgeführt werden kann. Wenn es kompatibel ist, wird es grundsätzlich ausgeführt. Sollten im Einzelfall kleinere Probleme auftreten, können Sie diese in der Community ansprechen, um schnelles Feedback zu erhalten;
- Kontrollieren Sie die Ressourcen des Testclusters, testen Sie die Datensatzgröße und vergleichen Sie die Abfrageergebnisse des ByConity-Clusters und des ClickHouse-Clusters, um zu sehen, ob sie den Erwartungen entsprechen. Falls erwartet, kann ein Austausch geplant werden. Bei Aufgaben, die stärker rechenorientiert sind, kann ByConity eine bessere Leistung erbringen.
- Basierend auf der Größe des Testdatensatzes, dem verbrauchten S3- und HDF-Speicherplatz, der Bandbreite und der QPS-Rechenressourcennutzung werden die für die Speicherung und Berechnung der gesamten Datenmenge erforderlichen Ressourcen bewertet;
- Geben Sie die Daten gleichzeitig in den ByConity- oder ClickHouse-Cluster ein und starten Sie den Dual-Lauf für einen bestimmten Zeitraum, um Probleme zu lösen, die während des Dual-Laufs auftreten. Wenn unser Unternehmen beispielsweise nicht über ausreichende Ressourcen verfügt, können wir diese je nach Geschäft nutzen. Wir können zunächst einen ByConity-Cluster in der Cloud aufbauen, ihn in einen bestimmten Teil des Geschäfts verschieben und ihn dann nach und nach ersetzen IDC-Ressourcen, wir können diese verschieben. Ein Teil der Daten wird offline migriert;
- Sie können sich vom ClickHouse-Cluster abmelden, sobald keine Probleme mit der Dual-Ausführung auftreten.
Während dieses Prozesses gibt es einige Überlegungen:
- Die Lesebandbreite und QPS von S3- und HDFS-Remotespeicher können höher sein und es sind bestimmte Vorbereitungen erforderlich. Beispielsweise beträgt unsere maximale Lese- und Schreibbandbreite pro Sekunde: 2,5 GB schreiben/6 GB lesen, und die maximale QPS pro Sekunde beträgt: 2 ~ 6.000;
- Wenn die Bandbreite des Worker-Knotens voll ist, kommt es auch zu einem Abfrageengpass.
- Die Cache-Festplatte des Standardknotens (d. h. des Lese-Rechenknotens) kann entsprechend größer konfiguriert werden, was den Bandbreitendruck von S3 während der Abfrage verringern und die Abfrage beschleunigen kann.
- Wenn Sie auf nicht zwischengespeicherte Daten stoßen, kann es zu Kaltstartproblemen kommen. Auch hierfür hat ByConity einige betriebliche Vorschläge, die stärker in das eigene Geschäft integriert werden müssen. So nutzen wir beispielsweise die Vorkontrolle am Morgen, um diesen Teil des Kaltstartproblems zu entschärfen.
Zukunftsplan
Zukünftig werden wir die Erprobung und Implementierung der ByConity Data Lake-Lösung vorantreiben. Darüber hinaus werden wir das Datenindikatormanagement mit der Data-Warehouse-Theorie kombinieren, sodass 80 % der Abfragen auf das Data-Warehouse fallen. Jeder ist herzlich willkommen, an diesem Erlebnis teilzunehmen.
GitHub ｜https://github.com/ByConity/ByConity
Scannen Sie den QR-Code, um ByConity Assistant hinzuzufügen
Fellow Chicken „Open-Source“ -Deepin-IDE und endlich Bootstrapping erreicht! Guter Kerl, Tencent hat Switch wirklich in eine „denkende Lernmaschine“ verwandelt. Tencent Clouds Fehlerüberprüfung und Situationserklärung vom 8. April RustDesk-Remote-Desktop-Startup-Rekonstruktion Web-Client WeChats Open-Source-Terminaldatenbank basierend auf SQLite WCDB leitete ein großes Upgrade ein TIOBE April-Liste: PHP fiel auf ein Allzeittief, Fabrice Bellard, der Vater von FFmpeg, veröffentlichte das Audiokomprimierungstool TSAC , Google veröffentlichte ein großes Codemodell, CodeGemma , wird es dich umbringen? Es ist so gut, dass es Open Source ist – ein Open-Source-Bild- und Poster-Editor-Tool