Wann holst du eine Analyse aus SQL heraus und nach Python?

Bleib in SQL für Filtern, Joinen und Aggregieren, denn die Arbeit passiert direkt neben den Daten und skaliert, ohne sie zu bewegen. Geh nach Python, wenn du statistische Modellierung, Iteration oder Simulation, komplexe String- oder Textverarbeitung, Aufrufe einer externen API oder wiederholbare Charts brauchst. Eine nützliche Regel: erst in SQL runteraggregieren, dann das kleinere Ergebnis nach Python ziehen für die Teile, in denen SQL schlecht ist.

Mein Default ist SQL für alles, was Filtern, Joinen oder Aggregieren ist, denn die Berechnung passiert dort, wo die Daten liegen, und ich schiebe nicht Gigabytes über die Leitung für ein group by, das das Warehouse in Sekunden erledigt hätte. Ich wechsle nach Python, wenn die Aufgabe etwas ist, worin SQL wirklich schlecht ist: ein Modell fitten, eine Simulation fahren, unsauberes Text-Parsing, eine externe API ansprechen oder Charts erzeugen, die ich identisch neu bauen will. Die Regel, an die ich mich halte, ist: erst runteraggregieren. Ich ziehe das zusammengefasste Ergebnis, vielleicht fünfzigtausend Zeilen, nicht die rohen zwanzig Millionen, was ich Leute habe machen sehen, die sich danach wunderten, warum ihr Kernel gestorben ist. Der andere Faktor ist Wartbarkeit. Wenn diese Analyse monatlich von jemand anderem neu laufen soll, schlägt SQL in einem versionierten Modell mit Tests ein Notebook, das an der Umgebung einer einzigen Person hängt. Wenn es eine einmalige Exploration ist, ist ein Notebook völlig in Ordnung und schneller geschrieben.