Google Cloud Dataflow ofrece un sistema de procesamiento de datos totalmente gestionado para ejecutar flujos de procesamiento de Apache Beam en Google Cloud de una manera altamente escalable. Debido a que es un servicio totalmente gestionado, los usuarios de Dataflow no tienen que preocuparse por las regresiones y versiones del lado del servicio. Te garantizamos que solo deberás ocuparte de tu lógica de flujo de procesamiento mientras Google se encarga de la infraestructura de servicios. Por otro lado, Apache Beam en sí es un SDK muy completo que proporciona muchas transformaciones tanto simples como altamente complejas para que las utilices en sus flujos de procesamiento. Por ejemplo, incluye una serie de conectores de E/S, muchos de los cuales son transformaciones compuestas de Apache Beam con decenas a centenares de pasos. Históricamente, estos se consideraban "código de usuario" desde la perspectiva del servicio, a pesar de no haber sido creados ni mantenidos por el usuario. Hay varias complicaciones comunes que los clientes encuentran en las transformaciones de Beam complejas, como los conectores de E/S.
Para resolver estos tres problemas, Dataflow presentó recientemente una nueva oferta llamada E/S administrada. Con ella, el servicio en sí es capaz de administrar estas complejidades por ti. De esta manera, puedes centrarte en la lógica empresarial de sus flujos de procesamiento, y no en las minucias relacionadas con el uso y la configuración de un conector específico para satisfacer sus necesidades. A continuación, detallamos cómo se abordan cada una de las complejidades mencionadas anteriormente a través de la E/S administrada.
Apache Beam es un SDK completo con muchas transformaciones, funciones y optimizaciones. Al igual que muchas piezas grandes de software, actualizar Beam a una nueva versión puede ser un proceso importante. Por lo general, la actualización de Beam implica actualizar todas las partes de un flujo de procesamiento, incluidos todos los conectores de E/S. Sin embargo, otras veces solo necesitas obtener acceso a una corrección de errores críticos o una mejora disponible en la última versión de uno o más conectores de E/S utilizados en tu flujo de procesamiento.
Managed I/O with Dataflow simplifies this by completely taking over the management of the Beam I/O connector version. With Managed I/O, Dataflow will make sure that I/O connectors used by pipelines are always up to date. Dataflow performs this by always upgrading I/O connectors to the latest vetted version during job submission and streaming update via replacement.
For example, assume that you use a Beam pipeline that uses Beam 2.x.0 and assume that you use the Managed Apache Iceberg I/O source in your pipeline. Also, assume that the latest vetted version of the Iceberg I/O source supported by Dataflow is 2.y.0. During job submission, Dataflow will replace this specific connector with version 2.y.0 and will keep the rest of the Beam pipeline including any standard (non-managed) I/O connectors at version 2.x.0.
Después del reemplazo, Dataflow optimiza el flujo de procesamiento actualizado y lo ejecuta en GCE. Para lograr el aislamiento entre los conectores de diferentes versiones de Beam, Dataflow implementa un contenedor adicional de SDK de Beam en las VMs de GCE. Entonces, en este caso, los contenedores Beam SDK de ambas versiones (2.x.0 y 2.y.0) se ejecutarán en cada VM de GCE utilizada por el trabajo de Dataflow.
Por ende, con la E/S administrada, te aseguramos que los conectores de E/S usados en tu flujo de procesamiento siempre estarán actualizados. Esto te permitirá enfocarte en mejorar la lógica empresarial de tu flujo sin preocuparte por actualizar la versión de Beam solo para obtener las actualizaciones de los conectores de E/S.
Las diferencias de APIs entre los conectores de E/S de Beam varían significativamente. Esto significa que, cuando quieras usar un nuevo conector de E/S de Beam, deberías aprender una API específica de ese conector. Algunas APIs son grandes y poco intuitivas. Estas son algunas de las razones:
Los puntos anteriores dan como resultado superficies de API muy grandes para algunos conectores que no son intuitivas y no permiten que los nuevos clientes las usen con eficacia.
Managed I/O offers standardized Java and Python APIs for supported I/O connectors. For example, with Beam Java SDK an I/O connector source can be instantiated in the following standardized form.
Managed.read(SOURCE).withConfig(sourceConfig)
An I/O connector sink can be instantiated in the following form.
Managed.write(SINK).withConfig(sinkConfig)
Here SOURCE and SINK are keys specifically identifying the connector while sourceConfig and sinkConfig are maps of configurations used to instantiate the connector source or sink. The map of configurations may also be provided as YAML files available locally or in Google Cloud Storage. Please see the Managed I/O website for more complete examples for supported sources and sinks.
El SDK de Python de Beam ofrece una API simplificada de manera similar.
Esto significa que diversos conectores de E/S de Beam pueden crearse en instancias con diferentes APIs de manera estándar. Por ejemplo:
// Crea una fuente de E/S de Java BigQuery
Map<String, Object> bqReadConfig = ImmutableMap.of("query", "<query>", ...);
Managed.read(Managed.BIGQUERY).withConfig(bqReadConfig)
// Crea una fuente de Java Kafka.
Map<String, Object> kafkaReadConfig = ImmutableMap.of("bootstrap_servers", "<server>", "topic", "<topic>", ...);
Managed.read(Managed.KAFKA).withConfig(kafkaReadConfig)
// Crea una fuente de Java Kafka, pero con una configuración basada en YAML disponible eb Google Cloud Storage.
String kafkaReadYAMLConfig = "gs://path/to/config.yaml"
Managed.read(Managed.KAFKA).withConfigUrl(kafkaReadYAMLConfig)
// Create a Python Iceberg I/O source.
iceberg_config = {"table": "<table>", ...}
managed.Read(managed.ICEBERG, config=iceberg_config)
Muchos conectores de Beam ofrecen una API completa para configurar y optimizar el conector a fin de que se adapte a un flujo de procesamiento y un ejecutor de Beam determinados. Una desventaja de este caso es que, si quieres específicamente ejecutar en Dataflow, es posible que debas aprender las configuraciones específicas más adecuadas para Dataflow y las apliques cuando configures tu flujo de procesamiento. La documentación sobre conectores es extensa y detallada, y los cambios específicos necesarios podrían no ser intuitivos. Como consecuencia, es posible que los conectores usados en flujos de procesamiento de Dataflow no tengan un rendimiento óptimo.
Los conectores de E/S administrada resuelven este problema reconfigurando automáticamente los conectores para incorporar las prácticas recomendadas y configurarlos a fin de que se adapten a Dataflow. Esa reconfiguración podría ocurrir durante el envío del trabajo o por una actualización de transmisión por reemplazo.
Por ejemplo, los flujos de procesamiento de transmisión ofrecen dos modos: exactamente una vez y al menos una vez, mientras que el receptor de E/S de BigQuery con la API de Storage Write ofrece dos semánticas de entrega análogas: exactamente una vez y al menos una vez. El receptor de BigQuery con semántica de entrega al menos una vez suele ser menos costoso y generar latencias más bajas. Con los conectores de E/S estándar de BigQuery, debes asegurarte de aplicar el modo apropiado al usar la E/S de BigQuery. Con el receptor de E/S administrada de BigQuery, esto se configura automáticamente. Por lo tanto, si tu flujo de procesamiento de transmisión está funcionando en el modo de al menos una vez, tu receptor de E/S administrada de BigQuery se configurará automáticamente para usar la misma semántica de entrega.
Ejecutamos varios flujos de procesamiento que escribieron datos utilizando el receptor de E/S administrada de Iceberg respaldado por un catálogo de Hadoop implementado en GCS (consulta aquí los otros catálogos compatibles). Los flujos de procesamiento se enviaron utilizando Beam 2.61.0 y Dataflow actualizó el receptor de E/S administrada automáticamente por Dataflow a la versión compatible más reciente. Todos los puntos de referencia usaron VMs n1-standard-4 y la cantidad de VMs usadas por el flujo se fijó en 100. Nota: El tiempo de ejecución en este caso no incluye los tiempos de inicio ni apagado.
Como se ve en los puntos de referencia, la E/S administrada de Iceberg escaló correctamente y ambos puntos crecieron linealmente con el tamaño de los datos.
También ejecutamos un flujo de procesamiento de transmisión que leía desde Google Pub/Sub y usamos el receptor de E/S administrada de Kafka para enviar mensajes a un clúster de Kafka alojado en GCP. El flujo utilizó Beam 2.61.0 y Dataflow actualizó el receptor de Kafka a la última versión compatible. Durante el estado constante, el flujo utilizó 10 VMs n1-standard-4 (máx.: 20 VMs), procesó continuamente mensajes a un rendimiento de 250,000 msj/s en todos los pasos y se ejecutó durante 2 horas.
El siguiente gráfico muestra los rendimientos de datos de varios pasos del flujo de procesamiento. Nota: Los rendimientos son diferentes porque el tamaño de los elementos cambia de un paso a otro. El flujo leyó de Pub/Sub a una velocidad de 75 MiB/s (línea roja) y escribió en Kafka a una velocidad de 40 MiB/s (línea verde).
Tanto la latencia como el trabajo acumulado fueron bajos durante la ejecución del flujo de procesamiento.
El flujo utilizó la CPU y la memoria de la VM de manera eficiente.
Como muestran estos resultados, el flujo de procesamiento se ejecutó con eficiencia con el receptor de E/S administrada de Kafka provisto por el servicio de Dataflow.
Usar E/S administradas es tan simple como usar una fuente o un receptor compatibles en tu flujo de procesamiento y ejecutarlo con Dataflow Runner v2. Cuando ejecutes tu flujo de procesamiento, Dataflow se asegurará de que las últimas versiones verificadas de las fuentes y los receptores estén habilitadas durante el envío de trabajos y la actualización de transmisión por reemplazo, incluso aunque uses una versión anterior de Beam.
