Witam wszystkich, nazywam się Alexander i jestem inżynierem jakości danych, który sprawdza jakość danych. Ten artykuł opowie o tym, jak do tego doszedłem i dlaczego w 2020 roku ten obszar testów był na fali.
globalny trend
Dzisiejszy świat przeżywa kolejną rewolucję technologiczną, której jednym z aspektów jest wykorzystanie zgromadzonych danych przez wszelkiego rodzaju firmy do kręcenia własnego koła zamachowego sprzedaży, zysków i PR. Wydaje się, że to właśnie dostępność dobrych (jakościowych) danych, a także sprawne mózgi, które potrafią na nich zarobić (poprawnie przetwarzać, wizualizować, budować modele uczenia maszynowego itp.), stały się dzisiaj dla wielu kluczem do sukcesu. Jeśli 15-20 lat temu duże firmy zajmowały się głównie intensywną pracą z gromadzeniem danych i ich monetyzacją, to dziś jest to los prawie wszystkich zdrowych na umyśle ludzi.
Pod tym względem kilka lat temu wszystkie portale poszukujące pracy na całym świecie zaczęły się przepełniać wakatami Data Scientist, gdyż wszyscy byli pewni, że mając takiego specjalistę w swoim zespole, zbudują supermodel uczenia maszynowego, przewidywania przyszłości i wykonać „skok kwantowy” dla firmy. Z biegiem czasu ludzie zdali sobie sprawę, że takie podejście prawie nigdy nie działa, ponieważ daleko od wszystkich danych, które wpadają w ręce takich specjalistów, nadaje się do trenowania modeli.
I zaczęły się prośby od Data Scientistów: „Kupmy więcej danych od tych i tamtych…”, „Mamy za mało danych…”, „Potrzebujemy trochę więcej danych i najlepiej wysokiej jakości…”. Na podstawie tych próśb zaczęto budować liczne interakcje między firmami, które posiadają taki lub inny zestaw danych. Naturalnie wymagało to technicznej organizacji tego procesu – podłączenia się do źródła danych, pobrania ich, sprawdzenia, czy są załadowane w całości itp. Liczba takich procesów zaczęła rosnąć, a dziś mamy ogromne zapotrzebowanie na inny rodzaj specjalistów - Inżynierów Jakości Danych - tych, którzy monitorowaliby przepływ danych w systemie (potoki danych), jakość danych na wejściu i wyjściu, wyciągali wnioski na temat ich wystarczalności, integralności i innych cech.
Trend Data Quality inżynierów przybył do nas z USA, gdzie w szalejącej epoce kapitalizmu nikt nie jest gotowy przegrać bitwy o dane. Poniżej zamieściłem zrzuty ekranu z dwóch najpopularniejszych witryn poszukiwania pracy w USA: и - które wyświetlają dane na dzień 17 marca 2020 r. o liczbie otrzymanych ofert pracy, dla słów kluczowych: Data Quality i Data Scientist.
Analitycy danych – 21416 wakatów
Jakość danych – 41104 wakatów
Analitycy danych – 404 wakaty
Jakość danych - 2020 wolnych miejsc
Oczywiście zawody te w żaden sposób ze sobą nie konkurują. Screenami chciałem tylko zobrazować obecną sytuację na rynku pracy pod kątem zapotrzebowania na inżynierów Data Quality, którzy są teraz dużo bardziej potrzebni niż Data Scientist.
W czerwcu 2019 roku EPAM, odpowiadając na potrzeby współczesnego rynku IT, wyodrębnił Data Quality jako odrębną praktykę. Inżynierowie Jakości Danych w swojej codziennej pracy zarządzają danymi, sprawdzają ich zachowanie w nowych warunkach i systemach, kontrolują aktualność danych, ich wystarczalność i przydatność. Przy tym wszystkim, w sensie praktycznym, inżynierowie Data Quality naprawdę niewiele czasu poświęcają klasycznym testom funkcjonalnym, ALE to silnie zależy od projektu (podam przykład poniżej).
Obowiązki Inżyniera Jakości Danych nie ograniczają się do rutynowych ręcznych/automatycznych kontroli „zerów, zliczeń i sum” w tabelach bazy danych, ale wymagają głębokiego zrozumienia potrzeb biznesowych klienta, a co za tym idzie, umiejętności przekształcania dostępnych danych w użyteczne informacje biznesowe.
Teoria jakości danych
Aby jak najpełniej wyobrazić sobie rolę takiego inżyniera, zastanówmy się, czym w teorii jest Data Quality.
Jakość danych - jeden z etapów Zarządzania Danymi (cały świat, który zostawimy Ci do samodzielnego studiowania) i odpowiada za analizę danych według następujących kryteriów:
Myślę, że nie warto rozszyfrowywać każdego z punktów (w teorii nazywają się one „wymiarami danych”), są one dość dobrze opisane na obrazku. Ale sam proces testowania nie oznacza ścisłego kopiowania tych funkcji do przypadków testowych i ich weryfikacji. W Data Quality, jak w każdym innym typie testowania, należy przede wszystkim opierać się na wymaganiach dotyczących jakości danych uzgodnionych z uczestnikami projektu podejmującymi decyzje biznesowe.
W zależności od projektu Data Quality, inżynier może pełnić różne funkcje: od zwykłego testera-automata z powierzchowną oceną jakości danych do osoby, która prowadzi ich głębokie profilowanie według powyższych kryteriów.
Bardzo szczegółowy opis zarządzania danymi, jakości danych i powiązanych procesów jest dobrze opisany w książce pt „DAMA-DMBOK: Zasób wiedzy o zarządzaniu danymi: wydanie 2”. Gorąco polecam tę książkę jako wprowadzenie do tego tematu (link do niej znajdziesz na końcu artykułu).
Moja historia
W branży IT przeszedłem od Junior QA w firmach produktowych do Lead Data Quality Engineer w EPAM. Po około dwóch latach pracy jako tester nabrałem przekonania, że wykonałem absolutnie wszystkie rodzaje testów: regresyjne, funkcjonalne, obciążeniowe, stabilności, bezpieczeństwa, interfejsu użytkownika itp. - i wypróbowałem wiele narzędzi testowych, które pracowały w trzy języki programowania: Java, Scala, Python.
Patrząc wstecz, rozumiem, dlaczego mój zestaw umiejętności był tak zróżnicowany — brałem udział w projektach dotyczących danych, dużych i małych. To właśnie wprowadziło mnie w świat wielu narzędzi i możliwości rozwoju.
Aby docenić różnorodność narzędzi i możliwości zdobywania nowej wiedzy i umiejętności, wystarczy spojrzeć na poniższy obrazek, który pokazuje najpopularniejsze z nich w świecie „Data & AI”.
Ten rodzaj ilustracji jest tworzony corocznie przez jednego ze znanych inwestorów venture capital, Matta Turcka, rodem z programistów. Tutaj do swojego bloga i gdzie pracuje jako partner.
Szczególnie szybko rozwinąłem się zawodowo, gdy byłem jedynym testerem w projekcie, a przynajmniej na początku projektu. To właśnie w tym momencie musisz wziąć odpowiedzialność za cały proces testowania i nie masz możliwości wycofania się, tylko do przodu. Na początku było to przerażające, ale teraz wszystkie zalety takiego testu są dla mnie oczywiste:
- Zaczynasz komunikować się z całym zespołem jak nigdy dotąd, ponieważ nie ma pełnomocnika do komunikacji: ani kierownika testów, ani innych testerów.
- Zanurzenie w projekt staje się niewiarygodnie głębokie i masz informacje o wszystkich komponentach zarówno ogólnie, jak i szczegółowo.
- Deweloperzy nie patrzą na ciebie jak na „tego testera, który nie wie, co robi”, ale raczej jak na równego sobie, tworzącego niesamowitą wartość dla zespołu dzięki autotestom i przewidywaniu błędów w określonym węźle produktu.
- W rezultacie jesteś bardziej wydajny, lepiej wykwalifikowany, bardziej poszukiwany.
Wraz z rozwojem projektu w 100% przypadków stałem się mentorem dla nowych testerów, którzy przychodzili do niego, uczyli ich i przekazywali wiedzę, której sam się nauczyłem. Jednocześnie, w zależności od projektu, nie zawsze otrzymywałem od kierownictwa specjalistów od autotestów najwyższego poziomu i trzeba było albo przeszkolić ich z automatyzacji (dla chętnych), albo stworzyć narzędzia do ich wykorzystania w codziennych czynności (narzędzia do generowania danych i ładowania ich do systemu, narzędzie do wykonywania testów obciążeniowych/szybkich testów stabilności itp.).
Przykład konkretnego projektu
Niestety, ze względu na obowiązek zachowania poufności, nie mogę szczegółowo opowiedzieć o projektach, nad którymi pracowałem, ale podam przykłady typowych zadań Inżyniera Jakości Danych na jednym z projektów.
Istotą projektu jest wdrożenie platformy do przygotowywania danych do szkolenia w oparciu o modele uczenia maszynowego. Klientem była duża firma farmaceutyczna z USA. Technicznie rzecz biorąc, był to klaster wzrastać do instancji, z kilkoma mikroserwisami i bazowym projektem Open Source z EPAM - , dostosowany do potrzeb konkretnego klienta (obecnie projekt odrodził się w ). Procesy ETL zostały zorganizowane przy użyciu i przeniosłem dane z systemy klienckie w wiadra. Następnie na platformę wdrożono obraz dockera modelu uczenia maszynowego, który został wytrenowany na świeżych danych i za pomocą interfejsu REST API wydał interesujące dla biznesu prognozy i rozwiązał konkretne problemy.
Wizualnie wyglądało to mniej więcej tak:
Testów funkcjonalnych tego projektu było bardzo dużo, a biorąc pod uwagę szybkość rozwoju funkcjonalności i konieczność utrzymania tempa cyklu wydawniczego (dwutygodniowe sprinty), trzeba było od razu pomyśleć o zautomatyzowaniu testów najbardziej krytycznych węzłów systemu . Większość samej platformy opartej na Kubernetes została objęta autotestami zaimplementowanymi na + Pythona, ale one też wymagały wsparcia i rozszerzenia. Dodatkowo dla wygody klienta stworzono GUI do zarządzania modelami uczenia maszynowego wdrożonymi do klastra, a także możliwością określenia skąd i gdzie mają być przesyłane dane do trenowania modeli. Ten obszerny dodatek pociągał za sobą rozszerzenie zautomatyzowanych kontroli funkcjonalnych, które były wykonywane głównie za pomocą wywołań interfejsu API REST i niewielkiej liczby testów interfejsu użytkownika typu end-2-end. W okolicach równika całego tego ruchu dołączył do nas tester manualny, który świetnie poradził sobie z testami akceptacyjnymi wersji produktu i komunikowaniem się z klientem w sprawie akceptacji kolejnego wydania. Dodatkowo, w związku z pojawieniem się nowego specjalisty, mogliśmy udokumentować naszą pracę i dodać kilka bardzo ważnych kontroli manualnych, które trudno było od razu zautomatyzować.
I wreszcie, po osiągnięciu stabilności platformy i dodatku GUI, zaczęliśmy budować potoki ETL przy użyciu Apache Airflow DAG. Zautomatyzowana kontrola jakości danych została przeprowadzona poprzez napisanie specjalnych Airflow DAG, które sprawdzały dane na podstawie wyników procesu ETL. W ramach tego projektu mieliśmy szczęście i klient udostępnił nam zanonimizowane zbiory danych, na których testowaliśmy. Sprawdziliśmy linia danych linia po linii pod kątem zgodności typu, obecności uszkodzonych danych, całkowitej liczby rekordów przed i po, porównania przekształceń wykonanych przez proces ETL przez agregację, zmianę nazw kolumn i tak dalej. Ponadto kontrole te zostały przeskalowane do różnych źródeł danych, na przykład oprócz SalesForce również w MySQL.
Ostateczne kontrole jakości danych zostały przeprowadzone już na poziomie S3, gdzie były przechowywane i były w stanie gotowym do użycia do trenowania modeli uczenia maszynowego. Aby uzyskać dane z końcowego pliku CSV znajdującego się w S3 Bucket i zweryfikować je, napisano kod za pomocą .
Również po stronie klienta istniał wymóg przechowywania części danych w jednym S3 Bucket, a części w innym. Wymagało to również napisania dodatkowych kontroli, które kontrolują niezawodność takiego sortowania.
Ogólne doświadczenie w innych projektach
Przykład najbardziej uogólnionej listy czynności inżyniera jakości danych:
- Przygotuj dane testowe (ważne nieprawidłowe duże małe) za pomocą zautomatyzowanego narzędzia.
- Załaduj przygotowany zestaw danych do oryginalnego źródła i sprawdź jego gotowość do użycia.
- Uruchom procesy ETL do przetwarzania zestawu danych z pamięci źródłowej do pamięci końcowej lub pośredniej przy użyciu określonego zestawu ustawień (jeśli to możliwe, ustaw konfigurowalne parametry dla zadania ETL).
- Weryfikuj dane przetwarzane przez proces ETL pod kątem ich jakości i zgodności z wymaganiami biznesowymi.
Jednocześnie głównym celem kontroli powinno być nie tylko to, czy przepływ danych w systemie w zasadzie się sprawdził i doszedł do końca (co jest częścią testów funkcjonalnych), ale przede wszystkim na sprawdzanie i walidacja danych pod kątem zgodności z oczekiwanymi wymaganiami, identyfikacja anomalii i inne rzeczy.
Narzędzia
Jedną z technik takiej kontroli danych może być organizacja kontroli łańcuchowych na każdym etapie przetwarzania danych, w literaturze tzw. Takie kontrole są najczęściej realizowane poprzez pisanie weryfikujących zapytań SQL. Oczywiste jest, że takie zapytania powinny być jak najlżejsze i sprawdzać jakość poszczególnych elementów danych (metadane tabel, puste wiersze, NULL, Błędy w składni - inne atrybuty wymagane do sprawdzenia).
W przypadku testów regresyjnych, które wykorzystują gotowe (niezmienione, nieznacznie zmienione) zestawy danych, kod autotestu może przechowywać gotowe szablony do sprawdzania zgodności danych z jakością (opisy oczekiwanych metadanych tabeli; przykładowe obiekty łańcuchowe, które można losowo wybrane podczas testu itp.).
Ponadto podczas testowania musisz napisać testowe procesy ETL przy użyciu frameworków takich jak Apache Airflow, lub nawet narzędzie chmurowe z czarną skrzynką, takie jak , I tak dalej. Ta okoliczność sprawia, że inżynier testów zagłębia się w zasady działania powyższych narzędzi i jeszcze skuteczniej zarówno przeprowadza testy funkcjonalne (np. procesy ETL istniejące w projekcie), jak i wykorzystuje je do sprawdzania danych. W szczególności Apache Airflow posiada gotowe operatory do pracy np. z popularnymi analitycznymi bazami danych . Najbardziej podstawowy przykład jego użycia został już przedstawiony. więc nie będę się powtarzać.
Oprócz gotowych rozwiązań nikt nie zabrania Ci wdrażania swoich technik i narzędzi. Będzie to korzystne nie tylko dla projektu, ale także dla samego Inżyniera Jakości Danych, który w ten sposób poprawi swoje perspektywy techniczne i umiejętności kodowania.
Jak to działa na prawdziwym projekcie
Dobrą ilustracją ostatnich akapitów o „łańcuchu danych”, ETL i wszechobecnych kontrolach jest następujący proces z jednego z rzeczywistych projektów:
Tutaj różne dane (oczywiście przygotowane przez nas) trafiają do „lejka” wejściowego naszego systemu: ważne, niepoprawne, mieszane itp., następnie są filtrowane i trafiają do pamięci pośredniej, po czym znów czeka na nie seria transformacje i umieszczane w ostatecznej pamięci masowej, która z kolei będzie wykorzystywana do analiz, budowania data martów i wyszukiwania biznesowych insightów. W takim systemie my, nie sprawdzając funkcjonalnie pracy procesów ETL, skupiamy się na jakości danych przed i po przekształceniach, a także na wyjściu do analityki.
Podsumowując powyższe, niezależnie od miejsc, w których pracowałem, wszędzie byłem zaangażowany w projekty Data, które łączyły następujące cechy:
- Tylko dzięki automatyzacji można przetestować niektóre przypadki i osiągnąć akceptowalny dla biznesu cykl wydawniczy.
- Tester w takim projekcie jest jednym z najbardziej szanowanych członków zespołu, ponieważ przynosi ogromne korzyści każdemu z uczestników (przyspieszenie testowania, dobre dane Data Scientist, wczesne wykrywanie defektów).
- Nie ma znaczenia, czy pracujesz na własnym sprzęcie, czy w chmurze — wszystkie zasoby są skupione w klastrze, takim jak Hortonworks, Cloudera, Mesos, Kubernetes itp.
- Projekty są budowane w oparciu o podejście oparte na mikroserwisach, przeważa przetwarzanie rozproszone i równoległe.
Zauważam, że testując w obszarze Data Quality, tester przenosi swoją zawodową uwagę na kod produktu i wykorzystywane narzędzia.
Charakterystyczne cechy testowania jakości danych
Ponadto dla siebie zidentyfikowałem następujące (od razu zrobię zastrzeżenie BARDZO uogólnione i skrajnie subiektywne) charakterystyczne cechy testowania w projektach (systemach) Data (Big Data) i innych obszarach:
Przydatne linki
- Teoria: .
- EPAM
- Zalecane materiały dla początkującego Inżyniera Jakości Danych:
- Darmowy kurs na Stepiku: .
- Kurs na LinkedIn Nauka: .
- Artykuły:
- ;
- ;
- ;
- Video:
- ;
- ;
wniosek
Jakość danych to bardzo młody, obiecujący kierunek, którego częścią jest bycie częścią start-upu. Będąc w Data Quality, zanurzysz się w wielu nowoczesnych technologiach, na które jest popyt, ale co najważniejsze, będziesz miał ogromne możliwości generowania i wdrażania swoich pomysłów. Będziesz mógł zastosować podejście ciągłego doskonalenia nie tylko nad projektem, ale także dla siebie, stale rozwijając się jako specjalista.
Źródło: www.habr.com