Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Os modelos do Dataflow permitem que você empacote um pipeline do Dataflow para implantação.
Qualquer pessoa com as permissões corretas pode usar o modelo para implantar o pipeline empacotado.
Você pode criar seus próprios modelos personalizados do Dataflow, e o Google fornece
modelos pré-criados para situações
comuns.
Benefícios
Os modelos têm várias vantagens em relação à implantação direta de um pipeline no Dataflow:
Os modelos separam o design do pipeline da implantação Por exemplo, um desenvolvedor pode criar um
modelo, e um cientista de dados pode implantá-lo mais tarde.
Os modelos podem ter parâmetros que permitem personalizar o pipeline ao implantar o
modelo.
É possível implantar um modelo usando o console Google Cloud , a Google Cloud CLI ou as chamadas da
API REST. Não é necessário um ambiente de desenvolvimento nem qualquer dependência de pipeline instalada na sua
máquina local.
Um modelo é um artefato de código que pode ser armazenado em um repositório de controle de origem e usado em
pipelines de integração contínua de CI/CD.
Modelos fornecidos pelo Google
O Google fornece uma variedade de modelos do Dataflow pré-criados e de código aberto que podem ser usados em cenários comuns. Para mais informações sobre os modelos disponíveis, consulte Modelos fornecidos pelo Google.
Comparar modelos Flex e clássicos
O Dataflow é compatível com dois tipos de modelo: Flex, novos e clássicos. Se você estiver criando um novo modelo do Dataflow, recomendamos criá-lo como um modelo Flex.
Com um modelo Flex, o pipeline é empacotado como uma imagem do Docker no Artifact Registry, junto com um arquivo de especificação de modelo no Cloud Storage. A especificação do modelo contém um ponteiro para a imagem do Docker. Quando você executa o modelo, o serviço do Dataflow inicia uma VM do inicializador, extrai a imagem do Docker e executa o pipeline. O gráfico de execução é criado dinamicamente com base nos parâmetros de ambiente de execução fornecidos pelo usuário. Para usar a API na inicialização de um job com um modelo Flex, use o
método projects.locations.flexTemplates.launch.
Um modelo clássico contém a serialização JSON de um gráfico de job do Dataflow. O
código do pipeline precisa unir todos os parâmetros de ambiente de execução na interface
ValueProvider. Essa interface permite que os usuários especifiquem valores de parâmetro quando implantam o
modelo. Se quiser usar a API para trabalhar com modelos clássicos, consulte a
documentação de referência da API
projects.locations.templates.
Os modelos flexíveis têm as seguintes vantagens em relação aos modelos clássicos:
Ao contrário dos modelos clássicos, os Flex não exigem a interface ValueProvider para parâmetros de entrada. Nem todas as origens e coletores do Dataflow oferecem suporte ao
ValueProvider.
Os modelos clássicos têm um gráfico de jobs estático, mas os modelos Flex podem construir dinamicamente
o gráfico de jobs. Por exemplo, o modelo pode selecionar um conector de E/S diferente com base nos parâmetros
de entrada.
Um modelo Flex pode realizar o pré-processamento em uma máquina virtual (VM) durante a
construção do pipeline. Por exemplo, ele pode validar valores de parâmetro de entrada.
Fluxo de trabalho de modelo
O uso de modelos do Dataflow envolve as seguintes etapas gerais:
Os desenvolvedores configuram um ambiente de desenvolvimento e desenvolvem seu pipeline. O ambiente inclui o SDK do Apache Beam e outras dependências.
Dependendo do tipo de modelo (flexível ou clássico):
Para modelos Flex, os desenvolvedores empacotam o pipeline em uma imagem do Docker, enviam a imagem para o Artifact Registry e fazem upload de um arquivo de especificação do modelo
para o Cloud Storage.
Para modelos clássicos, os desenvolvedores executam o pipeline, criam um arquivo de modelo e organizam o modelo no Cloud Storage.
Outros usuários enviam uma solicitação ao serviço do Dataflow para executar o modelo.
O Dataflow cria um pipeline com base no modelo. O pipeline pode levar de
cinco a sete minutos para começar a ser executado.
Definir permissões do IAM
Os jobs do Dataflow, incluindo aqueles executados a partir de modelos, usam duas contas de serviço do IAM:
O serviço do Dataflow usa uma
conta de serviço do Dataflow
para manipular recursos do Google Cloud , como a criação de VMs.
As VMs de workers do Dataflow usam uma
conta de serviço de worker
para acessar arquivos e outros recursos do seu pipeline. Essa conta de serviço precisa ter acesso a todos os recursos aos quais o job de pipeline faz referência, incluindo a origem e o coletor usados pelo modelo. Para mais informações, consulte
Acessar Google Cloud recursos.
Verifique se essas duas contas de serviço têm os papéis apropriados. Para mais informações, consulte Segurança
e permissões do Dataflow.
Requisitos de versão do SDK do Apache Beam
Para criar seus próprios modelos, verifique se a versão do SDK do Apache Beam é compatível com a criação
de modelos.
Java
Para criar modelos com o SDK 2.x do Apache Beam para Java, você precisa ter a versão
2.0.0-beta3 ou posterior.
Python
Para criar modelos com o SDK 2.x do Apache Beam para Python, você precisa ter a versão 2.0.0
ou posterior.
Para executar modelos com a Google Cloud CLI, você precisa ter a Google Cloud CLI
na versão 138.0.0 ou mais recente.
Estender modelos
Use os modelos de
código aberto
do Dataflow para criar os seus próprios. Por exemplo, para um modelo que usa uma duração de janela fixa, os dados
que chegam fora dela podem ser descartados. Para evitar esse comportamento, use o código do modelo
como base e faça as mudanças para invocar a
operação .withAllowedLateness.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2025-08-18 UTC."],[[["\u003cp\u003eDataflow templates allow you to package a Dataflow pipeline for deployment, enabling users with permissions to deploy the packaged pipeline.\u003c/p\u003e\n"],["\u003cp\u003eFlex templates are recommended over classic templates for new Dataflow template creation due to their advantages, such as not requiring the \u003ccode\u003eValueProvider\u003c/code\u003e interface and allowing for dynamic job graph construction.\u003c/p\u003e\n"],["\u003cp\u003eDataflow templates separate pipeline design from deployment, allowing customization through parameters and offering deployment via the Google Cloud console, CLI, or REST API without a development environment.\u003c/p\u003e\n"],["\u003cp\u003eUsing Dataflow templates involves developers packaging the pipeline and other users submitting a request to run it, with Dataflow then creating a pipeline from the template, which can take several minutes to start.\u003c/p\u003e\n"],["\u003cp\u003eDataflow jobs run from templates use two IAM service accounts, a Dataflow service account for manipulating resources and a worker service account for accessing pipeline files and resources.\u003c/p\u003e\n"]]],[],null,["# Dataflow templates allow you to package a Dataflow pipeline for deployment.\nAnyone with the correct permissions can then use the template to deploy the packaged pipeline.\nYou can create your own custom Dataflow templates, and Google provides\n[pre-built templates](/dataflow/docs/templates/provided-templates) for common\nscenarios.\n\nBenefits\n--------\n\nTemplates have several advantages over directly deploying a pipeline to Dataflow:\n\n- Templates separate pipeline design from deployment. For example, a developer can create a template, and a data scientist can deploy the template at a later time.\n- Templates can have parameters that let you customize the pipeline when you deploy the template.\n- You can deploy a template by using the Google Cloud console, the Google Cloud CLI, or REST API calls. You don't need a development environment or any pipeline dependencies installed on your local machine.\n- A template is a code artifact that can be stored in a source control repository and used in continuous integration (CI/CD) pipelines.\n\nGoogle-provided templates\n-------------------------\n\nGoogle provides a variety of pre-built, open source Dataflow templates that you\ncan use for common scenarios. For more information about the available templates, see\n[Google-provided templates](/dataflow/docs/templates/provided-templates).\n\nCompare Flex templates and classic templates\n--------------------------------------------\n\nDataflow supports two types of template: Flex templates, which are newer, and\nclassic templates. If you are creating a new Dataflow template, we recommend\ncreating it as a Flex template.\n\nWith a Flex template, the pipeline is packaged as a Docker image in\nArtifact Registry, along with a template specification file in Cloud Storage. The template\nspecification contains a pointer to the Docker image. When you run the template, the\nDataflow service starts a launcher VM, pulls the Docker image, and runs the\npipeline. The execution graph is dynamically built based on runtime parameters provided by the\nuser. To use the API to launch a job that uses a Flex template, use the\n[`projects.locations.flexTemplates.launch`](/dataflow/docs/reference/rest/v1b3/projects.locations.flexTemplates/launch) method.\n\nA classic template contains the JSON serialization of a Dataflow job graph. The\ncode for the pipeline must wrap any runtime parameters in the `ValueProvider`\ninterface. This interface allows users to specify parameter values when they deploy the\ntemplate. To use the API to work with classic templates, see the\n[`projects.locations.templates`](/dataflow/docs/reference/rest/v1b3/projects.locations.templates)\nAPI reference documentation.\n\nFlex templates have the following advantages over classic templates:\n\n- Unlike classic templates, Flex templates don't require the `ValueProvider` interface for input parameters. Not all Dataflow sources and sinks support `ValueProvider`.\n- While classic templates have a static job graph, Flex templates can dynamically construct the job graph. For example, the template might select a different I/O connector based on input parameters.\n- A Flex template can perform preprocessing on a virtual machine (VM) during pipeline construction. For example, it might validate input parameter values.\n\nTemplate workflow\n-----------------\n\nUsing Dataflow templates involves the following high-level steps:\n\n1. Developers set up a development environment and develop their pipeline. The environment includes the Apache Beam SDK and other dependencies.\n2. Depending on the template type (Flex or classic):\n - For Flex templates, the developers package the pipeline into a Docker image, push the image to Artifact Registry, and upload a template specification file to Cloud Storage.\n - For classic templates, developers run the pipeline, create a template file, and stage the template to Cloud Storage.\n3. Other users submit a request to the Dataflow service to run the template.\n4. Dataflow creates a pipeline from the template. The pipeline can take as much as five to seven minutes to start running.\n\nSet IAM permissions\n-------------------\n\nDataflow jobs, including jobs run from templates, use two IAM service accounts:\n\n- The Dataflow service uses a [Dataflow service account](/dataflow/docs/concepts/security-and-permissions#service_account) to manipulate Google Cloud resources, such as creating VMs.\n- The Dataflow worker VMs use a [worker service account](/dataflow/docs/concepts/security-and-permissions#worker-service-account) to access your pipeline's files and other resources. This service account needs access to any resources that the pipeline job references, including the source and sink that the template uses. For more information, see [Access Google Cloud resources](/dataflow/docs/concepts/security-and-permissions#access-resources).\n\nEnsure that these two service accounts have appropriate roles. For more\ninformation, see\n[Dataflow security and permissions](/dataflow/docs/concepts/security-and-permissions).\n\nApache Beam SDK version requirements\n------------------------------------\n\nTo create your own templates, make sure your Apache Beam SDK version supports template\ncreation. \n\n### Java\n\nTo create templates with the Apache Beam SDK 2.x for Java, you must have version\n2.0.0-beta3 or higher.\n\n### Python\n\nTo create templates with the Apache Beam SDK 2.x for Python, you must have version 2.0.0\nor higher.\n\nTo run templates with Google Cloud CLI, you must have [Google Cloud CLI](/sdk/downloads)\nversion 138.0.0 or higher.\n\nExtend templates\n----------------\n\nYou can build your own templates by extending the\n[open source](https://github.com/GoogleCloudPlatform/DataflowTemplates)\nDataflow templates. For example, for a template that uses a fixed window duration, data\nthat arrives outside of the window might be discarded. To avoid this behavior, use the template\ncode as a base, and modify the code to invoke the\n[`.withAllowedLateness`](https://beam.apache.org/documentation/programming-guide/#managing-late-data) operation.\n\nWhat's next\n-----------\n\n- [Google-provided templates](/dataflow/docs/templates/provided-templates)\n- [Creating classic templates](/dataflow/docs/templates/creating-templates)\n- [Running classic templates](/dataflow/docs/templates/executing-templates)\n- [Build and run Flex Templates](/dataflow/docs/guides/templates/using-flex-templates)\n- [Troubleshoot Flex Templates](/dataflow/docs/guides/troubleshoot-templates)"]]