Samouczek testowania dużych zbiorów danych: czym jest, strategia, jak testować

⚡ Inteligentne podsumowanie

Testowanie dużych zbiorów danych (Big Data Testing) ma na celu sprawdzenie, czy aplikacja przetwarzająca duże zbiory danych poprawnie, szybko i bezpiecznie przetwarza terabajty danych. Łączy ono weryfikację etapowania danych, walidację MapReduce i walidację wyników ze sprawdzaniem architektury i wydajności w rozproszonym klastrze Hadoop.

🔘 Główny cel: Sprawdzane jest przetwarzanie danych w obrębie klastra, a nie poszczególne cechy produktu.
️ Trzy fazy: Przygotowanie danych, MapReduce i walidacja wyników są elementami każdego cyklu testów Hadoop.
✅ Przede wszystkim jakość danych: Przed testowaniem aplikacji sprawdzana jest zgodność, dokładność, duplikacja, spójność, ważność i kompletność.
🧪 Archima znaczenie strukturalne: Usługi wydajnościowe i failover potwierdzają, że klaster przetrwa awarię węzła bez utraty przepustowości.
🛠️. Parametry strojenia: Mierzone są układ pamięci masowej, dzienniki zatwierdzania, współbieżność, buforowanie, przekroczenia limitu czasu i ustawienia JVM.
⚠️ Znane wyzwania: Brak umiejętności w zakresie automatyzacji, opóźnienia maszyn wirtualnych i ogromne zbiory danych utrudniają testowanie dużych zbiorów danych.

Czytaj więcej

Czym jest testowanie Big Data?

Testowanie Big Data to proces testowania aplikacji Big Data, mający na celu zapewnienie, że wszystkie jej funkcjonalności działają zgodnie z oczekiwaniami. Celem testowania Big Data jest upewnienie się, że system Big Data działa płynnie i bezbłędnie, przy jednoczesnym zachowaniu wydajności i bezpieczeństwa.

Big Data to zbiór dużych zbiorów danych, których nie da się przetworzyć za pomocą tradycyjnych technik obliczeniowych. Testowanie tych zbiorów danych wymaga użycia różnych narzędzi, technik i frameworków. Big Data odnosi się do tworzenia, przechowywania, pobierania i analizy danych, co jest niezwykłe pod względem objętości, różnorodności i szybkości. Możesz dowiedzieć się więcej na ten temat. Big Data, Hadoop oraz MapaReduce zanim zaczniesz testować.

Jaka jest strategia testowania Big Data?

Testowanie aplikacji Big Data to weryfikacja przetwarzania danych, a nie testowanie poszczególnych funkcji oprogramowania. W przypadku testowania Big Data kluczowe są testy wydajnościowe i funkcjonalne.

W strategii testowania Big Data inżynierowie QA weryfikują poprawne przetwarzanie terabajtów danych za pomocą klastra commodity i innych komponentów pomocniczych. Wymaga to wysokich umiejętności testowania, ponieważ przetwarzanie jest bardzo szybkie. Przetwarzanie może mieć trzy typy:

Przetwarzanie wsadowe: Przechowywane dane są przetwarzane według harmonogramu, dzięki czemu testy mają na celu ukończenie zadania i jego dokładność.
Przetwarzanie w czasie rzeczywistym: Rekordy są przetwarzane w momencie ich otrzymania, dlatego testy skupiają się na zmniejszeniu opóźnień i utraty danych.
Przetwarzanie interaktywne: Analitycy wysyłają zapytania bezpośrednio, dlatego testy mają na celu ustalenie czasu reakcji na zapytania ad hoc.

Poniższy diagram podsumowuje tę strategię.

Oprócz tego, jakość danych jest również ważnym czynnikiem w testowaniu Hadoop. Przed przetestowaniem aplikacji konieczne jest sprawdzenie jakości danych, co powinno być częścią testowania baz danych. Obejmuje to sprawdzenie różnych cech, takich jak zgodność, dokładność, duplikacja, spójność, ważność, kompletność danych itp. W tym samouczku dotyczącym testowania Hadoop nauczymy się testować aplikacje Hadoop.

Jak testować aplikacje Hadoop

Poniższy rysunek przedstawia ogólny przegląd faz testowania aplikacji Big Data.

Testowanie Big Data, zwane także testowaniem Hadoop, można podzielić na trzy etapy.

Krok 1: Walidacja etapowania danych

Pierwszy krok w tym samouczku poświęconym testowaniu dużych zbiorów danych nazywany jest etapem przed Hadoop i dotyczy walidacji procesu.

Należy sprawdzić poprawność danych pochodzących z różnych źródeł, takich jak systemy RDBMS, blogi, media społecznościowe itp., aby mieć pewność, że do systemu trafiają prawidłowe dane.
Porównywanie danych źródłowych z danymi przesłanymi do systemu Hadoop, aby upewnić się, że są zgodne
Sprawdź, czy dane są prawidłowetraczaładował i umieścił we właściwym miejscu HDFS lokalizacja

Narzędzia takie jak Taland a Datameer może być używany do walidacji etapów przetwarzania danych.

Krok 2: Weryfikacja „MapReduce”.

Drugim krokiem jest walidacja „MapReduce”. Na tym etapie tester Big Data weryfikuje poprawność logiki biznesowej na każdym węźle, a następnie weryfikuje ją po uruchomieniu na wielu węzłach, upewniając się, że:

Proces MapReduce działa poprawnie
Na danych zaimplementowano reguły agregacji lub segregacji danych
Generowane są pary klucz-wartość
Walidacja danych po procesie MapReduce

Krok 3: Faza sprawdzania wyników

Ostatnim lub trzecim etapem testowania Hadoopa jest proces sprawdzania poprawności wyników. Wyjściowe pliki danych są generowane i gotowe do przeniesienia do EDW (Enterprise Data Warehouse) lub dowolnego innego systemu w zależności od wymagań.

Działania w trzecim etapie obejmują:

Aby sprawdzić, czy reguły transformacji zostały prawidłowo zastosowane
Aby sprawdzić integralność danych i pomyślne załadowanie danych do systemu docelowego
Aby sprawdzić, czy nie ma uszkodzeń danych, porównując dane docelowe z danymi systemu plików HDFS

ArchiTesty techniczne

Teraz uwaga skupia się na klastrze, który je przechowuje, a nie na danych.

Hadoop przetwarza bardzo duże wolumeny danych i jest bardzo zasobochłonny. Dlatego testy architektoniczne są kluczowe dla zapewnienia sukcesu projektu Big Data. Źle lub nieprawidłowo zaprojektowany system może prowadzić do spadku wydajności, a nawet niespełnienia wymagań. Co najmniej: jest gwarancją najlepszej jakości, które mogą dostarczyć Ci Twoje monitory, a usługi testowania awaryjnego powinny być uruchamiane w środowisku Hadoop.

Testowanie wydajności obejmuje testowanie czasu wykonania zadania, wykorzystania pamięci, przepustowości danych i podobnych parametrów systemowych. Celem usługi testowania przełączania awaryjnego jest weryfikacja płynności przetwarzania danych w przypadku awarii węzłów danych.

Test wydajności

Testowanie wydajności dużych zbiorów danych obejmuje trzy główne obszary.

Pobieranie danych i przepustowość: Na tym etapie tester Big Data weryfikuje, jak szybko system może pobierać dane z różnych źródeł. Testowanie obejmuje określenie liczby komunikatów, które kolejka może przetworzyć w danym przedziale czasowym. Obejmuje to również określenie szybkości wprowadzania danych do bazowego magazynu danych, na przykład częstotliwość wprowadzania do… MongoDB oraz Cassandra Baza danych.
Przetwarzanie danych: Polega ona na weryfikacji szybkości wykonywania zapytań lub zadań MapReduce. Obejmuje również testowanie przetwarzania danych w izolacji, gdy bazowy magazyn danych jest wypełniony zestawami danych. Na przykład, uruchamianie zadań MapReduce w bazowym systemie plików HDFS.
Wydajność podkomponentów: Systemy te składają się z wielu komponentów i konieczne jest przetestowanie każdego z nich osobno. Na przykład, jak szybko wiadomość jest indeksowana i przetwarzana, zadania MapReduce, wydajność zapytań, wyszukiwanie itp.

Podejście do testowania wydajności

Testowanie wydajności aplikacji Big Data wiąże się z testowaniem ogromnych ilości danych ustrukturyzowanych i nieustrukturyzowanych. Do testowania tak dużych ilości danych wymagane jest specjalne podejście.

Poniższy przepływ pracy ilustruje sekwencję czynności wykonywanych podczas testu wydajności.

Testowanie wydajności jest wykonywane w tej kolejności.

Proces rozpoczyna się od skonfigurowania klastra Big Data, który ma zostać przetestowany pod kątem wydajności
Zidentyfikuj i zaprojektuj odpowiednie obciążenia
Przygotowywanie indywidualnych klientów (tworzenie skryptów na zamówienie)
Wykonaj test i przeanalizuj wyniki (jeśli cele nie zostaną osiągnięte, dostrój komponent i wykonaj test ponownie)
Optymalna konfiguracja

Parametry do testowania wydajności

Różne parametry, które należy zweryfikować w celu przeprowadzenia testów wydajnościowych to:

Przechowywanie danych: Jak dane są przechowywane w różnych węzłach
Dzienniki zatwierdzania: Jak duży może być dziennik zatwierdzania
Konkurencja: Ile wątków może wykonywać operacje zapisu i odczytu
Buforowanie: Dostosuj ustawienia pamięci podręcznej „pamięć podręczna wierszy” i „pamięć podręczna kluczy”
Przekroczenia limitu czasu: Wartości dotyczące limitu czasu połączenia, limitu czasu zapytania itp.
Parametry JVM: Rozmiar sterty, algorytmy zbierania GC itp.
Wydajność MapReduce: Sortowanie, scalanie itp.
Kolejka wiadomości: Szybkość, rozmiar itp. wiadomości.

Potrzeby środowiska testowego

Potrzeby środowiska testowego zależą od rodzaju testowanej aplikacji. W przypadku testowania oprogramowania Big Data środowisko testowe powinno obejmować następujące elementy.

Powinien mieć wystarczająco dużo miejsca do przechowywania i przetwarzania dużej ilości danych
Powinien mieć klaster z rozproszonymi węzłami i danymi
Powinien mieć minimalne wykorzystanie procesora i pamięci, aby utrzymać wysoką wydajność w celu przetestowania wydajności Big Data

Testowanie dużych zbiorów danych a tradycyjne testowanie baz danych

Poniższa tabela porównuje te dwie dyscypliny właściwość po właściwości.

Właściwości	Tradycyjne testowanie baz danych	Testowanie dużych zbiorów danych
Dane	Tester pracuje ze strukturalnymi danymi	Tester działa zarówno z danymi ustrukturyzowanymi, jak i nieustrukturyzowanymi
Podejście testowe	Podejście do testowania jest dobrze zdefiniowane i sprawdzone w czasie	Podejście testowe wymaga ukierunkowanych wysiłków badawczo-rozwojowych
Strategia testowania	Tester ma do wyboru strategię „Próbkowania” wykonywaną ręcznie lub strategię „Weryfikacji wyczerpującej” za pomocą narzędzia automatyzującego	Strategia „próbkowania” w Big Data to wyzwanie
Infrastruktura	Nie wymaga specjalnego środowiska testowego, ponieważ rozmiar pliku jest ograniczony	Wymaga specjalnego środowiska testowego ze względu na duży rozmiar danych i plików (HDFS)
Narzędzia walidacji	Tester używa makr opartych na programie Excel lub narzędzi automatyzacji opartych na interfejsie użytkownika	Brak zdefiniowanych narzędzi; zakres jest ogromny, od narzędzi programistycznych, takich jak MapReduce, po HiveQL
Narzędzia testujące	Narzędzia testowe można używać z podstawową wiedzą operacyjną i krótkim szkoleniem	Obsługa narzędzia testowego wymaga określonych umiejętności i przeszkolenia. Co więcej, narzędzia te są w początkowej fazie rozwoju i z czasem mogą zostać wzbogacone o nowe funkcje.

Narzędzia używane w scenariuszach Big Data

Poniższa tabela grupuje popularne narzędzia według warstwy klastra.

Big Data Cluster	Narzędzia Big Data
Brak SQL:	CouchDB, Bazy danych MongoDB, Cassandra, Redis, ZooKeeper, HBase
MapaZmniejsz:	Hadoopa, Ul, Pig, Kaskadowe, Oozie, Kafka, S4, MapR, Przepływ
Przechowywanie:	S3, HDFS (rozproszony system plików Hadoop)
Serwery:	Elastyczny, Heroku, Google Silnik aplikacji, EC2
Przetwarzanie:	R, Yahoo! Rury, Mechanical Turk, BigSheets, Datameer

Wyzwania w testowaniu Big Data

W niemal każdym projekcie Big Data pojawiają się trzy praktyczne przeszkody.

Automatyka: Testy automatyczne Do Big Data potrzebny jest ktoś z wiedzą techniczną. Ponadto narzędzia automatyczne nie są przygotowane do radzenia sobie z nieoczekiwanymi problemami pojawiającymi się podczas testów.
Wirtualizacja: To jeden z integralnych etapów testowania. Opóźnienia maszyn wirtualnych powodują problemy z synchronizacją w testach wydajności Big Data w czasie rzeczywistym. Ponadto zarządzanie obrazami w Big Data jest uciążliwe.
Duży zbiór danych: Z głośnością wiążą się trzy rodzaje ciśnienia.
- Trzeba zweryfikować więcej danych i zrobić to szybciej
- Należy zautomatyzować wysiłek związany z testowaniem
- Konieczność testowania na różnych platformach

Wyzwania związane z testowaniem wydajności

Różnorodny zestaw technologii: Każdy podkomponent należy do innej technologii i wymaga testowania w izolacji
Brak dostępności określonych narzędzi: Żadne pojedyncze narzędzie nie jest w stanie przeprowadzić kompleksowego testowania. Na przykład NoSQL może nie nadawać się do kolejek komunikatów.
Skrypt testowy: Do projektowania scenariuszy testowych i przypadków testowych potrzebny jest wysoki stopień skryptowania
Środowisko testowe: Wymaga specjalnego środowiska testowego ze względu na duży rozmiar danych
Rozwiązanie monitorujące: Istnieją ograniczone rozwiązania umożliwiające monitorowanie całego środowiska
Rozwiązanie diagnostyczne: Aby dotrzeć do wąskich gardeł wydajności, potrzebne jest rozwiązanie niestandardowe

FAQ

Jakość danych jest sprawdzana w ramach testowania bazy danych, przed rozpoczęciem testowania aplikacji. Testerzy weryfikują zgodność, dokładność, duplikację, spójność, ważność i kompletność, a także szukają wartości null, problemów z kodowaniem i przesunięć kolumn.

Sztuczna inteligencja generuje syntetyczne dane testowe, które odzwierciedlają produkcję bez ujawniania prywatnych rekordów, sygnalizuje anomalie w potoku, których nie uwzględniają stałe reguły, i ustala priorytety kontroli walidacyjnych do wykonania. Ludzka kontrola logiki biznesowej pozostaje kluczowa.

Copilot i podobni asystenci agentów przyspieszają szablony: zapytania porównawcze HiveQL, PySpark asercje i skrypty uzgadniające. Najpierw uruchom wygenerowany kod na znanym, dobrym zbiorze danych, ponieważ wiarygodne zapytanie może zwalidować niewłaściwe kolumny.

Walidacja schematu potwierdza, że rekordy przychodzące zawierają oczekiwane pola, typy i dopuszczają wartości null, zanim dotrą do systemu HDFS lub bazy danych NoSQL. Wykrycie dryftu schematu podczas pobierania danych kosztuje znacznie mniej niż tracpóźniej powodując uszkodzenie wyjścia.

Zespoły łączą zamaskowany podzbiór pobrany z produkcji, wygenerowane rekordy, które analizują przypadki skrajne, takie jak wartości null i wartości odstające, oraz odtworzone strumienie danych historycznych. Samo próbkowanie jest ryzykowne, ponieważ rzadkie rekordy powodują awarie warte znalezienia.

Testowanie ETL weryfikuje strukturalne obciążenia w magazynie danych za pomocą zdefiniowanych narzędzi i przewidywalnych wolumenów. Testowanie Big Data obejmuje dane strukturalne i niestrukturalne w rozproszonym klastrze, gdzie walidacja jest tworzona w MapReduce lub HiveQL.

Zmierz szybkość przetwarzania w stosunku do rozmiaru wiadomości, wstrzyknij zaległości, aby potwierdzić przywrócenie kolejki, i zamknij węzeł w trakcie transmisji, aby upewnić się, że nic nie zostało pominięte. Porównaj zliczone okno zdarzeń źródłowych z oknem odbiorczym.

SQL i HiveQL, jeden język dla MapReduce lub Spark Praca, praktyczna znajomość HDFS i bazy danych NoSQL, a także pisanie skryptów dla systemów testowych. Rozumowanie analityczne ma większe znaczenie, ponieważ nie istnieje jedno kompleksowe narzędzie.