Enterprise Search: ein Big-Data-Problem für den Big Boss?

Wie die meisten Menschen denke ich bei Big Data an riesige Datenbestände in einer Größenordnung von, sagen wir, mehreren Petabyte, die einer dezentralen Verarbeitung bedürfen.

Kurz zur Erinnerung: Ein Petabyte umfasst mehr als eine Million Gigabyte – ein ganzes Lager voller USB-Sticks. Normalerweise finden sich Unternehmen im Big-Data-Bereich wieder, wenn sie Transaktionsdaten von Millionen von Kunden sammeln oder wie im Fall sozialer Medien, wenn sie Statusmeldungen, Bilder und Videos eines sehr großen Abonnentenstamms speichern.

Doch es gibt noch eine weitere, naheliegende Möglichkeit, um die Big-Data-Schwelle zu überschreiten. Die internen Dateisysteme großer Unternehmen überschreiten die Größe von einem Petabyte oft mühelos. Wir sprachen mit einem IT‑Verantwortlichen, der ein Dateisystem von 1,5 Petabyte verwaltet, das allein auf den nutzergenerierten Daten der 40.000 Unternehmensmitarbeiter basiert. Das Dateisystem Ihres Unternehmens ist möglicherweise nicht so groß. Doch wenn Ihre Firma mehr als 1.000 Mitarbeiter beschäftigt, verfügen Sie höchstwahrscheinlich über einige Terabyte Speicherplatz oder sogar mehr. Noch kein Petabyte, aber dennoch eine ganze Menge.

Ist Enterprise Search Big Data?

Der Big-Data-Bereich ist einigermaßen schwer zu fassen und bei vielen Faktoren herrscht keine übereinstimmende Begriffsbildung. Es gibt aber noch ein anderes Bewertungskriterium, ob es sich um Big Data handelt oder nicht: wenn besonders komplexe Geschäftstätigkeiten auf besonders hohe Performance-Anforderungen treffen. Wenn Sie für einen immensen Datenbestand mit hoher Geschwindigkeit schwierige Rechenvorgänge oder Algorithmen ausführen, haben Sie es mit Big Data zu tun.

An welche Arten von Big-Data-Problemen kann man im Zusammenhang mit internen Dateisystemen denken? Ähnlich wie bei einer webbasierten Suche können Mitarbeiter bei der unternehmensweiten Suche die Dateisysteme des Unternehmens durchsuchen und auf diese Weise à la Google Ergebnisse in Form einer geordneten Liste generieren. Sie kann nach Relevanz sortiert werden und  die vergebenen Dateiberechtigungen berücksichtigen. Letzteres bedeutet, dass diese Suche, im Gegensatz zur Websuche, anhand von Berechtigungen (Listen für die Zugriffsberechtigungen) für einzelne Inhalte ergeben muss, ob ein Benutzer die Suchergebnisse anzeigen darf.

Im Idealfall ist Enterprise Search genauso schnell und leistungsstark wie eine Suchmaschinen benötigt aber weit weniger Rechnerkapazitäten.

Insgesamt sieht es danach aus, dass solche unternehmensweiten Suchen zunehmend der Big-Data-Kategorie zugeordnet werden.  Sie fragen sich, ob hier Metadaten im Spiel sind? Ja bei beiden, sowohl bei der Websuche als auch bei der unternehmensweiten Suche.

Die Reihenfolge von Suchergebnissen

Wenn wir uns eingehender mit dem Thema Enterprise Search beschäftigen, bekommen wir ein Gefühl für die Dimensionen und die Rolle, die Metadaten spielen. Wie bei Suchmaschinen für private Anwender sollten die passendsten Suchergebnisse auf der ersten Seite stehen. Das führt zum sogenannten Ranking-Problem. Es wurde von den Google-Gründern, die den PageRank-Algorithmus erfunden haben, auf bemerkenswerteste Weise gelöst. Zwar berechnet Google die Ergebnisreihenfolge inzwischen längst mithilfe anderer Methoden, doch aus der ursprünglichen Idee kann man lernen: Der PageRank basiert auf bestimmten Metadaten, in diesem Fall den Links zu einer Webseite, mit deren Hilfe die Reihenfolge bestimmt wird.

Mit anderen Worten: Zu den beliebteren Webseiten – die in der Liste der Seiten, die der Schlüsselwortsuche entsprechen, weiter oben stehen – führen mehr Links. Wer sich genauer informieren möchte, kann hier die ursprüngliche Publikation von Sergey und Larry lesen. Übrigens gibt es noch weitere Ranking-Algorithmen, doch sie basieren alle auf dem beschriebenen Abstimmungsansatz und der Verwendung von Metadaten zur Zahl der Links.

Die große Frage ist: gibt es bei der unternehmensweiten Suche ein Äquivalent zu dieser Ranking-Bestimmung mithilfe von Metadaten und können anhand derer Dateiergebnisse entsprechend der Schlüsselwortsuche auf der Grundlage einer Popularitätsskala sortiert werden.

Social Search als Teil der unternehmensweiten Suche

Es gibt tatsächlich eine passende Analogie zur Ranking-Bestimmung mithilfe von Links. Denn in gewisser Weise sind die Metadaten mit dem Dateizugriff verbunden: Die Zahl der Nutzer, die eine Datei anzeigen oder ändern, dient als Anhaltspunkt für deren Popularität. Wie bei der Suche im Internet sind zusätzliche Metadaten auch bei der unternehmensweiten Suche vorteilhaft. Wir können auch auf ganz normale Dateien ähnliche Popularitätsalgorithmen anwenden. Nachdem hier Metadaten zu den jeweiligen Aktivitäten ins Spiel kommen haben wir es definitiv mit einer Big-Data-Herausforderung zu tun. Und damit genau mit der Art von Problemen, die Chefs gelöst sehen wollen.

Man kann dieses Problem auf vielerlei Arten angehen. Vor einiger Zeit habe ich einen Blog-Beitrag geschrieben,  in dem es um das Prinzip der „gleich gesinnten Nutzer“ geht. Demnach haben Menschen, die allgemein dieselben Interessen teilen, wahrscheinlich noch weitere Gemeinsamkeiten – sie haben den gleichen Geschmack. Das lässt sich auch als eine Art von Herdenverhalten beschreiben: Wir folgen einander.  Dieses Phänomen wird in der Welt der sozialen Netzwerke von vielen der üblichen Verdächtigen für Social Search genutzt, zum Beispiel von Facebook für die „Graph Search“.

Ähnliches lässt sich bei der unternehmensweiten Suche durch eine Feinabstimmung der Ranking-Bestimmung erreichen.  Nehmen wir an, Nutzer A greift auf die Datei „Marketingstrategie für Produkt X“ zu, auf die auch Nutzer B zugreift. Und Nutzer B hat auch auf die Datei „Umsatzdaten für Produkt X“ zugegriffen, auf die Nutzer A nicht zugreift. Nach dem Prinzip der gleich gesinnten Nutzer würde der Popularitätswert der Datei mit den Umsatzdaten durch Nutzer A leicht positiv beeinflusst, auch wenn er nicht darauf zugreift. Nehmen wir nun an, Nutzer A sucht nach Schlüsselwörtern, die in der Datei „Umsatzdaten für Produkt X“ enthalten sind, beispielsweise „Metadaten“ und „Software“. Die Datei würde aufgrund ihrer SAN-Gewichtung in der Liste der Ergebnisse weiter oben angezeigt, als wenn A und B nicht „gleich gesinnt“ wären.

Kurz und bündig: SANs

Nein, hier geht es nicht um Storage Area Networks. Das eben beschriebene Ranking-Modell wird als Social Attribute Network (SAN) bezeichnet und berücksichtigt zwei Arten von Metadaten: die Nutzer und ihre Beziehungen als sozialen Teil sowie die eigentlichen Daten und deren Beziehung zueinander. Im Gegensatz zu einem SAN bezieht der PageRank soziale Metadaten nicht direkt ein, da der Ranking-Algorithmus nur auf Daten‑ oder Inhaltsbeziehungen beruht.

Es gibt einige ausgezeichnete Studien zu SANs, doch alle weisen letztendlich auf einen Mann zurück, der  für diese Modelle Pate gestanden und einen Ranking-Algorithmus erfunden hat, der noch vor dem PageRank kam: Jon Kleinberg von der Cornell University.

Die Berechnung eines SAN-Rankings für die unternehmensweite Suche, ich verspreche, mich kurz zu fassen, erfolgt oft mithilfe einer riesigen Tabelle, die übrigens auch bei der PageRank-Berechnung verwendet wird. Stellen Sie sich vor, dass jede Zeile einer Datei und jede Spalte einem Nutzer entspricht. Der ursprüngliche Eintrag gibt an, ob ein Nutzer auf die Datei zugreift – nehmen wir dafür einmal eine 1. Der SAN-Algorithmus ist iterativ und passt die Popularitätswerte auf der Grundlage einer Kette von Vorlieben an.  Schlussendlich wird eine Zahl errechnet, technisch betrachtet eine Wahrscheinlichkeit, doch das soll uns nicht stören, aus der sich die Relevanz einer Datei für die einzelnen Nutzer ergibt. Das heißt, dass ein SAN im Unterschied zum PageRank ein nutzerspezifisches Ranking liefert.

Die Tabelle ist gigantisch (sie kann mehrere tausend Nutzer und hunderttausende Dateien enthalten), und die Berechnungen sind komplex und müssen ausgeführt werden, bis die Rankingwerte konvergieren.

Enterprise Search ist ein weites Feld, insbesondere im Hinblick auf die sozialen Aspekte und lässt sich nicht in einem einzigen Blog-Beitrag abhandeln. Ich komme in den nächsten Wochen auf das Thema Dateisuche und die damit verbundenen Datendimensionen zurück.

Bildnachweis: Magnus Manske

The post Enterprise Search: ein Big-Data-Problem für den Big Boss? appeared first on Varonis Deutsch.