Interview mit Vijay Bommireddipalli, IBM

„Spark ist eine Technologie, die wie Linux und Java alles durchdringt“

| Autor / Redakteur: Michael Matzer / Nico Litzel

Vijay Bommireddipalli ist der Leiter des IBM Spark Technology Center in San Francisco und arbeitet dort im Bereich Engineering.
Vijay Bommireddipalli ist der Leiter des IBM Spark Technology Center in San Francisco und arbeitet dort im Bereich Engineering. (Bild: IBM)

Apache Spark, ein Framework für die Verarbeitung von Big Data, ist mittlerweile das aktivste Projekt in der Open Source Community. Im Juni 2015 gründete IBM in San Francisco ein eigenes Technologiezentrum (TC) für Apache Spark. BigData-Insider hatte die Gelegenheit, ein Interview mit Vijay Bommireddipalli zu führen, dem Leiter des IBM Spark Technology Center.

BigData-Insider: Herr Bommireddipalli, warum sollte man Apache Spark anderen Echtzeit-Datenverarbeitungstechnologien vorziehen?

Bommireddipalli: Aus mehreren Gründen. Erstens: Es ist ein Open-Source-Projekt. Das ist sehr wichtig, denn deshalb hat kein einzelner Hersteller die Kontrolle darüber. Zweitens: Es hat seine Fähigkeit bewiesen, horizontal extrem gut zu skalieren. In China umfassen die größten Cluster 3.000 bis 5.000 Nodes. Jeder einzelne dieser x86-Nodes ist ziemlich groß und leistungsfähig. Das macht Spark für viele Leute attraktiv.

Drittens: Von Haus aus kommt Spark mit Machine Learning und Statistik-Algorithmen, die schon im Framework implementiert sind. Das war die Quelle der Inspiration des Konzepts für Spark. Während ein Algorithmus ausgeführt wird, müssen viele iterative Schritte abgearbeitet werden. Soweit es möglich ist, werden die Zwischenergebnisse dabei im Arbeitsspeicher gehalten. Das geht viel schneller als bei Hadoop, wo jedes Zwischenergebnis persistent auf Platte gespeichert werden muss. Hier sieht man in Spark enorme Vorteile.

Aber ist Apache Spark wirklich so wichtig, dass IBM zu Recht ein gesondertes Technologiezentrum gegründet hat?

Bommireddipalli: Durchaus. Spark ist eine Technologie, wie Linux und Java, welche das gesamte Feld der Big Data Analytics durchdringt. Deshalb wurde ähnlich wie damals das Technologiezentrum für Spark gegründet. Schon ab 2010 begannen die Nutzer damit, die verteilte Verarbeitung von Big Data mithilfe von Clustern aufzusetzen. Man startete mit geschlossenen, proprietären MPP-ähnlichen Frameworks, die auch IBM hatte, und setzte dies mit einer großen Bewegung rund um Apache Hadoop fort.

Ich war in einem Produkt-Team, das viel Hadoop verwendete. Wir stießen auf eine ganze Reihe von Einschränkungen im MapReduce-Paradigma. Jedes Mal wenn eine Aufgabe starten soll, dauert es eine Weile. MapReduce erledigte manche Dinge sehr gut, so etwa Parallelisierung und Skalierung für die Nutzer. Wir hatten aber den Eindruck, dass es sehr ineffizient implementiert worden war.

Deshalb suchten wir nach einem Framework, das die Antwort auf die Frage lieferte, wie wir die Abläufe beschleunigen könnten. Um 2012 und 2013 schauten wir uns Spark an. Nicht nur ich, sondern eine ganze Reihe weiterer IBM-Produktteams suchten nach genau solch einer Lösung. Schnell sahen wir kurze Antwortzeiten, denn es war ein In-memory-Framework. Die APIs waren wirklich sauber programmiert. Es hatte die besten Eigenschaften des Hadoop-Ökosystems und es löste einige von Hadoops Hauptproblemen.

Vor allem die lineare und langsame Weise der Batch-Verarbeitung.

Bommireddipalli: Das Konzept hinter Spark war von den AMPLab-Entwicklern in Berkeley wirklich gut durchdacht. Unsere IBM-Teams führten Spark ein. Auch auf der Führungsebene erkannte man, dass Spark keine kurzzeitige Mode war, sondern dabei half, ein paar echte Probleme zu lösen. Wir probierten Spark aus und das Management entschied, die Sache formeller zu etablieren, indem es das Spark Technology Center gründete.

Stellt das Technology Center eine bedeutende Investition seitens der IBM dar?

Bommireddipalli: Es ist eine enorme Investition. Die offizielle Ankündigung im Juni 2015 umfasste drei Bestandteile: eine zu den Menschen, eine zu Code und schließlich eine zum Investment. Die Kurzversion lautete: „Wir bringen weltweit 3.500 Forscher und Entwickler zusammen, die an Apache Spark arbeiten.“

3500?!

Bommireddipalli: OK, nicht jeder davon arbeitet am Spark-Core selbst. Aber es gibt etwas mehr als 30 Produktlinien, die auf Spark aufbauen. Mein Team besteht im Kern aus etwa 50 Personen, die an Spark selbst arbeiten.

Was war der strategische Gedanke hinter der Gründung des Spark Technology Center?

Bommireddipalli: Apache Spark soll in vielen IBM-Produkten als „Hauptausführungs“-Engine genutzt werden. Oder manche sind mit Spark integriert, weil sie eine In-memory-Verarbeitung der Daten anstreben.

Was genau ist hier Ihre Position?

Bommireddipalli: Ich leite die Engineering-Seite des Spark Technology Center. Aber es gibt auch eine Design-Seite, sodass IBM in der Lage ist, sowohl das Spark-Framework als auch die Benutzbarkeit zu verbessern. Wir haben außerdem sogenannte Committer, die Schreibrechte am Spark-Quelltext haben. In Open-Source-Projekten sind Committer sehr wichtig. Einige unserer Teammitglieder haben bereits mehr als 100, in manchen Fällen sogar mehr als 200 Beiträge zu Spark geliefert. Dies sind wirklich Experten.

Im Unterschied zu Committern gibt es weltweit mehr als 1.000 Leute, die zu Sparks Quellcode beitragen wollen, aber weniger als 50 Committer dürfen in den Spark-Quelltext selbst hineinschreiben. Somit können sie die Richtung lenken, in die sich das Spark-Projekt bewegt. Mein Team ist also ziemlich einflussreich. Seine Aufgabe besteht im Wesentlichen darin, zur Community beizutragen. Das bedeutet auf der anderen Seite, dass alle 30 verbundenen IBM-Produkte davon profitieren. Soweit ich weiß, sind wir das größte Team, das ausschließlich an Apache Spark arbeitet.

Wie sehen denn Ihre Beiträge aus? Ich könnte mir vorstellen, dass einer Ihrer Schwerpunkte Spark SQL ist.

Bommireddipalli: Unsere Schwerpunkte sind Machine Learning und SQL (Structured Query Language). Gemessen am Umfang der beigetragenen Codezeilen, sind wir einer der größten Contributoren für Machine Learning in Apache Spark.

Sie haben bereits das SystemML-Projekt beigesteuert.

Bommireddipalli: Diese Library ist einer unserer Kronjuwelen, den wir der Open-Source Community übergaben. Jahrelange Forschungsarbeit ist darin eingegangen. Während Apache Spark aus mehr als 800.000 Codezeilen besteht, hat SystemML nahezu 400.000.

Die Aufgabe von SystemML für Big Data besteht darin, etwas zu schaffen, was damals mit SQL für relationale Daten geschehen ist. Mit SQL können Nutzer Abfragen schreiben, ohne sich überlegen zu müssen, wie sie die Joins in der systemnahen Sprache C++ formulieren sollen. SQL umgeht diese Komplikation.

Bei SystemML war nun die Grundidee, anspruchsvolle Machine-Learning-Algorithmen auf ähnlich deklarative Weise zu realisieren. Wir schufen eine Untermenge der Sprache R und sagten, das ist die Sprache, in der man Algorithmen spezifiziert. Der Compiler kümmert sich um die Implementierung und die Parallelisierung etc. Der Compiler ist also so etwas wie SQL für Machine Learning. Das ermöglicht Berechnungen mit Code, der – sagen wir – nur 15 bis 20 Zeilen lang ist. Dieser Code könnte vom Compiler in tausend Zeilen Spark-Code übersetzt werden.

Läuft SystemML nur auf Apache Spark?

Bommireddipalli: Nein. SystemML entstand vor Spark. Man kann es zu einem Single-Node-Programm kompilieren, ebenso für Hadoop oder für Spark. Nach einem entsprechenden Compile-Flag-Wechsel wird eine der drei Runtime-Dateien generiert. SystemML ist inzwischen ein separates Apache-Projekt.

Aber auch Spark selbst entstand mit Machine Learning als Kerngedanke.

Bommireddipalli: Richtig. Apache Spark besitzt ML-Funktionen von Haus aus: SparkML, wofür wir derzeit der größte Kontributor sind. Wir betrachten diese Situation also nicht als eine Entweder-oder-Option, sondern bieten Nutzern das Beste aus beiden Welten. Es gibt ML-Algorithmen, die für bestimmte Zwecke geschrieben wurden, und wenn einer dem jeweiligen Nutzer besser gefällt, dann kann er auch diesen nutzen.

Aber SystemML bietet einen großen Vorteil: Wenn der Nutzer einen Algorithmus anpassen will, müsste er in SparkML den Code in der Sprache Scala umschreiben – er müsste also ein Systementwickler sein. In SystemML arbeitet der Nutzer hingegen mit einer Hochsprache und kann den Algorithmus so anpassen, wie es notwendig ist.

Sind ML-Algorithmen auf Spark schneller als auf Hadoop?

Bommireddipalli: Als wir SystemML-Code für Spark kompilierten, stellten wir eine Beschleunigung um den Faktor 300 gegenüber der MapReduce-Implementierung fest – mit der gleichen Anzahl von Nodes. In Machine Learning sind viele Prozesse repetitiv. Würde man sie auf Disk ausführen, wäre das hunderte Male langsamer. Das ist der große Vorteil mit Spark. Und das macht die Applikationen wie etwa Predictive Maintenance oder Betrugserkennung, die darauf aufsetzen, möglich. In technischer Hinsicht sehen wir Spark als das passende Vehikel dafür.

Die Community ist bei Spark besser vorgegangen als bei Hadoop. Sie hat es in einem einzigen kohärenten Release veröffentlicht und zugleich die APIs vereinfacht. In Hadoop muss man alles als Map & Reduce codieren, aber Spark besitzt Highlevel APIs – APIs wie etwa Filter. Aus der Sicht des Nutzers ist es viel einfacher, Spark-Code zu schreiben, denn er kann dies auf hohem sprachlichem Niveau tun.

Konnten Sie auch die Leistung von SQL erhöhen?

Bommireddipalli: Der Grund, warum wir SQL neben ML als Hauptvehikel gewählt haben, ist der, dass wir bei IBM über ein umfangreiches Wissen und große Kompetenz hinsichtlich SQL verfügen. Der Optimierer für SparkSQL heißt Catalyst und ist geradezu ein Baby im Vergleich zu den Compilern, die wir für DB2 etc. haben. Aber Spark brachte etwas Neues in seiner Infrastruktur, das wir für wertvoll genug hielten, um einige dieser Konzepte in den SparkSQL Optimizer v2 zu übernehmen.

Spark 2.0 [veröffentlicht im Herbst 2016] hat einen großen Schritt vorwärts gemacht, was die Unterstützung für SQL anbelangt. Die Version 2 ist viel schneller. TPC-DS ist einer der Standards für die Leistungsmessung: „Transaction Processing Council – Decision Support“ ist ein Benchmark für die Leistung von Datenanalyseanfragen. Wir wollten diese Leistung mit Spark v1.4 testen, aber es hat sich herausgestellt, dass nur 39 von 99 Abfragen ausführbar waren. Bis v1.6 drehte sich das Verhältnis um: 60 Abfragen bestanden den Test, 40 fielen durch. In Spark 2.0 bestanden alle 99 Abfragen den Test – eine drastische Verbesserung. Wegen dieser Anstrengung ist Spark heute in der Lage, es mit einer gestandenen SQL Engine aufzunehmen. Beispielsweise versucht mein Team derzeit, einen Benchmark-Test mit 100 Terabyte Daten auszuführen.

Liefern Sie noch weitere Beiträge außer SystemML und SQL?

Bommireddipalli: Viele Unternehmenskunden kommen zu uns und erzählen uns, was sie mit Spark tun und was sie gerne in Spark realisiert sähen. Das sind sowohl banale als auch sehr aufregende Dinge. Höchst notwendig ist etwa der Support für Kerberos [PKI-Verschlüsselung]. All diese sicherheitsrelevanten Aspekte werden aus Sicht eines Unternehmenskunden benötigt. Wir wollen Spark in Richtung Unternehmenseinsatz trimmen. Das bedeutet, Spark zu einer Mainstream- und Kerninfrastruktur zu machen. Man stelle sich Spark als Kernausführungskomponente für die Datenanalyse vor.

Beschäftigen Sie sich auch mit Virtual Reality, dem IoT, Künstlicher Intelligenz und Robotik?

Bommireddipalli: Ja, wir machen Datenvisualisierung mithilfe von Augmented Reality. Wir arbeiten zudem auf dem Feld der Robotik, an einer Klasse von Algorithmen, die SLAM genannt werden: „Simultaneous Localization and Mapping“. Das ist unter anderem für Drohnen-Technologie relevant. Wir nehmen SLAM und parallelisieren es auf Spark, damit Nutzer sehen, wie viele Raumpunkte Spark in kürzester Zeit erzeugen kann. Da gibt es einige Vorteile. Wir sind also an der vordersten Front im Internet der Dinge.

Was ist der Unterschied zwischen IBM BigInsights BigSQL und der SQL-Unterstützung für Apache Spark?

Bommireddipalli: IBM hat mehrere Produkte mit SQL-Unterstützung. Wir richten uns ganz nach der IT-Branche. Wenn es dadurch zu Überschneidungen kommt, ist das okay, denn meist entdecken wir später, dass beide Produkte prosperieren, z. B. DB2 on System z vs. DB2 on Distributed Infrastructure. Als wir seinerzeit Hadoop integrierten, gingen unsere Kunden nicht her und ersetzten ihre verteilten DB2-Systeme. Die Kunden erstellten vielmehr neue Anwendungsfälle, die sich mit Hadoop SQL und der Hadoop-Infrastruktur verarbeiten lassen.

Wollten die Kunden nur herausfinden, wie weit sie damit kommen können?

Bommireddipalli: Nun ja, es gibt immer noch einige DB2-Funktionen zur Transaktionsverarbeitung, an die Hadoop und Spark nicht heranreichen, wie etwa die ACID (AKID) Eigenschaften. Oder ein echtes Update – in Hadoop und Spark wird immer nur eine neue Kopie der Daten angelegt.

Hat es inzwischen einen Paradigmenwechsel gegeben?

Bommireddipalli: Ja. Bei BigInsights packten wir die DB2-Infrastruktur und den DB2-SQL-Compiler in die Komponente BigSQL und führten sie nativ auf Hadoop aus. Diese sind immer noch schneller und vollständiger im SQL-Support als der Rest der Branche. Und wenn Teile der Anwendungen auf Spark umgestellt werden, dann kann BigSQL bidirektional Daten mit Spark austauschen.

Das würde also die bestehende Hadoop-Unterstützung ergänzen?

Bommireddipalli: Ja. Stellen Sie sich ein kontinuierliches Spektrum vor. Sie haben DB2, das sehr schnellen Datenaustausch mit BigSQL auf Hadoop ermöglicht. BigSQL ermöglicht den Hochgeschwindigkeits-Datenaustausch mit Spark. Wir ermöglichen zudem die direkte Integration zwischen Spark und DB2. Der Nutzer soll Daten so nahtlos wie möglich verarbeiten können. Wir haben dafür das Projekt „CommonSQL“ geschaffen: Die gleiche SQL-Sprache wird über alle Systeme hinweg gesprochen. Wir wollen sicherstellen, dass die Kunden ihre Entwicklungsinvestitionen bewahren können.

Warum entscheidet sich Ihr Kunde für das eine oder andere?

Bommireddipalli: Der jeweilige Use Case des Kunden diktiert, ob die Datenverarbeitung auf DB2, Hadoop oder Spark erfolgt. Ein Beispiel: Wir haben Spark nativ auf z/OS implementiert. Der Grund: Unsere Kunden in der Finanzindustrie wollten nicht, dass ihre Daten ihre Plattform verlassen und sie ihre Geschäftslogik neu erfinden müssen. Nun können sie ihre ML-Algorithmen direkt auf System z, dem Mainframe, ausführen lassen. Aber wenn sie eine nicht so vertrauliche Datenmenge verarbeiten wollen, können sie dies auf x86- oder POWER-Servern tun. Die Varianten in den IBM-Produkten spiegeln also die Vielfalt in den Verwendungsfällen unserer Kunden wider.

Was ist IBM Data Science Experience?

Bommireddipalli: Unsere Implementierung einer Entwicklungsumgebung für Apache Spark nannten wir „Data Science Experience“ (DSX) und kündigten sie im Juni 2016 an. DSX ist im Wesentlichen eine Sammlung von beliebten Open-Source-Projekten und wir haben einen signifikanten Beitrag zu diesen Projekten geleistet. Registriert man sich für DSX, dann sieht man Spark, SystemML und alle anderen Tools in einer einzigen Entwicklungsumgebung. Wir haben dafür im September die entsprechende Methodologie DataFirst gelauncht. DSX stellt Nutzern von R und Python eine Umgebung zur Entwicklung von Data-Science-Anwendungen bereit.

Was ist IBM DataWorks, das im September 2016 angekündigt wurde?

Bommireddipalli: DataWorks ist jetzt eine Marke, kein Produkt. DSX ist sozusagen eine Benutzeroberfläche von DataWorks. Man wird in dieser Richtung noch sehr viel mehr sehen.

Kommentare werden geladen....

Kommentar zu diesem Artikel abgeben

Der Kommentar wird durch einen Redakteur geprüft und in Kürze freigeschaltet.

Anonym mitdiskutieren oder einloggen Anmelden

Avatar
Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
  1. Avatar
    Avatar
    Bearbeitet von am
    Bearbeitet von am
    1. Avatar
      Avatar
      Bearbeitet von am
      Bearbeitet von am

Kommentare werden geladen....

Kommentar melden

Melden Sie diesen Kommentar, wenn dieser nicht den Richtlinien entspricht.

Kommentar Freigeben

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

Freigabe entfernen

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Kontaktieren Sie uns über: support.vogel.de/ (ID: 44470610 / Infrastruktur)