Engpässe in Dataflow beheben

Ein Engpass tritt auf, wenn ein Schritt, eine Phase oder ein Worker den gesamten Job verlangsamt. Engpässe können zu inaktiven Workern und erhöhter Latenz führen.

Wenn Dataflow einen Engpass erkennt, wird in der Jobgrafik eine Benachrichtigung angezeigt und im Bereich „Schrittinformationen“ werden die Art des Engpasses und die Ursache (falls bekannt) aufgeführt. Dataflow exportiert auch Informationen zur Engpasserkennung in einen Monitoring-Messwert, der die Daten als Zeitreihe darstellt. So können Sie Engpässe im Zeitverlauf oder in der Vergangenheit ansehen.

Engpässe erkennen

Wenn Dataflow eine Streamingpipeline ausführt, besteht der Job aus einer Reihe von Komponenten, z. B. Streaming-Shuffles, Verarbeitungs-Threads für benutzerdefinierte Funktionen (DoFn) und Checkpointing für persistenten Status. Um den Datenfluss zu ermöglichen, verwendet Dataflow Warteschlangen, um diese Komponenten zu verbinden. Daten werden von Upstream nach Downstream übertragen.

In vielen Pipelines wird die gesamte Durchsatzkapazität durch eine einzelne Komponente begrenzt, wodurch ein Engpass in der Pipeline entsteht. Die Geschwindigkeit, mit der Daten einen Engpass durchlaufen können, begrenzt, wie schnell die Pipeline Eingabedaten annehmen und verarbeiten kann.

Betrachten Sie beispielsweise eine Pipeline, in der die DoFn-Verarbeitung nach einem Streaming-Shuffle erfolgt. Eine Warteschlange zwischen den beiden puffert die gemischten, aber noch nicht verarbeiteten Daten. Wenn die DoFn-Verarbeitung Daten nicht so schnell verarbeiten kann, wie sie durch das Streaming-Shuffle erzeugt werden, wächst die Warteschlange. Bei einem längeren Engpass kann die Warteschlange ihre Kapazität erreichen. An diesem Punkt wird das weitere Shuffling pausiert und der Backlog wird nach oben weitergegeben. Auch in Queues weiter oben stauen sich Backlogs, was schließlich zu einer Verlangsamung führt, die sich bis zur Datenquelle auswirkt. Das bedeutet, dass die gesamte Pipeline nicht mit der Eingabe mithalten kann.

Wenn ein Engpass auftritt, kann ein erheblicher Teil der Pipeline fehlerhaft erscheinen, obwohl nur ein einzelner Punkt in der Pipeline den Rückstand verursacht. Dieses Verhalten kann die Fehlersuche bei Engpässen erschweren. Das Ziel der Engpasserkennung ist es, den genauen Ort und die Ursache zu ermitteln, damit Sie die Grundursache beheben können.

Dataflow erkennt einen Engpass, wenn eine Verzögerung den Grenzwert von fünf Minuten überschreitet. Wenn die Verzögerung diesen Grenzwert nicht überschreitet, erkennt Dataflow keinen Engpass.

Die Engpasserkennung erfordert nicht immer, dass Sie Maßnahmen ergreifen. Das hängt von Ihrem Anwendungsfall ab. Eine Pipeline kann auch bei vorübergehenden Verzögerungen von mehr als fünf Minuten normal funktionieren. Wenn das für Ihren Anwendungsfall akzeptabel ist, müssen Sie die angegebenen Engpässe möglicherweise nicht beheben.

Arten von Engpässen

Wenn Dataflow einen Engpass erkennt, wird in der Monitoring-Oberfläche der Schweregrad des Problems angegeben. Engpässe lassen sich in die folgenden Kategorien einteilen:

Verarbeitung hängt und macht keinen Fortschritt
Der Fortschritt der Pipeline wird in diesem Schritt vollständig angehalten.
Verarbeitung läuft, gerät aber in Verzug.
Die Pipeline kann eingehende Daten nicht so schnell verarbeiten, wie sie eingehen. Dadurch wächst der Rückstand.
Verarbeitung läuft, aber Rückstand bleibt unverändert
Die Pipeline wird ausgeführt und die Verarbeitungsrate ist mit der Eingaberate vergleichbar. Die Verarbeitung ist schnell genug, dass der Rückstand nicht wächst, aber der angesammelte Rückstand nimmt auch nicht deutlich ab.
Die Verarbeitung läuft und holt Rückstand auf.
Der Rückstand wird geringer, aber der aktuelle Engpass verhindert, dass die Pipeline schneller aufholt. Wenn Sie eine Pipeline mit einem Backlog starten, ist dieser Status möglicherweise normal und es ist kein Eingreifen erforderlich. Behalten Sie den Fortschritt im Blick, um zu sehen, ob das Backlog weiter abnimmt.

Ursachen von Engpässen

In diesem Abschnitt werden die Ursachen für Engpässe aufgeführt, die erkannt werden können. Mithilfe dieser Informationen können Sie das Problem beheben. In einigen Fällen können mehrere Ursachen vorliegen, die miteinander in Verbindung stehen. Wenn Worker beispielsweise unterdimensioniert sind, kann die vCPU-Auslastung hoch sein. Eine hohe vCPU-Auslastung kann dazu führen, dass Vorgänge langsamer werden, was wiederum zu einer erhöhten Warteschlangenverzögerung führen kann. In der Analyse der wahrscheinlichen Ursachen werden möglicherweise alle als Ursachen für den Engpass angezeigt.

Vorgänge mit langer Verarbeitungszeit

Einige Vorgänge in dieser Berechnung haben eine lange Verarbeitungszeit. Dies geschieht immer dann, wenn ein Eingabebündel an den Worker gesendet wird, der DoFn ausführt, und seitdem viel Zeit vergangen ist, ohne dass Ergebnisse verfügbar sind.

Dies ist meistens das Ergebnis eines einzelnen Vorgangs mit langer Ausführungszeit im Nutzercode. Andere Probleme können sich in Form von Vorgängen mit langer Verarbeitungszeit äußern. Beispiele hierfür sind Fehler, die innerhalb von DoFn ausgegeben und wiederholt werden, Wiederholungen über einen langen Zeitraum oder Abstürze des Worker-Harness aufgrund von Faktoren wie OOMs.

Wenn die betroffene Berechnung im Nutzercode erfolgt, suchen Sie nach Möglichkeiten, den Code zu optimieren oder die Ausführungszeit zu begrenzen. Zur Unterstützung beim Debugging enthalten die Worker-Logs Stacktraces für alle Vorgänge, die länger als 5 Minuten hängen bleiben.

Schlüssel-Commit zu groß

Weitere Informationen finden Sie unter Ausnahme „Key commit too large“.

Berechtigung für BigQuery-Senke verweigert

Dieser Fehler weist darauf hin, dass das Dienstkonto, mit dem die Pipeline ausgeführt wird, nicht die erforderlichen Berechtigungen zum Schreiben in die BigQuery-Ressource hat.

So können Sie dieses Problem anhand von Worker-Logs bestätigen:

  1. Öffnen Sie in der Google Cloud Console die Dataflow-Seite Jobdetails.
  2. Klicken Sie im unteren Bereich auf den Tab Logs (Protokolle) und wählen Sie Worker Logs (Worker-Protokolle) aus.
  3. Suchen Sie nach Fehlermeldungen, die darauf hindeuten, dass Berechtigungen oder der Zugriff verweigert wurden (z. B. PERMISSION_DENIED, 403 Forbidden, Access Denied oder actuallyForbidden).
  4. Sehen Sie sich den Logeintrag an, um das Zieldataset oder die Zieltabelle und die spezifische fehlende Berechtigung (z. B. bigquery.tables.updateData) zu ermitteln.

So lösen Sie dieses Problem:

  • Prüfen Sie, ob dem Dienstkonto die Rolle BigQuery Data Editor (roles/bigquery.dataEditor) für das Ziel-Dataset und die Zieltabelle zugewiesen wurde.
  • Wenn Sie projektübergreifend schreiben, müssen Sie dafür sorgen, dass dem Dienstkonto die Berechtigungen direkt im Zielprojekt erteilt werden, in dem sich das BigQuery-Dataset befindet, und dass VPC Service Controls (falls aktiviert) die Kommunikation zwischen den beiden Projekten zulassen.

Wenn das Problem durch diese Schritte nicht behoben wird, finden Sie unter Vordefinierte BigQuery-Rollen und -Berechtigungen Informationen dazu, wie Sie fehlende detaillierte Berechtigungen für Ihre spezifische Konfiguration ermitteln und gewähren.

BigQuery-Senkenressource erschöpft

Dieser Fehler weist darauf hin, dass das Limit für ein BigQuery-Kontingent überschritten wurde. Die wahrscheinlichste Ursache ist ein unzureichendes Kontingent im BigQuery-Zielprojekt, um das Volumen der geschriebenen Daten zu verarbeiten.

So können Sie dieses Problem anhand von Worker-Logs bestätigen:

  1. Öffnen Sie in der Google Cloud Console die Dataflow-Seite Jobdetails.
  2. Klicken Sie im unteren Bereich auf den Tab Logs (Protokolle) und wählen Sie Worker Logs (Worker-Protokolle) aus.
  3. Suchen Sie nach Fehlermeldungen, die darauf hindeuten, dass Ressourcen oder Kontingente erschöpft sind oder Ratenbeschränkungen überschritten wurden (z. B. RESOURCE_EXHAUSTED, 429 Too Many Requests, quotaExceeded oder rateLimitExceeded).
  4. Prüfen Sie den Logeintrag, um zu bestätigen, welcher Vorgang und welches Kontingentlimit überschritten wurde (z. B. Durchsatz- oder Verbindungslimits für die Storage Write API AppendRows oder Ratenlimits für Streaming-Insert-Anweisungen).

So lösen Sie dieses Problem:

  • Ermitteln Sie, welche BigQuery-Senkenimplementierung in Ihrer Pipeline verwendet wird, z. B. die Storage Write API oder Streaming-Insert-Anweisungen.
  • Sehen Sie sich Ihre BigQuery-Kontingentnutzung in der Google Cloud Console an. Achten Sie insbesondere auf Kontingente, die sich auf Ihren Senkentyp beziehen, z. B. gleichzeitige Verbindungen, Durchsatz oder Streaming-Insert-Anweisungen pro Sekunde.
  • Wenn Sie diese Limits regelmäßig erreichen oder überschreiten, sollten Sie eine Kontingenterhöhung beantragen.

Wenn durch diese Schritte nicht ermittelt werden kann, welches Limit überschritten wurde, finden Sie unter Kontingent- und Limitfehler beheben weitere Informationen.

RPC-Fehler bei BigQuery-Senke

Dieser Fehler gibt an, dass RPC-Anfragen von der Pipeline an BigQuery fehlschlagen. Mögliche Ursachen sind vorübergehende Netzwerk- oder Dienstprobleme, ungültige Anfrage-Payloads, Schemadiskrepanzen oder Fehler aufgrund von Zeitüberschreitungen und überschrittenen Fristen.

So prüfen Sie das Problem anhand von Worker-Logs:

  1. Öffnen Sie in der Google Cloud Console die Seite Jobdetails von Dataflow.
  2. Klicken Sie im unteren Bereich auf den Tab Logs (Protokolle) und wählen Sie Worker Logs (Worker-Protokolle) aus.
  3. Suchen Sie nach Fehlermeldungen oder Ausnahmen im Zusammenhang mit BigQuery-Schreibvorgängen, z. B. DEADLINE_EXCEEDED, UNAVAILABLE, INVALID_ARGUMENT oder Schemavalidierungsfehlern.
  4. Sehen Sie sich den Stacktrace und die Fehlermeldung an, um den von der BigQuery API zurückgegebenen spezifischen Fehlermodus zu ermitteln.

So lösen Sie dieses Problem:

  • Sobald Sie die spezifische Fehlermeldung oder den Statuscode in den Worker-Logs gefunden haben, können Sie in der Referenz zu BigQuery-Fehlermeldungen nachsehen, wie Sie den jeweiligen Fehler beheben können.
  • Wenn Ihre Pipeline die Storage Write API verwendet, finden Sie Informationen zur Behandlung bestimmter Schreib- und Streamfehler in der API-Dokumentation zur BigQuery Storage Write API im Abschnitt „Fehlerbehandlung“.
Lange Verarbeitungszeit für alle Vorgänge

Vorgänge in dieser Berechnung dauern immer lange. Das deutet auf ein Problem in der vom Nutzer bereitgestellten DoFn hin.

Diese Ursache unterscheidet sich von Vorgänge mit langer Verarbeitungszeit. Während sich diese Ursache auf einige Vorgänge auswirkt, betrifft diese Ursache alle Vorgänge in dieser Berechnung.

Prüfen Sie die Worker-Logs auf Fehler, Ausnahmen oder Stacks, die auf langsame oder hängende Threads hinweisen. Wenn Sie das Apache Beam SDK für Python verwenden und die Vorgänge von Natur aus lange dauern (z. B. langsame externe API-Aufrufe oder E/A mit hoher Latenz), sollten Sie ein Async DoFn verwenden. Diese Funktion kann den Durchsatz verbessern, da verhindert wird, dass die Verarbeitung durch diese zeitaufwendigen Aufgaben blockiert wird.

Langsamer Lesevorgang des nichtflüchtigen Zustands

Bei der Berechnung wird ein erheblicher Teil der Zeit mit dem Lesen des persistenten Status im Rahmen der Ausführung von DoFn verbracht. Das kann an einem zu großen nichtflüchtigen Status oder zu vielen Lesevorgängen liegen. Reduzieren Sie gegebenenfalls die Größe des persistenten Status oder die Häufigkeit der Lesevorgänge. Optimieren Sie die Zugriffsmuster für den Status, indem Sie mehrere Leseoperationen für den Status kombinieren oder bei Bedarf den Map-Status anstelle des Wertstatus verwenden. Möglicherweise handelt es sich auch um ein vorübergehendes Problem, das durch die Langsamkeit des zugrunde liegenden persistenten Status verursacht wird.

Langsamer Schreibvorgang des nichtflüchtigen Zustands

Bei der Berechnung wird viel Zeit damit verbracht, während des Commits der Verarbeitungsergebnisse persistenten Status zu schreiben. Dies kann die Folge eines zu großen persistenten Status sein. Reduzieren Sie die Größe des persistenten Status. Optimieren Sie die Muster für den Statuszugriff, indem Sie mehrere Status-Schreibvorgänge kombinieren, sofern dies sinnvoll ist. Möglicherweise handelt es sich auch um ein vorübergehendes Problem aufgrund der Langsamkeit des zugrunde liegenden persistenten Status.

Abgelehnter Commit

Die Datenverarbeitung kann aufgrund ungültiger Daten nicht in den persistenten Status übernommen werden. Das liegt in der Regel daran, dass eines der Betriebslimits überschritten wurde. Weitere Informationen finden Sie in den Logs. Alternativ können Sie sich an den Support wenden.

Unzureichende Apache Kafka-Quellpartitionen

Die Berechnung der Apache Kafka-Quelle hat nicht genügend Partitionen. Versuchen Sie Folgendes, um dieses Problem zu beheben:

  • Erhöhen Sie die Anzahl der Kafka-Partitionen.
  • Fügen Sie „redistribute“ mit .withRedistribute() ein, wenn Sie Kafka IO-Lesevorgänge konfigurieren, um die Daten effizienter zu parallelisieren. Fügen Sie .withRedistributeNumKeys(N) ein, wobei N > partitions eine Obergrenze für die Gesamtzahl der Schlüssel darstellt. Eine begrenzte Anzahl von Schlüsseln sorgt für Effizienz durch die Bündelung von Datensätzen.
  • Verwenden Sie .withOffsetDeduplication(), um die Kosten für den Shuffle zum Neuverteilen zu minimieren. In diesem Modus wird die Datenmenge minimiert, die im Rahmen der Umverteilung beibehalten werden muss, während gleichzeitig die „genau einmalige“ Verarbeitung gewährleistet wird.

Weitere Informationen finden Sie auf der Seite Daten aus Apache Kafka in Dataflow lesen im Abschnitt Parallelität.

Apache Kafka-Quelle mit großem Umfang an persistentem Status

Bei der Berechnung der Apache Kafka-Quelle wird ein hohes Datenvolumen neu verteilt, was zu hoher Latenz und hohen Kosten führen kann. Versuchen Sie Folgendes, um dieses Problem zu beheben:

  • Wenn für die Pipeline eine genau einmalige Verarbeitung erforderlich ist, minimieren Sie die Kosten für den Shuffle zur Neuverteilung, indem Sie den Offset-Deduplizierungsmodus verwenden. In diesem Modus wird die Datenmenge minimiert, die im Rahmen der Umverteilung beibehalten werden muss, während gleichzeitig eine genaue Verarbeitung erfolgt.
  • Wenn die Verarbeitung mindestens einmal für die Pipeline ausreicht, kann die Konfiguration allow duplicates aktiviert werden.

Weitere Informationen finden Sie unter Daten aus Apache Kafka in Dataflow lesen.

Unzureichende Quellparallelität

Eine Quellberechnung hat eine unzureichende Parallelität. Erhöhen Sie nach Möglichkeit die Parallelisierung in der Quelle. Wenn Sie die Parallelisierung nicht erhöhen können und der Job den Mindestens einmal-Modus verwendet, fügen Sie der Pipeline eine Redistribute-Transformation hinzu.

„Heiße“ Schlüssel oder unzureichende Schlüsselparallelität

Der Job hat „heiße“ Schlüssel oder eine unzureichende Schlüsselparallelität.

Für jeden Sharding-Schlüssel verarbeitet Dataflow Nachrichten seriell. Während Dataflow einen Batch von Nachrichten für einen bestimmten Schlüssel verarbeitet, werden andere eingehende Nachrichten für diesen Schlüssel in die Warteschlange gestellt, bis der aktuelle Batch abgeschlossen ist.

Wenn Dataflow nicht genügend unterschiedliche Schlüssel parallel verarbeiten kann, kann dies zu einem Engpass führen. Beispielsweise sind möglicherweise zu wenige eindeutige Schlüssel vorhanden oder bestimmte Schlüssel sind in den Daten überrepräsentiert („Hotkeys“). Ändern Sie die Logik Ihrer Pipeline, um die Daten neu zu verteilen. Fügen Sie den Gruppierungsschlüsseln beispielsweise ein zufälliges Suffix hinzu, um Hotkeys aufzuteilen, und fassen Sie die Ergebnisse in einem nachfolgenden Schritt zusammen. Weitere Informationen finden Sie unter Probleme mit Tastenkombinationen beheben.

Unterdimensionierte vCPUs

Dem Job sind nicht genügend Worker-vCPUs zugewiesen. Diese Situation tritt ein, wenn der Job bereits auf das Maximum skaliert wurde, die vCPU-Auslastung hoch ist und es immer noch einen Rückstand gibt. Möglicherweise müssen Sie die maximale Anzahl der für diesen Job bereitgestellten Worker erhöhen. Sie können diese Zahl beispielsweise durch eine Aktualisierung des Autoscaling-Bereichs erhöhen. Alternativ können Sie nach Möglichkeiten suchen, die vCPU-Auslastung durch Änderungen am Pipelinecode oder an der Arbeitslast zu verringern. Mit dem Cloud Profiler können Sie nach Optimierungsmöglichkeiten suchen.

Hohe vCPU-Auslastung. Warten auf Hochskalierung

Der Job hat eine hohe vCPU-Auslastung, aber es gibt noch Spielraum für eine Hochskalierung. Dieser Zustand ist wahrscheinlich vorübergehend, bis die Aufskalierung erfolgen kann. Sie können das Autoscaling überwachen, um die Autoscaling-Entscheidungen zu sehen. Wenn dieser Zustand über einen längeren Zeitraum anhält oder häufig auftritt, müssen Sie möglicherweise die Autoscaling-Konfiguration ändern, indem Sie einen anderen Hinweis zur Worker-Auslastung festlegen, damit der Job proaktiver skaliert werden kann.

Unausgewogene vCPU-Auslastung verursacht Engpässe bei einigen Ausreißer-Workern

Der Job hat genügend Worker-vCPUs, aber einige Worker weisen eine sehr hohe vCPU-Auslastung auf. Das liegt oft an einer ungleichmäßigen Arbeitsverteilung. Mögliche Ursachen sind ungleichmäßig geladene Quellpartitionen oder Hotkeys.

Versuchen Sie Folgendes, um dieses Problem zu beheben:

  • Ermitteln Sie die Ursache für die ungleichmäßige Beladung und versuchen Sie, das Problem zu beheben. Achten Sie beispielsweise darauf, dass die Quellpartitionen gleichmäßig verteilt sind.
  • Wenn es nicht möglich ist, die ungleichmäßige Last zu korrigieren, sollten Sie den VM-Typ des Workers ändern, um die Anzahl der vCPUs pro Worker zu erhöhen und die Spitzenlast zu senken. Weitere Informationen zum Konfigurieren von vCPUs pro Worker finden Sie unter Dataflow-Worker-VMs konfigurieren.
Problem bei der Kommunikation mit Workern

Dataflow kann nicht mit allen Worker-VMs kommunizieren. Prüfen Sie den Status der Worker-VMs des Jobs. Hier einige Gründe dafür:

  • Beim Bereitstellen der Worker-VMs ist ein Problem aufgetreten.
  • Der Worker-VM-Pool wird während der Ausführung des Jobs gelöscht.
  • Netzwerkprobleme.
Die Pub/Sub-Quelle hat Pull-Fehler.

Beim Abrufen von Daten aus der Pub/Sub-Quelle sind Fehler aufgetreten. Prüfen Sie, ob das erforderliche Thema und die erforderlichen Abos vorhanden sind, und überprüfen Sie das Kontingent und die Konfiguration. Sie können auch die Logs auf Fehler prüfen.

Pub/Sub-Quelle hat unzureichende Parallelität

Für die Berechnung der Pub/Sub-Quelle ist eine unzureichende Anzahl von Pub/Sub-Schlüsseln vorhanden. Wenn Sie die Anzahl der Schlüssel erhöhen möchten, legen Sie die Dienstoption num_pubsub_keys fest. Weitere Informationen finden Sie unter Pub/Sub-Quellenparallelität.

Pub/Sub-Quelle aus unbekanntem Grund gedrosselt

Die Berechnung der Pub/Sub-Quelle wird beim Lesen aus Pub/Sub aus unbekanntem Grund gedrosselt. Möglicherweise ist das ein vorübergehendes Problem. Prüfen Sie, ob es Probleme mit der Pub/Sub-Konfiguration, fehlende IAM-Berechtigungen oder Kontingentlimits gibt. Wenn jedoch keiner der oben genannten Bereiche die Ursache ist und das Problem weiterhin besteht, wenden Sie sich an den Support.

Veröffentlichung von Pub/Sub-Senken langsam oder hängt

Die Berechnung der Pub/Sub-Senke ist langsam oder hängt. Dieses Problem kann durch ein Konfigurationsproblem oder ein Kontingentlimit verursacht werden.

Lange Wartezeit in der Arbeitswarteschlange

Das älteste infrage kommende Arbeitsalter ist hoch, da eine große Anzahl von Schlüsseln und die Geschwindigkeit, mit der Schlüssel verarbeitet werden, berücksichtigt werden. In diesem Fall dauert jeder Vorgang möglicherweise nicht ungewöhnlich lange, aber die gesamte Wartezeit ist hoch.

Dataflow verwendet einen einzelnen Verarbeitungsthread pro Sharding-Schlüssel und die Anzahl der Verarbeitungsthreads ist begrenzt. Die Warteschlangenverzögerung entspricht ungefähr dem Verhältnis von Schlüsseln zu Threads multipliziert mit der On-Thread-Latenz für jedes Verarbeitungs-Bundle für einen Schlüssel:

(key count / total harness threads) * latency per bundle

Versuchen Sie Folgendes:

  • Erhöhen Sie die Anzahl der Worker. Weitere Informationen finden Sie unter Streaming-Autoscaling.
  • Erhöhen Sie die Anzahl der Worker-Harness-Threads. Legen Sie die Pipelineoption numberOfWorkerHarnessThreads / number_of_worker_harness_threads fest.
  • Verringern Sie die Anzahl der Schlüssel.
  • Die Latenz des Vorgangs verringern.
Vorübergehendes Problem mit dem Streaming Engine-Backend

Es gibt ein Konfigurations- oder Betriebsproblem mit dem Streaming Engine-Backend. Möglicherweise ist das ein vorübergehendes Problem. Wenn das Problem weiterhin besteht, wenden Sie sich bitte an den Support.

Unbestimmbare Ursache

Die Ursache des Rückstands kann nicht mit Sicherheit ermittelt werden. Möglicherweise ist das ein vorübergehendes Problem. Wenn das Problem weiterhin besteht, wenden Sie sich bitte an den Support.

Messwerte für Engpässe

Die folgenden Jobmesswerte liefern Informationen zu Engpässen:

Nächste Schritte