Cet article est une publication invitée écrite par Yaroslav Tkachenko, 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 de Hadoop pour les charges de travail par lots, mais il prend désormais également en charge le SQL, l’apprentissage automatique et le traitement des flux. Aujourd’hui, je veux me concentrer sur le streaming Spark et montrer quelques options disponibles pour le traitement des flux.
Le traitement des données de flux est utilisé lorsque des données dynamiques sont générées en continu, et on le trouve 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 informations dérivées des données sont également utilisées pour fournir des alertes, afficher des tableaux de bord et alimenter des modèles d’apprentissage automatique capables de réagir rapidement aux nouvelles tendances dans les données.
DStreams vs DataFrames
Le streaming Spark est devenu 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 RDD, il est donc facile à utiliser si vous venez de charges de travail batch de bas niveau soutenues par RDD. DStreams a subi de nombreuses 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 solution à ces défis, le streaming structuré Spark a été introduit dans Spark 2.0 (et est devenu stable en 2.2) en tant qu’extension construite au-dessus de Spark SQL. Pour cette raison, il tire parti du code SQL Spark et des optimisations de la mémoire. Le streaming structuré donne également des abstractions très puissantes comme les API Dataset / DataFrame ainsi que SQL. Plus besoin de traiter directement avec RDD!
Le streaming structuré et le streaming avec DStreams utilisent le micro-dosage. La plus grande différence est la latence et les garanties de diffusion des messages: Le streaming structuré offre une diffusion exactement une fois avec une latence de plus de 100 millisecondes, alors que l’approche du streaming avec DStreams ne garantit qu’une diffusion au moins une fois, mais peut fournir des latences de millisecondes.
Personnellement, je préfère le streaming structuré Spark pour les cas d’utilisation simples, mais le streaming Spark avec DStreams est vraiment bon pour les topologies plus compliquées en raison de sa flexibilité. C’est pourquoi je veux montrer ci-dessous comment utiliser le streaming avec DStreams et le Streaming avec des trames de données (qui est généralement utilisé avec le streaming structuré Spark) pour consommer et traiter les données d’Apache Kafka. Je vais utiliser Scala, Apache Spark 2.3 et Apache Kafka 2.0.
De plus, par exemple, je vais exécuter mes travaux en utilisant des ordinateurs portables Apache Zeppelin fournis par Qubole. Qubole est une plateforme de données que j’utilise quotidiennement. Il gère les clusters Hadoop et Spark, facilite l’exécution de requêtes Ad hoc Hive et Presto et fournit également des ordinateurs portables Zeppelin gérés que j’utilise avec plaisir. Avec Qubole, je n’ai pas besoin de penser beaucoup à la configuration et au réglage de Spark et Zeppelin, c’est juste 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 sur 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 des agrégations
- Enfin, je m’intéresse aux anomalies et aux données généralement mauvaises — puisque je ne contrôle pas le producteur, je veux attraper des choses comme des valeurs nulles, des chaînes vides, peut-être des dates incorrectes et d’autres valeurs avec des formats spécifiques, etc.
- La tâche doit s’exécuter pendant un certain temps, puis se terminer automatiquement. En règle générale, les travaux de streaming Spark s’exécutent en continu, mais il peut parfois être utile de l’exécuter ad hoc pour l’analyse / le débogage (ou à titre d’exemple dans mon cas, car il est si facile d’exécuter un travail Spark dans un bloc-notes).
Streaming avec DStreams
Dans cette approche, nous utilisons DStreams, qui est simplement une collection de RDD.
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? Étant donné que DStream n’est qu’une collection de RDD, il est généralement utilisé pour les transformations et les traitements de bas niveau. L’ajout d’une API DataFrames en plus de 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, le streaming structuré Spark pourrait être une meilleure solution en général!