Este artículo es una publicación invitada escrita por Yaroslav Tkachenko, Arquitecto de Software de Activision.
Apache Spark es uno de los marcos de procesamiento de datos a gran escala más populares y potentes. Se creó como una alternativa al marco MapReduce de Hadoop para cargas de trabajo por lotes, pero ahora también admite SQL, aprendizaje automático y procesamiento de secuencias. Hoy quiero centrarme en la transmisión de Spark y mostrar algunas opciones disponibles para el procesamiento de transmisiones.
El procesamiento de datos de flujo se utiliza cuando se generan datos dinámicos de forma continua, y a menudo se encuentra en casos de uso de big data. En la mayoría de los casos, los datos se procesan en tiempo casi real, un registro a la vez, y los conocimientos derivados de los datos también se utilizan para proporcionar alertas, paneles de procesamiento y alimentar modelos de aprendizaje automático que pueden reaccionar rápidamente a las nuevas tendencias dentro de los datos.
DStreams vs. DataFrames
La transmisión de Spark pasó a ser alfa con Spark 0.7.0. Se basa en la idea de streams discretizados o DStreams. Cada DStream se representa como una secuencia de RDD, por lo que es fácil de usar si proviene de cargas de trabajo por lotes respaldadas por RDD de bajo nivel. Los DStreams experimentaron muchas mejoras durante ese período de tiempo, pero aún había varios desafíos, principalmente porque es una API de muy bajo nivel.
Como solución a esos desafíos, la transmisión estructurada de Spark se introdujo en Spark 2.0 (y se volvió estable en 2.2) como una extensión construida sobre Spark SQL. Por eso, aprovecha el código SQL de Spark y las optimizaciones de memoria. La transmisión estructurada también proporciona abstracciones muy potentes, como API de Dataset / DataFrame y SQL. ¡No más tratos con RDD directamente!
Tanto el Streaming estructurado como el Streaming con DStreams utilizan micro-lotes. La mayor diferencia es la latencia y las garantías de entrega de mensajes: La transmisión estructurada ofrece entrega de una sola vez con latencia de más de 100 milisegundos, mientras que el enfoque de transmisión con DStreams solo garantiza la entrega de al menos una vez, pero puede proporcionar latencias de milisegundos.
Personalmente prefiero la transmisión estructurada de Spark para casos de uso simples, pero la transmisión de Spark con DStreams es realmente buena para topologías más complicadas debido a su flexibilidad. Es por eso que a continuación quiero mostrar cómo usar la transmisión con DStreams y la Transmisión con DataFrames (que generalmente se usa con la transmisión estructurada de Spark) para consumir y procesar datos de Apache Kafka. Voy a usar Scala, Apache Spark 2.3 y Apache Kafka 2.0.
Además, como ejemplo, ejecutaré mis trabajos utilizando cuadernos Apache Zeppelin proporcionados por Qubole. Qubole es una plataforma de datos que uso a diario. Gestiona clústeres Hadoop y Spark, facilita la ejecución de consultas ad hoc Hive y Presto, y también proporciona cuadernos Zeppelin administrados que uso con gusto. Con Qubole no necesito pensar mucho en configurar y afinar Spark y Zeppelin, solo se maneja para mí.
El caso de uso real que tengo es muy sencillo:
- Se escribe algún tipo de telemetría a Kafka: mensajes JSON pequeños con metadatos y pares de clave/valor arbitrarios
- Quiero conectarme a Kafka, consumir y deserializar esos mensajes
- Luego aplicar transformaciones si es necesario
- Recopilar algunas agregaciones
- Finalmente, estoy interesado en anomalías y datos generalmente incorrectos, ya que no controlo al productor, quiero capturar cosas como NULOs, cadenas vacías, quizás fechas incorrectas y otros valores con formatos específicos, etc.
- El trabajo debe ejecutarse durante algún tiempo, terminará automáticamente. Por lo general, los trabajos de transmisión de Spark se ejecutan de forma continua, pero a veces puede ser útil ejecutarlos ad hoc para análisis/depuración (o como ejemplo en mi caso, ya que es muy fácil ejecutar un trabajo de Spark en un cuaderno).
Streaming con DStreams
En este enfoque utilizamos DStreams, que es simplemente una colección de RDDs.
Streaming con DataFrames
Ahora podemos intentar combinar Streaming con API de DataFrames para obtener lo mejor de ambos mundos!
Conclusión
¿Qué enfoque es mejor? Dado que DStream es solo una colección de RDDs, normalmente se usa para transformaciones y procesamiento de bajo nivel. Agregar una API de DataFrames además de eso proporciona abstracciones muy potentes como SQL, pero requiere un poco más de configuración. Y si tiene un caso de uso simple, la transmisión estructurada de Spark podría ser una mejor solución en general.