Back to top

Aspider kommt – Ein suchmaschinenunabhängiger Webcrawler für eine bessere unternehmensweite Suche

content processing_0.jpgStellen Sie sich einmal vor, in einer Enzyklopädie mit mehreren Milliarden Einträgen nach einer speziellen Information zu suchen.

So würde das Internet aussehen, wenn es keine Webcrawler gäbe. Eigentlich verdankt das Internet seinen Erfolg und sein Wachstum sogar dieser entscheidenden Technologie – zumindest teilweise. Ähnlich wie bei Hochhäusern, die ihre heutige Höhe auch erst durch die Erfindung der Stahlträgerkonstruktion erreichen konnten.
Der Webcrawler übernimmt im Internet die Aufgabe, Millionen Webseiten sicher und so schnell wie möglich zu erfassen und damit einen Index für die Suchmaschine zu erstellen. Um die Sicherheit zu gewährleisten dürfen nicht zu viele Anfragen gleichzeitig an einen bestimmten Internet-Server (oder Host) gestellt werden. Aber wie kann man Millionen Webseiten durchsuchen, wenn man einen Server nur alle paar Sekunden anfragen darf? Die Antwort ist einfach: Sie verarbeiten mehrere Abfragen auf verschiedenen Hosts gleichzeitig.

Im Intranet stellt sich den Crawlern jedoch ein ganz anderes Szenario als im Internet. Hier gibt es nur wenige Sites, die durchsucht werden müssen; nur wenige Hosts sind involviert. Wenn man eine Intranet-Site mit einem Webcrawler betreibt, der für Crawling in großem Maßstab (Tausende oder Millionen Hosts) entwickelt wurde, wird dieser in seiner Standardkonfiguration wahrscheinlich zu langsam erscheinen. 

Beispielanwendungen für Webcrawler

Wir bei Search Technologies haben ähnliches mit dem Heritrix Webcrawler in unserem Aspire Content Processing Framework – einem leistungsfähigen Framework für unstrukturierte Daten, das unabhängig von konkreten Suchmaschinen arbeitet – selbst erlebt. Wir haben sogar versucht, die „Höflichkeits-Richtlinien“ zu modifizieren, die Erfolge waren aber vernachlässigbar. Dann haben wir versucht, den Quellcode von Heritrix zu modifizieren, um die Leistung zu steigern. Als Nebeneffekt trat dabei aber eine potenzielle Instabilität des Crawlers, bedingt durch dessen inkonsistente Architektur, auf.

Ein weiteres Problem war das Thema Sicherheit, da Heritrix nur Basic und Digest (HTTP-Authentifizierung) sowie Cookie-basierende Authentifizierung (Authentifizierung durch Umleitung auf eine Anmeldeseite) unterstützt. Einige unserer Kunden nutzen jedoch Sites mit NTLM/Kerberos Authentifizierung. Das Modifizieren des Heritrix-Quellcodes war riskant, weil NTLM als proprietäres Protokoll nicht im offiziellen Projekt enthalten ist. Daher mussten wir eine eigene Version des Crawlers bereitstellen.

Aspider: Die Webcrawling Problemlösung

Beim Crawling von Intranet-Sites können folgende Vorteile ausgenutzt werden:

  1. Crawling kann auf Zeiten mit geringer Last gelegt werden (wie z.B. zwischen 19 Uhr und 5 Uhr morgens).
  2. Der Server für den Webcrawler kann sich in der Nähe des Host-Servers befinden, idealereise im selben Datenzentrum. Dadurch kann mehr als eine Seite pro Sekunde angefragt werden.

Durch diese Vorgaben zeigte sich, dass wir eine neue Methode brauchen, um Webcrawling entsprechend den Anforderungen unserer Kunden vorzunehmen. Und damit war es geschehen: Unser eigenes Webcrawler-Projekt mit Namen Aspider (für Aspire Webcrawler) war geboren. 

Das Ziel für unseren Aspider Webcrawler war: 

  • Verbesserte Leistung im Crawling über wenige Hosts (Intranet-Sites)
  • Erhalten der Heritrix-Funktion zur Extrahierung weiterführender Links
  • Nutzung des Aspire 3.x Konnektoren-Frameworks, einschließlich integrierter verteilter Verarbeitung, integrierter inkrementeller Snapshots, Ausfallsicherung und flexibler Steuerung des Crawlings (zum Pausieren und Wiederaufnehmen von Crawlingvorgängen zwischen System-Neustarts)
  • Unterstützung der standardmäßigen Heritrix-Authentifizierung (Basic, Digest und Cookie-basierend). Zusätzliche nahtlose Integration von NTLM/Kerberos.

Hierdurch können wir unseren Kunden bessere technische Unterstützung bieten, wenn ein Crawlingvorgang fehlschlägt, da wir nicht mit Code von Drittanbietern arbeiten müssen, um das Crawling zu steuern.

Wie haben wir diese Ziele erreicht?

Ziel 1: Bessere Leistung

Wir haben unser Konnektoren-Framework Aspire 3.x eingesetzt, um die Leistung im Crawling spürbar zu steigern (lesen Sie mehr über unser neustes Aspire 3.1 Release), wenn auch anfänglich auf Kosten von Sicherheit (zu viele Abfragen in kurzer Zeit) und Konfigurierbarkeit. Um die Zuverlässigkeit zu steigern haben wir daher einen hochgradig konfigurierbaren Throttle-Controller hinzugefügt, der die Geschwindigkeit des Crawlings nach Bedarf anpassen kann.

Throttle Control ist eine Technologie, welche den Datendurchsatz der Anfragen des Crawlers steuert, damit die Webserver (und System-Administratoren) nicht überlastet werden. Um einen vollständig verteilten Throttle Controller zu realisieren werden Anfragen an denselben Host nur von einem einzigen Aspire-Knoten gestellt. Dieser wird freigegeben, sobald die maximal erlaubte Anzahl URLs pro Minute erreicht wurde. Dann kann derselbe oder ein anderer Aspire-Knoten die URLs in der nächsten Minute verarbeiten. Dies stellt eine einfache, aber effektive Methode, die Geschwindigkeitslimits einzuhalten, dar – unabhängig davon, wie viele Aspire-Knoten für das Crawling eingesetzt werden.

Ziel 2: Erhalten der Heritrix-Funktion zur Extrahierung weiterführender Links

Dies ist die Hauptaufgabe für jeden Webcrawler: HTML Code analysieren und weiterführende Links finden. Heritrix erledigt diese Aufgabe hervorragend, daher wollten wir diesen Teil von Heritrix in unseren eigenen Crawler übernehmen. Dazu gehört auch die Extrahierung weiterführender Links aus JavaScript. In Zukunft planen wir einen Headless-Webbrowser einzubauen, der die Extrahierung der weiterführenden Links sowohl auf dynamisch als auch vom Client erstellte Verknüpfungen ausweitet.

Ziel 3: Nutzen unseres neuen Konnektoren-Frameworks

Dies war der einfachste Teil, da unser Aspire 3.x Konnektoren-Framework uns die Arbeit abgenommen hat. Wir mussten nur noch die Teile implementieren, die wir brauchen.

Dabei haben wir erreicht:

  • Hohe Verfügbarkeit und Ausfallsicherung mit Hilfe von Zookeeper zur Kontrolle der Synchronisation
  • Elastische Skalierbarkeit: Dem Cluster können im laufenden Betrieb weitere Aspire-Knoten hinzugefügt werden, die dann automatisch in den laufenden Crawlingvorgang eingebunden werden.
  • Automatische, inkrementelle Crawlingvorgänge basierend auf Snapshots.
  • Flexible Steuerung des Crawlings über Pausieren/Fortsetzen/Anhalten – in Zeiten, in denen der Hauptserver hohe Last handhaben muss, können die Aspire-Server hierdurch angehalten werden; bei geringerer Last kann die Arbeit dann wieder aufgenommen werden

Ziel 4: Authentifizierung über Basic, Digest und Cookie-basierend zusätzlich zu NTLM/Kerberos anbieten

Hierzu haben wir die Apache HTTP Library genutzt, die für all diese Methoden Implementierungen enthält.

Ziel 5: Besseren Support bieten

Da es sich um unseren eigenen Code handelt, kennen wir Architektur und Design sehr genau. Damit können wir nun unseren Kunden helfen, Probleme mit dem Crawling schneller zu lösen. 

Schon seit der Veröffentlichung von Aspire 1.0 ist uns klar, welche Bedeutung dem Webcrawling zukommt. Mit Aspider haben wir nun die Möglichkeit, die Projekte unserer Kunden mit verbesserter Funktionalität erfolgreicher zu unterstützen, was große Auswirkungen auf alle künftigen Projekte der unternehmensweiten Suche haben wird. Wir versuchen ständig, die Erwartungen unserer Kunden zu übertreffen. Aspider ist ein Ergebnis dieser Bemühungen.

Nebenbei erwähnt haben wir unseren früheren Heritrix-Konnektor und die modifizierte Heritrix-Engine (mit Unterstützung für NTLM und anderen Funktionen) als Open-Source freigegeben. Sie können diese auf Github finden. Fragen und Kommentare können Sie uns an de.stc@accenture.com schicken.

- Andres

0

Wir freuen uns, bekannt zu geben, dass wir jetzt Teil von Accenture sind! Lesen Sie die Ankündigung hier.