Prácticas recomendadas para cargas de trabajo multiempresa en BigQuery
En este documento se describen técnicas y prácticas recomendadas para patrones comunes que se usan en plataformas de datos multiempresa y en mercados de datos empresariales.
Las empresas comerciales, los proveedores de software como servicio (SaaS) y las organizaciones públicas suelen tener que alojar de forma segura datos internos y de terceros en diferentes zonas geográficas y administrativas. BigQuery es una herramienta potente que puede satisfacer de forma constante los requisitos de la plataforma multiinquilino para exabytes de datos y cientos de miles de consumidores de datos en diferentes unidades de negocio. Este documento está dirigido a organizaciones que implementan plataformas multiempresa en BigQuery y que quieren conocer los controles de acceso y las funciones de gestión del rendimiento disponibles.
Los creadores de plataformas multiempresa a menudo tienen que equilibrar los siguientes aspectos:
- Aislamiento de datos: implementa controles estrictos para evitar fugas de datos entre los distintos clientes.
- Rendimiento constante: configura y asigna reservas de BigQuery para mantener un rendimiento constante en todos los inquilinos.
- Gestión de recursos: planifica el impacto de las cuotas y los límites.
- Distribución geográfica: localiza los datos en las ubicaciones geográficas designadas y obligatorias. Si tienes alguna duda relacionada con el cumplimiento, consulta los recursos de cumplimiento de Google Cloud.
- Auditoría y seguridad: protege los datos de los inquilinos frente a accesos y exfiltraciones inadecuados.
- Gestión de costes: asegúrate de que los costes de BigQuery sean coherentes para alojar a cada arrendatario.
- Complejidad operativa: minimiza la variabilidad del sistema necesaria para alojar nuevos clientes.
Proveedor de SaaS con infraestructura de arrendatario compartida
Los proveedores de SaaS que alojan datos de terceros deben garantizar la fiabilidad y el aislamiento de toda su flota de clientes. Es posible que esos clientes sean decenas de miles y que se acceda a los datos de los clientes a través de una infraestructura de servicios compartidos. Algunos proveedores de SaaS también mantienen un almacén de datos central y saneado para realizar análisis en toda su flota de clientes.
Un diseño de un conjunto de datos por cliente ayuda a mitigar los siguientes problemas que experimenta una organización cuando se amplía a miles de clientes:
- Complejidad administrativa: número total de proyectos nuevos y recursos en la nube por cliente.
- Latencia integral: indica si el almacén de datos está actualizado para los inquilinos y las soluciones de analíticas entre clientes.
- Expectativas de rendimiento: asegurarse de que el rendimiento del arrendatario se mantenga dentro de los límites aceptables.
Configurar conjuntos de datos para cada inquilino
En un proyecto dedicado a almacenar datos de clientes, los datos de cada cliente se separan por conjuntos de datos de BigQuery. En la organización anfitriona, se usa un segundo proyecto para implementar analíticas y aprendizaje automático en los datos de clientes combinados. A continuación, puede configurar el motor de procesamiento de datos, Dataflow, para que escriba los datos entrantes en las tablas internas y específicas del arrendatario. La configuración de flujo de datos usa tablas completas en lugar de vistas autorizadas. El uso de tablas escritas por completo permite gestionar de forma uniforme la distribución geográfica y ayuda a evitar alcanzar los límites de vistas autorizadas cuando aumenta el número de inquilinos.
La separación del almacenamiento y los recursos de computación de BigQuery te permite configurar menos proyectos en comparación con los almacenes basados en clústeres para gestionar problemas como los niveles de servicio y el aislamiento de datos. Si no necesitas configurar los arrendatarios con recursos de nube dedicada adicionales, te recomendamos que utilices la configuración predeterminada de un conjunto de datos dedicado para cada arrendatario. En el siguiente diagrama se muestra un ejemplo de configuración de un proyecto basado en este diseño recomendado:
Imagen 1. Un número constante de proyectos gestiona los datos y las necesidades de procesamiento a medida que aumenta el número de inquilinos.
La configuración del proyecto de la figura 1 incluye los siguientes proyectos:
- Proyecto de flujo de procesamiento de datos: los componentes de infraestructura principales que reciben, procesan y distribuyen los datos de los clientes se empaquetan en un único proyecto.
- Proyecto de datos de arrendatario combinado: proyecto de datos principal que mantiene un conjunto de datos por cliente. Se espera que se acceda a los datos de los arrendatarios a través de proyectos de nivel de computación.
- Proyectos de desarrollo interno: proyectos que representan los recursos autogestionados que usan los equipos de analíticas para evaluar los datos de los arrendatarios y crear nuevas funciones.
- Proyectos de aplicaciones para usuarios finales: proyectos que contienen recursos diseñados para interactuar con usuarios finales. Te recomendamos que uses cuentas de servicio específicas de un arrendatario para acceder a los conjuntos de datos del arrendatario y que utilices una pipeline de compilación sólida y segura para desplegar las aplicaciones.
- Proyectos de nivel de computación de reserva: proyectos que asignan la actividad de consulta del arrendatario a las reservas de BigQuery.
Compartir reservas
Las reservas de este enfoque se basan en el algoritmo de programación equitativa integrado en las reservas de BigQuery. Cada reserva de nivel de computación se asigna a un solo proyecto. Las consultas de inquilino usan slots de programación justos que están disponibles para cada proyecto de nivel de computación, y los slots no utilizados de cualquier nivel se reutilizan automáticamente en otro nivel. Si un arrendatario tiene requisitos de tiempo específicos, puedes usar un par de proyecto y reserva que se dedique a proporcionar un número exacto de ranuras.
Configurar perímetros de Controles de Servicio de VPC
En esta configuración, recomendamos usar perímetros de Controles de Servicio de VPC para evitar que los conjuntos de datos de los clientes se expongan accidentalmente fuera de tu organización y para impedir que se combinen datos sin autorización dentro de la organización. Google Cloud
Perímetros
En esta configuración, le recomendamos que cree los siguientes perímetros de servicio:
- Flujo de procesamiento de datos: se debe aplicar un perímetro a los proyectos del flujo de procesamiento de datos para todos los servicios que no necesiten recibir datos de los clientes.
- Datos de inquilino: un perímetro alrededor del proyecto del conjunto de datos del inquilino y alrededor de los proyectos de computación de BigQuery del inquilino. Fuerza todos los servicios para impedir el acceso desde fuera de la organización.
- Aplicaciones internas: aplica todos los servicios y usa niveles de acceso para conceder acceso a los recursos a los equipos de los departamentos.
- Aplicaciones externas: un perímetro alrededor de tus aplicaciones SaaS. Inhabilita todos los servicios que no sean necesarios para que las aplicaciones funcionen.
Perímetros puente
En esta configuración, le recomendamos que cree los siguientes puentes de perímetro:
- Flujo de procesamiento de datos y datos de inquilino: permite que el flujo de procesamiento escriba datos en conjuntos de datos de inquilinos.
- Proceso de datos y aplicaciones internas: permite que el proceso escriba datos en el conjunto de datos entre clientes.
- Aplicaciones externas y datos de inquilinos: permiten que las aplicaciones orientadas al exterior consulten datos de inquilinos.
- Aplicaciones externas e internas: permite que las aplicaciones orientadas al exterior procesen datos mediante modelos que las aplicaciones internas desarrollen e implementen.
Proveedor de SaaS con infraestructura de cliente dedicada
En situaciones más complejas, los proveedores de SaaS pueden implementar una infraestructura de computación dedicada para cada arrendatario. En este caso, la infraestructura dedicada se encarga de atender las solicitudes de datos de los clientes en BigQuery.
Un diseño de infraestructura de arrendatario dedicado aborda los siguientes problemas habituales al implementar la infraestructura de cada arrendatario junto con BigQuery:
- Rendición de cuentas de facturación: seguimiento de los costes de infraestructura asociados a cada arrendatario incorporado.
- Latencia integral: indica si el almacén de datos está actualizado para los inquilinos y las soluciones de analíticas entre clientes.
- Expectativas de rendimiento: asegurar que el rendimiento del arrendatario se mantenga dentro de los límites aceptables.
Colocar conjuntos de datos con recursos dedicados
Cuando implementes una infraestructura de inquilino dedicada, te recomendamos que crees una carpeta principal para los proyectos específicos del inquilino. A continuación, coloca los conjuntos de datos de BigQuery del arrendatario en proyectos con los recursos dedicados que acceden a esos datos en nombre del arrendatario. Para minimizar la latencia de extremo a extremo de los datos de los clientes, las canalizaciones de Dataflow insertan datos directamente en los conjuntos de datos de los clientes.
Este diseño gestiona el procesamiento y la distribución de datos upstream, de forma similar al diseño de infraestructura compartida anterior. Sin embargo, los datos y las aplicaciones del arrendatario que acceden a ellos se organizan en proyectos específicos del arrendatario (y, opcionalmente, en carpetas dedicadas al arrendatario) para simplificar la facturación y la gestión de recursos. En el siguiente diagrama se muestra un ejemplo de configuración de un proyecto basado en este diseño recomendado:
Imagen 2. Un proyecto de flujos de procesamiento de datos gestiona los datos de un solo arrendatario de varios proyectos.
La configuración del proyecto de la figura 2 incluye los siguientes proyectos:
- Proyecto de flujos de procesamiento de datos: los componentes de infraestructura principales que reciben, procesan y distribuyen los datos de los clientes se empaquetan en un único proyecto.
- Proyectos de inquilino dedicados: proyectos que contienen todos los recursos de la nube dedicados a un solo inquilino, incluidos los conjuntos de datos de BigQuery. Te recomendamos que uses Gestión de Identidades y Accesos (IAM) para limitar en gran medida el ámbito de las cuentas y cuentas de servicio que pueden acceder a los conjuntos de datos de los clientes.
- Proyectos de analíticas internos: proyectos que representan los recursos autogestionados que usan los equipos de analíticas para evaluar los datos de los inquilinos y crear nuevas funciones.
- Proyecto de red externa: proyecto que gestiona y enruta las solicitudes de los inquilinos a sus backends dedicados.
Compartir reservas
Las reservas de esta estrategia se basan en el algoritmo de programación equitativa que se incluye en las reservas de BigQuery. En esta configuración, las reservas de nivel de proceso se asignan a cada proyecto de cliente que usa ese nivel. Si un arrendatario tiene requisitos de tiempo específicos, puedes crear una reserva dedicada para proporcionar un número preciso de ranuras a un proyecto de arrendatario.
Usar los controles de gestión de identidades y accesos e inhabilitar la creación de claves
Es posible que los perímetros de Controles de Servicio de VPC no sean adecuados para este caso. Los límites relacionados con los proyectos impiden que una organización use límites de perímetro en torno a proyectos que interactúen con los proyectos del arrendatario. En su lugar, te recomendamos que uses controles de gestión de identidades y accesos estrictos y inhabilites la creación de claves para protegerte frente a accesos externos no deseados.
Mercado de datos con autoridad central
Los mercados de datos son un tema de diseño habitual en el que los datos analíticos principales se almacenan en un repositorio central y los subconjuntos se comparten en función de las líneas de negocio. Los mercados de datos suelen tener decenas o cientos de inquilinos, representados como líneas de negocio, que se deben tener en cuenta.
Un diseño de mercado de datos en BigQuery satisface las siguientes necesidades:
- Colaboración segura con datos: comparte datos con controles técnicos para minimizar el acceso inadecuado entre equipos.
- Gobernanza de datos centralizada: se asegura de que los recursos de datos principales que se usan en los informes empresariales cruciales estén estandarizados y validados.
- Atribución de costes de unidades de negocio: seguimiento y ajuste del uso de computación por unidades de negocio.
Usar un repositorio administrado de forma centralizada
En este diseño, los datos principales se recogen en un repositorio administrado de forma centralizada. Las vistas autorizadas, las funciones definidas por el usuario (UDFs) autorizadas y las políticas de columnas se suelen usar conjuntamente para compartir datos con líneas de negocio y, al mismo tiempo, evitar la distribución accidental de datos sensibles.
Los equipos de los proyectos de inquilino pueden acceder a conjuntos de datos gestionados de forma centralizada en función de los permisos de su cuenta. Los equipos usan los espacios asignados a sus proyectos para crear informes y conjuntos de datos derivados. El equipo de datos principal usa vistas autorizadas para mantener la propiedad total del control de acceso a los recursos del mercado de datos. En esta configuración, te recomendamos que no crees varias capas de vistas sobre los objetos que presenta el proyecto de datos principal. En el siguiente diagrama se muestra un ejemplo de configuración de proyecto basado en este diseño recomendado:
Imagen 3. Un proyecto de datos principal mantiene un data mart centralizado al que se puede acceder desde toda la organización.
La configuración del proyecto de la figura 3 incluye los siguientes proyectos:
- Proyecto de datos principales: el perímetro de gobernanza para gestionar el acceso a los datos principales y a las vistas del data mart. Mantienes las vistas autorizadas en los conjuntos de datos de este proyecto y las concedes a tus equipos de analíticas en función de la pertenencia a grupos.
- Infraestructura de extracción, transformación y carga (ETL): infraestructura para procesar las fuentes de datos de origen y convertirlas en los datos principales. En función de las necesidades de separación administrativa, puedes implementar la infraestructura de ETL como un proyecto independiente o como parte del proyecto de datos principal.
- Proyectos del equipo de analíticas: los consumidores del mercado de datos usan estos proyectos y su propio acceso a la infraestructura aprovisionada para procesar los datos del mercado de datos. Los proyectos del equipo de analíticas deben poder crear conjuntos de datos derivados para uso local.
Usar un diseño de reserva de dos niveles
Cuando trabaje con mercados de datos, le recomendamos que utilice un diseño de dos niveles. En un diseño de dos niveles, asignas al recurso de organización una reserva que tiene un número reducido de ranuras para cubrir el uso general. Si los equipos tienen más necesidades, asigna reservas a nivel de proyecto o carpeta.
Configurar perímetros de Controles de Servicio de VPC
En esta configuración, recomendamos usar perímetros de seguridad de Controles de Servicio de VPC para evitar que los conjuntos de datos de BigQuery se expongan accidentalmente fuera de tuGoogle Cloud organización.
Perímetros
En esta configuración, le recomendamos que cree los siguientes perímetros de servicio:
- Datos principales: un perímetro para proteger los conjuntos de datos del almacén de datos y del mercado de datos.
- Flujos de procesamiento de datos: un perímetro para el proyecto de infraestructura de ETL. Si las canalizaciones de datos necesitan hacer solicitudes fuera de tu Google Cloud organización, te recomendamos que separes este perímetro del perímetro de datos principal.
- Analytics: un perímetro para crear e implementar recursos de analíticas internos de tu organización. Se espera que este perímetro tenga una política de acceso más permisiva que el perímetro de datos principal con el que está conectado.
Perímetros puente
En esta configuración, te recomendamos que crees los siguientes puentes de perímetro:
- Flujos de procesamiento de datos y datos principales: permite que los flujos de procesamiento de datos escriban en el proyecto de datos principales.
- Datos y analíticas principales: permite a los usuarios de los proyectos de analíticas consultar las vistas autorizadas.
Copiar conjuntos de datos en configuraciones multirregionales
Como BigQuery no permite las consultas entre regiones, no puedes usar la estrategia de segmentar datos con vistas autorizadas cuando los mercados de datos deben estar en varias regiones. En su lugar, puede usar BigQuery Data Transfer Service para copiar los conjuntos de datos pertinentes en otra región. En este caso, creas políticas de columnas en el catálogo de datos para cada región adicional en la que residan los datos. En el siguiente diagrama se muestra una configuración multirregional:
Imagen 4. En una configuración multirregional, se usa BigQuery Data Transfer Service para copiar conjuntos de datos entre regiones.
La configuración del proyecto de la figura 4 incluye los siguientes proyectos.
- Proyecto de datos principales: el perímetro de gobernanza para gestionar el acceso a los datos principales y a las vistas del data mart. Los datos se copian y se mantienen en conjuntos de datos regionales que pueden servir a equipos de todo el mundo.
- Infraestructura de ETL: infraestructura para procesar las fuentes de datos de origen y convertirlas en datos principales. En función de las necesidades de separación administrativa, puedes implementar la infraestructura de ETL como un proyecto independiente o como parte del proyecto de datos principal.
- Proyectos del equipo de analíticas: los consumidores del mercado de datos usan estos proyectos y su propia infraestructura aprovisionada para procesar datos en conjuntos de datos regionales del mercado de datos. Se espera que los proyectos del equipo de analíticas puedan crear conjuntos de datos derivados para uso local.
BigQuery Data Transfer Service es un componente programado adicional que tiene algunas limitaciones. El programador de servicios integrado está limitado a un intervalo mínimo de 15 minutos y debe copiar todas las tablas del conjunto de datos de origen. No se pueden insertar secuencias de comandos adicionales para crear subconjuntos de datos específicos de una región en el programador de BigQuery Data Transfer Service.
Si tu organización necesita más flexibilidad, tienes las siguientes opciones:
- Tareas de Cloud Composer: puedes programar tareas de Cloud Composer para emitir tareas de ETL que creen subconjuntos regionales antes de activar BigQuery Data Transfer Service a través de su API de cliente. Si tu organización puede admitir una latencia adicional, te recomendamos esta opción.
- Infraestructura de ETL: la infraestructura de ETL, como Dataflow, puede escribir simultáneamente subconjuntos regionales en regiones de destino. Si tu organización necesita una latencia de datos mínima entre regiones, te recomendamos esta opción.
Mercados de datos con autoridad descentralizada
Usa la autoridad descentralizada cuando necesites una separación administrativa por propietario del sistema, líneas de negocio o cuestiones geográficas.
Un mercado de datos descentralizado tiene las siguientes diferencias con respecto a un mercado de datos estándar:
- Colaboración segura con datos: comparte datos con controles técnicos para minimizar el acceso inadecuado entre equipos.
- Visibilidad de los datos: los equipos deben poder descubrir conjuntos de datos y solicitar acceso a ellos.
- Procedencia de los datos: sin un equipo de curación centralizado, los equipos deben poder confiar en el origen de los datos que se introducen en sus productos de analíticas.
Delegar la administración de datos principales
Este diseño es diferente del enfoque de los mercados de datos convencionales, ya que la autoridad descentralizada delega las decisiones de administración de datos principales en subgrupos de componentes de la organización. Si usas una autoridad descentralizada, mantienes el control central de la seguridad y la capacidad de BigQuery mediante Cloud Key Management Service (Cloud KMS), las políticas de columnas, los controles de servicio de VPC y las reservas. Por lo tanto, evitas la dispersión de datos que es habitual en los almacenes autogestionados. En el siguiente diagrama se muestra una arquitectura que usa una autoridad descentralizada:
Imagen 5. Un proyecto de gobernanza principal ayuda a garantizar una seguridad coherente, mientras que los grupos individuales mantienen sus operaciones de datos.
La configuración del proyecto de la figura 5 incluye los siguientes proyectos:
- Proyecto de gobernanza principal: el proyecto responsable de las cuestiones de gestión de toda la organización. En este proyecto, crearás recursos de seguridad, como conjuntos de claves de Cloud KMS y políticas de columnas de Data Catalog. Este proyecto actúa como proyecto de administración de reservas de BigQuery, lo que permite compartir ranuras en toda la organización.
- Proyectos de datos de unidades organizativas: los propietarios de los mercados de datos autogestionados de la organización. El proyecto de gobierno principal gestiona el ámbito restringido de los proyectos de datos de la unidad organizativa.
- Proyectos del equipo de analíticas: los proyectos que usan los consumidores de los mercados de datos. Estos proyectos usan su propia infraestructura y sus propios slots aprovisionados para acceder a los datos del mercado de datos y procesarlos.
Usar un diseño de reserva de dos niveles
Te recomendamos que tus mercados de datos descentralizados utilicen el mismo diseño de dos niveles que los mercados de datos estándar. En esta configuración, asignas al recurso de organización una reserva que tiene un número reducido de ranuras para cubrir el uso general. Si los equipos tienen más necesidades, asigna reservas a nivel de proyecto o carpeta.
Usar un catálogo de datos
Un catálogo de datos proporciona descubrimiento en toda la organización, etiquetado de metadatos y configuración de políticas de columnas. La función de descubrimiento de Dataplex crea automáticamente entradas de metadatos para todas las tablas de BigQuery nuevas de tu organización. Las funciones de Dataplex también ayudan a los administradores de gobierno de datos a identificar rápidamente nuevos recursos de datos y aplicar los controles adecuados.
Configurar perímetros de Controles de Servicio de VPC
En esta configuración, recomendamos usar perímetros de seguridad de Controles de Servicio de VPC para evitar que los conjuntos de datos de BigQuery se expongan accidentalmente fuera de tuGoogle Cloud organización.
Perímetros
En esta configuración, le recomendamos que cree los siguientes perímetros de servicio:
- Datos principales: un perímetro para proteger los conjuntos de datos del almacén de datos y del mercado de datos. Este perímetro debe incluir todos los proyectos de la unidad organizativa y el proyecto de gobierno de datos.
- Analytics: un perímetro para crear e implementar recursos de analíticas internos de la organización. Se espera que este perímetro tenga una política de acceso más permisiva que el perímetro de datos principal con el que se conecta.
Perímetros puente
En esta configuración, te recomendamos que crees los siguientes puentes de perímetro:
- Datos y analíticas principales: permite a los usuarios de los proyectos de analíticas consultar las vistas autorizadas.
Compartir datos entre varias organizaciones
El uso compartido entre varias organizaciones es un aspecto de diseño especial de los mercados de datos. Este diseño de uso compartido de datos está pensado para organizaciones que quieren compartir de forma segura sus conjuntos de datos con otra entidad que tenga su propia organización de Google.
La función para compartir datos entre organizaciones resuelve los siguientes problemas del usuario que comparte los datos:
- Confidencialidad al compartir: solo la parte a la que se dirigen los datos puede acceder a ellos.
- Protección frente a accesos inadecuados: solo se puede acceder externamente a los recursos a los que se pretende acceder.
- Separación de los recursos de computación: se factura a las partes externas por las consultas que inician.
Proteger proyectos internos de proyectos de datos compartidos
El diseño de intercambio de datos entre organizaciones se centra en proteger los proyectos internos de la organización frente a la actividad de los proyectos de datos compartidos. El proyecto de conjunto de datos compartido actúa como un búfer para impedir el acceso al tratamiento de datos internos sensibles, al tiempo que ofrece la posibilidad de compartir datos externamente.
Las consultas que se inician desde el proyecto externo usan los recursos de computación del proyecto que las invoca. Si todos los conjuntos de datos consultados comparten la misma Google Cloud región, estas consultas pueden combinar datos de diferentes organizaciones. En el siguiente diagrama se muestra cómo se comparten los conjuntos de datos en una configuración de proyecto con varias organizaciones:
Imagen 6. Una organización externa consulta datos de varios conjuntos de datos en proyectos compartidos.
La configuración del proyecto de la figura 6 incluye los siguientes proyectos:
- Proyecto interno de la organización: el proyecto que contiene datos internos sensibles. El proyecto interno puede compartir datos externamente copiando datos anonimizados en los conjuntos de datos del proyecto de datos compartidos. El proyecto interno debe ser el propietario de la cuenta de servicio responsable de actualizar los datos compartidos.
- Proyecto de datos compartidos: el proyecto que contiene la información anonimizada que se copia del proyecto interno. Usa grupos de usuarios externos para gestionar el acceso de terceros. En este caso, gestionas la pertenencia a grupos como función administrativa y das a las cuentas externas el permiso de lector para que puedan acceder al conjunto de datos a través de estos grupos.
Configurar perímetros de Controles de Servicio de VPC
En esta configuración, recomendamos usar perímetros de Controles de Servicio de VPC para compartir datos externamente y evitar que los conjuntos de datos de BigQuery se expongan accidentalmente fuera de tus proyectos internos.
Perímetros
En esta configuración, le recomendamos que cree los siguientes perímetros de servicio:
- Datos internos: un perímetro para proteger los recursos de datos principales. Controles de Servicio de VPC aplica el acceso a BigQuery.
- Datos compartidos externamente: un perímetro para alojar conjuntos de datos que se pueden compartir con organizaciones externas. Este perímetro inhabilita la aplicación del acceso a BigQuery.
Perímetros puente
En esta configuración, te recomendamos que crees el siguiente puente de perímetro:
- Datos internos a externos: un puente de perímetro permite que los proyectos de datos internos más protegidos transfieran datos a proyectos de uso compartido de datos externos.
Consideraciones adicionales en sistemas multicliente
En esta sección se analizan en profundidad casos especiales que puedes tener en cuenta junto con las prácticas recomendadas anteriores.
Google Cloud límites y cuotas de recursos
- Las cuentas de servicio tienen una cuota flexible de 100 cuentas de servicio por proyecto. Puedes solicitar cuota a través de la consola Google Cloud para los proyectos que mantengan cuentas de servicio de inquilino.
- La simultaneidad de BigQuery tiene un valor predeterminado de 100 consultas por proyecto que emite consultas (los proyectos que contienen conjuntos de datos no tienen estos límites). Para aumentar esta cuota flexible, ponte en contacto con tu representante de ventas.
- Controles de Servicio de VPC tiene un límite de 10.000 proyectos en toda la organización dentro de los perímetros de servicio. Si los diseños de tu proyecto por cliente tienen una gran escalabilidad, te recomendamos que uses un diseño de conjunto de datos por cliente.
- Controles de Servicio de VPC tiene un límite de 100 perímetros, incluidos los puentes, por organización.
Usar vistas autorizadas o tablas de subconjuntos materializadas
Para gestionar el acceso de los arrendatarios a subconjuntos de tablas de hechos grandes, puede usar vistas autorizadas específicas de los arrendatarios o crear tablas de subconjuntos específicas de los arrendatarios. En la siguiente tabla se comparan estos enfoques:
| Función | Vistas autorizadas | Tablas de subconjuntos |
|---|---|---|
| Número de clientes admitidos | Hay un límite de 2500 recursos autorizados por conjunto de datos. | Entre los recursos autorizados se incluyen las vistas, los conjuntos de datos y las funciones autorizados.No hay límites en el número de conjuntos de datos de un proyecto ni en el número de tablas de un conjunto de datos. |
| Particiones y clústeres |
Las vistas autorizadas deben compartir el esquema de partición y clúster común de la tabla base. Para mejorar el rendimiento de la segmentación de inquilinos, le recomendamos que agrupe la tabla principal por el ID de inquilino. |
Puedes crear particiones en la tabla de subconjuntos y agruparla en clústeres según las necesidades del inquilino. |
| Regionalización | Las vistas autorizadas no pueden abarcar varias regiones y deben estar en la región Google Cloud de la tabla base. La regionalización afecta a los inquilinos geográficamente remotos. | Las tablas de subconjuntos pueden estar en la región más adecuada para el inquilino. Podrían aplicarse costes adicionales. |
| Implementación de políticas de columnas | Las políticas de columnas aplicadas a una tabla base se aplican a todas las vistas autorizadas, independientemente de los permisos de esas vistas. | En cada tabla de subconjunto se debe aplicar la política de columnas para que entre en vigor. |
| Registro de acceso a datos | Los registros de acceso a los datos se reflejan en el registro de la tabla base. | El acceso a cada tabla de subconjunto se registra por separado. |
| Flexibilidad de las transformaciones | Las vistas autorizadas permiten rediseñar al instante el objeto al que acceden los inquilinos. | Para cambiar las tablas de subconjuntos, es necesario hacer cambios de esquema complejos. |
Control de datos sensibles
Para evitar el acceso no autorizado a los datos, BigQuery ofrece varias funciones adicionales además de los permisos estándar de gestión de identidades y accesos.
Cifrado proporcionado por el cliente
El cifrado de datos del cliente abarca los casos en los que una organización de alojamiento almacena y trata datos en nombre de un arrendatario, pero no puede acceder a parte del contenido de los datos. Por ejemplo, es posible que la organización de alojamiento no pueda acceder a datos personales o de dispositivos que se consideren sensibles.
Recomendamos que el remitente de los datos utilice claves de cifrado AEAD de la biblioteca Tink de código abierto para cifrar los datos sensibles. Las claves de encriptado AEAD de la biblioteca Tink son compatibles con las funciones AEAD de BigQuery. El arrendatario puede descifrar los datos accediendo al material de la clave en una UDF autorizada o transfiriendo el material de la clave como un parámetro de consulta a BigQuery, donde la organización host no puede registrar la clave.
Políticas de acceso a columnas
En los mercados de datos multiempresa, las políticas de columnas se usan con frecuencia para evitar que se filtre contenido sensible por error entre equipos que colaboran. Las vistas autorizadas son el mecanismo preferido para compartir datos entre equipos en un escenario de mercado de datos. Las vistas autorizadas no pueden conceder acceso a una columna protegida.
Si aplicas la política para controlar el acceso, impedirás que accedan los usuarios a los que no se les haya concedido el rol de lector detallado. Aunque la política no se aplique, se registrará todo el acceso de los usuarios a la columna categorizada.
Protección de datos sensibles
Protección de Datos Sensibles proporciona APIs y utilidades de análisis que te ayudan a identificar y mitigar el contenido sensible almacenado en conjuntos de datos de BigQuery o Cloud Storage. Las organizaciones que se encuentran en situaciones de multitenencia suelen usar la API DLP (que forma parte de Protección de Datos Sensibles) para identificar y, opcionalmente, tokenizar datos sensibles antes de almacenarlos.
Gestión de reservas de slots
La gestión de reservas en sistemas multiarrendatario ayuda a controlar los costes a medida que los arrendatarios escalan y garantiza el rendimiento de cada arrendatario.
Para gestionar las reservas, te recomendamos que crees un solo proyecto administrativo de reserva. Las confirmaciones de ranuras que se compran en el mismo proyecto administrativo se pueden compartir entre todas las reservas que procedan del proyecto administrativo. Un proyecto que usa compromisos de slots solo se puede asignar a una reserva a la vez. Todas las consultas que proceden de un proyecto comparten ranuras en función de los recursos disponibles.
Para asegurarte de que se cumplen los objetivos de nivel de servicio (SLOs) de los inquilinos, puedes monitorizar las reservas a través de Cloud Logging y el esquema de información de BigQuery. Las organizaciones que experimentan periodos de actividad intensa por parte de los analistas o de trabajos prioritarios pueden asignar capacidad adicional mediante slots flexibles.
Reservas como niveles de computación de inquilino
Los proveedores de SaaS que tienen desde decenas hasta miles de clientes suelen configurar un número finito de reservas de BigQuery como recursos compartidos.
Si es un proveedor de SaaS que ha compartido la infraestructura de los arrendatarios, le recomendamos que dedique cada reserva a un solo proyecto y que agrupe a los arrendatarios para que compartan ese proyecto en los cálculos de BigQuery. Este diseño reduce la sobrecarga administrativa de tener miles de proyectos y reservas adicionales, al tiempo que permite a tu organización asignar una capacidad de espacio mínima necesaria para satisfacer las necesidades de rendimiento previstas de la reserva.
Si la oportunidad del procesamiento de datos ELT es una prioridad, te recomendamos que asignes una reserva para gestionar el procesamiento. Para evitar que se usen ranuras adicionales que podrían utilizarse para cargas de trabajo ad hoc, asigna el valor ignore idle slots a la reserva.
A continuación, se muestra un ejemplo de cómo configurar las reservas como niveles de computación de inquilino:
- Procesamiento de datos: 2000 espacios, se ignoran los inactivos. Esta reserva se ha configurado para cumplir los SLOs de tratamiento de datos.
- Proyectos internos: 1000 espacios, se permite la inactividad. Esta reserva se aplica a los proyectos que se usan para las analíticas internas.Las ranuras se reutilizan si sobran del procesamiento de datos o de los niveles de computación.
- Nivel de computación bajo: 2000 espacios, se ignora el tiempo de inactividad. Esta reserva se aplica a los inquilinos a los que se han asignado pocos recursos. A diferencia del nivel alto, esta reserva ignora los espacios inactivos.
- Nivel de computación alto: 3000 espacios, permite la inactividad. Esta reserva se aplica a los inquilinos que tienen muchos recursos. Para acelerar las consultas, se aplican automáticamente las ranuras inactivas de otras reservas.
Si tus clientes operan en una infraestructura dedicada, te recomendamos que asignes la carpeta o el proyecto designados a la reserva compartida correspondiente.
Reservas por equipo
Cuando trabajas con equipos en un entorno de mercado de datos, te recomendamos que crees una reserva para cada equipo que necesite recursos de computación adicionales. A continuación, asigna esa reserva a la carpeta principal que contiene los proyectos del equipo. Todos los proyectos nuevos de ese equipo usan las franjas de programación justa de la misma asignación de recursos.
A continuación, se muestra un ejemplo de cómo configurar las reservas por equipo:
- Reserva a nivel de organización: 500 espacios, permite la inactividad. Esta reserva se asigna a la organización de nivel superior y proporciona ranuras a cualquier usuario de BigQuery que no utilice un proyecto con una reserva dedicada.
- Procesamiento de datos: 1000 espacios, se ignoran los inactivos. Esta reserva se ha configurado para cumplir los SLOs mínimos de tratamiento de datos.
- Administración de datos principales: 500 espacios, permite la inactividad. Esta reserva se aplica a los proyectos que se usan para la administración interna. Las ranuras se reutilizan si sobran de los niveles de procesamiento de datos o de computación.
- Reservas de procesamiento de Analytics: 500 ranuras, se permite la inactividad. Se trata de una reserva dedicada que se asigna a un equipo de analistas.
Requisitos de alojamiento multirregional
Los requisitos de alojamiento multirregional suelen deberse a la necesidad de reducir la latencia de los datos para los consumidores o de cumplir mandatos normativos.
Los proyectos de Google Cloud se consideran globales y pueden aprovisionar recursos en cualquier región. BigQuery considera que los conjuntos de datos, las políticas de columnas y los compromisos de slots son recursos regionales. Los slots solo pueden acceder a conjuntos de datos de la región local, y las políticas de columnas solo se pueden aplicar a tablas de conjuntos de datos locales. Para usar los precios basados en la capacidad, debes comprar ranuras en cada región que contenga conjuntos de datos.
Para obtener información sobre cómo cumplir los requisitos normativos, ponte en contacto con tu representante de ventas.