Malé soubory jsou v Hadoopu velkým problémem – nebo alespoň jsou, pokud je počet otázek v seznamu uživatelů na toto téma nějak omezen. V tomto příspěvku se podívám na problém a prozkoumám některá běžná řešení.
Problémy s malými soubory a HDFS
Malý soubor je takový, který je výrazně menší než velikost bloku HDFS (výchozí 64 MB). Pokud ukládáte malé soubory, pravděpodobně jich máte hodně (jinak byste se neobrátili na Hadoop) a problém je v tom, že HDFS si se spoustou souborů neporadí.
Každý soubor, adresář a blok v HDFS je reprezentován jako objekt v paměti jmenného uzlu, z nichž každý zabírá 150 bajtů, jako pravidlo. Takže 10 milionů souborů, každý pomocí bloku, by zabralo asi 3 gigabajty paměti. Rozšíření mnohem za tuto úroveň je problém současného hardwaru. Miliarda souborů rozhodně není proveditelná.
Kromě toho HDFS není zaměřen na efektivní přístup k malým souborům:je primárně navržen pro streamování přístupu k velkým souborům. Čtení malých souborů obvykle způsobuje mnoho hledání a mnoho přeskakování z datového uzlu na datový uzel za účelem načtení každého malého souboru, což je všechno neefektivní vzor přístupu k datům.
Problémy s malými soubory a MapReduce
Mapové úlohy obvykle zpracovávají blok vstupu najednou (pomocí výchozího FileInputFormat ). Pokud je soubor velmi malý a je jich mnoho, pak každá mapová úloha zpracovává velmi málo vstupů a existuje mnohem více mapových úloh, z nichž každá vyžaduje další účetní režii. Porovnejte 1GB soubor rozdělený do 16 64MB bloků a 10 000 nebo tak 100 kB souborů. Každý z 10 000 souborů používá jednu mapu a doba úlohy může být desítky nebo stokrát pomalejší než ekvivalentní soubor s jedním vstupním souborem.
Existuje několik funkcí, které pomáhají zmírnit režii účetnictví:opětovné použití JVM pro spouštění více mapových úloh v jednom JVM, čímž se vyhnete režii při spuštění JVM (viz mapred.job.reuse.jvm.num.tasks property) a MultiFileInputSplit který může mít více než jedno rozdělení na mapu.
Proč vznikají malé soubory?
Existují nejméně dva případy
- Soubory jsou části většího logického souboru. Vzhledem k tomu, že HDFS podporuje připojení teprve nedávno, velmi běžným vzorem pro ukládání neomezených souborů (např. souborů protokolu) je jejich zapisování po částech do HDFS.
- Soubory jsou ze své podstaty malé. Představte si velký korpus obrázků. Každý obrázek je samostatný soubor a neexistuje žádný přirozený způsob, jak je spojit do jednoho většího souboru.
Tyto dva případy vyžadují různá řešení. V prvním případě, kdy se soubor skládá ze záznamů, lze problému předejít voláním sync() HDFS každé tak často nepřetržitě zapisovat velké soubory. Případně je možné napsat program, který malé soubory spojí dohromady.
V druhém případě je potřeba nějaký druh kontejneru pro seskupení souborů nějakým způsobem. Hadoop zde nabízí několik možností.
Soubory HAR
Hadoop Archives (soubory HAR) byly zavedeny do HDFS ve verzi 0.18.0, aby zmírnily problém spousty souborů, které vyvíjejí tlak na paměť jmenného uzlu. Soubory HAR fungují tak, že se nad HDFS vytvoří vrstvený souborový systém. Soubor HAR je vytvořen pomocí archivu hadoop příkaz, který spustí úlohu MapReduce pro zabalení archivovaných souborů do malého počtu souborů HDFS. Pro klienta používajícího souborový systém HAR se nic nezměnilo:všechny původní soubory jsou viditelné a přístupné (i když pomocí har:// URL). Počet souborů v HDFS se však snížil.
Čtení souborů v HAR není o nic efektivnější než čtení souborů v HDFS a ve skutečnosti může být pomalejší, protože každý přístup k souboru HAR vyžaduje dvě čtení indexového souboru a také čtení datového souboru (viz diagram). A přestože soubory HAR lze použít jako vstup do MapReduce, neexistuje žádná speciální magie, která by mapám umožnila pracovat nad všemi soubory v korezidentu HAR v bloku HDFS. Mělo by být možné sestavit vstupní formát, který dokáže využít vylepšenou lokalitu souborů v HAR, ale zatím neexistuje. Všimněte si, že MultiFileInputSplit, dokonce i s vylepšeními v HADOOP-4565 pro výběr souborů v rozdělení, které jsou lokální uzel, bude vyžadovat hledání na malý soubor. Bylo by zajímavé vidět výkon tohoto ve srovnání se SequenceFile, řekněme. V současné době se HAR pravděpodobně nejlépe používají čistě pro archivní účely.
Sekvenční soubory
Obvyklá odpověď na otázky týkající se „problému s malými soubory“ je:použijte SequenceFile. Myšlenka je taková, že jako klíč použijete název souboru a jako hodnotu obsah souboru. V praxi to funguje velmi dobře. Vrátíme-li se zpět k 10 000 souborům o velikosti 100 kB, můžete napsat program, který je vloží do jednoho souboru SequenceFile, a poté je můžete zpracovat způsobem streamování (přímo nebo pomocí MapReduce) pomocí SequenceFile. Je tam i pár bonusů. SequenceFiles lze rozdělit, takže je MapReduce může rozdělit na bloky a pracovat s každým blokem nezávisle. Na rozdíl od HAR podporují také kompresi. Bloková komprese je ve většině případů nejlepší volbou, protože komprimuje bloky několika záznamů (spíše než jeden záznam).
Převod existujících dat na SequenceFiles může být pomalý. Je však dokonale možné vytvořit kolekci SequenceFiles paralelně. (Stuart Sierra napsal velmi užitečný příspěvek o převodu souboru tar na SequenceFile – nástroje jako tento jsou velmi užitečné a bylo by dobré vidět jich více). Do budoucna je nejlepší navrhnout svůj datový kanál tak, aby zapisoval data u zdroje přímo do SequenceFile, pokud je to možné, spíše než zapisovat do malých souborů jako mezikrok.
Na rozdíl od souborů HAR neexistuje způsob, jak vypsat všechny klíče v SequenceFile, kromě čtení celého souboru. (MapFiles, které jsou jako SequenceFiles se seřazenými klíči, udržují částečný index, takže ani nemohou vypsat všechny své klíče – viz diagram.)
SequenceFile je spíše zaměřen na Java. TFile je navržen jako multiplatformní a může být náhradou za SequenceFile, ale zatím není k dispozici.
HBase
Pokud vytváříte velké množství malých souborů, může být v závislosti na vzoru přístupu vhodnější jiný typ úložiště. HBase ukládá data do MapFiles (indexované SequenceFiles) a je dobrou volbou, pokud potřebujete provádět analýzy streamování ve stylu MapReduce s občasným náhodným vyhledáváním. Pokud je latence problémem, pak existuje spousta dalších možností – viz vynikající průzkum obchodů s páry klíč-hodnota Richarda Jonese.