Seite 4: Fazit

Inhaltsverzeichnis

Beide Tools sind dafür geeignet, komplexe Big-Data-Applikationen mit verschiedenen Arten der Verarbeitung umzusetzen. Für Spark spricht, dass es stark auf dem Markt vertreten, in vielen Hadoop-Distributionen integriert ist und mehrere große Firmen hinter sich vereinen kann. Innovationen kommen mit jedem neuen Release dazu. So ist nicht zu befürchten, dass Spark bald die Puste ausgeht. Es gibt aber durchaus einige konzeptionelle Altlasten, die das Framework mit sich herumträgt.

Flink scheint nicht nur dort auf einem solideren Fundament aufgebaut zu sein, auch die API, das Monitoring, in vielen Bereichen wirkt Flink einfach frischer. Durch seine europäischen Wurzeln kämpft es aber durchaus um Akzeptanz bei den großen, in Nordamerika ansässigen Firmen. Während etwa auf der Strata, der wohl bedeutendsten Big-Data-Konferenz, ein kompletter Track im Zeichen von Spark steht, ist Flink mit nur einem Vortrag vertreten. Dass das bei europäischen Konferenzen durchaus anders ist, macht aber Hoffnung. Auch dass bei der letztjährigen Flink-Forward-Konferenz in Berlin schon einige Produktionsszenarien zu der noch jungen Technik vorgestellt wurden, ist ein gutes Zeichen.

Die Entscheidung für oder wider eines der beiden Tools ist nicht einfach. Wenn man Real-Time Streaming braucht, aber auch Batch Processing, ist Flink eine ausgezeichnete Wahl. Ansonsten ist die Frage relevant, ob man auf die etablierte Technik setzt oder ein Early Adopter sein möchte. Die eingesetzte Programmiersprache kann durchaus auch eine Rolle spielen. Spark ist vorrangig in Scala geschrieben, und die Java API wird von der Scala API abgeleitet. Dass es nicht immer ganz einfach ist, von der mächtigeren Sprache abzuleiten, wird schnell deutlich. Einige Teile der API sind unschön.

Flink ist zu großen Teilen in Java geschrieben und hat eine deutlich stimmigere Java API. Bei Data-Analysten erfreut sich Python auch großer Beliebtheit – hier hat Spark eindeutig die Nase vorn. Zwar verfügt auch Flink über eine Python API, die von Spark ist aber deutlich ausgereifter.

Performance ist für viele Big-Data-Anwendungen ein zentrales Thema und soll hier nicht ignoriert werden. Bei der Batch-Verarbeitung gibt es einige klassische Benchmarks wie TeraSort, zwischen Flink und Spark [1] [2]. In den meisten ist Flink Spark bei der Laufzeit überlegen. Das wird hauptsächlich auf das stärkere Pipelining zwischen den Schritten zurückgeführt. Hier wird Spark mit den neuen APIs wohl aufholen können, aktuell fehlen hier aber noch belastbare Zahlen.

Bei der Stream-Verarbeitung gilt es, zwei Performance-Aspekte zu betrachten: Durchsatz (Records/s) und Latenz. In Sachen Latenz ist Flink Spark per Design überlegen, da Spark durch das Micro-Batching eine Latenz in Höhe des Batch-Intervalls hinzufügt. Beim Thema Durchsatz gibt es leider noch keine verlässlichen Benchmarks. In einem von Yahoo kommen beide auf die höchste getestete Performance von 170.000 Records/s. Eine verbesserte Variante der getesteten Flink-Applikation erreichte bei Twitter sogar 15.000.000 Records/s. Unklar ist hier, wie viel man durch Tuning bei Spark noch hätte verbessern können. Da Spark kein reines Streaming-Framework ist, gibt es generell mehr Streaming-Benchmarks, die Flink mit Apache Storm vergleichen. In ihnen schlägt Flink Storm regelmäßig um Größenordnungen; insbesondere wenn bei Storm Verarbeitungsgarantien (das sogenannte Acking) aktiviert sind. Hierfür hat Flink ein leichtgewichtigeres Konzept gewählt. Mit der kürzlich erschienenen Version 1.0 von Apache Storm hat sich in diesen Punkten viel getan. Es lohnt sich also, die Augen nach neuen Benchmarks offen zu halten.

Ein anderes Kriterium, das insbesondere in großen Firmen oft eine Rolle spielen kann, ist das Thema Support. Spark wird inzwischen in allen großen Hadoop-Distributionen mitgeliefert und unterstützt. Auch Databricks, die Firma hinter Spark, bietet Support an. Bei Flink wird Data Artisans wohl über kurz oder lang auch Produktionssupport anbieten, noch ist man allerdings auf die (allerdings sehr aktive und hilfsbereite) Mailingliste angewiesen.

Ein großer Vorteil, wenn es um die Evaluierung der Tools geht, ist, dass beide auf der gleichen Plattform laufen. Wer einen Hadoop-Cluster hat, kann Prototypen in beiden Tools entwickeln und so entscheiden, welches der beiden sich für den Einzelfall besser eignet.

Michael Pisula
hat Informatik an der Universität Passau studiert. Sein besonderes Interesse gilt den verteilten Systemen, insbesondere der immer wichtiger werdenden Big-Data-Welt. Als Senior Consultant bei TNG hilft er Kunden, wenn es um Big Data, Akka, Continuous Integration und allgemein um nichttriviale Probleme geht.

Konstantin Knauf
hat an der TU Darmstadt Mathematik und Informatik mit Schwerpunkt Machine Learning studiert. Als Software Consultant bei TNG Technology Consulting unterstützt er Kunden vorrangig in den Bereichen Big Data und Automatisierung. (ane)