Big Data: das Ende vom Hype und der Anfang vom Business
Nachdem die Gartner-Analysten den Hype-Zyklus rund um das Thema Big Data für beendet erklärt haben, stellt sich nun die Frage, warum Big Data in Deutschland weiterhin ein Akzeptanzproblem hat: Ist das Thema etwa doch nicht erwachsen genug oder wird einfach die Relevanz nicht gesehen?
- Thorsten Greiner
Nachdem die Gartner-Analysten den Hype-Zyklus rund um das Thema Big Data für beendet erklärt haben, stellt sich nun die Frage, warum Big Data in Deutschland weiterhin ein Akzeptanzproblem hat: Ist das Thema etwa doch nicht erwachsen genug oder wird einfach die Relevanz nicht gesehen?
Big Data ist noch nicht in vielen deutschen Unternehmen ein Thema. Liegt das an hierzulande fehlenden disruptiven Geschäftsmodellen wie bei Uber? Mangelt es an neuen, datengetriebenen Ideen, die sich Big Data realisieren lassen? Tatsächlich sind diese Fragen falsch gestellt – die wirkliche ist, welches Risiko ein Unternehmen eingeht, das Big Data nicht einsetzt. Nämlich das Risiko, dass seine Mitbewerber auf genau diese Unterstützung für ihre Geschäftsmodelle setzen. Dabei ist Big Data nur der "Enabler", der erweiterte Geschäftsmodelle praktikabel macht. Denn das Versprechen von Big-Data-Techniken wie Apache Hadoop ist dem Kern nach nicht so sehr das "Big", sondern vielmehr die Skalierbarkeit. Ein solches System kann mit den Anforderungen mitwachsen, ohne dass die grundlegende IT-Architektur zu ändern ist.
Neues Berufsbild Data Scientist:
Die Skalierbarkeit ermöglicht neue Ansätze in der Auswertung von Daten: ETL- (Extract, Transform, Load) werden durch ELT-Prozesse (Extract, Load, Transform), das strukturierte Data Warehouse durch einen "Data Lake" ersetzt, sodass Datenanalysen auf einer viel größeren Datenbasis erfolgen können. Neben der Berechnung von Kennzahlen/KPIs (Key Performance Indicators) auf dem Datenbestand wird auch die Gewinnung neuen Wissens zunehmend wichtiger. Die Anwendung von Methoden aus dem Bereich Statistik oder Machine Learning auf diesen Daten wird heute unter dem Begriff "Data Science" zusammengefasst.
Im Zuge der zunehmenden digitalen Transformation werden Big-Data-Techniken weiter an Bedeutung gewinnen und nicht selten alle Bereiche eines Unternehmens, von der Entwicklung über Marketing und Vertrieb bis hin zur Produktion, betreffen. Das kann helfen, Management-Entscheidungen datengetrieben zu treffen und die Produktivität signifikant zu erhöhen.
Technische Umsetzung
Wie lässt sich ein derartiges Szenario nun technisch umsetzen? Die Einstiegshürde ist denkbar niedrig – ein Hadoop-Cluster lässt sich heute auf Standard-Hardware oder auch in der Cloud in wenigen Stunden aufsetzen und für den Big-Data-Einstieg nutzen.
Hersteller wie Cloudera oder Hortonworks funktionieren analog zu dem, was Linux-Distributoren im Betriebssystemumfeld machen: Sie nehmen die Einzelprojekte des Hadoop-Ökosystems (z. B. Hive, Pig, Spark und Sqoop) und bauen daraus ihre Distributionen zusammen. Ein wesentlicher Bestandteil sind dabei die Cluster-Verwaltungstools wie Cloudera Manager oder Apache Ambari: Sie stellen die Installation, die Konfiguration und das Monitoring der Komponenten zur Verfügung. Und sie kommen in der Regel da zum Einsatz, wo ein Hadoop-Cluster auf eigener Hardware ausgerollt werden soll – typischerweise bei klassischen On-Premise-Infrastrukturen. Dabei sollten Firmen beachten, dass sie auch über entsprechend leistungsfähige Hardware verfügen, um In-Memory-Techniken wie Apache Spark nutzen zu können. Die Hardware stellt dabei einen nicht unerheblichen Kostenfaktor dar.
Ein Hadoop-Cluster lässt sich aber auch in der Cloud umsetzen: Hier übernehmen zum Beispiel Cloudera Director beziehungsweise Hortonworks Cloudbreak die Provisionierung und Installation des kompletten Clusters. Mit diesen Tools lässt sich ein Hadoop-Cluster unter Amazon Web Services (AWS), auf der Google Cloud Platform oder unter Microsofts Azure mit einem Klick einrichten. Ein Cluster in der Cloud eignet sich vor allem gut, um die Technik kennenzulernen und für den Einsatz im eigenen Unternehmen zu evaluieren. Allerdings sind hier Randbedingungen zu beachten – etwa der Schutz vertraulicher Daten.
Technische Reife
Hadoop ist anfänglich eher als Insellösung für eine spezialisierte Anwendergruppe gestartet worden, mit Lücken in den Bereichen Datensicherheit, Zugangskontrolle und Auditing. Zu Beginn konnten zum Beispiel in der Hadoop-Default-Konfiguration im Prinzip alle Nutzer auf alle Daten zugreifen. In dem Bereich hat Hadoop stark aufgeholt. Heute ist die Technik so ausgereift, dass ein unternehmensweiter Einsatz möglich ist. Das heißt: Die anfänglich nicht berücksichtigten Themen sind mittlerweile umgesetzt, und zwar so, dass sich höchste Anforderungen an Datensicherheit, Zugangskontrolle und Auditing im Betrieb realisieren lassen.
Hier kommen Komponenten wie Apache Knox und Apache Ranger zum Einsatz. Dabei geht es um zwei Ansätze: Der eine beruht darauf, die Authentifizierung im Hadoop-Cluster grundsätzlich auf den verteilten Authentifizierungsdienst Kerberos umzustellen. Wenn das erfolgt ist, können Zugriffe nur noch mit gültigen Kerberos-Tickets erfolgen. Darauf aufbauend kann sich Apache Ranger in die Hadoop-Komponenten einklinken und feingranulare Zugriffskontrollen zur Verfügung stellen. Der Ansatz lässt sich am ehesten mit Zugriffssteuerungslisten (Access Control List; ACL) zum Beispiel in einem Dateisystem oder mit Zugriffsrechten in einem traditionellen RDBMS vergleichen.
Apache Ranger besteht aus zwei Teilen: dem Access Manager, der eine Web-basierte Oberfläche für die Verwaltung von Policies bereitstellt, und Plug-ins für Hadoop-Komponenten, die diese Policies umsetzen. Über Letztere lässt sich der Zugriff auf Daten oder Funktionen gewähren oder verbieten. Beispielsweise könnte einer Gruppe von Nutzern der Zugriff auf Tabellenspalten in Hive verboten werden, die personenbezogene Daten enthalten.
Der andere Ansatz beruht darauf, Zugriffe auf einen Hadoop-Cluster nur über sogenannte Edge-Knoten zuzulassen. Hier nimmt dann Apache Knox die Rolle eines Proxy ein, der Authentifizierung und Autorisierung übernimmt. Dabei ist Knox architektonisch modular aufgebaut und bietet somit die Möglichkeit, im Laufe der Zeit noch mehr Dienste über den Knox-Server abzusichern. Damit er nicht selbst zum Engpass wird, ist er zustandslos implementiert und lässt sich dadurch etwa durch Vorschalten eines Load Balancer horizontal skalieren. Insgesamt erleichtert Knox damit das Leben für beide Seiten:
Hadoop-Administratoren müssen etwa SSL nur noch auf einem Server konfigurieren, durch die integrierte Anbindung von Identity-Management-Systemen entfällt das Anlegen von Benutzern, und das Verschleiern der Infrastruktur bietet weniger Angriffsfläche. Hadoop-Benutzer hingegen müssen sich nur noch eine URL und einen Log-in merken, um ohne Wissen um die Komplexität des Hadoop-Clusters hinter dem Portal direkt loszulegen.
Wichtige Themen wie Ausfallsicherheit und Redundanz sind ebenfalls in der Hadoop-Architektur adressiert. Sie sieht vor, dass einzelne Komponenten ausfallen können, ohne dass das Auswirkungen auf den Betrieb hat. Daten werden grundsätzlich redundant gespeichert – typischerweise auf mindestens drei Cluster-Knoten. Bei Ausfall eines Knotens werden gegebenenfalls auch neue Kopien der Daten erzeugt. Bei Berechnungen mit Map/Reduce oder Apache Spark sorgen Mechanismen wie ein automatischer Retry oder die spekulative Ausführung dafür, dass diese auch bei Ausfall einzelner Knoten weiter laufen. Auch Standarddienste wie Apache Flume, ein verteilt arbeitendes System zum Sammeln, Aggregieren und Transportieren großer Datenmengen, bieten immer Möglichkeiten, sie redundant zu konfigurieren. Die drei folgenden Business Cases zeigen nun Hadoop in der Praxis.
