Üdvözlök mindenkit, a nevem Alexander, és adatminőségi mérnök vagyok, aki ellenőrzi az adatok minőségét. Ez a cikk arról fog szólni, hogyan jutottam el idáig, és miért volt 2020-ban ez a tesztelési terület egy hullám csúcsán.
globális trend
A mai világban egy újabb technológiai forradalom zajlik, amelynek egyik aspektusa az, hogy a felhalmozott adatokat mindenféle vállalat felhasználja saját eladási, profit- és PR lendkerekére. Úgy tűnik, hogy a jó (minőségi) adatok jelenléte, valamint az azokból pénzt keresni tudó (helyesen feldolgozni, vizualizálni, gépi tanulási modelleket építeni stb.) tudó ügyes agy sokak számára ma már a siker kulcsává vált. Ha 15-20 évvel ezelőtt a nagyvállalatok főként az adatgyűjtéssel és a bevételszerzéssel foglalkoztak intenzív munkával, ma már szinte minden épeszű ember dolga.
E tekintetben néhány évvel ezelőtt a világ összes álláskeresési portálja megtelt adattudósok üresedéseivel, mivel mindenki biztos volt abban, hogy egy ilyen szakember felvételével meg lehet építeni a gépi tanulás szupermodelljét. , megjósolni a jövőt és végrehajtani egy „kvantumugrást” a vállalat számára. Idővel az emberek rájöttek, hogy ez a megközelítés szinte soha nem működik sehol, mivel nem minden adat, amely az ilyen szakemberek kezébe kerül, alkalmas modellek képzésére.
És elkezdődtek a Data Scientists kérései: „Vásároljunk még több adatot ezekből és ezekből...”, „Nincs elég adatunk...”, „Szükségünk van még néhány adatra, lehetőleg jó minőségűre...” . Ezekre a kérésekre alapozva számos interakció kezdett kiépülni az egyik vagy másik adathalmazt birtokló vállalatok között. Ehhez természetesen szükség volt ennek a folyamatnak a technikai megszervezésére – az adatforráshoz való csatlakozásra, letöltésre, annak ellenőrzésére, hogy teljesen be van-e töltve, stb. Az ilyen folyamatok száma növekedni kezdett, és ma már óriási szükségünk van egy másfajta adatforrásra. szakemberek - Adatminőségi mérnökök - azok, akik figyelemmel kísérnék a rendszerben (adatvezetékekben) lévő adatok áramlását, a bemeneti és kimeneti adatok minőségét, és következtetéseket vonnának le azok elegendőségére, integritására és egyéb jellemzőire.
A Data Quality mérnökök irányzata az USA-ból érkezett hozzánk, ahol a kapitalizmus tomboló korszaka közepette senki sem hajlandó elveszíteni az adatokért vívott csatát. Az alábbiakban képernyőképeket készítettem az Egyesült Államok két legnépszerűbb álláskereső webhelyéről: и — amely a 17. március 2020-i állapotot jeleníti meg a beérkezett meghirdetett állások számáról a következő kulcsszavakkal: Data Quality és Data Scientist.
Data Scientists – 21416 üresedés
Adatminőség – 41104 üresedés
Data Scientists – 404 üresedés
Adatminőség – 2020 betöltetlen állások
Nyilvánvaló, hogy ezek a szakmák semmiképpen sem versenyeznek egymással. Képernyőképekkel csak a munkaerőpiac jelenlegi helyzetét szerettem volna szemléltetni a Data Quality mérnökök iránti kérelmek tekintetében, akikre most sokkal többre van szükség, mint a Data Scientistre.
2019 júniusában az EPAM a modern IT-piac igényeire reagálva külön gyakorlattá választotta az adatminőséget. Az adatminőség-mérnökök mindennapi munkájuk során az adatokat kezelik, új körülmények között, rendszerekben ellenőrzik viselkedésüket, figyelemmel kísérik az adatok relevanciáját, elegendőségét és relevanciáját. Mindezek mellett gyakorlati értelemben az adatminőség-mérnökök valóban kevés időt fordítanak a klasszikus funkcionális tesztelésre, DE ez nagyban függ a projekttől (alább egy példát mutatok be).
Az adatminőségi mérnök felelőssége nem korlátozódik csupán az adatbázistáblák „nullainak, számainak és összegeinek” rutinszerű kézi/automatikus ellenőrzésére, hanem megköveteli az ügyfél üzleti igényeinek mély megértését, és ennek megfelelően a rendelkezésre álló adatok átalakításának képességét. hasznos üzleti információk.
Adatminőség-elmélet
Annak érdekében, hogy jobban elképzeljük egy ilyen mérnök szerepét, nézzük meg, mi az adatminőség elméletben.
Adatminőség — az adatkezelés egyik szakasza (egy egész világ, amelyet Önre hagyunk, hogy tanulmányozhassa egyedül), és felelős az adatok elemzéséért az alábbi kritériumok szerint:
Szerintem nem kell megfejteni az egyes pontokat (elméletileg "adatdimenzióknak" hívják), elég jól le vannak írva a képen. De maga a tesztelési folyamat nem jelenti azt, hogy ezeket a funkciókat szigorúan tesztesetekbe másoljuk és ellenőrizzük. Az adatminőségben, mint minden más típusú tesztelésnél, mindenekelőtt az üzleti döntéseket hozó projekt résztvevőivel egyeztetett adatminőségi követelményekre kell építeni.
Az adatminőségi projekttől függően egy mérnök különböző feladatokat lát el: egy közönséges automatizálási tesztelőtől, aki felületesen értékeli az adatminőséget, az adatok mélyprofilozását végző személyig a fenti kritériumok szerint.
Az adatkezelés, az adatminőség és a kapcsolódó folyamatok nagyon részletes leírása jól olvasható az elnevezésű könyvben "DAMA-DMBOK: Adatkezelési Tudástár: 2. kiadás". Nagyon ajánlom ezt a könyvet a téma bevezetésének (a cikk végén találsz rá egy linket).
Az én történetem
Az IT-iparban a termékgyártó cégek junior tesztelőjéből az EPAM vezető adatminőség-mérnökévé váltam. Körülbelül két év tesztelői munka után abban a szilárd meggyőződésem volt, hogy abszolút minden típusú tesztelést elvégeztem: regressziós, funkcionális, stressz-, stabilitás-, biztonság-, felhasználói felület stb. - és számos tesztelőeszközt kipróbáltam. három programozási nyelven dolgozott egyszerre: Java, Scala, Python.
Visszatekintve megértem, miért volt olyan sokrétű a készségkészletem – részt vettem kis és nagy adatvezérelt projektekben. Ez az, ami elvezetett a sok eszközt és lehetőséget kínáló világba a növekedéshez.
Ha szeretné értékelni az új ismeretek és készségek megszerzésére szolgáló eszközök és lehetőségek sokféleségét, nézze meg az alábbi képet, amely a „Data & AI” világ legnépszerűbb eszközeit mutatja.
Ezt a fajta illusztrációt az egyik híres kockázati tőkebefektető, Matt Turck állítja össze évente, aki a szoftverfejlesztésből származik. Itt a blogjába és , ahol partnerként dolgozik.
Szakmailag különösen gyorsan fejlődtem, amikor én voltam a projekt egyetlen tesztelője, vagy legalábbis a projekt elején. Ebben a pillanatban a teljes tesztelési folyamatért felelősnek kell lennie, és nincs lehetőség a visszavonulásra, csak előre. Eleinte ijesztő volt, de most egy ilyen teszt minden előnye nyilvánvaló számomra:
- Úgy kezd el kommunikálni az egész csapattal, mint még soha, mivel nincs proxy a kommunikációhoz: sem a tesztmenedzser, sem a tesztelőtársak.
- A projektben való elmerülés hihetetlenül mélyebbé válik, és minden komponensről információval rendelkezik, általánosságban és részletesen egyaránt.
- A fejlesztők nem úgy tekintenek rád, mint „a tesztelésről érkező fickóra, aki nem tudja, mit csinál”, hanem úgy tekintenek rád, mint egyenrangú személyre, aki hihetetlen előnyökkel jár a csapat számára automatizált tesztjeivel és a program egy adott komponensében megjelenő hibákra számítva. termék.
- Ennek eredményeként Ön hatékonyabb, képzettebb és keresletesebb.
A projekt növekedésével az esetek 100%-ában új tesztelők mentorává váltam, tanítottam őket, és átadtam a magam által tanult tudást. Ugyanakkor projekttől függően nem mindig kaptam a legmagasabb szintű autótesztelő szakembereket a vezetőségtől, és szükség volt vagy automatizálási képzésre (az érdeklődők számára), vagy a mindennapi tevékenységekhez használható eszközök létrehozására (eszközök) adatok generálásához és rendszerbe való betöltéséhez, eszköz a terhelés-/stabilitásteszt „gyors” elvégzéséhez stb.).
Példa egy konkrét projektre
Sajnos a titoktartási kötelezettség miatt nem tudok részletesen beszélni azokról a projektekről, amelyeken dolgoztam, de példákat hozok az egyik projektnél jellemző adatminőség-mérnöki feladatokra.
A projekt lényege, hogy az erre épülő gépi tanulási modellek képzéséhez adatokat előkészítő platformot valósítson meg. Az ügyfél egy nagy gyógyszergyártó cég volt az Egyesült Államokból. Technikailag egy klaszter volt , emelkedik példányok, számos mikroszolgáltatással és az alapul szolgáló nyílt forráskódú EPAM projekttel - , egy adott ügyfél igényeihez igazítva (most a projekt újjászületett ). Az ETL folyamatokat a segítségével szerveztük meg és áthelyezte az adatokat ügyfélrendszerek be Vödör. Ezt követően egy gépi tanulási modell Docker-képe került telepítésre a platformra, amelyet friss adatokra tanítottak, és a REST API felület segítségével olyan előrejelzéseket készített, amelyek érdekesek voltak az üzlet számára, és megoldottak bizonyos problémákat.
Vizuálisan minden valahogy így nézett ki:
Rengeteg funkcionális tesztelés volt ezen a projekten, és tekintettel a funkciók fejlesztésének sebességére és a kiadási ciklus ütemének fenntartására (kéthetes sprintek), azonnal el kellett gondolkodni a legkritikusabb összetevők tesztelésének automatizálásán. a rendszer. Maga a Kubernetes-alapú platform nagy részét lefedték a ben implementált automatikus tesztek + Python, de ezek támogatására, bővítésére is szükség volt. Ezenkívül az ügyfél kényelmét szolgálja egy grafikus felhasználói felület a fürtbe telepített gépi tanulási modellek kezelésére, valamint lehetővé teszi annak meghatározását, hogy a modellek betanításához hova és hova kell adatokat továbbítani. Ez a kiterjedt kiegészítés az automatizált funkcionális tesztelés kibővítésével járt, amelyet többnyire REST API-hívások és néhány end-2-end UI-teszt segítségével hajtottak végre. Mindezen mozgások egyenlítője körül csatlakozott hozzánk egy manuális tesztelő, aki kiváló munkát végzett a termékváltozatok átvételi tesztelésével és a következő kiadás elfogadásáról szóló kommunikációval az ügyféllel. Ezen kívül egy új szakember érkezése miatt dokumentálhattuk munkánkat, és több nagyon fontos, nehezen automatizálható kézi ellenőrzést is hozzáadhattunk.
Végül pedig, miután stabilitást értünk el a platform és a rajta lévő GUI-bővítmény révén, megkezdtük az ETL-csővezetékek építését Apache Airflow DAG-ok segítségével. Az automatizált adatminőség-ellenőrzés speciális Airflow DAG-ok írásával történt, amelyek az ETL folyamat eredményei alapján ellenőrizték az adatokat. A projekt részeként szerencsénk volt, és az ügyfél hozzáférést biztosított számunkra anonimizált adatkészletekhez, amelyeken teszteltük. Soronként ellenőriztük az adatokat a típusoknak való megfelelést, a törött adatok meglétét, a rekordok összesített számát előtte és utána, az ETL folyamat által végzett transzformációk összehasonlítását az összesítéshez, az oszlopnevek megváltoztatását és egyebeket. Ezenkívül ezeket az ellenőrzéseket különböző adatforrásokra méretezték, például a SalesForce mellett a MySQL-re is.
A végső adatminőség-ellenőrzések már S3 szinten megtörténtek, ahol tárolásra kerültek, és készen álltak a gépi tanulási modellek betanítására. Az S3 Bucketen található végső CSV-fájlból való adatok lekéréséhez és annak érvényesítéséhez a kódot a segítségével írták meg .
Az ügyfélnek azt is elő kellett írnia, hogy az adatok egy részét az egyik S3 tárolóban, egy részét pedig egy másikban tárolja. Ehhez további ellenőrzések írására is szükség volt az ilyen válogatás megbízhatóságának ellenőrzésére.
Általános tapasztalat más projektekből
Példa az adatminőségi mérnök tevékenységeinek legáltalánosabb listájára:
- Készítse elő a tesztadatokat (érvénytelen nagy kicsi) egy automata eszközzel.
- Töltse fel az előkészített adatkészletet az eredeti forrásba, és ellenőrizze, hogy készen áll-e a használatra.
- Indítson el ETL-folyamatokat egy adathalmaz feldolgozásához a forrástárolótól a végső vagy közbenső tárolóig egy bizonyos beállításkészlettel (ha lehetséges, állítson be konfigurálható paramétereket az ETL-feladathoz).
- Ellenőrizze az ETL folyamat által feldolgozott adatok minőségét és az üzleti követelményeknek való megfelelést.
Ugyanakkor az ellenőrzések során nem csak arra kell összpontosítani, hogy a rendszerben az adatáramlás elvileg működött és befejeződött-e (ami a funkcionális tesztelés része), hanem leginkább az adatok ellenőrzésére és érvényesítésére. az elvárt követelmények betartása, az anomáliák azonosítása és egyéb dolgok.
Tools
Az ilyen adatkezelés egyik technikája lehet a láncellenőrzés megszervezése az adatfeldolgozás minden szakaszában, az irodalomban az úgynevezett „adatlánc” - az adatok ellenőrzése a forrástól a végső felhasználásig. Az ilyen típusú ellenőrzéseket leggyakrabban ellenőrző SQL-lekérdezések írásával hajtják végre. Nyilvánvaló, hogy az ilyen lekérdezéseknek a lehető legkönnyebbnek kell lenniük, és ellenőrizniük kell az egyes adatok minőségét (táblázatok metaadatai, üres sorok, NULL-ok, szintaktikai hibák - egyéb, az ellenőrzéshez szükséges attribútumok).
A kész (változhatatlan, enyhén változtatható) adatkészleteket használó regressziós tesztelés esetén az automatikus teszt kód kész sablonokat tud tárolni az adatok minőségi megfelelőségének ellenőrzésére (várható tábla metaadatok leírása; sorminta objektumok véletlenszerűen kiválasztott a teszt során stb.).
Ezenkívül a tesztelés során ETL tesztfolyamatokat kell írnia olyan keretrendszerekkel, mint az Apache Airflow, vagy akár egy black-box felhő típusú eszköz , Stb. Ez a körülmény arra készteti a tesztmérnököt, hogy elmerüljön a fenti eszközök működési elveiben, és még hatékonyabban végezzen funkcionális tesztelést (például egy projekten meglévő ETL-folyamatokat), és használja ezeket az adatok ellenőrzésére. Az Apache Airflow kész operátorokkal rendelkezik például népszerű analitikai adatbázisokkal való munkavégzéshez. . Használatának legalapvetőbb példáját már felvázoltuk , szóval nem ismétlem magam.
A kész megoldásokon kívül senki sem tiltja meg, hogy saját technikákat és eszközöket alkalmazzon. Ez nem csak a projekt számára lesz előnyös, hanem magának az adatminőség-mérnöknek is, aki ezáltal javítja technikai látókörét és kódolási készségeit.
Hogyan működik ez egy valós projekten
Az „adatláncról”, az ETL-ről és a mindenütt jelenlévő ellenőrzésekről szóló utolsó bekezdéseket jól szemlélteti a következő folyamat az egyik valódi projektből:
Itt különféle (természetesen általunk készített) adatok kerülnek rendszerünk bemeneti „tölcsérébe”: érvényes, érvénytelen, kevert stb., majd kiszűrik és egy közbenső tárolóba kerülnek, majd ismét egy sor átalakításon mennek keresztül. és a végső tárolóba kerülnek, ahonnan viszont az elemzés, az adatpiacok felépítése és az üzleti betekintések keresése történik. Egy ilyen rendszerben az ETL folyamatok működésének funkcionális ellenőrzése nélkül a transzformációk előtti és utáni adatok minőségére, valamint az analitika kimenetére koncentrálunk.
Összefoglalva a fentieket, függetlenül attól, hogy hol dolgoztam, mindenhol részt vettem olyan adatprojektekben, amelyek a következő jellemzőkkel rendelkeztek:
- Csak automatizálással tesztelhet bizonyos eseteket, és érheti el a vállalkozás számára elfogadható kiadási ciklust.
- Egy ilyen projekt tesztelője a csapat egyik legelismertebb tagja, mivel minden résztvevő számára nagy előnyökkel jár (tesztelés felgyorsítása, jó adatok a Data Scientisttől, hibák azonosítása a korai szakaszban).
- Nem számít, hogy a saját hardverén vagy a felhőben dolgozik – minden erőforrást egy klaszterbe vonunk össze, mint például a Hortonworks, a Cloudera, a Mesos, a Kubernetes stb.
- A projektek mikroszolgáltatási megközelítésre épülnek, az elosztott és párhuzamos számítástechnika dominál.
Szeretném megjegyezni, hogy az Adatminőség területén végzett tesztelés során a tesztelő szakember szakmai fókuszát a termék kódjára és az alkalmazott eszközökre helyezi.
Az adatminőség-teszt megkülönböztető jellemzői
Ezen túlmenően saját magam számára azonosítottam a következő (azonnal fenntartással élek, hogy ezek NAGYON általánosított és kizárólag szubjektívek) a Data (Big Data) projektekben (rendszerekben) és más területeken végzett tesztelés sajátosságait:
Hasznos Linkek
- Elmélet: .
- EPAM
- Kezdő adatminőségi mérnöknek ajánlott anyagok:
- Ingyenes tanfolyam a Stepikről: .
- Tanfolyam a LinkedIn tanulásról: .
- Cikkek:
- ;
- ;
- ;
- videók:
- ;
- ;
Következtetés
Adatminőség egy nagyon fiatal, ígéretes irányzat, amelynek részesévé válni azt jelenti, hogy egy startup része. Az adatminőséget követően számos modern, igényes technológiában merül el, de ami a legfontosabb, óriási lehetőségek nyílnak meg előtted ötletei generálására és megvalósítására. A folyamatos fejlesztési szemléletet nem csak a projekten, hanem önmaga számára is alkalmazhatja, szakemberként folyamatosan fejlődve.
Forrás: will.com