Ist Data Science in Deutschland größtenteils noch in den Kinderschuhen?

[Peter_2498]

Hallo,

ich selber studiere noch im Master Mathematik(Vertiefung in Optimierung und maschinellem Lernen) und so langsam muss ich schauen, wohin ich will. Berufe im Bereich der mathematischen Optimierung sind eher seltener, dafür weiß man dort ungefähr auf was man sich einlässt. Data Science hingegen scheint mir heute irgendwie alles zu sein, was in einem (unter Umständen entfernten) Sinne mit Daten zu tun hat und das kann ja gefühlt alles sein...

In vielen Diskussionen, die ich darüber gelesen habe, wurde oftmals sowas gesagt wie: In 95% der Fälle ist aktuell "Data Science" = stupides "Datenrumgeschiebe", wo auch jemand komplett fachfremdes diese Arbeit übernehmen könnte. Hat also so gut wie nichts mit der Vorstellung von Data Science zu tun. Ich frage mich inwiefern es für mich Sinn macht, zu versuchen in dieser Sparte Fuß zu fassen.

Zurzeit scheint es mir irgendwie so wie mit dem Thema IT-Sicherheit. Leute, die das an der Uni machen, lernen da die ganze mathematische Theorie hinter Kryptographie und weiteres theoretisches Zeug über Verschlüsselungen. 99% der IT-Security Berufe sind aber im Vergleich dazu trivial...da prüft man dann irgendwelche ISO-Normen, was vielleicht nicht ganz so interessant ist für viele.

Wie sieht Data Science in Deutschland gerade aus und wie seht ihr die praktische Zukunft von Data Science? Wird dieses "echte" Data Science auch in naher Zukunft FAANG, Uni-Forschern und paar Auserwählten vorenthalten bleiben?

Außerdem war folgendes auf einer der Vorlesungsfolien für Data Science an unserer Uni:
Even Harvard Business Review calls the role of a data scientist as "the sexiest job of the 21st century"

 

[gymfan]

Wie Du schon schreibst, kann Data Science alles bedeuten, was irgendwie mit dem Versuch zusammen hängt, aus Daten Erkenntnisse zu erzielen. Damit könnte man auch KI-Experten dazu zählen, die für KI-Systeme die passenden Trainingsdaten auswählen und die Systeme darauf trainieren, kundenspezifisch mit diesen Systemen Erkenntnisse erzielen zu können.

Data Science ist ein interdisziplinäres Wissenschaftsfeld, welches wissenschaftlich fundierte Methoden, Prozesse, Algorithmen und Systeme zur Extraktion von Erkenntnissen, Mustern und Schlüssen sowohl aus strukturierten als auch unstrukturierten Daten ermöglicht

Wenn ich mal dreist die Definition von Wikipedia nehme, dann ist das bei uns am Standort (Pharma/Biotechnologie) seit über einem Jahrzehnt ein Mix aus Kollegen, die sich sehr gut mit den IT-Grundlagen von Reporting auskennen (also dem Zusammentragen von Daten aus allen möglichen Quellen und der Kombination/Präsentation dieser Daten in irgendeiner Form) und den Fachexperten aus Forschung und Produktion, welche die Daten wirklich interpretieren können.

Bis auf wenige Ausnahmen (Zufallstreffer der ITler oder Kollegen, die von der Produktion in die IT gewechselt haben) ist bei uns aus der IT/dem Reporting niemand in der Lage, fachlich fundiert (neue) Erkenntnisse aus den Daten zu ziehen. Sowas gelingt noch nicht einmal den IT-Kollegen, die Chemie oder Bioinformatik studiert haben und damit zumindest grob die biochemischen Prozesse hinter den Daten kennen.

Irgendwo "dazwischen" schweben für mich dann Firmen wie Palantir die vorgeben, mit irgendwelchen Algorithmen und dem Zusammenwürfeln der Datenquellen Schlüsse aus diesen Daten ziehen zu können (vermutlich mit den in Wikipedia erwähnten wissenschaftlichen fundierten Methoden). Wie gut das funktioniert, hängt wohl auch von der Struktur der Quelldaten und der Fragestellung ab. Je spezifischer die Fragestellungen werden, um so schwieriger ist es, aus unbekannten oder unstrukturierten Daten die richtigen Schlüsse ziehen zu wollen. Auch da muss der Data Scientist erst einmal Struktur in die Daten bringen oder er muss aus den u.U. übermäßig vielen Antworten des IT-Systems die plausibelsten heraus filtern, um diese mit den Fachexperten zu diskutieren.

Wieviel Zukunft das ganze bei uns am deutschen Standort hat, wird sich zeigen. Durch Harmonisierung der weltweiten Produktion wird es vermutlich in produktionsnahmen Bereichen immer mehr in die globalen IT/Data-Gruppen wandern, die Forschung bleibt aber am Standort, womit die Arbeit vermutlich nicht ausgehen wird.

 

[Rickmer]

Fast alles was ich von Data Science (tatsächliche Anwendung / Umsetzung) verstehe, habe ich diesem Vortrag gelernt:

YouTube

An dieser Stelle steht ein externer Inhalt von YouTube, der den Forumbeitrag ergänzt. Er kann mit einem Klick geladen und auch wieder ausgeblendet werden.

YouTube-Embeds laden

Ich bin damit einverstanden, dass YouTube-Embeds geladen werden. Dabei können personen­bezogene Daten an YouTube übermittelt werden. Mehr dazu in der Datenschutzerklärung.

YouTube-Embeds laden

Datenschutzerklärung

 

[_killy_]

@ascer als unseren Data Scientisten kann ja auch mal seine Meinung beisteuern.

Ansonsten sehe ich das Thema in Deutschland in der Breite noch völlig in den Kinderschuhen, was unterschiedliche Gründe hat:
-> weiterhin auch in größeren Unternehmen eine völlig zersplitterterte IT Landschaft - ja es gibt DWHs, aber hier sind nicht wirklich alle Vorsysteme angebunden

-> vorhandene Daten haben wenig Potenzial für DataScience Untersuchen, da bisher immer sehr Datensparsam vorgegangen wurde (Speicherplatz kostet Geld)

-> Datenqualität ist eher mittelmäßig ... es braucht ja nicht so viele Abweichungen in der Datenqualität, so dass irgendwelche Untersuchen auf einmal diese Datenqualitätsabweichungen als Finding haben

-> man kann Data Science und fachliches Know How zu den Daten schlecht trennen -> ich hatte mit Data Scientisten zusammengearbeitet und denen dann doch das fachliche Modell komplett erklärt, sonst kommt die Untersuchung zu den Ergebnissen, die eh allen klar ist, wirkliche Insights waren somit eher fachlich getrieben

-> DSGVO ... sehr sehr leidiges Thema, aber in Deutschland darfst du halt nicht sehr viele Daten von deinem Kunden verknüpfen und darauf Auswertungen machen, du darfst nur maximal die Daten speichern die zwingend für das Vertragsverhältnis notwendig sind - nicht mehr!


Selbst der Automotiv Bereich finde ich an der Stelle unattraktiv - aber aus Kundensicht. Die Fahrzeughersteller übernehmen keinerlei Haftung für Schäden, die während der autonomen Fahrphase entstehen. Dann muss ich als Fahrer doch die ganze Zeit auf den Straßenverkehr achten. Mehr als eine nette Einparkhilfe würde ich somit als Kunde nicht nachfragen wollen.

Eine breite Nachfrage bzgl. Jobs die sich mit Daten befassen:
-> BI Consultants
-> Datenmodellierer
-> Data Engineers
-> Datenqualitätsmanager
-> Data Architects
...
Somit eher alles um den Auf- und Ausbau von DWHs und Datenkonsum aus den aufgebauten DWHs.

 

[uincom]

-> DSGVO ... sehr sehr leidiges Thema, aber in Deutschland darfst du halt nicht sehr viele Daten von deinem Kunden verknüpfen und darauf Auswertungen machen, du darfst nur maximal die Daten speichern die zwingend für das Vertragsverhältnis notwendig sind - nicht mehr!

Nö.

 

[Skysnake]

Ist halt die Frage was man sich darunter vorstellt.

So Dinge wie bei Facebook, Google und Co gibt es hier eher nicht.

Was es aber gibt sind technische Analysen. Meine Erfahrung ist aber, dass die Leute sich viel viel viel zu viel dadurch versprechen. Klar findet man auch mal die Stecknadel im Heuhaufen, aber dann ist das sehr oft einfach über Korrelation bzw Anomalie Detektion erzeugt.

Also im Prinzip sehe ich nur recht einfache Statistik Sachen plus Domänen Kenntnisse als Grundlage und dazu GANZ viel Datenaufbereitung um das Zeug überhaupt nutzen zu können.

Ist bei "Big Data" auch immer so ne Sache. Ich finde es ja immer putzig, wenn Leute mit 10GB Daten daherkommen und das dann Big Dats nennen...

Für mich ist das eigentlich erst Big Data wenn ich in den Bereich von TB an Daten gehe.

Aber hey, viele haben halt auch keine Ahnung wie man effizient mit Daten umgeht und nehmen Python oder gleich Juniper Notebooks und arbeiten interaktiv....

Die Realität ist meiner Meinung nach leider meist sehr ernüchternd...

 

[TomH22]

Vorab: Ich bin kein Data Scientist, und habe auch nur sehr oberflächliches Wissen über dieses Thema. Aber ich arbeite in einem Unternehmen, das Kunden u.A. Produkte und Beratung mit dem Label "Data Science" anbietet.

Wie sieht Data Science in Deutschland gerade aus und wie seht ihr die praktische Zukunft von Data Science? Wird dieses "echte" Data Science auch in naher Zukunft FAANG, Uni-Forschern und paar Auserwählten vorenthalten bleiben?

Wir hatten hier neulich eine ähnliche Diskussion von jemanden, der generell von dem Unterschied zwischen Theorie und Praxis enttäuscht war.
Grundsätzlich gibt es zwei Dinge die man im Auge haben muss:

• Data Science ist neben AI/ML eines der Hype Themen zur Zeit. Mittlerweile verschwimmen auch die Grenzen zwischen den Bereichen. Damit wird natürlich auf vieles dieses Label draufgeklebt, egal ob es wirklich Data Science im engeren Sinne ist. Das ist manchmal reine Augenwischerei, anderseits werden auch "klassische" Produkte um Funktionen erweitert die aus dem Data Science und/oder ML Bereich kommen.
• Die IT Industrie lebt (wie eigentlich alle Industrien) von hochgradiger Spezialisierung und Arbeitsteilung. Sprich, komplexe Funktionen werden in Produkte (z.B. auch Frameworks, Libraries) gepackt, sodass nicht-Spezialisten sie nutzen können. Hype Beispiel zur Zeit sind Generative Modelle wie eben ChatGPT. Das ist aber schon in der klassischen Informatik so. Fast jeder Informatiker hat mal irgendeine Vorlesung über Compilerbau gehört, aber die wenigstens haben das je in ihrem Berufsleben wieder gebraucht. Aber jeder der noch Code schreibt, nutzt täglich Compiler.

Es gibt nur relativ wenige Jobs für Spezialisten, die Anzahl der Compiler/Interpreter von Marktbedeutung - selbst wenn man alle wichtigen Programmiersprachen zusammen nimmt - liegt irgendwo im zweistelligen Bereich.
Für uns in Deutschland kommt noch erschwerend hinzu, das wir in der weltweiten IT Nahrungskette eher auf der Konsumenten als auf der Produzentenseite stehen. Gibt ein paar Ausnahmen z.B. DeepL, oder teilweise auch SAP. Sicher auch ein paar hochspezialisierte Nischen, die kaum jemand (auch ich nicht) kennt.

Ich selber arbeitete übrigens für ein Holländisches Unternehmen, das auch enge Kontakte zu Universitäten in NL unterhält. Bei uns kommen daher auch Spezialisten von Unis, die dann bei uns im Bereich OR/Data Science und ML arbeiten.

In vielen Diskussionen, die ich darüber gelesen habe, wurde oftmals sowas gesagt wie: In 95% der Fälle ist aktuell "Data Science" = stupides "Datenrumgeschiebe", wo auch jemand komplett fachfremdes diese Arbeit übernehmen könnte. Hat also so gut wie nichts mit der Vorstellung von Data Science zu tun. Ich frage mich inwiefern es für mich Sinn macht, zu versuchen in dieser Sparte Fuß zu fassen.

Wie oben gesagt, sind die meisten Anwenderunternehmen Konsumenten von Technologie. Da geht es dann darum, die relevanten Fragestellungen zu identifizieren, sie genau genug zu spezifizieren, das man darauf aufbauend überhaupt ein sinnvolles Projekt definieren kann. Bei den Daten geht es weniger ums "rumschieben", sondern eher darum, die Daten überhaupt in eine Form zu bringen, das man etwas mit ihnen anfangen kann.
Dann muss man die richtigen Tools und die richtige Architektur auswählen. Falls man z.B. auch Cloud Lösungen wie Microsoft Azure setzt, kommen dann auch Kostenaspekte hinzu.

Unsere Data Science Spezialisten bauen gerade eine Data Analytics Platform auf Basis von Azure auf. Die ist aber für unsere Kunden.

Ich selber bin bei uns für Cloud FinOps zuständig und wir nutzen - ohne Date Science Experten zu sein - teilweise die gleichen Tools (z.b. Azure Data Factory, Power BI, usw.). Wir nennen es "Reporting", ich würde nie behaupten, dass ich Data Science mache.

Zurzeit scheint es mir irgendwie so wie mit dem Thema IT-Sicherheit. Leute, die das an der Uni machen, lernen da die ganze mathematische Theorie hinter Kryptographie und weiteres theoretisches Zeug über Verschlüsselungen. 99% der IT-Security Berufe sind aber im Vergleich dazu trivial...da prüft man dann irgendwelche ISO-Normen, was vielleicht nicht ganz so interessant ist für viele.

Da ist es das Gleiche. Es wäre schlimm wenn jeder seine eigene AES Library schreiben würde, oder sich gar eigene Verfahren ausdenken würde. Dann hätten wir noch viel mehr Sicherheitslücken als heute.

Auch hier greift die Arbeitsteilung: In der Regel nutzt Software eine der wenigen etablierten Kryptobibliotheken. Wenn Du nicht in der Kryptoanalyse oder ähnlichen Spezialgebieten arbeiten willst, musst Du die mathematische Theorie soweit verstehen, dass Du die Klausur bestehst, danach kannst Du es auch wieder vergessen.

IT Sicherheit im Unternehmen ist vor allem Risikobewertung und Management. Wenn mal wieder eine irgendwo eine Lücke aufgetaucht ist (wie jüngst in OpenSSL), musst man schnell bewerten können, welches die konkreten Risiken für die eigene IT sind. Ob man z.B. unmittelbar einen Notfallpatch einspielen muss, oder sogar Systeme vom Netz nehmen muss, oder ob man es im Rahmen des normalen Patch-Managements machen kann. Muss man Kunden mit einbinden?

Um z.B. CVEs Lesen und verstehen zu können, muss man schon Fachwissen haben. Dabei ist aber meist z.B. das Verständnis über ein Protokoll wie etwa TLS wichtiger als die Mathematik hinter einem kryptografischen Verfahren. Die Fehler treten nämlich meist in den Protokollimplementierungen auf.

 

[ascer]

@ascer als unseren Data Scientisten kann ja auch mal seine Meinung beisteuern.

Der tag ist bei mir tatsächlich untergegangen

Data Science hingegen scheint mir heute irgendwie alles zu sein, was in einem (unter Umständen entfernten) Sinne mit Daten zu tun hat und das kann ja gefühlt alles sein...

Mittlerweile verschwimmen auch die Grenzen zwischen den Bereichen. Damit wird natürlich auf vieles dieses Label draufgeklebt, egal ob es wirklich Data Science im engeren Sinne ist.

das ist manchmal reine Augenwischerei, anderseits werden auch "klassische" Produkte um Funktionen erweitert die aus dem Data Science und/oder ML Bereich kommen.

Von meiner Erfahrung aus - und auch der meines gesamten Netzwerks bei jeder Diskussion darüber - würde ich ganz klar sagen: keine Aussage trifft auf DS/AI/ML/... heutzutage mehr zu, als das jedes Unternehmen so viel wie möglich mit den Buzzwords hausieren geht und in Wirklichkeit sehr häufig kaum etwas dahintersteckt.

Ich war in der Automobilbranche und habe dort in puncto autonomes Fahren (und anderer KI-Services) ein entsprechendes Team geleitet, jetzt bin ich mehr Richtung Forschungsinstitut unterwegs, und habe mittlerweile mit diversen Unternehmen, auch den großen DAX-Schuppen, zusammengearbeitet: in der Regel organisieren da Manager (ohne Verständnis der Technologie) irgendein feature, proof of concept, demo, neues Produkt, ... und wirklich etwas Entwickeln tun die Wenigsten. Meistens ist es fremdvergeben oder nichts weiter als copy+paste von frei verfügbaren codebases von GitHub & Co.

Wie sieht Data Science in Deutschland gerade aus und wie seht ihr die praktische Zukunft von Data Science? Wird dieses "echte" Data Science auch in naher Zukunft FAANG, Uni-Forschern und paar Auserwählten vorenthalten bleiben?

Meiner Meinung nach: ja. Als ich angefangen habe, habe ich mit meinem damaligen Team noch explorative Datenanalysen selbst gemacht und dann selbst KI-Entwicklung betrieben - maßgeschneidert auf die Ergebnisse (und festgelegten Anforderungen).

Heutzutage gibt es für die typischen Dinge im reinforcement learning, object detection, image classification, ... große Libraries wo jeder DevOps mit Uni-Background (sodass man z.B. Metriken & Co. interpretieren kann) kurz die "train.py" im Terminal ausführen kann - mit den eigenen Daten. Kurzum: die Standardfälle sind so trivial geworden und es gibt so viel frei verfügbar, dass das keine Zukunft für irgendwen birgt. Es wird einfach verwendet was vorhanden ist.

Die Weiterentwicklung von den jeweiligen "State-Of-The-Art"-Modellen ist so komplex geworden, dass das sowieso nur noch BigPlayer mit massiven Ressourcen machen können. Was anderes existiert da gar nicht mehr und da gibt es ganz wenig, hochspezialisiertes Personal.

Ähnlich ist das mit etwaiger Analysesoftware, Natural-Language-Processing (siehe ChatGPT), usw.

Auf der anderen Seite, wo noch konkret geforscht wird, geht es mehr um proof of concept, Grundlagenforschung, ... also kurzum Dinge, die noch nicht von großen Libraries erledigt werden. Davon gibt es tatsächlich in Deutschland relativ viel, aber das ist dann selbstredend ebenfalls hochspezialisiertem Personal vorbehalten.

Summa summarum: wenn man nicht wirklich gut ist, Netzwerke von den Elite-Unis hat, selbst über Kapital verfügt um was zu gründen, oder oder...würde ich von dem Versuch, dort Fuß zu fassen, abraten.

Eine breite Nachfrage bzgl. Jobs die sich mit Daten befassen:
-> BI Consultants
-> Datenmodellierer
-> Data Engineers
-> Datenqualitätsmanager
-> Data Architects
...
Somit eher alles um den Auf- und Ausbau von DWHs und Datenkonsum aus den aufgebauten DWHs.

Anders sieht es hier aus. Wie ja schon mehrfach erwähnt: Branchenwissen/-erfahrung ist in vielen Anwendungsfällen sehr wichtig. Die absolute Mehrheit der Unternehmen hat kein (oder nicht ausreichendes) Fachpersonal, um ordentliche Digitalisierung voranzutreiben und wenn du keine saubere Datenbasis, DevOps Leute, usw. usf. hast, dann nutzt dir auch das beste, frei verfügbare Tooling nichts.

Stell dir das etwa so vor @Peter_2498:
Auf der einen Seite hast du fertige Dokumentensoftware wie Word, Excel, ... oder hochspezielles Zeug aber auf der anderen Seite hast du Unternehmen, die noch mit Papier und Tinte arbeiten.

Um zu den Entwicklern von Word, Excel, ... zu stoßen oder für hochspezielles Zeug => das sind wenige, sehr spezialiserte Stellen...
...aber wenn du weißt, wie du dieses Tools verwenden kannst und Branchenerfahrung mitbringst, kannst du (d)ein Unternehmen auf diese Tools umstellen, weg von Papier und Tinte.

Deshalb ist alles von der Liste von @_killy_ auch so gefragt. Die großen Modelle kommen von Microsoft, Google, Facebook, ... und neue Impulse / Grundlagenforschung i.d.R. von Unis, Instituten, einigen Startups, ... aber was es in Deutschland zu hauf gibt sind verteilte Systeme, verteilte Daten und Millionen Leute, die keinen Schimmer davon haben, wie man Zeug ordentlich digitalisiert und verwendet.

In solchen Gebieten kommt man dann definitiv deutlich leichter unter.

So Dinge wie bei Facebook, Google und Co gibt es hier eher nicht.

Das hängt von der Betrachtungsweise ab. Das meiste, was bei denen passiert, ist Optimierung von "State-of-the-Art" Zeug. Der beste Chatbot, die beste Bildklassifizierung, die beste ...

Bei Erschließung neuer Technologien, insbesondere von Grundlagenforschung, gibt es tatsächlich einiges in Deutschland. Die Problematik ist meist, dass es dann an Ressourcen mangelt, dies entsprechend zu skalieren und an Digitalisierung und Geld mangelt, es breitflächig einzusetzen. Zusätzlich dann noch die Bürokratie hier...

Aber hey, viele haben halt auch keine Ahnung wie man effizient mit Daten umgeht und nehmen Python

Definitiv. Wobei ich jetzt Python in dem Punkt gar nicht negativ erwähnen würde. In enorm vielen Bereichen ist das Standard für DS/AI/ML/...

Letztenendes kann Datenverarbeitung in Python deutlich schneller sein, als selbstgeschriebener C++-Code, denn in professionellen Anwendungen ist Python ja nicht mehr als eine (sehr, sehr mächtige) "API", die dann jedwede Berechnung nach CUDA auf die GPU schiebt. Auf einem Supercomputer, auf den ich Zugriff habe, sind bestimmt gut 3/4 der Anwendungen Python-Code...der dann über entsprechende Libraries Daten auf diverse Knoten verteilt und Berechnungen in C/Julia/Rust/... triggert und sich nach Ende schlichtweg das Ergebnis abholt.

 

[Peter_2498]

Danke auch dir @ascer für deine Sicht der Dinge. Ich bin kein begnadeter Data Scientist, bin an keiner Elite-Uni und Geld habe ich auch nicht ohne Ende 😅 und damit wäre es glaube ich das beste dahingehend meine Erwartungen deutlich zurückzuschrauben und mich nicht zu sehr auf Data Science zu versteifen. Danke nochmal an alle!

 

[ascer]

Master Mathematik(Vertiefung in Optimierung und maschinellem Lernen)

Ich würde dabei in zwei Richtungen denken:
Zum Einen könntest du dir eine Branche aussuchen, wo du über Erfahrung, Kontakte oder zumindest Interesse verfügst und eben der "Anwender" wirst, d.h. lerne was es an Tools gibt und verknüpfe das mit einem Bereich, wo Mathematiker gefragt sind. Finanzwesen, Versicherung...
Zum Anderen ist Validierung von DS/AI/ML/... ein sehr großes Thema, insbesondere in Europa. In meinem Studium musste ich auch durch unzählige Mathevorlesungen durch - mein Fokus war aber immer eher Neuroinformatik, DataScience, vor allem AI und Robotik...darüber bin ich am Ende (reinforcement learning) auch zu meiner Stelle in der Automobilbranche gekommen. Der Punkt dabei ist: trotz der vielen Mathevorlesungen bin ich bei weitem kein Mathematiker und bei jedem Projekt, wo es um sehr teure Einzelmaschinen oder Ähnliches ging (ich hatte z.B. ein Projekt im Raumfahrtbereich) müssen Daten, KI-Modelle, ... validiert werden. Da hatte ich sehr häufig Kontakt mit Mathematikern. Beispielsweise Stochastik und Bayes'sche Statistik. Selbst in meiner vorherigen Position im autonomen Fahren ist (zumindest in der westlichen Welt) Optimierung und Validierung ein sehr großes Thema. Nichts darf ohne Erlaubnis auf die Fahrbahn und es gibt keine Erlaubnis ohne Zertifizierung.

 

[Skysnake]

Bei Erschließung neuer Technologien, insbesondere von Grundlagenforschung, gibt es tatsächlich einiges in Deutschland. Die Problematik ist meist, dass es dann an Ressourcen mangelt, dies entsprechend zu skalieren und an Digitalisierung und Geld mangelt, es breitflächig einzusetzen. Zusätzlich dann noch die Bürokratie hier...

Jup dem kann ich zustimmen. Das hatte ich auch mit den genannten Firmen gemeint, die die Sachen eben skalieren.

Es ist erschreckend wie klein Dinge in Deutschland sind. Da laufen Sachen auf ner Hand voll VMs. Von so Skalen wie bei Amazon , Facebook usw ist man da weit weg.

Klar sind es insgesamt dann auch viele Server, aber in europäischen Firmen ist die Zerstückelung von Ressourcen scheinbar Gesetz...

Definitiv. Wobei ich jetzt Python in dem Punkt gar nicht negativ erwähnen würde. In enorm vielen Bereichen ist das Standard für DS/AI/ML/...

Gegen Python als Glue Code sagt ja auch keiner was. Ich nutze Python auch für verdammt viele Sachen gern weil man schnell zu Ergebnissen kommt und es im Vergleich zu zum Beispiel Bash sehr viel performanter ist.

Wenn ich aber sehe was teilweise mit Junyper Notepads gemacht wird, dann drehen sich mir teils die Fußnägel hoch. Da wird teils wirklich interaktiv gearbeitet und nicht drüber nachgedacht, dass das überhaupt nicht skaliert.

Letztenendes kann Datenverarbeitung in Python deutlich schneller sein, als selbstgeschriebener C++-Code, denn in professionellen Anwendungen ist Python ja nicht mehr als eine (sehr, sehr mächtige) "API", die dann jedwede Berechnung nach CUDA auf die GPU schiebt.

Ja, das heißt aber nicht, das man das Hirn ausschalten darf. Wenn dadurch am Ende ein Hadoop Verhau raus kommt, dann kann es noch so tolle Libs verwenden und trotzdem ineffizient wie Sau sein....

Spark gibt es ja nicht ohne Grund

Und ein ist wichtig. Es kann schneller sein als selbst geschriebener Code. Es kann aber auch fucking viel langsamer sein. Und da fängt es an. Fast niemand stellt sich die Frage wie schnell KANN es denn sein und vergleicht das mit dem was er wirklich sieht. Das ist so traurig... aber dann würde man eben sehen, das die Dinge oft verdammt schlecht laufen und unterm Strich über den gesamten Workflow ineffizient wie Sau sind.

Auf einem Supercomputer, auf den ich Zugriff habe, sind bestimmt gut 3/4 der Anwendungen Python-Code...der dann über entsprechende Libraries Daten auf diverse Knoten verteilt und Berechnungen in C/Julia/Rust/... triggert und sich nach Ende schlichtweg das Ergebnis abholt.

Was ja an sich auch ok ist. Nur ist meine Erfahrung, dass die Workflows oft ziemlich schlecht sind. Also bei HPC an sich ist man schon oft durch den Memory limitiert und Kommunikation wird suboptimal gemacht, aber bei den ganzen AI bzw Dataanalytics Anwendungen ist es ein Graus. Das ist oft so ineffizient und nicht skalierbar gemacht, das tut echt weh.

Rein interessehalber wie groß ist das System mit dem du arbeitest?

 

[Peter_2498]

Zum Einen könntest du dir eine Branche aussuchen, wo du über Erfahrung, Kontakte oder zumindest Interesse verfügst und eben der "Anwender" wirst, d.h. lerne was es an Tools gibt und verknüpfe das mit einem Bereich, wo Mathematiker gefragt sind. Finanzwesen, Versicherung...

Ja, ich glaube ich muss einfach erstmal schauen was die Zukunft bringt. Irgendwie kommt es ja immer anders, als man geplant hat. Vielleicht bewerbe ich mich bei einer interessanten Stelle und es stellt sich heraus, dass mir die Arbeit dort nicht passt oder ich nehme aufgrund mangelnder Alternativen eine mir nicht so interessant erscheinende Stelle an und merke dann, dass die Arbeit dort wirklich ganz cool ist.

 

[ascer]

Ja, ich glaube ich muss einfach erstmal schauen was die Zukunft bringt.

Ein genereller Tipp: wenn du dir eine Nische aussuchst, in der du Talent/Interesse hast, dann wird das mit ausreichend Geduld/Zeitinvestment auch was werden. Wie du schon sagtest: schauen was die Zukunft bringt. Spätestens wenn du anfängst zu arbeiten, wirst du sehr schnell merken, was dir gefällt und was dir liegt. Dort dann Kontakte ausbauen und du wirst keine Probleme haben.

Ich bin kein begnadeter Data Scientist, bin an keiner Elite-Uni und Geld habe ich auch nicht ohne Ende 😅

Ich würde auf jeden Fall immer nach Talent sortieren. Wenn du das Gefühl hast, dort nicht wirklich begnadet zu sein, gibt es ganz sicher etwas anderes, dass dir mehr liegt...

Sobald du in etwas erstmal Zeit investiert hast, arbeitest, Kontakte geknüpft hast sind auch die anderen Dinge nicht mehr so wichtig.

Elite-Uni (oder Geld) öffnet Türen, bietet schnell viel Kontakte...aber was mehrere Jahre hinter den ersten Türen liegt, dass liegt viel eher an deinem Interesse und Talent. Was du kannst, was du in deinem CV hast, Berufserfahrung, ... wird dich später bringen, wohin du möchtest. Geld (z.B. in puncto Selbstständigkeit) oder Elite-Uni (insbesondere Kontakte & Projekte) ist da nur "der Turbo für den Start".

Rein interessehalber wie groß ist das System mit dem du arbeitest?

Eines von den kleineren Clustern: Größenordnung 500 nodes.

 

[Skysnake]

Ok 500 nodes ist jetzt nicht mehr klein. Die Frage ist dann wie die Jobs so laufen. Ich bekomme halt irgendwo das Kotzen wenn ich sehe das Jobs 5 Minuten laufen. Was da an Overhead dabei ist....

Und genau das meine ich halt. Als Glue Code ist das ja ok, aber gerade wenn man skaliert muss man echt aufpassen, dass der Glue Code nicht signifikante Anteile der Laufzeit ausmacht.

Btw die Meldung von Amazon gelesen, die von Serverless weg gehen für die Qualitätsanalyse der Streams und damit 90% der Laufzeit sparen?

Das sind so Geschichten wo ich mir denke. Jup da hat jemand nicht über die Skalierbarkeit nachgedacht

 

[ascer]

Ok 500 nodes ist jetzt nicht mehr klein. Die Frage ist dann wie die Jobs so laufen. Ich bekomme halt irgendwo das Kotzen wenn ich sehe das Jobs 5 Minuten laufen. Was da an Overhead dabei ist....

Das stimmt wohl, aber passiert das tatsächlich häufig? Da muss man sich ja die Frage stellen, warum der Job überhaupt auf einem Supercomputer lief. Wenn das aus RAM-Gründen o.Ä. nicht auf einer workstation laufen kann...okay...aber ansonsten würde das ja problemlos auf einer Workstation - dann vielleicht im Stundenbereich - durchlaufen.

Ich war bisher auf zwei Supercomputern unterwegs. In meiner aktuellen Stelle und früher Uni-Zeug (das System war ~300 Knoten) und habe sowas tatsächlich nie erlebt. Abgesehen von grundlegender Einführung von SLURM und dem System usw. gab es beispielsweise auch Infoblätter & Co. darüber, was man wie machen kann/sollte und auch wie man verantwortungsvoll mit den Ressourcen umgeht.

I.d.R. (so auch bei uns) kannst du ohne vorherige Anmeldung eines größeren Experiments auch nur auf kleineren Partitionen des Systems oder mit Limitierung bzgl. Anzahl Nodes bzw. Laufzeit rechnen.

Abgesehen davon werden die Jobs auch geloggt und wenn z.B. haufenweise Jobs abstürzen oder im Idle hängen o.Ä. gäbe es bestimmt entsprechende Folgen. Prototyping ist z.B. auch nur ausschließlich dann gestattet, wenn das Experiment wegen der Ressourcenanforderungen (also z.B. RAM im TB-Bereich) direkt auf dem Cluster laufen muss - ansonsten findet das ausschließlich auf Workstations statt.

Imho ist das auch eine Frage der Administration. Wenn man ein Derartiges System einfach zur Verfügung stellt, ohne einheitliche Standards, An- und Einweisungen, Regeln, ... wird es natürlich zu Missbrauch kommen. Da ist aber dann eben auch die Administration gefragt, nicht jedes Projekt und jeden Praktikanten Zugang zu geben.

Wenn jemand von A nach B ohne Transportgut kommen muss, drücke ich dem ja auch nicht gleich die Schlüssel vom größten LKW in die Hand, den ich finden kann.

Und genau das meine ich halt. Als Glue Code ist das ja ok, aber gerade wenn man skaliert muss man echt aufpassen, dass der Glue Code nicht signifikante Anteile der Laufzeit ausmacht.

Das stimmt wohl, aber das ist heutzutage ja relativ einfach - zumindest im DataScience- und vor allem KI-Bereich. Beispielsweise TensorFlow, PyTorch, ... bis hin zu generelleren Dingen wie Dask sind ja direkt dafür entwickelt auf mehreren Maschinen parallel zu rechnen.

Hängt natürlich alles sehr stark von den verwendeten Tools ab und kann dann ganz anders aussehen...aber zumindest im KI-Bereich war meine Erfahrung bisher, dass das problematische eher die Anwendungen sind, wo jemand meint mit C++ und z.B. MPI irgendwas "besser" oder "effizienter" zu können, als das kurz in Python/Dask runterzuschreiben.

Btw die Meldung von Amazon gelesen, die von Serverless weg gehen für die Qualitätsanalyse der Streams und damit 90% der Laufzeit sparen?

Das sind so Geschichten wo ich mir denke. Jup da hat jemand nicht über die Skalierbarkeit nachgedacht

Das stimmt natürlich auch. Wobei ich da aber auch glaube, dass das oft an der Struktur von großen Konzernen liegt: wenn Team A sich damit nicht auskennt und etwas für einen bestimmten Zweck entwickelt hat, weil Manager Oberklug das so haben wollte, dann bekommt man Skalierbarkeit halt nicht beliebig als Feature hinterherentwickelt.

 

[Skysnake]

Das stimmt wohl, aber passiert das tatsächlich häufig? Da muss man sich ja die Frage stellen, warum der Job überhaupt auf einem Supercomputer lief.

Ja das passiert auf manchen Systemen absolut regelmäßig. Schon mal was von Nowcasting gehört? Montecarlo ist auch immer beliebt und da dann je nach Fall auch angebracht.

Warum sollte nen Ingi nen Tag auf seine Ergebnisse warten wenn er es auch entsprechend parallelisieren kann. Das ist ja immer das Argument pro Cloude.

Wenn das aus RAM-Gründen o.Ä. nicht auf einer workstation laufen kann...okay...aber ansonsten würde das ja problemlos auf einer Workstation - dann vielleicht im Stundenbereich - durchlaufen.

Nö. Bei Nowcasting brauchst du das Ergebnis jetzt, denn in ner Stunde ist es schon veraltet und wenn du 1000 Corestunden brauchst, nach einer Stunde das Ergebnis aber nutzlos ist, dann parallelisierst du das so weit wie es halt geht. Das Fatale daran. Der Job kommt dann wahrscheinlich alle 1-3 Stunden wieder.

Ansonsten kann ich aus eigener Erfahrung mit nem 8k Knoten System reden dessen Testqueue rund 350 Knoten für 15 Minuten war, dass das absolut Sinnvoll ist. Durch den großen Turnaround und Verschnitt bei der Größe waren 300 Knoten eigentlich immer binnen 30 Minuten verfügbar. Und dann konnte ich halt 300x15 Minuten in unter 1h rechnen. Also 75 Knotenstunden in unter 2h erledigt. Warum sollte ich da 3 Tage auf irgend ner Highend Workstation rechnen zumal es um Parameterstudien für genau das große System ging?

Strong weak scaling kann man auch mit kurzen Laufzeiten gut realisieren wenn man weiß was man macht und der Startup nicht schon ne Stunde dauert. Was es leider gibt

Ich war bisher auf zwei Supercomputern unterwegs. In meiner aktuellen Stelle und früher Uni-Zeug (das System war ~300 Knoten) und habe sowas tatsächlich nie erlebt. Abgesehen von grundlegender Einführung von SLURM und dem System usw. gab es beispielsweise auch Infoblätter & Co. darüber, was man wie machen kann/sollte und auch wie man verantwortungsvoll mit den Ressourcen umgeht

HPC ist SEHR vielschichtig und die Leute haben sehr unterschiedliche Probleme. Klar sieht man die Rechnung die 2 Tage läuft nicht ungern, aber es gibt gerade bei den Chemikern und Ingenieuren recht kurze Laufzeiten hat, aber eben Millionen von Parametern. Abgrasen muss. Und damit kommen wir zum springenden Punkt.

Es KANN absolut sinnvoll sein seine Jobs kleiner zu hacken und auch 5 Minuten Jobs zu starten, einfach weil die CPU Cycles ansonsten ungenutzt verpuffen würden. Ich hatte da z.b. mal so nen Spetzi der hat den Slurm alle 5 Minuten oder so abgefragt und dann abgeschätzt wie viele Cores sein Job haben kann für wie lange um durch den Backfill sofort dran zu kommen. Der Gutste hat die Auslastung des Systems stark nach oben getrieben. Aber als Admin habe ich gesehen das er "Schindluder" treibt aus den Systemparametern ohne ihn zu kennen. Und einmal hat er dann auch Mist gebaut und das System überlastet, weil er 5 Instanzen seines eigenen Queueing Systems parallel hat laufen lassen und damit den Slurm überlastet hat. Dafür gab es dann auch was auf die Finger. Aber sonst? WTF sicher nicht sondern mein Respekt, denn er hat einen guten Weg gefunden das System zu überlisten und das sogar auf ne Art die am Ende allen hilft weil er viele Tote Cycles für sich genutzt hat. Er hat es aber eben NICHT stumpf immer als Single Core 5 Min Job eingestellt was auch ginge. Er hätte dafür sogar nicht mehr gezahlt weil der Job overhead ja nicht verrechnet wird.

Aber leider gibt es genug Leute die halt NICHT sinnvoll eine queuing System nutzen können. Und gerade aus dem Bereich der Life Science als auch Datenanalyse habe ich leider überwiegend negative Erfahrungen sammeln müssen.

Ok theoretische Chemiker sind auch so ne besondere Gattung die gerne mal riesige Files ins storage legen und dann Tage lang mit maximaler Bandbreite aus dem Lesen....... die bekommen dann aber auch gerne mal ihren eigenen Spezistorage damit Sie den Rest nicht nerven

I.d.R. (so auch bei uns) kannst du ohne vorherige Anmeldung eines größeren Experiments auch nur auf kleineren Partitionen des Systems oder mit Limitierung bzgl. Anzahl Nodes bzw. Laufzeit rechnen.

Das sind dann aber eben Systeme bei denen du Zeiten zugeteilt bekommst also nicht dafür zahlst. Aber was machst du wenn die Leute dafür bezahlen und es Ihnen die Kosten eben Wert ist?

Je nachdem wie groß der Profit bzw der Schmerz ist akzeptieren Leute auch 10% kürzere Laufzeit für doppelte HW Ressourcen...

Imho ist das auch eine Frage der Administration. Wenn man ein Derartiges System einfach zur Verfügung stellt, ohne einheitliche Standards, An- und Einweisungen, Regeln, ... wird es natürlich zu Missbrauch kommen. Da ist aber dann eben auch die Administration gefragt, nicht jedes Projekt und jeden Praktikanten Zugang zu geben.

Wenn jemand von A nach B ohne Transportgut kommen muss, drücke ich dem ja auch nicht gleich die Schlüssel vom größten LKW in die Hand, den ich finden kann.

Du machst es dir da zu einfach. Am Ende vom Tag sind so Systeme für 95% der Leute einfach nur ein Werkzeug mit dem Sie sich mehr schlecht als recht auskennen. Aber da kannst du vielen auch überhaupt keinen Vorwurf mit machen. Die werden für andere Dinge bezahlt und wissen es oft eben auch einfach nicht besser...

Zudem bekommt in Deutschland halt eher keiner nen Dr. Weil er nen bestehenden Code Faktoren schneller gemacht hat durch Optimierung oder Portierung auf GPUs. Und in Firmen arbeiten die Leute viel mit ISV Codes und die Hersteller haben kaum/keinen Anreiz zu optimieren und die Nutzer auch nicht, weil sie wenig dran ändern können bzw wenn wird halt einfach das doppelte an HW hingestellt und die an sich ineffizient genutzt weil die Lizenzen der limitierende Faktor sind, damit aber pro € mehr gerechnet werden kann als wenn man mehr Lizenzen kauft.

Das stimmt wohl, aber das ist heutzutage ja relativ einfach - zumindest im DataScience- und vor allem KI-Bereich. Beispielsweise TensorFlow, PyTorch, ... bis hin zu generelleren Dingen wie Dask sind ja direkt dafür entwickelt auf mehreren Maschinen parallel zu rechnen.

Hängt natürlich alles sehr stark von den verwendeten Tools ab und kann dann ganz anders aussehen...aber zumindest im KI-Bereich war meine Erfahrung bisher, dass das problematische eher die Anwendungen sind, wo jemand meint mit C++ und z.B. MPI irgendwas "besser" oder "effizienter" zu können, als das kurz in Python/Dask runterzuschreiben.

Da will ich aber mal recht vehement widersprechen.

Gerade die ganzen AI Sachen sind dafür verschrien nicht oder schlecht über Node Grenzen zu skalieren. Zudem ist es peinlich das NVIDIA in ihrer Implementierung einfach nur das Datenlayout geändert hat und damit extrem viel schneller wurde. Ich weiß nicht mehr welches bekannte Framework das war aber Intel AMD haben das dann irgendwann auch gemacht, weil die Entwickler das nicht hinbekommen haben....

Also an sich sollte man meinen die wüssten was Sie machen und machen auch nen recht guten Job bzw besseren als der Durchschnitt, das heißt aber nicht das nicht trotzdem teils massiv gefailed wird bzw Luft nach oben besteht.

Das stimmt natürlich auch. Wobei ich da aber auch glaube, dass das oft an der Struktur von großen Konzernen liegt: wenn Team A sich damit nicht auskennt und etwas für einen bestimmten Zweck entwickelt hat, weil Manager Oberklug das so haben wollte, dann bekommt man Skalierbarkeit halt nicht beliebig als Feature hinterherentwickelt.

Das hat eher was damit zu tun das die Leute keine Vorstellung davon haben wie weit ihre Sachen skalieren müssen, es Ihnen kack egal ist oder Sie schlicht keine Ahnung von O Notation bzw Rechnerarchitektur haben und manchmal ein bisschen was von allem....

 

[ascer]

@Skysnake ich glaube, das wird hier zu Offtopic und sollte - falls weiter - in einem eigenen Thread thematisiert werden.

Ganz allgemein würde ich aber noch sagen: wann immer Meinungen einen emotionalen (und negativen) Touch haben sowie diverse Absolutismen enthalten (oder zumindest stark dahin konvergieren), ist das Statement i.d.R. mindestens diskutabel, wenn nicht gar suspekt.

Es ist wichtig bei komplexen Themen zu berücksichtigen, dass ein jeder von uns nur Inselkompetenzen besitzt, die in einem ganzen Meer an Inkompetenz baden. Das resultiert zwangsläufig immer aus Spezialisierung, bestimmten Branchen, Berufen, Studiengängen, Interessen, ...

Z.B. kann man aus Sicht trivial parallelisierbarer Algorithmen - gibt ja durchaus reale Probleme, die annähernd lineal skalieren - die Meinung vertreten, AI libs wie PyTorch oder TensorFlow würden schlecht skalieren. Selbst im Vergleich zu typischen Dingen aus Chemie, Physik und meiner Erfahrung nach (die hier nur aus Austausch in der Mensa & angucken der Jobs auf dem Cluster besteht) insbesondere der Meteorologie skaliert das in der Tat schlecht.
Die Frage in dem Punkt ist ja aber, ob das legitime Vergleiche sind. Mich z.B. verwundert es eher, wie gut PyTorch/TensorFlow (und Ähnliches Zeug im DS/AI Bereich) GPUs nutzen können. Man muss sich ja vor Augen halten: ein Computerchip hat N homogene Recheneinheiten und sämtliche Geschwindigkeit resultiert einzig durch Parallelisierung selbiger. Neuronale Netze hingegen funktionieren grundlegend anders. Wenn ich einen CV Algorithmus mit herkömmlichen Methoden schreiben um so was banales wie Türklinken zu detektieren, wird das ein riesiges Monstrum und in der Detektionsgüte am Ende trotzdem eine Katastrophe. Es gibt natürlich diverse Tricks, wie man sowas zumindest mit np-vollständigen Ansätzen hinbekommt, z.B. durch Approximationen, aber nichtsdestoweniger ist das am Ende in der Detektionsgüte trotzdem selbst den primitivsten neuronalen Netzen unterlegen.

Neuronale Netze hingegen liegen grundsätzlich sogar in EXP - es gibt da bis heute nichts polynomielles, was sauber die Struktur und Gewichtung erarbeiten würde. Neuronen bilden für uns mehr oder weniger arbiträr Dendriten aus, können ein Signal weiterleiten oder auch nicht (für einen Computerchip unmöglich, ein "nicht weiterleiten" in einer Gleichung ist höchstens durch ein neutrales Element wie eine 0 "simulierbar") usw. usf.
Dann kommt noch dazu, dass die Struktur selbst ein wildes durcheinander vieler Schichten ist.

Trotzdem haben wir es geschafft Dinge wie sparsity künstlich nachzubilden und können diverse GPUs recht gut auslasten um uns einer Problemlösung für eine KI anzunähern, deren optimale Lösung ein EXP Problem ist und eigentlich unlösbar ist. Und das am Ende im Bezug auf Ressourcenverbrauch in einer Art und Weise, die um Größenördnungen effizienter ist, als manuell als Mensch irgendwelche herkömmlichen CV Algorithmen aneinanderzureihen (oder NLP, oder ... - je nach Aufgabengebiet).

Man kann also einerseits darauf blicken und sich fragen, warum jetzt 16 GPU nodes nur mit 70% utilization im average laufen - oder erstaunt darüber sein, dass da eine Lösung für etwas in EXP angenähert wird, die hinterher um Größenordnungen präziser funktioniert als jeder herkömmliche Ansatz und das im Bruchteil einer Zeit und Ressourcenverbrauch im Vergleich zu herkömmlichen Lösungen.

Nochmal am Beispiel Meteorologie: die rechnen bei uns fröhlich auf Hunderten Nodes mit hoher Auslastung. Da deren Modellrechnungen per KI (bisher) nur halbwegs gut mit Graph Neural Networks läuft (und das im Vergleich zu üblichen Netzen in NLP oder CV noch in den Kinderschuhen steckt), gibt es da noch keine KI-Lösungen die alles andere abgelöst haben, aber man kann es selbst dort schon gut Vergleichen: die herkömmlichen Modellrechnungen für ihre Wetteranalysen laufen auf Hunderten nodes parallel, teilweise Tagelang. Mit sehr hoher Auslastung pro Node - also gut parallelisiert. Die ersten KI-Versuche ergeben bei denen so langsam auch brauchbare Resultate - und das trainiert 1-2 Tagen max. auf 8-16 GPU Nodes. Da dann, da GNNs sich schlechter parallelisieren lassen, mit höchstens 50% utilization pro GPU.

Die Frage ist dann ja: ist jetzt der herkömmliche Ansatz besser / effizienter, nur weil er die vorhandenen Ressourcen besser ausnutzt? Oder nicht doch auch der KI-Ansatz, der zwar wegen der Komplexität der Architektur die gegebene Hardware deutlich schlechter nutzt, aber insgesamt viel weniger Hardware benötigt?

Bei solchen Dingen gehört immer viel Domänenwissen dazu. Von außen betrachtet sehen einige Dinge ineffizient aus, manchmal steckt da aber Kalkül und Gründe dahinter. Manchmal natürlich auch nicht und es war nur ein Versehen