Amoro ist ein Lake-Warehouse-Verwaltungssystem, das auf offenen Daten-Lake-Tabellen wie Apache Iceberg basiert. Es bietet eine Reihe steckbarer Datenselbstoptimierungsmechanismen und Verwaltungsdienste mit dem Ziel, den Benutzern eine sofort einsatzbereite Lake-Warehouse-Nutzung zu ermöglichen. Erfahrung .
01 Über den Autor
Yu Zhiqiang , Leiter der Big-Data-Center-Plattformgruppe von Zhejiang Telecom, verfügt über mehr als 10 Jahre Erfahrung im Aufbau und in der Implementierung von Data Warehouses und Big Data . Erfahrene kommerzielle MPP-Datenbank Vertica und Open-Source-MPP-Datenbank StarRocks-DBA. Derzeit ist er hauptsächlich an der Konstruktion und Implementierung der integrierten Lake-Warehouse-Architektur auf Basis von Apache Iceberg und dem Open-Source-MPP-Produktdatenanwendungsmarkt beteiligt.
02 Apache Iceberg bei Zhejiang Telecom
Warum Iceberg wählen?
Das Big Data Center von Zhejiang Telecom ist hauptsächlich für die Geschäftsdatenaggregation und Data Warehouse-Produktion der Telekommunikation sowie für einige Datenanwendungen verantwortlich. Die Innovation der Big-Data-Architektur hat bisher im Allgemeinen drei Phasen durchlaufen .
Phase 1: Data-Warehouse-Transformation Hive-Erkundung
Mit der Iteration des Big-Data-Systems begannen wir mit dem Aufbau eines auf Hive basierenden Echtzeitanalyse-Big-Data-Systems und untersuchten gleichzeitig die Machbarkeit der Umwandlung des Data Warehouse in Hive. Nach dem Wechsel zu Hive stießen wir jedoch auf die folgenden Probleme :
-
Bei Verwendung der MR-Ausführung ist die Offline-Stapelverarbeitung ineffizient und die Produktionsabschlusszeit verzögert sich im Vergleich zur kommerziellen MPP-Datenbank um 4 bis 5 Stunden.
-
Das Fehlen von Einschränkungen relationaler Datenbanken, strenge Feldtypbeschränkungen, ACID-Semantik und die Unterstützung von Tools und Plattformen von Drittanbietern haben zu höheren Folgekosten für die Datenqualitätspflege und einer minderwertigen Datenqualität geführt.
Basierend auf den oben genannten Faktoren unterbrach Data Warehouse den Transformationsprozess von Hive und wandte sich wieder der Suche nach günstigeren und kommerzielleren MPP-Produkten zu (hauptsächlich ausgehend vom ursprünglichen MPP-Zeilenspeicherengpass und der Einführung einer spaltenorientierten MPP-Speicherdatenbank auf Basis der x86-Architektur). Die abgeschlossene Big-Data-Cluster-Synchronisierung basiert auf der Hive-Exploration, um einige Datenanwendungsaufgaben durchzuführen, die keine hohe Aktualität erfordern. Der Vorgang zum Schreiben von Daten in Hive ist wie folgt:
Das hier abgeleitete Tool wird hauptsächlich vom lokalen Sammlungsteam über Java entwickelt. Es extrahiert und generiert regelmäßig formatierte Textdateien aus der Bibliothek, indem es auf Oracle zugreift und sie dann in Hive schreibt. Damit ist die Synchronisierung der Geschäftsdaten mit den Data Warehouse-Daten abgeschlossen. Eine wesentliche Grundlage dieser Methode besteht darin, dass die Leseleistung von Oracle aus der Datenbank garantiert ist und die Verwendung der Geschäftssystembibliothek nicht beeinträchtigt wird. Die reguläre Triggermethode führte jedoch auch dazu, dass die Datenaktualität in Hive relativ schlecht war.
Phase 2: Die Verlagerung von Geschäftssystemen in die Cloud führt zu architektonischen Anpassungen der Back-End-Data-Warehouses und Anwendungssysteme
Als Zhejiang Telecom anschließend mit der Migration des Systems in die Cloud begann, wechselte die Geschäftssystembibliothek schrittweise von Oracle zu TeleDB (Telecoms selbst entwickelte relationale Datenbank auf Basis von MySQL). Die traditionelle Datenflussverbindung zum direkten Lesen von Geschäftsbibliotheksdaten und Das Schreiben in das Data Warehouse-System der TeleDB-Geschäftsbibliothek verursacht großen Druck. Aufgrund dieser Probleme haben sich auch unsere Datenverbindungen verändert.
Das abgeleitete Tool verwendet hier hauptsächlich zwei Produkte. Eines stammt von einem externen Produkt, das über die Open-Source-Canal-Technologie gepackt wird. Da dieses Produkt später nur TeleDB anpasste, entsprach es nicht den tatsächlichen Anforderungen (TelePG wurde später in der Produktion eingeführt ( Telecom basiert auf einer von Telecom selbst entwickelten Postgresql-Datenbank) und führte später das von Telecom selbst entwickelte Cross-IDC-Synchronisationstool ein, das die Innovation der Data Warehouse-ODS-Schicht von der Offline-Datenerfassung zur Echtzeit-Datenerfassung ermöglichte Die Aktualität der Daten des Hive-Datensystems für Geschäftsanalysen ist immer noch relativ schlecht.
Phase 3: Überdenken Sie die Richtung von Big Data und bauen Sie einen integrierten Lake-Warehouse-Cluster auf
Nachdem sich die Cloud-Migration des Produktionssystems stabilisiert hat, haben auch das Data Warehouse und der Application Mart mit dem Prozess der Cloud-Migration begonnen. Wir haben die Positionierung und Richtung von Big Data überdacht und überlegt, die nach und nach marginalisierten Big-Data-Cluster neu aufzubauen, um Zhejiang Telecom zu unterstützen. Echtzeit-Aggregation, Integration und Rekonstruktion von Data Warehouses für alle Geschäftssystemdaten. Der ursprüngliche CDH-Cluster wurde auf die von China Telecom entwickelte Big-Database-Version aktualisiert. Für die Synchronisierung muss ein Format für die Basis des Lake Warehouse ausgewählt werden, das das Schreiben und Lesen von Daten in Echtzeit unterstützt. Mit der allmählichen Reife der Data-Lake-Technologie und im Zusammenhang mit der Ermutigung der Gruppe, Big-Data-Teams zu Open Source zu bewegen, ergab unsere Untersuchung, dass Data-Lake-Produkte das Problem des Schreibens und Lesens von Daten in Echtzeit gut lösen können.
Nach dem Vergleich von Hudi, Delta Lake und Iceberg glauben wir, dass Iceberg nicht nur das Schreiben von CDC-Daten gut unterstützt, sondern auch eine umfassendere Unterstützung für Streaming-Batch-Engines und MPP-Datenbanken bietet. Je nach Geschäftsanalyseszenario können verschiedene Engines ausgewählt werden, um den Leistungsanforderungen gerecht zu werden. Die NetEase-Datenentwicklungs- und Verwaltungsplattform EasyData (im Folgenden als NetEase EasyData bezeichnet) und Wushu BI unterstützen Iceberg ebenfalls gut. Letztendlich haben wir uns für Iceberg als neues Tischformat entschieden.
Auch hier hat die Datenanbindung zwei Phasen durchlaufen :
-
Bühne eins:
Kafka wurde hauptsächlich durch die Echtzeitentwicklung des FlinkSQL-Moduls von NetEase EasyData in Iceberg geschrieben. Aufgrund der unzureichenden Garantie des ursprünglichen Synchronisierungstools und der Einführung des Rechenzentrums wurde die Datenverbindung jedoch optimiert und angepasst.
-
Stufe zwei:
In den frühen Tagen wurde TeleDB über die Echtzeit-Datenübertragung von NetEase EasyData (basierend auf FlinkCDC) in Echtzeit auf Iceberg geschrieben. Da das Online-Aufgabenvolumen immer größer wurde, traten unvollständige Probleme bei der Anpassung der von Telecom selbst entwickelten Datenbanken TeleDB und TeleDB auf TelePG wurde entdeckt. Später, aufgrund der engen Zeit für den Projektstart, hat unser Team eine selbst entwickelte Datensammlungsplattform in den See eingeführt, die auf FlinkCDC-Funktionen basiert, um die Echtzeiteingabe von Geschäftsdaten in den See zu realisieren. Der Gesamtbetrieb ist derzeit stabil, aber Ressourcenoptimierung und Benutzerfreundlichkeit erfordern weitere Forschung und Entwicklung.
Geschäftspraktiken
Die Datenquellen unseres Teams stammen aus einer Vielzahl von Quellen, einschließlich Geschäftsdaten aus der BMO-Domäne von Zhejiang Telecom und anderen Systemen. Nachdem die Daten in die ODS-Schicht gelangt sind, werden sie von DWD und DWS verarbeitet. Anschließend werden auf der Youshu-Plattform verschiedene Berichte entsprechend den unterschiedlichen Anforderungen des Geschäftsanalyseszenarios (Echtzeit- und Offline-Berichte) generiert Eingebettet in die Geschäfts- und Analyseanwendungen, die das Personal täglich nutzt, stehen jedem Betriebsknoten zur Verfügung.
Unterschiedliche Nutzungsszenarien von Berichten bestimmen die Reaktionsgeschwindigkeit von Daten, was auch bestimmt, dass wir unterschiedliche Berechnungs-Engines verwenden müssen. Für die tägliche Self-Service-Analyse verwenden wir Spark und Trino, um die Abfrage von Iceberg-Berichten zu unterstützen. Die Stapelverarbeitung der Data Warehouse-Produktionsschicht erfolgt hauptsächlich offline und basiert hauptsächlich auf Spark. Für Szenarien mit hohen Anforderungen an die Reaktionsgeschwindigkeit in der Anwendungsschicht Wir werden die Doris-Datenbank (Katalog mit direktem Zugriff auf die Iceberg-Tabelle) verwenden, um die Anforderungen verschiedener Szenarien zu unterstützen.
Verwendung
Nachdem wir Iceberg als Tabellenformat des Data Warehouse-Systems festgelegt haben, haben wir die meisten ODS in Iceberg konvertiert und werden DWD und DWS in Zukunft schrittweise in Iceberg konvertieren.
Die aktuelle Gesamtspeicherkapazität der Iceberg-Tabelle beträgt 1,1 PB und es wird erwartet, dass sie nach Abschluss der Transformation aller Data Warehouses 10 bis 15 PB betragen wird. Darunter werden fast 10.000 Iceberg CDC-Tabellen in Echtzeit geschrieben, und es wird geschätzt, dass nach Abschluss der ersten Transformation insgesamt 30.000 bis 40.000 Iceberg-Tabellen geschrieben werden.
03 Amoro bei Zhejiang Telecom
Warum Amoro wählen?
Beim Schreiben in Echtzeit in die Iceberg-Tabelle wird eine große Anzahl kleiner Dateien generiert. Insbesondere um die Datenkonsistenz sicherzustellen, haben wir in vielen Szenarien den Upsert-Modus aktiviert (in diesem Modus wird jedes Mal, wenn ein Datenelement geschrieben wird, ein Es werden Einfüge- und Löschdaten generiert.) Das Generieren einer großen Anzahl von Gleichheits-Löschdateien verschärft das Problem kleiner Dateien, hat große Auswirkungen auf die Abfrageleistung und verursacht sogar OOM auf der Engine-Seite. Daher ist die rechtzeitige Überwachung und Zusammenführung kleiner Dateien sowie die Reduzierung von Gleichheitslöschdateien sehr wichtig, um die Verfügbarkeit von Iceberg-Tabellen sicherzustellen.
Beim Zusammenführen von Iceberg-Dateien sind wir hauptsächlich auf die folgenden Schwierigkeiten gestoßen :
- Der Zusammenführungseffekt von Dateien mit Gleichheitslöschung ist nicht ideal : Wir verwenden die von der Iceberg-Community bereitgestellte Zusammenführungsmethode und planen regelmäßig Flink Spark-Aufgaben zum Zusammenführen von Dateien. Diese Methode zum Zusammenführen von Dateien durch Umschreiben ist mit Hunderten von G Daten relativ teuer . Das Zusammenführen kann jedes Mal mehrere Stunden oder sogar länger dauern, und es kann immer noch Probleme geben, wenn die Equality-Delete-Dateien nicht sofort nach Abschluss des Zusammenführens gelöscht werden.
- Ein großer Rückstand an Gleichheitslöschungsdateien führt zu einem Zusammenführungsfehler : Sobald der Dateistatus der Tabelle nicht rechtzeitig erkannt wird oder der Gleichheitslöschungsrückstand aus einem Zusammenführungsfehler, dem Dateizusammenführungsplan, dem Speicherverbrauch sowie dem Lese- und Schreibaufwand resultiert sind sehr groß, oft aufgrund von OOM, zu langer Ausführungszeit und anderen Problemen. Schließlich kann die Zusammenführung nicht abgeschlossen werden und die Tabelle kann nur wiederhergestellt werden, was die Wartungskosten erheblich erhöht.
Basierend auf den oben genannten Problemen hoffen wir, über ein ausgereiftes System zu verfügen, das uns dabei helfen kann, Tabellen mit vielen fragmentierten Dateien rechtzeitig zu erkennen und diese Tabellen zeitnah zu optimieren. Durch Recherchen haben wir herausgefunden, dass Amoro dieses Szenario sehr gut lösen kann und Amoro eine Vielzahl von Funktionen bietet, die uns dabei helfen, die Tabellenoptimierung besser zu verwalten :
-
Die Web-Benutzeroberfläche zeigt Indikatoren zur Tabelle und zur Optimierung an, die uns dabei helfen können, den Dateistatus der Tabelle, die Schreibhäufigkeit sowie die Details und den Betriebsstatus der Optimierung intuitiver zu beobachten.
-
Permanente Aufgaben automatisieren die Optimierungstabelle kontinuierlich
-
Flexible Erweiterung und Verkleinerung der Optimiererressourcen
-
Optimieren der Ressourcen isolierter Tabellen durch die Optimierergruppe
Verwendung
Nach der Bereitstellung von Amoro haben wir alle Iceberg-Tabellen schnell verbunden. Wir haben während der ersten Bereitstellungs- und Debugging-Phase viele Tests und Überprüfungen durchgeführt und gleichzeitig die Methode zur Erstellung der Iceberg-Tabelle optimiert (z. B. die Verwendung von Partitionen usw.). Wir sind auch sehr zufrieden Vielen Dank an die Community für ihre Unterstützung. Tolle Unterstützung. Derzeit haben wir insgesamt zwei Optimierungsgruppen basierend auf der Größe und dem Geschäft der Tabelle unterteilt. Die Gesamtressourcen verwenden 78 Kerne und 776 GB Speicher (was relativ mehr Speicherressourcen verbraucht) und können kleine Dateien stabil und effizient verwalten und zusammenführen.
Wirkung
Amoro sorgt für eine effiziente und stabile Zusammenführung
Amoro bietet eine einfache Minor-Optimierungsmethode, die kleine Dateien zusammenführt und das Umschreiben großer Dateien vermeidet, während gleichzeitig Equality-Delete-Dateien in Pos-Delete-Dateien mit höherer Abfrageleistung konvertiert werden. Im Vergleich zur Dateizusammenführungsmethode der Iceberg-Community weist diese Zusammenführungsmethode einen geringeren Overhead auf, sodass sie häufiger ausgeführt werden kann und der Ausführungszyklus auf Minutenebene liegt, wodurch der Rückstand kleiner Dateien effektiv vermieden wird.
Vor der Verwendung von Amoro lag die Anzahl der von CDC häufig geschriebenen Dateien zum Löschen von Gleichheit in der Iceberg-Tabelle häufig über 1.000, und die Größe der Datei zum Löschen von Gleichheit, die einer einzelnen Datendatei zugeordnet war, lag über 5 GB.
Nach der Verwendung von Amoro bleiben das Gleichheitslöschen der Iceberg-Tabelle und die Anzahl der kleinen Dateien unter 50.
Amoro kümmert sich um den Rückstand an Gleichstellungslöschdateien
Nachdem wir die Upsert- Konfiguration für alle Iceberg-Tabellen aktiviert haben , besteht das Problem darin, dass sich in den Iceberg- Tabellen eine große Anzahl von Equality-Delete- Dateien befindet. Sobald der Equality-Delete- Rückstand auftritt, kann es leicht zu OOM der Zusammenführungsaufgabe kommen . Dies liegt daran , dass im Iceberg-Plan-Aufgabenmechanismus die Datendatei mit allen Dateien verknüpft wird , deren Sequenznummern größer als sie selbst sind ( die Sequenznummer der Datei ist standardmäßig gleich der Sequenznummer des Snapshots und die Sequenznummer von Schnappschuss wird automatisch vergrößert ) . Daher verweisen Dateien, die für historische Snapshots übermittelt werden, auf viele Gleichheitslöschdateien . Diese Gleichheitslöschdateien müssen während des Iceberg MOR und der Dateizusammenführung in den Speicher eingelesen werden, um die Daten in der zugehörigen Datendatei zu löschen. Dies verbraucht viel Speicher.
Als Reaktion auf die oben genannten Probleme hat die Amoro-Community Optimierungen bei der Optimierung vorgenommen . Im Upsert-Szenario beziehen sich viele Daten in der Equality-Delete-Datei, die mit der Datendatei verknüpft sind, nicht auf die aktuelle Datendatei, sodass tatsächlich viele ungültige Inhalte im Equality-Delete-Lesevorgang im Speicher vorhanden sind, diese jedoch belegen viel Erinnerung. Darüber hinaus kann Amoro die Größe der Datendatei in jeder Aufgabe begrenzen, indem es bei der Planung selbstoptimierender Aufgaben die Konfiguration self-optimizing.max-task-size-bytes konfiguriert, sodass die Datendateigröße jeder Aufgabe erwartet, aber gleich gelöscht wird Die Dateigröße ist unvorhersehbar. Dann können wir den Inhalt der Datendatei in der Aufgabe verwenden, um Datensätze mit Gleichheitslöschung herauszufiltern, die nicht im Speicher zwischengespeichert werden müssen.
Die spezifische Implementierungsmethode besteht darin, dass wir einen BloomFilter anhand der Gleichheitsfelddatensätze der Datendatei in der Aufgabe erstellen. Durch diesen BloomFilter filtern wir die Daten heraus, die Schnittmengen zwischen den Gleichheitsfelddaten und der Datendatei in den vielen zugeordneten Gleichheitslöschdateien aufweisen mit der selbstoptimierenden Datendatei und laden Sie sie. Der Speicher wird für die Teilnahme an MOR verwendet, was die Speichernutzung erheblich reduziert und so das Upsert-Szenario „Equality-Delete-Datei“ vermeidet, das bei vielen Dateien zu OOM des Optimierers führt.
04 Zukunftsplanung
-
In Zukunft werden wir die aktuelle Iceberg-Version auf die von Telecom selbst entwickelte Iceberg-Version aktualisieren. Zunächst werden wir die Anzahl der Dateien optimieren, die während des Echtzeit-Schreibens von Flink generiert werden, um den Druck auf Amoro bei der Selbstoptimierung zu verringern. Synchronisierung wird aktiv mit allen Beteiligten mitgestaltet werden. Iceberg Open-Source-Community
-
Verlagern Sie die DWD- und DWS-Schichten schrittweise von kommerziellen MPP-Datenbanken zu integrierten Lake-Warehouse-Clustern auf Iceberg-Basis
-
In Anbetracht der Tatsache, dass es in Zukunft möglicherweise erforderlich sein könnte, den Datensee in Echtzeit zu lesen, unterstützt Iceberg das Lesen von V2-Tabellen in Echtzeit immer noch nicht. Daher untersuchen und versuchen wir auch, Amoro Mixed Iceberg zu verwenden, um das reale Szenario zu lösen -Zeitliches Auslesen des Data Lake.
Abschließend möchte ich mich noch einmal bei der Amoro-Community für ihre starke Unterstützung bedanken und wünsche der Amoro-Community immer bessere Besserung.
Ende~
Wenn Sie sich für Data Lake, Lake-Warehouse-Integration, Tabellenformat oder Amoro-Community interessieren, kontaktieren Sie uns bitte für ausführliche Gespräche.
Weitere Informationen zu Amoro finden Sie unter:
- Offizielle Website: amoro.netease.com/
- Quellcode: github.com/NetEase/amo…
Community-Kommunikation: Suchen Sie nach kllnn999 und fügen Sie Ashida Aina-Assistentin WeChat hinzu, um der Community beizutreten
Autor: Yu Zhiqiang
Herausgeber: Viridian