Proves de validació de dades per a projectes de migració de dades i ETL

data validation tests

Aquest tutorial descriu els projectes de migració de dades i ETL i cobreix les comprovacions o proves de validació de dades de projectes de migració de dades i ETL per millorar la qualitat de les dades:

Aquest article s'adreça als provadors de programari que treballen en projectes ETL o Data Migration i estan interessats a centrar les seves proves només en els aspectes de qualitat de les dades. Aquest tipus de projectes tenen un gran volum de dades que s’emmagatzemen a l’emmagatzematge de font i que després són operades per alguna lògica present al programari i es traslladen a l’emmagatzematge de destinació.

Les proves de validació de dades garanteixen que les dades presents en els sistemes objectiu final siguin vàlides, exactes, segons els requisits empresarials i que siguin útils per al sistema de producció en directe.

El nombre d’aspectes sobre la qualitat de les dades que es poden provar és enorme i la llista següent proporciona una introducció a aquest tema.

Què aprendreu:

• Què és la validació de dades?
• Per què validar les dades dels projectes ETL?
• Per què validar les dades dels projectes de migració de dades?
  • Full de mapatge de dades
  • Proves de validació de dades
    • # 1) Uniformitat de dades
    • # 2) Presència de l'entitat
    • # 3) Precisió de dades
    • # 4) Validació de metadades
    • # 5) Integritat de dades
    • # 6) Completesa de les dades
    • # 7) Transformació de dades
    • # 8) Unicitat o duplicació de dades
    • # 9) Obligatori
    • # 10) Puntualitat
    • # 11) Dades nul·les
    • # 12) Comprovació de l'abast
    • # 13) Normes comercials
    • # 14) Funcions agregades
    • # 15) Truncament i arrodoniment de dades
    • # 16) Proves de codificació
    • # 17) Proves de regressió
• Conclusió
  • Lectura recomanada

Què és la validació de dades?

En termes senzills, la validació de dades és el fet de validar el fet que les dades que es mouen com a part dels treballs de migració de dades o ETL són consistents, exactes i completes als sistemes de producció en viu objectiu per satisfer els requisits empresarials.

Exemple: L'adreça d'un estudiant a la taula Student era de 2.000 caràcters al sistema d'origen. La validació de dades verifica si el mateix valor resideix al sistema de destinació. Comprova si les dades s’han truncat o si s’eliminen certs caràcters especials.

En aquest article, analitzarem moltes d’aquestes comprovacions de validació de dades. Com a provadors de projectes de migració de dades o ETL, afegeix un valor enorme si descobrim problemes de qualitat de dades que es poden propagar als sistemes objectiu i interrompre tot el procés empresarial.

Per què validar les dades dels projectes ETL?

En els projectes ETL, les dades s’extreuen de la font, es treballen aplicant una lògica al programari, es transformen i després es carreguen a l’emmagatzematge de destinació. En molts casos, la transformació es fa per canviar les dades d'origen a un format més útil per als requisits empresarials.

Aquí, és necessària la validació de dades per confirmar que les dades que es carreguen al sistema de destinació són completes, exactes i que no hi ha pèrdua de dades ni discrepàncies.

Exemple: Una aplicació de comerç electrònic té feines ETL que seleccionen tots els OrdersIds contra cada CustomerID de la taula Ordres, que resumeix TotalDollarsSpend per part del client i el carrega en una nova taula CustomerValue, marcant cada client que classifica com a clients de valor alt / mitjà / baix en algun algorisme complex.

La prova de validació de dades simple consisteix a comprovar que el CustomerRating es calcula correctament.

Una altra prova és verificar que TotalDollarSpend es calcula correctament sense defectes en arrodonir els valors o desbordaments de valor màxim.

Per què validar les dades dels projectes de migració de dades?

Als projectes de migració de dades, els enormes volums de dades que s’emmagatzemen a l’emmagatzematge d’origen es migren a emmagatzematge objectiu diferent per diversos motius, com ara actualització d’infraestructura, tecnologia obsoleta, optimització, etc. Per exemple, les empreses podrien migrar el seu enorme magatzem de dades de sistemes heretats a solucions més noves i robustes a AWS o Azure.

El motiu principal d’aquests projectes és moure les dades del sistema d’origen a un sistema de destinació de manera que les dades de l’objectiu siguin altament utilitzables sense cap interrupció ni impacte negatiu per a l’empresa.

Un cop més, es requereix la validació de dades per confirmar que les dades de la font són les mateixes a l'objectiu després del moviment.

Exemple: Suposem que per a l'aplicació de comerç electrònic, la taula Ordres que tenia 200 milions de files es va migrar al sistema de destinació a Azure. La prova de validació de dades simple consisteix a verificar que els 200 milions de files de dades estiguin disponibles al sistema de destinació.

Una altra prova podria ser confirmar que els formats de data coincideixen entre el sistema d'origen i el de destinació.

Hi ha diversos aspectes que els provadors poden provar en projectes com ara proves funcionals, proves de rendiment, proves de seguretat, proves infra, proves E2E, proves de regressió, etc.

Lectura recomanada => Prova de migració de dades , Tutorial de proves de magatzem de dades de proves ETL

En aquest article, només analitzarem l’aspecte de les dades de les proves per a projectes d’ETL i migració.

Full de mapatge de dades

Per començar, creeu un full de mapatge de dades per al vostre projecte de dades. El mapatge de dades és el procés de fer coincidir entitats entre les taules d'origen i de destinació. Comenceu documentant totes les taules i les seves entitats al sistema font en un full de càlcul. Ara documenteu els valors corresponents per a cadascuna d’aquestes files que s’espera que coincideixin a les taules de destinació. Anoteu les regles de transformació en una columna independent, si n'hi ha.

Els fulls de mapatge de dades contenen molta informació recollida dels models de dades proporcionats per Data Architects. Inicialment, els verificadors podrien crear una versió simplificada i poden afegir més informació a mesura que avancin. Vegeu l’exemple del full de mapatge de dades a continuació:

Baixeu una plantilla des de Full de mapatge de dades simplificat

Proves de validació de dades

# 1) Uniformitat de dades

Es realitzen proves d’uniformitat de dades per verificar que el valor real de l’entitat té la concordança exacta en diferents llocs. Aquí tenim possibles dos tipus de proves:

(i) Comprovacions dins del mateix esquema:

• L'entitat de dades pot existir en dues taules dins del mateix esquema (sistema d'origen o sistema de destinació)
• Exemple: Com podeu veure a la imatge següent, ProductID es troba a la taula Detalls de la comanda i productes. Feu una verificació de concordança exacta per a ProductId present a la taula Detalls de la comanda i productes.

(ii) Comprovacions entre esquemes:

• L'entitat de dades es pot migrar tal com està a l'esquema de destinació, és a dir, està present al sistema d'origen i al sistema de destinació
• Exemple: Com podeu veure a la imatge anterior, ProductID es troba a la taula de productes del sistema font i a la taula de productes del sistema de destinació. Feu una verificació de concordança exacta per a ProductId a la taula Productes del sistema origen a ProductId a la taula Products del sistema de destinació.

Nota: El millor és ressaltar (codi de color) les entitats de dades coincidents al full Mapping de dades per a una consulta ràpida.

# 2) Presència de l'entitat

En aquest tipus de prova, hem de validar que totes les entitats (taules i camps) coincideixin entre l'origen i l'objectiu. Hi ha dues possibilitats: una entitat pot estar present o absent segons el disseny del model de dades.

(i) Valideu que coincideixin totes les taules (i columnes), que tenen una presència corresponent tant a la font com a la destinació. Traiem una llista de totes les taules (i columnes) i fem una comparació de text. Aquesta prova de seny funciona només si s'utilitzen els mateixos noms d'entitat.

De vegades s’utilitzen noms de taules diferents i, per tant, és possible que la comparació directa no funcioni. És possible que haguem de mapar aquesta informació al full Assignació de dades i validar-la per a fallades.

Una altra possibilitat és l’absència de dades. Hi ha casos en què el model de dades requereix que una taula del sistema d'origen (o columna) no tingui la presència corresponent al sistema de destinació (o viceversa). Feu proves per validar-ho.

• Exemple: Com podeu veure a la imatge següent, la taula CustDemographic està present al sistema de destinació i no al sistema d'origen.
• El camp CustomerType de la taula Clients només té dades al sistema d'origen i no al sistema de destinació.

# 3) Precisió de dades

Com el seu nom indica, validem si les dades són lògicament exactes. Hi ha dues categories per a aquest tipus de proves. Amb això, el comprovador pot detectar els problemes de qualitat de les dades fins i tot al sistema d'origen.

(imatge font )

Nota: Executeu aquesta prova al sistema de destinació i torneu a comprovar si hi ha cap defecte al sistema d'origen.

(i) Tipus no numèric: Segons aquesta classificació, comprovem la precisió del contingut no numèric. Exemples són correus electrònics, codis PIN, telèfon en un format vàlid.

(ii) Anàlisi de dominis: En aquest tipus de proves, escollim dominis de dades i validem els errors. Hi ha tres agrupacions per a això:

• Basat en el valor: Aquí creem una llista de valors que poden aparèixer per a un camp (columna de la taula). A continuació, valideu si els valors de les columnes són un subconjunt de la nostra llista.
  • Exemple: Verifiqueu si la columna Sexe conté M o F.
• Basat en el rang: Aquí establim un interval mínim i màxim per a valors de dades vàlids per a una columna, en funció del raonament lògic o empresarial. A continuació, validem si els valors de les columnes estan dins d’aquest interval.
  • Exemple: De 0 a 120 per Edat.
• Fitxer de referència : Aquí el sistema utilitza un fitxer de validesa extern.
  • Exemple: Els codis de país són vàlids, trien el valor correcte del fitxer de referència, els codis de país són els mateixos entre el control de qualitat i l’entorn de producció? Si s’ha actualitzat el codi de país del fitxer de referència, s’actualitza correctament a DB?

# 4) Validació de metadades

A la validació de metadades, validem que les definicions de tipus de dades de taula i columna per a l'objectiu estiguin dissenyades correctament i, un cop dissenyades, s'executin segons les especificacions de disseny del model de dades.

Aquí hi ha dues agrupacions:

per augmentar la seguretat a la xarxa interna de la vostra empresa

(i) Disseny de metadades: La primera comprovació és validar que el model de dades està dissenyat correctament segons els requisits empresarials per a les taules de destinació. Els arquitectes de dades poden migrar entitats d’esquema o poden fer modificacions quan dissenyen el sistema de destinació.

La següent comprovació hauria de ser validar que els scripts adequats es van crear utilitzant els models de dades.

Per a cada categoria següent, primer comprovem si les metadades definides per al sistema objectiu compleixen els requisits empresarials i, en segon lloc, si les taules i les definicions de camps s'han creat amb precisió.

A continuació es detallen algunes de les comprovacions de metadades:

• Comprovació del tipus de dades: Exemple: Les vendes totals funcionaran correctament amb tipus Decimal (8, 16 o 20 bytes) o Doble?
• Comprovació de la longitud de les dades : Exemple: La longitud de les dades per al camp Adreça serà suficient amb 500 caràcters? Pot ser que es faci un procés de migració de dades a mesura que s’afegeix una nova geografia a l’empresa. És possible que les adreces de la nova geografia tinguin un format excessivament llarg i que, si s’adhereixin a la longitud original, es pugui produir un error en un cas d’ús.
• Comprovació de l’índex: Exemple: Es fa una indexació per a la columna OrderId al sistema de destinació? Què passa si es va produir una fusió d'empreses que requeria una migració de dades i la taula de comandes creix 100 vegades en el sistema de destinació?
• Comprovació de metadades a tots els entorns: En aquesta comprovació, comproveu que les metadades coincideixen entre la prova de control de qualitat i l'entorn de producció. Les proves poden passar a l’entorn de control de qualitat, però fallen en altres entorns.

(ii) Canvi del delta: Aquestes proves descobreixen els defectes que es produeixen quan el projecte està en curs i a mig camí hi ha canvis a les metadades del sistema font i no s’han implementat en sistemes objectiu.

Exemple: S'ha afegit un nou camp CSI (Índex de satisfacció del client) a la taula de clients de la font, però no s'ha pogut fer al sistema de destinació.

# 5) Integritat de dades

Aquí, principalment validem les restriccions d’integritat com la clau externa, la referència de la clau primària, la única, la predeterminada, etc.

(imatge font )

Per a les claus externes, hem de comprovar si hi ha registres orfes a la taula fill on la clau externa utilitzada no està present a la taula principal.

Exemple: La taula de clients té CustomerID, que és una clau principal. La taula de comandes té CustomerID com a clau externa. És possible que la taula de comandes tingui un identificador de client que no es troba a la taula de clients. Hem de fer proves per descobrir aquestes violacions de restriccions d’integritat. La taula de mapatge de dades us proporcionarà claredat sobre les taules que tenen aquestes restriccions.

Nota: Executeu aquesta prova al sistema de destinació i torneu a comprovar-ho al sistema d'origen si hi ha defectes.

# 6) Completesa de les dades

Es tracta de proves de seny que descobreixen el recompte de registres o de files que falten entre la taula d'origen i la de destinació i es poden executar amb freqüència un cop automatitzats.

Hi ha dos tipus de proves:

(i) Recompte de registres: Aquí comparem el recompte total de registres de les taules coincidents entre el sistema d'origen i el de destinació. Es tracta d’una comprovació ràpida de seny per verificar la publicació del treball ETL o Migration. Tenim un defecte si els recomptes no coincideixen.

De vegades hi ha registres rebutjats durant l'execució del treball. Alguns d’aquests poden ser vàlids. Però, com a provador, en fem un cas.

(ii) Perfils de dades de columnes: Aquest tipus de prova de seny és valuosa quan el recompte de registres és enorme. Aquí, creem conjunts lògics de dades que redueixen el recompte de registres i, a continuació, fem una comparació entre origen i objectiu.

• Si és possible, filtreu tots els valors únics d'una columna, per exemple, És possible que l'identificador de producte es produeixi diverses vegades a la taula OrderDetails. Trieu una llista única per a ProductID tant de les taules de destinació com de les fonts i valideu-les. Això redueix altament el nombre de registres i accelera les proves de seny.
• Igual que les proves anteriors, també podem escollir totes les columnes principals i comprovar si els KPI (longitud mínima, màxima, mitjana, màxima o mínima, etc.) coincideixen entre la taula de destinació i la font. Exemple: Agafeu els valors mitjans, mínims i màxims de la columna Preu de Detalls de l’ordre i compareu aquests valors entre les taules de destinació i d’origen per no coincidir.
• Es pot fer una altra comprovació dels valors Nuls. Trieu columnes importants i filtreu una llista de files on la columna conté valors nuls. Compareu aquestes files entre els sistemes de destinació i de font per al desajustament.

# 7) Transformació de dades

Aquestes proves constitueixen les proves bàsiques del projecte. Reviseu el document de requisits per entendre els requisits de transformació. Prepareu les dades de prova als sistemes font per reflectir diferents escenaris de transformació. Aquests disposen de multitud de proves i s’han de tractar detalladament als temes de proves ETL.

A continuació es mostra una llista concisa de les proves incloses en aquesta:

(i) Transformació:

• Exemple: El codi ETL pot tenir una lògica per rebutjar dades no vàlides. Verifiqueu-los en funció dels requisits.
• El codi ETL també pot contenir lògica per generar automàticament certes claus, com ara claus substitutives. Hem de fer proves per verificar-ne la correcció (tècnica i lògica).
• Valideu la correcció de la unió o la divisió de valors de camp després de fer un treball ETL o Migració.
• Feu proves per verificar les comprovacions d’integritat referencial. Per exemple, un tipus de defecte podria ser ProductId que s'utilitza a la taula Ordres no està present a Productes de la taula principal. Feu una prova per verificar el comportament dels registres orfes durant un treball ETL.
• De vegades, les dades que falten s’insereixen mitjançant el codi ETL. Verifiqueu-ne la correcció.
• Els scripts ETL o Migration de vegades tenen lògica per corregir les dades. Verifiqueu que la correcció de dades funcioni.
• Verifiqueu si s’informa als usuaris dades no vàlides / rebutjades / errònies.
• Creeu un full de càlcul d’escenaris de dades d’entrada i resultats esperats i valideu-los amb el client empresarial.

(ii) Casos Edge: Verifiqueu que la lògica de transformació manté els límits.

• Exemple: Què passa quan TotalSales amb un valor d'1 bilió s'executa a través d'un treball ETL? Els casos de final a final funcionen? Identifiqueu els camps que poden tenir valors grans i feu proves amb aquests valors grans. Han d’incloure valors numèrics i no numèrics.
• Per als camps de dates, inclòs tot l'interval de dates previstes: anys de traspàs, 28/29 dies per al febrer. 30, 31 dies per a altres mesos.

# 8) Unicitat o duplicació de dades

En aquest tipus de prova, identifiqueu les columnes que haurien de tenir valors únics segons el model de dades. A més, tingueu en compte la lògica empresarial per eliminar aquestes dades. Executeu proves per verificar si són úniques al sistema. A continuació, feu proves per identificar els duplicats reals.

• Exemple: Filtreu les dades duplicades i verifiqueu si són autèntiques. Per exemple, El registre dependent dels empleats conté les mateixes dades de germans dues vegades.
• El número de telèfon de l'usuari ha de ser únic al sistema (requisit empresarial).
• El requisit empresarial diu que una combinació de ProductID i ProductName a la taula Productes hauria de ser única, ja que ProductName es pot duplicar.

# 9) Obligatori

En aquest tipus de prova, identifiqueu tots els camps marcats com a obligatoris i valideu-los si els camps obligatoris tenen valors. Si hi ha valors predeterminats associats a un camp de la base de dades, comproveu si s'emplena correctament quan no hi ha dades.

• Exemple: Si no s'introdueix la data de facturació, la data actual és la data de facturació.

# 10) Puntualitat

Documenta sempre les proves que comprovin que treballes amb dades dels terminis acordats.

• Exemple: ProductDiscount es va actualitzar 15 dies enrere i el domini empresarial indica que ProductDiscount canvia cada set dies. Això vol dir que les proves no es realitzen amb els valors de descompte adequats.
• Se suposava que un informe d’anàlisi predictiu de l’índex de satisfacció del client funcionaria amb les dades de la darrera setmana, que era una setmana de promoció de vendes a Walmart. Però el treball ETL es va dissenyar per executar-se amb una freqüència de 15 dies. Aquest és un defecte important que els comprovadors poden descobrir.

# 11) Dades nul·les

En aquest tipus de proves, ens centrem en la validesa de les dades nul·les i en la verificació que la columna important no pot ser nul·la.

• Exemple: Filtreu totes les dades nul·les i valideu-les si es permet.
• Si hi ha columnes importants per a les decisions empresarials, assegureu-vos que no hi hagi nuls.

# 12) Comprovació de l'abast

S'ha de provar l'entitat de dades en què els intervals tenen sentit per al negoci.

• Exemple: La quantitat de comanda per factura no pot superar els 5 K a la categoria de programari.
• L’edat no pot superar els 120 anys.

# 13) Normes comercials

Documenta els requisits empresarials dels camps i fes proves per al mateix.

• Exemple: Els recursos amb una edat inferior a 20 anys no són elegibles. Es requereixen comprovacions de validació de dades si s'aplica aquesta regla a les dades.
• La data de finalització hauria de ser nul·la si l'estat d'empleat actiu és cert / mort.
• Les dades de FROM han de ser inferiors a TO Date.
• Sumeu els imports de compra a nivell d’article als imports a nivell de comanda

# 14) Funcions agregades

Les funcions agregades s’incorporen a la funcionalitat de la base de dades. Documenteu tots els agregats del sistema d'origen i verifiqueu si l'ús d'agregats dóna els mateixos valors al sistema de destinació (suma, màxim, mínim, recompte).

Molt sovint les eines del sistema d'origen són diferents del sistema de destinació. Comproveu si ambdues eines executen funcions agregades de la mateixa manera.

# 15) Truncament i arrodoniment de dades

En aquest tipus de proves, identifiquem camps amb truncament i arrodoniment lògic relatius al negoci. A continuació, documentem i obtenim la signatura de la lògica de truncament i arrodoniment amb els propietaris de productes i els provem amb dades representatives de la producció.

# 16) Proves de codificació

Valideu si hi ha valors codificats al sistema d'origen i verifiqueu si les dades s'omplen correctament després de publicar el treball ETL o migració de dades al sistema de destinació.

• Exemple: Es van acceptar caràcters de doble byte per a FirstName en xinès al sistema font que estava codificat. Verifiqueu el comportament d'aquest camp quan es mou al sistema de destinació.
• El camp Contrasenya s'ha codificat i migrat. Assegureu-vos que funcionin bé després de la migració.

# 17) Proves de regressió

Aquest és un concepte bàsic de proves en què els verificadors executen tot el conjunt de casos de proves crítics generats mitjançant la llista de verificació anterior i publiquen un canvi al sistema d'origen o de destinació.

Conclusió

Per tant, hem vist que la validació de dades és una àrea interessant per explorar per a projectes intensius en dades i constitueix les proves més importants. El full de mapatge de dades és un artefacte crític que els verificadors han de mantenir per aconseguir l'èxit amb aquestes proves. Poden mantenir diverses versions amb ressaltats de color per formar entrades per a qualsevol de les proves anteriors.

Cal tenir cura de mantenir els canvis delta entre versions.

Demanem als lectors que comparteixin altres àrees de la prova que han trobat durant el seu treball per beneficiar la comunitat de verificadors.

Lectura recomanada

• Què és el procés ETL (extracció, transformació, càrrega) a Data Warehouse?
• 15 millors eines ETL el 2021 (llista completa actualitzada)
• Com realitzar proves ETL mitjançant l'eina Informatica PowerCenter
• 10 millors eines de mapatge de dades útils en el procés ETL (LLISTA 2021)
• Top 10 d'eines de proves ETL el 2021
• Tutorial de proves de migració de dades: una guia completa
• 13 millors eines de migració de dades per a una integritat completa de les dades (LLISTA 2021)
• Tutorial de proves de magatzem de dades de proves ETL (una guia completa)