Planifica tu canalización de Dataflow

En esta página se explican las consideraciones importantes para planificar la canalización de datos antes de comenzar el desarrollo de código. Las canalizaciones de datos transfieren datos de un sistema a otro y, a menudo, son componentes fundamentales de los sistemas de información de la empresa. El rendimiento y la confiabilidad de la canalización de datos pueden afectar a estos sistemas más amplios y a la eficacia con la que se cumplen los requisitos de la empresa.

Si planificas las canalizaciones de datos antes de desarrollarlas, puedes mejorar su rendimiento y confiabilidad. En esta guía, se explican varias consideraciones de planificación para las canalizaciones de Dataflow, incluidas las siguientes:

• Expectativas de rendimiento para las canalizaciones, incluidos los estándares de capacidad de medición
• Integración de tus canalizaciones en fuentes de datos, receptores y otros sistemas conectados
• Regionalización de canalizaciones, fuentes y receptores
• Seguridad, como la encriptación de datos y las redes privadas

Define y mide los SLOs

Una medida importante del rendimiento es la eficacia con la que tu canalización cumple con los requisitos de tu negocio. Los objetivos de nivel de servicio (SLO) proporcionan definiciones de rendimiento tangibles que puedes comparar con los límites aceptables. Por ejemplo, puedes definir los siguientes SLO de ejemplo para tu sistema:

• Actualización de datos: Genera un 90% de recomendaciones de productos a partir de la actividad del sitio web del usuario que hubo hace no más de 3 minutos.

• Precisión de los datos: En un mes calendario, menos del 0.5% de las facturas de los clientes contienen errores.

• Balanceo de cargas/aislamiento de datos: Dentro de un día hábil, procesa todos los pagos de prioridad alta dentro de los 10 minutos posteriores a la adaptación y completa los pagos de prioridad estándar al día hábil siguiente.

Puedes usar indicadores de nivel de servicio (SLI) para medir el cumplimiento del SLO. Los SLI son métricas cuantificables que indican la eficacia con la que tu sistema cumple con un SLO determinado. Por ejemplo, puedes medir el ejemplo de SLO de actualidad de datos mediante la antigüedad de la actividad del usuario procesada más recientemente como un SLI. Si tu canalización genera recomendaciones a partir de eventos de actividad del usuario y si tu SLI informa un retraso de 4 minutos entre el tiempo del evento y el momento en que se procesa, las recomendaciones no considerarán la actividad del sitio web de un usuario previa a los 4 minutos. Si una canalización que procesa datos de transmisión excede una latencia del sistema de 4 minutos, sabes que no se cumple el SLO.

Debido a que los componentes del sistema más allá de tu canalización afectan a tu SLO, es importante capturar un rango de SLI que describa el rendimiento general del sistema más allá del rendimiento de la canalización en sí, incluidas las métricas que describen el rendimiento de extremo a extremo de tu sistema. Por ejemplo, la canalización de Dataflow podría calcular los resultados con un retraso aceptable, pero es posible que se produzca un problema de rendimiento con un sistema descendente que pueda afectar a los SLO más amplios.

Para obtener más información sobre los SLO importantes que debes considerar, consulta el libro Ingeniería de confiabilidad de sitios.

Actualidad de los datos

La actualidad de los datos hace referencia a la usabilidad de los datos en relación con su antigüedad. Los siguientes SLO de actualidad de los datos se mencionan en el libro de ingeniería de confiabilidad de sitios como los formatos más comunes de SLO de actualidad de los datos de las canalizaciones:

• X% de los datos procesados en Y [segundos, días, minutos]. Este SLO se refiere al porcentaje de datos que se procesan en un período determinado. Por lo general, se usa para canalizaciones por lotes que procesan fuentes de datos delimitadas. Las métricas para este tipo de SLO son los tamaños de datos de entrada y salida en los pasos de procesamiento de claves en relación con el tiempo de ejecución de la canalización transcurrido. 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 “Para el juego Shave the Yak, el 99% de las actividades del usuario que afectan las puntuaciones de los jugadores se tiene en cuenta dentro de los 30 minutos posteriores a la finalización de la partida”.

• Los datos más antiguos no duran más de X [segundos, días, minutos]. Este SLO se refiere a la antigüedad de los datos producidos por la canalización. Por lo general, se usa para canalizaciones de transmisión que procesan datos de fuentes no delimitadas. Para este tipo de SLO, debes usar métricas que indiquen cuánto tiempo tarda la canalización en procesar los datos. Dos métricas posibles son la antigüedad del elemento sin procesar más antiguo (cuánto tiempo estuvo un elemento sin procesar en la cola) o la antigüedad del elemento procesado más reciente. Un ejemplo de SLO es “Las recomendaciones de productos se generan a partir de la actividad del usuario que no tiene más de 5 minutos”.

• El trabajo de canalización se completa de forma correcta en X [segundos, días, minutos]. Este SLO establece un plazo para la finalización exitosa y se suele usar para canalizaciones por lotes que procesan datos de fuentes de datos limitadas. Este SLO requiere el tiempo total transcurrido por la canalización y el estado de finalización del trabajo, además de otros indicadores que muestren el éxito del trabajo (por ejemplo, el porcentaje de elementos procesados que generan errores). Un ejemplo de SLO es “Los pedidos de los clientes del día hábil actual se procesan a las 9:00 a.m. del día siguiente”.

Si deseas obtener información sobre el uso de Cloud Monitoring para medir la actualidad de los datos, consulta las métricas de trabajos de Dataflow.

Precisión de los datos

La precisión de los datos hace referencia a los datos que no contienen errores. Puedes determinar la precisión de los datos a través de diferentes medios, como los siguientes:

• Pruebas de unidades y pruebas de integración, que automatizas con la integración continua.

• Pruebas de canalización de extremo a extremo, que puedes ejecutar en un entorno de preproducción después de que la canalización apruebe las pruebas de unidades y de integración. Puedes automatizar las pruebas de canalización de extremo a extremo mediante la entrega continua.

• Canalizaciones que se ejecutan en producción, cuando usas la supervisión para observar métricas relacionadas con la corrección de los datos.

Para ejecutar canalizaciones, la definición de un objetivo de corrección de datos, por lo general, implica la medición de la corrección a lo largo de un período. Por ejemplo:

• Según el trabajo, menos del X% de los elementos de entrada contienen errores de datos. Puedes usar este SLO para medir la precisión de los datos en las canalizaciones por lotes. Un ejemplo de SLO podría ser “Por cada trabajo por lotes diario para procesar las lecturas del medidor de electricidad, menos del 3% de las lecturas contienen errores de entrada de datos”.
• Durante un período de X minutos, menos del Y% de los elementos de entrada contienen errores de datos. Puedes usar este SLO para medir la precisión de los datos en las canalizaciones de transmisión. Un ejemplo de SLO es “Menos del 2% de las lecturas del medidor de electricidad durante la última hora contienen valores negativos”.

A fin de medir estos SLO, usa las métricas durante un período adecuado para acumular la cantidad de errores por tipo. Algunos ejemplos de tipos de errores son que los datos son incorrectos debido a un esquema con formato incorrecto o los datos están fuera de un rango válido.

Si deseas obtener información sobre el uso de Cloud Monitoring para medir la precisión de los datos, consulta las métricas de trabajos de Dataflow.

Aislamiento de datos y balanceo de cargas

El aislamiento de datos implica segmentar los datos por atributo, lo que puede facilitar el balanceo de cargas. Por ejemplo, en una plataforma de procesamiento de pagos en línea, puedes segmentar los datos para que los pagos individuales tengan prioridad estándar o alta prioridad. La canalización podría usar el balanceo de cargas para garantizar que los pagos de prioridad alta se procesen antes que los de prioridad estándar.

Imagina que defines los siguientes SLOs para el procesamiento de pagos:

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

Si la plataforma de pagos cumple con estos SLO, los clientes pueden ver los pagos finalizados de alta prioridad en un panel de informes a medida que se completan. Por el contrario, es posible que los pagos estándar no aparezcan en el panel hasta el día siguiente.

En esta situación de ejemplo, tienes las siguientes opciones:

• Ejecuta una sola canalización para procesar los pagos de prioridad estándar y alta.
• Aisla y balancea las cargas de los datos según las prioridades en varias canalizaciones.

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

Usa una sola canalización para entregar en SLOs mixtos

En el siguiente diagrama, se ilustra una sola canalización que se usa para procesar pagos de prioridad alta y de prioridad estándar. La canalización recibe notificaciones de pagos nuevos desde una fuente de datos de transmisión, por ejemplo, un tema de Pub/Sub o uno de Apache Kafka. Luego, procesa de inmediato los pagos y escribe eventos en BigQuery mediante inserciones de transmisión.

La ventaja de una sola canalización es que simplifica los requisitos operativos porque necesitas administrar solo una fuente de datos y una canalización. Dataflow usa funciones de ajuste automático para ayudar a ejecutar el trabajo de la manera más rápida y eficiente posible.

Una desventaja de una sola canalización es que la canalización compartida no puede priorizar los pagos de prioridad alta por sobre los pagos de prioridad estándar, y los recursos de canalización se comparten en ambos tipos de pago. En la situación de negocios descrita antes, tu canalización debe mantener los dos SLO más estrictos. Es decir, la canalización debe usar el SLO para los pagos de prioridad alta, sin importar la prioridad real de los pagos procesados. Otra desventaja es que, en caso de que haya trabajos pendientes, la canalización de transmisión no puede priorizar el procesamiento de trabajos pendientes según la urgencia del trabajo.

Usa varias canalizaciones personalizadas para SLOs específicos

Puedes usar dos canalizaciones para aislar recursos y entregarlos en SLO específicos. En el siguiente diagrama, se ilustra este enfoque.

Los pagos de prioridad alta están aislados a una canalización de transmisión para el procesamiento priorizado. Los pagos de prioridad estándar se procesan mediante una canalización por lotes que se ejecuta a diario y que usa trabajos de carga de BigQuery para escribir resultados procesados.

Aislar datos en diferentes canalizaciones tiene ventajas. A fin de entregar pagos de prioridad alta según SLO más estrictos, puedes asignar tiempos de procesamiento más cortos si asignas más recursos a la canalización dedicada a los pagos de prioridad alta. Las configuraciones de recursos incluyen agregar trabajadores de Dataflow, usar máquinas más grandes y habilitar el ajuste de escala automático. El aislamiento de los elementos de prioridad alta en una cola de procesamiento separada también puede mitigar las demoras de procesamiento si se produce una afluencia repentina de pagos de prioridad estándar.

Cuando usas varias canalizaciones para aislar y balancear las cargas de los datos de las fuentes por lotes y de transmisión, el modelo de programación de Apache Beam permite que las canalizaciones de alta prioridad (transmisión) y 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 delimitada para la canalización por lotes. Para obtener más información, consulta Crea bibliotecas de transformaciones reutilizables.

Planifica fuentes y receptores de datos

Para procesar datos, una canalización de datos debe integrarse en otros sistemas. Esos sistemas se denominan fuentes y receptores. Las canalizaciones de datos leen los datos de fuentes y escriben datos en receptores. Además de fuentes y receptores, las canalizaciones de datos pueden interactuar con sistemas externos para enriquecer los datos, filtrarlos o llamar a la lógica empresarial externa dentro de un paso de procesamiento.

Para la escalabilidad, Dataflow ejecuta las etapas de la canalización en paralelo en varios trabajadores. Los factores que están fuera del código de la canalización y el servicio de Dataflow también afectan la escalabilidad de la canalización. Estos factores pueden ser los siguientes:

• Escalabilidad de sistemas externos: Los sistemas externos con los que interactúa tu canalización pueden restringir el rendimiento y pueden formar el límite superior de escalabilidad. Por ejemplo, un tema de Apache Kafka configurado con una cantidad insuficiente de particiones para la capacidad de procesamiento de lectura que necesitas puede afectar el rendimiento de tu canalización. Para ayudarte a garantizar que la canalización y sus componentes cumplan con tus objetivos de rendimiento, consulta la documentación de prácticas recomendadas para los sistemas externos que uses. También puedes simplificar la planificación de la capacidad de la infraestructura mediante los servicios de Google Cloud que proporcionan escalabilidad integrada. Para obtener más información, consulta Usa fuentes y receptores administrados de Google Cloud en esta página.

• Elección de formatos de datos: Algunos formatos de datos pueden ser más rápidos para leer que otros. Por ejemplo, el uso de formatos de datos que admiten lecturas paralelizables, como Avro, suele ser más rápido que usar archivos CSV que tienen saltos de línea incorporados en los campos y es más rápido que usar archivos comprimidos.

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

Llamadas a servicios externos

Llamar a servicios externos desde tu canalización genera sobrecargas por llamada que pueden disminuir el rendimiento y la eficiencia de tu canalización. Si tu canalización de datos llama a servicios externos, para reducir las sobrecargas, agrupa en lotes varios elementos de datos en solicitudes únicas siempre que sea posible. Muchas transformaciones de E/S nativas de Apache Beam realizan automáticamente esta tarea, incluidas BigQueryIO y operaciones de inserción de transmisión. Además de los límites de capacidad, algunos servicios externos también pueden aplicar de manera forzosa cuotas que limiten la cantidad total de llamadas durante un período (por ejemplo, una cuota diaria) o restrinjan la frecuencia de las llamadas (como la cantidad de solicitudes por segundo).

Debido a que Dataflow paraleliza el trabajo en varios trabajadores, demasiado tráfico puede sobrecargar un servicio externo o agotar las cuotas disponibles. Cuando se usa el ajuste de escala automático, Dataflow puede intentar compensar si agregas trabajadores para ejecutar un paso lento como una llamada externa. Agregar trabajadores puede aumentar la presión sobre los sistemas externos. Asegúrate de que los sistemas externos puedan admitir los requisitos de carga anticipados o limitar el tráfico de tu canalización a niveles sustentables. Para obtener más información, consulta Limita los tamaños de los lotes y las llamadas simultáneas a servicios externos.

Usa fuentes y receptores administrados de Google Cloud

Usar los servicios administrados de Google Cloud con tu canalización de Dataflow quita la complejidad de la administración de capacidad, ya que proporciona escalabilidad integrada, rendimiento coherente y cuotas y límites que se adaptan a la mayoría de los requisitos. También debes tener en cuenta diferentes cuotas y límites para las operaciones de canalización. Dataflow impone cuotas y límites. Para aumentar algunas de ellas, comunícate con la asistencia de Google Cloud.

Dataflow usa instancias de VM de Compute Engine para ejecutar tus trabajos, por lo que necesitas suficiente cuota de Compute Engine. No tener la cuota suficiente de Compute Engine puede impedir el ajuste de escala automático de la canalización o evitar que se inicien los trabajos.

En las partes restantes de esta sección, se explora cómo las diferentes cuotas y límites de Google Cloud pueden influir en el diseño, el desarrollo y la supervisión de la canalización. Pub/Sub y BigQuery se usan como ejemplos de fuentes y receptores de canalización.

Ejemplo 1: Pub/Sub

Cuando usas Pub/Sub con Dataflow, Pub/Sub proporciona un servicio de transferencia de eventos escalable y duradero para entregar mensajes hacia y desde tus canalizaciones de datos de transmisión. Puedes usar la consola de Google Cloud para ver el consumo de la cuota de Pub/Sub y aumentar los límites de cuota. Recomendamos que solicites un aumento de cuota si tienes una sola canalización que exceda las cuotas y los límites por proyecto.

Las cuotas y los límites de Pub/Sub se diseñan en torno al uso a nivel de proyecto. Específicamente, los publicadores y suscriptores de diferentes proyectos tienen cuotas de capacidad de procesamiento de datos independientes. Si varias canalizaciones publican o se suscriben a un solo tema, puedes obtener la máxima capacidad de procesamiento permitida en ese tema si implementas cada canalización en su propio proyecto. En esta configuración, cada canalización usa una cuenta de servicio basada en proyectos diferente para consumir y publicar mensajes.

En el siguiente diagrama, Canalización 1 y Canalización 2 comparten la misma cuota de suscriptores y capacidad de procesamiento del publicador que está disponible para el Proyecto A. Por el contrario, la Canalización 3 puede usar la cuota total de suscriptores y capacidad de procesamiento del publicador que se adjunta al Proyecto B.

Varias canalizaciones pueden leer desde un solo tema de Pub/Sub mediante suscripciones independientes al tema, lo que permite que las canalizaciones de Dataflow extraigan mensajes y confirmen su recepción sin importar los otros suscriptores (como en otras canalizaciones). Esta característica facilita la clonación de canalizaciones mediante la creación de suscripciones adicionales de Pub/Sub. Crear suscripciones adicionales es útil a fin de crear canalizaciones de réplicas para alta disponibilidad (generalmente para casos de uso de transmisión), a fin de ejecutar más canalizaciones de prueba con los mismos datos y para habilitar las actualizaciones de la canalización.

Ejemplo 2: BigQuery

La lectura y escritura de los datos de BigQuery es compatible con el SDK de Apache Beam para varios lenguajes, incluidos Java, Python y Go. Cuando 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 diferentes métodos de lectura consumen distintas 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 desde la ubicación temporal de Cloud Storage.

Las solicitudes de exportación a 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 comenzar a procesar datos, lo que agrega tiempo de ejecución adicional para el trabajo.

Por el contrario, el enfoque de lectura directa usa la API de BigQuery Storage para leer los datos de las tablas directamente desde BigQuery. La API de BigQuery Storage proporciona un alto rendimiento de lectura de la capacidad de procesamiento para los datos de las filas de tabla mediante gRPC. El uso de la API de BigQuery Storage hace que el paso de exportación sea innecesario, lo que evita restricciones de cuota de exportación y puede reducir el tiempo de ejecución del trabajo.

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

Escribir datos en tablas de BigQuery también tiene sus propias implicaciones de cuota. Por ejemplo, las canalizaciones por lotes que usan trabajos de carga de BigQuery consumen diferentes cuotas de trabajo de carga de BigQuery que se aplican a nivel de tabla y de proyecto. Del mismo modo, las canalizaciones de transmisión que usan inserciones de transmisión de BigQuery consumen cuotas de inserción de transmisión de BigQuery.

Para determinar los métodos más apropiados para leer y escribir datos, considera tu caso práctico. Por ejemplo, debes evitar usar trabajos de carga de BigQuery con el fin de agregar miles de datos por día a una tabla. Usa una canalización de transmisión para escribir datos casi en tiempo real en BigQuery. La canalización de transmisión debe usar inserciones de transmisión o la API de Storage Write para este fin.

Consideraciones regionales

Dataflow se ofrece como un servicio administrado en varias regiones de Google Cloud. Cuando elijas una región para ejecutar tus trabajos, ten en cuenta los siguientes factores:

• La ubicación de las fuentes de datos y los receptores
• Preferencias o restricciones en las ubicaciones de procesamiento de datos
• Funciones de Dataflow que solo se ofrecen en regiones específicas
• La región que se usa para administrar la ejecución de un trabajo determinado
• La zona que se usa para los trabajadores

Para un trabajo determinado, el parámetro de configuración de la región que usas para el trabajo y los trabajadores puede variar. Para obtener más información, incluido cuándo especificar regiones y zonas, consulta la documentación de regiones de Dataflow.

Si especificas regiones para ejecutar tus trabajos de Dataflow, puedes planificar consideraciones regionales para la alta disponibilidad y la recuperación ante desastres. Para obtener más información, consulta Alta disponibilidad y redundancia geográfica.

Regiones

Las regiones de Dataflow almacenan y controlan los metadatos relacionados con tu trabajo, como información sobre el grafo de Apache Beam, como nombres de transformaciones. También controlan comportamientos de los trabajadores, como el ajuste de escala automático. Especificar un extremo regional te ayuda a satisfacer tus necesidades de seguridad y cumplimiento, la localidad de datos y la ubicación regional de un trabajo. A fin de evitar el impacto en el rendimiento de las llamadas entre redes entre regiones, te recomendamos que uses la misma región para el trabajo y los trabajadores cuando sea posible.

Trabajadores de Dataflow

Los trabajos de Dataflow usan instancias de VM de Compute Engine (llamadas trabajadores de Dataflow) para ejecutar tu canalización. Los trabajos de Dataflow pueden usar cualquier zona de Compute Engine para los trabajadores, incluidas las regiones en las que no hay ubicaciones de Dataflow. Si especificas una región de trabajador para tu trabajo, puedes controlar la ubicación regional de tus trabajadores. Para especificar una región o zona de trabajador, 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 del trabajador, o la marca --worker-zone para anular la zona del trabajador.
• Si usas el SDK de Java de Apache Beam a fin de crear tu trabajo, debes establecer regiones y zonas para los trabajadores mediante las opciones de canalización. Usa workerRegion para anular la región del trabajador o workerZone para anular la zona del trabajador.

Para mejorar la latencia y la capacidad de procesamiento de la red, te recomendamos que crees trabajadores en una región que se encuentre geográficamente cerca de tus fuentes de datos y receptores. Si no especificas una región o una zona para los trabajadores cuando creas un trabajo, Dataflow automáticamente usa de forma predeterminada una zona que se encuentra en la misma región que el trabajo.

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

Consideraciones sobre la encriptación de datos

Como un servicio completamente administrado, Dataflow encripta de forma automática los datos que se mueven a través de tu canalización de datos mediante claves de Google y administradas por Google para los datos en tránsito y en reposo. En lugar de usar claves que administra y que son propiedad de Google, tal vez prefieras administrar tus propias claves de encriptación. Para ese caso, Dataflow admite claves de encriptación administradas 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 encriptación y realizar operaciones criptográficas en un clúster de HSM certificados con el nivel 3 del estándar FIPS 140-2.

Cuando usas CMEK, Dataflow usa tu clave de Cloud KMS para encriptar los datos, excepto las operaciones basadas en claves de datos, como la renderización en ventanas, la agrupación y la unión. Si las claves de datos contienen datos sensibles, como información de identificación personal (PII), debes aplicar un hash o transformar las claves antes de que ingresen a la canalización de Dataflow.

Consideraciones sobre las Herramientas de redes privadas

Tus requisitos de herramientas de redes y seguridad pueden requerir que las cargas de trabajo basadas en VM, como los trabajos de Dataflow, solo usen direcciones IP privadas. Dataflow te permite especificar que los trabajadores usen direcciones IP privadas para todas las comunicaciones de red. Si las IP públicas están inhabilitadas, debes habilitar el Acceso privado a Google en la subred para que los trabajadores de Dataflow puedan acceder a las APIs y los servicios de Google.

Te recomendamos inhabilitar las IP públicas para los trabajadores de Dataflow, a menos que los trabajos de Dataflow requieran IP públicas a fin de acceder a los recursos de red fuera de Google Cloud. Inhabilitar las IP públicas también evita que los trabajadores de Dataflow accedan a recursos fuera de la subred o a redes de VPC de intercambio de tráfico. Del mismo modo, también se evita el acceso de red a los trabajadores de la VM desde fuera de la subred o las redes de VPC de intercambio de tráfico.

Si deseas obtener más información sobre el uso de la opción de canalización --usePublicIps para especificar si los trabajadores deben tener solo IP privadas, consulta Opciones de canalización.

¿Qué sigue?

• Desarrolla y prueba tu canalización.
• Obtén información sobre cómo diseñar flujos de trabajo de canalización completos.
• Obtén más información sobre las prácticas de ingeniería de confiabilidad de sitios (SRE) de Google para las canalizaciones de procesamiento de datos.