Data Management
Unterstützung von Batch, interaktiv, Online & Streaming Use Cases
YARN
erlaubt gemischte Workloads, auch non-MapReduce Verarbei-tung (viele interaktive, einige Real-time, sowie Graph-Datenbank Verarbeitung)
Application Master Konzept isoliert Mandanten, damit bessere Security
Resource Manager verbessert Resourcennutzung im Cluster
Rolling upgrades für alle Versionen ab Hadoop 2.0. Möglichkeit für Benutzer zur Steuerung von Upgrades und Versionierung
Nutzung von HIVE Diensten auf Basis Apache TEZ- Interactive Queries
STINGER Phase 2 soll mehr SQL Funktionen liefern und und 20-80x schneller werden
Volles Daten Lifecycle
Management FALCON Data Lifecycle Management Framework – ermöglicht Tool Orchestrierung über XML Beschreibungssprache wie z. B.:
Datenimport Replikation
Scheduling und Koordination
Data lifecycle Policies = Datenauditierung und Lineage
Multi-cluster und SLA Management. SLA wird je nach Workload durch Scheduler in YARN gemanaged und kontrolliert
Data Lake Handling ( Data Lake Konzept – Alle Daten werden in einem Pool gesammelt und diese dann unterschiedlichsten Berei-chen für Analysen zur Verfügung gestellt, um die Daten-Silos in den Unternehmen aufzuheben und damit die Wertschöpfungs-kette der Analysen zu erhöhen)
Datenintegration/Real-time
Ingestion STORM ist derzeit kein Bestandteil von Hadoop 2.0.
Yahoo hat Verbesserungen zur besseren Ablauffähigkeit der Messa-ging Technologie in YARN implementiert.
Reliability
High availability Hohe Verfügbarkeit durch integrierte Hochverfügbarkeitsfunktionen in den Software-Komponenten
Disaster recovery Multi Data Center Disaster Recovery. AMBARI managed heute nur einen einzelne Cluster. Multi-Cluster Management muss durch Eigenentwicklung auf Basis der API Calls in die einzelnen Clustern implementiert werden
Rolling upgrades ohne Service
Unterbrechung Höchstverfügbarkeit der Verarbeitung auch bei rollierenden Versions-wechseln in der Software-Infrastruktur
Fallback capability nach Versions/
Release Wechsel Alle Konfigurationen werden in Ambari DB gespeichert. Heute funk-tioniert ein Zurückfallen auf die vorherige Version durch manuellen Prozess
HDFS Snapshots Point in time recovery über Snapshots Backup & recovery procedures Dokumentiert und verfügbar über Falcon
Bereich Kriterium Fähigkeiten von Open Source Hadoop 2.0
Managebarkeit
Automation der Initial Installation
& Upgrades Nach der Installation des Ambari Servers (automatisierbar), Auto-mation der Registration/Installation auf verschiedene Hosts über die Ambari API.
Support für Automation
Frame-works (Puppet, Chef) Automation eines vollen Deployments eines Hadoop Clusters auf der Basis eines unterstützten Betriebssystemes mit der Ambari API.
Ambari nutzt Puppet (standalone mode) End-to-end Management
Frame-work über das Hadoop Ecosystem Ambari föderiert das Hadoop Ecosystem in ein universelles Manage-ment Interface. REST API wurde durch ein gemeinsames Design von Red Hat, Teradata, Microsoft und Hortonworks entwickelt. REST API ermöglicht ISVs oder Unternehmen das Ersetzen von Teilen von Ambari durch ihre spezielle Lösung. Wurde bereits getan durch Tera-data für Viewpoint Integration und Microsoft für die System Center Integration. Wird auch genutzt im Savannah Projekt zum Deploy-ment von Hadoop auf OpenStack.
Integriertes Performance
Monitoring Performance Monitoring wird derzeit über Ganglia realisiert. Es wurde schon ersetzt durch HP OpenView und mit ähnlicher Strategie kann es mit anderen Lösungen wie Tivoli, BMC, …ersetzt werden.
Release & Patch Management
Support & Reporting Ambari erzeugt Report über verschiedene Versionen der jeweiligen Komponenten auf den Hosts und im Cluster
CMDB Support Durch die Registrierung auf den Hosts hat Ambari die Information über Hardware/Operating System/Rollen etc. Diese können über API’S ausgelesen und in einer CMDB Lösung abgespeichert werden.
Security
Granulare Rollen-basierte Zugriffskontrolle via Active Direc-tory , LDAP, Kerberos
KNOX
Vereinfachte Security für User und Administratoren
ermöglicht durchgehenden Zugriff und Single Application Feel
-Abstrahiert Benutzer von der Lokation ihrer Dienste Mandanten, Daten, Netzwerk und
Namensraum-Trennung in allen Diensten
YARN ermöglicht Kunden das Anfordern und Ablehnen von Contai-nern auf den spezifischen Hosts. Daten residieren auf jedem Node des Clusters, diese können auf den jeweiligen Hosts verschlüsselt werden. Namenode Föderierung kann konfiguriert werden –
»chroot« Umgebung.
Unterstützung für
Datenverschlüsselung Verfügbar über Filesystem Verschlüsselung oder auf OS Level oder über 3rd Party Voltage
Auditierbarkeit Alle Konfigurationsänderungen werden über Ambari in der Ambari DB gespeichert.
Tabelle 15: Bewertung von Betriebskriterien für Hadoop, basierend auf Hadoop 2.0
9.2 Betrieb einer unternehmensweiten Stream-basierten Real-time-Analytics-Plattform
Neben den Big-Data-Architektur-Elementen für Data at Rest, die die wichtigen Data-Store- und Analytics-Plattfor-men auf der Basis von Hadoop und die EDW-PlattforAnalytics-Plattfor-men umfassen, kommen in Big-Data-Einsatzfällen vermehrt Anforderungen zum Tragen, bei denen es um Data in Motion geht. Hier geht es um immensen Datenmengen, Real-time-Verarbeitung und -Analytics.
Hierbei kommen Streaming-Technologien zum Einsatz, die es ermöglichen, im Low-Latency-Bereich (im µs Bereich) auf Daten-Events zu reagieren, diese miteinander zu korrelieren, zu aggregieren, CEP sowie analytische Ope-rationen gegen strukturierte, semi- und unstrukturierte Daten vorzunehmen, z. B.:
Textdateien, Tabellenkalkulationen, Grafiken, Video- und Audioaufzeichnungen
E-Mail, Chat und Instant Messaging, Webdatenver-kehr, Blogs und Social Networking-Websites
Finanztransaktionen, Daten aus dem Kundenservice, Daten aus polizeilich eingesetzter Suchsoftware, Sys-tem- und Anwendungsprotokolle
Satellitendaten, GPS-Daten, Sensorprotokolle, Daten aus Kartenlesegeräten und Zugriffsdaten.
Stream-Computing-Plattformen sind von ihrer Eigen-schaft und Struktur her Applikationsserver-Container mit hoher In-Memory-Compute- und -Analyse-Fähigkeit234. In den Runtime-Containern der Stream-Computing-Plattform werden Daten über standardisierte Konnek-toren direkt aus dem Netzwerk, über Message Queues, über direkte Connectivity mit den API-Services der Social Networks, Anbindungen an Data Warehouses oder auch durch File Ingestion in die operative Auswertungslogik eingebracht.
Die immer weiter steigenden Anforderungen an die Aus-wertung von Events , die z. B. aus der steigenden Anzahl von Sensoren (Internet of Things), Mobile Apps sowie GPS-Informationen und Instrumentierung von Fahrzeugen und Maschinen stammen, machen es notwendig, diese Datenvolumina in Echtzeit zu analysieren und nur solche Daten in die Data-Store-Technologien zu übertragen, die eine zeitlich längere Relevanz oder weitere Verarbeitungs- und Analytics-Funktionen benötigen.
Aus diesem Grunde werden Streaming-Technologien zum einen als High-Volume Data Ingest Service und zur Vorverarbeitung zu den Big Data Stores eingesetzt. Zum anderen ermöglichen sie Real-time-Analysen, wenn im Einsatz Low-Latency-Anforderungen zu erfüllen sind.
Typische Anwendungsbeispiele bilden:
Financial Services:
Einsatz im Bereich High Volume Trading, Real-time Trade Monitoring und Fraud Detection.
Telekommunikation:
Einsatz im Bereich Real-time Call Detail Record Aus-wertung mit Mobile Advertisement, Fraud Detection, dynamische Netzwerk-Optimierung.
Security:
Einsatz im Bereich Real-time Video/Audio Überwachung
Ergebnisdaten, die zur Speicherung oder Weiterverar-beitung anstehen, werden über Standard-Konnektoren und Adapter in Richtung Enterprise Service Bus, Data Warehouse oder in ein Filesystem geschrieben.
Die Streaming Runtime Container selbst enthalten keine eigenen Persistenz-Layer über ihre In-Memory Speicher-bereiche hinaus.
An dieser Stelle sollen die operationalen Implikationen und Themenstellungen beispielhaft für die IBM InfoS-phere Streams-Plattform dargestellt werden, um die wesentlichen Optionen und Randbedingungen für den Einsatz einer Real-time- Analytics-Plattform zu skizzieren.
234 z. B. durch Einsatz von Text Analytics, statistischen Analysen, R-basierter Analytics und Operatoren zum Parsen, Filtern und Aggregieren von Daten
Physische Infrastruktur
Die leistungsstarke Verarbeitungsplattform, die die kom-plexen, kontinuierlichen Datenanalysen mit höchstem Durchsatz und schnellsten Reaktionszeiten ermöglicht, erlaubt einen Infrastruktur-Einstieg auf Basis von Einzel-servern, die auf eine praktisch unbegrenzte Anzahl von Rechner-Knoten hochskalieren kann.
Als Hardware-Infrastruktur für die Streams-Plattform dienen standardisierte x86 oder IBM Power Linux-basierte Systeme (vgl. Abbildung 64).
Innerhalb des Clusters können je nach Nutzeranforderun-gen unterschiedliche Hardware-AusprägunNutzeranforderun-gen betrie-ben werden. Streams verfügt über ein automatisiertes Deployment der Applikationen über den Cluster unter der Berücksichtigung der Kapazitätsanforderungen während der Ausführung.
Streams entscheidet automatisch zur Laufzeit, wo die einzelnen Streams-Applikationen und Operatoren ausgeführt werden. Hierfür werden Load-Balancing-Mechanismen und Verfügbarkeitsmetriken der Ausfüh-rungsplattform auf die sogenannten Processing-Elemente angewandt. Auf diese Weise kann z. B. die Ausführungs-umgebung dynamisch rekonfiguriert werden, um die kontinuierliche Verarbeitung der Datenströme im Falle von Server- oder Softwarefehlern aufrecht zu erhalten.
Daten-Haltung
Plattenspeicher in den Rechenknoten wird nur für Konfigurationsdaten, die Softwareinstallation und für das Shared Filesystem235 zur Konfiguration des Clusters benötigt.
Die Streams-Umgebung benötigt ein Daten-Manage-ment- und Sicherungskonzept, wie man es für Stan-dard-Applikationsserver und ihre Konfigurations- und Deployment-Umgebungen heutzutage in den meisten Rechenzentren etabliert hat.
Für die Herstellung einer Hochverfügbarkeitskonstella-tion nutzt Streams eine Recovery-Datenbank, um Failover von Services und Instanzen reibungslos und automatisch durchzuführen.
Daten-Zugriff
Streams-Instanzen und die Streams-Applikationen halten alle zur Ausführung notwendigen Daten In-Memory vor.
Externe Daten werden über Konnektoren und Adapter zugeführt bzw. aus der Streams-Applikation heraus in z. B.
Datenbanken, Message Queues oder Files persistiert.
Beim Design einer Streams-Applikation ist eine Ende-zu-Ende-Betrachtung der Laufzeitarchitektur zu beachten. Informations-Feeds und die ausgehenden
235 NFS oder GPFS
Abbildung 64: Typische Laufzeit-Umgebung einer Streams-Applikation
Daten-Volumina, die in Message Queues, Hadoop oder Data Warehouses gespeichert werden, müssen von ihrer Leistungsfähigkeit und ihrem IO-Verhalten an die zu erwartende Verarbeitungsgeschwindigkeit angepasst sein.
Die analytische Verarbeitungskapazität wird infrastruk-turell als Compute-Kapazität bereitgestellt und skaliert linear.
Streams-Processing-Anwendungen erzeugen sehr leicht Volumina im Bereich von Zehntausenden Events pro Sekunde. Hier bietet die flexible Architektur der Streams-Plattform einen sehr einfachen Streams-Plattformbetrieb.
Daten-Integration
Die Daten-Integration der Plattform geschieht durch standardisierte Adapter und Konnektoren236. Für spezielle Anforderungen können mit der Streams-Entwicklungs-umgebung eigene Adapter entwickelt werden.
Die Event-Verarbeitung erlaubt die Nutzung der folgen-den Toolkits für Analyse-Zwecke: Advanced Text Analytics, SPSS, R analytics, TimeSeries, Geospatial, OpenCV (Video), CEP, Industry toolkit (FIX).
IT-Sicherheit
InfoSphere Streams Runtime kann auf Security-Enhanced Linux (SELinux) Umgebungen mit den entsprechenden Security Policies ablaufen.
Für die Authentisierung von Benutzern auf der Plattform kann das Pluggable Authentication Module (PAM) oder ein externer Lightweight Directory Access Protocol (LDAP) Server eingebunden werden. Die Zugriffe der Benutzer und Administratoren auf die Applikationen und ihre Kon-figurationen werden durch ACLs gewährleistet.
Streams verfügt über ein integriertes Audit Logging, um alle Aktivitäten der Benutzer und Applikation nachzuwei-sen und nachvollziehbar zu machen.
Weitere Betriebskriterien
Die Operations Console der Streams-Plattform ermöglicht mehrere Optionen für das Monitoring und das Manage-ment der Applikationen.
Über die Console werden die Streams-Jobs gestart, die dann kontinuierliche Datenanalysen durchführen. Alle Applikationen sind über das integrierte Applikations-Repository sichtbar und können dort der Jobverarbeitung zugeführt werden. Eine Integration in andere externe Scheduler (UC4 ...) ist über Schnittstellen möglich.
Die Integration der Streams-Umgebung in IT-Monitoring-Systeme kann über die Streamstool-Command-Funktio-nalität einfach implementiert werden.
Die Operations Console erlaubt die Visualisierung der laufenden Applikationen und die Verbindungen zu den aktiven Datenquellen in der Verarbeitung.
Aus Sicht eines produktiven Einsatzes von Streaming-Technologien kann eingeschätzt werden, dass diese Umgebungen für den Betrieb sehr einfach und flexibel verwaltet werden können. Die Streaming-Systeme leben von der Parallelisierung der Compute- und Memory-Power heutiger Server-Umgebungen und lassen sich einfach in Cloud-basierte Umgebungen integrieren.
236 Beispiele sind JMS, REST, JDBC/ODBC zu allen gängigen relationalen DB-Systemen, TCPIP, Files, HTTP-, HTTPS-, FTP-, FTPS, RSS- Feeds etc.