Planificar una canalización de Dataflow

En esta página se explican aspectos importantes que debes tener en cuenta al planificar tu canalización de datos antes de empezar a desarrollar el código. Los flujos de datos transfieren datos de un sistema a otro y suelen ser componentes esenciales de los sistemas de información empresarial. El rendimiento y la fiabilidad de tu flujo de datos pueden influir en estos sistemas más amplios y en la eficacia con la que se cumplen tus requisitos empresariales.

Si planificas tus flujos de procesamiento de datos antes de desarrollarlos, puedes mejorar su rendimiento y fiabilidad. En esta página se explican varias consideraciones de planificación para las canalizaciones de Dataflow, entre las que se incluyen las siguientes:

• Expectativas de rendimiento de tus pipelines, incluidos los estándares de medición
• Integración de tus canalizaciones con fuentes de datos, receptores y otros sistemas conectados
• Regionalización de flujos de procesamiento, fuentes y sumideros
• Seguridad, como el cifrado de datos y las redes privadas

Definir y medir SLOs

Una medida importante del rendimiento es el grado en que tu canal cumple los requisitos de tu empresa. Los objetivos de nivel de servicio (SLOs) proporcionan definiciones tangibles del rendimiento que puedes comparar con umbrales aceptables. Por ejemplo, puedes definir los siguientes SLOs de ejemplo para tu sistema:

• Actualidad de los datos: genera el 90% de las recomendaciones de productos a partir de la actividad de los usuarios en el sitio web que se haya producido como máximo hace 3 minutos.

• Exactitud de los datos: en un mes natural, menos del 0,5% de las facturas de los clientes contienen errores.

• Aislamiento de datos o equilibrio de carga: en un día hábil, procesar todos los pagos de alta prioridad en un plazo de 10 minutos desde la presentación y completar los pagos de prioridad estándar antes del siguiente día hábil.

Puedes usar indicadores de nivel de servicio para medir el cumplimiento de los objetivos de nivel de servicio. Los indicadores de nivel de servicio son métricas cuantificables que indican si tu sistema cumple un objetivo de nivel de servicio determinado. Por ejemplo, puedes medir el SLO de actualización de datos de ejemplo usando la antigüedad de la actividad de usuario procesada más recientemente como SLI. Si su pipeline genera recomendaciones a partir de eventos de actividad de los usuarios y su SLI informa de un retraso de 4 minutos entre la hora del evento y la hora en la que se procesa, las recomendaciones no tienen en cuenta la actividad de los usuarios en el sitio web de hace más de 4 minutos. Si una canalización que procesa datos de streaming supera una latencia del sistema de 4 minutos, sabrá que no se cumple el SLO.

Como los componentes del sistema que no forman parte de tu canalización afectan a tu SLO, es importante registrar una serie de SLIs que describan el rendimiento general del sistema, más allá del rendimiento de la propia canalización. Esto incluye métricas que describan el estado integral del sistema. Por ejemplo, tu pipeline de Dataflow puede calcular resultados con un retraso aceptable, pero puede producirse un problema de rendimiento con un sistema posterior que afecte a SLOs más amplios.

Para obtener más información sobre los SLOs importantes que debes tener en cuenta, consulta el libro Site Reliability Engineering.

Actualización de datos

La actualización de los datos hace referencia a la usabilidad de los datos en relación con su antigüedad. En el libro Site Reliability Engineering se mencionan los siguientes SLOs de actualización de datos como los formatos de SLO de actualización de datos de la canalización más habituales:

• El X% de los datos se ha procesado en Y [segundos, días, minutos]. Este SLO hace referencia al porcentaje de datos que se procesan en un periodo determinado. Se suele usar en flujos de procesamiento por lotes que procesan fuentes de datos delimitadas. Las métricas de este tipo de SLO son los tamaños de los datos de entrada y salida en los pasos de procesamiento clave en relación con el tiempo de ejecución del flujo. Puedes elegir un paso que lea un conjunto de datos de entrada y otro que procese cada elemento de la entrada. Un ejemplo de SLO es el siguiente: "En el juego Shave the Yak, el 99% de las actividades de los usuarios que influyen en las puntuaciones de los jugadores se contabilizan en un plazo de 30 minutos después de que finalice la partida".

• Los datos más antiguos no tienen más de X [segundos, días, minutos]. Este SLO hace referencia a la antigüedad de los datos producidos por la canalización. Se suele usar en flujos de procesamiento que tratan datos de fuentes ilimitadas. En este tipo de SLO, usa métricas que indiquen cuánto tiempo tarda tu canalización en procesar los datos. Dos métricas posibles son la antigüedad del elemento no procesado más antiguo (es decir, el tiempo que lleva un elemento no procesado en la cola) o la antigüedad del elemento procesado más recientemente. Un ejemplo de SLO es "Las recomendaciones de productos se generan a partir de la actividad de los usuarios que no tenga más de 5 minutos".

• El trabajo de la canalización se completa correctamente en un plazo de X [segundos, días, minutos]. Este SLO establece una fecha límite para completar el proceso correctamente y se usa habitualmente en las canalizaciones por lotes que procesan datos de fuentes de datos delimitadas. Este objetivo de nivel de servicio requiere el tiempo total transcurrido de la canalización y el estado de finalización del trabajo, además de otras señales que indican el éxito del trabajo, como el porcentaje de elementos procesados que dan como resultado errores. Un ejemplo de SLO es "Los pedidos de los clientes del día hábil actual se procesan antes de las 9:00 del día siguiente".

Para obtener información sobre cómo usar Cloud Monitoring para medir la actualización de los datos, consulta Métricas de tareas de Dataflow.

Corrección de los datos

La exactitud de los datos se refiere a que los datos no tengan errores. Puedes determinar la exactitud de los datos de diferentes formas, entre las que se incluyen las siguientes:

• Pruebas unitarias y pruebas de integración, que puedes automatizar mediante la integración continua.

• Pruebas de flujo de procesamiento completas: puedes ejecutarlas en un entorno de preproducción una vez que el flujo de procesamiento haya superado las pruebas unitarias y de integración. Puedes automatizar las pruebas de flujos de procesamiento de extremo a extremo mediante la entrega continua.

• Las canalizaciones que se ejecutan en producción, cuando usas la monitorización para observar las métricas relacionadas con la exactitud de los datos.

En el caso de las canalizaciones en ejecución, definir un objetivo de corrección de datos suele implicar medir la corrección durante un periodo. Por ejemplo:

• Por trabajo, menos del X% de los elementos de entrada contienen errores de datos. Puedes usar este SLO para medir la exactitud de los datos de las canalizaciones por lotes. Un ejemplo de SLO es el siguiente: "En cada tarea de lote diaria para procesar lecturas de contadores de electricidad, menos del 3% de las lecturas contienen errores de introducción de datos".
• En un periodo de X minutos, menos del Y% de los elementos de entrada contienen errores de datos. Puedes usar este SLO para medir la exactitud de los datos de las canalizaciones de streaming. Un ejemplo de SLO es "Menos del 2% de las lecturas del contador de electricidad de la última hora contienen valores negativos".

Para medir estos objetivos de nivel de servicio, usa métricas durante un periodo adecuado para acumular el número de errores por tipo. Por ejemplo, los datos son incorrectos debido a un esquema con un formato incorrecto o están fuera de un intervalo válido.

Para obtener información sobre cómo usar Cloud Monitoring para medir la exactitud de los datos, consulta Métricas de tareas de Dataflow.

Aislamiento de datos y balanceo de carga

El aislamiento de datos consiste en segmentar los datos por atributo, lo que puede facilitar el balanceo de carga. Por ejemplo, en una plataforma de procesamiento de pagos online, puede segmentar los datos para que los pagos individuales tengan una prioridad estándar o alta. Tu canalización puede usar el balanceo de carga para asegurarse de que los pagos de alta prioridad se procesen antes que los de prioridad estándar.

Supongamos que defines los siguientes OLS para el procesamiento de pagos:

• Los pagos de alta prioridad se procesan en un plazo de 10 minutos.
• Los pagos con prioridad estándar se procesan antes de las 9:00 del siguiente día hábil.

Si la plataforma de pagos cumple estos SLOs, los clientes podrán ver los pagos de alta prioridad finalizados en un panel de control de informes a medida que se completen. En cambio, es posible que los pagos estándar no aparezcan en el panel de control hasta el día siguiente.

En este ejemplo, tienes las siguientes opciones:

• Ejecuta una sola canalización para procesar pagos de prioridad estándar y alta.
• Aísla y balancea la carga de los datos en función de las prioridades de varias pipelines.

En las siguientes secciones se describe cada opción en detalle.

Usar una sola canalización para cumplir SLOs mixtos

En el siguiente diagrama se muestra una única canalización que se usa para procesar pagos de prioridad alta y estándar. La canalización recibe notificaciones de nuevos pagos de una fuente de datos de streaming, como un tema de Pub/Sub o un tema de Apache Kafka. A continuación, procesa los pagos inmediatamente y escribe los eventos en BigQuery mediante inserciones de transmisión.

La ventaja de usar una sola canalización es que simplifica los requisitos operativos, ya que solo tienes que gestionar una fuente de datos y una canalización. Dataflow usa funciones de ajuste automático para ayudarte a ejecutar tu trabajo de la forma más rápida y eficiente posible.

Una de las desventajas de usar una sola canalización es que no se pueden priorizar los pagos de alta prioridad sobre los de prioridad estándar, y los recursos de la canalización se comparten entre ambos tipos de pago. En el caso práctico descrito anteriormente, tu canalización debe mantener el SLO más estricto de los dos. Es decir, la canalización debe usar el SLO para los pagos de alta prioridad, independientemente de la prioridad real de los pagos procesados. Otra desventaja es que, en caso de que haya un trabajo pendiente, la canalización de streaming no puede priorizar el procesamiento del trabajo pendiente según la urgencia del trabajo.

Usar varias canalizaciones adaptadas a SLOs específicos

Puedes usar dos pipelines para aislar recursos y cumplir SLOs específicos. En el siguiente diagrama se ilustra este enfoque.

Los pagos de alta prioridad se aíslan en una canalización de streaming para que se procesen con prioridad. Los pagos de prioridad estándar se procesan mediante un flujo de procesamiento por lotes que se ejecuta a diario y que usa tareas de carga de BigQuery para escribir los resultados procesados.

Aislar los datos en diferentes flujos de trabajo tiene varias ventajas. Para procesar los pagos de alta prioridad con SLOs más estrictos, puedes reducir los tiempos de procesamiento asignando más recursos a la canalización dedicada a los pagos de alta prioridad. Las configuraciones de recursos incluyen añadir trabajadores de Dataflow, usar máquinas más grandes y habilitar el escalado automático. Aislar los elementos de alta prioridad en una cola de procesamiento independiente también puede mitigar los retrasos en el procesamiento si se produce una afluencia repentina de pagos de prioridad estándar.

Si usas varias canalizaciones para aislar y equilibrar la carga de los datos de fuentes de procesamiento por lotes y en tiempo real, el modelo de programación de Apache Beam permite que las canalizaciones de alta prioridad (en tiempo real) y de prioridad estándar (por lotes) compartan el mismo código. La única excepción es la transformación de lectura inicial, que lee de una fuente limitada para la canalización por lotes. Para obtener más información, consulta el artículo Crear bibliotecas de transformaciones reutilizables.

Planificar las fuentes de datos y los sumideros

Para procesar datos, es necesario integrar una canalización de datos con otros sistemas. Estos sistemas se denominan fuentes y receptores. Los flujos de procesamiento de datos leen datos de fuentes y escriben datos en sumideros. Además de las fuentes y los receptores, las canalizaciones de datos pueden interactuar con sistemas externos para enriquecer o filtrar datos, o bien para llamar a una lógica empresarial externa en un paso de procesamiento.

Para mejorar la escalabilidad, Dataflow ejecuta las fases de tu canalización en paralelo en varios trabajadores. También influyen en la escalabilidad de tu flujo de procesamiento factores que no dependen del código de tu flujo ni del servicio Dataflow. Entre estos factores se incluyen los siguientes:

• Escalabilidad de los sistemas externos: los sistemas externos con los que interactúa tu canalización pueden limitar el rendimiento y constituir el límite superior de la escalabilidad. Por ejemplo, un tema de Apache Kafka configurado con un número insuficiente de particiones para el rendimiento de lectura que necesitas puede afectar al rendimiento de tu flujo de procesamiento. Para asegurarse de que la canalización y sus componentes cumplen sus objetivos de rendimiento, consulte la documentación de prácticas recomendadas de los sistemas externos que esté usando. También puedes simplificar la planificación de la capacidad de la infraestructura usando los servicios de Google Cloud Platform, que ofrecen escalabilidad integrada. Para obtener más información, consulta la sección Usar fuentes y receptores gestionados de Google Cloud Platform de esta página.

• Elección de formatos de datos: puede que algunos formatos de datos se lean más rápido que otros. Por ejemplo, usar formatos de datos que admitan lecturas paralelizadas, como Avro, suele ser más rápido que usar archivos CSV que tengan saltos de línea insertados en los campos, y también más rápido que usar archivos comprimidos.

• Ubicación de los datos y topología de la red: la proximidad geográfica y las características de la red de las fuentes y los receptores de datos en relación con la canalización de datos pueden influir en el rendimiento. Para obtener más información, consulta la sección Consideraciones regionales de esta página.

Llamadas a servicios externos

Llamar a servicios externos desde tu flujo de procesamiento conlleva sobrecargas por llamada que pueden reducir el rendimiento y la eficiencia de tu flujo de procesamiento. Si tu canalización de datos llama a servicios externos, para reducir la sobrecarga, agrupa varios elementos de datos en solicitudes únicas siempre que sea posible. Muchas transformaciones de entrada/salida nativas de Apache Beam realizan esta tarea automáticamente, como BigQueryIO y las operaciones de inserción de streaming. Además de los límites de capacidad, algunos servicios externos también aplican cuotas que limitan el número total de llamadas durante un periodo, como una cuota diaria, o restringen la frecuencia de las llamadas, como el número de solicitudes por segundo.

Como Dataflow paraleliza el trabajo entre varios trabajadores, un volumen de tráfico excesivo puede sobrecargar un servicio externo o agotar las cuotas disponibles. Cuando se usa el autoescalado, Dataflow puede intentar compensarlo añadiendo trabajadores para ejecutar un paso lento, como una llamada externa. Si añades más trabajadores, puede que los sistemas externos se vean sometidos a una mayor presión. Asegúrate de que los sistemas externos puedan admitir los requisitos de carga previstos o limita el tráfico de tu canal a niveles sostenibles. Para obtener más información, consulta Limitar los tamaños de los lotes y las llamadas simultáneas a servicios externos.

Usar Google Cloud fuentes y sumideros gestionados

Si usas Google Cloud servicios gestionados con tu canalización de Dataflow, no tendrás que preocuparte por la complejidad de la gestión de la capacidad, ya que ofrecen escalabilidad integrada, un rendimiento constante y cuotas y límites que se adaptan a la mayoría de los requisitos. Debes tener en cuenta las diferentes cuotas y límites de las operaciones de canalización. Dataflow impone cuotas y límites. Puedes aumentar algunos de estos límites poniéndote en contacto con el Google Cloud equipo de Asistencia.

Dataflow usa instancias de VM de Compute Engine para ejecutar tus trabajos, por lo que necesitas una cuota de Compute Engine suficiente. Si no tienes suficiente cuota de Compute Engine, el autoescalado de la canalización puede verse afectado o las tareas no podrán iniciarse.

En el resto de esta sección se explica cómo pueden influir las diferentes cuotas y límites en el diseño, el desarrollo y la monitorización de tu canalización. Google CloudPub/Sub y BigQuery se usan como ejemplos de fuentes y sumideros de la canalización.

Ejemplo 1: Pub/Sub

Cuando usas Pub/Sub con Dataflow, Pub/Sub proporciona un servicio de ingestión de eventos escalable y duradero para enviar y recibir mensajes de tus flujos de procesamiento de datos en tiempo real. Puedes usar la consola para ver Google Cloud el consumo de cuota de Pub/Sub y aumentar los límites de cuota. Te recomendamos que solicites un aumento de la cuota si tienes alguna canalización que supere las cuotas y los límites por proyecto.

Las cuotas y los límites de Pub/Sub se han diseñado en función del uso a nivel de proyecto. En concreto, los editores y suscriptores de diferentes proyectos tienen cuotas de procesamiento de datos independientes. Si varias canalizaciones publican o se suscriben a un mismo tema, puedes obtener el rendimiento máximo permitido en ese tema implementando cada canalización en su propio proyecto. En esta configuración, cada canal usa una cuenta de servicio basada en proyectos diferente para consumir y publicar mensajes.

En el siguiente diagrama, Pipeline 1 y Pipeline 2 comparten la misma cuota de rendimiento de suscriptor y editor que está disponible para Project A. Por el contrario, Pipeline 3 puede usar toda la cuota de rendimiento de suscriptores y editores que esté asociada a Project B.

Se pueden leer datos de varios flujos de trabajo desde un único tema de Pub/Sub mediante suscripciones independientes al tema, lo que permite que los flujos de trabajo de Dataflow extraigan y confirmen mensajes de forma independiente de otros suscriptores, como otros flujos de trabajo. Esta función permite clonar fácilmente flujos de procesamiento creando suscripciones adicionales de Pub/Sub. Crear suscripciones adicionales es útil para crear réplicas de flujos de procesamiento para alta disponibilidad (normalmente, en casos prácticos de streaming), para ejecutar flujos de procesamiento de prueba adicionales con los mismos datos y para habilitar las actualizaciones de los flujos de procesamiento.

Ejemplo 2: BigQuery

El SDK de Apache Beam admite la lectura y escritura de datos de BigQuery en varios lenguajes, como Java, Python y Go. Si usas Java, la clase BigQueryIO proporciona esta función. BigQueryIO admite dos métodos para leer datos: EXPORT (exportación de tablas) y DIRECT_READ. Los distintos métodos de lectura consumen diferentes cuotas de BigQuery.

La exportación de tablas es el método de lectura predeterminado. Funciona como se muestra en el siguiente diagrama:

En el diagrama se muestra el siguiente flujo:

1. BigQueryIO invoca una solicitud de exportación de BigQuery para exportar datos de la tabla. Los datos de la tabla exportada se escriben en una ubicación temporal de Cloud Storage.
2. BigQueryIO lee los datos de la tabla de la ubicación temporal de Cloud Storage.

Las solicitudes de exportación de BigQuery están limitadas por las cuotas de exportación. La solicitud de exportación también debe completarse antes de que la canalización pueda empezar a procesar los datos, lo que añade tiempo de ejecución adicional a la tarea.

Por el contrario, el método de lectura directa usa la API Storage de BigQuery para leer los datos de las tablas directamente de BigQuery. La API Storage de BigQuery proporciona un rendimiento de lectura de alto rendimiento para los datos de las filas de las tablas mediante gRPC. Si usas la API Storage de BigQuery, no es necesario realizar el paso de exportación, lo que evita las restricciones de cuota de exportación y puede reducir el tiempo de ejecución de los trabajos.

En el siguiente diagrama se muestra el flujo si usas la API Storage de BigQuery. A diferencia del flujo que usa una solicitud de exportación de BigQuery, este flujo es más sencillo, ya que solo tiene un paso de lectura directa para obtener los datos de la tabla al flujo de trabajo.

La escritura de datos en tablas de BigQuery también tiene sus propias implicaciones en cuanto a las cuotas. Los flujos de procesamiento por lotes que usan tareas de carga de BigQuery consumen diferentes cuotas de tareas de carga de BigQuery que se aplican a nivel de tabla y de proyecto. Del mismo modo, las canalizaciones de streaming que usan inserciones de streaming de BigQuery consumen cuotas de inserción de streaming de BigQuery.

Para determinar los métodos más adecuados para leer y escribir datos, ten en cuenta tu caso práctico. Por ejemplo, no uses trabajos de carga de BigQuery para añadir datos a una tabla miles de veces al día. Usa una canalización de streaming para escribir datos casi en tiempo real en BigQuery. Tu canalización de streaming debe usar inserciones de streaming o la API Storage Write para este fin.

Consideraciones regionales

Dataflow se ofrece como servicio gestionado en varias Google Cloud regiones. Cuando elija una región para ejecutar sus tareas, tenga en cuenta los siguientes factores:

• La ubicación de las fuentes de datos y los sumideros
• Preferencias o restricciones sobre las ubicaciones de tratamiento de datos
• Funciones de Dataflow que solo se ofrecen en regiones concretas
• Región que se usa para gestionar la ejecución de un trabajo determinado.
• La zona que se usa para los trabajadores de la tarea

En una tarea determinada, la configuración de la región que uses para la tarea y para los trabajadores puede ser diferente. Para obtener más información, incluido cuándo especificar regiones y zonas, consulta la documentación sobre regiones de Dataflow.

Si especificas las regiones en las que quieres ejecutar tus tareas de Dataflow, puedes planificar la alta disponibilidad y la recuperación tras desastres en función de las consideraciones regionales. Para obtener más información, consulta el artículo sobre alta disponibilidad y redundancia geográfica.

Regiones

Las regiones de Dataflow almacenan y gestionan metadatos relacionados con tu trabajo, como información sobre el gráfico de Apache Beam, como los nombres de las transformaciones. También controlan el comportamiento de los trabajadores, como el autoescalado. Especificar una región te ayuda a satisfacer tus necesidades de seguridad y cumplimiento, localidad de los datos y ubicación regional de un trabajo. Para evitar que las llamadas de red entre regiones afecten al rendimiento, te recomendamos que utilices la misma región para el trabajo y para los trabajadores siempre que sea posible.

Trabajadores de Dataflow

Las tareas de Dataflow usan instancias de VM de Compute Engine, llamadas trabajadores de Dataflow, para ejecutar tu flujo de procesamiento. Las tareas de Dataflow pueden usar cualquier zona de Compute Engine para los trabajadores, incluidas las regiones en las que no haya ubicaciones de Dataflow. Si especificas una región de trabajador para tu tarea, puedes controlar la ubicación regional de tus trabajadores. Para especificar una región o una zona de los trabajadores, haz lo siguiente:

• Si usas la CLI de gcloud para crear un trabajo a partir de una plantilla de Dataflow, usa la marca --worker-region para anular la región de los trabajadores o la marca --worker-zone para anular la zona de los trabajadores.
• Si usas el SDK de Apache Beam para Java para crear tu trabajo, define las regiones y las zonas de los trabajadores mediante opciones de la canalización. Usa workerRegion para anular la región del trabajador o workerZone para anular la zona del trabajador.

Para mejorar la latencia y el rendimiento de la red, te recomendamos que crees trabajadores en una región que esté geográficamente cerca de tus fuentes y receptores de datos. Si no especificas una región o una zona para los trabajadores al crear un trabajo, Dataflow utilizará de forma predeterminada una zona que esté en la misma región que el trabajo.

Si no usas el servicio Shuffle de Dataflow o Streaming Engine, los datos que procesa el trabajo (es decir, los datos almacenados en cualquier objeto PCollection) se encuentran en los trabajadores del trabajo, siempre que ningún código de usuario transmita datos fuera de los trabajadores. Si el servicio Dataflow Shuffle o Streaming Engine están habilitados, el conjunto de datos distribuido representado por un objeto PCollection se puede transmitir entre los trabajadores y estos servicios.

Consideraciones sobre el cifrado de datos

Como servicio totalmente gestionado, Dataflow cifra automáticamente los datos que se mueven por tu flujo de procesamiento de datos mediante Google-owned and Google-managed encryption keys , tanto los datos en tránsito como los datos en reposo. En lugar de usar Google-owned and Google-managed encryption keys, puede que prefieras gestionar tus propias claves de cifrado. En ese caso, Dataflow admite claves de cifrado gestionadas por el cliente (CMEK) mediante Cloud Key Management Service (KMS). También puedes usar Cloud HSM, un servicio de módulo de seguridad de hardware (HSM) alojado en la nube que te permite alojar claves de encriptado y llevar a cabo operaciones criptográficas en un clúster formado por HSMs con certificación FIPS 140-2 de nivel 3.

Cuando usas CMEK, Dataflow usa tu clave de Cloud KMS para encriptar los datos, excepto en las operaciones basadas en claves de datos, como las de ventanas, agrupación y unión. Si las claves de datos contienen datos sensibles, como información personal identificable (IPI), debes cifrar o transformar las claves antes de que entren en la canalización de Dataflow.

Consideraciones sobre las redes privadas

Es posible que tus requisitos de redes y seguridad exijan que las cargas de trabajo basadas en máquinas virtuales, como los trabajos de Dataflow, usen solo direcciones IP privadas. Dataflow te permite especificar que los trabajadores usen direcciones IP privadas para todas las comunicaciones de red. Si las IPs públicas están inhabilitadas, debes habilitar Acceso privado de Google en la subred para que los trabajadores de Dataflow puedan acceder a las APIs y los servicios de Google.

Te recomendamos que inhabilites las IPs públicas de los trabajadores de Dataflow, a menos que tus trabajos de Dataflow necesiten IPs públicas para acceder a recursos de red fuera de Google Cloud Platform. Si inhabilitas las IPs públicas, los trabajadores de Dataflow no podrán acceder a recursos que estén fuera de la subred ni a redes de VPC emparejadas. Del mismo modo, se impide el acceso a la red de los trabajadores de las VMs desde fuera de la subred o de las redes de VPCs emparejadas.

Para obtener más información sobre cómo usar la opción de canalización --usePublicIps para especificar si los trabajadores deben tener solo IPs privadas, consulta Opciones de canalización.

Siguientes pasos

• Desarrolla y prueba tu flujo de procesamiento.
• Consulta información sobre cómo diseñar flujos de trabajo de la canalización completos.
• Consulta más información sobre las prácticas de Site Reliability Engineering (SRE) de Google para las canalizaciones de tratamiento de datos.