Práticas recomendadas para cargas de trabalho multiinquilino no BigQuery

Este documento fornece técnicas e práticas recomendadas para padrões comuns que são usados em plataformas de dados multi-inquilino e data marts empresariais.

As empresas comerciais, os fornecedores de software como serviço (SaaS) e as organizações governamentais têm frequentemente de alojar em segurança dados internos e de terceiros em limites geográficos e administrativos. BigQuery é uma ferramenta poderosa que pode satisfazer consistentemente os requisitos de plataforma multi-inquilino para exabytes de dados e centenas de milhares de consumidores de dados em unidades de negócio distintas. Este documento destina-se a organizações que implementam plataformas multiinquilino no BigQuery e que querem compreender os controlos de acesso e as funcionalidades de gestão de desempenho disponíveis.

Os criadores de plataformas multiinquilino têm frequentemente de equilibrar as considerações para o seguinte:

• Isolamento de dados: implemente controlos rigorosos para evitar fugas de dados entre inquilinos.
• Desempenho consistente: configure e atribua reservas do BigQuery para manter um desempenho consistente em todos os inquilinos.
• Gestão de recursos: planeie o impacto das quotas e dos limites.
• Distribuição geográfica: localize dados em localizações geográficas designadas e necessárias. Para preocupações relacionadas com a conformidade, consulte as Google Cloudofertas de conformidade.
• Auditoria e segurança: salvaguarde os dados do inquilino contra o acesso e a exfiltração inadequados.
• Gestão de custos: garanta custos consistentes do BigQuery para alojar cada inquilino.
• Complexidade operacional: minimize a quantidade de variabilidade do sistema necessária para alojar novos inquilinos.

Fornecedor de SaaS com infraestrutura de inquilino partilhada

Os fornecedores de SaaS que alojam dados de terceiros têm de garantir a fiabilidade e o isolamento de toda a sua base de clientes. Esses clientes podem ser dezenas de milhares e os dados dos clientes podem ser acedidos através da infraestrutura de serviços partilhados. Alguns fornecedores de SaaS também mantêm um repositório de dados central e limpo para fazer análises em toda a sua frota de inquilinos.

Uma arquitetura de conjunto de dados por inquilino ajuda a mitigar as seguintes preocupações que uma organização tem quando é dimensionada para milhares de inquilinos:

• Complexidade administrativa: o número total de novos projetos e recursos na nuvem por cliente
• Latência de ponta a ponta: o quão atualizada está a base de dados para os inquilinos e as soluções de estatísticas de vários clientes
• Expectativas de desempenho: garantir que o desempenho do inquilino se mantém dentro dos limites aceitáveis

Configure conjuntos de dados para cada inquilino

Num projeto dedicado ao armazenamento de dados de clientes, os dados de cada cliente são separados por conjuntos de dados do BigQuery. Na organização anfitriã, usa um segundo projeto para implementar a análise e a aprendizagem automática em dados de clientes combinados. Em seguida, pode configurar o motor de tratamento de dados, o Dataflow, para escrever dados recebidos nas tabelas internas e específicas do inquilino. A configuração do Dataflow usa tabelas totalmente escritas em vez de vistas autorizadas. A utilização de tabelas totalmente escritas permite o processamento uniforme da distribuição geográfica e ajuda a evitar atingir os limites de visualização autorizados quando o número de inquilinos aumenta.

A separação do armazenamento e da computação do BigQuery permite-lhe configurar menos projetos em comparação com os armazéns baseados em clusters para resolver problemas como os níveis de serviço e o isolamento de dados. Quando não precisa de configurar inquilinos com recursos de nuvem dedicados adicionais, recomendamos que considere a configuração predefinida de um conjunto de dados dedicado para cada inquilino. O diagrama seguinte mostra um exemplo de configuração do projeto com base nesta criação recomendada:

Figura 1. Um número constante de projetos processa os dados e as necessidades de processamento à medida que o número de inquilinos aumenta.

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

• Projeto de pipeline de dados: os componentes de infraestrutura principais que recebem, processam e distribuem os dados do inquilino estão todos incluídos num único projeto.
• Projeto de dados de inquilinos combinado: o projeto de dados principal que mantém um conjunto de dados por cliente. Espera-se que os dados do inquilino sejam acedidos através de projetos de nível de computação.
• Projetos de desenvolvimento interno: projetos que representam os recursos autogeridos que as equipas de estatísticas usam para avaliar os dados dos inquilinos e criar novas funcionalidades.
• Projetos de aplicações de utilizador final: projetos que contêm recursos concebidos para interagir com utilizadores finais. Recomendamos que use contas de serviço com âmbito de inquilino para aceder a conjuntos de dados de inquilinos e use um pipeline de compilação robusto e seguro para implementar aplicações.
• Projetos de nível de computação de reserva: os projetos que mapeiam a atividade de consulta do inquilino para reservas do BigQuery.

Partilhe reservas

As reservas nesta abordagem baseiam-se no algoritmo de agendamento justo integrado nas reservas do BigQuery. Cada reserva de nível de computação é atribuída a um único projeto. As consultas de inquilinos usam intervalos de agendamento justo que estão disponíveis para cada projeto de nível de computação, e os intervalos não usados de qualquer nível são automaticamente reutilizados noutro nível. Se um inquilino tiver requisitos de tempo específicos, pode usar um par de projeto-reserva dedicado a fornecer um número exato de espaços.

Configure perímetros dos VPC Service Controls

Nesta configuração, recomendamos perímetros dos VPC Service Controls para evitar a exposição acidental de conjuntos de dados de inquilinos fora da sua Google Cloud organização e para evitar a junção de dados não autorizada na organização.

Perímetros

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

• Pipeline de dados: um perímetro em torno dos projetos de pipeline de dados deve aplicar todos os serviços que não precisam de receber dados de inquilinos.
• Dados do inquilino: um perímetro em torno do projeto do conjunto de dados do inquilino e em torno dos projetos de computação do BigQuery do inquilino. Aplique todos os serviços para impedir o acesso a partir de fora da organização.
• Aplicações internas: aplique todos os serviços e use níveis de acesso para conceder acesso a recursos às equipas dos departamentos.
• Aplicações externas: um perímetro em torno das suas aplicações SaaS. Aplique todos os serviços que não sejam necessários para o funcionamento das aplicações.

Pontes de perímetro

Nesta configuração, recomendamos que crie as seguintes pontes de perímetro:

• Data pipeline e dados do inquilino: permitir que a pipeline escreva dados em conjuntos de dados do inquilino.
• Pipeline de dados e aplicações internas: permitem que a pipeline escreva dados no conjunto de dados de vários clientes.
• Aplicações externas e dados de inquilinos: permita que as aplicações externas consultem dados de inquilinos.
• Aplicações externas e aplicações internas: permitem que as aplicações viradas para o exterior processem dados através de modelos que as aplicações internas desenvolvem e implementam.

Fornecedor de SaaS com infraestrutura de inquilino dedicada

Em cenários mais complexos, os fornecedores de SaaS podem implementar uma infraestrutura de computação dedicada para cada inquilino. Neste cenário, a infraestrutura dedicada é responsável por processar pedidos de dados de inquilinos no BigQuery.

Um design de infraestrutura de inquilino dedicado aborda as seguintes preocupações comuns ao implementar infraestrutura para cada inquilino juntamente com o BigQuery:

• Responsabilidade pela faturação: monitorizar os custos de infraestrutura associados a cada inquilino integrado.
• Latência integral: o nível de atualização do repositório de dados para os inquilinos e as soluções de estatísticas de vários clientes.
• Expetativas de desempenho: garantir que o desempenho do inquilino se mantém dentro dos limites aceitáveis.

Coloque conjuntos de dados com recursos dedicados

Quando implementa uma infraestrutura de inquilino dedicada, recomendamos que crie uma pasta principal para os projetos específicos do inquilino. Em seguida, coloque os conjuntos de dados do BigQuery do inquilino em projetos com os recursos dedicados que acedem a esses dados em nome do inquilino. Para minimizar a latência completa dos dados do inquilino, os pipelines do Dataflow inserem dados diretamente nos conjuntos de dados do inquilino.

Este design processa e distribui dados a montante, de forma semelhante ao design de infraestrutura partilhada anterior. No entanto, os dados e as aplicações do inquilino que acedem aos dados do inquilino estão organizados em projetos específicos do inquilino (e, opcionalmente, organizados em pastas dedicadas ao inquilino) para simplificar a faturação e a gestão de recursos. O diagrama seguinte mostra um exemplo de configuração do projeto com base nesta criação recomendada:

Figura 2. Um projeto de pipelines de dados processa dados de um único inquilino de vários outros projetos.

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

• Projeto de pipelines de dados: os componentes de infraestrutura essenciais que recebem, processam e distribuem os dados do inquilino estão todos incluídos num único projeto.
• Projetos de inquilino dedicados: projetos que contêm todos os recursos da nuvem dedicados a um único inquilino, incluindo conjuntos de dados do BigQuery. Recomendamos que use a gestão de identidade e de acesso (IAM) para limitar significativamente o âmbito das contas e das contas de serviço que podem aceder aos conjuntos de dados de clientes.
• Projetos de estatísticas internos: projetos que representam os recursos autogeridos que as equipas de estatísticas usam para avaliar os dados do inquilino e criar novas funcionalidades.
• Projeto de rede externo: projeto que processa e encaminha pedidos de inquilinos para os respetivos back-ends dedicados.

Partilhe reservas

As reservas nesta abordagem baseiam-se no algoritmo de agendamento justo integrado nas reservas do BigQuery. Nesta configuração, as reservas de nível de computação são atribuídas a cada projeto de inquilino que usa esse nível. Se um inquilino tiver requisitos de tempo específicos, pode criar uma reserva dedicada para fornecer um número preciso de espaços a um projeto de inquilino.

Use os controlos da IAM e desative a criação de chaves

Os perímetros dos VPC Service Controls podem não ser adequados para este cenário. Os limites relacionados com o projeto impedem que uma organização use limites de perímetro em torno de projetos que interagem com os projetos de inquilino. Em alternativa, recomendamos que use controlos de IAM rigorosos e desative a criação de chaves para ajudar a proteger contra o acesso externo indesejado.

Repositório de dados com autoridade central

Os data marts são um tema de design comum em que os dados de estatísticas essenciais são armazenados num repositório central e os subconjuntos são partilhados ao longo das linhas de negócio. Os mercados de dados têm frequentemente dezenas ou centenas de inquilinos, representados como linhas de negócio, a ter em conta.

Uma conceção de data mart no BigQuery satisfaz as seguintes necessidades:

• Colaboração segura de dados: partilhar dados com controlos técnicos para minimizar o acesso inadequado entre equipas.
• Gestão de dados centralizada: garantir que os recursos de dados essenciais usados para relatórios empresariais críticos são padronizados e validados.
• Atribuição de custos da unidade de negócio: acompanhamento e ajuste da utilização de computação por unidades de negócio.

Use um repositório administrado centralmente

Neste design, os dados essenciais são capturados num repositório administrado centralmente. As vistas autorizadas, as funções definidas pelo utilizador (FDUs) autorizadas e as políticas de colunas são frequentemente usadas em conjunto para partilhar dados com linhas de negócio, ao mesmo tempo que impedem a distribuição acidental de dados confidenciais.

As equipas nos projetos de inquilinos podem aceder a conjuntos de dados geridos centralmente com base nas respetivas autorizações da conta. As equipas usam as posições atribuídas aos seus próprios projetos para criar relatórios e conjuntos de dados derivados. A equipa de dados principal usa vistas autorizadas para manter a propriedade total do controlo de acesso aos recursos do data mart. Nesta configuração, recomendamos que evite criar várias camadas de vistas sobre os objetos apresentados pelo projeto de dados principal. O diagrama seguinte mostra um exemplo de configuração do projeto com base nesta criação recomendada:

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

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

• Projeto de dados essenciais: o perímetro de governação para gerir o acesso aos dados essenciais e às vistas do data mart. Mantém as vistas autorizadas nos conjuntos de dados deste projeto e concede vistas autorizadas às suas equipas de análise com base na associação a grupos.
• Extrair, transformar, carregar (ETL) infraestrutura: infraestrutura para processar origens de dados a montante nos dados principais. Consoante as necessidades de separação administrativa, pode optar por implementar a infraestrutura de ETL como o seu próprio projeto ou como parte do projeto de dados principal.
• Projetos da equipa de análise: os consumidores do mercado de dados usam estes projetos e usam o seu próprio acesso à infraestrutura aprovisionada para processar dados no mercado de dados. Espera-se que os projetos da equipa de estatísticas consigam criar conjuntos de dados derivados para utilização local.

Use um design de reserva de dois níveis

Quando trabalha com data marts, recomendamos que use um design de dois níveis. Num design de dois níveis, atribui ao recurso da organização uma reserva com um pequeno número de vagas para abranger a utilização geral. Se as equipas tiverem necessidades maiores, atribua reservas ao nível do projeto ou da pasta.

Configure perímetros dos VPC Service Controls

Nesta configuração, recomendamos perímetros dos VPC Service Controls para evitar a exposição acidental de conjuntos de dados do BigQuery fora da suaGoogle Cloud organização.

Perímetros

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

• Dados principais: um perímetro para proteger os conjuntos de dados do data warehouse e do data mart.
• Pipelines de dados: um perímetro para o projeto de infraestrutura ETL. Se os pipelines de dados precisarem de fazer pedidos fora da sua organização, recomendamos que separe este perímetro do perímetro de dados principal. Google Cloud
• Analytics: um perímetro para criar e implementar recursos de estatísticas que são internos à sua organização. Espera-se que este perímetro tenha uma política de acesso mais permissiva do que o perímetro de dados principal com o qual está interligado.

Pontes de perímetro

Nesta configuração, recomendamos que crie as seguintes pontes de perímetro:

• Data pipelines e dados essenciais: permitir que as data pipelines escrevam no projeto de dados essenciais.
• Dados e estatísticas principais: permitem que os utilizadores nos projetos de estatísticas consultem as vistas autorizadas.

Copie conjuntos de dados para configurações multirregionais

Uma vez que o BigQuery não permite consultas entre regiões, não pode usar a estratégia de segmentar dados com vistas autorizadas quando os data marts têm de existir em várias regiões. Em alternativa, 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, cria políticas de colunas no catálogo de dados para cada região adicional em que os dados residem. O diagrama seguinte 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 essenciais: o perímetro de governação para gerir o acesso aos dados essenciais e às vistas do data mart. Os dados são copiados e mantidos em conjuntos de dados regionais que podem servir equipas a nível global.
• Infraestrutura de ETL: infraestrutura para processar origens de dados a montante nos dados principais. Consoante as necessidades de separação administrativa, pode optar por implementar a infraestrutura de ETL como o seu próprio projeto ou como parte do projeto de dados principal.
• Projetos da equipa de estatísticas: os consumidores do mercado de dados usam estes projetos e usam a sua própria infraestrutura aprovisionada para processar dados em conjuntos de dados regionais do mercado de dados. Espera-se que os projetos da equipa de estatísticas consigam criar conjuntos de dados derivados para utilização local.

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

Se a sua organização precisar de mais flexibilidade, estão disponíveis as seguintes opções:

• Tarefas do Cloud Composer: pode agendar tarefas do Cloud Composer para emitir tarefas de ETL que criam subconjuntos regionais antes de acionar o Serviço de transferência de dados do BigQuery através da respetiva API de cliente. Se a sua organização puder suportar latência adicional, recomendamos esta opção.
• Infraestrutura de ETL: a infraestrutura de ETL, como o Dataflow, pode escrever duplamente subconjuntos regionais em regiões de destino. Se a sua organização exigir uma latência de dados mínima entre regiões, recomendamos esta opção.

Data marts com autoridade descentralizada

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

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

• Colaboração segura de dados: partilhar dados com controlos técnicos para minimizar o acesso inadequado entre equipas.
• Visibilidade dos dados: as equipas têm de conseguir descobrir e pedir acesso a conjuntos de dados.
• Proveniência dos dados: sem uma equipa de curadores central, as equipas têm de poder confiar na origem dos dados que entram nos respetivos produtos de estatísticas.

Delegue a administração de dados essenciais

Este design é diferente de uma abordagem convencional de data mart porque a autoridade descentralizada delega as decisões de administração de dados principais nos subgrupos de componentes da organização. Quando usa a autoridade descentralizada, mantém o controlo central da segurança e da capacidade do BigQuery através do Cloud Key Management Service (Cloud KMS), das políticas de colunas, dos VPC Service Controls e das reservas. Por conseguinte, evita a expansão descontrolada de dados que é comum com os armazéns geridos por si. O diagrama seguinte mostra uma arquitetura que usa autoridade descentralizada:

Figura 5. Um projeto de governação central ajuda a garantir uma segurança consistente, enquanto os grupos individuais mantêm as respetivas operações de dados.

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

• Projeto de governação principal: o projeto responsável por questões de gestão entre organizações. Neste projeto, cria recursos de segurança, como conjuntos de chaves do Cloud KMS e políticas de colunas do catálogo de dados. Este projeto funciona como o projeto de administração de reservas do BigQuery, permitindo a partilha de slots em toda a organização.
• Projetos de dados da unidade organizacional: os proprietários de data marts autogeridos na organização mais ampla. O projeto de governação principal gere o âmbito restrito para os projetos de dados da unidade organizacional.
• Projetos da equipa do Analytics: os projetos usados pelos consumidores dos data marts. Estes projetos usam a sua própria infraestrutura aprovisionada e slots para aceder e processar dados no data mart.

Use um design de reserva de dois níveis

Recomendamos que os seus data marts descentralizados usem o mesmo design de dois níveis que os data marts padrão. Nesta configuração, atribui ao recurso da organização uma reserva com um pequeno número de espaços para abranger a utilização geral. Se as equipas tiverem necessidades maiores, atribua reservas ao nível do projeto ou da pasta.

Use um catálogo de dados

Um catálogo de dados oferece descoberta ao nível da organização, etiquetagem de metadados e configuração de políticas de colunas. A deteção do Dataplex cria automaticamente entradas de metadados para todas as novas tabelas do BigQuery na sua organização. As capacidades do Dataplex também ajudam os administradores de governação de dados a identificar rapidamente novos recursos de dados e a aplicar os controlos adequados.

Configure perímetros dos VPC Service Controls

Nesta configuração, recomendamos perímetros dos VPC Service Controls para evitar a exposição acidental de conjuntos de dados do BigQuery fora da suaGoogle Cloud organização.

Perímetros

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

• Dados principais: um perímetro para proteger os conjuntos de dados do data warehouse e do data mart. Este perímetro deve incluir todos os projetos de unidades organizacionais e o projeto de administração de dados.
• Analytics: um perímetro para criar e implementar recursos de estatísticas internos à organização. Espera-se que este perímetro tenha uma política de acesso mais permissiva do que o perímetro de dados principal com o qual está interligado.

Pontes de perímetro

Nesta configuração, recomendamos que crie as seguintes pontes de perímetro:

• Dados e estatísticas principais: permitem que os utilizadores nos projetos de estatísticas consultem as vistas autorizadas.

Partilha de dados entre várias organizações

A partilha entre várias organizações é uma consideração de design especial para o design de um data mart. Esta conceção de partilha de dados destina-se a organizações que pretendem partilhar os respetivos conjuntos de dados de forma segura com outra entidade que tenha a sua própria organização Google.

A partilha de dados entre várias organizações aborda as seguintes preocupações do partilhador de dados:

• Confidencialidade da partilha: apenas a parte pretendida pode aceder aos dados partilhados.
• Proteção contra acesso inadequado: só é possível aceder externamente aos recursos que se destinam a ser acedidos.
• Separação de computação: as partes externas são faturadas pelas consultas que iniciam.

Nota: em alguns casos, as consultas originadas de fora da organização podem falhar inesperadamente. O Cloud Customer Care pode ajudar a iniciar uma alteração de configuração para corrigir o problema.

Proteja projetos internos de projetos de dados partilhados

A conceção da partilha de dados multi-organizacional centra-se na proteção dos projetos internos da organização contra a atividade em projetos de dados partilhados. O projeto do conjunto de dados partilhado funciona como um buffer para não permitir o acesso ao processamento de dados internos confidenciais, ao mesmo tempo que oferece a capacidade de partilhar 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 partilharem a mesma Google Cloud região, estas consultas podem unir dados entre organizações. O diagrama seguinte mostra como os conjuntos de dados são partilhados numa configuração de projeto com várias organizações:

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

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 partilhar dados externamente copiando dados higienizados para os conjuntos de dados do projeto de dados partilhados. O projeto interno deve ser proprietário da conta de serviço responsável por atualizar os dados partilhados.
• Projeto de dados partilhados: o projeto que contém as informações saneadas que são copiadas do projeto interno. Use grupos de utilizadores externos para gerir o acesso por partes externas. Neste cenário, gere a associação ao grupo como uma função administrativa e concede às contas externas a autorização de visualizador para que possam aceder ao conjunto de dados através destes grupos.

Configure perímetros dos VPC Service Controls

Nesta configuração, recomendamos os perímetros dos VPC Service Controls para partilhar dados externamente e evitar a exposição acidental de conjuntos de dados do BigQuery fora dos seus projetos internos.

Perímetros

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

• Dados internos: um perímetro para proteger os principais recursos de dados. Os VPC Service Controls aplicam o acesso ao BigQuery.
• Dados partilhados externamente: um perímetro para alojar conjuntos de dados que podem ser partilhados com organizações externas. Este perímetro desativa a aplicação do acesso ao BigQuery.

Pontes de perímetro

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

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

Considerações adicionais em sistemas multi-inquilinos

Esta secção apresenta uma análise mais detalhada de casos especiais que pode considerar juntamente com as práticas recomendadas anteriores.

Google Cloud Limites e quotas de recursos

• As contas de serviço estão limitadas a uma quota flexível de 100 contas de serviço por projeto. Pode pedir quota através da consola Google Cloud para projetos que mantêm contas de serviço de inquilino.
• A simultaneidade do BigQuery tem uma simultaneidade predefinida de 100 consultas por projeto que emite consultas (os projetos que contêm conjuntos de dados não têm estes limites). Para aumentar esta quota flexível, contacte o seu representante de vendas.
• O VPC Service Controls tem um limite de 10 000 projetos em toda a organização nos perímetros de serviço. Se os seus designs de projeto por inquilino tiverem uma grande expansão, recomendamos que use um design de conjunto de dados por inquilino.
• O VPC Service Controls tem um limite de 100 perímetros, incluindo pontes, por organização.

Usar vistas autorizadas ou tabelas de subconjuntos materializadas

Para gerir o acesso dos inquilinos a subconjuntos de tabelas de factos grandes, pode usar vistas autorizadas específicas do inquilino ou criar tabelas de subconjuntos específicas do inquilino. A tabela seguinte apresenta uma comparação destas abordagens:

Funcionalidade	Vistas autorizadas	Tabelas de subconjuntos
Número de inquilinos suportados	Existe um limite rígido de 2500 recursos autorizados por conjunto de dados.	Os recursos autorizados incluem vistas autorizadas, conjuntos de dados autorizados e funções autorizadas.Não existem limites para o número de conjuntos de dados num projeto ou de tabelas num conjunto de dados.
Partição e clustering	As vistas autorizadas têm de partilhar o esquema de partição e cluster comum da tabela base. Para melhorar o desempenho da segmentação de inquilinos, recomendamos que agrupe a tabela principal no ID do inquilino.	Pode particionar a tabela de subconjuntos e agrupá-la de acordo com as necessidades do inquilino.
Regionalização	As vistas autorizadas não podem abranger várias regiões e têm de estar na Google Cloud região da tabela base. A regionalização afeta inquilinos geograficamente remotos.	As tabelas de subconjuntos podem existir na região mais adequada para o inquilino. Podem aplicar-se custos adicionais.
Aplicação de políticas de colunas	As políticas de colunas aplicadas a uma tabela base são aplicadas a todas as vistas autorizadas, independentemente das autorizações nessas vistas.	Cada tabela de subconjunto tem de aplicar a política de colunas para que entre em vigor.
Registo em registo de acesso aos dados	Os registos de acesso aos dados são refletidos no registo da tabela base.	O acesso a cada tabela de subconjunto é registado separadamente.
Flexibilidade de transformação	As vistas autorizadas permitem a reformulação instantânea do objeto ao qual os inquilinos estão a aceder.	São necessárias alterações complexas ao esquema para alterar tabelas de subconjuntos.

Controlar dados confidenciais

Para evitar o acesso não autorizado aos dados, o BigQuery oferece várias funcionalidades adicionais além das autorizações padrão da IAM.

Encriptação fornecida pelo cliente

A encriptação de dados do cliente abrange os casos em que uma organização de alojamento armazena e processa dados em nome de um inquilino, mas é impedida de aceder a alguns dos conteúdos de dados. Por exemplo, a organização de alojamento pode ser impedida de aceder a dados pessoais ou de dispositivos considerados confidenciais.

Recomendamos que o remetente de dados use chaves de encriptação AEAD da biblioteca Tink de código aberto para encriptar dados confidenciais. As chaves de encriptação AEAD da biblioteca Tink são compatíveis com as funções AEAD do BigQuery. Em seguida, o inquilino pode desencriptar os dados acedendo ao material da chave numa UDF autorizada ou transmitindo o material da chave como um parâmetro de consulta ao BigQuery, onde a organização anfitriã não pode registar a chave.

Políticas de acesso a colunas

Nos data marts multi-inquilinos, as políticas de colunas são usadas frequentemente para evitar a fuga acidental de conteúdo sensível entre equipas que colaboram. As vistas autorizadas são o mecanismo preferencial para partilhar dados entre equipas num cenário de data mart. As visualizações autorizadas não podem conceder acesso a uma coluna protegida.

Quando define a política para aplicar o controlo de acesso, impede o acesso a utilizadores que não receberam a função de leitor detalhado na política. Mesmo quando a política não é aplicada, a política regista todo o acesso do utilizador à coluna categorizada.

Proteção de dados confidenciais

A proteção de dados confidenciais oferece APIs e utilitários de análise que ajudam a identificar e mitigar conteúdo confidencial armazenado em conjuntos de dados do BigQuery ou do Cloud Storage. As organizações em cenários multiinquilinos usam frequentemente a API DLP (parte da proteção de dados confidenciais) para identificar e, opcionalmente, tokenizar dados confidenciais antes de serem armazenados.

Gestão de reservas de horários disponíveis

A gestão de reservas em sistemas multi-inquilinos ajuda a controlar os custos à medida que os inquilinos aumentam e garante as garantias de desempenho para cada inquilino.

Para gerir reservas, recomendamos que crie um único projeto administrativo de reservas. Os compromissos de ranuras comprados no mesmo projeto administrativo são partilháveis em todas as reservas que têm origem no projeto administrativo. Um projeto que usa compromissos de slots só pode ser atribuído a uma reserva de cada vez. Todas as consultas que têm origem num projeto partilham espaços com base nos recursos disponíveis.

Para garantir que os objetivos de nível de serviço (SLOs) dos inquilinos são cumpridos, pode monitorizar as reservas através do Cloud Logging e do esquema de informações do BigQuery. As organizações que registam períodos de grande atividade devido à atividade dos analistas ou a tarefas prioritárias podem atribuir capacidade adicional através de slots flexíveis.

Reservas como níveis de computação de inquilino

Os fornecedores de SaaS que têm dezenas a muitos milhares de inquilinos configuram normalmente um número finito de reservas do BigQuery como recursos partilhados.

Se for um fornecedor de SaaS com uma infraestrutura de inquilinos partilhada, recomendamos que dedique cada reserva a um único projeto e agrupe os inquilinos para partilhar esse projeto para computação do BigQuery. Este design reduz a sobrecarga administrativa de ter milhares de projetos e reservas adicionais, ao mesmo tempo que permite à sua organização atribuir uma capacidade de vagas mínima necessária para satisfazer as necessidades de desempenho previstas para a reserva.

Se a atualização do processamento de dados ELT for uma prioridade máxima, recomendamos que atribua uma reserva para processamento. Para evitar a utilização de espaços adicionais que poderiam ser usados para cargas de trabalho ad hoc, defina a reserva para ignorar espaços inativos.

Segue-se um exemplo de como configurar as reservas como níveis de computação de inquilinos:

• Processamento de dados: 2000 espaços, ignorar inativos. Esta reserva está configurada para cumprir os SLOs de tratamento de dados.
• Projetos internos: 1000 vagas, permitem a inatividade. Esta reserva é aplicada aos projetos usados para estatísticas internas.Os slots são reutilizados se sobrarem do tratamento de dados ou dos níveis de computação.
• Nível de computação baixo: 2000 espaços, ignorar inatividade. Esta reserva é aplicada a inquilinos com poucos recursos. Ao contrário do nível elevado, esta reserva ignora os espaços inativos.
• Nível de computação elevado: 3000 slots, permite o estado inativo. Esta reserva é aplicada a inquilinos com recursos elevados. Para acelerar as consultas, são aplicadas automaticamente vagas inativas de outras reservas.

Se os seus inquilinos operarem numa infraestrutura dedicada, recomendamos que atribua a pasta ou o projeto designado à reserva partilhada adequada.

Reservas por equipa

Quando trabalha com equipas numa definição de data mart, recomendamos que crie uma reserva para cada equipa que necessite de computação adicional. Em seguida, atribua essa reserva à pasta principal que contém os projetos da equipa. Todos os novos projetos dessa equipa usam horários de agendamento justo da mesma atribuição de recursos.

Segue-se um exemplo de como configurar as reservas por equipa:

• Reserva ao nível da organização: 500 vagas, permite o estado inativo. Esta reserva é atribuída à organização de nível superior e dá capacidade de processamento a qualquer utilizador do BigQuery que não esteja a usar um projeto com uma reserva dedicada
• Processamento de dados: 1000 espaços, ignorar inativos. Esta reserva está configurada para cumprir os SLOs de tratamento de dados mínimos.
• Administração de dados essenciais: 500 slots, permitir inatividade. Esta reserva é aplicada aos projetos usados para administração interna. Os slots são reutilizados se sobrarem do tratamento de dados ou dos níveis de computação.
• Reservas de processamento do Analytics: 500 slots, permitem a inatividade. Esta é uma reserva dedicada que é atribuída a uma equipa de estatísticas.

Requisitos de alojamento multirregional

Normalmente, os requisitos de alojamento multirregional resultam da necessidade de reduzir a latência dos dados para os consumidores ou de cumprir os mandatos regulamentares.

Os projetos no Google Cloud são considerados globais e podem aprovisionar recursos em qualquer região. O BigQuery considera os conjuntos de dados, as políticas de colunas e os compromissos de slots como recursos regionais. Os slots só podem aceder a conjuntos de dados na região local, e as políticas de colunas só podem ser aplicadas a tabelas em conjuntos de dados locais. Para usar os preços baseados na capacidade, tem de comprar espaços em cada região que contenha conjuntos de dados.

Para orientações sobre a adesão aos requisitos regulamentares, consulte o seu representante de vendas.

O que se segue?

• Saiba mais sobre as práticas recomendadas de IAM.