Práticas recomendadas para cargas de trabalho de vários locatários no BigQuery

Neste documento, apresentamos técnicas e práticas recomendadas para padrões comuns usados em plataformas de dados de vários locatários e data marts empresariais.

Empresas comerciais, fornecedores de software como serviço (SaaS, na sigla em inglês) e organizações governamentais geralmente hospedam com segurança dados internos e de terceiros em limites geográficos e administrativos. O BigQuery é uma ferramenta avançada que atende regularmente aos requisitos de plataforma de vários locatários para exabytes de dados e centenas de milhares de consumidores de dados em unidades de negócios distintas. Este documento é destinado a organizações que implantam plataformas de vários locatários no BigQuery e querem entender os controles de acesso disponíveis e os recursos de gerenciamento de desempenho.

Os criadores de plataformas de vários locatários geralmente precisam equilibrar as seguintes considerações:

• Isolamento de dados: implemente controles fortes para evitar o vazamento de dados entre locatários.
• Desempenho consistente: configure e distribua as reservas do BigQuery para manter o desempenho consistente entre os locatários.
• Gerenciamento de recursos: planeje o impacto das cotas e limites.
• Distribuição geográfica: localize dados em localizações geográficas designadas e necessárias. Para preocupações relacionadas à conformidade, consulte as ofertas de conformidade do Google Cloud.
• Auditoria e segurança: proteja os dados do locatário contra acesso inapropriado e exfiltração.
• Gerenciamento de custos: garanta custos consistentes do BigQuery para hospedar cada locatário.
• Complexidade operacional: minimize a quantidade de variabilidade do sistema necessária para hospedar novos locatários.

Fornecedor de SaaS com infraestrutura compartilhada de locatário

Os fornecedores de SaaS que hospedam dados de terceiros precisam garantir a confiabilidade e o isolamento de toda a frota de clientes. Esses clientes podem chegar a dezenas de milhares, e os dados deles podem ser acessados em uma infraestrutura compartilhada de serviços. Alguns fornecedores de SaaS também mantêm um armazenamento de dados central limpo para fazer análises em toda a frota de locatários.

O design de conjunto de dados por locatário ajuda a reduzir as seguintes preocupações de uma organização quando ela escalona para milhares de locatários:

• Complexidade administrativa: o número total de novos projetos e recursos da nuvem por cliente
• Latência de ponta a ponta: última atualização dos locatários e das soluções de análise de vários clientes
• Expectativas de desempenho: garantir que o desempenho do locatário permaneça dentro dos limites aceitáveis.

Configurar conjuntos de dados para cada locatário

Dentro de um projeto dedicado a armazenar dados de clientes, os dados de cada cliente são separados por conjuntos de dados do BigQuery. Dentro da organização host, você usa um segundo projeto para implantar análises e aprendizado de máquina em dados combinados do cliente. Em seguida, é possível configurar o mecanismo de processamento de dados, o Dataflow, para gravar duas vezes os dados de entrada nas tabelas internas e específicas de locatários. A configuração do Dataflow usa tabelas totalmente gravadas, em vez de visualizações autorizadas. O uso de tabelas totalmente gravadas permite o gerenciamento uniforme da distribuição geográfica e ajuda a evitar chegar aos limites de visualização autorizados quando o número de locatários é escalonado.

A separação de armazenamento e computação do BigQuery permite que você configure menos projetos em comparação com armazenamentos baseados em cluster para lidar com problemas como níveis de serviço e isolamento de dados. Quando você não precisa configurar locatários com recursos adicionais de nuvem dedicada, recomendamos considerar a configuração padrão de um conjunto de dados dedicado para cada locatário. O diagrama abaixo mostra um exemplo de configuração de projeto com base nesse design recomendado:

Figura 1. Um número constante de projetos lida com as necessidades de dados e processamento à medida que o número de locatários aumenta.

A configuração do projeto na figura 1 inclui os seguintes projetos:

• Projeto de pipeline de dados: os principais componentes da infraestrutura que recebem, processam e distribuem dados de locatários são empacotados em um único projeto.
• Projeto combinado de dados do locatário: o projeto de dados principal que mantém um conjunto de dados por cliente. Os dados de locatário devem ser acessados pelos projetos de nível de computação.
• Projetos internos de desenvolvimento: projetos que representam os recursos autogerenciados que as equipes de análise usam para avaliar dados de locatários e criar novos recursos.
• Projetos de aplicativos de usuários finais: projetos que contêm recursos projetados para interagir com os usuários finais. Recomendamos usar contas de serviço com escopo de locatário para acessar conjuntos de dados de locatário e um pipeline de criação robusto e seguro para implantar aplicativos.
• Projetos de reserva de nível de computação: projetos que mapeiam a atividade de consulta do locatário para as reservas do BigQuery.

Compartilhar reservas

As reservas nessa abordagem dependem do algoritmo de programação equitativa que é incorporado às reservas do BigQuery. Cada reserva de nível de computação é atribuída a um único projeto. As consultas de locatário usam slots de programação equitativa disponíveis para cada projeto do nível de computação. Os slots não utilizados de qualquer nível são automaticamente reutilizados em outro nível. Se um locatário tiver requisitos de tempo específicos, será possível usar um par de reserva de projeto dedicado a fornecer um número exato de slots.

Configurar perímetros do VPC Service Controls

Nesta configuração, recomendamos perímetros do VPC Service Controls para impedir que conjuntos de dados de locatário sejam expostos acidentalmente fora da sua organização do Google Cloud e evitar a junção de dados não autorizados na organização.

Perímetros

Nessa configuração, recomendamos que você crie os seguintes perímetros de serviço:

• Pipeline de dados: um perímetro nos projetos de pipeline de dados deve impor todos os serviços que não precisam receber dados de locatário.
• Dados de locatário: um perímetro em torno do projeto do conjunto de dados de locatário e em torno dos projetos de computação do BigQuery de locatário. Aplique todos os serviços para impedir o acesso de fora da organização.
• Aplicativos internos: aplique todos os serviços e use níveis de acesso para conceder acesso a recursos às equipes do departamento.
• Aplicativos externos: um perímetro em torno dos seus aplicativos de SaaS. Aplique todos os serviços que não são necessários para o funcionamento dos aplicativos.

Pontes do perímetro

Nessa configuração, recomendamos que você crie estes pontes do perímetro:

• Pipeline de dados e dados de locatário: permitem que o pipeline grave dados em conjuntos de dados de locatário.
• Pipeline de dados e aplicativos internos: permitem que o pipeline grave dados no conjunto de dados entre clientes.
• Aplicativos externos e dados de locatários: permitem que os aplicativos externos consultem dados de locatários.
• Aplicativos externos e aplicativos internos: permitem que aplicativos externos processem dados usando modelos que os aplicativos internos desenvolvem e implantam.

Fornecedor de SaaS com infraestrutura dedicada de locatário

Em cenários mais complexos, os fornecedores de SaaS podem implantar uma infraestrutura de computação dedicada para cada locatário. Nesse cenário, a infraestrutura dedicada é responsável por atender às solicitações de dados de locatário no BigQuery.

Um design de infraestrutura dedicada de locatário aborda as seguintes preocupações comuns ao implantar uma infraestrutura para cada locatário com o BigQuery:

• Responsabilidade de faturamento: rastrear custos de infraestrutura associados a cada locatário integrado.
• Latência de ponta a ponta: última atualização do banco de dados para os locatários e para as soluções de análise de vários clientes
• Expectativas de desempenho: garantir que o desempenho do locatário permaneça dentro dos limites aceitáveis.

Colocar conjuntos de dados com recursos dedicados

Ao implantar a infraestrutura dedicada de locatário, recomendamos que você crie uma pasta principal para os projetos específicos do locatário. Em seguida, coloque os conjuntos de dados do BigQuery do locatário em projetos com os recursos dedicados que acessam esses dados em nome do locatário. Para minimizar a latência de ponta a ponta para dados de locatário, os pipelines do Dataflow inserem dados diretamente nos conjuntos de dados de locatário.

Esse design lida com a distribuição e o processamento de dados upstream, semelhantes ao design da infraestrutura compartilhada anterior. No entanto, os dados de locatário e aplicativos que acessam dados de locatário são organizados em projetos específicos de locatários (e, opcionalmente, organizados em pastas dedicadas ao locatário) para simplificar o gerenciamento de faturamento e recursos. O diagrama abaixo mostra um exemplo de configuração de projeto com base nesse design recomendado:

Figura 2. Projeto de pipelines de dados processando dados de um único locatário a partir de vários outros projetos.

A configuração do projeto na figura 2 inclui os seguintes projetos:

• Projeto de pipelines de dados: os principais componentes da infraestrutura que recebem, processam e distribuem dados de locatário são empacotados em um único projeto.
• Projetos dedicados de locatário: projetos que contêm todos os recursos da nuvem dedicados a um único locatário, incluindo conjuntos de dados do BigQuery. Recomendamos que você use o Identity and Access Management (IAM) para limitar o escopo de quais contas e contas de serviço podem acessar os conjuntos de dados do cliente.
• Projetos de análise internos: projetos que representam os recursos autogerenciados que as equipes de análise usam para avaliar dados de locatários e criar novos recursos.
• Projeto de rede externa: projeto que processa e encaminha solicitações de locatário para os back-ends dedicados.

Compartilhar reservas

As reservas nesta abordagem dependem do algoritmo de programação equitativa que é incorporado às reservas do BigQuery. Nesta configuração, as reservas de nível de computação são atribuídas a cada projeto de locatário que usa esse nível. Se um locatário tiver requisitos específicos de tempo, será possível criar uma reserva dedicada para fornecer um número exato de slots a um projeto de locatário.

Usar controles do IAM e desativar a criação de chaves

Os perímetros do VPC Service Controls podem não ser apropriados para esse cenário. Os limites relacionados ao projeto impedem que uma organização use limites de perímetro em projetos que interagem com os projetos de locatário. Em vez disso, recomendamos que você use controles rígidos do IAM e desative a criação de chaves para ajudar a proteger contra acesso externo indesejado.

Data mart com autoridade central

Os data marts são um tema de design comum em que os principais dados de análise são armazenados em um repositório central e os subconjuntos são compartilhados nas linhas de negócios. Os data marts costumam ter dezenas ou centenas de locatários, representados como linhas de negócios a serem consideradas.

Um design de data mart no BigQuery atende às seguintes necessidades:

• Colaboração de dados segura: compartilhamento de dados com controles técnicos para minimizar o acesso inadequado entre equipes.
• Governança central de dados: garantia de que os principais recursos de dados usados para relatórios empresariais críticos sejam padronizados e validados.
• Atribuição de custos de unidades de negócios: rastreamento e ajuste do uso de computação por unidades de negócios.

Usar um repositório administrado centralmente

Nesse design, os dados principais são capturados em um repositório administrado de maneira centralizada. As visualizações autorizadas, as funções definidas pelo usuário (UDFs, na sigla em inglês), também autorizadas, e as políticas de coluna são usadas com frequência para compartilhar dados com linhas de negócios e, ao mesmo tempo, evitar a distribuição acidental de dados confidenciais.

As equipes em projetos de locatário podem acessar conjuntos de dados controlados de maneira centralizada com base nas permissões da conta. As equipes usam slots alocados para os próprios projetos para criar relatórios e conjuntos de dados derivados. A equipe de dados principais usa visualizações autorizadas para manter a propriedade total do controle de acesso aos recursos do data mar. Nessa configuração, recomendamos que você evite criar várias camadas de visualizações sobre os objetos que o projeto de dados principais apresenta. O diagrama abaixo mostra um exemplo de configuração de projeto com base nesse design recomendado:

Figura 3. Um projeto de dados principais mantém um data mar centralizado acessível em toda a organização.

A configuração do projeto na figura 3 inclui os seguintes projetos:

• Projeto de dados principais: o perímetro de governança para gerenciar o acesso a dados principais e às visualizações de data mart. Você mantém visualizações autorizadas nos conjuntos de dados dentro deste projeto e concede visualizações autorizadas às suas equipes de análise com base na associação ao grupo.
• Infraestrutura de extração, transformação e carregamento (ETL, na sigla em inglês): infraestrutura para processar origens de dados upstream nos dados principais. Dependendo das necessidades de separação administrativa, é possível implantar a infraestrutura de ETL como projeto próprio ou como parte do projeto de dados principais.
• Projetos de equipe de análise: os consumidores do data mar usam esses projetos e o próprio acesso provisionado de infraestrutura para processar dados no data mar. Os projetos da equipe de análise podem criar conjuntos de dados derivados para uso local.

Usar um design de reserva de dois níveis

Ao trabalhar com data marts, recomendamos o uso de um design de dois níveis. Em um design de dois níveis, você atribui ao recurso da organização uma reserva com poucos slots para abranger o uso geral. Se as equipes tiverem maiores necessidades, atribua reservas no nível do projeto ou da pasta.

Configurar perímetros do VPC Service Controls

Nessa configuração, recomendamos os perímetros do VPC Service Controls para impedir que conjuntos de dados do BigQuery sejam expostos acidentalmente fora da sua organização do Google Cloud.

Perímetros

Nessa configuração, recomendamos que você crie os seguintes perímetros de serviço:

• Dados principais: um perímetro para proteger o armazenamento de dados e os conjuntos de dados de data mart.
• Pipelines de dados: um perímetro para o projeto de infraestrutura ETL. Se os pipelines de dados precisarem fazer solicitações fora da organização do Google Cloud, recomendamos que você separe esse perímetro do perímetro de dados principais.
• Análises: um perímetro para criar e implantar recursos de análise internos da sua organização. Espera-se que esse perímetro tenha uma política de acesso mais abrangente do que o perímetro de dados principais com que é vinculado.

Pontes do perímetro

Nessa configuração, recomendamos que você crie as seguintes pontes do perímetro:

• Pipelines de dados e dados principais: permitem que os pipelines de dados gravem no projeto de dados principais.
• Dados principais e análises: permitem que os usuários nos projetos de análise consultem as visualizações autorizadas.

Copiar conjuntos de dados para configurações multirregionais

Como o BigQuery não permite consultas entre regiões, não é possível usar a estratégia de segmentação de dados com visualizações autorizadas quando os data marts precisam existir em várias regiões. Em vez disso, você pode usar o serviço de transferência de dados do BigQuery para copiar conjuntos de dados relevantes para outra região. Neste cenário, você cria políticas de coluna no catálogo de dados para cada região adicional em que os dados estão. O diagrama a seguir mostra uma configuração multirregional:

Figura 4 Uma configuração multirregional usa o serviço de transferência de dados do BigQuery para copiar conjuntos de dados entre regiões.

A configuração do projeto na figura 4 inclui os seguintes projetos.

• Projeto de dados principais: o perímetro de governança para gerenciar o acesso a dados principais e às visualizações de data mart. Os dados são copiados e mantidos em conjuntos de dados regionais que podem atender a equipes de todo o mundo.
• Infraestrutura de ETL: infraestrutura para processar origens de dados upstream nos dados principais. Dependendo das necessidades de separação administrativa, é possível implantar a infraestrutura de ETL como projeto próprio ou como parte do projeto de dados principais.
• Projetos de equipe de análises: os consumidores do data mart usam esses projetos e a própria infraestrutura provisionada para processar dados em conjuntos de dados regionais do data mart. Os projetos da equipe de análises precisam criar conjuntos de dados derivados para uso local.

O serviço de transferência de dados do BigQuery é um componente programado adicional com algumas limitações. O programador de serviços integrado é limitado a um intervalo mínimo de 15 minutos e precisa copiar todas as tabelas do conjunto de dados de origem. Não há como incorporar scripts adicionais para criar subconjuntos de dados específicos da região no programador do serviço de transferência de dados do BigQuery.

Se sua organização precisar de mais flexibilidade, estas opções estarão disponíveis:

• Jobs do Cloud Composer: programe jobs do Cloud Composer para emitir jobs ETL que criem subconjuntos regionais antes de acionar o serviço de transferência de dados do BigQuery pela API do cliente. Se sua organização for compatível com latência adicional, recomendamos essa opção.
• Infraestrutura de ETL: infraestrutura ETL, como o Dataflow, pode gravar subconjuntos regionais em regiões de destino duas vezes. Se sua organização precisar de latência mínima de dados entre as regiões, recomendamos essa opção.

Data marts com autoridade descentralizada

Use a autoridade descentralizada quando precisar da separação administrativa por proprietário do sistema, linhas de negócios ou preocupações geográficas.

Um data mart descentralizado apresenta as seguintes preocupações em comparação com um data mart padrão:

• Colaboração de dados segura: compartilhamento de dados com controles técnicos para minimizar o acesso inadequado entre equipes.
• Detecção de dados: as equipes precisam descobrir e solicitar acesso a conjuntos de dados.
• Procedência de dados: sem uma equipe de curadoria central, as equipes precisam ser capazes de confiar na origem dos dados que entram nos produtos de análise.

Delegar a administração de dados principais

Esse design é diferente da abordagem convencional de data mart, porque a autoridade descentralizada delega as decisões de administração de dados principais a subgrupos de componentes da organização. Ao usar a autoridade descentralizada, você mantém o controle central da segurança e da capacidade do BigQuery usando o Cloud Key Management Service (Cloud KMS), as políticas de coluna, o VPC Service Controls e as reservas. Portanto, evite a expansão de dados que é comum com armazenamentos autogerenciados. O diagrama abaixo mostra uma arquitetura que usa autoridade descentralizada:

Figura 5. Um projeto de governança principal ajuda a garantir a segurança consistente, enquanto os grupos individuais mantêm suas operações de dados.

A configuração do projeto na figura 5 inclui os seguintes projetos:

• Projeto de governança principal: o projeto responsável pelas preocupações de gerenciamento de várias organizações. Neste projeto, você cria recursos de segurança, como keyrings do Cloud KMS e políticas de coluna do catálogo de dados. Este projeto atua como o projeto de administração de reservas do BigQuery, permitindo o compartilhamento de slots para toda a organização.
• Projetos de dados de unidade organizacional: os proprietários de data marts autogerenciados em toda a organização. O projeto principal de governança gerencia o escopo restrito dos projetos de dados da unidade organizacional.
• Projetos de equipe de análise: projetos usados pelos consumidores dos data marts. Esses projetos usam a própria infraestrutura provisionada e os slots para acessar e processar dados dentro do data mar.

Usar um design de reserva de dois níveis

Recomendamos que os data marts descentralizados usem o mesmo design de dois níveis que os data marts padrão. Nesta configuração, você atribui ao recurso da organização uma reserva com poucos slots para abranger o uso geral. Se as equipes tiverem maiores necessidades, atribua reservas no nível do projeto ou da pasta.

Usar um catálogo de dados

Um catálogo de dados fornece descoberta em toda a organização, inclusão de tag de metadados e configuração de políticas de coluna. A descoberta do Dataplex cria automaticamente entradas de metadados para todas as novas tabelas do BigQuery na sua organização. As capabilities do Dataplex também ajudam os administradores de governança de dados a identificar rapidamente novos recursos de dados e aplicar os controles adequados.

Configurar perímetros do VPC Service Controls

Nessa configuração, recomendamos os perímetros do VPC Service Controls para impedir que conjuntos de dados do BigQuery sejam expostos acidentalmente fora da sua organização do Google Cloud.

Perímetros

Nessa configuração, recomendamos que você crie os seguintes perímetros de serviço:

• Dados principais: um perímetro para proteger o armazenamento de dados e os conjuntos de dados de data mart. Esse perímetro precisa incluir todos os projetos da unidade organizacional e o projeto de governança de dados.
• Análise: um perímetro para criar e implantar recursos de análise internos na organização. Espera-se que esse perímetro tenha uma política de acesso mais abrangente do que o perímetro de dados principais com que ele é vinculado.

Pontes do perímetro

Nessa configuração, recomendamos que você crie as seguintes pontes do perímetro:

• Dados principais e análises: permitem que os usuários nos projetos de análise consultem as visualizações autorizadas.

Compartilhamento de dados entre várias organizações

O compartilhamento entre várias organizações é uma consideração especial de design em um design de data mart. Esse design de compartilhamento de dados é para organizações que querem compartilhar com segurança seus conjuntos de dados com outra entidade que tenha sua própria organização do Google.

O compartilhamento de dados entre várias organizações abrange as seguintes questões para quem compartilha dados:

• Compartilhamento de confidencialidade: somente a parte pretendida pode acessar dados compartilhados.
• Proteção contra acesso inadequado: somente os recursos que precisam ser acessados externamente podem ser acessados externamente.
• Separação de computação: partes externas são cobradas para consultas que elas iniciam.

Observação: em alguns casos, as consultas originadas em organizações externas podem falhar de forma inesperada. O Cloud Customer Care pode ajudar você a iniciar uma alteração de configuração para corrigir o problema.

Proteger projetos internos contra projetos de dados compartilhados

O design de compartilhamento de dados de várias organizações foca na proteção dos projetos internos da organização contra atividades em projetos de dados compartilhados. O projeto do conjunto de dados compartilhado atua como um buffer para impedir o acesso a processamento interno de dados confidenciais e, ao mesmo tempo, fornecer a capacidade de compartilhar dados externamente.

As consultas iniciadas a partir do projeto externo usam os recursos de computação do projeto de invocação. Se todos os conjuntos de dados consultados compartilharem a mesma região do Google Cloud, essas consultas poderão mesclar dados entre organizações. O diagrama abaixo mostra como os conjuntos de dados são compartilhados em uma configuração de projeto de várias organizações:

Figura 6. Uma organização externa consulta dados de vários conjuntos de dados em projetos compartilhados.

A configuração do projeto na figura 6 inclui os seguintes projetos:

• Projeto interno da organização: o projeto que contém dados internos confidenciais. O projeto interno pode compartilhar dados externamente copiando dados limpos nos conjuntos de dados do projeto de dados compartilhados. O projeto interno precisa ser o proprietário da conta de serviço responsável por atualizar os dados compartilhados.
• Projeto de dados compartilhados: o projeto que contém as informações limpas copiadas a partir do projeto interno. Use grupos de usuários externos para gerenciar o acesso de terceiros. Nesse cenário, você gerencia a associação ao grupo como uma função administrativa e concede permissão para visualização às contas externas para que elas possam acessar o conjunto de dados nesses grupos.

Configurar perímetros do VPC Service Controls

Nessa configuração, recomendamos os perímetros do VPC Service Controls para compartilhar dados externamente e evitar que os conjuntos de dados do BigQuery sejam expostos acidentalmente fora dos seus projetos internos.

Perímetros

Nessa configuração, recomendamos que você crie os seguintes perímetros de serviço:

• Dados internos: um perímetro para proteger recursos de dados principais. O VPC Service Controls aplica acesso ao BigQuery.
• Dados compartilhados externamente: um perímetro para hospedar conjuntos de dados que podem ser compartilhados com organizações externas. Esse perímetro desativa a aplicação de acesso ao BigQuery.

Pontes do perímetro

Nesta configuração, recomendamos que você crie a seguinte ponte do perímetro:

• Dados internos para externos: uma ponte do perímetro permite que os projetos de dados internos mais protegidos transmitam dados para projetos de compartilhamento de dados externos.

Outras considerações sobre sistemas de vários locatários

Nesta seção, apresentamos mais detalhes sobre casos especiais que você pode considerar junto com as práticas recomendadas anteriores.

Cotas e limites de recursos do Google Cloud

• As contas de serviço são limitadas a uma cota flexível de 100 contas de serviço por projeto. É possível solicitar cotas pelo Console do Google Cloud para projetos que mantêm contas de serviço de locatários.
• A simultaneidade do BigQuery tem uma simultaneidade padrão de 100 consultas por projeto que emite consultas (projetos que mantêm conjuntos de dados não têm esses limites). Para aumentar essa cota, entre em contato com seu representante de vendas.
• O VPC Service Controls tem um limite de 10.000 projetos em perímetros de serviços em toda a organização. Se seus designs de projeto por locatário tiverem alta escala, recomendamos usar um design de conjunto de dados por locatário.
• O VPC Service Controls tem um limite de 100 perímetros, incluindo pontes, por organização.

Como usar visualizações autorizadas ou tabelas de subconjunto materializadas

Para gerenciar o acesso de locatário a subconjuntos de tabelas de fatos, é possível usar visualizações autorizadas específicas de locatário ou criar tabelas de subconjuntos específicas de locatário. Na tabela a seguir, você vê uma comparação dessas abordagens:

Recurso	Visualizações autorizadas	Tabelas de subconjuntos
Número de locatários compatíveis	Há um limite absoluto de 2.500 recursos autorizados por conjunto de dados.	Os recursos autorizados incluem visualizações autorizadas, conjuntos de dados autorizados e funções autorizadas. Não há limites para o número de conjuntos de dados em um projeto ou de tabelas em um conjunto de dados.
Particionamento e agrupamento em cluster	As visualizações autorizadas precisam compartilhar o esquema de particionamento e cluster comum da tabela base. Para melhorar o desempenho da segmentação de locatário, recomendamos que você agrupe a tabela pai no ID do locatário.	É possível particionar a tabela do subconjunto e agrupá-la conforme as necessidades do locatário.
Regionalização	As visualizações autorizadas não podem cruzar regiões e precisam estar na região do Google Cloud da tabela base. A regionalização afeta locatários geograficamente remotos.	As tabelas de subconjunto podem existir na região mais apropriada para o locatário. Sujeitas a custos adicionais.
Aplicação da política de coluna	As políticas de coluna aplicadas a uma tabela base são aplicadas a todas as visualizações autorizadas, independentemente das permissões contidas nelas.	Cada tabela de subconjunto precisa aplicar a política de coluna para que ela entre em vigor.
Geração de registros de acesso a dados	Os registros de acesso a dados são refletidos no registro da tabela base.	O acesso a cada tabela de subconjunto é registrado separadamente.
Flexibilidade de transformação	As visualizações autorizadas permitem a reformulação instantânea do objeto que os locatários estão acessando.	Alterações de esquema complexas são necessárias para alterar as tabelas de subconjuntos.

Como controlar dados confidenciais

Para impedir o acesso não autorizado aos dados, o BigQuery oferece vários recursos adicionais além das permissões padrão do IAM.

Criptografia fornecida pelo cliente

A criptografia de dados do cliente abrange casos em que uma organização de hospedagem armazena e processa dados em nome de um locatário, mas é impedida de acessar alguns dos conteúdos dos dados. Por exemplo, a organização de hospedagem pode ser impedida de acessar dados pessoais ou do dispositivo que são considerados confidenciais.

Recomendamos que o remetente de dados use chaves de criptografia AEAD, da biblioteca do Tink de código aberto, para criptografar dados confidenciais. As chaves de criptografia AEAD da biblioteca do Tink são compatíveis com as funções AEAD do BigQuery. O locatário pode descriptografar os dados acessando o material da chave em uma UDF autorizada ou transmitindo o material da chave como um parâmetro de consulta para o BigQuery, em que a organização do host não pode registrar a chave.

Políticas de acesso à coluna

Em data marts de vários locatários, as políticas de coluna são frequentemente usadas para evitar que conteúdo confidencial vaze acidentalmente entre equipes colaborativas. As visualizações autorizadas são o mecanismo preferido para compartilhar dados entre equipes em um cenário de data mart. Visualizações autorizadas não podem conceder acesso a uma coluna protegida.

Ao definir a política para aplicar o controle de acesso, você impede o acesso a usuários que não receberam o papel de leitor refinado à política. Mesmo quando a política não é aplicada, ela registra todo o acesso do usuário à coluna categorizada.

Proteção de dados sensíveis

A Proteção de dados confidenciais oferece APIs e utilitários de verificação que ajudam a identificar e reduzir conteúdos confidenciais armazenados nos conjuntos de dados do BigQuery ou do Cloud Storage. As organizações em cenários de vários locatários frequentemente usam a API DLP, que faz parte da proteção de dados confidenciais, para identificar e, opcionalmente, tokenizar os dados confidenciais antes que eles sejam armazenados.

Gerenciamento de reservas de slots

O gerenciamento de reservas em sistemas de vários locatários ajuda a controlar os custos à medida que os locatários escalonam e assegura garantias de desempenho para cada locatário.

Para gerenciar reservas, recomendamos que você crie um único projeto administrativo de reserva. Os compromissos de slot que são comprados no mesmo projeto administrativo podem ser compartilhados em todas as reservas originadas do projeto administrativo. Um projeto que usa compromissos de slot só pode ser atribuído a uma reserva por vez. Todas as consultas que originam de um projeto compartilham slots com base nos recursos disponíveis.

Para garantir que os objetivos de nível de serviço (SLOs, na sigla em inglês) do locatário sejam atendidos, é possível monitorar as reservas pelo Cloud Logging e pelo esquema de informações do BigQuery. As organizações que passam por períodos movimentados de atividades de análise ou jobs prioritários podem alocar capacidade extra usando slots flexíveis.

Reservas como níveis de computação de locatário

Os fornecedores de SaaS que têm dezenas de milhares de locatários normalmente configuram um número finito de reservas do BigQuery como recursos compartilhados.

Se você for um fornecedor de SaaS que tem uma infraestrutura compartilhada de locatário, recomendamos dedicar cada reserva a um único projeto e locatários de grupo para compartilhar esse projeto para computação do BigQuery. Esse design reduz a sobrecarga administrativa de ter milhares de projetos e reservas adicionais e permite que sua organização aloque uma capacidade de slot mínima necessária para atender às necessidades previstas de desempenho para a reserva.

Se os cronogramas de processamento de dados de ELT forem uma prioridade, recomendamos que você aloque uma reserva para lidar com o processamento. Para evitar o uso de slots extras que podem ser usados em cargas de trabalho ad-hoc, defina a reserva para ignorar slots inativos.

Veja a seguir um exemplo de como configurar reservas como níveis de computação de locatário:

• Processamento de dados: 2.000 slots. Ignorar os inativos. Essa reserva está configurada para atender a SLOs de processamento de dados.
• Projetos internos: 1.000 slots. Permitir os inativos. Essa reserva é aplicada aos projetos usados na análise interna. Os slots serão reutilizados se forem deixadas pelo nível de processamento de dados ou de computação.
• Nível baixo de computação: 2.000 slots. Ignorar os inativos. Essa reserva é aplicada a locatários com recursos baixos. Ao contrário do nível alto, essa reserva ignora os slots inativos.
• Nível elevado de computação: 3.000 slots. Permitir os inativos. Essa reserva é aplicada a locatários com recursos de alta qualidade. Para acelerar as consultas, os slots inativos de outras reservas são aplicados automaticamente.

Se os locatários operam em uma infraestrutura dedicada, recomendamos atribuir a pasta ou o projeto designado à reserva compartilhada apropriada.

Reservas por equipe

Ao trabalhar com equipes em um data lake, recomendamos que você crie uma reserva para cada equipe que necessite de computação adicional. Em seguida, atribua essa reserva à pasta pai que contém os projetos da equipe. Todos os novos projetos dessa equipe usam slots de programação equitativa da mesma alocação de recursos.

Veja a seguir um exemplo de como configurar reservas por equipe:

• Reserva no nível da organização: 500 slots. Permitir os inativos. Essa reserva é atribuída à organização de nível superior e fornece slots para qualquer usuário do BigQuery que não esteja usando um projeto com uma reserva dedicada.
• Processamento de dados: 1.000 slots. Ignora os inativos. Essa reserva é configurada para atender aos SLOs mínimos de processamento de dados.
• Administração de dados principais: 500 slots. Permitir os inativos. Essa reserva é aplicada aos projetos usados para administração interna. Os slots serão reutilizados se forem deixados de fora no processamento de dados ou nas camadas de computação.
• Reservas de processamento de análises: 500 slots. Permitir os inativos. É uma reserva dedicada fornecida a uma equipe de análise.

Requisitos de hospedagem em várias regiões

Os requisitos de hospedagem em várias regiões geralmente são resultado de uma necessidade de reduzir a latência dos dados para os consumidores ou atender a exigências regulatórias.

Os projetos do Google Cloud são considerados globais e podem provisionar recursos em qualquer região. O BigQuery considera conjuntos de dados, políticas de coluna e compromissos de slots como recursos regionais. Os slots só podem acessar conjuntos de dados na região local. Além disso, as políticas de colunas só podem ser aplicadas a tabelas em conjuntos de dados locais. Para usar preços baseados em capacidade, é preciso comprar slots em cada região que contém conjuntos de dados.

Para receber orientações sobre como aderir aos requisitos regulamentares, consulte seu representante de vendas.

A seguir

• Saiba mais sobre práticas recomendadas do IAM.