Sommer Sitzung 11
| Thema | Stichworte | Material ___________________________ |
| Überblick | Grundlegendes Web-Crawling, HTML-Verarbeitung und Concurrency | Beispiele und Literatur: Home |
| Bezug Volltextsuche | Hatten Index, Vorverarbeitung, grundlgende Rechtschreibekorrektur, aber woher bekommen wir den Inhalt? – bisher? – statische Sammlung, z.B. Shakespeares Werke; was wäre toll? – das Web ist eine riesiger Fundus von Text, für unterschiedliche Anwendungen (Volltextsuche, aber auch andere Sachen, z.B. Analyse, Klassifikation, Clustering, vgl. Literatur, spez. Manning et al.) |  |
| Websites laden | Simpelste Form Website laden? – URL, Stream; @Test load, URL instanziieren, mit Guava in String lesen | s. Code: load |
| Kurzexkurs: externe Bibliotheken in Java | Viele Dinge, die mit Standard-Bibliotheken nicht oder nur umständlich möglich sind; statt immer wieder neu oder selbst implementieren kann man zusätzliche Bibliotheken einbinden; die werden meist in Form von Jar-Dateien bereitgestellt; ein Beispiel von oben: Google Guava: Zusatzbibliotheken für Java auf vielen Ebenen (Collections, IO, etc); lohnt sich kennenzulernen | Guava |
| Probleme mit HTML | Was für Probleme? – generell: Web ist gross, HTML ist chaotisch (vers. Browser behandeln Sachen verschieden etc.); konkret: wir können HTML nicht einfach so indexieren; Vorverarbeitung ist nicht so einfach wie bei Plain-Text-Beispiel von neulich; warum? – hierarchisch geschachtelt; Was machen wir mit dem rohen, möglicherweise invaliden HTML? – wir brauchen Struktur | — |
| Websites parsen | Wie is HTML grundlegend aufgebaut? – s. Abb.; High-level API? – zu URL Dokument, mit was? – Inhalt und Links; Was ist parsing? – linear zu strukturiert umwandeln; @Test parse, API: WebDocument, Parser; Wie HTML verarbeiten? – wie XML? – Unterschied HTML – XML? – Attribute in Anführungszeichen, Elemente immer schließen, etc.; d.h. Problem: HTML ist kein XML, XML kann man gut verarbeiten; Lösung: aus HTML valides XML machen; das machen wir nicht selbst, sondern verwenden wieder eine externe Bibliothek; NekoHTML nutzen für fehlerkorrigierende HTML-Verarbeitung; Was aus HTML lesen? – Was brauchen wir aus der Seite? – Text und Links, kann geschachtelt sein; d.h. konkret? – Rekursives Auslesen von p- und a-tags |  |
| Implementierung: HTML parsen | Der Parser übernimmt für uns die Umwandlung einer URL in ein WebDocument, das Inhalt und ausgehende Links der Seite an der URL enthält; Jetzt OK für ein Dokument | s. Code: parse |
| Websites crawlen | Wollen nicht nur eins, sondern mehrere; Grundidee? – beginne irgendwo (URL seeds); Seite holen, parsen, Text speichern, URLs extrahieren und merken, und von vorne mit neuen URLs; Wie umsetzen? – @Test crawl, API: Crawler, Seed, Ergebnisliste; Logik des Crawling? – Implementieren: seed durchgehen; Dokumente speichern; neue Links sammeln, auch wieder abgrasen, usw. |  |
| Concrrency | Zweites Problem: Web ist groß, im Grunde unendlich; Performance: wie grundsätzlich optimieren? – Verteilung d.h. verschiedene Seiten gleichzeitig (parallel, nebenläufig, concurrent) verarbeiten, nicht nacheinander (sequenziell); hier und heute nicht auf Nodes d.h. verschiedene Rechner aber auf Cores in einem Rechner | — |
| Concurrency: Probleme | Wenn man was gleichzeitig macht, was gibt es für Probleme? – z.B. gleichzeitig mehrere Seiten einlesen? – am Ende soll alles in einem Index zusammengeführt werden; generelles Problem: gleichzeitige Sachen am Ende zusammenführen; wenn das Zusammenführen nicht korrekt gemacht wird, wenn der Zugriff auf gemeinsamen Zustand der parallelen Prozesse nicht korrekt koordiniert wird, was passiert? – das Programm wird nicht-deterministisch, d.h.? – bei verschiedenen Durchläufen können verschiedene Ergebnisse rauskommen, je nachdem welcher Prozess in welcher Reihenfolge was macht; d.h. was müssen wir tun? – 1) kein gemeinsamer Zustand oder 2) den Zugriff auf gemeinsamen Zustand kontrollieren (oder synchronisieren); allgemein merken: Concurrency ist eine sehr schwierige und heikle Sache, wo unheimlich viel schief gehen kann, in die man sich nur schwer reindenken kann, und die aufwändig zu debuggen ist; aktuelle Ansätze sind nur ein Schritt; Konsens in der Softwareentwicklung: der richtige Weg ist noch nicht gefunden, gibt viele Ansätze, Sachen der Java-Standardbibliothek sind nur ein Weg; hier nur eine kurze, einfache Einführung; Empfehlung: Bloch, Kapitel 10 (sehr praktische, kompakte Darstellung) | — |
| Concurrency in Java | Executor service und Parallelisierung im Crawler, CrawlerRunnable: crawl-Methode aus Crawler ins Runnable; synchronized Wrapper für Koordinierung des Zugriffs | s. Code: Crawler |
| Implementierung: Crawler und Runnable | Ein Runnable, die Einheit dessen, was parallel zu tun ist. In unserem Fall heißt das: die Ausgangs-URLs gleichzeitig bis zur gewünschten Tiefe crawlen. Sollen wir jeden Link parallel verfolgen? – da die meisten Links auf dem gleichen Host liegen hätte dies zur Folge, dass aus sehr vielen (z.B. bei zeit.de) Threads gleichzeitig Anfragen an einen Host gingen, was nicht höflich wäre und auch nicht funktionieren würde. | s. Code: Runnable |
| Fazit | Fehlerkorrigierendes HTML-Parsing und paralleles Crawling – um aus Websites sowas zu machen wie unser Shakespeare-Text, den wir indexieren oder anders weiterverarbeiten können | — |
| Hausaufgabe | Überlegungen zum Crawling; Laufzeitvergleiche | Sommer-Aufgabe-10 |