Recenze Apache Nutch: čtyři hranice, které rozhodují, zda poběží a co najde

Apache Nutch je crawler nadace Apache Software Foundation, jehož vývoj začal v roce 2004. Jde o systém pro JVM postavený na Hadoopu, navržený jako opakující se cyklus, nikoli jako jeden průběžný příkaz: počáteční URL se nejprve injectnou do perzistentní databáze, poté následují kola generate → fetch → parse → updatedb. K dispozici jsou pluginy pro protokol, parser, filtrování URL i scoring. Obvyklým výstupem je spíš index pro Solr nebo Elasticsearch než CSV.

Spustil jsem Nutch 1.22 proti kontrolovanému lokálnímu testovacímu webu — takovému, který na straně serveru loguje každý požadavek, takže výsledky posuzuji podle toho, co server skutečně viděl, a ne podle toho, co tvrdil crawler. Průběh určovaly čtyři hranice: verze JDK, http.agent.name, rozsah crawlu a to, zda je v plugin.includes přítomný parse-js. Celý cyklus jsem opakovaně spouštěl s testovanou konfigurací; změňte JDK nebo nechte identitu agenta prázdnou a skončí to ještě před stažením užitečných stránek.

Hranice JDK se projeví dřív, než crawl vůbec začne. Nutch 1.22 zde na JDK 26.0.1 nespustil: první Hadoop job spadl uvnitř Subject.getSubject(), protože Java odstranila cestu přes SecurityManager. Nutch přibaluje Hadoop 3.4.2, zatímco oprava dorazila do Hadoopu 3.4.3 sedm dní po vydání Nutch 1.22. Samostatně pak parse-js změnil záchyt dvou JavaScriptových literálů ze 0/2 na 2/2, aniž by se musel spouštět prohlížeč.

K čemu Nutch je a k čemu není

Nutch není scraper. Jeho úlohou není strukturovaná extrakce polí: ve velkém objevuje a stahuje URL, udržuje perzistentní databázi těchto adres a jejich stavů (crawldb) a vrací segmenty, které pak jiný nástroj přetvoří na index. Když ho nasměrujete na katalog a čekáte tabulku jmen a cen, dostanete místo toho crawldb.

Právě tahle architektura vysvětluje většinu toho, co následuje. Nutch vznikl přibližně o dvě desetiletí dřív než éra jednoho binárního crawleru a je stavěný na problém, pro který vznikl Hadoop: procházet víc stránek, než se vejde do jednoho stroje. Spustit ho na notebooku proti fixture o 12 stránkách je jako najmout si nákladní vlak na stěhování jedné knihovny — je to poučné pro ten vlak, ale nespravedlivé čekat ergonomii kola.

Aktuální vydání je 1.22, ohlášené 17. února 2026. Projekt je pod licencí Apache-2.0, repo mělo při kontrole 27. července 2026 3 272 hvězdiček a 8 otevřených issues a větev master byla aktualizována čtyři dny předtím. Jde o udržovaný projekt, ne o opuštěný — a to je správný rámec pro problém s JDK: okno pro balíčkování, které se zavřelo o týden dřív, ne zanedbání.

Matice verzí: JDK 24+, Hadoop 3.4.2 a dvouřádková oprava

Blokátor je souhra tří verzí a jediná část, kterou máte pod kontrolou, je to, na jakém JDK Nutch poběží. Úplně první Hadoop job na výchozím JDK hostitele spadl při inicializaci:

java.lang.UnsupportedOperationException: getSubject is not supported
    at java.base/javax.security.auth.Subject.getSubject(Subject.java:277)
    at org.apache.hadoop.security.UserGroupInformation.getCurrentUser(UserGroupInformation.java:588)
    at org.apache.nutch.crawl.Injector.inject(Injector.java:473)

Návratový kód 255. Nula stažených stránek. bin/nutch inject se vůbec nedostane na síť — inicializuje Hadoop LocalJobRunner, ten se ptá, kdo je aktuální uživatel, to zavolá Subject.getSubject(), a právě to JEP 486 změnil na nepodmíněnou výjimku ve chvíli, kdy JDK 24 natrvalo odstranilo SecurityManager. Můj hostitelský JDK byl OpenJDK 26.0.1, tedy hluboko za touto hranicí.

Nezabírá ani tradiční úniková cesta. Přidání -Djava.security.manager=allow, což býval přepínač pro znovupovolení starého chování, odmítne VM ještě před načtením kódu Nutch:

Error occurred during initialization of VM
java.lang.Error: A command line option has attempted to allow or enable the Security
Manager. Enabling a Security Manager is not supported.

To je návratový kód 1 a záměrná slepá ulička — tento přepínač zmizel spolu s funkcí.

Kořen problému je ve verzi Hadoopu, kterou Nutch 1.22 přibaluje. Problém getSubject je sledovaný jako HADOOP-19212 a opravený v Hadoop 3.4.3 a 3.5.0; Nutch 1.22 přibaluje hadoop-common-3.4.2. Nutch 1.22 vyšel 17. února 2026 a Hadoop 3.4.3 následoval asi o týden později.

Není to ani problém závislosti na Solru nebo Hadoop clusteru. Často se předpokládá, že Nutch potřebuje Hadoop cluster a běžící Solr, aby vůbec něco udělal. Nepotřebuje. Lokální režim používá Hadoop LocalJobRunner běžící v procesu — žádný démon HDFS, žádný YARN, žádný cluster. Celý cyklus inject → generate → fetch → parse → updatedb běží na jednom stroji a nic dalšího není třeba instalovat. Zeď JDK je čistě problém verze přibalené knihovny a zastaví vás dřív, než se k infrastrukturní otázce vůbec dostanete.

Praktická verze matici, všechny tři řádky změřené:

Oprava jsou dva příkazy. Nainstalujte LTS JDK a nasměrujte na něj Nutch:

brew install openjdk@17
export NUTCH_JAVA_HOME=/opt/homebrew/opt/openjdk@17

Jde o keg-only instalaci, takže se tím nesahá na systémové výchozí JDK. Vlastní CI projektu míří na Java 17 a projekt veřejně oznámil, že verze 1.22 je poslední, která poběží na Java 11, a že 1.23 bude Java 17 vyžadovat. LTS JDK tedy není obezlička — je to podporovaná konfigurace. Nesoulad je mezi tím, co Nutch podporuje, a tím, co vám v roce 2026 dá brew install openjdk, a to jsou dvě různé otázky, které se jen náhodou střetnou hned u prvního příkazu.

Vše odtud dál běželo na OpenJDK 17.0.20, kde je celý cyklus čistý.

Nastavení v číslech: 396 MB a jedna vlastnost, která blokuje všechno

„Těžký“ je přídavné jméno, které se používá pořád, ale bez měřítka je k ničemu. Takhle vypadá rozbalená binární distribuce Nutch 1.22:

Pro srovnání: moderní Go crawler jako katana se dodává jako jeden binární soubor o velikosti zhruba 50 MB, bez JVM a bez externích jarů.

A pak je tu brána, na kterou vás nikdo neupozorní. Dodávaný nutch-site.xml je prázdný a http.agent.name má výchozí hodnotu prázdného řetězce. Když jsem ho nenechal nastavený, první crawl stáhl nula cest a v logu se objevilo:

ERROR Fetcher: No agents listed in 'http.agent.name' property.

Stačilo nastavit právě tuhle jednu vlastnost — nic dalšího — a fetch začal fungovat. Když byla vlastnost prázdná, příkaz doběhl bez stažení stránek a log hlásil výše uvedenou chybu s agentem; nebyl tichý.

Minimum použitelné konfigurace se ukázalo být trojicí artefaktů: conf/nutch-site.xml (jméno agenta, sada pluginů, scope), conf/regex-urlfilter.txt (omezení na hostitele) a soubor se seed URL. To není špatné číslo. Jen je to o tři soubory víc než crawler run <url>.

Co našel: přepínač pluginu, na kterém záleží

Testovací web měl tři záměrně odlišné typy endpointů a chování Nutch se mezi nimi čistě rozdělilo:

• Třída A — běžné HTML odkazy (4 stránky plus řetězec dlouhý 3 odkazy)
• Třída B — endpointy, které existují jen jako string literály uvnitř propojeného JavaScriptového souboru: jeden jako argument volání, fetch('/api/js-endpoint-7'), druhý jako přiřazení, const other = "/api/js-endpoint-8"
• Třída C — endpoint, který existuje až po spuštění JavaScriptu, který ho vloží do DOM

Výsledky ze serverových hit logů, zopakované třikrát:

Ve všech třech opakováních naprosto shodné. Deterministické.

Zvýšení třídy B je ta část, která se obvykle podceňuje. Nutch našel oba JavaScriptem vložené endpointy bez spuštění prohlížeče, a to pomocí regexového skenu JavaScriptového obsahu v pluginu parse-js. Soubor app.js byl v obou konfiguracích stažen stejně — Nutch bere <script src> jako odkaz bez ohledu na obsah — rozdíl je tedy čistě v tom, zda něco čte obsah souboru a hledá řetězce připomínající URL. Když plugin zapnete, zachytí oba typy literálů.

Na této fixtuře dosáhl výchozí Nutch i standardní režim katany stejné sady třídy A, zatímco Nutch s parse-js a katana s -jc dosáhly tříd A a B bez prohlížeče. Verze katany a celý příkaz ale v tomto článku nejsou zachyceny, takže jde spíš o kontext než o striktní produktový benchmark.

Třída C je poctivý strop. Žádná statická konfigurace se k ní nedostala, což je očekávatelné: získat endpoint, který existuje až po spuštění skriptu, znamená ten skript opravdu spustit. Zkusil jsem i výměnu protocol-http za protocol-htmlunit, tedy čistě Java protokol Nutch, který vykonává JavaScript. Běžel a neshodil se, ale ve stejném čtyřkolovém harnessu dokončil jen jedno kolo, stáhl pouze seed stránku a app.js, třídy A/B/C nezasáhl ani jednu a ve druhém kole hlásil 0 records selected for fetching. To je spíš podkonfigurovaný pokus než verdikt o schopnostech HtmlUnit. Co z toho plyne je užší závěr: výměna za JS-exekuující protokol není drop-in změna, a třída C zůstala nedosažená ve všech konfiguracích, které jsem testoval.

Řízení crawlu a chování při chybách

Hloubka není přepínač. V Nutch neexistuje --depth 3; hloubka je prostě tolik kol generate → fetch → parse → updatedb, kolik jich spustíte, protože kolo R stahuje frontu objevenou v kole R-1. Můj depth chain to potvrdil přesně:

Čisté a mechanické, ale znamená to, že hloubka je počet iterací ve vašem skriptu, ne parametr.

A teď past. Výchozí hodnota dodávaná s Nutch je db.ignore.external.links=false a je spárovaná s benevolentním URL filtrem +. — což znamená, že výchozí crawl Nutch bude následovat odkazy mimo seed hostitele. Nasadil jsem stránku s jedním odkazem v rámci scope a jedním odkazem na jiný hostname a crawl ten cizí host skutečně stáhl. Dva nezávislé signály se shodly: vlastní crawldb Nutch ho označil jako db_fetched a serverový čítač druhého hostitele zaznamenal hit.

Zůstat v rámci scope je potřeba zapnout výslovně a obě nápravy fungují ověřitelně:

Když crawlíte jeden web, nastavte to před prvním ostrým během. Jedna metodická poznámka: tento test je citlivý na zátěž lokálního serveru, takže tyto tři řádky pocházejí z běhu, kdy na fixture nesahal nic jiného. Chování samo je mechanicky jasné a podložené dvěma nezávislými signály; konkrétní hodnoty v tabulce jsou jeden čistý běh, ne průměr z mnoha.

Sitemap je samostatný krok. Ohleduplnost zapnutá je — normální crawl stáhl /robots.txt — ale samotná sitemap potřebuje vlastní příkaz:

Je to jiný model než crawleri, kteří známé soubory stahují inline, a stojí vás to jeden extra příkaz, ale práci to udělá úplně.

Dvě menší vlastnosti obstály dobře.

Zpracování chyb: crawl nad stránkou odkazující na 500 a 404 doběhl všechna kola čistě, stále stáhl všechny čtyři stránky třídy A a každou chybu zaznamenal zvlášť:

Nic se nerozsypalo.

Ohleduplnost: při jednom vlákně na frontu odpovídal rozestup mezi fetchi ze stejného hostitele nastavení:

Ovladač dělá přesně to, co říká. Výchozí dodaná hodnota je 5,0 sekundy, což je konzervativní a zase nejspíš správné pro nástroj navržený tak, aby byl slušný k cizím serverům.

Batch daň v sekundách

Každý příkaz Nutch je nový JVM. Tenhle jediný fakt dominuje časovému profilu mnohem víc než cokoliv kolem samotného fetchování.

Efektivní minimální čas na job — start JVM plus inicializace Hadoopu, měřeno jako nejlevnější fáze s triviální prací — je zhruba 1,77 sekundy. Vynásobte to čtyřmi příkazy na kolo a přidejte úvodní inject, a obrázek celého crawlu vypadá takto:

Ten rozdíl není o propustnosti fetchování; oba nástroje si vyžádají stejných pár stránek. Je to architektura. Nutch platí fixní procesní náklad za každou fázi, protože ty fáze jsou navržené jako MapReduce joby. Na malém lokálním crawlu dominují náklady na přípravu. Ten fixní náklad by měl být u delší úlohy menší částí celku, ale tento test neměřil, při jakém měřítku se Nutch a katana vyrovnají, ani zda se jejich poměr obrátí.

Pro a proti

Pro

• Deterministické statické objevení: třída HTML 4/4, depth chain 3/3, shoda ve všech třech opakovaných bězích.
• parse-js bez prohlížeče obnovuje endpointy z JavaScriptových literálů (2/2), a to jak z argumentů volání, tak z přiřazení.
• Dvě ověřené kontroly scope, které crawl plně omezí (db.ignore.external.links a hostitel v regex-urlfilter).
• Ingest sitemap přes bin/nutch sitemap dosáhl plného 2/2 záchytu endpointů, které normální crawl úplně minul.
• Odolnost vůči chybám: 500 i 404 jsou zpracované oddělenými stavy v crawldb a crawl pokračuje.
• V tomto lokálním běhu odpovídal pozorovaný interval na stejném hostiteli nastavené prodlevě 1,0 s; výchozí dodaná hodnota je 5,0 s.
• Apache-2.0, aktivně udržovaný, 78 pluginů a perzistentní crawldb, který drží stav jednotlivých URL napříč koly.
• Poběží v lokálním režimu bez clusteru, bez HDFS a bez nutnosti Solru.

Proti

• Nepoběží na JDK 24 a novějším, kde dopadá odstranění SecurityManageru (selhání jsem změřil na 26.0.1) — přibalený Hadoop 3.4.2 předchází upstream opravě a únikový přepínač už neexistuje, takže pin na LTS JDK je tvrdý předpoklad, ne preference.
• ≈396 MB po rozbalení, 188 library jarů, 78 pluginových adresářů, 35 konfiguračních souborů.
• Nový JVM pro každý příkaz znamená ~1,77 s fixního režijního času na fázi; ~45 s pro crawl do hloubky 4 na 12 stránkách oproti ~13 s u jednoho binárního crawleru na stejných datech.
• Výchozí nastavení sleduje odkazy na externí hosty; zůstat na jednom webu je potřeba výslovně zapnout.
• http.agent.name je dodaný prázdný a fetcher odmítne běžet, dokud ho nenastavíte.
• Žádný přepínač hloubky — hloubka je počet iterací, který si musíte řídit sami.
• Endpointy vznikající až za běhu DOM byly v každé testované konfiguraci nedosažitelné a výměna za JS-exekuující protokol nebyla drop-in změna.
• Testoval jsem lokální režim na jednom hostu s malou fixturou. Distribuovaný/HDFS režim, indexace do Solru, hostdb, resume a plánování inkrementálního recrawlu byly mimo tento test — berte je zde jako netestované, ne jako doporučené.

Pro koho je a kdo by měl jít dál

Nutch dává smysl tehdy, když je nejtěžší částí samotný crawl. Pokud stavíte vyhledávací index, provozujete rozsáhlý crawl napříč více doménami, potřebujete perzistentní URL databázi se stavem jednotlivých adres a retry semantikou, nebo očekáváte, že práci časem rozložíte na více strojů, je to infrastruktura, která tuto konkrétní práci dělá už od doby, kdy většina alternativ ještě neexistovala. Pluginový systém vám umožní měnit chování protokolu, parseru, filtru i scoringu bez forků. Výchozí nastavení ohleduplnosti je navíc tak konzervativní, že je vidět, že autoři přemýšleli nad tím, jak se chovat slušně.

Jděte dál, pokud chcete z pár stránek dostat strukturovaná data. Nutch je stáhne a naparsuje, pak vám předá crawldb a segmenty a čeká, že si přinesete indexer. Jděte dál, pokud jsou vaše cíle single-page aplikace renderované klientem — třída C zůstala nedosažená ve všem, co jsem spustil. Jděte dál, pokud váš tým JVM nepoužívá, protože byste do stacku přidávali Java toolchain, pin na LTS JDK a 396 MB jarů. A pokud je pracovní zátěž „jednou týdně projít jeden web do hloubky čtyři“, strávíte víc času kolem iterací a konfiguračních souborů, než si samotný crawl zaslouží.

Pro většinu lidí, kteří vybírají scraper, je právě to poslední reálný případ. Což není kritika Nutch — je to neshoda mezi nástrojem a úkolem. Pokud chcete širší přehled trhu, náš přehled open-source scraperů a nejlepších GitHub projektů pro web scraping pokrývají lehčí část spektra podrobněji.

Alternativy, včetně toho, kam zapadá náš vlastní stack

Nejdřív férové rámování: Nutch je zdarma, pod Apache licencí, self-hosted a můžete ho provozovat donekonečna bez nákladů za jednotlivý request. To je skutečná výhoda a nic z následujícího ji nemaže.

Související recenze: Recenze Browsertrix Crawler.

V open-source světě záleží srovnání na tom, co optimalizujete. Pokud chcete Python framework s řízením crawlu a filozofií request-first, Scrapy je pro mnoho projektů bližší analogie; tento článek ale na stejné bázi neměřil velikost jeho instalace. Pokud chcete kompaktní Go crawler bez prohlížeče, Colly je další podoba, kterou stojí za to zvážit. Pokud je váš problém spíš převod stránek na obsah připravený pro LLM než objevování URL, Crawl4AI míří do jiné vrstvy.

Spravovaná služba jako Thunderbit přesouvá fetchování, renderování a extrakci za API, zatímco Nutch nechává crawl state a infrastrukturu pod vaší kontrolou. Thunderbit jsem na této fixtuře nespouštěl, takže jde o srovnání modelu vlastnictví, ne o tvrzení o stejné přesnosti záchytu nebo výkonu na dynamických stránkách.

Obchod je mezi vlastnictvím a režijním nákladem a není to subtilní rozdíl. Nutch vám dává plnou kontrolu, perzistentní crawldb, clusterovou škálovatelnost už v návrhu a nulové marginální náklady — výměnou za JVM, pin na LTS JDK, 396 MB jarů, cyklus po kolech a vlastní vrstvu indexace. Spravované API vám dá strukturovaný výstup na první volání a žádnou infrastrukturu — výměnou za cenu za volání a menší kontrolu nad frontier crawlu. Pokud je vaším úkolem „indexovat 50 milionů stránek“, model Nutch je správný a API by bylo absurdní. Pokud je úkolem „dostat strukturované záznamy z 200 produktových stránek do čtvrtka“, platí opak.

Vyzkoušejte Thunderbit pro extrakci webových dat

Verdikt

Apache Nutch stojí za zvážení, pokud provozujete průběžný crawl napříč více doménami a už máte JVM infrastrukturu. Na této fixtuře bylo statické objevování deterministické napříč opakováními, parse-js našel oba JavaScriptové endpointy jako literály, chyby zůstaly reprezentované v crawldb a pozorované rozestupy požadavků odpovídaly nastavené prodlevě.

Vstupní náklady si spočítejte realisticky. Nutch 1.22 zde selhal na JDK 26.0.1; OpenJDK 17.0.20 je LTS konfigurace, kterou jsem v této recenzi skutečně ověřil, zatímco Java 21 testována nebyla. Pak nastavte http.agent.name, rozhodněte scope výslovně a počítejte s pozorovanou fixní spodní hranicí zhruba 1,77 sekundy na fázi při tomto malém lokálním běhu. Jestli ten trade-off dává smysl, záleží na délce, šíři a potřebě perzistentního stavu vašeho crawlu.

Vyzkoušejte Thunderbit pro extrakci webových dat Get Started Free

Časté otázky

Proč Apache Nutch selže s chybou "getSubject is not supported"? Na JDK 24 a novějším JEP 486 způsobil, že Subject.getSubject() hází výjimku bez podmínky, zatímco přibalený Hadoop 3.4.2 ho stále volal. První Hadoop job tedy spadne dřív, než se stáhne jediná stránka, a starý únikový přepínač -Djava.security.manager=allow už VM nespustí. Použijte ověřenou konfiguraci s Java 17 a nastavte NUTCH_JAVA_HOME; Java 21 může být podporovaná, ale tato recenze na ní celý cyklus nespustila.

Na jaké verzi Java bych měl Nutch 1.22 provozovat? Java 17 je nejbezpečnější odpověď — vlastní CI Nutch na ni míří a v mém testování na OpenJDK 17.0.20 fungovala bez problémů. Java 11 je pro 1.22 také stále podporovaná, ačkoliv projekt oznámil, že 1.23 bude vyžadovat Java 17. Cokoliv od JDK 24 výš nepoběží. Keg-only instalace z Homebrew (brew install openjdk@17) spolu s NUTCH_JAVA_HOME ponechá systémové výchozí JDK beze změny.

Umí Nutch procházet weby s JavaScriptem? Částečně, a ten rozdíl je důležitý. Když je zapnutý plugin parse-js, Nutch našel oba endpointy, které existovaly jen jako string literály v propojeném JavaScriptovém souboru — 2/2, bez prohlížeče. S výchozí sadou pluginů nenašel ani jeden. Endpoint, který se objevil až po vykonání JavaScriptu a úpravě DOM, ale v každé statické konfiguraci, kterou jsem testoval, zůstal nedosažený, a výměna za HtmlUnit protokol nebyla v mém běhu drop-in změna. Pro klientsky renderované aplikace počítejte s protokolem, který JavaScript skutečně vykonává, s reálnou konfigurační prací, nebo s jiným nástrojem.

Potřebuje Nutch nainstalovaný Hadoop a Solr? Ne. Lokální režim používá Hadoop LocalJobRunner běžící v procesu — žádný cluster, žádný démon HDFS, žádný YARN — a celý cyklus inject → generate → fetch → parse → updatedb funguje na jednom stroji bez další instalace. Solr je obvyklý cíl pro indexaci, ale samotný crawl ho nevyžaduje. Je ale pravda, že Hadoop jary jsou přibalené (13 kusů, verze 3.4.2), a právě proto ten problém s kompatibilitou JDK vůbec vzniká.

Jak zabráním tomu, aby Nutch crawloval jiné weby? Nastavte to explicitně, protože výchozí hodnota to neudělá. Nutch 1.22 přichází s db.ignore.external.links=false a benevolentním URL filtrem; v mém testu výchozí crawl následoval odkaz na jiný host a skutečně ho stáhl. Buď nastavte db.ignore.external.links=true v nutch-site.xml, nebo přidejte pravidlo hostitele do conf/regex-urlfilter.txt (například +^https://example\.com/ a za něj -.). Obě varianty crawl plně omezily, což jsem ověřil z vlastního crawldb Nutch i z logu požadavků na druhém serveru.