Prácticas recomendadas para las cargas de trabajo multiusuario en BigQuery
En este documento, se proporcionan técnicas y prácticas recomendadas para los patrones comunes que se usan en plataformas de datos de múltiples usuarios y data marts empresariales.
Las empresas comerciales, los proveedores de software como servicio (SaaS) y las organizaciones gubernamentales deben alojar de forma segura datos internos y de terceros a través de los límites geográficos y administrativos. BigQuery es una herramienta potente que puede abordar de manera coherente los requisitos de plataformas multiusuario para exabytes de datos y cientos de miles de consumidores de datos en unidades de negocios diferentes. Este documento está dirigido a organizaciones que implementan plataformas multiusuario en BigQuery y desean comprender los controles de acceso y las funciones de administración del rendimiento disponibles.
Los compiladores de plataformas de multiusuario a menudo necesitan equilibrar las consideraciones para los siguientes casos:
- Aislamiento de datos: Implementa controles sólidos para evitar la filtración de datos entre usuarios.
- Rendimiento coherente: configura y propaga reservas de BigQuery para mantener un rendimiento coherente en los usuarios.
- Administración de recursos: Planifica el impacto de las cuotas y los límites.
- Distribución geográfica: Ubica los datos en ubicaciones geográficas designadas y obligatorias. Para problemas relacionados con el cumplimiento, consulta las ofertas de cumplimiento de Google Cloud.
- Auditoría y seguridad: Protege los datos del usuario del acceso inapropiado y el filtrado.
- Administración de costos: asegúrate de que los costos de BigQuery sean coherentes para alojar cada usuario.
- Complejidad operativa: Minimiza la cantidad de variabilidad del sistema que se requiere para alojar usuarios nuevos.
Proveedor de SaaS con infraestructura de usuario compartido
Los proveedores de SaaS que alojan datos de terceros deben garantizar la confiabilidad y el aislamiento de toda su flota de clientes. Esos clientes pueden llegar a ser decenas de miles, y se puede acceder 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 limpio para realizar estadísticas en toda su flota de usuarios.
Un diseño de conjunto de datos por usuario ayuda a mitigar las siguientes preocupaciones que experimenta una organización cuando se escala a miles de usuarios:
- Complejidad administrativa: La cantidad total de proyectos nuevos y recursos de la nube por cliente
- Latencia de extremo a extremo: cómo está actualizada el almacén de datos para los usuarios de estadísticas de clientes múltiples y los usuarios actualizados.
- Expectativas de rendimiento: asegúrate de que el rendimiento del usuario se mantenga dentro de límites aceptables
Configura conjuntos de datos para cada usuario
Dentro de un proyecto dedicado a almacenar datos de clientes, los datos de cada cliente están separados por conjuntos de datos de BigQuery. Dentro de la organización host, usas un segundo proyecto para implementar estadísticas y aprendizaje automático en datos de clientes combinados. Luego, puedes configurar el motor de procesamiento de datos, Dataflow, para realizar una escritura doble de datos entrantes en las tablas internas y específicas de usuarios. La configuración de Dataflow usa tablas completamente escritas en lugar de vistas autorizadas. El uso de tablas completamente escritas permite un control uniforme de la distribución geográfica y ayuda a evitar alcanzar los límites de vistas autorizados cuando se escala la cantidad de usuarios.
La separación de almacenamiento y procesamiento de BigQuery te permite configurar menos proyectos en comparación con almacenes basados en clústeres para manejar problemas como los niveles de servicio y el aislamiento de datos. Cuando no necesites configurar usuarios con recursos de nube dedicados adicionales, te recomendamos que consideres la configuración predeterminada de un conjunto de datos dedicado para cada usuario. En el siguiente diagrama, se muestra una configuración de proyecto de ejemplo en función de este diseño recomendado:
Figura 1. Un número constante de proyectos maneja las necesidades de procesamiento y datos a medida que aumenta la cantidad de usuarios.
La configuración del proyecto en la figura 1 incluye los siguientes proyectos:
- Proyecto de canalización de datos: los componentes de infraestructura principales que reciben, procesan y distribuyen los datos de usuario se empaquetan en un solo proyecto.
- Proyecto de datos de usuario combinado: el proyecto de datos principal que mantiene un conjunto de datos por cliente. Se espera que se acceda a los datos de los usuarios a través de proyectos de nivel de procesamiento.
- Proyectos de desarrollo interno: proyectos que representan los recursos autogestionados que usan los equipos de estadísticas para evaluar los datos del usuario y compilar características nuevas.
- Proyectos de aplicación de usuario final: proyectos que contienen recursos diseñados para interactuar con los usuarios finales. Te recomendamos que uses cuentas de servicio con alcance de usuario para acceder a los conjuntos de datos de usuarios y usar una canalización de compilación sólida y segura a fin de implementar aplicaciones.
- Proyectos de nivel de procesamiento de reserva: los proyectos que asignan la actividad de la consulta de usuario a las reservas de BigQuery.
Comparte reservas
Las reservas en este enfoque se basan en el algoritmo de programación equilibrada que se compila en las reservas de BigQuery. Cada reserva de nivel de procesamiento se asigna a un solo proyecto. Las consultas de usuarios usan ranuras de programación equilibrada que están disponibles para cada proyecto de nivel de procesamiento. Las ranuras que no se usan de cualquier nivel se reutilizan de forma automática en otro nivel. Si una instancia tiene requisitos de tiempo específicos, puedes usar un par de reserva de proyecto dedicado a proporcionar una cantidad exacta de ranuras.
Configura perímetros de Controles del servicio de VPC
En esta configuración, recomendamos perímetros de los Controles del servicio de VPC para evitar una exposición accidental de los conjuntos de datos de usuario fuera de la organización de Google Cloud y evitar la unión de datos no autorizada dentro de la organización.
Perímetros
En esta configuración, te recomendamos que crees los siguientes perímetros de servicio:
- Canalización de datos: un perímetro alrededor de los proyectos de canalización de datos debe aplicar todos los servicios que no necesitan recibir datos de usuario.
- Datos de usuarios: un perímetro alrededor del proyecto de conjunto de datos de usuario y alrededor de los proyectos de procesamiento de BigQuery de usuario. Aplica todos los servicios para evitar el acceso desde fuera de la organización.
- Aplicaciones internas: aplica todos los servicios y usa niveles de acceso para otorgar acceso a los recursos a los equipos de departamentos.
- Aplicaciones externas: un perímetro alrededor de tus aplicaciones de SaaS. Aplica todos los servicios que no sean necesarios para que funcionen las aplicaciones.
Puentes perimetrales
En esta configuración, te recomendamos que crees los siguientes puentes perimetrales:
- Canalización de datos y datos de usuario: Permite que la canalización escriba datos en conjuntos de datos de usuario.
- Canalización de datos y aplicaciones internas: permite que la canalización escriba datos en el conjunto de datos entre clientes.
- Aplicaciones externas y datos de usuario: permiten que las aplicaciones externas consulten datos de usuario.
- Aplicaciones externas y aplicaciones internas: Permite que las aplicaciones externas procesen datos con modelos que desarrollan e implementan las aplicaciones internas.
Proveedor de SaaS con infraestructura de usuario dedicada
En situaciones más complejas, los proveedores de SaaS podrían implementar una infraestructura de procesamiento dedicada para cada usuario. En esta situación, la infraestructura dedicada es responsable de entregar solicitudes de datos de usuario dentro de BigQuery.
Un diseño de infraestructura de usuario dedicado aborda las siguientes inquietudes comunes cuando se implementa una infraestructura para cada usuario junto con BigQuery:
- Responsabilidad de facturación: Haz un seguimiento de los costos de la infraestructura asociados con cada usuario incorporado.
- Latencia de extremo a extremo: cómo está actualizada el almacén de datos para los usuarios y las soluciones de estadísticas entre clientes.
- Expectativas de rendimiento: asegurar que el rendimiento del usuario se mantenga dentro de límites aceptables
Coloca conjuntos de datos con recursos dedicados
Cuando implementas una infraestructura de usuario dedicada, te recomendamos crear una carpeta superior para los proyectos específicos del usuario. Luego, ubica los conjuntos de datos de BigQuery del usuario en proyectos con los recursos dedicados que acceden a esos datos en nombre del usuario. Para minimizar la latencia de extremo a extremo a fin de los datos de usuario, las canalizaciones de Dataflow insertan los datos directamente en los conjuntos de datos de los usuario.
Este diseño controla la distribución y el procesamiento de datos ascendentes, similar al diseño de infraestructura compartida anterior. Sin embargo, los datos de usuarios y las aplicaciones que acceden a ellos se organizan en proyectos específicos de los usuarios (y, de forma opcional, se organizan en carpetas dedicadas a los usuarios) para simplificar la facturación y la administración de recursos. En el siguiente diagrama, se muestra una configuración de proyecto de ejemplo en función de este diseño recomendado:
Figura 2. Un proyecto de canalización de datos maneja datos de un solo usuario de muchos otros proyectos.
La configuración del proyecto en la figura 2 incluye los siguientes proyectos:
- Proyecto de canalización de datos: los componentes de infraestructura principales que reciben, procesan y distribuyen los datos de usuario se incluyen en un solo proyecto.
- Proyectos de usuario exclusivos: Proyectos que contienen todos los recursos de la nube dedicados a un solo usuario, incluidos los conjuntos de datos de BigQuery. Te recomendamos que uses la Administración de identidades y accesos (IAM) para limitar de forma eficaz el permiso de las cuentas y cuentas de servicio que pueden acceder a los conjuntos de datos de clientes.
- Proyectos de estadísticas internas: proyectos que representan los recursos autogestionados que usan los equipos de estadísticas para evaluar los datos de usuario y compilar características nuevas.
- Proyecto de red externa: proyecto que controla y enruta las solicitudes de usuario a sus backends dedicados.
Comparte reservas
Las reservas de este enfoque dependen del algoritmo de programación equilibrada que se incorpora en las reservas de BigQuery. En esta configuración, las reservas de nivel de procesamiento se asignan a cada proyecto de usuario que usa ese nivel. Si una instancia tiene requisitos de tiempo específicos, puedes crear una reserva dedicada para proporcionar una cantidad precisa de ranuras a un proyecto de usuario.
Usa los controles de IAM e inhabilita la creación de claves
Es posible que los perímetros de los Controles del servicio de VPC no sean adecuados para esta situación. Los límites relacionados con el proyecto evitan que una organización use límites perimetrales alrededor de proyectos que interactúan con los proyectos de usuarios. En cambio, te recomendamos que uses controles de IAM estrictos y que inhabilites la creación de claves para ayudar a proteger contra el acceso externo no deseado.
Data mart con autoridad central
Los data marts son un tema de diseño común en el que los datos de estadísticas principales se almacenan en un repositorio central y los subconjuntos se comparten entre las líneas de negocio. Con frecuencia, los data marts tienen decenas o cientos de usuarios, representados como líneas de negocio que deben considerarse.
Un diseño de data mart en BigQuery aborda las siguientes necesidades:
- Colaboración de datos segura: Compartir datos con controles técnicos para minimizar el acceso inapropiado en los equipos.
- Administración de datos centrales: Garantizar que los recursos de datos principales que se usan para los informes críticos de la empresa se estandarizaron y se validen.
- Atribución de costos por unidad de negocios: Realizar un seguimiento y ajustar el uso de cálculos por unidades de negocios.
Usa un repositorio administrado de forma central
En este diseño, los datos principales se capturan en un repositorio administrado de forma central. Las vistas autorizadas, las funciones definidas por el usuario (UDF) autorizadas y las políticas de columnas se usan con frecuencia en conjunto para compartir datos con líneas de negocio y, al mismo tiempo, evitar la distribución accidental de datos sensibles.
Los equipos de proyectos de usuario pueden acceder a los conjuntos de datos administrados de forma central según sus permisos de cuenta. Los equipos usan ranuras asignadas a sus propios proyectos para compilar 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 data mart. En esta configuración, te recomendamos que evites compilar varias capas de vistas sobre los objetos que presenta el proyecto de datos principales. En el siguiente diagrama, se muestra un ejemplo de configuración de proyecto según este diseño recomendado:
Figura 3. Un proyecto de datos principal mantiene un data mar centralizado a la que se puede acceder desde toda la organización.
La configuración del proyecto en la figura 3 incluye los siguientes proyectos:
- Proyecto de datos principales: El perímetro de administración para administrar el acceso a los datos principales y las vistas de data mart. Puedes mantener vistas autorizadas dentro de los conjuntos de datos en este proyecto y otorgar vistas autorizadas a los equipos de estadísticas según la membresía del grupo.
- Extracción, transformación, carga (ETL): infraestructura para procesar fuentes de datos ascendentes en los datos principales. Según las necesidades de separación administrativa, puedes elegir implementar la infraestructura de ETL como su propio proyecto o como parte del proyecto de datos principales.
- Proyectos de equipo de estadísticas: Los consumidores del data mart usan estos proyectos y utilizan su propia infraestructura aprovisionada para procesar datos dentro del data mart. Se espera que los proyectos del equipo de estadísticas puedan compilar conjuntos de datos derivados para uso local.
Usa un diseño de reserva de dos niveles
Cuando trabajes con data marts, te recomendamos que uses un diseño de dos niveles. En un diseño de dos niveles, asigna al recurso de organización una reserva que tiene una pequeña cantidad de ranuras para cubrir el uso general. Si los equipos tienen mayores necesidades, asigna reservas a nivel de proyecto o de carpeta.
Configura perímetros de Controles del servicio de VPC
En esta configuración, recomendamos perímetros de Controles del servicio de VPC para evitar la exposición accidental de conjuntos de datos de BigQuery fuera de tu organización de Google Cloud.
Perímetros
En esta configuración, te recomendamos que crees los siguientes perímetros de servicio:
- Datos principales: Un perímetro para proteger el almacén de datos y los conjuntos de datos de data mart.
- Canalizaciones de datos: Un perímetro del proyecto de infraestructura de ETL Si las canalizaciones de datos necesitan realizar solicitudes fuera de la organización de Google Cloud, te recomendamos que separes este perímetro del perímetro de datos principal.
- Estadísticas: Un perímetro para compilar e implementar elementos de estadísticas que son 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 se conecta.
Puentes perimetrales
En esta configuración, te recomendamos que crees los siguientes puentes perimetrales:
- Canalizaciones de datos y datos principales: Permiten que las canalizaciones de datos escriban en el proyecto de datos principales.
- Datos y estadísticas principales: Permiten que los usuarios de los proyectos de estadísticas consulten las vistas autorizadas.
Copia conjuntos de datos para configuraciones multirregionales
Debido a que BigQuery no permite consultas entre regiones, no puedes usar la estrategia de segmentación de datos con vistas autorizadas cuando los data marts deben existir en varias regiones. En su lugar, puedes usar el Servicio de transferencia de datos de BigQuery para copiar conjuntos de datos relevantes en otra región. En esta situación, crearás políticas de columnas dentro del catálogo de datos para cada región adicional en la que residen los datos. En el siguiente diagrama, se muestra una configuración multirregional:
Figura 4. Una configuración multirregional usa el Servicio de transferencia de datos de BigQuery para copiar conjuntos de datos entre regiones.
La configuración del proyecto en la figura 4 incluye los siguientes proyectos.
- Proyecto de datos principales: El perímetro de administración para administrar el acceso a los datos principales y las vistas de data mart. Los datos se copian y conservan en conjuntos de datos regionales que pueden entregar equipos a todo el mundo.
- Infraestructura de ETL: Infraestructura para procesar fuentes de datos ascendentes en los datos principales. Según las necesidades de separación administrativa, puedes elegir implementar la infraestructura de ETL como su propio proyecto o como parte del proyecto de datos principales.
- Proyectos del equipo de estadísticas: Los consumidores del data mart usan estos proyectos y utilizan su propia infraestructura aprovisionada para procesar datos dentro de conjuntos de datos regionales del data mart. Se espera que los proyectos del equipo de estadísticas puedan compilar conjuntos de datos derivados para uso local.
El Servicio de transferencia de datos de BigQuery es un componente programado adicional, con algunas limitaciones. El programador de servicios integrado está limitado a un tiempo mínimo de intervalo de 15 minutos y debe copiar todas las tablas del conjunto de datos de origen. No hay forma de incorporar secuencias de comandos adicionales para crear subconjuntos de datos específicos de la región en el programador del Servicio de transferencia de datos de BigQuery.
Si tu organización necesita más flexibilidad, las siguientes opciones están disponibles:
- Trabajos de Cloud Composer: Puedes programar trabajos de Cloud Composer para emitir trabajos de ETL que crean subconjuntos regionales antes de activar el Servicio de transferencia de datos de BigQuery a través de su API de cliente. Si tu organización puede admitir latencia adicional, recomendamos esta opción.
- Infraestructura de ETL: La infraestructura de ETL, como Dataflow, puede escribir dos veces subconjuntos regionales en regiones de destino. Si tu organización requiere una latencia de datos mínima entre regiones, te recomendamos esta opción.
Data marts con autoridad descentralizada
Usa la autoridad descentralizada cuando necesites separación administrativa por propietario del sistema, líneas de negocio o preocupaciones geográficas.
Un data mart descentralizado tiene las siguientes preocupaciones en comparación con un data mart estándar:
- Colaboración de datos segura: Compartir datos con controles técnicos para minimizar el acceso inapropiado en los equipos.
- Visibilidad de los datos: Los equipos deben poder descubrir y solicitar acceso a los conjuntos de datos.
- Origen de los datos: Sin un equipo de selección central, los equipos deben poder confiar en el origen de los datos que se incluyen en sus productos de estadísticas.
Delega la administración de datos principales
Este diseño es diferente de un enfoque de data mart convencional porque la autoridad descentralizada delega las decisiones de administración de datos principales a los subgrupos componentes de la organización. Cuando usas la autoridad descentralizada, mantienes el control central de la seguridad y la capacidad de BigQuery mediante Cloud Key Management Service (Cloud KMS), políticas de columnas, Controles del servicio de VPC y reservas. Por lo tanto, evitas la subutilización de datos común en los almacenes autoadministrados. En el siguiente diagrama, se muestra una arquitectura que usa autoridad descentralizada:
Figura 5. Un proyecto de administración principal ayuda a garantizar una seguridad coherente, mientras que los grupos individuales mantienen sus operaciones de datos.
La configuración del proyecto en la figura 5 incluye los siguientes proyectos:
- Proyecto de administración principal: Es el proyecto responsable de las inquietudes de la administración entre organizaciones. En este proyecto, debes crear recursos de seguridad, como las políticas de columnas del Data Catalog y los llaveros de claves de Cloud KMS. Este proyecto actúa como el proyecto de administración de reservas de BigQuery, lo que permite el uso compartido de ranuras en toda la organización.
- Proyectos de datos de unidades organizativas: Los propietarios de data marts autoadministrados dentro de la organización más amplia. El proyecto de administración principal administra el alcance restringido para los proyectos de datos de la unidad organizacional.
- Proyectos del equipo de estadísticas: Los proyectos que usan los consumidores de data marts. Estos proyectos usan sus propias ranuras y infraestructura aprovisionadas para acceder e procesar datos dentro del data mart.
Usa un diseño de reserva de dos niveles
Recomendamos que tus data marts descentralizados usen el mismo diseño de dos niveles que los data marts estándar. En esta configuración, le asignas al recurso de la organización una reserva que tiene una cantidad pequeña de ranuras para cubrir el uso general. Si los equipos tienen mayores necesidades, asigna reservas a nivel de proyecto o de carpeta.
Usa un catálogo de datos
Un catálogo de datos proporciona descubrimiento en toda la organización, etiquetado de metadatos y configuración de la política de columnas. El descubrimiento de Dataplex crea entradas de metadatos automáticamente para todas las tablas nuevas de BigQuery en toda tu organización. Las capacidades de Dataplex también ayudan a los administradores de datos a identificar rápidamente los recursos de datos nuevos y aplicar los controles adecuados.
Configura perímetros de Controles del servicio de VPC
En esta configuración, recomendamos perímetros de Controles del servicio de VPC para evitar la exposición accidental de conjuntos de datos de BigQuery fuera de tu organización de Google Cloud.
Perímetros
En esta configuración, te recomendamos que crees los siguientes perímetros de servicio:
- Datos principales: Un perímetro para proteger el almacén de datos y los conjuntos de datos de data mart. Este perímetro debe incluir todos los proyectos de unidades organizativas y el proyecto de administración de datos.
- Estadísticas: Un perímetro para compilar e implementar elementos de estadísticas 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.
Puentes perimetrales
En esta configuración, te recomendamos que crees los siguientes puentes perimetrales:
- Datos y estadísticas principales: Permiten que los usuarios de los proyectos de estadísticas consulten las vistas autorizadas.
Uso compartido de datos de varias organizaciones
El uso compartido de varias organizaciones es una consideración de diseño especial para un diseño de data mart. Este diseño de uso compartido de datos está dirigido a organizaciones que deseen compartir sus conjuntos de datos de forma segura con otra entidad que tenga su propia organización de Google.
El uso compartido de datos de varias organizaciones aborda las siguientes preocupaciones para el compartidor de datos:
- Confidencialidad de uso compartido: Solo la parte deseada puede acceder a los datos compartidos.
- Protección contra el acceso inapropiado: Solo se puede acceder de forma externa a los recursos a los que se debe acceder.
- Separación de procesamiento: Se facturan las partes externas por las consultas que inician.
Protege proyectos internos de proyectos de datos compartidos
El diseño del uso compartido de datos en varias organizaciones se centra en proteger los proyectos internos de la organización contra la actividad en proyectos de datos compartidos. El proyecto de conjunto de datos compartido actúa como un búfer para inhabilitar el acceso al procesamiento de datos internos sensibles, a la vez que proporciona la capacidad de compartir datos de forma externa.
Las consultas que se inician desde el proyecto externo usan los recursos de procesamiento del proyecto que invoca. Si todos los conjuntos de datos consultados comparten la misma región de Google Cloud, estas consultas pueden unir datos entre organizaciones. En el siguiente diagrama, se muestra cómo se comparten los conjuntos de datos en una configuración de proyecto de varias organizaciones:
Figura 6. Una organización externa consulta datos de varios conjuntos de datos en proyectos compartidos.
La configuración del proyecto en 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 de forma externa mediante la copia de datos limpios en los conjuntos de datos del proyecto de datos compartidos. El proyecto interno debe ser propietario de la cuenta de servicio responsable de actualizar los datos compartidos.
- Proyecto de datos compartidos: el proyecto que contiene la información limpia que se copia del proyecto interno. Usa grupos de usuarios externos para administrar el acceso de terceros. En esta situación, administras la membresía del grupo como una función administrativa y le das a las cuentas externas el permiso de visualizador para que puedan acceder al conjunto de datos a través de estos grupos.
Configura perímetros de Controles del servicio de VPC
En esta configuración, recomendamos perímetros de Controles del servicio de VPC para compartir datos de forma externa y evitar la exposición accidental de conjuntos de datos de BigQuery fuera de los proyectos internos.
Perímetros
En esta configuración, te recomendamos que crees los siguientes perímetros de servicio:
- Datos internos: Un perímetro para proteger los recursos de datos principales Controles del servicio de VPC aplica acceso a BigQuery.
- Datos compartidos de forma externa: 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.
Puentes perimetrales
En esta configuración, te recomendamos que crees los siguientes puentes perimetrales:
- Datos internos a externos: Un puente perimetral permite que los proyectos de datos internos más protegidos exporten datos a proyectos de datos compartidos externos.
Consideraciones adicionales en los sistemas multiusuario
En esta sección, se proporciona una visión más profunda de los casos especiales que puedes considerar junto con las prácticas recomendadas anteriores.
Límites y cuotas de recursos de Google Cloud
- Las cuentas de servicio están limitadas a una cuota inicial de 100 cuentas de servicio por proyecto. Puedes solicitar cuotas a través de la consola de Google Cloud para proyectos que mantienen cuentas de servicio de usuario.
- La simultaneidad de BigQuery tiene una simultaneidad predeterminada de 100 consultas por proyecto que emite consultas (los proyectos que contienen conjuntos de datos no tienen tales límites). Para aumentar esta suave, comunícate con tu representante de ventas.
- Controles del servicio de VPC tiene un límite de 10,000 proyectos dentro de los perímetros de servicio en toda la organización. Si tus diseños de proyecto por usuario tienen un escalamiento vertical alto, recomendamos que uses un diseño de conjunto de datos por usuario.
- Controles del servicio de VPC tiene un límite de 100 perímetros, incluidos los puentes, por organización.
Usa vistas autorizadas o tablas de subconjuntos materializados
Para administrar el acceso de los usuarios a subconjuntos de tablas de datos grandes, puedes usar vistas autorizadas específicas de usuarios o crear tablas de subconjuntos específicas de usuarios. En la siguiente tabla, se proporciona una comparación de estos enfoques:
| Función | Vistas autorizadas | Tablas de subconjuntos |
|---|---|---|
| Cantidad de usuarios admitidos | Existe un límite estricto de 2500 recursos autorizados por conjunto de datos. | Los recursos autorizados incluyen vistas autorizadas, conjuntos de datos autorizados y funciones autorizadas. No hay límites para la cantidad de conjuntos de datos en un proyecto o tablas en un conjunto de datos. |
| Partición y agrupamiento en clústeres |
Las vistas autorizadas deben compartir el esquema de clúster y partición común de la tabla base. Para mejorar el rendimiento de la segmentación de usuarios, recomendamos que agrupes la tabla superior en el ID del usuario. |
Puedes particionar la tabla del subconjunto y agruparla en clústeres según las necesidades del usuario. |
| Regionalización | Las vistas autorizadas no pueden cruzarse entre regiones y deben estar en la región de Google Cloud de la tabla base. La regionalización afecta a los usuarios remotos geográficamente. | Las tablas de subconjuntos pueden existir en la región que sea más apropiada para el usuario. Es posible que se apliquen costos adicionales. |
| Aplicación de la política de columnas | Las políticas de columnas que se aplican a una tabla base se aplican a todas las vistas autorizadas, independientemente de los permisos en esas vistas. | Cada tabla de subconjunto debe aplicar la política de columnas para que tenga efecto. |
| Registro de acceso a los datos | Los registros de acceso a los datos se reflejan en el registro de la tabla base. | El acceso a cada tabla del subconjunto se registra por separado. |
| Flexibilidad de transformación | Las vistas autorizadas permiten el rediseño instantáneo del objeto al que acceden los usuarios. | Se requieren cambios de esquema complejos para cambiar tablas de subconjuntos. |
Controla datos sensibles
Para evitar el acceso no autorizado a los datos, BigQuery ofrece varias características adicionales más allá de los permisos de IAM estándar.
Encriptación proporcionada por el cliente
La encriptación de datos de clientes abarca los casos en los que una organización de hosting almacena y procesa datos en nombre de un usuario, pero se le impide acceder a algunos de los contenidos de datos. Por ejemplo, es posible que la organización de hosting no pueda acceder a datos personales o del dispositivo que se consideran sensibles.
Recomendamos que el remitente de los datos use claves de encriptación AEAD, desde la biblioteca Tink de código abierto, para encriptar datos sensibles. Las claves de encriptación AEAD de la biblioteca Tink son compatibles con las funciones AEAD de BigQuery. Para desencriptar los datos, el usuario puede acceder al material de clave en una UDF autorizada o pasar el material de clave como un parámetro de consulta a BigQuery, donde la organización host no puede registrar la clave.
Políticas de acceso de columnas
En los data marts de varias instancias, las políticas de columnas se usan con frecuencia para evitar que el contenido sensible se filtre entre los equipos colaboradores de forma accidental. Las vistas autorizadas son el mecanismo preferido para compartir datos entre equipos en una situación de data mart. Las vistas autorizadas no pueden otorgar acceso a una columna protegida.
Cuando configuras la política para aplicar el control de acceso, evitas el acceso a los usuarios a los que no se les otorgó el rol fine-grained reader a la política. Incluso cuando la política no se aplica, la política registra todo el acceso de los usuarios a la columna categorizada.
Protección de datos sensibles
La Protección de datos sensibles proporciona API y utilidades de análisis que te ayudan a identificar y mitigar el contenido sensible que se almacena dentro de conjuntos de datos de BigQuery o Cloud Storage. Las organizaciones en situaciones multiusuario suelen usar la API de DLP (parte de la protección de datos sensibles) para identificar y asignar tokens de manera opcional a los datos sensibles antes de que se almacenen.
Administración de reservas de ranuras
La administración de reservas en sistemas de usuarios múltiples ayuda a controlar los costos a medida que los usuarios aumentan su escala y garantiza garantías de rendimiento para cada usuario.
Para administrar las reservas, te recomendamos que crees un solo proyecto administrativo de reservas. Los compromisos de ranuras que se compran dentro del mismo proyecto administrativo se pueden compartir en todas las reservas que se originan en el proyecto administrativo. Un proyecto que usa compromisos de ranuras solo se puede asignar a una reserva a la vez. Todas las consultas que se originan en un proyecto comparten ranuras según los recursos disponibles.
Para garantizar que se cumplan los objetivos de nivel de servicio (SLO) de los usuarios, puedes supervisar las reservas a través de Cloud Logging y el esquema de información de BigQuery. Las organizaciones que tienen períodos de alta actividad de analistas o trabajos prioritarios pueden asignar capacidad adicional mediante ranuras flexibles.
Reservas como niveles de procesamiento de usuario
Por lo general, los proveedores de SaaS que tienen decenas de miles de usuarios configuran una cantidad finita de reservas de BigQuery como recursos compartidos.
Si eres un proveedor de SaaS que tiene una infraestructura de usuarios compartidos, te recomendamos que dediques cada reserva a un solo proyecto y a usuarios grupales para compartirlas con el procesamiento de BigQuery. Este diseño reduce la sobrecarga administrativa de tener miles de proyectos y reservas adicionales, al tiempo que permite que tu organización asigne una capacidad de ranura mínima necesaria para satisfacer las necesidades de rendimiento previstas de la reserva.
Si la puntualidad del procesamiento de datos ELT es una prioridad principal, recomendamos que asignes una reserva para manejar el procesamiento. A fin de evitar el uso de ranuras adicionales que se podrían usar para las cargas de trabajo ad-hoc, configura la reserva a fin de que ignore las ranuras inactivas.
A continuación, se muestra un ejemplo de cómo configurar reservas como niveles de procesamiento de usuario:
- Procesamiento de datos: 2000 ranuras, ignorar inactivas. Esta reserva está configurada para cumplir con los SLO de procesamiento de datos.
- Proyectos internos: 1,000 ranuras; permitir inactivas. Esta reserva se aplica a los proyectos que se usan en las estadísticas internas. Las ranuras se vuelven a usar si quedan en los niveles de procesamiento o procesamiento de datos.
- Nivel de procesamiento bajo: 2000 ranuras, ignorar inactivas. Esta reserva se aplica a los usuarios que tienen pocos recursos. A diferencia del nivel alto, esta reserva ignora las ranuras inactivas.
- Nivel de procesamiento alto: 3000 ranuras, permitir inactivas. Esta reserva se aplica a los usuarios que tienen recursos altos. Para acelerar las consultas, se aplican de forma automática las ranuras inactivas de otras reservas.
Si tus usuarios operan en una infraestructura dedicada, te recomendamos que asignes la carpeta o el proyecto designado a la reserva compartida adecuada.
Reservas por equipo
Cuando trabajes con equipos en una configuración de data mart, te recomendamos crear una reserva para cada equipo que requiera procesamiento adicional. Luego, asigna esa reserva a la carpeta superior que contiene los proyectos del equipo. Todos los proyectos nuevos para ese equipo usan ranuras de programación equilibrada 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 la organización: 500 ranuras, permitir inactivas. Esta reserva se asigna a la organización de nivel superior y le asigna ranuras a cualquier usuario de BigQuery que no use un proyecto que tenga una reserva dedicada.
- Procesamiento de datos: 1000 ranuras, ignorar inactivas. Esta reserva está configurada para cumplir con los SLO de procesamiento mínimo de datos.
- Administración de datos principales: 500 ranuras, permitir inactivas. Esta reserva se aplica a los proyectos que se usan para la administración interna. Las ranuras se reutilizan si quedan libres en los niveles de procesamiento de datos o de procesamiento.
- Reservas de procesamiento de estadísticas: 500 ranuras, permitir inactivas. Esta es una reserva dedicada que se otorga a un equipo de estadísticas.
Requisitos de hosting multirregional
Por lo general, los requisitos de hosting multirregional suelen ser el resultado de una necesidad de reducir la latencia de los datos para los consumidores o cumplir con regulaciones regulatorias.
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 ranuras son recursos regionales. Las ranuras solo pueden acceder a los conjuntos de datos en la región local y las políticas de columna solo pueden aplicarse a las tablas dentro de los conjuntos de datos locales. Para usar precios basados en la capacidad, debes comprar ranuras en cada región que contenga conjuntos de datos.
Para obtener orientación sobre el cumplimiento de los requisitos normativos, consulta con tu representante de ventas.
¿Qué sigue?
- Obtén más información sobre las prácticas recomendadas de IAM.