Big Data und IT-Performance So zünden Sie bei Big Data Analytics den Turbo

Big Data zeichnet sich durch Volume (große Datenmengen), Velocity (schnelle Verarbeitung, im Idealfall in Echtzeit), Variety (Vielfalt von Datentypen und -quellen) und Veracity aus (Sinnhaftigkeit und Vertrauenswürdigkeit der Daten und der daraus abgeleiteten Ergebnisse). Diese Mannigfaltigkeit in ihrer Erscheinungsweise stellt besondere Anforderungen an die Planung und Steuerung von Performance und Kapazität.

Anbieter zum Thema

Vogel IT-Medien GmbH

QUNIS GmbH

Confluent Germany GmbH

Performance lässt sich im Zusammenhang mit Big Data nicht ohne die Berücksichtigung für Kapazität realisieren. Denn wenn der IT die Ressourcen ausgehen, ist es auch um die Leistung bald schlecht bestellt. Eine gute Planung verhindert Flaschenhälse und gute Monitoring-Tools verschaffen Überblick und Kontrolle.

Olav Strand, Director Central EMEA bei Splunk

Massendaten werden meist für Analysezwecke benötigt und diese Analyse soll möglichst schnell erfolgen. Die BI-Infrastruktur ist meist für die Anforderungen eines Data Marts oder Data Warehouses ausgelegt. Doch „üblicherweise sind Big-Data-Applikationen tausend Mal umfangreicher“, schreiben Dave Jewell und seine Kollegen von IBM, „außerdem erfordern sie viel kürzere Antwortzeiten als herkömmliche BI-Anwendungen.“ Aus diesen Gründen empfiehlt Olav Strand „Cloud-Optionen für elastische Rechnerkapazitäten und Kosteneffizienz, was das Speichern, Verwalten und Nutzen von Big Data anbelangt“. So lassen sich einige Probleme der Kapazitätsplanung lösen.

Sharding

Es ist auch von Vorteil, zum Mittel des „Database Sharding“ zu greifen. Dabei wird eine Datenbasis wie etwa eine Video-Datenbank in gleiche Stücke aufgeteilt und diese dann parallel auf verschiedenen Servern (mit CPU, RAM und Disk) verarbeitet. Weil die kleineren Stücke kleiner sind, lassen sie sich schneller verarbeiten und bewegen. Ein schöner Nebeneffekt: Die Ressourcen müssen aufgrund des koordinierten Ansatzes nicht um den Vorrang in der Behandlung konkurrieren. Es gibt keine Konflikte.

Scale-up

In einer großen verteilten Umgebung ist es normal, dass Komponenten nach Ablauf ihrer MTBF (Mean Time Between Failures) ausfallen. Man muss also entweder höherwertige Komponenten kaufen, die länger halten, oder weniger Komponenten nutzen und diese höher integrieren. Das wird von den Herstellern „konvergente Architektur“ genannt. Beispiele finden sich bei HP, IBM, Oracle und als SAP-HANA-Appliances. Eine weitere Aufwertung besteht darin, langsame Festplatte durch schnelle und robustere Flash-Memory-SDDs zu ersetzen. Sie verkürzen die Zugriffszeiten.

Scale-out mit Hadoop

Diesem Scale-up-Ansatz steht der zunehmende Scale-out-Trend gegenüber: Preisgünstige x86-Server werden parallel geschaltet und in einem Hadoop-Cluster wie in einem Filesystem verwaltet. Doch gerade diese Verwaltung muss im Hinblick auf Performance getrimmt werden. Das Tuning eines Hadoop-Clusters lässt sich unter Verwendung verschiedener Parameter vornehmen, die Hadoop mitbringt. Damit man diese Parameter nicht auf Befehlszeilenebene einstellen muss, stellen diverse Monitoring-Tools bedienungsfreundlichere Umgebungen bereit.

In-Memory-Verarbeitung

Eine mittlerweile bekannte Methode, eine Datenbank die hohe Geschwindigkeit von RAM und CPU nutzen zu lassen, ist die Verarbeitung im Hauptspeicher. Solch eine In-Memory-Datenbank arbeitet nahe an der CPU und kann deren Geschwindigkeit nutzen, um Algorithmen schneller ausführen und auf die Daten anwenden zu lassen. Dieser In-Memory-Zugriff erfolgt wesentlich schneller als auf Festplatte oder Flash-Speicher und erlaubt eine Anwendung jene kürzeren Antwortzeiten, die die Endanwender verlangen. Eine relationale Datenbank muss ihren Datenzugriff hingegen durch Anlegen eines Pufferspeichers (Cache) auf Festplatten beschleunigen.

In-Memory-Fallstricke

Dave Jewell und sein Team warnen allerdings vor einer Falle, in die so mancher HANA-Fan tappen könnte. Üblicherweise setzen In-Memory-Technologien Java-VMs ein, die auf der Anwendungsebene laufen. Diese JVMs verwenden Garbage Collection (GC), um RAM-Speicherplatz von Objekten, die nicht mehr genutzt werden, zurückzuholen. Um diese Aufgabe erledigen zu können, lassen sie die aktuelle Datenverarbeitung pausieren.

Hier liegt der Hase im Pfeffer: „Ist der Speicherraum einer 64-bit-JVM entsprechend groß, verhält sich die Garbage Collection auf unvorhersagbare Weise und kann ausgedehnte Pausen verursachen“, so Dave Jewell. „Dies ist für Datenanalysen mit hoher Geschwindigkeit oder gar die Rückgabe von Analyseergebnissen in Echtzeit nicht geeignet.“ Es gebe Tuning-Techniken, um dieses Problem umgehen. Auch verschiedene Produkte wie Terracotta BigMemory (jetzt bei Software AG) und die HotSpot VM umgehen dieses Risiko auf jeweils eigene Weise. Die GC-Technik entwickelt sich weiter. Der Nutzer sollte sich aber dieses Fallstricks bewusst sein.

Streaming

Eine weitere Herausforderung ist die ungeheure Menge von Daten, die Sensoren und die Maschine-zu-Maschine-Kommunikation liefern. Sensoren im Smart-Grid liefern in regelmäßigen Intervallen Beobachtungsdaten. Streaming-Systeme speichern diese unstrukturierten Daten kurz im Hauptspeicher zwischen, um sie auszuwerten, und verwerfen sie dann wieder. „Nicht die Daten an sich sind von Wert, sondern ihre Analyse“, gibt Wilfried Hoge von IBM zu bedenken. Und die Analyse muss nahezu in Echtzeit erfolgen, denn sie liefert den Mehrwert und sorgt für den ROI.

Das Netzwerk

Der Ausfall einer Netzwerkkomponente hat Auswirkungen auf mehrere Hadoop-Datenknoten. Als Folge muss eine Aufgabe neu gestartet oder mehr Aufgaben müssen auf die restlichen Knoten verteilt werden, wodurch die Ausführung länger dauert. Daher sollten Netzwerke auf Redundanz ausgelegt werden, sodass sich Aufgaben über mehrere Pfade und Knoten hinweg verteilen lassen.

Die Skalierbarkeit ist stets zu berücksichtigen. Software-defined Networking könnte bei entsprechenden SAN-Komponenten hilfreich sein. Auf jeden Fall ist es eine Überlegung wert, den Datenzugriffsteil eines Netzwerks vom restlichen Netzwerk abzutrennen, um diesen nicht zu überlasten.

Es ist nicht offensichtlich, aber schon eine kleine Umstellung in einem Prozess kann weitreichende Vorteile haben. Im bekannten ETL-Prozess (extract, transform, and load) braucht man beispielsweise nur den Load-Schritt VOR den Transform-Schritt zu stellen und hat dann den Vorteil, Daten nicht zweimal übers Netzwerk schicken zu müssen.

Herausforderung „Variety“

„Die meisten Big-Data-Projekte stoßen auf mehr Probleme aufgrund der Vielfalt der Datentypen als wegen des Datenvolumens“, berichtet Dave Jewell von IBM. Es ist zwar ein geschäftlicher Vorteil, möglichst viele Datenquellen für Entscheidungen heranziehen zu können. Doch für jeden Datentyp ist mitunter eine separate Software notwendig. Für die Textanalyse im Social-Media-Umfeld sind andere Tools nötig als etwa für die Gesichtserkennung von Überwachungsvideos. Üblicherweise werden diese unterschiedlichen Datentypen nicht auf der gleichen Plattform gespeichert und verändern sich obendrein ständig. Das bedeutet eine Herausforderung hinsichtlich Performance und Kapazität.

Dave Jewell gibt folgende drei Tipps:

• 1. Definieren Sie eine umfassende Taxonomie. Sie hilft Ihnen beim Design und erhöht die Nutzbarkeit des Big Data Systems.

• 2. Bestimmen Sie die vielfältigen Weisen, auf die Datenobjekte gleichen Typs im heterogenen Unternehmensnetzwerk dargestellt werden (Metadaten und Indizes helfen dabei).

• 3. Überwachen Sie laufend Datenänderungen und kontrollieren Sie neue Termini, mit denen sich Anwendungen auf das gleiche Datenelement beziehen. Das beseitigt Widersprüche und Inkonsistenzen.

Herausforderung „Veracity“

Der Aspekt der „Veracity“ betrifft ungesicherte oder ungenaue oder sogar potenziell inkorrekte Daten. Sobald Irrtümer und Widersprüche auftauchen, verlieren die Nutzer das Vertrauen in die Ergebnisse. Die ganze Lösung ist in Frage gestellt.

Daher ist es essenziell, die Daten zu reinigen und Prozesse zu implementieren, die die Gefahr „verunreinigter Daten“ minimieren. Dazu ist es nötig, die Verwendungszwecke im Unternehmen herauszufinden und festzulegen, ab welchem Grad die Qualität der Daten als „gut genug“ angesehen wird. Denn jede Reinigung kostet Zeit und verursacht Kosten und Aufwand.

Folgende Strategien im Hinblick auf Datenqualität empfiehlt Dave Jewell:

• 1. Definieren Sie Benchmarks und Kriterien für Datenqualität,

• 2. identifizieren Sie Schlüsselattribute für Datenqualität wie etwa Aktualität und Vollständigkeit,

• 3. Data Lifecycle Management und Compliance,

• 4. Metadaten-Anforderungen und -Verwaltung und

• 5. Klassifizierung von Datenelementen.

Dass Information Governance für Big Data von hoher Bedeutung ist, ergibt sich aus diesen Empfehlungen. Nur solche Daten, die vor Manipulation sicher sind, sind auch vertrauenswürdig. Und manche Daten, so zeigt der zusätzliche Aspekt des „Value“, werden schon nach kurzer Zeit obsolet, werden also nicht mehr benötigt und können gelöscht werden.

(ID:43068878)