Na rozdíl od jakéhokoli I/O subsystému přichází Hadoop také se sadou primitiv. Tyto primitivní úvahy, i když jsou obecné povahy, jdou se systémem Hadoop IO a samozřejmě také s určitým zvláštním významem. Hadoop se zabývá mnoha terabajty datových sad; zvláštní pozornost k těmto primitivům poskytne představu, jak Hadoop zpracovává vstup a výstup dat. Tento článek rychle přelétne tato primitiva, aby poskytl perspektivu vstupního výstupního systému Hadoop.
Integrita dat
Integrita dat znamená, že data by měla zůstat přesná a konzistentní ve všech operacích ukládání, zpracování a získávání. Aby bylo zajištěno, že během přetrvávání a zpracování nedojde ke ztrátě nebo poškození dat, zachovává Hadoop přísná omezení integrity dat. Každá operace čtení/zápisu se odehrává na discích, tím spíše je přes síť náchylná k chybám. A objem dat, se kterými Hadoop zpracovává, situaci jen zhoršuje. Obvyklým způsobem, jak zjistit poškozená data, jsou kontrolní součty. kontrolní součet je vypočítána, když data poprvé vstoupí do systému a jsou odeslána přes kanál během procesu vyhledávání. Načítající konec znovu vypočítá kontrolní součet a shoduje se s přijatými. Pokud se přesně shodují, pak se data považují za bezchybná, jinak obsahují chybu. Problém ale je – co když je samotný zaslaný kontrolní součet poškozen? To je vysoce nepravděpodobné, protože jde o malá data, ale ne o nepopiratelnou možnost. Ke zmírnění situace lze použít správný druh hardwaru, jako je paměť ECC.
Toto je pouhá detekce. K nápravě chyby se proto používá jiná technika, nazývaná CRC (Cyclic Redundancy Check).
Hadoop to jde dále a vytváří zřetelný kontrolní součet pro každých 512 (výchozích) bajtů dat. Protože CRC-32 má pouze 4 bajty, režie úložiště nepředstavuje problém. Všechna data, která vstupují do systému, jsou před odesláním k uložení nebo dalšímu zpracování ověřena datovými uzly. Data odesílaná do kanálu datových uzlů jsou ověřena pomocí kontrolních součtů a jakékoli zjištěné poškození je okamžitě oznámeno klientovi pomocí ChecksumException . Klient čtený z datanodu také prochází stejným cvičením. Datové uzly uchovávají protokol ověření kontrolního součtu, aby sledovaly ověřený blok. Protokol aktualizuje datový uzel po obdržení signálu úspěšného ověření bloku od klienta. Tento typ statistik pomáhá udržet špatné disky na uzdě.
Kromě toho se provádí pravidelné ověřování úložiště bloků pomocí DataBlockScanner běžící spolu s vláknem datanode na pozadí. To chrání data před poškozením na fyzickém úložném médiu.
Hadoop udržuje kopie nebo repliky dat. To se konkrétně používá k obnově dat z masivního poškození. Jakmile klient zjistí chybu při čtení bloku, okamžitě oznámí datovému uzlu chybný blok z jmenného uzlu a poté vyvolá ChecksumException . Namenode jej pak označí jako špatný blok a naplánuje další odkaz na blok na jeho repliky. Tímto způsobem je replika udržována s jinými replikami a označený špatný blok je odstraněn ze systému.
Pro každý soubor vytvořený v LocalFileSystem Hadoop , skrytý soubor se stejným názvem ve stejném adresáři s příponou .
Komprese
S ohledem na objem dat, se kterými se Hadoop zabývá, není komprese luxus, ale požadavek. Existuje mnoho zjevných výhod komprese souborů, které Hadoop správně používá. Šetří požadavky na úložiště a je nezbytnou schopností urychlit přenos dat po síti a na discích. Hadoop běžně používá mnoho nástrojů, technik a algoritmů. Mnohé z nich jsou velmi populární a byly v průběhu věků používány při kompresi souborů. Často se používají například gzip, bzip2, LZO, zip a tak dále.
Serializace
Proces, který mění strukturované objekty na proud bajtů, se nazývá serializace . To je zvláště vyžadováno pro přenos dat po síti nebo uchovávání nezpracovaných dat na discích. Deserializace je pouze obrácený proces, kdy se proud bajtů přemění na strukturovaný objekt. To je vyžadováno zejména pro objektovou implementaci nezpracovaných bajtů. Není proto divu, že distribuované výpočty toto využívají v několika odlišných oblastech:meziprocesová komunikace a perzistence dat.
Hadoop používá RPC (Remote Procedure Call) k zajištění meziprocesové komunikace mezi uzly. Proto protokol RPC používá proces serializace a deserializace k vykreslení zprávy do proudu bajtů a naopak a k jejímu odeslání přes síť. Proces však musí být dostatečně kompaktní, aby co nejlépe využíval šířku pásma sítě, a také rychlý, interoperabilní a flexibilní, aby se přizpůsobil aktualizacím protokolu v průběhu času.
Hadoop má svůj vlastní kompaktní a rychlý serializační formát Writables , které programy MapReduce používají ke generování klíčů a typů hodnot.
Datová struktura souborů
Existuje několik kontejnerů na vysoké úrovni, které rozvíjejí specializovanou datovou strukturu v Hadoopu pro uložení speciálních typů dat. Chcete-li například udržovat binární protokol, SequenceFile kontejner poskytuje datovou strukturu pro zachování binárních párů klíč-hodnota. Poté můžeme použít klíč, jako je časové razítko reprezentované LongWritable a hodnotu podle Writable , což odkazuje na zaznamenané množství.
Existuje další kontejner, seřazená derivace SequenceFile s názvem MapFile . Poskytuje index pro pohodlné vyhledávání podle klíče.
Tyto dva kontejnery jsou interoperabilní a lze je navzájem převádět.
Závěr
Toto je jen rychlý přehled vstupního/výstupního systému Hadoop. V dalších článcích se ponoříme do mnoha složitých detailů. Není těžké porozumět vstupnímu/výstupnímu systému Hadoop, pokud má člověk základní znalosti I/O systémů obecně. Hadoop tomu prostě dodal trochu extra šťávy, aby držel krok s jeho distribuovanou povahou, která funguje v masivním měřítku dat. To je vše.
Odkaz
Bílá, Tome. Hadoop, The Definitive Guide, 2009 . Publikace O’Reilly.