Cum ati aborda aceasta problema de validare de date?

Exista o echipa care ia diverse date si le agrega, transforma si pune la dispozitie intr-un format frumos si clean.

Exista o a 2’a echipa care ia aceste date (statice) exportate de prima echipa si le importa intr-o baza de date spre a fi servite de un back-end api.

Pe scurt, echipa de data-stuff exporta fisiere (1 fisier cu datele + 1 fisier cu schema lui, fiecare fisier poate fi considerat ca o tabela din baza de date al back-endului), iar echipa de back-end importa aceste fisiere + le mai modifica din field-uri/valori, adauga alte field-uri, etc.

Totul bine pana aici.

Acum intervin niste probleme cu validitatea datelor, atat pe partea de business cat si pe partea tehnica.

Pe partea tehnica: te astepti ca unele sa vina field-uri sa fie mandatory, etc.
Pe partea de business: daca field-ul a1,a2 exista atunci nu ar trebui sa exista a3 sau daca field-ul a1 nu exista atunci ar trebui sa existe a2

Cum ati proceda in acest caz?

Cine ar trebui sa valideze aceste cazuri? Data-stuff team? Back-end team? 50/50?

Cum ar trebui stabilit contractul intre cele 2 echipe? Ce responsabilitati ar trebui discutate/asignate?

P.S. Exista colaborare intre cele 2 echipe, de fiecare data cand vine un business requirement nou, se discuta ce trebuie implementat, si dupa ce field-uri noi sa adauge pe o anumita tabela sau daca e cazul o tabela noua.

Daca ai un furnizor de date și un consumator și așa rămâne pentru vecie atunci le faci compatibile. Fifty - fifty.

Daca furnizorul are mai multi consumatori, atunci e treaba fiecărui consumator să facă borș cu datele.

1 Like

E greu de tras o concluzie din ce zici pana acum. Reformulez, corecteaza-ma daca gresesc:
Inteleg ca echipa 1 aduce datele, le agrega si le aplica niste transformari, apoi le exporta in perechi de fisiere, date+schema.
Echipa 2 le importa si aplica alte transformari.
Nevoile de validare, pe ambele criterii, biz+tehnic, tin de transformarile facute de ambele echipe sau de una din ele in mod special?
Dpdv data engineering, ar trebui ca fiecare din echipe sau una din ele macar sa seteze niste teste automate de validare dupa fiecare etapa de transformare (echipa1 sau echipa2) in functie de care sunt cele care genereaza nevoi de validare. Si, daca e cazul, completate testele cu o rutina de intors datele la echipa responsabila sau de mutat intr-un container de date invalide.

Sa spunem ca sunt foarte multe date, de exemplu daca o tabela contine 10 milioane de entitati si 2 din alea 10 milioane nu satisfac o conditie de business (exemplu cu daca a1 nu exista atunci a2 ar trebui sa existe, doarece este folosit la o anumita logica de business pe un back-end api), cum procedezi?

Echipa 1: data-stuff
Echipa 2: back-end API

Poti sa scrii niste teste pe un chunk din datele exportate de data-stuff, dar e doar o foarte mica parte. Ce faci cand apar probleme de genul pe API? fix una din alea 2 entitati cu probleme din cele 10 milioane in total a fost descoperita din greseala. Cum procedezi?

Nu am inteles partea cu ‘o rutina de intors datele/mutat intr-un container de date invalide’, poti sa detaliezi te rog? Multumesc :slight_smile:

Poti sa detaliezi ce ai vrut sa spui prin ‘le faci compatibile, 50/50’ ? Multumesc :slight_smile:

Adica o parte a scriptului de validare care sa notifice echipa responsabila / sa ii trimita inapoi datele daca e ceva de corectat/corectabil sau sa le mute undeva intr-un loc separat daca nu, sa nu fie prezente in API - din alta perspectiva - daca sunt vitale, tb corectate, daca nu, pot fi mutate separat pentru a scapa de probleme.

Daca sunt foarte multe date, cu atat mai mult e nevoie de teste automate si de pasi automati pentru fie trimis la corectare, tot setul sau doar partea incorecta, fie pus separat partea incorecta.

Alte variante care pot ajuta:

  • consolidarea tuturor transformarilor intr-un singur loc, probabil la data-team, si validare unica la final before final import
  • folosirea unei BD unice cu constraints si triggers/stored procedures pentru validare

Dar toate astea-s doar din avion, voi stiti ce aveti acolo. Ideea de baza e ca trebuie 1.simplificat si 2.automatizat cat mai mult.

Am uitat sa mentionez cateva detalii importante:

  • La cate 1-2 saptamani data-stuff scoate un nou export de date (unde valorile entitatilor pot fi actualizate, adica aceeasi entitate cu id-ul X, fieldul a1 poate avea valoare diferita intre 2 exporturi)
  • Toate datele trebuie sa existe, nu se pot ‘izola datele cu probleme intr-un loc separat’, daca sunt probleme, trebuie corectate printr-un nou export de date care sa fie importat in db

Ceea ce as fi vrut eu sa aflu daca a mai intalnit cineva cazul acesta prin proprie experienta si cum l-a abordat, ce procese s-au pus in practica pentru a gestiona integritatea datelor.

Exemplu concret bazat pe ce am scris adineaori, daca in tabela T, o entitate cu field-ul a1 nu exista atunci a2 ar trebui sa existe (logic, vor fi si entitati cu a1 si a2, sau doar cu a1), cine ar trebui sa valideze ca toate cele 10 milioane de entitati din tabela X satisfac conditia aceasta? In primul rand, ar trebui scris un test pentru toate entitatile sau doar sampling? De ce prima sau a 2’a varianta?(argumente pe baza de statistica, 95percentile etc.)

Ceva de genul acesta :smiley:

ceva asemanator am si eu la munca, dar ambii pasi sunt in cadrul echipei (deci putem comunica mai usor)

un coleg imi pune la dispozitie csv cu 20 mil randuri de date, pe care eu le import printr-un script intr-o tabela mysql pentru a le pune la dispozitia unui api, care la randul lui face anumite transformari si le trimite ca json clientilor.

Colegul punandu-mi la dispozitie datele printr-un script folosind tehnologie big data, automat viteza e de partea lui si am ales ca validarile sa le faca el (de ex, se intampla ca unele linii sa fie duplicate, iar eu cand fac importul din csv in mysql, eroare cheie duplicata. alta faza, veneau stringuri ce contineau backslash si trebuia facut escape). Altfel, nu vad alta varianta, sa iau eu csv-ul si sa-l iau la testat linie cu linie pentru validari, prin api, ar dura o vesnicie. Importul il fac cu mysqlimport, si un csv de 20 mil linii dureaza n jur de 30 minute.

In cazul tau, daca datele sunt “corect” trimise (fara erori cum aveam eu mai sus) de catre echipa1, mie imi pare ca e de datoria echipei2 sa-si faca validarile respective.

echipa1 spune “noi va punem la dispozitie datele cu fieldurile a1, a2 si a3”, iar echipa2 poate sa aleaga cand face importul daca a1 && a2, atunci a3 = null :rofl:

in functie si de modul in care sunt puse la dispozitie datele respective, si cui ii mai sunt sharuite, validarea respectiva poate fi mutate de la o echipa la alta. Daca echipa1 pune csv-ul respectiv doar la dispozitia echipei2, si validarile le-ar putea face mult mai repede, atunci parca mai corect ar fi sa le faca ei si datele sa vina deja modificate. Daca datele alea ajung la mai multe echipe, fiecare ar trebui sa-si faca validarile proprii.

1 Like

Eu ce as face la asta:

  1. Nu as modifica datele venite de la echipa 1, in prima instanta (mai ales daca se pot schimba intre importuri)
  2. Validarea sa se faca de catre echipa 2; aici sugerez folosirea unei baze de date NoSql si versionarea fiecarui document in parte.
  3. Introduci documentul in nosql chiar daca nu e valid, dar il afisezi undeva separat pentru luarea la mana de catre alta echipa. Aceste edge-case-uri sunt foarte importante de vazut, ca sa stii de ce nu ti s-a importat X sau Y.
  4. Cand echipa 2 trebuie sa faca diverse alte transformari pe acele date, sugerez sa se faca o functionalitate pentru tragerea datelor din colectia de mai sus in alta colectie, care o sa fie providerul de date pentru API. Aici poti sa marchezi documentele invalide.
  5. Sa zicem ca echipa 1 face un update la document, se poate scrie o migrare de la versiunea 1 la versiunea 2, ad-hoc. Apoi, se ruleaza sincronizarea de mai sus.

Ce se realizeaza cu acest lucru:

Echipa 1 face numai adunarea de date.
Echipa 2 este responsabila pentru business case-uri si validari.
Daca ceva e invalid, se va stii si se va putea vedea edge-case-ul.
La update-ul sursei de date se va putea usor updata/migra ce are echipa 2, iar in plus vine si cu beneficiul ca poti sa vezi cum arata la momentul X un document.

Ceva de genul vrem si noi sa implementam la noi, dar nu am gasit timpul inca :smiley:

1 Like

Transferul datelor prin export/import e solutia cea mai pacatoasa dintre optiunile posibile. E genul de cerinta a clientului non-tehnic, care vrea sa isi vada datele in Excel inainte sa fie procesate in pasul urmator.
Exista 10 solutii posibile de transfer date intre sisteme, automat, caz in care se pot aplica validari la ambele capete. Fiecare sistem trebuie sa isi valideze datele inainte sa le foloseasca, punct.

1 Like