O Google Cloud Dataflow oferece um sistema de processamento de dados totalmente gerenciado para executar pipelines do Apache Beam no Google Cloud de maneira altamente escalonável. Por se tratar de um serviço totalmente gerenciado, os usuários do Dataflow não precisam se preocupar com regressões e controles de versão no lado do serviço. A ideia é que você se preocupe apenas com a lógica do pipeline e deixe que o Google gerencie a infraestrutura do serviço. Embora isso seja verdade, o próprio Apache Beam é um SDK com muitos recursos que fornece desde transformações simples até transformações altamente complexas para uso em seus pipelines. Por exemplo, o Apache Beam fornece vários conectores de E/S. Muitos deles são transformações compostas do Apache Beam com dezenas ou até centenas de etapas. Eles sempre foram considerados "código de usuário" sob o ponto de vista do serviço, embora não sejam criados nem mantidos pelo usuário. Existem várias complicações comuns que os clientes enfrentam em transformações complexas do Beam, como os conectores de E/S.
Para lidar com essas três questões, o Dataflow introduziu recentemente uma nova oferta chamada Managed I/O. Com o Managed I/O, o próprio serviço é capaz de gerenciar essas complexidades em seu nome. Assim, você pode realmente se concentrar na lógica de negócios dos pipelines em vez de nos detalhes relacionados ao uso e à configuração de um conector específico para atender às necessidades deles. A seguir, detalhamos como cada uma das complexidades mencionadas acima é tratada por meio do Managed I/O.
O Apache Beam é um SDK completo e com um monte de transformações, recursos e otimização. Assim como em muitos softwares grandes, o upgrade do Beam para uma nova versão pode ser um processo significativo. Normalmente, o upgrade do Beam envolve fazer o upgrade de todas as partes de um pipeline, incluindo todos os conectores de E/S. Mas, em alguns casos, basta obter acesso a uma correção de bug crítica ou a uma melhoria disponível na versão mais recente de um ou mais conectores de E/S usados no pipeline.
Managed I/O with Dataflow simplifies this by completely taking over the management of the Beam I/O connector version. With Managed I/O, Dataflow will make sure that I/O connectors used by pipelines are always up to date. Dataflow performs this by always upgrading I/O connectors to the latest vetted version during job submission and streaming update via replacement.
For example, assume that you use a Beam pipeline that uses Beam 2.x.0 and assume that you use the Managed Apache Iceberg I/O source in your pipeline. Also, assume that the latest vetted version of the Iceberg I/O source supported by Dataflow is 2.y.0. During job submission, Dataflow will replace this specific connector with version 2.y.0 and will keep the rest of the Beam pipeline including any standard (non-managed) I/O connectors at version 2.x.0.
Após a substituição, o Dataflow otimiza o pipeline atualizado e o executa no GCE. Para alcançar o isolamento entre conectores de diferentes versões do Beam, o Dataflow implanta um contêiner adicional do SDK do Beam nas VMs do GCE. Portanto, neste caso, os contêineres do SDK do Beam das versões 2.x.0 e 2.y.0 serão executados em cada VM do GCE usada pelo job do Dataflow.
Desse modo, com o Managed I/O, você pode ter a certeza de que os conectores de E/S usados no pipeline sempre estarão atualizados. Isso permite que você se concentre na melhoria da lógica de negócios do pipeline sem a preocupação de fazer upgrade da versão do Beam apenas para obter atualizações dos conectores de E/S.
As diferenças de APIs entre os conectores de E/S do Beam variam muito. Isso significa que, sempre que você tentar usar um novo conector de E/S do Beam, precisará aprender a trabalhar com uma API específica para esse conector. Algumas APIs podem ser muito grandes e não intuitivas. Isso pode ser devido:
Os pontos acima resultam em plataformas de API muito grandes para alguns conectores, que não são intuitivas para que um novo cliente as utilize com eficiência.
Managed I/O offers standardized Java and Python APIs for supported I/O connectors. For example, with Beam Java SDK an I/O connector source can be instantiated in the following standardized form.
Managed.read(SOURCE).withConfig(sourceConfig)
An I/O connector sink can be instantiated in the following form.
Managed.write(SINK).withConfig(sinkConfig)
Here SOURCE and SINK are keys specifically identifying the connector while sourceConfig and sinkConfig are maps of configurations used to instantiate the connector source or sink. The map of configurations may also be provided as YAML files available locally or in Google Cloud Storage. Please see the Managed I/O website for more complete examples for supported sources and sinks.
O SDK do Python para Beam oferece uma API igualmente simplificada.
Isso significa que vários conectores de E/S do Beam com diferentes APIs podem ser instanciados de uma forma muito padronizada. Por exemplo:
// Create a Java BigQuery I/O source
Map<String, Object> bqReadConfig = ImmutableMap.of("query", "<query>", ...);
Managed.read(Managed.BIGQUERY).withConfig(bqReadConfig)
// Create a Java Kafka I/O source.
Map<String, Object> kafkaReadConfig = ImmutableMap.of("bootstrap_servers", "<server>", "topic", "<topic>", ...);
Managed.read(Managed.KAFKA).withConfig(kafkaReadConfig)
// Create a Java Kafka I/O source but with a YAML based config available in Google Cloud Storage.
String kafkaReadYAMLConfig = "gs://path/to/config.yaml"
Managed.read(Managed.KAFKA).withConfigUrl(kafkaReadYAMLConfig)
// Create a Python Iceberg I/O source.
iceberg_config = {"table": "<table>", ...}
managed.Read(managed.ICEBERG, config=iceberg_config)
Muitos conectores do Beam oferecem uma API abrangente para configurar e otimizar o conector de acordo com um pipeline e um executor do Beam determinados. Uma desvantagem disso é que, se você quiser especificamente que a execução ocorra no Dataflow, talvez seja necessário aprender sobre as configurações específicas mais apropriadas para o Dataflow e aplicá-las ao configurar o pipeline. A documentação relacionada ao conector pode ser longa e detalhada, e as mudanças específicas necessárias podem não ser intuitivas. Isso pode fazer com que os conectores usados em pipelines do Dataflow tenham um desempenho abaixo do ideal.
O gerenciamento de conectores de E/S resolve isso ao reconfigurar automaticamente os conectores para incorporar as práticas recomendadas e configurá-los para se adequarem melhor ao Dataflow. Essa configuração pode ocorrer durante o envio do job ou a atualização do streaming via substituição.
Por exemplo, os pipelines de streaming do Dataflow oferecem dois modos: exactly-once e at-least-once. Já o coletor de E/S do BigQuery com a API Storage Write oferece duas semânticas de entrega similares: exactly-once e at-least-once. O coletor do BigQuery com semântica de entrega at-least-once geralmente é mais barato e resulta em latências mais baixas. Com os conectores de E/S padrão do BigQuery, você é responsável por garantir o uso do modo apropriado ao usar a E/S do BigQuery. Com o coletor Managed I/O para BigQuery, isso é configurado automaticamente para você. Isso significa que, se o pipeline de streaming estiver operando no modo at-least-once, o coletor Managed I/O para BigQuery será configurado automaticamente para usar a semântica de entrega at-least-once.
Executamos vários pipelines que gravavam dados usando o coletor Managed I/O para Iceberg apoiado por um catálogo do Hadoop implantado no GCS (veja aqui os outros catálogos com suporte). Os pipelines foram enviados usando o Beam 2.61.0, e o Dataflow fez o upgrade automático do coletor Managed I/O para a versão mais recente com suporte. Todos os comparativos de mercado usaram VMs n1-standard-4, e o número de VMs usadas pelo pipeline foi fixado em 100. Observe que o tempo de execução aqui não inclui o tempo de inicialização e desligamento.
Como mostram os comparativos de mercado, o Managed I/O para Iceberg foi bem escalonado verticalmente, e ambas as métricas aumentaram de forma linear com o tamanho dos dados.
Também executamos um pipeline de streaming que fazia a leitura do Google Pub/Sub e usamos o coletor Managed I/O para Kafka para enviar mensagens por push para um cluster do Kafka hospedado no GCP. O pipeline usou o Beam 2.61.0, e o Dataflow fez o upgrade do coletor Managed para Kafka para a versão mais recente com suporte. Durante o estado estável, o pipeline usou 10 VMs n1-standard-4 (máx. de 20 VMs). O pipeline processou as mensagens consistentemente com uma capacidade de processamento de 250 mil mensagens/s em todas as etapas e foi executado por 2 horas.
O gráfico a seguir mostra as capacidades de processamento de dados de várias etapas do pipeline. Observe que as capacidades de processamento são diferentes aqui, pois o tamanho do elemento muda entre as etapas. O pipeline fez a leitura do Pub/Sub a uma taxa de 75 MiB/s (linha vermelha) e gravou no Kafka a uma taxa de 40 MiB/s (linha verde).
Tanto a latência quanto o backlog permaneceram baixos durante a execução do pipeline.
O pipeline usou a CPU e a memória da VM de maneira eficiente.
Como esses resultados demonstram, o pipeline foi executado de maneira eficiente com o coletor Managed I/O para Kafka atualizado, fornecido pelo serviço Dataflow.
Usar o Managed I/O é tão simples quanto usar uma das origens e dos coletores com suporte em seu pipeline e executar o pipeline com o Dataflow Runner v2. Ao executar o pipeline, o Dataflow garantirá que as versões mais recentes validadas das origens e dos coletores estejam ativadas durante o envio do job e a atualização do streaming via substituição, mesmo que você esteja usando uma versão mais antiga do Beam para o pipeline.
