.jpg)
Eine der ersten Aufgaben bei einem Migrationsprojekt von Hive zu BigQuery Data Warehouse ist die Übertragung der benutzerdefinierten Funktionen von Hive, einschließlich UDFs (User-Defined Functions), UDTFs (User-Defined Table-Generating Functions) und UDAFs (User-Defined Aggregate Functions) auf die BigQuery-Seite. Da es in diesem Bereich erhebliche Unterschiede zwischen Hive und BigQuery gibt, ist dieser Migrationsschritt alles andere als trivial.
In diesem Beitrag stelle ich bewährte Strategien und Best Practices für diesen wichtigen Prozess vor.
Apache Hive erweitert seine Abfragemöglichkeiten mit benutzerdefinierten Funktionen. Diese Funktionen ermöglichen es Ihnen, die Standardfunktionalität von Hive zu erweitern, um spezifische, benutzerdefinierte Datenverarbeitungsanforderungen zu erfüllen. In Hive werden diese benutzerdefinierten Funktionen in der Regel in Java geschrieben, indem bestimmte Schnittstellen und abstrakte Klassen implementiert werden.
Das Hauptunterscheidungsmerkmal zwischen diesen Funktionen ist die Kardinalität der Eingabe- und Ausgabezeilen.
Wenn wir über UDFs sprechen, bietet Google BigQuery eine vielseitige und leistungsstarke Plattform für das Hinzufügen benutzerdefinierter Funktionen und die Anpassung an verschiedene Datenverarbeitungsanforderungen. Im Gegensatz zu Hive, wo benutzerdefinierte Funktionen überwiegend Java-basiert sind, bietet BigQuery drei primäre Möglichkeiten zur Erweiterung seiner Fähigkeiten:
Mit dem richtigen Setup können alle diese Optionen nahtlos von SQL aus verwendet werden, so wie Sie eine native BQ-Funktion verwenden würden.
Zum Zeitpunkt der Erstellung dieses Blogbeitrags bietet BigQuery keine Möglichkeit, benutzerdefinierte UDAFs oder UDTFs zu implementieren. Wenn Sie also einige dieser benutzerdefinierten Funktionen auf der Hive-Seite haben, müssen Sie ein wenig kreativ sein, um sie zu ersetzen.
Bei unseren Migrationsprojekten dient der unten stehende Entscheidungsbaum als Leitfaden, um den am besten geeigneten Weg für die Migration von Hive UDFs zu BigQuery zu ermitteln, wobei die Fähigkeiten und Einschränkungen von BigQuery im Vergleich zu den benutzerdefinierten Funktionen von Hive berücksichtigt werden. Das Ziel ist es, sicherzustellen, dass alle notwendigen Transformationen und Berechnungen, die von den ursprünglichen Hive UDFs durchgeführt werden, in der neuen BigQuery-Umgebung erhalten bleiben und optimiert werden.
.png)
Die Reise beginnt mit der grundlegenden Frage, ob die UDF im neuen BigQuery Data Warehouse benötigt wird. Während der Bewertung prüfen wir, ob die Funktion in einer Transformation verwendet wird, die auf die BQ-Seite migriert werden soll. Ist dies nicht der Fall, erhalten wir eine einfache Lösung: Es ist keine Migration erforderlich, und wir können uns mit der Einfachheit dieses Ergebnisses trösten. Wenn die UDF jedoch tatsächlich benötigt wird, erkunden wir als Nächstes die native Funktionsbibliothek von BigQuery, um zu sehen, ob es eine vorhandene Funktion gibt, die die Fähigkeiten unserer Hive-UDF replizieren kann. Wenn eine native BigQuery-Funktion verfügbar ist, übernehmen wir sie und nutzen die in BigQuery integrierte Effizienz.
In Fällen, in denen BigQuery keine native Alternative anbietet, untersuchen wir die Art der Funktion, mit der wir es zu tun haben. Bei einer Standard-UDF prüfen wir, ob eine Neuimplementierung in BigQuery SQL möglich ist; wenn ja, fahren wir mit diesem SQL-zentrierten Ansatz fort. Wenn nicht, wenden wir uns den serverlosen Lösungen von Google Cloud zu und nutzen die Funktion BQ Remote UDFs. Diese Option ist attraktiv, da wir Java verwenden und den Kernfunktionscode unverändert lassen können. Sollten Remote-Funktionen in unserem Fall aus irgendeinem Grund nicht verfügbar sein, können wir jederzeit auf JS UDFs zurückgreifen.
Bei UDAFs hängt die Entscheidung von der Datenmenge ab, insbesondere davon, ob die Aggregation innerhalb eines begrenzten Bereichs erfolgt. Für überschaubare Datengruppierungen können wir mit der ARRAY_AGG-Funktion von BigQuery benutzerdefinierte Aggregationen erstellen. Bei unhandlicheren Aggregationen müssen wir unseren Ansatz möglicherweise komplett umgestalten oder die Verarbeitung auf Google Cloud Dataflow oder Dataproc verlagern, um Skalierbarkeit und Leistung zu gewährleisten.
Wenn wir bei UDTFs im Bereich von SQL bleiben möchten, ist der Weg einfach: Wir wandeln die Funktion um, um Elemente als Array zu generieren, und verwenden die UNNEST-Funktion von BigQuery, um die Arrays in mehrere Zeilen zu zerlegen. Wenn dieser Ansatz nicht funktioniert, können wir jederzeit auf Cloud Dataflow oder Dataproc zurückgreifen, um unsere Funktionalität zu implementieren.
Dieser Entscheidungsbaum hilft nicht nur bei der methodischen Migration der benutzerdefinierten Funktionen von Hive zu BigQuery, sondern stellt auch sicher, dass jeder Schritt mit den optimalen Praktiken und der Architektur von BigQuery übereinstimmt, um einen reibungslosen und effizienten Übergang zu gewährleisten.
Das war's mit unserem Leitfaden zum Übertragen der benutzerdefinierten Funktionen von Hive auf BigQuery. Es ist nicht gerade ein Spaziergang, aber mit der Roadmap, die wir erstellt haben, ist es definitiv machbar. Betrachten Sie den Entscheidungsbaum als Ihr zuverlässiges GPS, das Ihnen hilft, sich bei der Migration zurechtzufinden, ohne sich zu verirren.
In den kommenden Beiträgen werde ich echte Migrationsgeschichten aufschlüsseln - keine Floskeln, nur die direkte Information darüber, wie diese Tools in der Praxis funktionieren. Wir werden über die Erfolge, die Fehlschläge und die Hacks berichten, die jede Migration zu einem Gewinn gemacht haben.
Wenn Sie sich also auf den großen Wechsel zu BigQuery vorbereiten, bleiben Sie am Ball. Wir haben die Insider-Tipps, die Ihnen helfen werden, die Komplexität zu durchbrechen und das Beste aus dem Kraftpaket von Google Cloud herauszuholen.
Wir sehen uns im nächsten Beitrag, in dem wir mit echter Migrationsmagie auf den Punkt kommen.
