Die Migration eines Data Warehouse von Hive zu BigQuery bietet viele Vorteile, wie Skalierbarkeit, Leistung und Kosteneffizienz. Während dieser Umstellung ist die Sicherstellung der Treue und Genauigkeit der Daten von größter Bedeutung. Robuste Datenvalidierungsmechanismen sind erforderlich, um sicherzustellen, dass in Ihren neu migrierten Pipelines keine Regression stattgefunden hat. In diesem Blogbeitrag geben wir einen allgemeinen Überblick über den Validierungsprozess für Datenpipelines während einer Data Warehouse-Migration.
Bei der Datenvalidierung wird sichergestellt, dass die Daten korrekt und konsistent sind und den vordefinierten Standards oder Anforderungen entsprechen. Das Ziel der Datenvalidierung besteht darin, Fehler oder Inkonsistenzen in den Daten zu erkennen und zu beheben und so ihre Qualität und Zuverlässigkeit für die Verwendung bei der Entscheidungsfindung, Analyse und anderen Geschäftsprozessen zu verbessern. Da Migrationen von Hive zu BigQuery zu Unterschieden in den Ausgaben der Datenpipeline führen können, ist die Datenvalidierung von entscheidender Bedeutung, um sicherzustellen, dass Ihre Daten nach der Migration im gleichen Zustand bleiben.
Der Prozess einer Data-Warehouse-Migration umfasst im Allgemeinen drei Schritte. Zunächst müssen Sie Ihre Datenpipelineskripte oder -abfragen von Ihrem ursprünglichen Dialekt in den Zieldialekt übersetzen (z. B. HiveQL in BigQuery SQL). Anschließend führen Sie Ihre ursprünglichen Pipelines parallel zu den neu migrierten Pipelines aus. Der letzte Schritt besteht dann in der Datenvalidierung und der Behebung möglicher Fehler, die während des Prozesses entdeckt werden.
Da ETL-Pipelines oft aus mehreren Schritten und Zwischentabellen bestehen, stellt sich zunächst die Frage, in welchen Phasen ich meine Tabellen validieren sollte. Unserer Erfahrung nach ist die beste Lösung, jede Tabelle innerhalb der aktuellen Pipeline zu validieren, die von einem externen Vorgang verwendet wird. Zum Beispiel, wenn eine Tabelle als Eingabedaten für ein Modell für maschinelles Lernen verwendet wird, oder wenn eine Tabelle als Eingabe für eine andere Pipeline verwendet wird. Auf diese Weise können Sie Ressourcen einsparen, da die Validierung jedes einzelnen Schritts innerhalb einer Pipeline zu zusätzlichen Kosten und Aufwand führt. Wenn Sie feststellen, dass Ihre Tabelle Fehler aufweist, die möglicherweise aus einer früheren Phase Ihrer Pipeline stammen, können Sie die zusätzlichen Validierungsschritte an diesem Punkt hinzufügen;
Für die Datenvalidierung haben wir ein Tool implementiert, das eine Abfrage erstellt, die verschiedene Vergleichswerte für die Quell- und die Zieltabelle berechnet und dann die beiden miteinander vergleicht. Hier gibt es zwei Ansätze, die man verfolgen kann. Erstens lässt man jede Tabelle an ihrem aktuellen Speicherort (z. B. bleiben Hive-Tabellen in Hive und BigQuery-Tabellen in BigQuery), und dann fragt man jede Tabelle ab und zieht die resultierenden Werte an einen gemeinsamen Speicherort, z. B. das Laden in Pandas DataFrames. Ein Vorteil dieses Ansatzes ist, dass die Tabellen über verschiedene Plattformen hinweg verglichen werden können. Wenn Sie jedoch mit umfangreichen Tabellen arbeiten, können Sie auf mögliche Speicher- oder Berechnungsbeschränkungen stoßen. Nach unserer Erfahrung ist es von Vorteil, die ursprüngliche Hive-Tabelle in BigQuery hochzuladen. Dadurch können wir die Validierungsabfrage direkt in BigQuery durchführen und dessen Verarbeitungsleistung nutzen;
Sobald Sie sowohl Ihre ursprünglichen als auch die migrierten Tabellen fertig haben, ist es an der Zeit, sie gegeneinander zu validieren. In diesem Abschnitt werde ich vier Hauptvalidierungen erläutern, die wir empfehlen, durchzuführen. Zur Veranschaulichung jedes Ansatzes verwenden wir die folgenden zwei Tabellen, von denen eine die von der ursprünglichen Pipeline generierten (Quell-)Daten und die andere die (Ziel-)Daten nach der Migration enthält.
Quelle: Tabelle
Zieltabelle
Bei der Migration von Daten von Hive zu BigQuery besteht ein einfacher erster Schritt darin, die Größe der Tabellen zu überprüfen, um sicherzustellen, dass alle Daten erfolgreich übertragen worden sind. Dazu werden die Zeilenzahl und das Datenvolumen (z. B. in kB) zwischen den Hive- und BigQuery-Tabellen verglichen, um etwaige Diskrepanzen oder Datenverluste während des Migrationsprozesses zu erkennen. Da unsere beiden Eingabetabellen die gleiche Größe und Anzahl von Zeilen hatten, wurden beide Validierungen erfolgreich durchgeführt.
Die Schemavalidierung von Tabellen ist wichtig, da nachgelagerte Verbraucher möglicherweise erwarten, dass die Daten von einem bestimmten Typ sind und dass die Spalten bestimmte Namen haben. Die Schemavalidierung ist nicht immer eine einfache Aufgabe, z. B. wenn Strukturspalten mit Unterfeldnamen, bei denen die Groß- und Kleinschreibung beachtet wird, auftreten. Hier ist es wichtig zu beurteilen, ob solche Probleme im Kontext Ihrer eigenen Systeme legitim sind.
In der folgenden Ausgabe sehen wir, dass die Validierung fehlschlägt, wenn wir den Datentyp der Spalte "Alter" vergleichen. In unseren ursprünglichen Daten war dies eine Ganzzahl, während es sich in den migrierten Daten nun um eine Fließkommazahl handelt.
Statistiken auf Spaltenebene können nützlich sein, um festzustellen, ob die übersetzte Pipeline dieselben Daten wie Ihre ursprüngliche Pipeline erzeugt. Die Berechnung von Statistiken wie Summe, Durchschnitt, Minimum, Maximum oder Perzentile kann Aufschluss über die Verteilung der Daten innerhalb einer bestimmten Spalte geben. Der Vorteil dabei ist, dass die Aggregation der Daten in einzelne statistische Werte schnelle und gut skalierbare Ergebnisse ermöglicht. Dabei sind jedoch einige wichtige Aspekte zu beachten. Erstens lässt sich nicht jeder Datentyp einfach in solche Metriken umwandeln. Wie erhält man die Summe eines String-Wertes? In solchen Fällen müssen die Daten zunächst in eine numerische Darstellung umgewandelt werden, auf deren Grundlage diese Statistiken berechnet werden können. Im Falle einer Zeichenkettenspalte könnte ein Ansatz darin bestehen, die Länge jeder Zeichenkette zu berechnen und sie zu summieren. Ein solcher Ansatz ist jedoch nicht robust, da kleine Unterschiede unentdeckt bleiben können;
Dies wird durch die nachstehenden Validierungsergebnisse veranschaulicht. Hier sehen wir, dass alle drei Überprüfungen erfolgreich waren. Wenn wir uns jedoch die Daten in den einzelnen Tabellen ansehen, stellen wir fest, dass es sowohl in der Spalte "Name" als auch in der Spalte "favorite_food" tatsächlich Diskrepanzen gibt. In der Spalte "Name" ist der Name "Jörg" in unserer Quelltabelle nun "J?rg" in unserer Zieltabelle. Da beide jedoch die gleiche Länge haben, bleibt dies unentdeckt. Bei der Spalte "favorite_foods" gibt es in der letzten Zeile einen Unterschied im zweiten Element der Arrays. Da wir in diesem Fall den Mindestwert der Länge der Arrays genommen haben, bleibt die Differenz ebenfalls unentdeckt. In solchen Fällen sind Zeilenvalidierungen erforderlich, um die Unterschiede richtig zu erkennen.
Während Vergleiche auf Spaltenebene ein grobes Bild Ihrer Daten vermitteln können, bieten Vergleiche auf Zeilenebene eine feinere Prüfung der Daten zwischen zwei Tabellen. Techniken wie Hashing, Verkettung und der direkte Vergleich auf Zellebene helfen dabei, Inkonsistenzen in den Datenwerten zu erkennen. Diese Art des Vergleichs ist jedoch nicht ohne besondere Herausforderungen. Zum Beispiel der Abgleich von Zeilen mit zusammengesetzten Primärschlüsseln, die Verwaltung der Reihenfolge von Array-Elementen und die Handhabung verschachtelter Strukturen. Dies alles erfordert Lösungen, um genaue Validierungsergebnisse auf Zeilenebene zu erzielen;
Nachfolgend sehen wir die Ergebnisse der Zeilenüberprüfung, bei der alle drei Fälle fehlgeschlagen sind. Im ersten Fall sehen wir das Ergebnis eines Hash-Laufs über die Quell- und Zieltabelle, bei dem die Zeilen verbunden werden, deren "Name" "Sally" ist. In Anbetracht der unterschiedlichen Datentypen für die Spalte "Alter" kommt es zu einem Fehler. Als Nächstes führen wir einen Hash für die Zeilen durch, die durch den "Namen" "Jörg" verbunden sind. Da es jedoch keine übereinstimmende Zeile mit diesem Wert in der Zieltabelle gibt, gibt die Verknüpfungsoperation für alle Zielspalten "null" zurück und führt somit zu einem Fehlschlag beim Vergleich. Schließlich führen wir einen Zellvergleich der Spalte "Lieblingsnahrungsmittel" in den Zeilen durch, in denen der "Name" "Maria" lautet. Hier erkennen wir den Unterschied zwischen den beiden Feldern und erhalten einen Fehler beim Vergleich.
Sobald Sie Ihren Validierungsschritt für eine Reihe von Tabellen durchgeführt haben, werden Sie unweigerlich eine Inkonsistenz in Ihren migrierten Daten feststellen. In diesem Stadium müssen Sie manuell tiefer in die Daten eindringen, um die Ursache zu ermitteln. Hier haben sich zeilenbasierte Vergleiche als unschätzbar wertvoll erwiesen, da sie genau Aufschluss darüber geben, welchen Primärschlüssel die fehlerhafte Zeile hat. Inkonsistenzen können aus einer Vielzahl von Gründen auftreten, wobei die Hauptursachen Übersetzungsfehler und inhärente Unterschiede zwischen Ihren ursprünglichen und den migrierten Dialekten (z. B. Hive und BigQuery) sind;
Nachdem Sie alle während der Validierung festgestellten Dateninkonsistenzen beseitigt haben, sollten Sie Ihre Validierungsschritte noch eine Weile beibehalten, um die Zuverlässigkeit Ihrer Daten weiter zu überwachen. Die empfohlene Dauer eines solchen Überwachungszeitraums hängt von der Art Ihrer Datenpipelines ab.
Sobald Sie mit der Anzahl der bestandenen Validierungsiterationen für eine bestimmte Tabelle zufrieden sind, können Sie den Validierungsschritt ausschalten und sich darauf verlassen, dass Ihre neu migrierte Datenpipeline auch weiterhin qualitativ hochwertige Daten produzieren wird.
Dies sind die allgemeinen Richtlinien für die Datenvalidierung bei der Migration Ihrer Datenpipelines. In zukünftigen Beiträgen werden wir tiefer in die Details der wichtigsten hier behandelten Themen eintauchen und reale Beispiele und Lösungen aus unseren Erfahrungen mit der Migration von Datenpipelines zu Google Cloud BigQuery bereitstellen. Wenn sich Ihr Unternehmen also auf eine Umstellung auf Google Cloud vorbereitet, bleiben Sie dran, um von unseren eigenen Erfahrungen zu lernen, damit Sie Ihre Data Warehouse-Migration mit Zuversicht und Leichtigkeit bewältigen können.
