Back to top

Suche für Big Data und Big Data für die Suche

Von Paul Nelson, leitender Architekt bei Search Technologies

Die Suche und Big Data haben schon einen langen Weg gemeinsam hinter sich. Schon 2009 haben wir die Möglichkeiten von Hadoop für einen großen Medienanbieter untersucht. 2011 haben wir die Suche in Log-Dateien als Nutzungsfall gefunden. 

Schon seit 2008 beschäftigt sich Search Technologies offiziell mit Big Data, damals haben wir die Verantwortung für eine äußerst umfangreiche Empfehlungsmaschine bei einem großen Kabelanbieter übernommen. Das System verarbeitet aktuell mehr als vier Milliarden Klicks pro Tag. Ursprünglich wurde dafür ein auf Python basierendes Map/Reduce-System eingesetzt, das wir dann 2010 auf Hadoop migriert und in die Produktion überführt haben.

Also habe ich Big Data und (insbesondere) die Auswirkungen auf die Suche seit mindestens sieben Jahren erforscht. Aber bisher hatte ich nie das Gefühl, einen Eintrag in den „Suchchroniken“ dazu schreiben zu können. 

Bisher. 

Bisher war die Suche für Big Data (für mich) eigentlich immer etwas gewesen, das nebenbei geschieht. Eine Möglichkeit, eine schnelle interaktive Suche in Log-Dateien vorzunehmen. Da Log-Dateien wenig Content im Volltext bieten (wenn überhaupt), habe ich eigentlich nur meine eigene Neugier befriedigt.

Dann hatte ich drei Erkenntnisse, die meine Sicht auf dieses Thema vollkommen geändert haben.

 

Erkenntnis 1: Es ist Zeit, dass Suchsysteme eine (angereicherte) Kopie der Daten aufbewahren

Ich gehöre zur älteren Generation. Ernsthaft. Ich entwickle schon seit 1978 Software.

Und genau wie für meine Eltern, die aus der Zeit der Weltwirtschaftskrise stammen, war es für mich schwer, einige der alten Vorurteile loszuwerden. Wie etwa die übermäßige Betonung auf effiziente Verwendung von Hardware und Speicherplatz. Ich erinnere mich noch daran, wie ich als Ingenieur bei Westinghouse gearbeitet und die gigantische „1 Gigabyte“-Festplatte für unsere Apollo Workstations bewundert habe (damals in etwa die Größe einer Waschmaschine). Solche Erfahrungen wurden zu Vorurteilen, die ich erst mit der Zeit ablegen musste.

Seit ich 1989 mein eigenes Unternehmen für Suchmaschinen gestartet habe (meine erste Suchmaschine lief noch von einer Diskette in 640K RAM auf einem Windows PC), war die Suchmaschine eigentlich immer „nur ein Index“. „Wir machen keine Kopien Ihrer Daten“, erklärte ich den Kunden zuversichtlich. „Wir halten nur einen Index. Die eigentlichen Daten bleiben auf Ihrem Quellsystem.“

Aber das soll sich jetzt ändern. Wenn wir akzeptieren, dass eine Kopie der Daten im Suchsystem (ich wähle hier ausdrücklich das Wort „Suchsystem“, um die gesamte Infrastruktur um die Suchmaschine sowie die Suchmaschine selbst einzufassen) liegen muss, öffnen wir die Suche einem viel breiteren Spektrum der Möglichkeiten, darunter:

  • Schnelle Neu-Verarbeitung und Neu-Indexierung in großem Maßstab, bedeutet ...

Heutzutage brauchen viele Suchsystem Tage, Wochen oder gar Monate, um die gesamten Daten neu zu verarbeiten und neu zu indexieren. Das kommt daher, weil die Daten erst neu von den ursprünglichen Contentquellen abgerufen werden müssen. Wenn eine Kopie dieser Daten im Suchsystem liegt, können erneute Verarbeitung und erneute Indexierung schnell vorgenommen werden, vielleicht sogar in wenigen Minuten oder Stunden.

  • ... ein viel leistungsfähigeres Indexieren ...

„Wenn wir das so machen, sind wir doch ständig mit neuem Indexieren beschäftigt.“

Solche Kommentare hört man häufig, wenn es um die Architektur von Suchmaschinen geht. Aber, was, wenn neues Indexieren und neue Verarbeitung keine großen Probleme mehr darstellen? Was, wenn wir alles ständig neu indexieren könnten, einfach nur, weil wir es können?

Solche Systeme verschieben unsere Erwartungshaltung hinsichtlich der Algorithmen, die von einem Suchsystem bewältigt werden können. Wir können beispielsweise jetzt schon komplexe Sicherheitsanforderungen für die Suche und exotische Relevanzalgorithmen bei der Indexierung einsetzen, statt diese Berechnungen während der Abfrage vorzunehmen. Damit werden Umfang und Leistungsfähigkeit des gesamten Suchsystems weiter angehoben.

  •  ... und Flexibilität, während ...

Je schneller wir indexieren können, desto leichter kann unser Suchsystem Änderungen bei der Content-Verarbeitung, dem Verständnis des Contents und der Bereinigung von einfachen Bugs im Index handhaben. Es wird damit schlechthin flexibel. 

Damit wird auch die Art und Weise verschoben, wie wir Suchsysteme einsetzen. Zuerst sammelt man nur Daten, Entscheidungen zur Content-Verarbeitung können auf später verschoben werden. Dieses komische Feld X von Contentquelle Y? Kümmere ich mich später drum. Mache ich mir später Gedanken drüber. Oder auch nicht. Vielleicht war es ja gar nicht so wichtig.

Damit werden Suchsysteme plastischer, manipulierbarer, man kann viel leichter mit ihnen „spielen“, bis es irgendwie passt. Und das macht einfach mehr Spaß.

  • ... gleichzeitig die Legacy-Systeme weniger belastet werden und ...

Wenn das Suchsystem eine Kopie der Daten zurückbehält, müssen diese nicht wieder erneut von den ursprünglichen Quellsystemen abgerufen werden, wenn der Content erneut verarbeitet und indexiert werden soll. 

Damit werden die Repositories, Legacy-Systeme und Netzwerke weniger belastet. Sie müssen nur eine Kopie des Dokuments liefern, damit ist ihre Arbeit getan.

  •  ... bessere Trennung zwischen Content-Erwerb, Content-Verarbeitung und Indexieren erreicht wird.

Architekten lieben Untersysteme separat und mit klar definierten Abgrenzungen, wo immer möglich. Standardarchitekturen für Suchmaschinen, die Content-Erwerb, Content-Verarbeitung und Indexieren auf einem einzelnen System vornehmen, sind unflexibel, schwierig zu aktualisieren und fehleranfällig. Es gibt einfach zu viele bewegliche Teile.

Den Content-Erwerb von der Content-Verarbeitung abtrennen, indem man einen Puffer aus Big Data (eine Kopie der Daten) zwischenschaltet, steigert die Stabilität und Zuverlässigkeit des Suchsystems drastisch. Jedes Untersystem funktioniert unabhängig und kann individuell entwickelt, getestet und verwaltet werden.

  • Und schließlich ...

Durch eine lokal vorliegende Kopie der Daten wird „Big Data mit Suche“ möglich.

 

Denn wie kann die Verarbeitung von Big Data ohne Daten vorgenommen werden? 

Die Antwort ist einfach: Gar nicht. Daher ist es notwendig zu akzeptieren, dass Suchsysteme inzwischen mehr als „nur ein Index“ sind. Viel mehr. Eine Kopie der ursprünglichen Daten, mit der man arbeiten kann, ermöglicht erst alles, worüber wir hier reden. Es ist eine absolute Voraussetzung. 

Aber trotzdem gibt es legitime Bedenkgründe, die dagegen sprechen, alle Daten in das Suchsystem zu kopieren.

  1. Es sind viele Daten
  2. Es ist nicht sicher

Diese Bedenken müssen ernsthaft bedacht werden, ehe man ein Suchsystem mit Fähigkeiten zu Big Data zu einem integralen Bestandteil der Unternehmensinfrastruktur macht.

In Hinsicht auf Punkt 1 (Es sind viele Daten!): Wir müssen nicht wirklich Kopien von allen Bits und Bytes auf jeder Festplatte festhalten. Nach aktuellem Stand der Dinge sind gut 95% der Daten in Unternehmensnetzwerken ohnehin nicht für Suche und Big Data geeignet. Sobald der Text aus einer PowerPoint-Datei extrahiert wurde, kann der Rest der 10MB PPT vernachlässigt werden. Ebenso bei Bilddateien (Extrahieren der Texte per OCR), Video und Audio (Extrahieren durch Stimmerkennung). Ja, man kann argumentieren, dass einige dieser ursprünglichen Daten für die Suche nützlich sein können, aber für die meisten Anwendungen liegt dieser Nutzen so weit in der Zukunft, dass wir uns jetzt noch nicht darum kümmern müssen. 

In Hinsicht auf Punkt 2 (Es ist nicht sicher!): Hier geht es meist um die Sorge, dass Kopien sensibler Dokumente „frei verfügbar“ im Suchsystem liegen. Die Daten wären sicherer, wenn sie direkt in den Suchindex geschrieben wären, weil es sich dabei dann um große Binärdateien handelt, die nur schwer durchsucht und gelesen werden können. 

Hierzu will ich eine kleine Geschichte einbringen, die um 1998 wirklich passiert ist. Ein Systemadministrator hat sich unautorisiert direkt auf unserem Outlook-Server eingeloggt und hat meine E-Mail gelesen, um etwas zu finden, das er gegen mich verwenden konnte. Mir ist also vollkommen bewusst, welche Auswirkungen es haben kann, wenn Administratoren an ungeschützte Daten kommen (Ich muss wohl nicht erst an Edward Snowden erinnern?). 

Daher können wir dieses zweite Problem lösen, indem wir Datenverschlüsselung und ausreichend sichere interne Prozesse anwenden, die verhindern, dass unautorisierte Administratoren Zugriff erhalten. Falls solch ein Zugriff dennoch auftreten sollte, muss dieser natürlich aufgezeichnet und überwacht werden. Wir müssen jetzt damit anfangen, Systemarchitekturen mit solchen Kontrollen zu entwickeln, damit diese bereit sind, wenn auch die Unternehmen so weit sind, sich auf die neue Technologie einzulassen. Was hoffentlich nicht mehr zu lange dauern wird.

Lesen Sie weiter ...

Erkenntnis 2: Big Data macht die Suche besser und leichter.

0