Auf der Suche nach dem heiligen Gral

Business Intelligence und Facetten

In einer Veröffentlichung aus dem Jahre 2008 [13] diskutiert Ben Yitzhak die Möglichkeit, Datenbeziehungen, die normalerweise mit mulitdimensionalen Cubes abgebildet werden, mithilfe von Facetten-Such-Abfragen zu modellieren. Der Autor stellt hierbei zwei Thesen zur Diskussion:

  • die Anwendung von dynamischen Aggregationen auf facettierten Daten bietet Vorteile im Vergleich zu den traditionellen, vorberechneten Aggregationen im Data Warehouse
  • facettierte Daten bilden die Realität genauer ab und führen zu signifikanten Vorteilen beim Speicherverbrauch
Facetten

Facetten erlauben dem Anwender, die Ergebnisse nach einer Kategorie zu gruppieren und damit einfache Aggregationen auf den gruppierten Ergebnissen bereitzustellen. Auf diese Weise kann der Nutzer sehen, in welchen Bereichen er weiter nach spezifischen Ergebnissen filtern möchte. Ein Vorteil ist hierbei, dass der Nutzer direkt an der Anzahl der Kind-Elemente ablesen kann, wo der weitere Drill-Down Sinn macht. Nehmen wir als Beispiel deutsche Autohersteller und starten mit einer initialen Abfrage mit zwei Facetten:

http://server/solr/select?q=auto&facet=true&facet.field=maker&facet.fiel…

Diese Abfrage wird alle Vorkommen für das Wort „auto“ anzeigen, aber wird diese anhand des Felds Hersteller (maker) und Ort (town) gruppieren:

VW         (23)
BMW        (12)
Audi       (7)
Porsche    (5)
Opel       (15)
Mercedes   (20)

Stuttgart  (40)
Berlin     (12)
München    (23)
Düsseldorf (15)
  • Freitextabfragen sind sehr flexibel möglich.
  • OLAP-Cube-Aggregationen sind vorberechnet und damit aufwändig in der Pflege, bei jeder Änderung der Daten müssen die Aggregate aktualisiert werden.
  • Es müssen nur die Felder indiziert werden, die in Abfragen auch verwendet werden, die Aggregationen müssen ebenfalls nicht vordefiniert werden.
  • Dokumente können mit mehreren Werten in der gleichen Dimension gleichzeitig assoziiert werden, was bei OLAP Cubes nur eingeschränkt oder schwierig möglich ist.
  • Der Relevanzwert in den Aggregationen bietet dem Nutzer Hinweise, wo sich der weitere Drill-Down lohnt.
  • Aggregationen müssen nicht vorberechnet werden und können daher quasi als Ad-hoc-Cubes oder Lazy-loaded-Aggregationen betrachtet werden.
  • Hybride Lösungen, die Textanalyse und relationale Daten kombinieren, wie etwa EMCs Greenplum, werden wahrscheinlich verstärkte Verbreitung erfahren.
  • Es bietet sich die Möglichkeit, nur die Pfade in der Navigation anzuzeigen, die auch wirklich Daten enthalten und damit den Nutzer zu führen und unnötige Drill-Downs zu vermeiden.

Gerade der zuletzt genannte Aspekt ist noch relativ neu: in den jüngsten Releases von Solr ist Field Collapsing umgesetzt [15], für ElasticSearch existieren Pläne zur Umsetzung [16].

Suche und Hadoop

Zuletzt möchten wir noch die Frage erörtern, wie sich die Suche mit MapReduce sinnvoll verbinden lässt. Wie lassen sich die Geschwindigkeit und Flexibilität von Suchtechnologie mit den massiv parallelen Verarbeitungskapazitäten von Hadoop kombinieren? Einerseits ist der Aufbau des Index ein zeitintensiver Prozess und könnte von der Parallelisierung in einer Hadoop-Infrastruktur profitieren. Andererseits erlaubt das Hadoop-Dateisystem HDFS keinen wahlfreien Lesezugriff auf die Dateien, sondern erwartet einen sequenziellen Zugriff. Auch ist Solr optimiert für einen Index im lokalen Dateisystem und kann von Haus aus seinen Index nicht automatisiert verteilt verwalten.

Eine sinnvolle Kombination wäre daher, den Hadoop Cluster für das verteilte Erstellen des Index zu nutzen und anschließend den gemergten Index auf ein lokales Dateisystem zur Nutzung im Suchserver zu exportieren. Verschiedene Beispiele hierzu sind online zu finden:

  • die Transformation von MapReduce Input direkt in Lucene-Format mit dem Cascading-Framework [17]
  • das verteilte Erstellen von einem Teil des Index mit Hadoop, anschließendem Merge und dem Bereitstellen des Gesamtindex für Solr ([18], in einer mehrphasigen Variante [19])
  • Arbeiten im Solr-Projekt zur Verbesserung der Integrationsmöglichkeiten [20]
  • ein spärlich dokumentiertes Plug-in für die ElasticSearch-Hadoop-Anbindung [21]

Ein weiterer Ansatz besteht darin, den Index direkt in HBase-Tabellen abzulegen, da HBase einen wahlfreien Zugriff auf die Daten erlaubt. Damit ergibt sich dann die Möglichkeit, den Lucene-Index direkt innerhalb der Hadoop-Umgebung abzuspeichern und von dort zu verwenden [22].

Fazit

Sowohl Solr als auch ElasticSearch bieten mächtige APIs, um mit der Suchmaschine zusammenzuarbeiten, und setzen auf den Lucene-Kernbibliotheken auf. Aktuell bietet Solr eine stärkere Verbreitung und eine größere Community, ElasticSearch punktet mit einfachem Betrieb der Server sowie der Möglichkeit, mehrere Indizes in einer Abfrage zu verbinden. Im klassischen BI-Umfeld ergeben sich interessante Anknüpfungspunkte zur facettenbasierten Suche. Und die ersten erfolgreichen Integrationen von Hadoop- und Lucene-Technologie zeigen vielversprechende Ansätze zur weiteren Entwicklung. Alles in allem wird Lucene wohl auch im Big-Data-Bereich eine tragende Rolle einnehmen.

Andrew Kenworthy arbeitet als Senior-Entwickler bei der inovex GmbH im Bereich Java-Applikationen und Business-Intelligence-Lösungen. Aktuell liegt sein Hauptfokus auf Hadoop- und Lucene-basierten Big-Data-Projekten, häufig im Umfeld der Webanalyse.

Christian Meder ist CTO bei der inovex GmbH in Pforzheim. Dort beschäftigt er sich vor allem mit leichtgewichtigen Java- und Open-Source-Technologien sowie skalierbaren Linux-basierten Architekturen. Seit mehr als einer Dekade ist er in der Open-Source-Community aktiv.

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.