Guia de planejamento do BigQuery Connector para SAP

Este guia de planejamento fornece aos administradores do SAP e do Google Cloud as informações necessárias para planejar a replicação de dados SAP no BigQuery usando a versão 2.9 (mais recente) do BigQuery Connector para SAP com o SAP LT Replication Server.

Neste guia, abordamos os seguintes tópicos:

• Requisitos de software
• Segurança
• Rede
• Planejamento de desempenho
• Opções de mapeamento de tabela e campo
• Ciclo de vida do suporte

Para informações sobre aceleradores de solução para modelagem de dados SAP no BigQuery, consulte o Google Cloud Cortex Framework.

Requisitos de software

Esta seção descreve os requisitos de software do BigQuery Connector para SAP.

É possível instalar o BigQuery Connector para SAP no SAP LT Replication Server no Google Cloud, no local ou em nuvens públicas, como AWS, Azure, e assim por diante.

Requisitos da versão de software do SAP

As versões necessárias do SAP LT Replication Server e dos sistemas de origem da SAP diferem quando você instala o SAP LT Replication Server no próprio servidor em uma arquitetura independente ou no sistema de aplicativos ABAP de origem em uma incorporação.

Os requisitos de software da SAP também são diferentes, dependendo do sistema SAP que você usa como fonte de dados: SAP S/4HANA ou SAP ECC.

Para ver as versões de software do SAP compatíveis com o Google Cloud Connector para BigQuery, selecione a guia que corresponde ao seu sistema de origem SAP:

Requisitos de sistema operacional

O conector do BigQuery para SAP é compatível com qualquer sistema operacional compatível com o SAP LT Replication Server.

Para informações sobre quais sistemas operacionais são compatíveis com o SAP LT Replication Server, consulte a Matriz de disponibilidade de produtos SAP (em inglês).

Requisito da conta do Cloud Billing

Embora o BigQuery Connector para SAP seja oferecido sem custos financeiros, você precisa de uma conta do Cloud Billing para receber o pacote de instalação.

Escalonabilidade

Para volumes muito grandes, como bilhões de registros de dados com milhões de deltas, o BigQuery Connector para SAP usa as funções de escalonamento e particionamento do SAP LT Replication Server para fazer a extração de dados em paralelo em escala. Para mais informações, consulte o Guia de dimensionamento da sua versão do SAP LT Replication Server no portal de ajuda da SAP.

No lado do Google Cloud , dependendo do caminho de replicação, o BigQuery Connector para SAP usa diferentes serviços do Google Cloud para escalonar o carregamento de dados:

• Para a replicação de CDC pelo Pub/Sub, o BigQuery Connector para SAP usa a API Pub/Sub e a API Storage Write.
• Para a replicação de dados de streaming, o BigQuery Connector para SAP usa a API BigQuery Streaming.

Origens de replicação compatíveis

O BigQuery Connector para SAP é compatível com a maioria dos sistemas de origem de aplicativos e bancos de dados mais usados, que são compatíveis com o SAP LT Replication Server.

Origens de aplicativos SAP compatíveis

É possível replicar dados das fontes de aplicativos SAP compatíveis com o SAP LT Replication Server. O BigQuery Connector para SAP dá suporte às principais versões de aplicativos empresariais em manutenção como fontes de dados, além de aplicativos legados mais antigos. Alguns dos aplicativos SAP compatíveis incluem:

• SAP Business Suite 7
• S/4HANA
• Aplicativos SAP em execução no SAP NetWeaver

Para replicar dados do SAP Business Warehouse, a SAP não recomenda o uso do SAP LT Replication Server. Para mais informações da SAP, consulte a Nota SAP 2525755.

Não há suporte para aplicativos SAP Cloud, como S/4HANA Cloud, SAP Ariba, SAP SuccessFactors e outros.

Fontes de dados compatíveis

Só é possível replicar tabelas transparentes ou em clusters.

O BigQuery Connector para SAP não é compatível com as visualizações de replicação do SAP Core Data Services (CDS).

Na ferramenta de design de informações, o BigQuery é compatível a partir do SAP BusinessObjects Business Intelligence 4.3 como fonte de dados. É possível consultar dados armazenados no BigQuery usando as ferramentas de relatórios do SAP BusinessObjects, como SAP BusinessObjects Web Intelligence e SAP Crystal Reports for Enterprise, entre outras.

Para mais informações sobre a verificação de compatibilidade da Nota SAP 2750723 - Suporte do Google BigQuery em produtos de plataforma de BI SAP (em inglês).

Segurança

Ao implementar a segurança para replicação de dados do SAP LT Replication Server para o BigQuery, é necessário implementar controles de segurança no SAP LT Replication Server, no sistema operacional do host SAP LT Replication Server e no Google Cloud.

Para a comunicação entre o BigQuery Connector para SAP e o BigQuery, o BigQuery Connector para SAP usa SSL e comunicação HTTPS de ponta a ponta.

Segurança do SAP

Para controlar quem pode configurar e trabalhar com o BigQuery Connector para SAP no SAP LT Replication Server, use a autorização padrão baseada em papéis do SAP.

O conector do BigQuery para SAP fornece o objeto de autorização ZGOOG_MTID como parte da instalação do transporte.

Para configurar e executar jobs de replicação de dados que usam o conector do BigQuery para SAP, é possível definir um papel que tenha acesso administrativo no SAP LT Replication Server, conforme descrito em Criar papéis e autorizações do SAP para BigQuery Connector para SAP.

Por exemplo, é possível definir um papel chamado ZGOOGLE_BIGQUERY_ADMIN que tenha todas as autorizações SAP e ZGOOG_MTID autorizações necessárias para configurar e operar a replicação de dados no BigQuery usando o Conector do BigQuery para SAP.

Para mais informações da SAP sobre papéis e autorização, consulte o Guia de segurança da sua versão do servidor de replicação do SAP LT no portal de ajuda da SAP (em inglês).

Segurança doGoogle Cloud

A implementação da segurança no Google Cloud para BigQuery Connector para SAP pode envolver os seguintes controles de segurança:

• Permissões de gerenciamento de identidade e acesso (IAM), papéis, contas de serviço e chaves.
• Controles do BigQuery definidos no nível do conjunto de dados ou da tabela.
• Controles de serviço de nuvem privada virtual (VPC) para serviços baseados em API, como o BigQuery.
• Endpoints do Private Service Connect que permitem o consumo particular de serviços, como o BigQuery, em redes VPC.

Google Cloud Identity and Access Management

Para a autenticação e autorização do BigQuery Connector para SAP, você precisa de uma conta de serviço do IAM no projetoGoogle Cloud que contém o conjunto de dados do BigQuery.

Para a autorização interagir com os recursos do Google Cloud , você concede papéis à conta de serviço que contém permissões para interagir com os serviços do BigQuery e do Pub/Sub.

Para replicação de dados de streaming (somente inserção), as permissões que o BigQuery Connector para SAP precisa para acessar o BigQuery estão contidas nos seguintes papéis do IAM:

• Editor de dados do BigQuery
• Usuário de jobs do BigQuery

Para a replicação de captura de dados de mudança (CDC, na sigla em inglês), as permissões que o BigQuery Connector para SAP precisa para acessar o Pub/Sub e o BigQuery estão contidas nos seguintes papéis do IAM:

• Editor de dados do BigQuery
• Usuário de jobs do BigQuery
• Editor do Pub/Sub

Se o servidor de replicação do SAP LT estiver em execução em uma VM do Compute Engine, você também precisará conceder o papel Criador de token da conta de serviço à conta de serviço da VM do host.

Se o SAP LT Replication Server estiver sendo executado no local ou em outra plataforma de nuvem, além de criar uma conta de serviço, você também precisará criar uma chave de conta de serviço para o BigQuery Connector para SAP. O administrador do SAP instala a chave no host do servidor SAP LT Replication. Quando o BigQuery Connector para SAP se conecta ao Pub/Sub ou ao BigQuery, o servidor de replicação do SAP LT usa a chave da conta de serviço para fazer a autenticação com Google Cloud.

Uma chave de conta de serviço não é necessária quando o SAP LT Replication Server está em execução no Google Cloud.

Para mais informações sobre o IAM, contas de serviço, papéis e permissões, consulte:

• Contas de serviço
• Como autenticar como uma conta de serviço
• Práticas recomendadas de conta de serviço
• Introdução à API BigQuery para autenticação

Controles de acesso de conjuntos de dados e tabelas do BigQuery

Além dos controles do IAM, também é possível controlar o acesso usando o BigQuery. No BigQuery Connector para SAP, é possível definir controles de acesso em conjuntos de dados e tabelas.

Veja mais informações em:

• Como controlar o acesso a conjuntos de dados
• Como controlar o acesso a tabelas

VPC Service Controls

No Google Cloud, as regras de firewall da VPC não são aplicáveis a interações baseadas em API com o BigQuery. Em vez disso, é possível usar os controles de serviço da nuvem privada virtual (VPC, na sigla em inglês) para restringir o tráfego.

Se a carga de trabalho da SAP estiver em execução no Google Cloud, defina perímetros de serviço da VPC para implementar o VPC Service Controls. Para mais informações, consulte Perímetros de serviço.

Se a carga de trabalho da SAP não estiver sendo executada no Google Cloud, implemente o VPC Service Controls como parte da configuração do Acesso privado do Google para hosts no local.

Para mais informações sobre segurança de rede para o BigQuery, consulte Segurança de rede.

Endpoints do Private Service Connect

Se você quiser configurar endpoints na sua rede VPC que permitam o consumo particular de serviços gerenciados pelo Google, como o BigQuery, use o Private Service Connect.

O Private Service Connect permite criar endpoints particulares que usam endereços IP internos de um intervalo CIDR de VPC para acessar APIs e serviços do Google. Também é possível usar o Private Service Connect para criar um nome DNS particular personalizado para a API de streaming do BigQuery. Para mais informações, consulte Private Service Connect.

Quando o BigQuery Connector para SAP é executado em um host fora do Google Cloud, não há suporte para o Private Service Connect.

Mais informações sobre a segurança do Google Cloud

Para obter mais informações sobre contas de serviço, papéis e permissões, consulte:

• Contas de serviço
• Como criar e ativar contas de serviço nas instâncias
• Visão geral sobre segurança e governança de dados
• Autenticação e autorização do BigQuery

Rede

Ao planejar o caminho de rede para replicação no BigQuery, considere os seguintes pontos:

• Largura de banda
• A latência e o impacto dela no consumo de recursos no host do SAP LT Replication Server
• O volume de dados e o impacto disso em qualquer carga de rede existente
• Se sua carga de trabalho da SAP não estiver sendo executada no Google Cloud, que tipo de conexão usar: Cloud Interconnect ou Cloud VPN

Conectando a Google Cloud

Se os sistemas SAP não estiverem sendo executados no Google Cloud e você ainda não tiver uma conexão dos sistemas SAP com o Google Cloud, será necessário estabelecer uma conexão e configurar o acesso privado às APIs do Google Cloud .

É possível estabelecer uma conexão com Google Cloud usando o Cloud Interconnect ou o Cloud VPN.

O Cloud Interconnect normalmente oferece largura de banda maior, menor latência e menor contenção de rede do que o Cloud VPN. Para jobs de replicação de alto volume e sensíveis ao desempenho, Google Cloud recomenda o Cloud Interconnect para BigQuery Connector para SAP.

Com o Cloud VPN, os dados de replicação são transmitidos pela Internet pública, portanto, a contenção de rede é menos previsível e as latências, em geral, são mais altas.

Independentemente da opção de conexão escolhida, é necessário analisar todo o tráfego que você espera que a conexão seja compatível. Determine se a conexão tem largura de banda e velocidade de rede suficientes para aceitar jobs de replicação e outras cargas de trabalho sem afetar negativamente nenhuma.

Conexões lentas podem aumentar o consumo de recursos no servidor de origem do SAP e no host do servidor de replicação do LT da SAP, estendendo o tempo necessário para a conclusão dos jobs e mantendo os recursos necessários para replicação vinculados por períodos mais longos.

Para mais informações sobre as opções de conexão, consulte o seguinte:

• Conectando a Google Cloud
• Visão geral do Cloud Interconnect
• Visão geral do Cloud VPN

Para usar um servidor proxy para enviar as solicitações HTTP a Google Cloud, recomendamos que você use destinos do RFC definidos na transação SM59.

Destinos do RFC

Os arquivos de transporte do BigQuery Connector para SAP contêm os seguintes exemplos de destinos do RFC na transação SM59. Esses destinos do RFC são conexões HTTP com servidores externos (tipo G) e se conectam ao endpoint da API pública do serviço respectivo.

Amostra de nome de destino do RFC	Host de destino (endpoint da API)	Observações
GOOG_BIGQUERY	https://bigquery.googleapis.com	Este destino do RFC é destinado à API BigQuery.
GOOG_PUBSUB	https://pubsub.googleapis.com	Este destino RFC segmenta a API Pub/Sub.
GOOG_IAMCREDENTIALS	https://iamcredentials.googleapis.com	Este destino do RFC é destinado à API do IAM.
GOOG_OAUTH2_TOKEN	https://googleapis.com/oauth2	Este destino do RFC é destinado ao endpoint Google Cloud para autenticação baseada em OAuth 2.0. Ele é usado para cargas de trabalho SAP que são executadas fora do Google Cloud e somente quando você quer autenticar no Google Cloud usando JSON Web Token (JWT).

O uso de destinos RFC para se conectar ao Google Cloud oferece as seguintes vantagens:

• Se você usa um servidor proxy no cenário do SAP e quer usar o mesmo para enviar as solicitações HTTP a Google Cloud, configure o servidor proxy no destino RFC.

• Se você quiser permitir o acesso às APIs e serviços do Google Cloud por meio de endpoints do Private Service Connect, é possível criar esses endpoints no projeto doGoogle Cloud e, em seguida, especificá-los nos destinos do RFC.

• É possível usar a compactação HTTP, recomendada pelo Google Cloud para replicações entre regiões, em que o sistema de origem SAP e o conjunto de dados do BigQuery são colocados em diferentes regiões do Compute Engine.

Se quiser usar destinos RFC para se conectar a serviços ou APIs do Google Cloud , você precisa criar entradas na tabela /GOOG/SERVIC_MAP que mapeiem os destinos do RFC para a tabela /GOOG/CLIENT_KEY. Para ver as etapas de configuração, consulte o guia de instalação e configuração do BigQuery Connector para SAP para seu cenário.

Compactação HTTP

Ao usar destinos RFC para configurar a conexão entre o BigQuery Connector para SAP e as APIs do Google Cloud , você pode usar a opção Compactação para compactar o corpo da solicitação HTTP. A compactação HTTP só está disponível quando você configura seus destinos RFC para usar HTTP 1.1.

Antes de ativar a compactação HTTP no seu ambiente de produção, analise os parâmetros do perfil que afetam a compactação HTTP em um ambiente de teste. Para mais informações da SAP, consulte a Nota SAP 1037677: a compactação HTTP compacta apenas alguns documentos.

Largura de banda

Verifique se a conexão de rede entre o SAP LT Replication Server e o Google Cloud tem largura de banda suficiente para atender ao volume de dados na velocidade necessária.

Conexões de rede mais lentas aumentam a latência da replicação de dados, o que aumenta os recursos que a replicação usa no sistema SAP de origem.

Para instalações produtivas, Google Cloud recomenda uma conexão do Cloud Interconnect. Também é possível usar o Cloud VPN.

Latência

Para reduzir a latência na conexão de rede, crie o conjunto de dados de destino do BigQuery o mais próximo possível do sistema SAP LT Replication Server e do sistema de origem SAP. Se o sistema SAP de origem estiver em execução no Google Cloud, crie o conjunto de dados do BigQuery na mesma região do Google Cloud que o sistema SAP de origem.

Teste a latência antes de migrar a instalação para um ambiente de produção.

Para mais informações sobre o desempenho da rede, consulte Desempenho da conexão de rede.

Controles de acesso à rede

É possível implementar controles de acesso à rede em ambos os lados da conexão entre o SAP LT Replication Server e o Google Cloud.

Google Cloud controles de acesso à rede

O BigQuery Connector para SAP se comunica com o BigQuery por um endpoint de API, que não está sujeito às regras de firewall da VPC Google Cloud.

Em vez disso, use o VPC Service Controls para restringir o tráfego.

Para mais informações sobre segurança de rede para o BigQuery, consulte Segurança de rede.

Controles de acesso à rede do host do SAP LT Replication Server

No host do SAP LT Replication Server, é necessário garantir que todos os firewalls ou proxies permitam o tráfego de saída do servidor para os endpoints das APIs BigQuery e Pub/Sub. Especificamente, verifique se o servidor de replicação do SAP LT pode acessar as seguintes APIs Google Cloud :

• https://bigquery.googleapis.com
• https://pubsub.googleapis.com
• https://iamcredentials.googleapis.com

Se você quiser usar endpoints do Private Service Connect para acessar as APIs do BigQuery e do Pub/Sub, configure os endpoints do Private Service Connect na tabela /GOOG/SERVIC_MAP.

Planejamento de desempenho

O desempenho dos carregamentos iniciais e dos jobs de replicação entre o SAP LT Replication Server e o BigQuery é afetado por vários fatores em diferentes pontos ao longo do caminho de replicação.

No entanto, determinados fatores básicos, como a distância entre o SAP LT Replication Server e o conjunto de dados do BigQuery, ou a largura de banda da conexão com o Google Cloud, têm maior impacto no desempenho do que a maioria dos outros fatores.

Práticas recomendadas gerais de desempenho

Para ter o melhor desempenho, incorpore as recomendações a seguir na configuração do servidor de replicação do SAP LT:

• Execute sua carga de trabalho da SAP, incluindo o sistema de origem da SAP e o SAP LT Replication Server, no Google Cloud.
• Se a carga de trabalho da SAP estiver no Google Cloud, crie o conjunto de dados do BigQuery na mesma região que a carga de trabalho da SAP.
• Se não for possível executar sua carga de trabalho da SAP no Google Cloud:
  • Crie seu conjunto de dados do BigQuery na região Google Cloudmais próxima da sua carga de trabalho da SAP.
  • Conecte-se ao Google Cloud usando o Cloud Interconnect.
• Para evitar a contenção de recursos, use hosts dedicados separados para o sistema de origem e o servidor de replicação do SAP LT.
• Dimensione o sistema do SAP LT Replication Server de acordo com sua carga de trabalho de acordo com o Guia de dimensionamento da sua versão do SAP LT Replication Server no portal de ajuda da SAP.
• Use as seguintes configurações de replicação do SAP LT Replication Server:
  • Jobs paralelos.
  • Tipo de leitura 1, se possível. Para mais informações, consulte Desempenho e as configurações avançadas de replicação LTRS.
• Configure o BigQuery Connector para SAP com:
  • Compactação de registro padrão.
  • Tamanho de bloco padrão.
• Ao mapear campos para sua tabela do BigQuery, evite nomes personalizados, se possível.

Veja mais informações em:

• Considerações sobre o desempenho do servidor SAP LT Replication
• Desempenho da conexão de rede
• Transmissão de dados
• Compactação de registro

Características adicionais que podem afetar o desempenho

Muitas características da configuração e dos dados podem afetar o desempenho. Talvez você não consiga modificar algumas destas características. Essas características incluem:

• No servidor de origem:
  • O número de CPUs.
  • A quantidade de memória.
  • O banco de dados usado, como SAP HANA, SAP ASE, IBM Db2 ou outros
  • O número de colunas na tabela de origem.
  • A quantidade de dados que cada registro mantém.
  • Os metadados da tabela, como o comprimento dos nomes de campos.
  • O número de processos de trabalho de caixa de diálogo.
• No servidor de replicação do SAP LT:
  • O número de CPUs.
  • A quantidade de memória.
  • Outras cargas de trabalho que o host pode estar executando.
  • Caixa de diálogo do SAP e processos de trabalho em segundo plano.
  • O tipo de arquitetura de instalação do SAP LT Replication Server. Para mais informações, consulte Instalação autônoma (recomendado) ou incorporada do SAP LT Replication Server.
  • O número de jobs em segundo plano em execução no sistema SAP LT Replication Server.
  • O número de jobs em segundo plano alocados para a transferência em massa na guia Administração da transação LTRC.
  • As configurações de desempenho da transação LTRS, incluindo tipo de leitura e tamanho da porção.
• Na configuração de replicação do BigQuery (transação /GOOG/SLT_SETTINGS):
  • Indica se os nomes personalizados são especificados para os campos de destino. O processamento dos nomes de campos de destino do BigQuery pode ter um pequeno impacto no desempenho.
  • Se a compactação de registros está ativada.
  • Tamanho do bloco, que pode afetar o número total de solicitações HTTP enviadas.

Considerações sobre desempenho do servidor SAP LT Replication

As seções a seguir discutem as opções de desempenho relacionadas à configuração do SAP LT Replication Server.

Desempenho e a arquitetura de instalação do SAP LT Replication Server

Uma arquitetura autônoma, em que o SAP LT Replication Server é instalado em seu próprio servidor dedicado, geralmente proporciona um desempenho melhor do que uma arquitetura incorporada, em que o SAP LT Replication Server está instalado no mesmo servidor que o sistema de origem de dados.

Em uma arquitetura incorporada, o SAP LT Replication Server precisa compartilhar os recursos do servidor com o sistema de origem do SAP.

Mesmo com uma arquitetura autônoma, a CPU e a memória do host, bem como quaisquer outras cargas de trabalho que possam estar em execução no servidor, podem afetar o desempenho de uma instância do SAP LT Replication Server.

Configurações de replicação avançada de desempenho e LTRS

O desempenho dos carregamentos iniciais e da replicação é afetado pelas configurações especificadas na tabela de origem na transação LTRS em Configurações avançadas de replicação.

Para orientação sobre ajuste de desempenho, especialmente para otimizar cargas iniciais ou replicação de alto volume, consulte o Guia de otimização de desempenho do SAP LT Replication Server no Portal de ajuda da SAP de dados.

OGoogle Cloud recomenda as seguintes especificações na seção Configurações avançadas de replicação > Desempenho geral da transação LTRS:

Para carregamentos iniciais da maioria dos tipos de tabela, especifique 1 Range Cálculo como o Read Type. Para tabelas muito grandes para o Cálculo de intervalo 1, especifique Tipo de leitura 5.

Para replicações, em Configurações ativas:

• Para replicações mais rápidas, especifique Intervalos automáticos.
• Para replicações mais confiáveis, especifique Sem intervalos.

A tabela a seguir sugere configurações para alguns cenários comuns.

Tipo de tabela	Tipo de leitura recomendado
Transparente (pequena a média)	Tipo de leitura 1 - Cálculo do intervalo
Transparente (grande)	Somente se o Tipo de leitura 1 não funcionar, o Tipo de leitura 5 - Cálculo do intervalo
Tabela de clusters	Tipo de leitura 4 - Fila do remetente

Desempenho da conexão de rede

A largura de banda e a latência da conexão entre o sistema SAP LT Replication Server e Google Cloud podem afetar o desempenho geral da replicação no BigQuery.

O impacto não afeta apenas a velocidade de replicação, mas a quantidade de recursos consumidos pelo SAP LT Replication Server e pelo sistema de origem, já que quanto mais tempo leva para receber a confirmação da replicação do BigQuery, o SAP LT Replication Server e o sistema de origem mais longos manterão os recursos do host.

Se sua carga de trabalho da SAP estiver sendo executada no local ou em outro provedor de nuvem, Google Cloud recomenda o uso de uma conexão do Cloud Interconnect, que fornece alta largura de banda e baixa latência sem ter que competir com tráfego na Internet pública.

É possível usar o Cloud VPN para se conectar ao Google Cloud e ao BigQuery. No entanto, com uma conexão VPN, suas replicações precisam competir com o tráfego geral da Internet.

Se a carga de trabalho da SAP estiver sendo executada no Google Cloud, Google Cloud recomenda localizar o SAP LT Replication Server e o conjunto de dados do BigQuery na mesma região. Se o SAP LT Replication Server e o BigQuery estiverem em regiões diferentes, a latência normalmente será maior, e o desempenho normalmente será pior. Para mais informações sobre como escolher uma região, consulte Como escolher uma região e zona.

Transmissão de dados

Geralmente, você quer enviar o máximo de dados possível em cada solicitação HTTP, para reduzir o número geral de solicitações HTTP e a sobrecarga de processamento relacionada.

Em alguns casos, no entanto, talvez seja necessário reduzir a quantidade de dados enviados, seja pelo tamanho dos registros em uma tabela específica ou porque você atingiu um limite de cota ou outro limite no Pub/Sub ou no BigQuery.

É possível controlar a quantidade de dados enviados em cada solicitação das seguintes maneiras:

• Ajuste a quantidade de dados (o tamanho da parte) que o SAP LT Replication Server envia para o BigQuery Connector para SAP.
• Ajuste a quantidade de dados (o tamanho do bloco) que o BigQuery Connector para SAP envia ao BigQuery.
• Ajuste as cotas para inserções de streaming no seu projeto do BigQuery.

Como ajustar a quantidade de dados enviados pelo SAP LT Replication Server

O servidor de replicação do SAP LT envia registros do sistema de origem para o BigQuery Connector para SAP em partes. Cada parte é tratada como um job de carga ou replicação separado que consome recursos do servidor até ser concluída.

Geralmente, se você aumentar o tamanho da parte do SAP LT Replication Server, diminuirá o número de processos do SAP LT Replication Server, bem como a sobrecarga associada a eles.

Tamanho da porção e do bloco

As partes do SAP LT Replication Server são dimensionadas em bytes ou como um produto de bytes e registros. O conector do BigQuery para os blocos do SAP é dimensionado pelo número de registros que eles podem conter. O tamanho do byte de um bloco varia de acordo com vários fatores, incluindo o número de campos nos registros e a quantidade de dados que cada registro mantém.

Se o tamanho da parte do SAP LT Replication Server for maior que o tamanho do bloco do BigQuery Connector para SAP, o BigQuery Connector para SAP enviará várias partes para cada parte até que todos os registros da parte sejam enviados.

Se o tamanho da parte for menor que o tamanho da parte, o BigQuery Connector para SAP enviará apenas uma parte por parte. Cada bloco contém apenas o número de registros enviados em cada parte, independentemente do tamanho do bloco definido no BigQuery Connector para SAP.

O ideal é definir um tamanho do sistema no SAP LT Replication Server que permita que o BigQuery Connector para SAP crie os maiores blocos possíveis sem exceder o limite do Pub/Sub ou do BigQuery no número de bytes em cada solicitação HTTP.

Para mais orientações sobre como especificar um tamanho de bloco, consulte Tamanho do bloco no conector do BigQuery para SAP.

Tamanho da porção no SAP LT Replication Server

Para alterar o tamanho de parte padrão usado pelo servidor de replicação SAP LT, execute a transação LTRS e ajuste o valor do campo Tamanho do pacote de Configurações avançadas de replicação em Opções de desempenho.

Para mais informações, consulte o Guia de otimização de desempenho do SAP LT Replication Server no portal de ajuda da SAP.

Tamanho dos fragmentos no conector do BigQuery para SAP

O conector do BigQuery para SAP envia dados ao BigQuery como blocos de registros.

Para a replicação de CDC pelo Pub/Sub, recomendamos que você use o tamanho de bloco padrão com o BigQuery Connector para SAP, que é de 1.000 registros. Esse é o número máximo de registros permitidos pelo Pub/Sub.

Para a replicação de dados de streaming, recomendamos que você use o tamanho de bloco padrão com o BigQuery Connector para SAP, que é de 10.000 registros. No entanto, se os registros em uma tabela de origem contiverem muito poucos campos ou os campos tiverem valores de dados de tamanho muito pequeno, você poderá usar um tamanho de bloco maior até o tamanho máximo permitido pelo BigQuery, que é de 50.000 registros.

Se o número de registros em um determinado bloco for resolvido para um tamanho de byte que excede o limite permitido para o tamanho de byte das solicitações HTTP, você poderá receber um erro quotaExceeded ou invalid.

Isso pode acontecer se os registros em uma tabela de origem contiverem muitos campos ou houver muitos dados.

Se você receber um erro relacionado ao tamanho do bloco, reduza o tamanho do bloco especificado na configuração de transferência em massa para essa tabela. Como alternativa, é possível ativar o tamanho dinâmico do bloco para essa tabela e ajustá-lo automaticamente. Para ver mais informações, consulte Tamanho dinâmico do bloco.

Se você não tiver ativado o tamanho dinâmico do bloco, para tabelas de origem SAP, como MSEG, ACDOCA e MATDOC, que podem ter registros grandes com muitos campos por registro, talvez seja necessário especificar um tamanho de bloco menor.

É possível especificar um tamanho de bloco executando a transação /GOOG/SLT_SETTINGS. O tamanho do bloco é especificado no campo Tamanho do bloco na tela de atributos da tabela.

Para mais orientações sobre como especificar um tamanho de bloco, consulte:

• Para replicação de CDC pelo Pub/Sub, consulte Especificar a criação de tabelas e outros atributos gerais.
• Para replicação de dados de streaming, consulte Especificar a criação de tabelas e outros atributos gerais.

Para mais informações sobre as mensagens de erro do BigQuery, consulte Mensagens de erro.

Processamento da sobrecarga associada ao envio de partes

Cada parte enviada aciona as seguintes ações, cada uma delas gerando sobrecarga de processamento ou consumo de recursos:

1. Uma coleção de registros alterados na tabela de registros no sistema de origem é enviada ao SAP LT Replication Server em uma única parte. Os registros alterados ainda não foram excluídos da tabela de registros.
2. O servidor de replicação do SAP LT solicita um novo token de acesso de Google Cloud.
3. O BigQuery Connector para SAP envia uma solicitação HTTP para Google Cloud para verificar a estrutura da tabela de destino.
4. O BigQuery Connector para SAP envia os registros para Google Cloud em todas as partes necessárias para enviar todos os registros recebidos na parte única. Cada bloco é enviado em uma solicitação HTTP separada.
5. Google Cloud processa cada bloco que recebe.
6. Um código de status HTTP OK é retornado para o SAP LT Replication Server para cada bloco.
7. Depois que Google Cloud recebe todos os registros, o SAP LT Replication Server exclui os registros enviados da tabela de geração de registros, o que finalmente libera recursos no sistema de origem.

Para mais informações sobre partes e como configurar o SAP LT Replication Server para fins de desempenho, consulte o Guia de otimização de desempenho do SAP LT Replication Server no Portal de ajuda da SAP.

Cotas de BigQuery

As cotas da API BigQuery Streaming que estão em vigor para seu projeto limitam a quantidade de dados que você pode transmitir ao BigQuery ao longo do tempo e em qualquer solicitação HTTP.

Por exemplo, o BigQuery define limites em métricas como:

• Os bytes por segundo por projeto que você pode enviar.
• O número máximo de registros ou linhas que podem ser enviados em uma única solicitação HTTP.
• O tamanho máximo de uma solicitação HTTP que pode ser enviada.

Para inserções de streaming, o BigQuery corrige o tamanho das solicitações HTTP para 10 MB e o número de registros que podem ser enviados em uma única solicitação HTTP para 50.000.

Na maioria dos casos, é possível alterar as cotas, mas não os limites.

É possível ver e editar as cotas que estão em vigor para o projeto no console doGoogle Cloud na página Cotas.

Para mais informações sobre as cotas e os limites do BigQuery para inserções de streaming, consulte:

• Cotas e limites
• Inserções de streaming

Cotas do Pub/Sub

As cotas da API Pub/Sub em vigor para seu projeto limitam a quantidade de dados que você pode transmitir para o BigQuery ao longo do tempo e em qualquer solicitação HTTP.

Por exemplo, o Pub/Sub define limites em métricas como:

• Os bytes por segundo por projeto que você pode enviar.
• O número máximo de registros ou linhas que podem ser enviados em uma única solicitação HTTP.
• O tamanho máximo de uma solicitação HTTP que pode ser enviada.

Para dados de CDC, o Pub/Sub corrige o tamanho das solicitações HTTP para 10 MB e o número de registros que podem ser enviados em uma única solicitação HTTP para 1.000.

Na maioria dos casos, é possível alterar as cotas, mas não os limites.

É possível ver e editar as cotas que estão em vigor para o projeto no console doGoogle Cloud na página Cotas.

Para mais informações sobre as cotas e os limites de recursos do Pub/Sub, consulte:

• Cotas e limites
• Limites de recursos

Compactação de registro

Para a replicação de CDC pelo Pub/Sub, o recurso de compactação de registros não é compatível.

Para replicação de dados de streaming, por padrão, o BigQuery Connector para SAP melhora o desempenho da replicação compactando os registros enviados ao BigQuery. A partir da versão 2.8 do BigQuery Connector para SAP, a opção de compactação de registros está disponível no nível da tabela e do campo.

Quando a compactação de registros está ativada no nível da tabela, que é a configuração padrão, BigQuery Connector para SAP omite todos os campos vazios no registro de origem dos registros enviados para o BigQuery. Quando o registro é inserido no BigQuery, os campos que foram omitidos dos dados enviados são inicializados com null na tabela de destino do BigQuery.

No entanto, se você precisar replicar alguns campos vazios com os valores iniciais para o BigQuery e ainda usar a compactação de registros no nível da tabela, mude a configuração de compactação de registros para esses campos específicos. Isso significa que os valores vazios nos campos especificados não são omitidos dos dados enviados e mantêm o valor com que foram inicializados na tabela de origem.

É possível controlar o comportamento da compactação de registros usando a configuração Enviar flag não compactada disponível no nível da tabela e do campo. A tabela a seguir resume o comportamento da compactação de registros:

Enviar flag não compactada no nível da tabela	Enviar flag não compactada no nível do campo	Comportamento de compactação de registros
Sim	Não	Todos os campos são enviados sem compactação.
Sim	Sim	Todos os campos são enviados sem compactação.
Não	Sim	Somente os campos selecionados no nível do campo são enviados sem compactação.
Não	Não	Todos os campos são enviados como compactados.

Quando os dados não compactados são enviados para replicação, exceto para campos de data e carimbo de data/hora, os campos vazios mantêm o valor com que foram inicializados na tabela de origem. Os valores a seguir para data e carimbo de data/hora recebem:

• Valor da inicialização do campo de data: DATE 1970-01-01
• Valor da inicialização do campo de carimbo de data/hora: TIMESTAMP 1970-01-01 00:00:00 UTC

A captura de tela a seguir mostra um exemplo do comportamento da compactação de registros:

• Linha 1: todos os campos estão descompactados. A flag de envio não compactada está selecionada no nível da tabela.
• Linha 2: todos os campos estão compactados. A flag "Send Uncompressed" está limpa no nível da tabela.
• Linha 3: os seguintes campos não estão compactados: int2_value, curr_value_154, currency, float_value e lang_value. Para esses campos, a flag "Enviar sem compactação" é selecionada no nível do campo.

Para melhorar o desempenho, não desative a compactação de registros selecionando Enviar flag não compactada no nível da tabela. Isso pode ter um impacto negativo no desempenho da replicação. Se você precisar enviar dados não compactados apenas para campos específicos, selecione Enviar flag não compactada para esses campos no nível do campo. Para mais informações sobre como a compactação de registros afeta os dados transferidos do servidor de replicação SAP LT para o BigQuery, consulte Noções básicas do recurso de compactação do BigQuery Connector para SAP.

Configurações de replicação do BigQuery

Ao configurar a replicação com o BigQuery Connector para SAP, você usa várias transações SAP diferentes, incluindo uma transação personalizada fornecida por Google Cloud:

• SM30: define propriedades para se conectar ao Google Cloud, armazenadas como um registro na tabela de configuração personalizada /GOOG/CLIENT_KEY. Opcionalmente, quando você usa destinos RFC para se conectar a APIs e serviços doGoogle Cloud , algumas propriedades de conexão são armazenadas na tabela de configuração personalizada /GOOG/SERVIC_MAP.
• LTRC: define o aplicativo de replicação e o ID de transferência em massa do BigQuery Connector para SAP, entre outras propriedades.
• SM59: define destinos RFC que permitem a conexão com APIs e serviços do Google Cloud, como o BigQuery e o IAM.
• /GOOG/SLT_SETTINGS: define as propriedades do conjunto de dados, da tabela e dos campos de destino do BigQuery. Ao inserir /GOOG/SLT_SETTINGS no SAP LT Replication Server, é necessário adicionar /n para escapar a barra inicial no nome da transação.

Suporte ao idioma

O BigQuery Connector para SAP é compatível apenas com configurações de replicação em inglês. Ao configurar a replicação usando as transações SAP e a transação personalizada fornecida por Google Cloud, use inglês como o idioma de login na tela de login da SAP.

No entanto, o BigQuery Connector para SAP é compatível com a execução de jobs em segundo plano executados no SAP LT Replication Server em todos os idiomas aceitos pelo SAP SLT.

Todas as mensagens de erro que podem ser encontradas ao trabalhar com o BigQuery Connector para SAP são geradas em inglês, independentemente do idioma de execução do job em segundo plano.

Propriedades da tabela de destino

Quando você configura a replicação no SAP LT Replication Server executando a transação /GOOG/SLT_SETTINGS, é possível especificar as configurações que se aplicam quando o BigQuery Connector para SAP cria a tabela de destino no BigQuery.

Por exemplo, é possível especificar as seguintes propriedades para uma tabela de destino do BigQuery:

• Nome da tabela
• A opção de nomeação padrão dos campos
• Campos extras para capturar alterações de registros e ativar consultas de contagem de registros
• Particionamento de tabelas

Opções de nomeação padrão dos campos

É possível configurar o BigQuery Connector para SAP para criar os nomes dos campos na tabela de destino do BigQuery a partir dos nomes dos campos de origem ou dos rótulos e descrições dos campos de origem. Os rótulos e descrições geralmente são mais informativos sobre o conteúdo do campo.

Por padrão, o BigQuery Connector para SAP usa os nomes dos campos de origem. É possível alterar o padrão especificando a sinalização de Nomes personalizados ao especificar os atributos de criação da tabela na configuração de transferência em massa da transação /GOOG/SLT_SETTINGS. Essa especificação é armazenada na tabela de configuração /GOOG/BQ_MASTR.

Ao criar os nomes, o BigQuery Connector para SAP os modifica para ficar em conformidade com a convenção de nomenclatura do BigQuery.

Antes de criar uma tabela, é possível editar os nomes dos campos na tela de mapeamento de campos da transação /GOOG/SLT_SETTINGS.

QuandoNomes personalizados é especificado, os nomes que o conector do BigQuery para SAP usará quando criar a tabela de destino serão mostrados naNome do campo externo coluna da tela de mapeamento de campo.

O conector do BigQuery para SAP cria os nomes na coluna Nome do campo externo a partir do rótulo de campo médio de cada campo de origem. Se um rótulo de campo médio não for especificado na definição do campo de origem, a descrição curta do campo será usada. Se a descrição curta não for especificada, o rótulo especificado mais curto será usado. Se nada for especificado, será usado o nome do campo de origem.

Para mais informações sobre como personalizar os nomes dos campos de destino, consulte Como personalizar nomes de campos de destino.

Como capturar alterações de registro e ativar contagens de registros

Para capturar o tipo de alteração na tabela de origem que acionou a replicação e poder consultar contagens de registros na tabela do BigQuery para comparação com o SAP LT Replication Server ou especificar contagens na tabela de origem, especifique a opção Sinalização de campos extras na transação /GOOG/SLT_SETTINGS ao configurar a replicação.

Quando a opção Sinalização de campos extras é especificada, as seguintes colunas são adicionadas ao esquema da tabela de destino do BigQuery:

Nome do campo	Tipo de dado	Descrição
operation_flag	STRING	Identifica o tipo de alteração na tabela de origem que acionou o carregamento ou a replicação do registro no BigQuery. Para contar registros inseridos no modo de replicação, consulte registros com valor I, U ou D no campo operation_flag. Para uma consulta de exemplo, veja Consultar o número de registros inseridos no modo de replicação. Para contar registros inseridos no modo de carregamento inicial, consulte registros que têm um valor de L no campo operation_flag. Para uma consulta de exemplo, veja Consultar a contagem de registros inseridos no modo de carregamento inicial.
is_deleted	BOOLEAN	Quando true, indica que o registro de origem foi excluído da tabela de origem. Para contar apenas os registros em uma tabela do BigQuery que não foram excluídos da tabela de origem, use o campo is_deleted para excluir registros de origem excluídos. Para ver um exemplo de consulta, acesse Consultar a contagem total de registros em uma tabela do BigQuery.
recordstamp	TIMESTAMP	A hora em que o SAP LT Replication Server enviou o registro ao BigQuery. Para contar o número de registros exclusivos em uma tabela do BigQuery, consulte apenas a instância inserida mais recentemente de cada registro. Para ver um exemplo de consulta, acesse Consultar a contagem total de registros em uma tabela do BigQuery.

A configuração atual da opção Sinalização de campos extras é armazenada na tabela de configuração /GOOG/BQ_MASTR.

Para mais informações sobre como especificar a Sinalização de campos extras, consulte:

• Para replicação de CDC pelo Pub/Sub, consulte Especificar a criação de tabelas e outros atributos gerais.
• Para replicação de dados de streaming, consulte Especificar a criação de tabelas e outros atributos gerais.

Particionamento de tabelas

É possível criar tabelas do BigQuery particionadas por um campo de carimbo de data/hora na tabela de origem, que cria uma tabela particionada por coluna de unidade de tempo ou no momento em que os registros são inseridas no BigQuery, o que cria uma tabela particionada por tempo de ingestão.

Ative o particionamento especificando um tipo de partição no campo Tipo de partição no /GOOG/BQ_TABLE ao configurar as propriedades de replicação.

Os tipos de partição que podem ser especificados ajustam a granularidade do particionamento por hora, dia, mês ou ano.

Para usar um carimbo de data/hora da tabela de origem para particionamento da coluna de unidade de tempo, especifique o nome do campo de origem no campo Partition Field.

Para usar um tempo de inserção do BigQuery para particionamento por tempo de ingestão, deixe o Campo da partição em branco. O conector do BigQuery para SAP cria um campo na tabela de destino para armazenar o tempo de inserção.

Propriedades do campo de destino

Por padrão, o BigQuery Connector para SAP usa os nomes de campos e os tipos de dados na tabela de origem SAP como nomes de campos e tipos de dados no BigQuery de destino.

Opcionalmente, antes de a tabela de destino ser criada, é possível personalizar os nomes dos campos ou alterar o tipo de dados do BigQuery.

Como personalizar nomes de campos de destino

Antes de criar uma tabela, é possível personalizar os nomes dos campos de destino.

Se necessário, o BigQuery Connector para SAP modifica os nomes personalizados especificados para conformidade com a convenção de nomenclatura do BigQuery.

Ao configurar a replicação, é possível visualizar os nomes dos campos na tela de mapeamento de campo da transação /GOOG/SLT_SETTINGS. O conector do BigQuery para SAP armazena suas configurações na tabela de configuração /GOOG/BQ_FIELD.

Antes de criar uma tabela, é possível especificar um nome de campo personalizado editando o nome gerado na coluna Nome do campo temporário da tela de mapeamento de campo. Se você excluir um valor e deixar o campo Nome do campo temporário em branco, o conector do BigQuery para SAP usará o nome do campo de origem como o nome desse campo.

Depois de fazer edições no Nome do campo temporário, clique em Salvar. BigQuery Connector para SAP valida o valor, aplica as convenções de nomenclatura do BigQuery conforme necessário e salva as mudanças. É possível validar um valor sem salvá-lo pressionando Enter.

Para informações sobre como definir o método de nomenclatura padrão para os campos de destino, consulte Opções de nomenclatura padrão para campos.

Usar uma planilha ou um arquivo de texto para editar o mapa de campos do BigQuery

Antes de criar uma tabela de destino do BigQuery, é possível salvar os tipos de dados, os nomes e as descrições padrão dos campos de destino em uma planilha ou em um arquivo de texto, para que os administradores ou engenheiros de dados do BigQuery possam editar os valores sem precisar de acesso ao servidor de replicação SAP LT.

Depois que os valores forem editados, você precisará converter o arquivo e o conteúdo dele no formato de valores separados por vírgula (CSV). É possível aplicar as atualizações às configurações de transferência em massa fazendo upload do arquivo CSV usando a transação personalizada /GOOG/SLT_SETTINGS.

Para editar o mapa de campos do BigQuery usando um arquivo CSV, siga estas etapas:

1. Crie uma planilha ou um arquivo de texto para os mapeamentos de campo padrão.
2. Edite os valores.
3. Converta a planilha ou o arquivo de texto no formato CSV.
4. Fazer o upload do arquivo CSV.

Para instruções detalhadas sobre cada uma dessas etapas, consulte Editar o mapa de campos do BigQuery em um arquivo CSV.

Convenção de nomenclatura do BigQuery para campos

A convenção de nomenclatura do BigQuery usa apenas letras minúsculas, números e sublinhados.

O conector do BigQuery para SAP aplica as convenções de nomenclatura do BigQuery a qualquer valor de entrada a ser usado para o nome de um campo de destino.

Por exemplo, se você inserir FIELD-@#!*123 como um nome de campo personalizado, o conector do BigQuery para SAP alterará o nome para field_123.

Para mais informações sobre a convenção de nomenclatura do BigQuery para campos, consulte Nomes de colunas.

Mapeamento de tipo de dados

Por padrão, o BigQuery Connector para SAP atribui tipos de dados aos campos de destino do BigQuery com base no Tipo de dados SAP ou no Tipo de dados SAP da SAP de origem.

Para a replicação de CDC pelo Pub/Sub, o processo envolve uma etapa intermediária no mapeamento de tipos de dados:

1. BigQuery Connector para SAP para Pub/Sub: quando BigQuery Connector para SAP envia dados para um tópico do Pub/Sub, os tipos de dados do SAP são convertidos inicialmente em tipos de dados Avro do Pub/Sub.

2. Pub/Sub para BigQuery: os dados formatados em Avro do Pub/Sub são transmitidos para o BigQuery usando uma assinatura do BigQuery. Neste ponto, o Pub/Sub atribui os tipos de dados finais do BigQuery.

Para garantir um fluxo de dados tranquilo e uma interpretação precisa, os tipos de dados Avro do Pub/Sub e os tipos de dados finais do BigQuery precisam ser compatíveis. Para informações sobre a compatibilidade de esquema entre um tópico do Pub/Sub e uma tabela do BigQuery, consulte Compatibilidade de esquema.

Ao configurar a replicação, é possível visualizar os tipos de dados na tela de mapeamento de campo da transação /GOOG/SLT_SETTINGS. O conector do BigQuery para SAP armazena suas configurações na tabela de configuração /GOOG/BQ_FIELD.

Antes de criar uma tabela, é possível mudar a especificação de tipo de dados padrão para um tipo de dados diferente do BigQuery e do Pub/Sub Avro.

Tipos de dados que exigem tratamento especial

Vários tipos de dados SAP exigem tratamento especial para que sejam representados com precisão na tabela de destino do BigQuery.

Alguns desses tipos de dados precisam ser processados por você. O BigQuery Connector para SAP cuida de outras pessoas para você.

booleanos

Para booleanos, o SAP usa o tipo de dados CHAR, que, por padrão, o conector do BigQuery para SAP mapeia para o tipo de dados STRING na tabela de destino do BigQuery.

Consequentemente, no caso dos booleanos, quando você configura a replicação usando a transação /GOOG/SLT_SETTINGS, é necessário alterar a atribuição de tipo de dados padrão dos campos booleanos de STRING para BOOLEAN na tela de mapeamento de campo.

Timestamps

Para carimbos de data/hora, a SAP usa os tipos de dados P (decimal) ou DEC (decimal), que, por padrão, o BigQuery Connector para SAP mapeia para NUMERIC na tabela de destino do BigQuery de dados.

Consequentemente, no caso dos carimbos de data/hora, quando você configura a replicação usando a transação /GOOG/SLT_SETTINGS, é necessário alterar a atribuição de tipo de dados padrão dos campos de carimbo de data/hora de NUMERIC para TIMESTAMP ou TIMESTAMP (LONG) na tela de mapeamento de campo.

Tipo de tipo SAP X

O tipo de tipo SAP X é um hexadecimal e é representado pelos tipos de dados RAW, RAWSTRING ou LRAW. Por padrão, o BigQuery Connector para SAP mapeia esses tipos de dados para STRING na tabela de origem do BigQuery.

Se você precisar que um campo de origem com o tipo de tipo SAP X seja mapeado para BYTES, em vez disso, será necessário mudar a atribuição de tipo de dados padrão para o campo na tela de mapeamento de campo da transação /GOOG/SLT_SETTINGS.

kinds vezes, o tipo de tipo SAP X também é usado em SAP para representar números inteiros. Nesse caso, o BigQuery Connector para SAP verifica o tipo de dados do campo de origem de um dos tipos de dados SAP para números inteiros, INT1, INT2, INT4, INT8 e atribui o tipo de dados INTEGER na tabela de destino do BigQuery.

Tipo de tipo SAP y

O tipo de tipo SAP y é uma string de bytes e é representado pelos tipos de dados RAW, RAWSTRING ou LRAW. Por padrão, o BigQuery Connector para SAP mapeia esses tipos de dados para STRING na tabela de origem do BigQuery.

Se você precisar que um campo de origem com o tipo de tipo SAP y seja mapeado para BYTES, em vez disso, será necessário mudar a atribuição de tipo de dados padrão para o campo na tela de mapeamento de campo da transação /GOOG/SLT_SETTINGS.

Tipo de dados do SAP LRAW

O BigQuery Connector para SAP armazena tipos de dados LRAW no BigQuery como strings codificadas em Base64.

Se você estiver usando a replicação de CDC pelo Pub/Sub, o conector converterá campos LRAW em codificação UTF-8 antes de enviá-los ao Pub/Sub. Apesar dessa conversão, o conector ainda armazena os dados como Base64 no BigQuery.

A conversão UTF-8 de um valor de campo LRAW feita pelo conector considera apenas os bytes iniciais indicados pela coluna de comprimento anterior. Isso segue os padrões da SAP, em que o campo de comprimento anterior (um tipo INT2 ou INT4) define o comprimento válido do conteúdo LRAW.

Mapeamento de tipo de dados padrão

Veja na tabela a seguir a conversão de tipo de dados padrão do conector do BigQuery para SAP:

Tipo de SAP	Tipo de dados do SAP	Tipo de dados do BigQuery	Tipo de dados Avro do Pub/Sub	Observações
b (número inteiro de 1 byte) s (número inteiro de 2 bytes) I (número inteiro de 4 bytes) 8 (inteiro de 8 bytes)	INT1 INT2 INT4 INT8	INTEGER	INT
F (float)	FLTP	FLOAT	FLOAT
P (embalado)	CURR DEC QUAN	NUMERIC	DOUBLE	Por padrão, o tipo de tipo SAP P é mapeado para o tipo de dados do BigQuery NUMERIC e convertido em um número no formato externo.
a (número flutuante decimal, 16 casas)	DECFLOAT16	NUMERIC	DOUBLE
e (número flutuante decimal, 16 casas)	DECFLOAT34	NUMERIC	DOUBLE
N (numérico)	NUMC	STRING	STRING
X (hexadecimal) y (string de bytes)	RAW RAWSTRING LRAW	STRING	STRING	Se o tipo de tipo SAP é X, mas o nome do tipo de dados abrange o padrão 'INT*' (INT1, INT2, INT4), um elemento de dados de origem é substituído por um novo elemento de dados TYPINT8 com TYPEKIND '8', que é mapeado para o tipo de dados do BigQuery INTEGER.
C (caractere) g (string de caracteres) ? (csequência) & (semelhante)	CHARSTRING	STRING	STRING
D (data)	DATS	DATE	STRING
T (período)	TIMS	TIME	STRING

Licenciamento

O BigQuery Connector para SAP é disponibilizado como "Software" no contrato que rege o uso da Google Cloud Plataforma, incluindo os Termos Específicos do Serviço, disponíveis em https://cloud.google.com/terms/service-terms. Sem limitar a generalidade dos termos acima, não é possível modificar ou distribuir o BigQuery Connector para SAP sem permissão expressa por escrito do Google.

Atualmente, o software BigQuery Connector para SAP é gratuito. Para maior clareza, o uso de outros "Softwares" e "Serviços" nos termos do contrato que rege o uso da plataforma Google Cloud , como BigQuery, Pub/Sub, API Pub/Sub, API Storage Write e API de streaming do BigQuery, pode ser cobrado.

BigQuery Connector para SAP não inclui nenhuma licença do software SAP, incluindo, sem limitação, o SAP LT Replication Server; compre uma licença apropriada para o software SAP.

Ciclo de vida do suporte

OGoogle Cloud oferece suporte e mantém a versão principal mais recente do BigQuery Connector para SAP por pelo menos 12 meses após a publicação de um aviso de descontinuação na página de notas da versão do SAP no Google Cloud com relação à versão principal anterior.

A seguir

Para informações sobre como instalar o BigQuery Connector para SAP, consulte Instalar o BigQuery Connector para SAP.