Techtalk: Puzzle einmal anders

E-Business Techtalk
Techtalk: Puzzle einmal anders

In einem Unternehmen existieren heute sehr viele Daten über Personen, Produkte, Vorgänge etc., doch leider sind sie oft in verschiedenen Systemen verstreut. Eine leistungsfähige Enterprise Search Lösung muss diese Grenzen überwinden und ein Gesamtbild anbieten. Besonderes herausfordernd ist, dass oft nicht alle Benutzer alles wissen dürfen.

Techtalk Serie Enterprise Search, Teil 2: Informationen aus verschiedenen Systemen zusammenführen

Jedes Unternehmen hat zahlreiche Systeme mit vielen Daten – über seine Kunden, seine Produkte, seine Prozesse und vieles mehr. Leider sind diese Daten oft ungenügend zugänglich und generieren deshalb nur wenig Wert.

Enterprise Search als Komponente im GARAIO E-Business-Motor nimmt sich dieser Herausforderung an und stellt Werkzeuge zur Verfügung, um Daten durchsuchbar, auffindbar und abfragbar zu machen. In einer losen Serie von Tech Talk Beiträgen zeigen wir entsprechende Konzepte und Lösungen aus der Praxis. 

Puzzle einmal anders

Betrachten wir zum Einstieg eine Person: Sie hat einen Namen, Postadresse(n), ein Geburtsdatum, ein Geschlecht. Dazu kommen Newsletter-Abonnemente, Bestellungen, Support-Anfragen, Offerten, laufende Projekte, Beziehungen zu anderen Personen und viele weitere verschiedene Informationen, die wiederum in verschiedenen Systemen bewirtschaftet werden. Wenn nun eine Enterprise Search-Lösung den gesamten Datenbestand nutzbar machen soll, muss sie dieses Puzzle zusammensetzen. Der Artikel zeigt einen möglichen Lösungsansatz für diese Herausforderung auf.

Die Idee

Jedes System, das Informationen hat, stellt diese als Fragmente zur Verfügung. Das Enterprise Search System führt diese Fragmente zusammen und bildet daraus eine Gesamtsicht auf jede der Entitäten. Diese Gesamtsicht wird dann aufbereitet und im Index gespeichert, der anschliessend für die Suche und Abfragen verwendet werden kann.

Der Index

Bereits Teil 1 der Enterprise Search-Serie zeigt auf, dass eine leistungsfähige Suche nur dann funktioniert, wenn alle Daten in einer vorverarbeiteten Form in einem zentralen Index zur Verfügung stehen. Als zentraler Index empfiehlt sich Apache Solr, die meistgenutzte Search Engine. Solr ermöglicht es, Daten in Form von semistrukturierten Dokumenten abzulegen und in einer kombinierten Form von Volltext- und Wert-Bedingungen abzufragen.

Besonders spannend ist das Ranking, d.h. die Berechnung der Relevanz von Suchbegriffen in Dokumenten. Dazu nutzt Solr verschiedene Algorithmen, welche die Verteilung des Suchbegriffs im Ganzen sowie sein Verhältnis zu anderen Begriffen im einzelnen Dokument berücksichtigen. Zudem können einzelne Felder in den gespeicherten Dokumenten mit einer höheren Gewichtung markiert werden. Dies funktioniert recht gut – sofern alle Daten zu einem Datensatz auch tatsächlich in einem Solr-Dokument zusammengeführt sind.

Der Index umfasst somit ein möglichst vollständiges Abbild aller Daten aus allen Systemen in einer für lesenden Zugriff optimierten Form. Die meisten Datenbank-Design-Regeln (z.B. Normalisierung) können grosszügig ignoriert werden, da keine Transaktionen auf diesen Datenbeständen ausgeführt werden müssen.

Puzzleteile: Fragmente

Ein Lösungsansatz besteht darin, die Verarbeitungskette zwischen der Quelle der Daten (typischerweise die zuständige Fachapplikation) und dem Index um eine Stufe zu erweitern: Die Fragmente. Ein Fragment enthält – wie sein Name es andeutet – ein Stück Information über etwas, zum Beispiel die Adressdaten einer Person.

Ein Fragment umfasst typischerweise folgende Informationen:

eine eindeutige Identifikation, welche auch die Rückverfolgbarkeit zur Quelle sicherstellt

eine Angabe, zu welcher Entität es gehört

eine Angabe über die dafür geltenden Berechtigungen

die effektiven Nutzdaten in der Form eines XML-Dokuments

Weiterhin gibt es Include-Fragmente, welche angeben, dass Entität A abhängig von einer anderen Entität B ist. Dies ermöglicht es, A anhand von Eigenschaften von B im Index zu finden.

Die Angabe der Berechtigungen kann abhängig vom jeweiligen Umfeld verschiedene Formen annehmen. Oftmals genügt es, dass ein Fragment angibt, welche Entität die Rechte des Fragments steuert.

Beispiel für einzelne Fragmente mit einem Anteil einer Postadresse bzw. gewissen Personenstammdaten sowie Informationen über ein externes Login. Diese Fragmente stammen aus verschiedenen Quellen und werden zu verschiedenen Zeitpunkten erzeugt.

Umfang der Nutzdaten und Regenerieren der Fragmente

Die Nutzdaten sollten üblicherweise die gesamte fachlich relevante Information umfassen, die im Quellsystem über diese Entität verfügbar ist. Die Beurteilung, ob und in welcher Form diese Informationen für Suche und Abfragen verwendet werden sollen, kann zu einem späteren Zeitpunkt erfolgen.

Damit wird vermieden, dass bei jeder neuen Anforderung an die Suche die Daten neu aus den Quellsystemen exportiert werden müssen. Dennoch ist es wichtig, dass alle Informationen in den Fragmenten lediglich ein Abbild darstellen, so dass sie bezüglich Datensicherung, Archivierung etc. schlanker behandelt werden können als die Daten in den Quellsystemen.

In gewissen Fällen – insbesondere beim initialen Aufbau des Index, aber teilweise auch später nach grundlegenden Anpassungen – müssen die Quellsysteme alle ihre Fragmente neu generieren und an den Index übermitteln. Im Regelbetrieb führen sie dies – nach Möglichkeit ereignisgesteuert und so rasch wie möglich – laufend aus, damit der Index möglichst jederzeit ein aktuelles Abbild der Daten enthält.

Der gemeinsame Schlüssel

Voraussetzung für die Zusammenführung der Fragmente ist ein gemeinsamer Schlüssel, mit dem eine Entität über die verschiedenen Systeme hinweg identifiziert werden kann. Dies ist oft eine Herausforderung, weil die Systeme je eigene Tabellen, interne Nummern etc. haben.

Aus Datenhaltungssicht eignet sich für den gemeinsamen Schlüssel eine guid besonders gut, da sie an beliebigen Stellen zu beliebigen Zeitpunkten generiert werden kann und mit hoher Sicherheit eindeutig ist. Die direkte Nutzung einer guid erfordert aber, dass sie von einem System zugeteilt und von den anderen Systemen in einer Art Zuordnungstabelle gespeichert wird. Dies ist recht umständlich und erfordert zusätzliche Datenhaltung in vielen Systemen.

Alternativ dazu kann der in RFC 4122 definierte Ansatz (oder eine Abwandlung davon) verwendet werden, um aus einem beliebigen Text eine guid zu berechnen. Im Fall der Fragment-Zuordnung eröffnet dies interessante Möglichkeiten, denn nun kann an Stelle der abstrakten guid jeder beliebige Text als Schlüssel verwendet werden. So könnte z.B. eine E-Mail-Adresse überall direkt durch ihren Text identifiziert werden. Sinnvollerweise definiert man Namensräume oder Format-Muster, um aus bestehenden Daten einen Schlüssel zu generieren.

So muss als Teil der Konzeption der Enterprise Search Lösung für jede Datensatzart festgelegt werden, wie der Schlüssel für ihre Datensätze gebildet wird. Wichtig ist dabei, dass für die Schlüsselbildung die üblichen Regeln eingehalten werden: nur unveränderliche, selektive und eindeutige Daten. Für eine Person käme daher die Sozialversicherungsnummer in Frage (rechtliche Aspekte ignorieren wir hier der Einfachheit halber), nicht aber Vorname oder Adresse, da sich diese ändern (Adresse) oder in unterschiedlichen Varianten existieren können (Vorname).

Die eigentliche Schlüsselbildung kann dann idealerweise in jedem System eigenständig erfolgen, sodass weder ein vorgelagerter Datenaustausch noch eine Speicherung von Zuordnungen notwendig sind.

Die Zusammenführung

Ein System, das Apache Solr vorgelagert ist, sammelt sämtliche Fragmente und erstellt aus allen Fragmenten, welche zu einer gleichen Entität gehören, ein Solr-Dokument. Dieses wird dann in Solr gespeichert und für Abfragen, Suchen etc. verwendet.

Dieser Schritt kann je nach Umfeld und Anforderungen mehr oder weniger komplex ausfallen. In jedem Fall muss es aber die fachlich strukturierten Informationen aus den Fragmenten in eine für Solr geeignete Form bringen.

Die Verarbeitungskette umfasst daher folgende groben Stufen:

1. Ermitteln der zu aktualisierenden Datensätze (unter Berücksichtigung von Includes etc.)

2. Ermitteln aller Fragmente, die für einen Datensatz relevant sind (inklusive Includes etc.)

3. Berechnen der verschiedenen Sichten auf einen Datensatz anhand der Berechtigungen (wer darf was über diesen Datensatz wissen) und Erstellung je eines kompletten XML-Dokuments mit allen sichtbaren Fragmenten (als IndexDocument bezeichnet)

4. Für jede der ermittelten Sichten: Umwandlung des IndexDocuments in ein SolrDocument

5. Speichern der neuen SolrDocuments, löschen allfälliger alter SolrDocuments

Stufe 1 ist typischerweise durch eine Queue realisiert, welche bei Änderungen an Fragmenten gefüllt und dann durch einen Agenten abgearbeitet wird. Je nach Umfeld und Anforderungen kann es Prioritäten oder spezielle synchrone Verarbeitungen geben, damit die Daten in ausgewählten Fällen besonders schnell im Index verfügbar sind.

Stufe 2 ist eine relativ einfache Select-Operation auf der Fragment-Datenbank.

Stufe 3 hängt stark vom eingesetzten Berechtigungsmodell ab. Im Allgemeinen werden die Berechtigungen der verschiedenen Fragmente zusammengeführt und jeweils Schnittmengen gebildet, sodass für jede Berechtigungsstufe eine Sicht entsteht.

Beispiel eines zusammengesetzten IndexDocument mit den oben gezeigten Fragmenten. Dieses Dokument kann anschliessend verarbeitet werden.

Stufe 4 kann als XSL-Transformation realisiert werden, was bezüglich Erweiterbarkeit und Modularisierung gegenüber einer Lösung in Code sehr vorteilhaft sein kann: Ähnlich wie die Grammatik für die Abfragesprache (siehe Teil 1 der Serie) aus dem Domain Model generiert wird, kann dies auch für grosse Teile der Abbildung in Solr erfolgen. Zudem bietet XSLT die Möglichkeit, Regeln und Berechnungen in diese Stufe zu integrieren, so dass auch komplexe Aggregationen über Daten aus verschiedenen Systemen möglich werden. Aufgrund der vorhergehenden Sichten-Berechnung berücksichtigen diese Aggregationen zudem automatisch die Berechtigungen.

Beispiel eines berechneten SolrDocument mit den Feldern, die im Index effektiv abgelegt werden. Sichtbar ist, dass gewisse Informationen redundant in verschiedenen Formen und Feldern abgelegt werden, während andere Felder (z.B. die Zusammenfassung) zusammengesetzte Informationen aus mehreren Fragmenten enthalten.

Die Stufe 5 ist der eigentliche schreibende Zugriff auf Solr, um den Index zu aktualisieren. Der Zugriff erfolgt über das REST API, wobei zur Performance-Optimierung Operationen gebündelt werden.

Das Gesamtbild

Ähnlich einem Puzzle, das erst nach der Zusammenführung der einzelnen Teile zu einem stimmigen Bild wird, erlaubt das skizzierte Modell der Fragmente, die im Unternehmen oft versplitterte Information zu einem Gesamtbild zusammenzuführen und abfrag- und durchsuchbar zu machen.

Nachdem der Index ein vollständiges, aufbereitetes Abbild der Informationen aus allen Systemen enthält, kann beliebig gesucht und abgefragt werden. Eine Anwendungsmöglichkeit ist ein Abfragesystem wie in Teil 1 skizziert. Genauso spannend sind Google-ähnliche Suchanwendungen: Ich tippe ein paar Wörter ein und finde, was ich suche. Hier kommen die spannenden Elemente des Rankings und der Tokenisierung ins Spiel, die wir in einem weiteren Beitrag beleuchten werden.