Wie kann die Qualität von Data-Warehouse-Daten sichergestellt werden?

Das Youzan Data Report Center bietet Händlern umfangreiche Datenindikatoren, darunter über 30 Seiten, über 100 Datenberichte und über 400 verschiedene Arten von Datenindikatoren, die Händlern helfen, Geschäfte rationaler und wissenschaftlicher zu betreiben, und auch direkt Analyse- und Entscheidungsmethoden für liefern geschäftliche Nutzung. Darüber hinaus haben die alltäglichen Aufgaben und Datentabellen auf niedriger Ebene Tausende von Ebenen erreicht.

Wie kann man angesichts eines so riesigen Datensystems eine Qualitätssicherungsstrategie als Test formulieren? Dieser Artikel beginnt mit vier Aspekten: 1. Youzan-Datenverbindung, 2. Testen der Datenschicht, 3. Testen der Anwendungsschicht und 4. Folgeplanung.

1. Youzan-Datenverbindung

1. Einführung in die Datenverbindung

Zunächst stelle ich das allgemeine Datenstrukturdiagramm von Youzan vor:

Von oben nach unten kann es grob in Application Service Layer, Data Gateway Layer, Application Storage Layer und Data Warehouse unterteilt werden.Plattformen wie Job Development und Metadata Management bieten grundlegende Funktionen für Data Computing, Task Scheduling und Datenabfrage.

Das Obige stellte eine vorläufige Einführung in die Gesamtarchitektur dar. Für die Qualitätskontrolle sind die beiden Kernteile: das Data Warehouse und der Datenanwendungsteil . Da diese beiden Teile zu den Kernverbindungen in der Datenverbindung gehören, kommt es im Vergleich zu anderen Ebenen häufiger zu täglichen Änderungen, und auch das Risiko von Problemen ist relativ groß.

Zweitens der Data-Layer-Test

1. Gesamtübersicht

Erstens kann die Qualitätssicherung der Datenschicht in drei Aspekte unterteilt werden: Aktualität, Integrität und Genauigkeit der Daten.

2. Aktualität der Daten

Datenaktualität bedeutet, wie der Name schon sagt, dass Testdaten rechtzeitig erstellt werden müssen. Die drei Schlüsselelemente der Aktualität sind: Zeitplanungszeit, Priorität und Datentermin . Die Priorität der Aufgabe bestimmt, wie viel Datenverarbeitungsressourcen sie erhält, und wirkt sich auf die Ausführungszeit der Aufgabe aus. Die Datenfrist ist ein einheitlicher Standard für die späteste Datenausgabezeit, die strikt eingehalten werden muss.

Unter diesen drei Elementen gehört die Datenfrist zu den „ allgemeinen Regeln “, auf die man sich in der Qualitätssicherungsphase konzentrieren muss. Basierend auf der Datenfrist können die Garantiestrategien für die Aktualität in zwei Typen unterteilt werden:

• Überwacht, ob die Offline-Datenaufgabe abgeschlossen ist. Diese Methode beruht auf der Überwachung und Alarmierung durch die Jobentwicklungsplattform von Youzan. Wenn die Datenaufgabe nicht fristgerecht abgeschlossen ist, werden Alarme in Form von E-Mail, Unternehmensmikro, Telefon usw. ausgegeben, um das entsprechende Personal zu benachrichtigen.

• Überprüfen Sie die Anzahl der vollständigen Tabelleneinträge oder die Anzahl der Partitionseinträge. Diese Methode stützt sich auf die Schnittstellenautomatisierungsplattform.Durch Aufrufen der dubbo-Schnittstelle wird beurteilt, ob der von der Schnittstellezurückgegebene Datenindex 0 ist und ob die Überwachungsdaten ausgegebenwerden.

Zweitens können wir auf die Anzahl von Fehlern und Wiederholungen achten.Wenn während der Ausführung der Aufgabe die anormale Situation von mehreren Fehlern und Wiederholungen auftritt, kann ein Alarm ausgelöst werden, damit das zuständige Personal dies wahrnimmt. Dieser Teil des Alarms ist eine Ergänzung zum Deadline Alarm, außerdem gibt es eine Funktionsintegration auf der Jobentwicklungsplattform Youzan.

3. Datenintegrität

Die Datenintegrität hängt, wie der Name schon sagt, davon ab, ob die Daten vollständig sind oder nicht, und konzentriert sich auf zwei Punkte: nicht viele Daten und nicht viele Daten.

• Es gibt nicht viele Daten: Überprüfen Sie im Allgemeinen die vollständigen Tabellendaten und wichtige Aufzählungswerte, um festzustellen, ob die Daten redundant, dupliziert oder ob der Primärschlüssel der Daten eindeutig ist.

• Es gibt viele Daten: Überprüfen Sie im Allgemeinen die vollständigen Tabellendaten, wichtige Felder (wie Primärschlüsselfelder, Aufzählungswerte, Datumsangaben usw.), um festzustellen, ob der Wert des Felds leer, null usw. ist.

Es ist ersichtlich, dass die Korrelation zwischen Datenintegrität und dem Geschäft selbst nicht so eng ist, und mehr ist die allgemeine Inhaltsprüfung der Data-Warehouse-Tabelle. Ausgehend von einigen grundlegenden Dimensionen können wir den Testfokus also in zwei Richtungen aufteilen: Tabellenebene und Feldebene.

Integrität auf Tabellenebene:

• Wenn die Gesamtzahl der Zeilen/Tabellengröße der gesamten Tabelle für die vollständige Tabellendimension überprüft wird und die Gesamtzahl der Zeilen/Gesamtgröße der Tabelle unverändert bleibt oder abnimmt, weist dies darauf hin, dass möglicherweise ein Problem mit den Tabellendaten vorliegt .

• Für die Partitionsdimension können Sie die Anzahl/Größe der Datenzeilen in der partitionierten Tabelle am aktuellen Tag überprüfen. Wenn der Unterschied zu groß (größer oder kleiner) im Vergleich zur vorherigen Partition ist, liegt möglicherweise ein Problem mit den Tabellendaten vor .

Derzeit hat die Youzan-Metadatenverwaltungsplattform verwandte Datenansichten integriert:

Integrität auf Feldebene:

• Eindeutigkeitsbeurteilung: Um die Eindeutigkeit des Primärschlüssels oder einiger Felder sicherzustellen, um eine Datenduplizierung und Datenverdopplung nach dem Verbinden mit anderen Tabellen zu verhindern, was zu großen endgültigen Statistiken führt.

Um beispielsweise festzustellen, ob die Bestellnummer in der Bestelltabelle der ods-Ebene eindeutig ist, schreiben Sie sql:

select 
count(order_no)
,count(distinct order_no) 
from ods.xx_order

Wenn die beiden gleich sind, bedeutet dies, dass der Wert „order_no“ in der Tabelle eindeutig ist; andernfalls bedeutet dies, dass der Wert „order_no“ in der Tabelle nicht eindeutig ist und es ein Problem mit den Tabellendaten gibt.

• Nicht-leeres Urteil: Stellen Sie sicher, dass wichtige Felder nicht leer sind, um Datenverluste nach leeren Daten und Tabellenverknüpfungen zu vermeiden, was zu weniger endgültigen Statistiken führt.

Um beispielsweise festzustellen, ob die Bestellnummer in der Bestelltabelle der Ods-Schicht null ist, schreiben Sie sql:

select 
count(*) 
from ods.xx_order 
where order_no is null

Wenn das Ergebnis gleich 0 ist, bedeutet dies, dass es keine Null in order_no gibt; wenn das Ergebnis größer als 0 ist, bedeutet dies, dass es einen Nullwert in order_no gibt und es ein Problem mit den Tabellendaten gibt.

• Beurteilung des Aufzählungstyps: Stellen Sie sicher, dass die Aufzählungsfeldwerte innerhalb des erwarteten Bereichs liegen, um geschäftliche schmutzige Daten zu vermeiden, die zu fehlenden/überflüssigen Datentypen in den endgültigen statistischen Ergebnissen führen.

Um beispielsweise zu beurteilen, ob alle Enumerationswerte im Feld shop_type in der Bestelltabelle des ods-Layers den Erwartungen entsprechen, schreiben Sie sql:

select shop_type from ods.xx_order group by shop_type

Analysieren Sie, ob die Abfrageergebnisse den Erwartungen entsprechen, um sicherzustellen, dass keine fehlenden/redundanten Aufzählungstypen vorhanden sind.

• Beurteilung der Datenvalidität: Beurteilung, ob das Datenformat den Erwartungen entspricht, und Verhinderung, dass das falsche Datenformat des Felds Fehler und fehlende Datenstatistiken verursacht. Am gebräuchlichsten sind Datumsformate yyyymmdd.

Sobald ein Datenintegritätsproblem auftritt, hat dies große Auswirkungen auf die Datenqualität. Daher ist die Integritätsstrategie besser für die Ods-Schicht geeignet, da wir erwarten, das Problem unangemessener Daten aus der Quelle zu finden und zu lösen, den Zeitverlust zu stoppen und die Ausweitung der Datenverschmutzung zu vermeiden, nachdem schmutzige Daten in den Downstream gelangen.

Darüber hinaus sehen wir, dass die Logik des Inhalts der Integritätsprüfung einfach und relativ fest ist und mit ein wenig einfacher Abstraktion als Vorlage erstellt werden kann. Als Test neigen wir dann eher dazu, Tools zur Überprüfung der Datenintegrität zu entwickeln. Derzeit ist Youzan "Data Shape Tool" implementiert. Hier sind einige meiner Ideen:

1. Für alle Tabellen gelten universelle Regeln, wie z. B. die Eindeutigkeit des Primärschlüssels der Tabelle.

2. Für verschiedene Typen wie numerische, Zeichenfolgen-, Aufzählungs- und Datumsformattypen werden allgemeine Regeln zur Datenbeurteilung aufgelistet.

3. Klassifizieren Sie jede Regel. Wenn beispielsweise der Primärschlüssel einer Tabelle nicht eindeutig ist, erfassen Sie ihn als kritisch. Der Anteil an Nullwerten in Feldern vom Typ String ist größer als 70 %, was als Warnung protokolliert wird.

4. Je nachdem, ob die Tabellendaten die oben genannten Regeln erfüllen, wird schließlich ein visueller Bericht implementiert, und Tester können die Datenqualität gemäß dem Berichtsinhalt bewerten.

4. Datengenauigkeit

Datengenauigkeit, wie der Name schon sagt, müssen die Daten „genau“ sein. Das Konzept der "Genauigkeit" ist relativ abstrakt, da es für uns schwierig ist, ein starkes logisches Urteil zu verwenden, um zu erklären, wie genau die Daten sind, und das meiste davon existiert in der Wahrnehmung. Daher ist Genauigkeitsprüfung auch eine Richtung, in der im Prozess der Datenqualitätssicherung relativ divergierend gedacht wird.

Nach der Zusammenfassung können wir die Korrektheit der Daten aus den Aspekten Feldselbstkontrolle, Datenhorizontalvergleich, Vertikalvergleich, Codereview etc. kontrollieren. Auch diese Prüfpunkte sind eng mit dem Geschäft verbunden.

4.1 Selbstkontrolle

Die Selbstprüfung von Daten bezieht sich auf die Überprüfung der Richtigkeit von Daten anhand ihrer eigenen Daten, ohne sie mit anderen Daten zu vergleichen, was die grundlegendste Art der Prüfung ist. Zu den üblichen Selbsttests gehören: Überprüfen, ob der numerische Index größer als 0 ist und der Verhältnisindex im Bereich von 0 bis 1 liegt. Solche Grundregeln wie die Datenintegrität können auch mit „Datenformwerkzeugen“ kombiniert werden, um das Testen zu unterstützen.

Beispielsweise muss für die Bestelltabelle der Zahlungsbetrag größer oder gleich 0 sein und es dürfen keine negativen Zahlen vorkommen.

select 
count(pay_price) 
from 
dw.dws_xx_order 
where par = 20211025 and pay_price<0

Wenn das Ergebnis 0 ist, bedeutet dies, dass der Zahlungsbetrag größer als 0 ist, was den Erwartungen entspricht; andernfalls, wenn das Zählergebnis größer als 0 ist, bedeutet dies, dass es ein Problem mit den Daten gibt.

4.2 Horizontaler Datenvergleich in der Tabelle

Der horizontale Vergleich innerhalb einer Tabelle kann als zwei oder mehr Felder in derselben Tabelle verstanden werden, die sich auf das Geschäft beziehen und eine bestimmte logische Beziehung haben, sodass sie für den Datenvergleich verwendet werden können.

Zum Beispiel ist es für die Bestelltabelle gemäß der tatsächlichen Geschäftsanalyse einfach zu erhalten: Für jedes Produkt in jedem Geschäft ist die Anzahl der Bestellungen >= die Anzahl der Personen, die Bestellungen aufgeben, schreiben Sie sql:

select 
kdt_id
,goods_id
,count(order_no)
,count(distinct buyer_id) 
from dw.dws_xx_order
where par = '20211025'
group by kdt_id,goods_id
having count(order_no)<count(distinct buyer_id)

Wenn im Abfrageergebnis kein Eintrag vorhanden ist, bedeutet dies, dass keine Anzahl der Bestellungen <Anzahl der erteilten Bestellungen vorhanden ist, und umgekehrt bedeutet dies, dass die Anzahl der Bestellungen> = Anzahl der erteilten Bestellungen ist, was den Erwartungen entspricht; andernfalls, Wenn der Datensatz im Abfrageergebnis größer als 0 ist, entspricht er nicht den Erwartungen.

4.3 Horizontaler Datenvergleich zwischen Tabellen

Der horizontale Vergleich zwischen Tabellen kann als zwei oder mehr Tabellen mit Feldern mit geschäftlichen Assoziationen oder derselben geschäftlichen Bedeutung verstanden werden, die für den Datenvergleich verwendet werden können:

• Vergleich zwischen Tabellen des gleichen Typs: Für Zahlungstabelle A und Zahlungstabelle B in Hive gibt es Zahlungsbetragsfelder, dann Tabelle A. Zahlungsbetrag unter derselben Dimension = Tabelle B. Zahlungsbetrag.

• Vergleich zwischen mehreren Speichersätzen: Beispielsweise verwendet das Youzan Data Report Center mysql und kylin für die Zahlungstabelle, und der Anwendungsschichtspeicher verwendet mysql bzw. kylin, die für den Master-Standby-Switch verwendet werden, dann die kylin-Tabelle A .Zahlungsbetrag unter derselben Dimension = mysql-table B .Zahlungsbetrag.

• Vergleich zwischen mehreren Systemen: Zwischen Systemen, wie z. B. dem Datenmeldezentrum und dem CRM-System, haben beide Systeme Kundenindikatordaten, dann das Datenmeldezentrum unter derselben Dimension - Tabelle A. Kundenindikatoren = CRM - Tabelle B. Kundenkennzahlen.

Wir analysieren die zugrunde liegende Logik des horizontalen Vergleichs von Daten eingehend.Das Wesentliche besteht darin, die verschiedenen Felder der beiden Tabellen zu vergleichen und die logischen Operatoren zu vergleichen, was auch einfacher in ein Werkzeug zu abstrahieren ist. Derzeit ist Youzan „Data Comparison Tool" implementiert. Hier sind einige meiner Ideen:

• Geben Sie zwei Tabellen ein und legen Sie jeweils die Primärschlüssel der beiden Tabellen fest.

• Tragen Sie die zu vergleichenden Felder in die beiden Tabellen ein und setzen Sie die Vergleichsoperatoren wie >, =, <.

• Gemäß den festgelegten Regeln werden die endgültigen Daten mit den Aufzeichnungen über Bestehen und Nichtbestehen verglichen, und ein visueller Bericht wird implementiert, und der Tester kann die Datenqualität gemäß dem Inhalt des Berichts bewerten.

4.4 Vergleich der Längsschnittdaten

Der Längsschnittvergleich ist der Vergleich von vor- und nachgelagerten Daten, um sicherzustellen, dass es keine Probleme in der vor- und nachgelagerten Verarbeitung wichtiger Felder gibt.

Beispielsweise enthält die dw-Schicht des Data Warehouse eine detaillierte Liste von Bestellungen und die dm-Schicht des Datenprodukts eine aggregierte Tabelle der Anzahl der Bestellungen, sodass die statistischen Ergebnisse der beiden Daten unter derselben Dimension konsistent sein sollten.

4.5 Codeüberprüfung

Zunächst einmal müssen wir in der Anforderungsprüfungsphase vor der Codeüberprüfung zunächst die detaillierte Qualität der Datenstatistik klären.Hier sind zwei konkrete Anforderungsbeispiele.

• Anforderung 1: (Fehlerbeispiel) Der Zahlungsbetrag aller Benutzer im Geschäft während der statistischen Zeit. Das Problem ist: Die Anforderungsbeschreibung ist zu prägnant, die zeitliche Dimension und die Filterbedingungen der Datenstatistik werden nicht klar erläutert, was zu einer unklaren statistischen Qualität führt, die eine klare Qualität der Produkte erfordert.

• Anforderung 2: (Korrektes Beispiel) Es gibt einen Offline-Zahlungsbetrag in der Größe eines gesamten Händler-Domain-Stores im Zan-Netzwerk. Unterstützt natürliche Tage, natürliche Wochen und natürliche Monate. Während des statistischen Zeitraums die Summe aller Zahlungsaufträge (ohne Gewinnspiel-, Geschenkkarten- und Verteilerlieferungsaufträge).

Nach der Klärung der Anforderungen werden im Folgenden einige häufige Bedenken bei der Codeüberprüfung ausführlich beschrieben:

1) Assoziationsbeziehung & Filterbedingungen

• Ob die zugeordnete Tabelle Outer Join oder Join verwendet, hängt davon ab, ob die Daten gefiltert werden müssen.

• In der on-Klausel der Assoziationsbeziehung, ob die linken und rechten Werttypen konsistent sind.

• Wenn die Zuordnungsbeziehung 1:1 ist, ob die Zuordnungsschlüssel der beiden Tabellen eindeutig sind. Wenn sie nicht eindeutig ist, erzeugt die Zuordnung kartesisch, was zu einer Datenaufblähung führt.

• Ob die Where-Bedingung korrekt gefiltert wird, achten Sie am Beispiel der oben genannten Anforderungen darauf, ob Lotteriegruppe, Geschenkkarte und Distributionsversorgungsauftrag in SQL korrekt ausgeschlossen werden.

2) Statistische Kaliberverarbeitung von Indikatoren

Die Statistik der Datenindikatoren beinhaltet zwei Grundkonzepte:

• Akkumulative Indikatoren: Wie Zahlungsbetrag, Seitenaufrufe usw., Indikatoren, die durch einfaches Addieren von Zahlenwerten gezählt werden können.Für solche Indikatoren ist die in SQL verwendete Funktion im Allgemeinen die Summe.

• Nicht kumulative Indikatoren: Beispielsweise kann die Anzahl der Besucher nicht einfach addiert werden, sondern muss für Statistiken dedupliziert und dann summiert werden.Für solche Indikatoren wird in der Regel count(distinct) in SQL verwendet.

3) Daten einfügen einfügen

• Ob die Wiederholung unterstützt werden soll. Dies ist gleichbedeutend damit, zu sehen, ob beim Einfügen ein Schlüsselwort zum Überschreiben vorhanden ist.Wenn es kein solches Schlüsselwort gibt, werden die schmutzigen Daten nicht überschrieben, wenn die Daten erneut ausgeführt werden (der Workflow wird mehrmals ausgeführt), sondern die Daten werden inkrementell eingefügt die Tabelle, die zum Endergebnis führen kann.Statistik verdoppelt.

• Ob die Reihenfolge der eingefügten Daten exakt der Reihenfolge der eingefügten Tabellenstruktur entspricht. Wir müssen sicherstellen, dass die Schreibreihenfolge der Datenfelder fehlerfrei ist, sonst werden die eingefügten Werte chaotisch.

3. Testen der Anwendungsschicht

1. Gesamtübersicht

Das grundlegende Testen der Front-End-Seite und der serverseitigen Schnittstelle ist das gleiche wie das allgemeine Testen von Unternehmen und wird hier nicht wiederholt. Dieser Artikel konzentriert sich auf die Bereiche, in denen das Testen von "Datenanwendungen" zusätzliche Aufmerksamkeit erfordert.

2. Downgrade-Strategie

• Beim Hinzufügen eines neuen Datenblatts auf der Seite muss bestätigt werden, ob die Funktion „Blauer Balken“ in der Anforderungs- und technischen Überprüfungsphase unterstützt werden muss, die zu „Linksverschiebung testen“ gehört.

Blauer Balken Einführung: Oben auf der Seite befindet sich ein blauer Balken, in dem Youzan den Händler darüber informiert, dass die Offline-Daten noch nicht erstellt wurden, und die "Produktionszeit" = aktuelle Zugriffszeit + 2 Stunden, die dynamisch berechnet wird.

• Konzentrieren Sie sich beim Testen von Indikatoren vom Verhältnistyp auf den Sonderfall, bei dem Dividende = 0 ist. Beachten Sie diesen Punkt während der Überprüfung des Back-End-Codes und der Testseitenfunktion. Derzeit gibt es Lob für diese Situation, und die einheitliche Front-End-Anzeige ist "-".

3. Aktiv/Standby-Strategie

Beachten Sie bei einer Aktiv/Standby-Umschaltstrategie, dass die Daten während des Tests normalerweise doppelt geschrieben werden, und dass Sie durch Konfiguration beim Abrufen von Daten zwischen den aktiven und Standby-Datenquellen wechseln können.

4. Datensicherheit

Achten Sie auf das Berechtigungsmanagement und die Steuerung der Datenabfrage und konzentrieren Sie sich auf das Testen der Szenarien horizontaler und vertikaler Ultra-Autorität.

4. Folgeplanung

Derzeit kann das Datenvergleichstool im Datengenauigkeitsvergleich realer Projekte nur 50 % der manuellen Tests ersetzen, da es derzeit keine SQL-Funktionen unterstützt.Einige komplexe horizontale und vertikale Datenvergleiche müssen noch in SQL geschrieben werden. Der Follow-up-Plan unterstützt SQL-Funktionen wie Summe, Anzahl, Max, Min usw., was die Abdeckung der Tools auf über 75 % erhöht und die Kosten für den Datenabgleich erheblich reduziert.

Derzeit werden „Data Form Report“ und „Data Comparison Tool“ in weiteren Projekttests eingesetzt, im Nachfolgeplan werden die Formularprüfung und der Datenabgleich zu Online-Prüfungen ausgebaut und Automatisierungs- und Datentools kombiniert um die Qualität der Data-Warehouse-Tabelle kontinuierlich sicherzustellen.

Gegenwärtig beruht die Methode der SQL-Code-Überprüfung hauptsächlich auf manueller Arbeit. Wir planen, einige grundlegende SQL-Prüfungen, wie z Integrieren Sie sie in den Big-Data-Testservice und stärken Sie andere Geschäftsbereiche.