Características de rendimiento de las canalizaciones de Kafka a BigQuery

En esta página, se describen las características de rendimiento de los trabajos de transmisión de Dataflow que leen datos de Apache Kafka y escriben en BigQuery. Proporciona resultados de pruebas comparativas para canalizaciones de solo mapa, que realizan transformaciones por mensaje sin hacer un seguimiento del estado ni agrupar elementos en el flujo.

Muchas cargas de trabajo de integración de datos, incluidas las de ETL, la validación de campos y la asignación de esquemas, se incluyen en la categoría de solo asignación. Si tu canalización sigue este patrón, puedes usar estos comparativos para evaluar tu trabajo de Dataflow en comparación con una configuración de referencia con buen rendimiento.

Metodología de prueba

Las comparativas se realizaron con los siguientes recursos:

Un clúster de Managed Service para Apache Kafka. Los mensajes se generaron con la plantilla del Generador de datos de transmisión.
- Tasa de mensajes: Aproximadamente 1,000,000 de mensajes por segundo
- Carga de entrada: 1 GiB/s
- Formato del mensaje: Texto JSON generado de forma aleatoria con un esquema fijo
- Tamaño del mensaje: Aproximadamente 1 KiB por mensaje
- Particiones de Kafka: 1000
Una tabla de BigQuery estándar
Una canalización de transmisión de Dataflow que usó la plantilla de Apache Kafka a BigQuery. Esta canalización realiza el análisis y la asignación de esquemas mínimos requeridos. No se usó ninguna función definida por el usuario (UDF) personalizada.

Después de que se estabilizó el ajuste de escala horizontal y la canalización alcanzó un estado estable, se permitió que las canalizaciones se ejecutaran durante aproximadamente un día, tras lo cual se recopilaron y analizaron los resultados.

Canalización de Dataflow

Esta comparativa utiliza una canalización solo de asignación que realiza una asignación y conversión simples de mensajes JSON. La canalización se probó con el modo exactamente una vez y el modo al menos una vez. El procesamiento al menos una vez proporciona una mejor capacidad de procesamiento. Sin embargo, solo se debe usar cuando se aceptan registros duplicados o el receptor descendente controla la anulación de duplicación.

Configuración del trabajo

En la siguiente tabla, se muestra cómo se configuraron los trabajos de Dataflow.

Configuración	Valor
Tipo de máquina del trabajador	`e2-standard-2`
CPU virtuales de la máquina de trabajo	2
RAM de la máquina del trabajador	8 GB
Persistent Disk de la máquina de trabajo	Disco persistente estándar (HDD), 30 GB
Cantidad máxima de trabajadores	120
Streaming Engine	Sí
Ajuste de escala automático horizontal	Sí
Modelo de facturación	Facturación basada en recursos
¿Está habilitada la API de Storage Write?	Sí
Transmisiones de la API de Storage Write	400
Frecuencia de activación de la API de Storage Write	5 segundos
Formato de mensaje	JSON
Modo de autenticación de Kafka	Credenciales predeterminadas de la aplicación (ADC). Para obtener más información, consulta Tipos de autenticación para los intermediarios de Kafka.

Se recomienda la API de BigQuery Storage Write para las canalizaciones de transmisión. Cuando usas el modo “exactamente una vez” con la API de Storage Write, puedes ajustar los siguientes parámetros de configuración:

Cantidad de transmisiones de escritura. Para garantizar un paralelismo de claves suficiente en la etapa de escritura, establece la cantidad de transmisiones de la API de Storage Write en un valor mayor que la cantidad de CPU de los trabajadores, y sigue las recomendaciones de rendimiento por transmisión.
Frecuencia de activación. Un valor de segundo de un solo dígito es adecuado para las canalizaciones de alto rendimiento.

Para obtener más información, consulta Escribe desde Dataflow a BigQuery.

También se debe prestar especial atención a la cantidad de particiones de Apache Kafka. Para garantizar un paralelismo de claves suficiente en la etapa de lectura, la cantidad de particiones debe ser, al menos, igual a la cantidad total de CPU virtuales de los trabajadores. Para obtener más información, consulta Lee desde Apache Kafka a Dataflow.

Resultados de comparativas

En esta sección, se describen los resultados de las pruebas de comparativas.

Capacidad de procesamiento y uso de recursos

En la siguiente tabla, se muestran los resultados de las pruebas de capacidad de procesamiento de la canalización y uso de recursos.

Resultado	Exactamente una vez	Al menos una vez
Capacidad de procesamiento de entrada por trabajador	Media: 15 MB/s, n=3	Media: 18 MBps, n=3
Uso promedio de CPU en todos los trabajadores	Media: 70%, n=3	Media: 75%, n=3
Cantidad de nodos trabajadores	Media: 63, n=3	Media: 53, n=3
Unidades de procesamiento de Streaming Engine por hora	Media: 58, n=3	Media: 0, n=3

El algoritmo de ajuste de escala automático puede afectar el nivel de uso objetivo de la CPU. Para lograr un uso de CPU objetivo más alto o más bajo, puedes establecer el rango de ajuste de escala automático o la sugerencia de uso del trabajador. Los objetivos de utilización más altos pueden generar costos más bajos, pero también una peor latencia final, en especial para cargas variables.

Latencia

En la siguiente tabla, se muestran los resultados de la comparativa de la latencia de la canalización para el modo de procesamiento exacto una vez, sin incluir la etapa de entrada.

Latencia total de extremo a extremo de la etapa, sin incluir la etapa de entrada	Exactamente una vez
P50	Media: 1,200 ms, n=3
P95	Media: 3,000 ms, n=3
P99	Media: 5,400 ms, n=3

Las pruebas midieron la latencia de extremo a extremo por etapa (la métrica de job/streaming_engine/stage_end_to_end_latencies) en tres ejecuciones de pruebas de larga duración. Esta métrica mide cuánto tiempo dedica el motor de transmisión a cada etapa de la canalización. Abarca todos los pasos internos de la canalización, como los siguientes:

Mezcla y encola mensajes para su procesamiento
El tiempo de procesamiento real; por ejemplo, la conversión de mensajes en objetos de fila
Escritura de estado persistente, así como el tiempo dedicado a poner en cola la escritura de estado persistente

Debido a una limitación de la métrica, no se informa la latencia de la etapa de entrada. Por lo tanto, no se incluye en el total.

Los comparativos que se muestran aquí representan un valor de referencia. La latencia es muy sensible a la complejidad de la canalización. Las UDF personalizadas, las transformaciones adicionales y la lógica de ventanas compleja pueden aumentar la latencia.

Estimación de costos

Para estimar el costo de referencia de tu propia canalización comparable con la facturación basada en recursos, usa la calculadora de precios de Google Cloud Platform de la siguiente manera:

Abre la calculadora de precios.
Haz clic en Agregar a la estimación.
Selecciona Dataflow.
En Tipo de servicio, selecciona "Dataflow clásico".
Selecciona Configuración avanzada para mostrar el conjunto completo de opciones.
Elige la ubicación en la que se ejecutará el trabajo.
En Tipo de trabajo, selecciona "Transmisión".
Selecciona Habilitar Streaming Engine.
Ingresa información sobre las horas de ejecución del trabajo, los nodos de trabajador, las máquinas de trabajador y el almacenamiento en Persistent Disk.
Ingresa la cantidad estimada de unidades de procesamiento de Streaming Engine.

El uso de recursos y el costo se ajustan de forma casi lineal con el rendimiento de entrada, aunque, para los trabajos pequeños con solo unos pocos trabajadores, el costo total está dominado por los costos fijos. Como punto de partida, puedes extrapolar la cantidad de nodos trabajadores y el consumo de recursos a partir de los resultados de la comparativa.

Por ejemplo, supongamos que ejecutas una canalización solo de mapa en el modo exactamente una vez, con una tasa de datos de entrada de 100 MiB/s. Según los resultados de la comparativa para una canalización de 1 GiB/s, puedes estimar los requisitos de recursos de la siguiente manera:

Factor de ajuste: (100 MiB/s) / (1 GiB/s) = 0.1
Nodos trabajadores proyectados: 63 trabajadores × 0.1 = 6.3 trabajadores
Cantidad proyectada de unidades de procesamiento de Streaming Engine por hora: 58 × 0.1 = 5.8 unidades por hora

Este valor solo debe usarse como una estimación inicial. El rendimiento y el costo reales pueden variar significativamente según factores como el tipo de máquina, la distribución del tamaño de los mensajes, el código del usuario, el tipo de agregación, el paralelismo de claves y el tamaño de la ventana. Para obtener más información, consulta Prácticas recomendadas para optimizar los costos de Dataflow.

Ejecuta una canalización de prueba

En esta sección, se muestran los comandos de gcloud dataflow flex-template run que se usaron para ejecutar la canalización solo de mapa.

Modo “exactamente una vez”

gcloud dataflow flex-template run JOB_NAME \
  --project=PROJECT_ID \
  --template-file-gcs-location=gs://dataflow-templates-us-central1/latest/flex/Kafka_to_BigQuery_Flex \
  --enable-streaming-engine \
  --parameters \
readBootstrapServerAndTopic="KAFKA_BOOTSTRAP_ADDRESS;KAFKA_TOPIC",\
kafkaReadAuthenticationMode=APPLICATION_DEFAULT_CREDENTIALS,\
messageFormat=JSON,\
writeMode=SINGLE_TABLE_NAME,\
outputTableSpec="PROJECT_ID:BQ_DATASET.BQ_TABLE_NAME",\
useBigQueryDLQ=true,\
outputDeadletterTable="PROJECT_ID:BQ_DATASET.BQ_TABLE_NAME_dlq",\
numStorageWriteApiStreams=400

Modo de entrega al menos una vez

gcloud dataflow flex-template run JOB_NAME \
  --project=PROJECT_ID \
  --template-file-gcs-location=gs://dataflow-templates-us-central1/latest/flex/Kafka_to_BigQuery_Flex \
  --enable-streaming-engine \
  --additional-experiments=streaming_mode_at_least_once \
  --parameters \
readBootstrapServerAndTopic="KAFKA_BOOTSTRAP_ADDRESS;KAFKA_TOPIC",\
kafkaReadAuthenticationMode=APPLICATION_DEFAULT_CREDENTIALS,\
messageFormat=JSON,\
writeMode=SINGLE_TABLE_NAME,\
outputTableSpec="PROJECT_ID:BQ_DATASET.BQ_TABLE_NAME",\
useBigQueryDLQ=true,\
outputDeadletterTable="PROJECT_ID:BQ_DATASET.BQ_TABLE_NAME_dlq",\
numStorageWriteApiStreams=400,\
useStorageWriteApiAtLeastOnce=true

Reemplaza lo siguiente:

JOB_NAME: Es el nombre del trabajo de Dataflow.
PROJECT_ID: Es el ID del proyecto.
KAFKA_BOOTSTRAP_ADDRESS: La dirección de arranque del clúster de Apache Kafka
KAFKA_TOPIC: Es el nombre del tema de Kafka.
BQ_DATASET: El nombre del conjunto de datos de BigQuery
BQ_TABLE_NAME: Es el nombre de la tabla de BigQuery.

Genera datos de prueba

Para generar datos de prueba, usa el siguiente comando para ejecutar la plantilla Streaming Data Generator:

gcloud dataflow flex-template run JOB_NAME \
  --project=PROJECT_ID \
  --template-file-gcs-location=gs://dataflow-templates-us-central1/latest/flex/Streaming_Data_Generator \
  --max-workers=140 \
  --parameters \
schemaLocation=SCHEMA_LOCATION,\
qps=1000000,\
sinkType=KAFKA,\
bootstrapServer=KAFKA_BOOTSTRAP_ADDRESS,\
kafkaTopic=KAFKA_TOPIC,\
outputType=JSON