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.

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.

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