Pipeline de flux de données - "Traitement bloqué à l'étape <STEP_NAME> pendant au moins <TIME> sans sortie ni achèvement à la fin de l'état ..."
Les pipelines Dataflow développés par mon équipe ont soudainement commencé à se bloquer, arrêtant de traiter nos événements. Leurs journaux de travail sont devenus pleins de messages d'avertissement disant qu'une étape spécifique était bloquée. La particularité est que les étapes qui échouent sont différentes, l'une est une sortie BigQuery et une autre pour la sortie Cloud Storage.
Voici les messages de journal que nous recevons:
Pour la sortie BigQuery:
Processing stuck in step <STEP_NAME>/StreamingInserts/StreamingWriteTables/StreamingWrite for at least <TIME> without outputting or completing in state finish
at Sun.misc.Unsafe.park(Native Method)
at Java.util.concurrent.locks.LockSupport.park(LockSupport.Java:175)
at Java.util.concurrent.FutureTask.awaitDone(FutureTask.Java:429)
at Java.util.concurrent.FutureTask.get(FutureTask.Java:191)
at org.Apache.beam.sdk.io.gcp.bigquery.BigQueryServicesImpl$DatasetServiceImpl.insertAll(BigQueryServicesImpl.Java:765)
at org.Apache.beam.sdk.io.gcp.bigquery.BigQueryServicesImpl$DatasetServiceImpl.insertAll(BigQueryServicesImpl.Java:829)
at org.Apache.beam.sdk.io.gcp.bigquery.StreamingWriteFn.flushRows(StreamingWriteFn.Java:131)
at org.Apache.beam.sdk.io.gcp.bigquery.StreamingWriteFn.finishBundle(StreamingWriteFn.Java:103)
at org.Apache.beam.sdk.io.gcp.bigquery.StreamingWriteFn$DoFnInvoker.invokeFinishBundle(Unknown Source)
Pour la sortie Cloud Storage:
Processing stuck in step <STEP_NAME>/WriteFiles/WriteShardedBundlesToTempFiles/WriteShardsIntoTempFiles for at least <TIME> without outputting or completing in state process
at Sun.misc.Unsafe.park(Native Method)
at Java.util.concurrent.locks.LockSupport.park(LockSupport.Java:175)
at Java.util.concurrent.FutureTask.awaitDone(FutureTask.Java:429)
at Java.util.concurrent.FutureTask.get(FutureTask.Java:191)
at com.google.cloud.hadoop.util.AbstractGoogleAsyncWriteChannel.waitForCompletionAndThrowIfUploadFailed(AbstractGoogleAsyncWriteChannel.Java:421)
at com.google.cloud.hadoop.util.AbstractGoogleAsyncWriteChannel.close(AbstractGoogleAsyncWriteChannel.Java:287)
at org.Apache.beam.sdk.io.FileBasedSink$Writer.close(FileBasedSink.Java:1007)
at org.Apache.beam.sdk.io.WriteFiles$WriteShardsIntoTempFilesFn.processElement(WriteFiles.Java:726)
at org.Apache.beam.sdk.io.WriteFiles$WriteShardsIntoTempFilesFn$DoFnInvoker.invokeProcessElement(Unknown Source)
Toutes les applications ont été vidées et redéployées mais la même chose s'est produite après un certain temps (période de 3 à 4 heures). Certains d'entre eux fonctionnaient depuis plus de 40 jours et ils s'y sont soudainement retrouvés sans aucune modification du code.
Je voudrais demander de l'aide pour connaître la raison de ce problème. Voici les identifiants suivants de certains des travaux Dataflow avec ces problèmes:
Coincé dans la sortie BigQuery: 2019-03-04_04_46_31-390197710764972657
Sortie bloquée dans Cloud Storage: 2019-03-04_07_50_00-10623118563101608836
Le Processing stuck les messages n'impliquent pas nécessairement que votre pipeline est réellement bloqué. Ces messages sont enregistrés par un travailleur qui effectue la même opération depuis plus de 5 minutes.
Souvent, cela indique simplement une opération lente: un RPC externe ou en attente d'un processus externe (très courant lors de l'exécution de travaux de chargement ou de requête vers BigQuery).
Si vous voyez ce type de messages se produire beaucoup dans votre pipeline, ou de plus en plus à des nombres plus élevés (5m, 10m, 50m, 1h, etc.), cela indique probablement un blocage - mais si vous le voyez de temps en temps dans votre pipeline, il n'y a rien à craindre.
Il convient de noter que dans les anciennes versions de Beam (de 2.5.0 à 2.8.0), il y avait un problème de blocage avec la bibliothèque Conscrypt qui était utilisée comme fournisseur de sécurité par défaut. Depuis Beam 2.9.0, Conscrypt n'est plus le fournisseur de sécurité par défaut .
Une autre option consiste à rétrograder vers Beam 2.4.0, où conscrypt n'était pas non plus le fournisseur par défaut.
Je rencontrais la même erreur et la raison en était que j'avais créé une table BigQuery vide sans spécifier de schéma. Assurez-vous de créer une table BQ avec un schéma avant de pouvoir charger des données via Dataflow.
J'ai le même problème, j'ai découvert que le cas le plus courant est parce que l'un des travaux n'a pas pu être inséré dans la table BigQuery ou n'a pas enregistré le fichier dans le compartiment CGS (très rare). Le thread en charge n'attrape pas l'exception et attend toujours le travail. Il s'agit d'un bug d'Apache Beam et j'ai déjà créé un ticket pour cela.
https://issues.Apache.org/jira/plugins/servlet/mobile#issue/BEAM-769
Voyons si les gars d'Apache Beam résolvent ce problème (il s'agit littéralement d'une exception non gérée).
Jusqu'à présent ma recommandation est de valider les contraintes de vos données avant l'insertion. Gardez donc à l'esprit des choses comme: 1) Taille maximale de la ligne (en ce moment 2019 est 1 Mo pour l'insertion de flux et 100 Mo pour le lot) 2) Les valeurs requises qui ne viennent pas devraient créer une lettre morte avant et ne pas être en mesure d'atteindre le travail 3) Si vous avez des champs inconnus, n'oubliez pas d'activer l'option ignoreUnknownFields (sinon ils feront mourir votre travail)
Je présume que vous ne rencontrez des problèmes qu'aux heures de pointe, car d'autres événements "insatisfaits" arrivent.
J'espère que cela pourrait aider un peu