Ce post est une publication invitée écrite par Yaroslav Tkachenko, un architecte logiciel chez Activision.

Apache Spark est l’un des frameworks de traitement de données à grande échelle les plus populaires et les plus puissants. Il a été créé comme une alternative au framework MapReduce d’Hadoop pour les charges de travail par lots, mais maintenant il prend également en charge SQL, l’apprentissage automatique et le traitement en flux. Aujourd’hui, je veux me concentrer sur Spark Streaming et montrer quelques options disponibles pour le traitement de flux.

Le traitement de données en flux est utilisé lorsque des données dynamiques sont générées en continu, et on le retrouve souvent dans les cas d’utilisation du big data. Dans la plupart des cas, les données sont traitées en temps quasi réel, un enregistrement à la fois, et les aperçus dérivés des données sont également utilisés pour fournir des alertes, rendre des tableaux de bord et alimenter des modèles d’apprentissage automatique qui peuvent réagir rapidement aux nouvelles tendances au sein des données.

DStreams vs. DataFrames

Spark Streaming est passé en alpha avec Spark 0.7.0. Il est basé sur l’idée de flux discrétisés ou DStreams. Chaque DStream est représenté comme une séquence de RDDs, il est donc facile à utiliser si vous venez de charges de travail batch de bas niveau soutenues par des RDDs. DStreams a subi beaucoup d’améliorations au cours de cette période, mais il y avait encore divers défis, principalement parce que c’est une API de très bas niveau.

Comme une solution à ces défis, Spark Structured Streaming a été introduit dans Spark 2.0 (et est devenu stable dans 2.2) comme une extension construite sur le dessus de Spark SQL. De ce fait, il tire parti des optimisations de code et de mémoire de Spark SQL. Structured Streaming offre également des abstractions très puissantes comme les API Dataset/DataFrame ainsi que SQL. Plus besoin de traiter directement avec les RDD !

Le Streaming structuré et le Streaming avec DStreams utilisent tous deux le micro-batching. La plus grande différence réside dans les garanties de latence et de livraison des messages : Le Streaming structuré offre une livraison exactement une fois avec une latence de 100+ millisecondes, tandis que l’approche Streaming with DStreams ne garantit qu’une livraison au moins une fois, mais peut fournir des latences de quelques millisecondes.

Je préfère personnellement Spark Structured Streaming pour les cas d’utilisation simples, mais Spark Streaming with DStreams est vraiment bon pour les topologies plus compliquées en raison de sa flexibilité. C’est pourquoi, ci-dessous, je veux montrer comment utiliser Streaming with DStreams et Streaming with DataFrames (qui est généralement utilisé avec Spark Structured Streaming) pour consommer et traiter des données provenant d’Apache Kafka. Je vais utiliser Scala, Apache Spark 2.3 et Apache Kafka 2.0.

De plus, pour les besoins de l’exemple, je vais exécuter mes travaux en utilisant les notebooks Apache Zeppelin fournis par Qubole. Qubole est une plateforme de données que j’utilise quotidiennement. Elle gère les clusters Hadoop et Spark, facilite l’exécution de requêtes ad hoc Hive et Presto, et fournit également des notebooks Zeppelin gérés que j’utilise volontiers. Avec Qubole, je n’ai pas besoin de penser beaucoup à la configuration et au réglage de Spark et Zeppelin, c’est simplement géré pour moi.

Le cas d’utilisation réel que j’ai est très simple:

• Une sorte de télémétrie est écrite à Kafka : petits messages JSON avec des métadonnées et des paires clé/valeur arbitraires
• Je veux me connecter à Kafka, consommer et désérialiser ces messages
• Puis appliquer des transformations si nécessaire
• Collecter quelques agrégations
• Finalement, Je suis intéressé par les anomalies et les mauvaises données en général – puisque je ne contrôle pas le producteur, je veux attraper des choses comme les NULL, les chaînes vides, peut-être des dates incorrectes et d’autres valeurs avec des formats spécifiques, etc.
• Le job devrait s’exécuter pendant un certain temps, puis se terminer automatiquement. Typiquement, les jobs Spark Streaming s’exécutent en continu, mais parfois il peut être utile de l’exécuter de manière ad hoc pour l’analyse/le débogage (ou comme exemple dans mon cas, puisqu’il est si facile d’exécuter un job Spark dans un notebook).

Streaming avec DStreams

Dans cette approche, nous utilisons DStreams, qui est simplement une collection de RDDs.

Streaming avec DataFrames

Maintenant, nous pouvons essayer de combiner le Streaming avec l’API DataFrames pour obtenir le meilleur des deux mondes !

Conclusion

Quelle approche est la meilleure ? Comme DStream n’est qu’une collection de RDD, il est généralement utilisé pour des transformations et des traitements de bas niveau. L’ajout d’une API DataFrames par-dessus cela fournit des abstractions très puissantes comme SQL, mais nécessite un peu plus de configuration. Et si vous avez un cas d’utilisation simple, Spark Structured Streaming pourrait être une meilleure solution en général!