Back to top

Konnektoren für Suchmaschinen erstellen ist schwere Arbeit

Ein aktueller Blick auf die Entwicklung von Konnektoren bei Search Technologies

Wir bei Search Technologies versuchen stets ideale Content-Konnektoren zu entwickeln. Die Arbeit ist schwer. Aber bereichernd. Und wir befassen uns jeden Tag damit.

In den letzten Jahren haben wir einige der komplexesten Contentquellen erfolgreich angeschlossen. Dazu gehören Legacy-Quellen wie Lotus Notes und eRooms, moderne SaaS-Quellen wie Box.com, Salesforce und Jive und Quellen großer sozialer Netzwerke wie SharePoint Online (Office 365) und IBM Connections.

Dabei haben wir viel gelernt.

Ich erinnere mich an ein Treffen mit den Entwicklern, die bei Search Technologies an den Konnektoren arbeiten, vor gut fünf Jahren. Damals hatten wir die ersten Konnektoren erstellt und waren dabei, unser Team zu erweitern. Also habe ich gesagt:

Es wird einfacher werden. Zurzeit ist jeder Konnektor noch Neuland. Für jeden Konnektor brauchen wir neue Methoden und neue Technologien, damit dieser effektiv arbeitet. Aber irgendwann werden wir einen Punkt erreichen, an dem sich die Konnektoren immer mehr gleichen. Es wird immer einfacher werden, neue Konnektoren zu erstellen, weil wir bereits alle verschiedenen Möglichkeiten gesehen haben und im Framework genug Möglichkeiten angesammelt haben, die Probleme anzugehen.

Damals hatte ich nicht damit gerechnet, wie vielseitig die Welt des Content Management wirklich ist. Immer, wenn man denkt, man hat alle Probleme gelöst, entwickelt jemand eine komplett neue Technologie, die auch uns zwingt, alles neu zu entwickeln. In letzter Zeit mussten wir die folgenden Probleme bewältigen:

  • Update-Token (geben an, welcher Content geändert wurde)
  • Datenbanken der Update-Token (separate Token für jede Art des Content und jede Websitesammlung)
  • Unvollständige Löschungen (manchmal werden Löschungen nur an übergeordneten Dokumenten vorgenommen, sodass wir die untergeordneten Dokumente durch eine rekursive Traversierung einer gespeicherten Hierarchie selbst löschen müssen)
  • Hybride Hierarchien (Update-Token für bestimmte Elemente, Snapshots für andere Elemente)
  • Plug-Ins für Content Management Systeme (oft erforderlich, um die Informationen zu Sicherheitsberechtigungen abzurufen, die benötigt werden)

Letzte Woche hatte ich wieder ein Treffen mit dem zentralen Ingenieursteam, wir haben eine Woche in Costa Rica verbracht und an der nächsten Stufe unseres Frameworks für Suchmaschinen-Konnektoren gearbeitet. Dies wird jetzt die vierte Strukturverbesserung des Konnektoren-Frameworks, seit wir 2009 angefangen haben, an Konnektoren zu arbeiten.

Wozu diese neue Strukturverbesserung? Ganz einfach: Wir haben in den letzten Jahren so viel gelernt, dass wir dieses Wissen in einem neuen Framework sammeln müssen, welches uns dann erlauben wird, bessere, schnellere, robustere und leichter testbare Konnektoren zu erstellen.

Zu den neuen Funktionen der Konnektoren, die wir Ende des Jahres veröffentlichen werden, gehören:

 

Leichter zu erstellende und zu aktualisierende Konnektoren

Code wurde vom Konnektor zum Framework ausgelagert.

Wir haben alle unsere Erkenntnisse aus der Arbeit mit Konnektoren in die Struktur des neuen Frameworks einbezogen, vor allem hinsichtlich der Art, wie die Konnektoren nach Aktualisierungen suchen und diese verarbeiten. Das bedeutet, dass bei der Erstellung von Konnektoren weniger Code notwendig wird, was wiederum bedeutet, dass die Konnektoren schneller erstellt und getestet werden können, was wiederum zu zuverlässigeren Konnektoren führt.

 

Verbesserte Skalierbarkeit und Leistung

Crawling wird linear skalieren, wenn Rechner hinzugefügt werden.

In früheren Versionen von Aspire wurde eine verteilte Kommunikationsmethode eingesetzt, die aber nie in das Konnektoren-Framework integriert wurde und nie wirklich hohe Leistung geliefert hat (durch eine Abhängigkeit von einer eher ungelenken Methode der Empfangsbestätigungen). Dieser alte Code wurde jetzt offiziell ausgemustert und wird in der neuen Version von Aspire nicht mehr vorhanden sein.

Das neue Framework wird von Anfang an über mehrere Rechner skalierbar sein. Crawler werden unabhängig von der Zahl der Rechner funktionieren und linar skalieren, wenn dem Cluster weitere Rechner hinzugefügt werden.

 

Automatische Elastizität

Skalierbarkeit wird automatisch vorgenommen, die Rechner müssen nur hinzugefügt werden.

Die Version 2.0 war ein riesiger Fortschritt, weil Aspire seit dieser Version Apache Zookeeper einsetzt, um die Crawler-Konfiguration zu verwalten und verteilen. Jetzt nutzen alle Aspire-Rechner im Cluster dieselbe Konfiguration. Eine Änderung an einem Rechner wird automatisch auf allen Rechnern wiedergegeben.

Dasselbe machen wir jetzt mit den Daten des Crawlers. Wir werden ab sofort einen NoSQL-Server nutzen, um den Status des Crawlers festzuhalten, sodass verteiltes Crawling in großem Umfang möglich wird. Damit können zusätzliche Rechner hinzugefügt werden, die sich dann automatisch mit dem Cluster verbinden, alle Konfigurationen herunterladen, Crawlaufträge vom NoSQL-Server abrufen und mit dem Crawling anfangen.

 

Kein Single Point of Failure

Keine komplexe Systemkonfiguration, die einen Single Point of Failure bieten könnte. Nur ein Cluster mit gleichwertigen Rechnern.

Eine weitere coole Funktion des neuen Frameworks ist, dass es ohne einen Hauptrechner auskommt. Der gesamte Systemstatus wird im NoSQL-Server festgehalten, alle Crawler arbeiten zusammen, um die Crawlaufträge abzuarbeiten und Content einzufangen.

Damit werden Konfiguration und Einrichtung erleichtert. Alle Aspire-Knoten sind komplett gleichberechtigt. Jeder Knoten kann jede Funktion vornehmen (Start, Stopp, Pause, Fortsetzen, Statistiken usw.) Jegliche Konfiguration ist über den Zookeeper geteilt. Es gibt keinen Hauptrechner oder untergeordnete Arbeitsrechner, die eine spezielle topologische Konfiguration erfordern.

 

Verteiltes Scannen

Alle Teile des Prozesses sind jetzt verteilt, in Threads angeordnet und parallel geschaltet.

Scanaufträge (die Aufträge, die Verzeichnisse und Listen von Dokumenten für die Crawler abrufen) sind am schwersten zu verteilen. Unsere neue Architektur behandelt diese Scanaufträge nun wie jeden anderen Auftrag, sodass mehrere Teile der Contentquelle automatisch aufgeteilt und von mehreren Rechnern gleichzeitig gescannt werden können. Dies funktioniert für die meisten Konnektoren und Crawlerarten automatisch.

 

Keine Dateifreigaben, keine lokalen Datenbanken, mehr Stabilität

Der gesamte Speicher wurde in einen gut unterstützten NoSQL-Server ausgelagert.

Eine Schwachstelle der früheren Architektur war, dass Snapshots und Crawler-Status in Dateien und lokalen Datenbanken (auf physischen Festplatten) gespeichert wurden. Das führte dazu, dass diese Dateien und lokalen Datenbanken auf freigegebenen Laufwerken liegen mussten, damit alle in das Crawling involvierten Rechner auf diese zugreifen können. Diese Dateien und lokalen Datenbanken waren die Quelle für fast alle Stabilitätsprobleme, die mit Aspire aufgetreten sind.

Dieser Crawler-Status wurde nun auf einen geteilten NoSQL-Server ausgelagert. Das bedeutet, dass jetzt der professionelle NoSQL-Server (inklusive Backup, Replizierung und Skalierbarkeit) für alle Aspekte des geteilten Status zuständig ist. Damit wird die Architektur deutlich stabiler.

 

Verbesserter Widerstand gegen Hardwareinstabilität

Zu jeder Zeit können beliebig viele Rechner heruntergefahren oder neu gestartet werden.

Da der gesamte Status auf dem NoSQL-Server aufbewahrt wird (einschließlich aller Aufträge, Queues und Snapshot-Informationen) kann jeder Rechner zu jeder Zeit heruntergefahren werden, ohne dass es zu Datenverlusten kommt. Wenn der Rechner wieder hochgefahren wird, macht er da weiter, wo er aufgehört hat. Wir könnten sogar das gesamte System herunterfahren, der Crawler würde einfach seine Arbeit nahtlos wieder aufnehmen, sobald das System wieder gestartet wird.

Diese Art der Widerstandsfähigkeit wird in modernen Cloud-Umgebungen benötigt, in denen Rechner von Amazon, Microsoft oder Google zu jeder Zeit heruntergefahren oder neu gestartet werden können. Wenn so etwas mit der neuen Architektur passiert, wird die Arbeit einfach später dort wieder aufgenommen, wo sie unterbrochen wurde.

 

Transparenz

Der vollständige Fortschritt und aktuelle Status des Crawlers kann zu jeder Zeit eingesehen werden.

Dadurch, dass der Status auf dem NoSQL-Server gespeichert ist, wird eine nie dagewesene Transparenz ermöglicht, mit Einblicken in den aktuellen Fortschritt der Rechner. Durch einen Blick auf den NoSQL-Server kann man erkennen: Die Zahl der Verzeichnisse (wartend, abgeschlossen oder in Arbeit), die Zahl der abzurufenden Dateien (wartend, abgeschlossen oder in Arbeit) und alle Informationen der Snapshots (die gesamte Hierarchie der Elemente und das letzte Modifikationsdatum für jedes Element).

Diese Transparenz erleichtert es, die Crawler und Konnektoren zu überwachen und eventuelle Bugs aufzuspüren.

 

Master-Benutzerdatenbank = Sicherheitsüberwachung

Ein einzelner Ort, an dem alle Benutzerinformationen über alle Systeme gespeichert werden.

Ab sofort werden alle Informationen zu Gruppenmitgliedschaften eines Benutzers zusammen gespeichert (nicht in separaten Dateien wie bisher). Das bedeutet, man kann einen Aspire-Benutzer abrufen und alle seine Gruppen in allen Contentquellen (sowie später auch andere Benutzereigenschaften) gesammelt in einem einzelnen Objekt sehen.

Wir nennen dies die „Master-Benutzerdatenbank“. Der Gedanke dabei ist, eine einzelne Master-Datenbank zu erstellen, in der alle Eigenschaften und Sicherheitsinformationen eines Benutzers aus dem gesamten Unternehmen und aus allen Contentquellen gesammelt und aktuell gehalten werden. Jegliche Änderungen an Benutzerinformationen im Unternehmen können damit nachverfolgt und überwacht werden, sodass Änderungen an Sicherheitsberechtigungen leicht erkannt werden können.

Man stelle sich nur vor: In der Zukunft wird Aspire alle Änderungen an den Sicherheitsberechtigungen eines Benutzers nachverfolgen. Jegliche Änderungen an Gruppenmitgliedschaften oder Zugriffsrechten für alle Systeme und jeglichen Content. Hört sich doch gut an, oder?

 

Abwärtskompatibilität

Alte Konnektoren werden auch im neuen Framework noch funktionieren.

Das neue Konnektor-Framework wird eine (moderate) Strukturverbesserung für die Konnektoren erfordern. In der Zwischenzeit werden die alten Konnektoren aber auch im neuen Framework noch weiter funktionieren. Diese Funktion ist wichtig, weil wir sehr viele Konnektoren anbieten.

 

Ankündigung: Konnektoren-Library

Uns erreichen immer mehr Anfragen zu Konnektoren, die außerhalb des Aspire-Frameworks genutzt werden können. Wir bevorzugen natürlich das Aspire-Framework, aber wir haben auch kein Problem damit, wenn jemand unsere Konnektoren in einem anderen Framework nutzen will.

Daher vereinfachen wir die Schnittstellen für unsere Konnektoren, sodass alle Konnektoren dieselben AbstractScanner- und AbstractFetcher-Schnittstellen unterstützen. Damit können die Konnektoren leichter programmiert und getestet und einfacher in externen Frameworks für die Content-Verarbeitung eingesetzt werden. Als Beispiel haben wir eine Demonstration des Einsatzes von Aspire-Konnektoren in "Kettle", dem Open-Source-Framework für Datenintegration von Pentaho, erstellt.

 

Gute Konnektoren zu erstellen ist schwere Arbeit

Gute Konnektoren zu erstellen ist schwere Arbeit, die kaum jemand ordentlich wertschätzt. Jeder Konnektor ist anders und erfordert eine einzigartige Lösung. Dies wird noch komplexer, weil alle IT-Umgebungen in Unternehmen unterschiedliche Netzwerk-Topologien nutzen, unterschiedliche Content-Dimensionen, unterschiedliche Funktionen und unterschiedliche Sicherheitsstrukturen.

Aber wir bleiben am Ball und entwickeln einen Konnektor nach dem anderen, lösen jedes Problem, das auftritt, verbessern die Leistung, versuchen die bestmögliche Abdeckung, höchstmögliche Leistung und maximale Zahl von Funktionen zu bieten – in enger Zusammenarbeit mit unseren Kunden, um die Konnektoren zuverlässig in die Produktionssysteme einzubinden.

Das ist uns wichtig, weil Konnektoren von entscheidender Bedeutung sind. Denn ohne Daten kann es auch keine Suche geben. Wenn man die Daten also nicht in die Suchmaschine bekommt, bringt die beste Suchmaschine nichts.

 

Ein neues Zeitalter der Konnektoren für Suchmaschinen

Aber es gibt auch große Erfolgserlebnisse. Unser zentrales Programmiererteam umfasst inzwischen fünfzehn Ingenieure, die alle von unserem neuen Framework begeistert sind. Wir hoffen, dass wir eine frühe Version schon am Ende des Jahres fertig haben. Dieses neue Framework wird alles verbessern, die gesamte Produktionskette unserer Konnektoren.

Search Technologies hat einen großen Schwerpunkt auf Konnektoren gelegt, sowie darauf, das Problem der Erfassung unstrukturierter Daten zu lösen. Daran arbeiten wir Tag und Nacht. Allerdings ist uns natürlich auch klar, dass dieses Problem nie vollständig „gelöst“ werden kann. Es ist ein permanent fortlaufender Prozess.

Wird es also in ein paar Jahren wieder eine neue Strukturverbesserung geben? Natürlich! Denn das gehört dazu, wenn man voll hinter einer Sache steht: Konstante Entwicklung und Verbesserung und ständige Arbeit daran, die Dinge noch besser zu machen.

-- Paul

0