Descripción general de los conectores

En este documento, se proporciona una descripción general de los conectores de Kafka Connect enGoogle Cloud. Descubre cuándo usar cada tipo de conector para administrar e integrar tus flujos de datos.

Estos conectores usan el framework de Kafka Connect para integrar Apache Kafka con otras aplicaciones. Ingieren y replican datos entre tus clústeres y aplicaciones de Kafka. Los tipos de conectores disponibles incluyen los siguientes:

  • Conectores de MirrorMaker 2.0

    • Conector de origen

    • Conector de punto de control

    • Conector de latido

  • Conector de receptor de BigQuery

  • Conector de receptor de Cloud Storage

  • Conector de fuente de Pub/Sub

  • Conector de receptor de Pub/Sub

Los conectores de MirrorMaker 2.0 están diseñados específicamente para la replicación de datos y la recuperación ante desastres entre clústeres de Kafka. Facilitan la duplicación de datos de un clúster de Kafka a otro, lo que permite la alta disponibilidad y la tolerancia a errores.

Los conectores de MirrorMaker 2.0 pueden establecer conexiones entre clústeres de Managed Service para Apache Kafka y otros clústeres de Managed Service para Apache Kafka o clústeres de Kafka autoadministrados.

Los otros conectores de Sink y Source sirven para integrar Kafka con varios servicios deGoogle Cloud . Estos conectores permiten la transferencia de datos entre clústeres del Servicio administrado para Apache Kafka y servicios de Google Cloud , como BigQuery, Cloud Storage o Pub/Sub.

Antes de comenzar

Antes de explorar y crear conectores, asegúrate de comprender lo siguiente y cumplir con los requisitos previos:

Cuándo usar MirrorMaker 2.0

Usa los conectores de MirrorMaker 2.0 en las siguientes situaciones:

  • Migra datos: Mueve tu carga de trabajo de Kafka a un nuevo clúster de Managed Service for Apache Kafka.

  • Recuperación ante desastres: Crea un clúster de copia de seguridad para garantizar la continuidad empresarial en caso de fallas.

  • Agregación de datos: Consolida datos de varios clústeres de Kafka en un clúster central de Managed Service para Apache Kafka con fines analíticos.

Funciones clave de MirrorMaker 2.0

  • Replica todos los componentes necesarios, incluidos los temas, los datos, las configuraciones, los grupos de consumidores con desfases y las ACL.
  • Mantiene el mismo esquema de partición en el clúster de destino, lo que simplifica la transición para las aplicaciones.
  • Detecta y replica automáticamente nuevos temas y particiones, lo que minimiza la configuración manual.
  • Proporciona métricas esenciales, como la latencia de replicación de extremo a extremo, que te permiten hacer un seguimiento del estado y el rendimiento del proceso de replicación.
  • Garantiza un funcionamiento confiable, incluso con grandes volúmenes de datos, y se puede escalar horizontalmente para controlar el aumento de las cargas de trabajo.
  • Utiliza temas internos para la sincronización de desfase, los puntos de control y los latidos. Estos temas tienen factores de replicación configurables, como offset.syncs.topic.replication.factor, para garantizar la alta disponibilidad y la tolerancia a errores.

Usa el conector de fuente de MirrorMaker 2.0

El conector de origen de MirrorMaker 2.0 replica temas y datos de un clúster de Kafka (el origen) a otro clúster de Kafka (el destino).

Fuente Objetivo
Clúster de Managed Service para Apache Kafka Clúster de Managed Service para Apache Kafka
Clúster de Managed Service para Apache Kafka Clúster de Kafka externo o autoadministrado
Clúster de Kafka externo o autoadministrado Clúster de Managed Service para Apache Kafka

El conector de origen de MirrorMaker 2.0 admite las siguientes situaciones de migración:

  • Replica o migra datos de un clúster de Kafka externo o autoadministrado a un clúster de Managed Service para Apache Kafka

  • Replicar o migrar datos de un clúster de Managed Service para Apache Kafka a un clúster de Kafka externo o autoadministrado

  • Replica los datos de Kafka en diferentes regiones para satisfacer los requisitos de recuperación ante desastres y alta disponibilidad.

Usa el conector del punto de control de MirrorMaker 2.0

El uso del conector del punto de control de MirrorMaker 2.0 es opcional. Copia los desplazamientos del consumidor, que indican el último mensaje consumido correctamente. Este proceso garantiza que los consumidores del clúster de destino puedan reanudar el procesamiento desde el mismo punto que el clúster de origen.

Este conector no es necesario para que funcione el conector de origen de MirrorMaker 2.0. Este conector solo es necesario si necesitas sincronizar el estado de ConsumerGroup para minimizar el tiempo de inactividad durante un cambio del clúster de origen al de destino. Si solo necesitas una copia de tus datos de origen, no se requiere este conector.

Usa el conector del punto de control de MirrorMaker 2.0 para los siguientes casos de uso:

  • Recuperación ante desastres para mantener un estado coherente del consumidor en todos los clústeres y permitir una conmutación por error sin problemas

  • Preserva el progreso del consumidor en situaciones en las que es fundamental.

Usa el conector de señal de monitoreo de funcionamiento de MirrorMaker 2.0

El conector de la señal de monitoreo de funcionamiento de MirrorMaker 2.0 es un componente opcional que genera mensajes periódicos de señal de monitoreo de funcionamiento en el clúster de origen de Kafka. El conector escribe estos mensajes en un tema dedicado, que suele llamarse heartbeats.

Puedes configurar un conector de origen de MirrorMaker 2.0 para replicar el tema heartbeats en el clúster de destino. Si observas este tema replicado en el clúster de destino, puedes supervisar el estado y el rendimiento de tu flujo de replicación de temas. Esto proporciona una forma de verificar la conexión y el flujo de datos entre los clústeres, incluso cuando no se produce ni se replica ningún otro dato.

Implementar solo el conector de Heartbeat no supervisa automáticamente el estado de la replicación. Para usarlo con fines de supervisión, debes replicar el tema heartbeats y, luego, observar su presencia y puntualidad en el clúster de destino, o bien usar herramientas de supervisión que consuman estos latidos.

El conector Heartbeat no es necesario para que funcione el conector Source de MirrorMaker 2.0. Usa el conector de señal de monitoreo de funcionamiento de MirrorMaker 2.0 para los siguientes casos de uso:

  • Supervisa el estado de la replicación de MirrorMaker 2.

  • Configura alertas en Cloud Monitoring con los latidos generados y las métricas disponibles para recibir notificaciones cuando se detenga la replicación o el latido.

Usa conectores de receptor

Los conectores receptores exportan datos de temas de Kafka a otros sistemas.

Usa el conector de receptor de BigQuery

El conector receptor de BigQuery transmite datos de los temas de Kafka a las tablas de BigQuery.

Usa el conector de receptor de BigQuery para los siguientes casos de uso:

  • Almacenamiento de datos para cargar datos de transmisión en BigQuery para informes y análisis

  • Propagación de tablas de BigQuery que potencian los paneles en tiempo real

Usa el conector de receptor de Cloud Storage

El conector receptor de Cloud Storage transmite datos de temas de Kafka a buckets de Cloud Storage.

Usa el conector Cloud Storage Sink para los siguientes casos de uso:

  • Ingesta de data lake para almacenar datos de Kafka en un data lake para el procesamiento por lotes y el archivado a largo plazo

  • Archivar datos para cumplir con los requisitos reglamentarios

Usa el conector de receptor de Pub/Sub

El conector receptor de Pub/Sub transmite mensajes de temas de Kafka a un tema de Pub/Sub.

Usa el conector de receptor de Pub/Sub para los siguientes casos de uso:

  • Integración de servicios para enviar datos de Kafka a otros servicios o aplicaciones que consumen datos de Pub/Sub. Google Cloud

  • Activar notificaciones o acciones en tiempo real según los datos procesados

Usa conectores de origen

Los conectores de origen importan datos de otros sistemas a temas de Kafka.

Usa el conector de fuente de Pub/Sub

El conector de origen de Pub/Sub transmite mensajes de una suscripción a Pub/Sub a un tema de Kafka.

Usa el conector de fuente de Pub/Sub para los siguientes casos de uso:

  • Transferencia de datos en tiempo real, que trae datos de servicios en la nube o de otras aplicaciones y los publica en Pub/Sub en Kafka para el procesamiento de transmisiones

  • Arquitecturas controladas por eventos que activan el procesamiento basado en Kafka según los eventos publicados en Pub/Sub.

Política de reinicio de tareas

Puedes establecer la política de reinicio de tareas de un conector, que determina el comportamiento cuando se produce una falla. Los conectores admiten las siguientes políticas:

  • Nunca reinicies. El conector no reinicia las tareas con errores. Esta política es el comportamiento predeterminado. Es útil para la depuración o en situaciones en las que se requiere intervención manual después de un error.

  • Reinicia con una retirada exponencial. El conector reinicia una tarea fallida después de una demora (llamada período de reintento). La demora aumenta de forma exponencial con cada error posterior. Se recomienda esta política para la mayoría de las cargas de trabajo de producción.

    Si usas la política de retirada exponencial, también debes establecer valores para la retirada mínima y máxima. El tiempo de espera mínimo debe ser superior a 60 segundos y el tiempo de espera máximo debe ser inferior a 7, 200 segundos.

Transformaciones y predicados

Kafka Connect admite las transformaciones y los predicados predeterminados de Kafka.

Especificas la configuración como parte de la configuración del conector. Por ejemplo, para configurar un conector de receptor para que ignore los mensajes que contienen una clave de encabezado DoNotProcess, debes agregar la siguiente configuración a tu conector:

transforms=dropMessage
transforms.dropMessage.type=org.apache.kafka.connect.transforms.Filter
transforms.dropMessage.predicate=hasKey
predicates=hasKey
predicates.hasKey.type=org.apache.kafka.connect.transforms.predicates.HasHeaderKey
predicates.hasKey.name=DoNotProcess

Esta configuración hace lo siguiente:

  1. Configura un predicado llamado hasKey del tipo org.apache.kafka.connect.transforms.predicates.HasHeaderKey. Este predicado coincide con todos los mensajes que contienen un encabezado con la clave DoNotProcess.

  2. Configura una transformación llamada dropMessage del tipo org.apache.kafka.connect.transforms.Filter. Esta transformación descarta todos los mensajes que coinciden con el predicado configurado.

  3. Vincula la transformación al predicado hasKey. Esto garantiza que la transformación solo descarte los mensajes que tengan presente la clave del encabezado DoNotProcess.

Para obtener más información, consulta la documentación de Kafka sobre transformaciones y predicados.

Próximos pasos

Apache Kafka® es una marca registrada de The Apache Software Foundation o sus afiliados en Estados Unidos y otros países.