Małe pliki są dużym problemem w Hadoop — a przynajmniej są, jeśli liczba pytań na liście użytkowników na ten temat jest czymś, przez co można przejść. W tym poście przyjrzę się problemowi i przeanalizuję kilka typowych rozwiązań.
Problemy z małymi plikami i HDFS
Mały plik to taki, który jest znacznie mniejszy niż rozmiar bloku HDFS (domyślnie 64 MB). Jeśli przechowujesz małe pliki, prawdopodobnie masz ich dużo (w przeciwnym razie nie zwróciłbyś się do Hadoop), a problem polega na tym, że HDFS nie może obsłużyć wielu plików.
Każdy plik, katalog i blok w HDFS jest reprezentowany jako obiekt w pamięci nazwy węzła, z których każdy zajmuje 150 bajtów, z reguły. Tak więc 10 milionów plików, każdy używający bloku, zajęłoby około 3 gigabajtów pamięci. Skalowanie znacznie powyżej tego poziomu jest problemem z obecnym sprzętem. Z pewnością miliard plików nie jest wykonalny.
Co więcej, HDFS nie jest przystosowany do wydajnego dostępu do małych plików:jest przeznaczony przede wszystkim do strumieniowego dostępu do dużych plików. Czytanie małych plików zwykle powoduje wiele wyszukiwań i wiele przeskoków od węzła danych do węzła danych w celu pobrania każdego małego pliku, a wszystko to jest niewydajnym wzorcem dostępu do danych.
Problemy z małymi plikami i MapReduce
Zadania mapowania zwykle przetwarzają bloki danych wejściowych na raz (używając domyślnego FileInputFormat ). Jeśli plik jest bardzo mały i jest ich dużo, każde zadanie mapy przetwarza bardzo mało danych wejściowych, a zadań mapy jest o wiele więcej, z których każde nakłada dodatkowe koszty księgowe. Porównaj plik 1 GB podzielony na 16 bloków 64 MB i pliki o wielkości około 10 000 100 KB. Każdy z 10 000 plików używa jednej mapy, a czas pracy może być dziesiątki lub setki razy wolniejszy niż odpowiednik z jednym plikiem wejściowym.
Istnieje kilka funkcji, które mogą pomóc złagodzić narzuty związane z prowadzeniem księgowości:ponowne użycie JVM zadania do uruchamiania wielu zadań mapowania w jednej JVM, co pozwala uniknąć pewnych narzutów na uruchamianie JVM (zobacz mapred.job.reuse.jvm.num.tasks właściwość) i MultiFileInputSplit który może uruchomić więcej niż jeden podział na mapę.
Dlaczego produkowane są małe pliki?
Są co najmniej dwa przypadki
- Pliki są fragmentami większego pliku logicznego. Ponieważ HDFS dopiero od niedawna obsługuje dodatki, bardzo powszechnym wzorcem zapisywania niepowiązanych plików (np. plików dziennika) jest zapisywanie ich porcjami w HDFS.
- Pliki są z natury małe. Wyobraź sobie duży zbiór obrazów. Każdy obraz jest odrębnym plikiem i nie ma naturalnego sposobu na połączenie ich w jeden większy plik.
Te dwa przypadki wymagają różnych rozwiązań. W pierwszym przypadku, gdy plik składa się z rekordów, problemu można uniknąć, wywołując funkcję sync() HDFS tak często, aby stale zapisywać duże pliki. Alternatywnie, możliwe jest napisanie programu, który połączy ze sobą małe pliki.
W drugim przypadku potrzebny jest jakiś rodzaj kontenera, aby w jakiś sposób pogrupować pliki. Hadoop oferuje tutaj kilka opcji.
Pliki HAR
Archiwa Hadoop (pliki HAR) zostały wprowadzone do HDFS w wersji 0.18.0, aby złagodzić problem wielu plików wywierających presję na pamięć nazwy węzła. Pliki HAR działają poprzez budowanie warstwowego systemu plików na HDFS. Plik HAR jest tworzony przy użyciu archiwum hadoop polecenie, które uruchamia zadanie MapReduce w celu spakowania archiwizowanych plików do niewielkiej liczby plików HDFS. Dla klienta używającego systemu plików HAR nic się nie zmieniło:wszystkie oryginalne pliki są widoczne i dostępne (choć przy użyciu har:// URL). Jednak liczba plików w HDFS została zmniejszona.
Odczytywanie plików w HAR nie jest bardziej wydajne niż odczytywanie plików w HDFS, a w rzeczywistości może być wolniejsze, ponieważ każdy dostęp do pliku HAR wymaga dwóch odczytów pliku indeksowego oraz odczytu pliku danych (patrz diagram). I chociaż pliki HAR mogą być używane jako dane wejściowe do MapReduce, nie ma specjalnej magii, która pozwalałaby mapom operować na wszystkich plikach współrezydentnych HAR w bloku HDFS. Powinno być możliwe zbudowanie formatu wejściowego, który mógłby wykorzystać ulepszoną lokalizację plików w HAR, ale jeszcze nie istnieje. Zauważ, że MultiFileInputSplit, nawet z ulepszeniami HADOOP-4565, aby wybrać pliki w podziale, które są węzłami lokalnymi, będą wymagały wyszukiwania dla małego pliku. Interesujące byłoby zobaczyć wydajność tego w porównaniu do, powiedzmy, SequenceFile. W chwili obecnej pliki HAR są prawdopodobnie najlepiej używane wyłącznie do celów archiwalnych.
Pliki sekwencji
Typowa odpowiedź na pytania dotyczące „problemu z małymi plikami” to:użyj SequenceFile. Pomysł polega na tym, aby użyć nazwy pliku jako klucza i zawartości pliku jako wartości. W praktyce sprawdza się to bardzo dobrze. Wracając do 10 000 plików 100KB, możesz napisać program, który umieści je w jednym SequenceFile, a następnie możesz przetwarzać je strumieniowo (bezpośrednio lub za pomocą MapReduce) operując na SequenceFile. Jest też kilka bonusów. SequenceFiles można dzielić, więc MapReduce może dzielić je na porcje i operować na każdej porcji niezależnie. Obsługują również kompresję, w przeciwieństwie do HAR. Kompresja bloków jest najlepszą opcją w większości przypadków, ponieważ kompresuje bloki kilku rekordów (a nie jednego rekordu).
Konwersja istniejących danych do SequenceFiles może być powolna. Równoległe tworzenie kolekcji SequenceFiles jest jednak całkowicie możliwe. (Stuart Sierra napisał bardzo przydatny post o konwersji pliku tar do SequenceFile — narzędzia takie jak to są bardzo przydatne i dobrze byłoby zobaczyć ich więcej). Idąc dalej, najlepiej jest zaprojektować potok danych tak, aby w miarę możliwości zapisywać dane ze źródła bezpośrednio w SequenceFile, zamiast zapisywać do małych plików jako krok pośredni.
W przeciwieństwie do plików HAR nie ma możliwości wyświetlenia wszystkich kluczy w SequenceFile, poza odczytaniem całego pliku. (MapFiles, które są podobne do SequenceFiles z posortowanymi kluczami, zachowują częściowy indeks, więc nie mogą też wyświetlić wszystkich swoich kluczy — patrz diagram.)
SequenceFile jest raczej skoncentrowany na Javie. TFile został zaprojektowany jako wieloplatformowy i może zastąpić SequenceFile, ale nie jest jeszcze dostępny.
HBase
Jeśli tworzysz wiele małych plików, wtedy, w zależności od wzorca dostępu, bardziej odpowiedni może być inny typ pamięci. HBase przechowuje dane w MapFiles (indeksowane SequenceFiles) i jest dobrym wyborem, jeśli chcesz przeprowadzać analizy strumieniowe w stylu MapReduce z sporadycznym wyszukiwaniem losowym. Jeśli opóźnienie jest problemem, istnieje wiele innych możliwości — zobacz doskonałą ankietę Richarda Jonesa dotyczącą sklepów z kluczową wartością.
