Organizar recursos de BigQuery

Al igual que otros Google Cloud servicios, los recursos de BigQuery se organizan en una jerarquía. Puedes usar esta jerarquía para gestionar aspectos de tus cargas de trabajo de BigQuery, como permisos, cuotas, reservas de ranuras y facturación.

Jerarquía de recursos

BigQuery hereda la Google Cloud jerarquía de recursos y añade un mecanismo de agrupación adicional llamado conjuntos de datos, que son específicos de BigQuery. En esta sección se describen los elementos de esta jerarquía.

Conjuntos de datos

Los conjuntos de datos son contenedores lógicos que se usan para organizar y controlar el acceso a los recursos de BigQuery. Los conjuntos de datos son similares a los esquemas de otros sistemas de bases de datos.

La mayoría de los recursos de BigQuery que creas (como tablas, vistas, funciones y procedimientos) se crean en un conjunto de datos. Las conexiones y los trabajos son excepciones, ya que están asociados a proyectos en lugar de a conjuntos de datos.

Un conjunto de datos tiene una ubicación. Cuando creas una tabla, los datos de la tabla se almacenan en la ubicación del conjunto de datos. Antes de crear tablas para los datos de producción, piensa en los requisitos de ubicación. Una vez creado un conjunto de datos, no se puede cambiar su ubicación.

Proyectos

Cada conjunto de datos está asociado a un proyecto. Para usar Google Cloud, debes crear al menos un proyecto. Los proyectos son la base para crear, habilitar y usar todos los Google Cloud servicios. Para obtener más información, consulta Jerarquía de recursos. Un proyecto puede contener varios conjuntos de datos, y en el mismo proyecto pueden existir conjuntos de datos con diferentes ubicaciones.

Cuando realizas operaciones en tus datos de BigQuery, como ejecutar una consulta o ingerir datos en una tabla, creas una tarea. Un trabajo siempre está asociado a un proyecto, pero no tiene por qué ejecutarse en el mismo proyecto que contiene los datos. De hecho, un trabajo puede hacer referencia a tablas de conjuntos de datos de varios proyectos. Las tareas de consulta, carga o exportación siempre se ejecutan en la misma ubicación que las tablas a las que hacen referencia.

Cada proyecto tiene una cuenta de facturación de Cloud asociada. Los costes acumulados en un proyecto se facturan a esa cuenta. Si usas los precios bajo demanda, las consultas se facturan al proyecto que las ejecuta. Si usas los precios basados en la capacidad, las reservas de ranuras se facturan al proyecto de administración que se ha usado para comprar las ranuras. El almacenamiento se cobra al proyecto en el que reside el conjunto de datos.

Carpetas

Las carpetas son un mecanismo de agrupación adicional por encima de los proyectos. Los proyectos y las carpetas de una carpeta heredan automáticamente las políticas de acceso de su carpeta principal. Las carpetas se pueden usar para modelar diferentes entidades jurídicas, departamentos y equipos de una empresa.

Organizaciones

El recurso de organización representa a una organización (por ejemplo, una empresa) y es el nodo raíz de laGoogle Cloud jerarquía de recursos.

No necesitas un recurso de organización para empezar a usar BigQuery, pero te recomendamos que crees uno. Si usas un recurso Organization, los administradores pueden controlar de forma centralizada tus recursos de BigQuery, en lugar de que los usuarios controlen los recursos que crean.

En el siguiente diagrama se muestra un ejemplo de la jerarquía de recursos. En este ejemplo, la organización tiene un proyecto dentro de una carpeta. El proyecto está asociado a una cuenta de facturación y contiene tres conjuntos de datos.

Cuestiones importantes

Cuando elija cómo organizar sus recursos de BigQuery, tenga en cuenta lo siguiente:

• Cuotas. Muchas cuotas de BigQuery se aplican a nivel de proyecto. Algunas se aplican a nivel del conjunto de datos. Las cuotas a nivel de proyecto que implican recursos de computación, como las consultas y las tareas de carga, se contabilizan en el proyecto que crea la tarea, en lugar de en el proyecto de almacenamiento.
• Facturación. Si quieres que los distintos departamentos de tu organización usen cuentas de facturación de Cloud diferentes, crea proyectos distintos para cada equipo. Crea las cuentas de facturación de Cloud a nivel de organización y asocia los proyectos a ellas.
• Reservas de slots. Las ranuras reservadas se limitan al recurso de organización. Después de comprar capacidad de ranuras reservadas, puedes asignar un grupo de ranuras a cualquier proyecto o carpeta de la organización, o bien asignar ranuras a todo el recurso Organization. Los proyectos heredan las reservas de slots de su carpeta o organización principal. Las ranuras reservadas están asociadas a un proyecto de administración, que se usa para gestionar las ranuras. Para obtener más información, consulta la página Gestión de cargas de trabajo mediante reservas.

• Permisos Ten en cuenta cómo afecta la jerarquía de permisos a las personas de tu organización que necesitan acceder a los datos. Por ejemplo, si quieres dar acceso a datos específicos a todo un equipo, puedes almacenar esos datos en un solo proyecto para simplificar la gestión del acceso.

  Las tablas y otras entidades heredan los permisos de su conjunto de datos principal. Los conjuntos de datos heredan los permisos de sus entidades superiores en la jerarquía de recursos (proyectos, carpetas y organizaciones). Para realizar una operación en un recurso, un usuario necesita los permisos pertinentes en el recurso y también permiso para crear un trabajo de BigQuery. El permiso para crear un trabajo está asociado al proyecto que se utiliza para ese trabajo.

Patrones

En esta sección se presentan dos patrones habituales para organizar los recursos de BigQuery.

• Un lago de datos central y mercados de datos departamentales. La organización crea un proyecto de almacenamiento unificado para alojar sus datos sin procesar. Los departamentos de la organización crean sus propios proyectos de mercado de datos para realizar análisis.

• Data lakes de departamentos y almacén de datos central. Cada departamento crea y gestiona su propio proyecto de almacenamiento para alojar los datos sin procesar de ese departamento. A continuación, la organización crea un proyecto de almacén de datos central para el análisis.

Cada enfoque tiene sus ventajas e inconvenientes. Muchas organizaciones combinan elementos de ambos patrones.

Lago de datos central y data marts de departamentos

En este patrón, se crea un proyecto de almacenamiento unificado para alojar los datos sin procesar de la organización. Tu canalización de ingestión de datos también puede ejecutarse en este proyecto. El proyecto de almacenamiento unificado actúa como un data lake para tu organización.

Cada departamento tiene su propio proyecto, que utiliza para consultar los datos, guardar los resultados de las consultas y crear vistas. Estos proyectos a nivel de departamento actúan como mercados de datos. Están asociados a la cuenta de facturación del departamento.

Estas son algunas de las ventajas de esta estructura:

• Un equipo de ingeniería de datos centralizado puede gestionar la canalización de ingestión en un solo lugar.
• Los datos sin procesar están aislados de los proyectos a nivel de departamento.
• Con el modelo de precios bajo demanda, la facturación de las consultas en ejecución se carga al departamento que ejecuta la consulta.
• Con los precios basados en la capacidad, puedes asignar ranuras a cada departamento en función de sus necesidades de computación previstas.
• Cada departamento está aislado de los demás en cuanto a las cuotas a nivel de proyecto.

Cuando se usa esta estructura, los permisos habituales son los siguientes:

• El equipo central de ingeniería de datos tiene los roles Editor de datos de BigQuery y Usuario de tareas de BigQuery en el proyecto de almacenamiento. De esta forma, pueden ingerir y editar datos en el proyecto de almacenamiento.
• Los analistas del departamento tienen asignado el rol Lector de datos de BigQuery para conjuntos de datos específicos del proyecto de lago de datos central. De esta forma, pueden consultar los datos, pero no actualizarlos ni eliminarlos.
• Los analistas del departamento también tienen asignados los roles Editor de datos de BigQuery y Usuario de tareas en el proyecto de mercado de datos de su departamento. De esta forma, pueden crear y actualizar tablas en su proyecto, así como ejecutar trabajos de consulta para transformar y agregar los datos con el fin de usarlos en el departamento correspondiente.

Para obtener más información, consulta Funciones y permisos básicos.

Lagos de datos de departamentos y almacén de datos central

En este patrón, cada departamento crea y gestiona su propio proyecto de almacenamiento, que contiene los datos sin procesar de ese departamento. Un proyecto de almacén de datos central almacena agregaciones o transformaciones de los datos sin procesar.

Los analistas pueden consultar y leer los datos agregados del proyecto de almacén de datos. El proyecto de almacén de datos también proporciona una capa de acceso para las herramientas de inteligencia empresarial (BI).

Estas son algunas de las ventajas de esta estructura:

• Es más sencillo gestionar el acceso a los datos a nivel de departamento si se usan proyectos independientes para cada departamento.
• Un equipo de analíticas centralizado tiene un solo proyecto para ejecutar trabajos de analíticas, lo que facilita la monitorización de las consultas.
• Los usuarios pueden acceder a los datos desde una herramienta de BI centralizada, que se mantiene aislada de los datos sin procesar.
• Los analistas y las herramientas externas pueden asignar ranuras al proyecto de almacén de datos para gestionar todas las consultas.

Cuando se usa esta estructura, los permisos habituales son los siguientes:

• Los ingenieros de datos tienen los roles Editor de datos de BigQuery y Usuario de tareas de BigQuery en el mercado de datos de su departamento. Estos roles les permiten ingerir y transformar datos en su mercado de datos.
• Los analistas tienen los roles Editor de datos de BigQuery y Usuario de tareas de BigQuery en el proyecto de almacén de datos. Estos roles les permiten crear vistas agregadas en el almacén de datos y ejecutar tareas de consulta.
• Las cuentas de servicio que conectan BigQuery con herramientas de BI tienen asignado el rol Lector de datos de BigQuery en conjuntos de datos específicos, que pueden contener datos sin procesar del lago de datos o datos transformados del proyecto del almacén de datos.

Para obtener más información, consulta Funciones y permisos básicos.

También puedes usar funciones de seguridad como las vistas autorizadas y las funciones definidas por el usuario (UDFs) autorizadas para que determinados usuarios puedan acceder a los datos agregados sin tener permiso para ver los datos sin procesar de los proyectos de mercado de datos.

Esta estructura de proyecto puede dar lugar a muchas consultas simultáneas en el proyecto de almacén de datos. Por lo tanto, es posible que alcances el límite de consultas simultáneas. Si adoptas esta estructura, te recomendamos que aumentes el límite de cuota del proyecto. También puedes usar la facturación basada en la capacidad para comprar un conjunto de ranuras con las que ejecutar las consultas.