Cześć wszystkim, nazywam się Aleksander i jestem inżynierem jakości danych, zajmującym się weryfikacją jakości danych. W tym artykule opowiem, jak do tego doszedłem i dlaczego w 2020 roku ta dziedzina testowania stała się tak popularna.
Globalny trend
Dzisiejszy świat przeżywa kolejną rewolucję technologiczną, z której jednym z aspektów jest wykorzystanie danych przez różne firmy do napędzania swoich procesów sprzedaży, zysków i PR. Wygląda na to, że posiadanie dobrych (jakościowych) danych oraz zdolnych ludzi, którzy potrafią przekształcać je w zyski (prawidłowo przetwarzać, wizualizować, budować modele uczenia maszynowego itd.), stały się kluczem do sukcesu dla wielu firm. Jeśli 15-20 lat temu intensywną pracą nad gromadzeniem danych i ich monetyzacją zajmowały się głównie duże przedsiębiorstwa, to dziś jest to domeną praktycznie wszystkich rozsądnych.
W związku z tym kilka lat temu wszystkie portale poświęcone poszukiwaniu pracy na całym świecie zaczęły być zalewane ofertami pracy dla Data Scientists, ponieważ wszyscy byli przekonani, że zatrudniając takiego specjalistę, można stworzyć supermodel uczenia maszynowego, przewidzieć przyszłość i dokonać 'kwantowego skoku' dla firmy. Z czasem ludzie zrozumieli, że takie podejście prawie nigdzie nie działa, ponieważ nie wszystkie dane, które trafiają w ręce takich specjalistów, nadają się do trenowania modeli.
I zaczęły się prośby ze strony Data Scientists: 'Kupmy więcej danych od tych i tych...', 'Brakuje nam danych...', 'Potrzebujemy jeszcze trochę danych, a najlepiej jakościowych...'. Na podstawie tych próśb zaczęły się budować liczne interakcje między firmami posiadającymi różne zbiory danych. Naturalnie wymagało to technicznej organizacji tego procesu – podłączenia do źródła danych, pobrania ich, sprawdzenia, czy zostały załadowane w pełnym zakresie itd. Liczba takich procesów zaczęła rosnąć, a dziś mamy ogromne zapotrzebowanie na innego rodzaju specjalistów – inżynierów jakości danych – którzy obserwowaliby przepływ danych w systemie (data pipelines), dbali o jakość danych na wejściu i wyjściu, wyciągali wnioski o ich wystarczalności, integralności i innych charakterystykach.
Trend na inżynierów jakości danych przyszedł do nas z USA, gdzie w czasie szalejącej ery kapitalizmu nikt nie jest gotowy przegrać walki o dane. Poniżej przedstawiam zrzuty ekranu z dwóch najbardziej popularnych stron z ofertami pracy w USA: i — na których przedstawiono dane na dzień 17 marca 2020 roku dotyczące liczby opublikowanych ofert pracy, związanych ze słowami kluczowymi: Data Quality i Data Scientist.
Data Scientists – 21416 ofert pracy
Data Quality – 41104 ofert pracy
Data Scientists – 404 ofert pracy
Data Quality – 2020 ofert pracy
Oczywiście, że te profesje w żaden sposób nie konkurują ze sobą. Zrzutami ekranu chciałem po prostu zilustrować aktualną sytuację na rynku pracy mianowicie zapotrzebowanie na inżynierów jakości danych, których obecnie potrzebujemy znacznie więcej niż Data Scientists.
W czerwcu 2019 roku EPAM, odpowiadając na potrzeby nowoczesnego rynku IT, wyodrębnił kierunek Data Quality jako odrębną praktykę. Inżynierowie jakości danych w trakcie swojej codziennej pracy zarządzają danymi, sprawdzają ich zachowanie w nowych warunkach i systemach, kontrolują adekwatność danych, ich wystarczalność i aktualność. Przy tym wszystkim w praktycznym sensie inżynierowie jakości danych rzeczywiście poświęcają trochę czasu na klasyczne testowanie funkcjonalne, NIE co w dużej mierze zależy od projektu (podam przykład później).
Obowiązki inżyniera jakości danych nie ograniczają się tylko do rutynowych ręcznych/automatycznych sprawdzeń na „nulls, count i sums” w tabelach baz danych, ale wymagają głębokiego zrozumienia potrzeb biznesowych klienta, a co za tym idzie, umiejętności przekształcania posiadanych danych w użyteczną informację biznesową.
Teoria jakości danych
Żeby jak najlepiej zrozumieć rolę takiego inżyniera, przyjrzyjmy się, czym jest teoria jakości danych.
Jakość danych — jest jednym z etapów zarządzania danymi (cały świat, który pozostawiamy do samodzielnego zgłębienia) i odpowiada za analizę danych według następujących kryteriów:
Myślę, że nie ma sensu szczegółowo opisywać każdego z punktów (teoretycznie nazywa się to „wymiary danych”), są one dobrze opisane na obrazku. Jednak sam proces testowania nie zakłada ścisłego kopiowania tych cech do przypadków testowych i ich weryfikacji. W zakresie jakości danych, 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 inżynier jakości danych może pełnić różne funkcje: od zwykłego testera automatyzacji z powierzchowną oceną jakości danych, po osobę przeprowadzającą ich głębokie profilowanie według powyższych cech.
Bardzo szczegółowy opis procesów zarządzania danymi, jakości danych i pokrewnych znajduje się w książce pod tytułem „DAMA-DMBOK: Zbiór Wiedzy o Zarządzaniu Danymi: 2. edycja”. Gorąco polecam tę książkę jako wstęp do tej tematyki (link do niej znajdziesz na końcu artykułu).
Moja historia
W branży IT przeszedłem drogę od Junior testera w firmach produktowych do Lead Data Quality Engineer w firmie EPAM. Już po około dwóch latach pracy jako tester byłem przekonany, że wykonywałem wszystkie rodzaje testów: regresyjnych, funkcjonalnych, obciążeniowych, stabilności, bezpieczeństwa, UI itd. — i przetestowałem wiele narzędzi testowych, pracując w trzech językach programowania: Java, Scala, Python.
Patrząc wstecz, rozumiem, dlaczego zestaw moich umiejętności zawodowych był tak różnorodny — brałem udział w projektach związanych z pracą z danymi, dużymi i małymi. To właśnie doprowadziło mnie do świata wielu narzędzi i możliwości rozwoju.
Aby ocenić różnorodność narzędzi i możliwości zdobywania nowej wiedzy i umiejętności, wystarczy spojrzeć na obrazek poniżej, na którym przedstawione są najpopularniejsze z nich w świecie „Danych i AI”.
Tego rodzaju ilustracje przygotowuje corocznie jeden z znanych inwestorów venture capital Matt Turck, który ma doświadczenie w programowaniu. Oto jego blog i , w której pracuje jako partner.
Szybko rozwijałem swoje umiejętności, gdy byłem jedynym testującym w projekcie, przynajmniej na początku. W takim momencie odpowiada się za cały proces testowania i nie ma możliwości wycofania się, tylko iść naprzód. Na początku było to przerażające, ale teraz dostrzegam wszystkie zalety takiego doświadczenia:
- Zaczynasz komunikować się z całym zespołem jak nigdy dotąd, ponieważ nie ma żadnego pośrednika w komunikacji: ani menedżera testów, ani kolegów testerów.
- Zanurzenie w projekt staje się niezwykle głębokie, a Ty posiadasz informacje o wszystkich komponentach zarówno w ogólnym zarysie, jak i w szczegółach.
- Programiści nie patrzą na Ciebie jak na 'tego gościa z testowania, który nie wiadomo czym się zajmuje', lecz raczej jak na równego sobie, przynoszącego niesamowitą wartość dla zespołu swoimi testami automatycznymi i przewidywaniem pojawienia się błędów w konkretnym elemencie produktu.
- W rezultacie — jesteś bardziej efektywny, bardziej wykwalifikowany, bardziej poszukiwany.
W miarę rozwoju projektu w 100% przypadków stawałem się mentorem dla nowych testerów, szkoląc ich i przekazując wiedzę, którą sam zdobyłem. W zależności od projektu, nie zawsze otrzymywałem od kierownictwa specjalistów do testów automatycznych najwyższego poziomu, dlatego istniała konieczność albo ich przeszkolenia w automatyzacji (dla chętnych), albo stworzenia narzędzi, które mogliby używać w codziennych aktywnościach (narzędzia do generowania danych i ich wgrywania do systemu, narzędzie do przeprowadzania testów obciążeniowych/testów stabilności 'na szybko' itd.).
Przykład konkretnego projektu
Niestety, z powodu zobowiązań dotyczących poufności nie mogę szczegółowo opowiadać o projektach, w których pracowałem, ale podam przykłady typowych zadań Inżyniera Jakości Danych w jednym z projektów.
Istotą projektu była realizacja platformy do przetwarzania danych w celu szkolenia modeli uczenia maszynowego. Zamawiającym była duża firma farmaceutyczna z USA. Technicznie był to klaster , uruchamiany na instancjach, z kilkoma mikroserwisami i bazującym na otwartym kodzie źródłowym projektem firmy EPAM — , dostosowanym do potrzeb konkretnego zleceniodawcy (obecnie projekt przekształcił się w ). Procesy ETL były organizowane przy pomocy i przenosili dane z systemu klienta do Buckets. Następnie na platformę został zaimplementowany obraz Dockera modelu uczenia maszynowego, który uczył się na świeżych danych i przez interfejs REST API dostarczał prognozy, które interesowały biznes i rozwiązywały konkretne problemy.
Wizualnie wszystko wyglądało mniej więcej tak:
Funkcjonalnego testowania na tym projekcie było pod dostatkiem, a biorąc pod uwagę tempo rozwoju funkcji i konieczność utrzymania cyklu wydania (dwu tygodniowe sprinty), należało od razu pomyśleć o automatyzacji testowania najważniejszych elementów systemu. Większa część samej platformy opartej na Kubernetes była pokryta testami automatycznymi, zrealizowanymi w + Python, ale ich utrzymanie i rozszerzanie również było konieczne. Co więcej, dla wygody klienta stworzono GUI do zarządzania modelami uczenia maszynowego zainstalowanymi na klastrze oraz możliwość określenia, skąd i dokąd należy przenieść dane do szkolenia modeli. To obszerne uzupełnienie pociągnęło za sobą rozszerzenie automatycznych funkcjonalnych testów, które w większości przeprowadzano poprzez wywołania REST API i niewielką liczbę testów end-2-end UI. Około w połowie tego procesu dołączył do nas tester ręczny, który doskonale radził sobie z testowaniem akceptacyjnym wersji produktu oraz komunikacją z klientem w sprawie akceptacji kolejnego wydania. Co więcej, dzięki pojawieniu się nowego specjalisty mogliśmy dokumentować naszą pracę i dodać kilka bardzo ważnych ręcznych testów, które było trudno od razu zautomatyzować.
I w końcu, po osiągnięciu stabilności platformy i nadbudowy GUI, przystąpiliśmy do budowy ETL pipelines przy użyciu Apache Airflow DAGs. Automatyczna kontrola jakości danych była realizowana poprzez pisanie specjalnych DAGów Airflow, które sprawdzały dane w oparciu o wyniki działania procesu ETL. W ramach tego projektu mieliśmy szczęście, ponieważ klient udostępnił nam dostęp do zanonimizowanych zbiorów danych, na których przeprowadzaliśmy testy. Sprawdzaliśmy dane linia po linii pod kątem zgodności typów, obecności uszkodzonych danych, ogólnej liczby rekordów przed i po, porównania dokonanych przez proces ETL transformacji w zakresie agregacji, zmiany nazw kolumn i innych. Dodatkowo, te kontrole były skalowane na różne źródła danych, na przykład oprócz SalesForce także na MySQL.
Kontrole końcowej jakości danych były realizowane na poziomie S3, gdzie były one przechowywane i były w stanie ready-to-use do szkolenia modeli uczenia maszynowego. Aby uzyskać dane z końcowego pliku CSV, leżącego na S3 Bucket, i ich walidacji, napisano kod z użyciem .
Również ze strony klienta istniało wymaganie przechowywania części danych w jednym S3 Bucket, a części w innym. W tym celu także konieczne było napisanie dodatkowych kontroli, które kontrolowały poprawność takiego sortowania.
Uogólnione doświadczenie z innych projektów
Przykład najbardziej ogólnej listy aktywności inżyniera ds. jakości danych:
- Przygotować dane testowe (ważne, nieważne, dużej i małej wielkości) za pomocą zautomatyzowanego narzędzia.
- Załadować przygotowany zestaw danych do źródła i sprawdzić jego gotowość do użycia.
- Uruchomić procesy ETL w celu przetworzenia zestawu danych z źródłowego repozytorium do końcowego lub pośredniego z zastosowaniem określonego zestawu ustawień (w przypadku możliwości określenia konfigurowalnych parametrów dla zadania ETL).
- Weryfikować przetworzone dane procesem ETL pod kątem ich jakości i zgodności z wymaganiami biznesowymi.
Główny nacisk w kontroli powinien być kładziony nie tylko na to, że strumień danych w systemie działa poprawnie i dociera do końca (co jest częścią testowania funkcjonalnego), ale przede wszystkim na weryfikację i walidację danych pod kątem zgodności z oczekiwanymi wymaganiami, identyfikacji anomalii i innych aspektów.
Narzędzia
Jedną z technik takiej kontroli nad danymi może być organizacja łańcuchowych kontroli na każdym etapie przetwarzania danych, tzw. „data chain” — kontrola danych od źródła do miejsca ostatecznego ich wykorzystania. Takie kontrole najczęściej realizowane są poprzez pisanie zapytań SQL weryfikujących. Oczywiście, zapytania te powinny być maksymalnie lekkie i sprawdzać poszczególne fragmenty jakości danych (metadata tabel, puste linie, NULL-e, błędy w składni — inne wymagane atrybuty kontroli).
W przypadku testowania regresyjnego, w którym wykorzystuje się już gotowe (niezmienialne lub niewielkie zmiany) zestawy danych, w kodzie autotestów można przechowywać już gotowe szablony kontroli danych pod kątem jakości (opisy oczekiwanych metadanych tabel; wybierane losowo obiekty próbne, które mogą być wybrane podczas testu, i inne).
Podczas testowania konieczne jest również pisanie testowych procesów ETL przy użyciu frameworków takich jak Apache Airflow, lub całkowicie narzędzi black-box typu , i inne. Taka sytuacja zmusza inżyniera testów do zgłębienia zasad działania powyższych narzędzi, aby efektywniej przeprowadzać testy funkcjonalne (na przykład istniejących procesów ETL w projekcie) oraz wykorzystać je do weryfikacji danych. W szczególności dla Apache Airflow dostępne są gotowe operatory do pracy z popularnymi bazami danych analitycznych, na przykład . Najbardziej podstawowy przykład jego użycia został już opisany , dlatego nie będę się powtarzać.
Oprócz gotowych rozwiązań, nikt nie zabrania Wam realizować własnych technik i narzędzi. To przyniesie korzyści nie tylko projektowi, ale także samemu inżynierowi ds. jakości danych, który w ten sposób rozwinie swoje techniczne kompetencje i umiejętności kodowania.
Jak to działa w rzeczywistym projekcie
Dobrym przykładem ostatnich akapitów dotyczących 'łańcucha danych', ETL i wszechobecnych kontroli jest poniższy proces z jednego z prawdziwych projektów:
Tutaj do wejściowej 'lejek' naszego systemu trafiają różne dane (oczywiście przygotowane przez nas): poprawne, niepoprawne, mieszane itd., następnie są filtrowane i trafiają do tymczasowego repozytorium, a potem jeszcze czeka je szereg przekształceń i umieszczenie w docelowym repozytorium, z którego będzie przeprowadzana analiza, budowa hurtowni danych i poszukiwanie możliwości biznesowych. W takim systemie, nie sprawdzając funkcjonalnie pracy procesów ETL, koncentrujemy się na jakości danych przed i po przekształceniach, a także na wyjściu do analizy.
Podsumowując, niezależnie od miejsc, w których pracowałem, zawsze byłem zaangażowany w projekty Data, które charakteryzowały się następującymi cechami:
- Tylko poprzez automatyzację można przetestować niektóre przypadki i osiągnąć akceptowalny dla biznesu cykl wydania.
- 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 dla Data Scientist, wykrywanie defektów na wczesnych etapach).
- Nie ważne, czy pracujesz na swoim sprzęcie, czy w chmurze — wszystkie zasoby są zorganizowane w klaster typu Hortonworks, Cloudera, Mesos, Kubernetes itd.
- Projekty są budowane w oparciu o podejście mikrousługowe, dominuje rozproszone i równoległe przetwarzanie.
Zauważam, że zajmując się testowaniem w obszarze jakości danych, specjalista ds. testowania przesuwa swój profesjonalny fokus na kod produktu i używanych narzędzi.
Cechy wyróżniające testowanie jakości danych.
Ponadto wyodrębniłem następujące (zaraz podkreślę BARDZO ogólne i wyłącznie subiektywne) cechy wyróżniające testowanie w projektach Data (Big Data) i innych obszarach:
Przydatne linki
- Teoria: .
- EPAM
- Zalecane materiały dla początkującego inżyniera jakości danych:
- Bezpłatny kurs na Stepik: .
- Kurs na LinkedIn Learning: .
- Artykuły:
- ;
- ;
- ;
- Wideo:
- ;
- ;
Podsumowanie
Jakość danych — to bardzo młoda, obiecująca dziedzina, bycie częścią której oznacza bycie częścią pewnego startupu. Wchodząc w Data Quality, zanurzysz się w dużej liczbie nowoczesnych, poszukiwanych technologii, ale najważniejsze — przed tobą otworzą się ogromne możliwości generowania i realizacji własnych pomysłów. Będziesz mógł wykorzystać podejście ciągłego doskonalenia nie tylko w projekcie, ale również dla siebie, nieprzerwanie rozwijając się jako specjalista.
Źródło: habr.com
