Enterprise Tensorflow - Python vs. Java

Warum nicht immer Python verwenden?

TensorFlow und Python gehen Hand in Hand. Wenn wir also TensorFlow u.a. im Machine Learning (ML) verwenden, denken wir sofort an Python. Der größte Teil der TensorFlow-API ist nur in Python verfügbar. Wenn wir unsere ML-Modelle entwickeln und trainieren, gibt es so gut wie keine Alternative zur Verwendung von Python (Proof-of-Concept oder esoterische Ansätze außen vor gelassen). Abhängig von der Umgebung, in der unser Modell tatsächlich verwendet werden soll, sind jedoch andere Sprachen besser für die Ausführung unseres Modells geeignet, insbesondere wenn wir keine Python-Laufzeit installieren können oder wollen. (Zu Gründen, aus denen ein Python-basierter Ansatz möglicherweise nicht sinnvoll ist, siehe unten.) In Fällen, in denen Python nicht ohne weiteres verfügbar ist, lohnt es sich ins Gedächtnis zu rufen, dass die tatsächliche Implementierung des Computation Graph in TensorFlow in C ++ geschrieben ist, d.h. wir haben es mit nativem Code zu tun. Daher kann er im Rahmen der meisten anderen Sprachen ausgeführt werden. Für viele Sprachen bietet Google die nötigen Wrapper für das Ablaufen eines Modells an. Wenn die TensorFlow-Wrapper keine Option sind, besteht immer noch die Möglichkeit, die von uns in TensorFlow trainierten Parameter (z.B. die Gewichte des neuronalen Netzwerkes) in einem anderen ML-Framework zu verwenden, das leichter verfügbar ist. In den seltenen Fällen, in denen weder TensorFlow noch ein anderes Framework zur Verfügung steht, hilft es, dass Vorhersagen oft viel einfacher von Hand implementierbar sind als Training, sodass wir sogar die Möglichkeit haben, den Teil des Machine Learning Algorithmus, der die Vorhersagen aus Daten und Parametern liefert, selber zu implementieren. In späteren Posts schauen wir uns jede dieser Möglichkeiten nacheinander an.

Argumente gegen Python

Die Plattform, auf der wir unser ML-Modell ausführen möchten, könnte uns einschränken:

• Mobil: Sie können / sollten keine vollständige Python-Umgebung in Ihre native App einbetten
• Native Desktop App: Ein schlanker kleiner Installer ist gefragt.
• Embedded: Vielleicht gibt es nicht genug Ressourcen, um eine Python-Umgebung zu installieren (obwohl Python auf vielen „kleinen” Plattformen sehr gut läuft)

Die Rahmenbedingungen des Projekts können die Optionen beschränken:

• Kundenanforderungen (ob gerechtfertigt oder nicht) ermöglichen möglicherweise nicht die Verwendung von Python.
• Politische Gründe (man muss die richtigen Leute an Bord holen) schränken einen ein - das ist besonders in Großkonzernen der Fall.
• Zeitaufwendige Zertifizierungs- / Freigabeprozesse für jede neue Komponente, die noch nicht im Einsatz ist - wieder ein typischer Fall für große Unternehmen
• Schlüsselpersonen im Entscheidungsprozess sind dagegen - und alle Argumente scheitern
• Team- / organisatorische Bedenken: Das Team, das die Host-Software erstellt, in die das Modell integriert wird, unterscheidet sich von den Entwicklern des Modells, die “Python Leute” sind möglicherweise nicht für die gesamte Lebensdauer des Produkts greifbar

Es gibt weitere Vorteile, die die Verwendung von Python zwar nicht ausschließen, jedoch in manchen Fällen eine Nicht-Python-Lösung attraktiver machen:

• Abhängigkeiten auf ein Minimum beschränken
• Den build-Prozess einfach halten
• Den Installer einfach halten / den Deployment-Prozess vereinfachen
• Einfachere Updates
• Die Größe der Artefakte (Installer, WARs, etc.) auf ein Minimum beschränken
• Ihr möchtet vielleicht nicht mehrere Programmiersprachen in eurem Projekt verwenden
• Ihr mögt Python nicht (jeder Jeck ist anders)

Wann Java die bessere Lösung sein kann

Die obigen Argumente gelten für viele Python Alternativen. Im Rest dieses Posts und der folgenden Reihe werden wir uns auf Java speziell für Server-Anwendungen konzentrieren, insbesondere in Verbindung mit „Enterprise”-Frameworks. In direktem Bezug auf die obigen Argumente, hier einige Gründe warum Java manchmal eine besser Alternative sein kann: (da Softwareentwicklung eine komplizierte Angelegenheit ist, muss jeder Fall natürlich individuell beurteilt werden):

Plattformbeschränkungen

Mit Ausnahme von Android, wo Java sozusagen zu Hause ist, gelten die für Python geltenden Plattformbeschränkungen generell auch für Java (wir benötigen eine separate Laufzeitumgebung usw.). Da wir uns auf serverseitiges Java konzentrieren, betrachten wir den Android-Fall hier nicht. Auch ist Google stark in diesem Bereich aktiv (siehe Tensorflow Light), so dass sich für dieses Szenario anderenorts genug Informationen finden. Im Allgemeinen wird Java Ihnen bei Plattformbeschränkungen nicht helfen. Da wir uns jedoch auf die serverseitige Entwicklung konzentrieren, ist die Plattform zum Glück selten das Problem für uns. Server haben heutzutage mehr als genug RAM, Speicher und CPU-Leistung.

Rahmenbedingungen des Projekts

Dies ist der Bereich, in dem Java Türen öffnet. Die Zauberformel „Wir bieten Ihnen eine 100%ige Java Enterprise Lösung" öffnet die Tür für eine schnelle PO, größere Budgets und breite Akzeptanz. (Pro Tipp: Tragen Sie einen schönen Anzug, während Sie die Zauberformel aufsagen). Im Ernst: Java ist die am weitesten verbreitete Plattform in der Geschäftswelt, insbesondere für große Unternehmen wie Versicherungen, Banken, Rundfunk und Industrie. In diesen Umgebungen wird eine bewährte Technologie mit einem lebendigen Ökosystem, kommerzieller Unterstützung und einem großen potenziellen Arbeitskräftepotenzial (fast) immer die nächste coole RAD-Technologie übertreffen. Wenn also eine Richtlinie die Verwendung bestimmter Technologien erzwingt, sind die Chancen gut, dass Java (und bestimmte Java-Frameworks) darunter sind. Man trifft auch oft auf fest verwurzelte Teams, die sich jahrelang um ein IT-Projekt gekümmert haben und nur zögerlich neue Technologien annehmen und Ihre neuen und coolen AI-Projekte mit FUD torpedieren könnten. Die Java Enterprise Karte spielen zu können ist vielleicht das Ass im Ärmel dass zum Auftragsabschluss führt. Das vorhandene Team nutzen zu können um die tolle neue KI-Lösung nach ihrer Einführung in Gang zu halten - auch wenn das Team, das sie erstellt hat, schon über alle Berge ist - lässt Entscheider ruhig schlafen und wird Ihre Arbeit erheblich erleichtern.

Weitere Vorteile von Java gegenüber Python

Bisher haben wir hauptsächlich dargelegt, warum eine Java-basierte Integration eine gute Idee wäre, wenn bestehende Infrastrukturen / Teams / Organisationen bereits stark in das Java-Ökosystem investiert sind. Aber manchmal macht Java sogar Sinn für ein Grüne-Wiese-Projekt. Im Folgenden sind einige Punkte aufgeführt, die die Stärke von Java im Allgemeinen und für eine serverseitige Anwendung im Besonderen hervorheben. Wie immer kommen diese Meinungen mit einer Dosis persönlicher Präferenz. Java ist auch kein Allheilmittel und es gibt immer mehrere Wege, ein Problem anzugehen. Java ist - was die „Coolness" angeht - in den letzten Jahren etwas in Ungnade gefallen. Einer der Gründe dafür ist, dass überbordende Enterprise Architekturen oft mit Kanonen auf Spatzen schießen. Aber wie es so oft der Fall ist, kommen und gehen Programmier-Moden und als Antwort auf diese (wohlbegründete) Kritik hat sich in Java vieles verändert, was die Rahmenbedingungen für ein klassisches Java Enterprise Projekt verbessert hat. Java ist …

• schnell. Überraschend schnell. Ich habe es oft schon persönlich erlebt, wie sorgfältig händisch optimierter C-Code durch sauberen Java Code dank des JIT Compilers geschlagen wurde. Und obwohl Rechenleistung vergleichsweiße billig ist, wirkt sich eine Größenordnung mehr Effizienz im Vergleich zum neuesten coolen JavaScript, Ruby etc. Framework merklich auf die Server-Rechnung aus
• ausgereift. Insbesondere viele der üblichen Apache Projekte hatten Jahre, um sorgfältig getestet und angepasst zu werden und weißen eine beeindruckende Stabilität und Verlässlichkeit auf. Oft sehen neue, ausgefallene Frameworks auf den ersten Blick fantastisch aus, scheitern aber, wenn sie in Kontakt mit der Realität kommen.
• nicht so aufgebläht wie früher. Neue Frameworks ermöglichen oft einen RAD-Ansatz, wie man ihn eigentlich eher aus Ruby on Rails oder Django kennt. Man schreibt nicht mehr eine Woche lang XML für eine „Hello World" -Serveranwendung. Auch bringt uns Java 8 endlich funktionale Programmierung und Bibliotheken wie Guava erlauben einen gut lesbaren, verständlichen Code. Java wird zwar nie so elegant sein wie Haskell, aber die Dinge sind viel besser geworden.
• gut unterstützt. Die Dokumentation von Sprache, Tools und Bibliotheken ist in der Regel umfangreich, verständlich und aktuell.
• statisch typisiert. Ob dies für oder gegen Java spricht ist natürlich auch immer Frage des persönlichen Programmierstils.

Als aktuelle (2017) Randnotiz, meine aktuelle Empfehlung für neue Java Server Projekte ist:

• Java 8
• Eine bewährte SQL-Datenbank (z. B. PostgreSQL)
• JOOQ für die Persistenzschicht
• Ninja als Web-Framework (CXF, Spring etc. sind auch keine schlechte Wahl)
• Alle Hilfsbibliotheken, die einem das Leben erleichtern, insbesondere Guava

Mit diesem Stack macht Java-Entwicklung tatsächlich wieder Spaß - probiert es aus! Und natürlich gelten viele der oben genannten Punkte nicht nur für Java, sondern für viele andere JVM-basierte Sprachen. Die Inhalte der folgenden Beiträge lassen sich auf die meisten JVM-basierten Sprachen übertragen, die einfache Java-Interoperabilität ermöglichen, wie Kotlin, Scala, Clojure und andere.

Wie Java für Tensorflow nutzen?

Wenn ihr nach dieser Diskussion Java als Plattform für die Integration eines Tensorflow-Modells in eine Produktionsumgebung in Erwägung zieht, bleibt die Frage: Wie kann ich das am besten tun? Dies hängt wiederum von einer Anzahl von Faktoren ab. In den nächsten Blog-Artikeln werden wir die verschiedenen Aspekte einer solchen Integration diskutieren. Insbesondere schauen wir uns an:

• Wie bekommen wir die gelernten Parameter (oder den ganzen Graphen) vom Trainings-Code in den Server?
• Wie laden wir Daten in den Graphen und führen Vorhersagen durch?
• Wie kann man die clientseitige Schnittstelle für verschiedene Vorhersage-Szenarien gestalten?
• Wie sieht ein Build und Continuous Integration (CI) für ein solches Project aus?
• Wie sieht die Projektstruktur aus?

Auf diese und weitere Themen werden wir in den folgenden Artikeln eingehen.