Omówiliśmy Funkcje Hadoop w naszym poprzednim samouczku Hadoop. Teraz omówimy ograniczenia Hadoopa. Istnieje wiele wad frameworków Apache Hadoop.
Na przykład problem z małymi plikami, powolne przetwarzanie, tylko przetwarzanie wsadowe, opóźnienie, problem z zabezpieczeniami, luka w zabezpieczeniach, brak pamięci podręcznej itp.
Wszystkie te ograniczenia Hadoop omówimy szczegółowo w tym samouczku Hadoop.
Co to jest Hadoop?
Apache Hadoop to platforma oprogramowania typu open source do rozproszonego przechowywania i przetwarzania ogromnych ilości zestawów danych. Open source oznacza, że jest dostępny bezpłatnie, a nawet możemy zmienić jego kod źródłowy zgodnie z wymaganiami.
Apache Hadoop umożliwia również uruchamianie aplikacji w systemie z tysiącami węzłów. Rozproszony system plików zapewnia szybkie szybkości przesyłania danych między węzłami.
Pozwala również systemowi na kontynuowanie działania w przypadku awarii węzła. Główne cechy Hadoopa są następujące:
- W Apache Hadoop dane są dostępne pomimo awarii maszyny spowodowanej wieloma kopiami danych. Tak więc, jeśli jakakolwiek maszyna ulegnie awarii, można uzyskać dostęp do danych z innej ścieżki.
- Apache Hadoop jest skalowalny, ponieważ łatwo jest dodać nowy sprzęt do węzła.
- Hadoop jest wysoce odporny na uszkodzenia, ponieważ domyślnie 3 repliki każdego bloku są przechowywane w klastrze. Tak więc, jeśli którykolwiek węzeł w klastrze ulegnie awarii, dane w tym węźle można łatwo odzyskać z drugiego węzła.
- Apache Hadoop działa na klastrze zwykłego sprzętu, który nie jest bardzo drogi.
- W Apache Hadoop dane są niezawodnie przechowywane w klastrze pomimo awarii sprzętu spowodowanej replikacją danych w klastrze.
Chociaż Hadoop jest najpotężniejszym narzędziem Big Data, ma on różne ograniczenia. Ze względu na ograniczenia Hadoop powstały Apache Spark i Apache Flink.
Ograniczenia Hadoop
Różne ograniczenia Apache Hadoop są podane poniżej wraz z ich rozwiązaniem-
a. Problemy z małymi plikami
Główny problem z Hadoop polega na tym, że nie nadaje się do małych danych. HDFS nie ma możliwości obsługi losowego odczytu małych ze względu na konstrukcję o dużej pojemności.
Małe pliki są mniejsze niż rozmiar bloku HDFS (domyślnie 128 MB). Jeśli przechowujesz tak dużą liczbę małych plików, HDFS nie poradzi sobie z tak dużą ilością małych plików.
Ponieważ HDFS został zaprojektowany do pracy z niewielką liczbą dużych plików do przechowywania dużych zestawów danych, a nie z dużą liczbą małych plików. Jeśli istnieje wiele małych plików, NameNode będzie przeciążony, ponieważ przechowuje przestrzeń nazw HDFS.
Rozwiązanie:
Po prostu połącz małe pliki, aby utworzyć większe pliki, a następnie skopiuj większe do HDFS.
Archiwa Hadoop (pliki HAR) rozwiązuje problem wielu małych plików. Archiwa Hadoop działają poprzez budowanie warstwowego systemu plików na szczycie HDFS.
Za pomocą polecenia archiwum pomocy Hadoop tworzone są pliki HAR; uruchamia to zadanie MapReduce, aby spakować archiwizowane pliki do niewielkiej liczby plików HDFS. Odczytywanie plików przez HAR nie jest bardziej wydajne niż czytanie przez HDFS.
Ponieważ każdy dostęp do pliku HAR wymaga odczytania dwóch plików indeksowych oraz pliku danych do odczytania, spowoduje to spowolnienie.
Pliki sekwencyjne również rozwiązują problem małych plików. W którym używamy nazwy pliku jako klucza i zawartości pliku jako wartości.
Pisząc program dla plików (100 KB), możemy umieścić je w jednym pliku Sekwencji, a następnie przetwarzać je w trybie strumieniowym operując na pliku Sekwencji.
MapReduce w Hadoop może dzielić plik sekwencji na porcje i operować na każdej porcji niezależnie, ponieważ plik sekwencji można podzielić.
Przechowując pliki w Hbase możemy rozwiązać problem małych plików. W rzeczywistości nie przechowujemy milionów małych plików w HBase, a raczej dodajemy zawartość binarną pliku do komórki.
b. Niska prędkość przetwarzania
MapReduce przetwarza ogromne ilości danych. W Hadoop MapReduce działa, dzieląc przetwarzanie na fazy:Mapa i Zmniejsz . Tak więc MapReduce wymaga dużo czasu na wykonanie tych zadań, co zwiększa opóźnienie. W związku z tym zmniejsza prędkość przetwarzania.
Rozwiązanie:
Dzięki przetwarzaniu danych w pamięci Apache Spark rozwiązuje ten problem. Podobnie jak w przypadku przetwarzania w pamięci, nie trzeba poświęcać czasu na przenoszenie danych/procesów do iz dysku, dzięki czemu jest to szybsze.
Apache Spark jest 100 razy szybszy w porównaniu z MapReduce, ponieważ przetwarza wszystko w pamięci.
Flink może również rozwiązać ten problem. Flink przetwarza szybciej niż Spark ze względu na swoją architekturę przesyłania strumieniowego.
c. Obsługa tylko przetwarzania wsadowego
Hadoop obsługuje tylko przetwarzanie wsadowe, nie nadaje się do przesyłania strumieniowego danych. W związku z tym ogólna wydajność jest wolniejsza. Framework MapReduce nie wykorzystuje maksymalnie pamięci klastra Hadoop.
Rozwiązanie
Apache Spark rozwiązuje ten problem, ponieważ obsługuje przetwarzanie strumieniowe. Ale przetwarzanie strumienia Spark nie jest tak wydajne, jak Flink, ponieważ wykorzystuje przetwarzanie mikrowsadowe. Apache Flink poprawia ogólną wydajność, ponieważ zapewnia pojedynczy czas działania do przesyłania strumieniowego i przetwarzania wsadowego.
d. Brak przetwarzania w czasie rzeczywistym
Apache Hadoop to platforma przetwarzania wsadowego. Oznacza to, że pobiera ogromną ilość danych wejściowych, przetwarza je i generuje wynik.
Przetwarzanie wsadowe jest bardzo wydajne w przypadku przetwarzania dużej ilości danych, ale zależy od rozmiaru przetwarzanych danych i mocy obliczeniowej systemu; wyjście może być znacznie opóźnione. Apache Hadoop nie nadaje się do przetwarzania w czasie rzeczywistym.
Rozwiązanie:
Spark nadaje się do przetwarzania strumieniowego. Przetwarzanie na parze zapewnia ciągłe dane wejściowe/wyjściowe. Przetwarza dane w krótkim czasie.
Flink zapewnia pojedynczy czas działania zarówno dla strumieniowania, jak i przetwarzania wsadowego.
e. Przetwarzanie iteracyjne
Apache Hadoop nie jest zbyt wydajny w przetwarzaniu iteracyjnym. Ponieważ Hadoop nie jest obsługiwany cykliczny przepływ danych (tj. łańcuch etapów, w którym każde wyjście poprzedniego etapu jest wejściem do następnego etapu).
Rozwiązanie:
Spark rozwiązuje ten problem. Ponieważ Apache Spark uzyskuje dostęp do danych z pamięci RAM zamiast z dysku. To znacznie poprawia wydajność iteracyjnego algorytmu, który wielokrotnie uzyskuje dostęp do tego samego zestawu danych.
W Apache Spark, w przypadku przetwarzania iteracyjnego, każda iteracja musi być zaplanowana i wykonana oddzielnie.
f. Opóźnienie
MapReduce w Hadoop działa wolniej, ponieważ obsługuje różne formaty, strukturę i ogromną ilość danych. W MapReduce funkcja Map pobiera zestaw danych i przekształca go w inny zestaw danych, w którym pojedynczy element jest podzielony na parę klucz-wartość.
Reduce pobiera dane wyjściowe z mapy jako, a Reduce pobiera dane wyjściowe z mapy jako dane wejściowe i przetwarza je dalej. MapReduce wymaga dużo czasu na wykonanie tych zadań, zwiększając w ten sposób opóźnienia.
Rozwiązanie:
Apache Spark może zmniejszyć ten problem. Chociaż Spark jest systemem wsadowym, jest stosunkowo szybszy, ponieważ buforuje większość danych wejściowych w pamięci przez RDD. Strumieniowe przesyłanie danych Apache Flink zapewnia niskie opóźnienia i wysoką przepustowość.
g. Brak łatwości użytkowania
Programista MapReduce w Hadoop musi podawać kod dla każdej operacji, co bardzo utrudnia pracę. W Hadoop MapReduce nie ma trybu interaktywnego, ale dodanie ula i świni znacznie ułatwia pracę z MapReduce.
Rozwiązanie:
Spark rozwiązał ten problem, ponieważ Spark ma tryb interaktywny. Dzięki temu zarówno programiści, jak i użytkownicy mogą otrzymywać pośrednie opinie na temat zapytań i innych działań.
Ponieważ Spark ma mnóstwo operatorów wysokiego poziomu, łatwo jest go zaprogramować. Można również użyć Apache Flink, ponieważ ma również operatorów wysokiego poziomu.
godz. Problem bezpieczeństwa
Apache Hadoop stanowi wyzwanie w utrzymaniu złożonych aplikacji. Hadoop nie ma szyfrowania na poziomie pamięci masowej i sieci, co jest poważnym problemem. Apache Hadoop obsługuje uwierzytelnianie Kerberos, które jest trudne do zarządzania.
Rozwiązanie:
Apache Spark zapewnia bonus bezpieczeństwa. Jeśli uruchamiasz Apache Spark w HDFS, może on korzystać z list ACL HDFS i uprawnień na poziomie plików.
ja. Narażony z natury
Apache Hadoop jest napisany w Javie. Java jest najpopularniejszym językiem, dlatego java jest najczęściej wykorzystywana przez cyberprzestępców.
j. Brak buforowania
Apache Hadoop nie jest wydajny w przypadku buforowania. MapReduce nie może buforować danych pośrednich w pamięci na potrzeby dalszych wymagań, co zmniejsza wydajność Hadoop.
Rozwiązanie:
Spark i Flink rozwiązują ten problem. Dane pamięci podręcznej Spark i Flink w pamięci do dalszych iteracji, które poprawiają ogólną wydajność.
k. Długi kod
Apache Hadoop ma 1, 20 000 linii kodu. Liczba linii daje liczbę błędów. Dlatego uruchomienie programów zajmie więcej czasu.
Rozwiązanie:
Spark i Flink są napisane w Scali i Javie. Ale implementacja jest w Scali, więc liczba linii kodu jest mniejsza niż Hadoop. Dzięki temu uruchamianie programów zajmuje mniej czasu.
Wniosek
W wyniku ograniczeń Hadoopa pojawiła się potrzeba Sparka i Flinka. W ten sposób spraw, aby system był bardziej przyjazny do gry z ogromną ilością danych.
Apache Spark zapewnia przetwarzanie danych w pamięci, poprawiając w ten sposób szybkość przetwarzania. Flink poprawia wydajność, ponieważ zapewnia pojedynczy czas działania dla przesyłania strumieniowego, a także przetwarzania wsadowego.
Spark zapewnia bonus bezpieczeństwa. Dlatego można rozwiązać wszystkie te ograniczenia Hadoop, korzystając z innych technologii Big Data, takich jak Apache Spark i Flink.
Jeśli znajdziesz inne ograniczenia Hadoop, daj nam znać, zostawiając komentarz w sekcji podanej poniżej.
