Guía del usuario de Data Mesh

Data Mesh for Cortex Framework extiende la base de datos para habilitar la administración de datos, la visibilidad y el control de acceso a través de los metadatos de BigQuery y Dataplex. Para implementar esto, se proporciona un conjunto básico de recursos de metadatos y anotaciones de recursos de BigQuery que se pueden personalizar y, de manera opcional, implementar junto con la base de datos. Estas especificaciones básicas proporcionan una configuración personalizada que es la base de metadatos para complementar la base de datos de Cortex Framework. Consulta los conceptos de Data Mesh antes de continuar con esta guía.

Los pasos que se describen en esta página están diseñados específicamente para configurar la malla de datos para Cortex Framework. Busca los archivos de configuración de Data Mesh dentro de las carpetas específicas de cada carga de trabajo en la sección de directorios de Data Mesh.

Advertencia: Es posible que esta guía de Data Mesh cambie con el tiempo. Comunícate con el equipo de Cortex si tienes comentarios o problemas relacionados.

Figura 1. Arquitectura de malla de datos para Cortex Framework.

Diseño

La malla de datos de Cortex está diseñada de manera similar a la base de datos general y consiste en tres fases con diferentes subcomponentes que administran Cortex o los usuarios:

1. Actualización de las especificaciones de recursos básicos: Con cada versión, Cortex actualiza las especificaciones de recursos básicos, lo que proporciona una base de metadatos estandarizada para Data Mesh.
2. Personalización de las especificaciones de recursos: Antes de la implementación, los usuarios pueden adaptar las especificaciones de los recursos para que se alineen con sus casos de uso y requisitos específicos.
3. Implementación y actualizaciones de Data Mesh: Los usuarios pueden habilitar Data Mesh en el archivo de configuración de Cortex. Se implementa después de los activos de datos durante la implementación de Cortex. Además, los usuarios tienen la flexibilidad de implementar el entramado de datos de forma independiente para realizar más actualizaciones.

Figura 2: Diseño de malla de datos para Cortex Framework.

Directorios de Data Mesh

Busca los archivos de configuración básicos de Data Mesh para cada carga de trabajo y fuente de datos en las siguientes ubicaciones. Ten en cuenta que los directorios contienen una estructura de archivo diferente, pero todas las especificaciones se encuentran de manera similar en la carpeta config.

Carga de trabajo	Fuente de datos	Ruta de acceso del directorio
Operacional	SAP ECC	src/SAP/SAP_REPORTING/config/ecc
	SAP S/4 HANA	src/SAP/SAP_REPORTING/config/s4
	Salesforce Sales Cloud (SFDC)	src/SFDC/config
	Oracle EBS	src/OracleEBS/config
Marketing	CM360	src/marketing/src/CM360/config
	Google Ads	src/marketing/src/GoogleAds/config
	Meta	src/marketing/src/Meta/config
	Marketing Cloud de Salesforce (SFMC)	src/marketing/src/SFMC/config
	TikTok	src/marketing/src/TikTok/config
	YouTube (con DV360)	src/marketing/src/DV360/config
	Google Analytics 4	src/marketing/src/GA4/config

Nota: Data Mesh no admite LiveRamp ni datos de Dun & Bradstreet (ESG).

Los recursos de metadatos se definen a nivel de la fuente de datos con un solo archivo YAML por proyecto de Google Cloud y contienen una lista de todos los recursos. Los usuarios pueden extender el archivo existente o crear archivos YAML adicionales que contengan specificaciones de recursos adicionales dentro de ese directorio si es necesario.

Las anotaciones de activos se definen a nivel del activo y contienen muchos archivos YAML en el directorio con una sola anotación por archivo.

Habilita las APIs y verifica los permisos

Modificar los valores predeterminados de Data Mesh te permite implementar funciones más allá de las descripciones. Si necesitas modificar los valores predeterminados de Data Mesh en config.json para implementar funciones más allá de las descripciones, asegúrate de que las APIs necesarias y los permisos de confirmación estén configurados como se describe en la siguiente tabla. Cuando implementes Data Mesh con la base de datos, otorga permisos al usuario que realiza la implementación o a la cuenta de Cloud Build. Si la implementación involucra proyectos de origen y destino diferentes, asegúrate de que estas APIs y permisos estén habilitados en ambos proyectos donde se empleen esas funciones.

Función	Roles de permisos	Documentación
Acceso a recursos y filas de BigQuery	Propietario de datos de BigQuery	Para obtener más información, consulta Roles requeridos para los roles de activos y Permisos requeridos para los roles de filas.
Acceso a columnas de BigQuery	Administrador de etiquetas de políticas	Para obtener más información, consulta la documentación sobre Roles usados con el control de acceso a nivel de columna y Restringe el acceso con el control de acceso a nivel de columna.
Etiquetas de catálogo	Propietario de TagTemplate de DataCatalog	Para obtener más información, consulta Etiqueta una tabla de BigQuery con Data Catalog y la documentación de IAM de Data Catalog.
Lakes de Dataplex	Editor de Dataplex	Para obtener más información, consulta la documentación sobre cómo crear un lago.

Nota: Cortex Data Mesh no requiere la integración de las APIs de Dataproc ni de Dataproc Metastore.

Información sobre las especificaciones de recursos básicos

La interfaz principal para configurar Data Mesh para Cortex es a través de las especificaciones de recursos básicos, que son un conjunto de archivos YAML proporcionados de forma predeterminada que definen los recursos de metadatos y las anotaciones que se implementan. Las especificaciones básicas proporcionan recomendaciones iniciales y ejemplos de sintaxis, pero están diseñadas para personalizarse aún más para satisfacer las necesidades de los usuarios. Estas especificaciones se dividen en dos categorías:

• Recursos de metadatos que se pueden aplicar a varios recursos de datos. Por ejemplo, las Plantillas de etiquetas de catálogo que definen cómo se pueden etiquetar los recursos con dominios de la empresa.
• Anotaciones que especifican cómo se aplican los recursos de metadatos a un recurso de datos en particular. Por ejemplo, una etiqueta de catálogo que asocia una tabla específica al dominio de Ventas.

En las siguientes secciones, se te guiará a través de ejemplos básicos de cada tipo de especificación y se explicará cómo personalizarlos. Las especificaciones básicas están etiquetadas con ## CORTEX-CUSTOMER, donde se deben modificar para adaptarse a una implementación si está habilitada la opción de implementación asociada. Para usos avanzados, consulta la definición canónica de estos esquemas de especificaciones en src/common/data_mesh/src/data_mesh_types.py.

Recursos de metadatos

Los recursos de metadatos son entidades compartidas que existen dentro de un proyecto y que se pueden aplicar a muchos recursos de datos. La mayoría de las especificaciones incluyen un campo display_name sujeto a los siguientes criterios:

• Solo contiene letras Unicode, números (0-9), guiones bajos (_), guiones (-) y espacios ( ).
• No puede comenzar ni terminar con espacios.
• La longitud máxima es de 200 caracteres.

En algunos casos, display_name también se usa como un ID, lo que podría introducir requisitos adicionales. En esos casos, se incluyen vínculos a la documentación canónica.

Si la implementación hace referencia a recursos de metadatos en diferentes proyectos de origen y de destino, debe haber una especificación definida para cada proyecto. Por ejemplo, Cortex Salesforce (SFDC) contiene dos especificaciones de Lake. Uno para las zonas sin procesar y de los CDC, y otro para los informes.

Lakes de Dataplex

Los lakes, las zonas y los recursos de Dataplex se usan para organizar los datos desde una perspectiva de ingeniería. Los lakes tienen un region y las zonas tienen un location_type, ambos relacionados con la ubicación de Cortex (config.json > location). La ubicación de Cortex define dónde se almacenan los conjuntos de datos de BigQuery y puede ser de una sola región o multirregional. La zona location_type debe establecerse en SINGLE_REGION | MULTI_REGION para que coincida. Sin embargo, las regiones de Lake siempre deben ser una sola región. Si la ubicación de Cortex y la zona location_type son multirregionales, selecciona una sola región dentro de ese grupo para la región de Lake.

• Requisitos
  • El display_name del lago se usa como lake_id y debe cumplir con los requisitos oficiales. Esto también sucede con los elementos display_name de zona y recurso. Los IDs de zona deben ser únicos en todos los lagos del proyecto.
  • Las especificaciones de Lake deben estar asociadas con una sola región.
  • asset_name debe coincidir con el ID del conjunto de datos de BigQuery, pero display_name puede ser una etiqueta más fácil de usar.
• Limitaciones
  • Dataplex solo admite el registro de conjuntos de datos de BigQuery en lugar de tablas individuales como recursos de Dataplex.
  • Un activo solo se puede registrar en una sola zona.
  • Dataplex solo se admite en ciertas ubicaciones. Para obtener más información, consulta Ubicaciones de Dataplex.

Consulta el siguiente ejemplo en lakes.yaml.

Estos recursos se definen en archivos YAML que especifican data_mesh_types.Lakes.

Plantillas de etiquetas de catálogo

Las plantillas de etiquetas de Data Catalog se pueden usar para agregar contexto a las tablas de BigQuery o a columnas individuales. Te ayudan a categorizar y comprender tus datos desde una perspectiva técnica y empresarial de una manera que está integrada en las herramientas de búsqueda de Dataplex. Definen los campos específicos que puedes usar para etiquetar tus datos y el tipo de información que puede contener cada campo (por ejemplo, texto, número, fecha). Las etiquetas de catálogo son instancias de las plantillas con valores de campo reales.

El campo de plantilla display_name se usa como el ID de campo y debe cumplir con los requisitos de TagTemplate.fields especificados en Class TagTemplate. Para obtener más información sobre los tipos de campos admitidos, consulta Tipos de campos de Data Catalog.

Cortex Data Mesh crea todas las plantillas de etiquetas como de lectura pública. También introduce un concepto level adicional a las especificaciones de la plantilla de etiquetas, que define si se debe aplicar una etiqueta a un activo completo, a campos individuales dentro de un activo o a ambos, con los valores posibles: ASSET | FIELD | ANY. Si bien esto no se aplica estrictamente en este momento, las verificaciones de validación futuras podrían garantizar que las etiquetas se apliquen en el nivel adecuado durante la implementación.

Consulta el siguiente ejemplo.

Las plantillas se definen en archivos YAML que especifican data_mesh_types.CatalogTagTemplates.

Las etiquetas de catálogo son instancias de las plantillas y se analizan a continuación en las Anotaciones de activos.

Control de acceso a nivel de recursos y columnas con plantillas de etiquetas

Cortex Framework permite habilitar el control de acceso a nivel de recurso o columna en todos los artefactos asociados con una plantilla de etiqueta de catálogo. Por ejemplo, si los usuarios desean otorgar acceso a los recursos según la línea de negocio, pueden crear asset_policies para la plantilla de etiquetas de catálogo line_of_business con diferentes principales especificados para cada dominio de la empresa. Cada política acepta filters, que se puede usar para hacer coincidir solo etiquetas con valores específicos. En este caso, podríamos hacer coincidir los valores de domain. Ten en cuenta que estos filters solo admiten la coincidencia de igualdad y ningún otro operador. Si se enumeran varios filtros, los resultados deben satisfacer todos los filtros (por ejemplo, filter_a AND filter_b). El conjunto final de políticas de activos es la unión de las que se definen directamente en las anotaciones y las de las políticas de plantillas.

El control de acceso a nivel de columna con etiquetas de catálogo se comporta de manera similar, ya que aplica etiquetas de política en los campos que coinciden. Sin embargo, como solo se puede aplicar una etiqueta de política a una columna, la prioridad es la siguiente:

1. Etiqueta de política directa: Si se define una etiqueta de política directamente en la anotación de la columna, esta tiene prioridad.
2. Política de plantilla de etiqueta coincidente: De lo contrario, el acceso se determina según la primera política de coincidencia definida en un campo dentro de la plantilla de etiqueta de catálogo asociada.

Cuando uses esta función, te recomendamos que habilites o inhabilites la implementación de etiquetas de catálogo y listas de control de acceso (LCA) juntos. Esto garantiza que las ACL se implementen correctamente.

Para comprender las especificaciones de esta función avanzada, consulta las definiciones de los parámetros asset_policies y field_policies en data_mesh_types.CatalogTagTemplate.

Glosario del catálogo

El glosario es una herramienta que se puede usar para proporcionar un diccionario de términos que usan columnas específicas dentro de los recursos de datos que podrían no ser de uso general. Los usuarios pueden agregar términos de forma manual en la consola, pero no hay compatibilidad con las especificaciones de recursos.

Taxonomías y etiquetas de políticas

Las taxonomías y etiquetas de políticas permiten un control de acceso a nivel de columna sobre los recursos de datos sensibles de una manera estandarizada. Por ejemplo, podría haber una taxonomía para las etiquetas que controlan los datos de PII en una línea de negocio en particular, en la que solo ciertos grupos pueden leer datos enmascarados, datos no enmascarados o no tener acceso de lectura.

Para obtener más detalles sobre las taxonomías y etiquetas de las políticas, consulta la documentación de Introducción al enmascaramiento de datos de columnas. Las siguientes secciones son particularmente relevantes:

• Los roles interactúan
• Herencia de autorización
• Reglas de enmascaramiento y jerarquía
• Prácticas recomendadas para las etiquetas de políticas

Cortex Framework proporciona etiquetas de políticas de muestra para demostrar cómo se especifican y los posibles usos. Sin embargo, los recursos que afectan el control de acceso no están habilitados en la implementación de Data Mesh de forma predeterminada.

Consulta el siguiente ejemplo.

Las taxonomías de políticas se definen en archivos YAML que especifican data_mesh_types.PolicyTaxonomies.

Anotaciones de activos

Las anotaciones especifican los metadatos aplicables a un recurso en particular y pueden hacer referencia a los recursos de metadatos compartidos que se definieron. Entre las anotaciones, se incluyen las siguientes:

• Descripciones de los activos
• Descripciones de los campos
• Etiquetas de catálogo
• Control de acceso a nivel de activos, filas y columnas

Nota: Si modificas un archivo de anotación, ten en cuenta que la consola solo renderiza líneas nuevas en las descripciones como espacios en blanco.

La base de datos de Cortex Framework ofrece anotaciones (descripciones) preconfiguradas para las siguientes cargas de trabajo.

• SAP ECC (sin procesar, CDC y generación de informes)
• SAP S4 HANA (sin procesar, CDC y generación de informes)
• SFDC (solo informes)
• Oracle EBS (solo informes)
• CM360 (solo informes)
• Google Ads (solo informes)
• Meta (solo informes)
• SFMC (solo informes)
• TikTok (solo informes)
• YouTube (con DV360) (solo informes)
• Google Analytics 4 (solo informes)

Consulta el siguiente ejemplo.

Las anotaciones se definen en archivos YAML que especifican data_mesh_types.BqAssetAnnotation.

Etiquetas de catálogo

Las etiquetas de catálogo son instancias de las plantillas definidas en las que se asignan valores de campo que se aplican al activo específico. Asegúrate de asignar valores que coincidan con los tipos de campo declarados en la plantilla asociada.

Los valores de TIMESTAMP deben estar en uno de los siguientes formatos:

  "%Y-%m-%d %H:%M:%S%z"
  "%Y-%m-%d %H:%M:%S"
  "%Y-%m-%d"

Consulta el siguiente ejemplo.

Consulta la definición de especificaciones en data_mesh_types.CatalogTag.

Especifica lectores y principales de la política de acceso

Controla el acceso a tus datos de BigQuery en Cortex Framework con políticas de acceso. Estas políticas definen quién (principales) puede acceder a recursos de datos específicos, filas dentro de un recurso o incluso columnas individuales. Los principales deben seguir un formato específico definido por el miembro de vinculación de políticas de IAM.

Acceso a nivel del activo

Puedes otorgar acceso a todos los recursos de BigQuery con varios permisos:

• READER: Consulta los datos en el recurso.
• WRITER: Modifica y agrega datos al recurso.
• OWNER : Control total sobre el recurso, incluida la administración del acceso.

Estos permisos son equivalentes a la sentencia GRANT DCL en SQL.

A diferencia del comportamiento de la mayoría de los recursos y las anotaciones, la marca de reemplazo no quita los principales existentes con el rol OWNERS. Cuando se agregan propietarios nuevos con la opción de reemplazo habilitada, solo se agregan a los propietarios existentes. Esta es una protección para evitar la pérdida de acceso no deseada. Para quitar propietarios de recursos, usa la consola. La anulación quita los principales existentes con el rol READER o WRITER.

Consulta el siguiente ejemplo.

Consulta la definición de especificaciones en data_mesh_types.BqAssetPolicy.

Acceso a nivel de las filas

Puedes otorgar acceso a conjuntos de filas según ciertos filtros de valores de columna. Cuando especifiques la política de acceso de fila, la cadena de filtro proporcionada se insertará en un CREATE DDL statement. Si se habilita la marca overwrite, se descartan todas las políticas de acceso de fila existentes antes de aplicar las nuevas.

Ten en cuenta lo siguiente sobre el acceso a nivel de fila:

• Si agregas políticas de acceso de fila, los usuarios que no se especifiquen en esas políticas no tendrán acceso para ver ninguna fila.
• Las políticas de fila solo funcionan con tablas, no con vistas.
• Evita usar columnas particionadas en los filtros de tu política de acceso de fila. Consulta el archivo YAML de configuración de informes asociado para obtener información sobre el tipo de activo y las columnas particionadas.

Para obtener más información sobre las políticas de acceso a nivel de las filas, consulta las prácticas recomendadas de seguridad a nivel de las filas.

Consulta el siguiente ejemplo.

Consulta la definición de especificaciones en data_mesh_types.BqRowPolicy.

Acceso a nivel de columna

Para habilitar el acceso a nivel de la columna, anota campos individuales con una etiqueta de política identificada por el nombre de la etiqueta de política y el nombre de la taxonomía. Actualiza el recurso de metadatos de la etiqueta de política para configurar el control de acceso.

Consulta el siguiente ejemplo.

Consulta la definición de especificaciones en data_mesh_types.PolicyTagId.

Implementa la malla de datos

La malla de datos se puede implementar como parte de la implementación de la base de datos o por sí sola. En cualquier caso, usa el archivo config.json de Cortex para determinar las variables relevantes, como los nombres de los conjuntos de datos de BigQuery y las opciones de implementación. De forma predeterminada, la implementación de Data Mesh no quitará ni reemplazará ningún recurso o anotación existentes para evitar pérdidas no intencionales. Sin embargo, también es posible reemplazar los recursos existentes cuando se implementan por sí solos.

Opciones de implementación

Las siguientes opciones de implementación se pueden habilitar o inhabilitar según las necesidades del usuario y las restricciones de inversión en config.json > DataMesh.

Nota: Te recomendamos que el control de acceso se realice únicamente a través de estas especificaciones de recursos si deployACLs está habilitado. Esto evita la adición o eliminación accidental de accesos.

Opción	Notas
deployDescriptions	Esta es la única opción habilitada de forma predeterminada y, además, implementa anotaciones de BigQuery con descripciones de recursos y columnas. No requiere habilitar ninguna API ni permiso adicional.
deployLakes	Implementa lakes y zonas.
deployCatalog	Implementa los recursos de la plantilla de catálogo y sus etiquetas asociadas en las anotaciones de activos.
deployACLs	Implementa recursos de la taxonomía de políticas y políticas de control de acceso a nivel de activos, filas y columnas a través de anotaciones de activos. Los registros contienen mensajes que indican cómo cambiaron las políticas de acceso.

Implementación con Data Foundation

De forma predeterminada, config.json > deployDataMesh habilita la implementación de las descripciones de los activos de Data Mesh al final de cada paso de compilación de la carga de trabajo. Esta configuración predeterminada no requiere habilitar ninguna API o rol adicional. Las funciones adicionales de Data Mesh se pueden implementar con la base de datos habilitando las opciones de implementación, las APIs y los roles requeridos, y modificando las especificaciones de recursos asociadas.

Implementación en solitario

Para implementar solo la malla de datos, los usuarios pueden usar el archivo common/data_mesh/deploy_data_mesh.py. Esta utilidad se usa durante los procesos de compilación para implementar el entramado de datos una carga de trabajo a la vez, pero cuando se llama directamente, también se puede usar para implementar varias cargas de trabajo a la vez. Las cargas de trabajo para las especificaciones que se implementarán deben estar habilitadas en el archivo config.json. Por ejemplo, asegúrate de que deploySAP=true si implementas Data Mesh para SAP.

Para asegurarte de que la implementación se realice con los paquetes y las versiones requeridos, puedes ejecutar la utilidad desde la misma imagen que usa el proceso de implementación de Cortex con los siguientes comandos:

  # Run container interactively
  docker container run -it gcr.io/kittycorn-public/deploy-kittycorn:v2.0

  # Clone the repo
  git clone https://github.com/GoogleCloudPlatform/cortex-data-foundation

  # Navigate into the repo
  cd cortex-data-foundation

Para obtener ayuda con los parámetros disponibles y su uso, ejecuta el siguiente comando:

  python src/common/data_mesh/deploy_data_mesh.py -h

El siguiente es un ejemplo de invocación para SAP ECC:

  python src/common/data_mesh/deploy_data_mesh.py \
    --config-file config/config.json \
    --lake-directories \
        src/SAP/SAP_REPORTING/config/ecc/lakes \
    --tag-template-directories \
        src/SAP/SAP_REPORTING/config/ecc/tag_templates \
    --policy-directories \
        src/SAP/SAP_REPORTING/config/ecc/policy_taxonomies \
    --annotation-directories \
        src/SAP/SAP_REPORTING/config/ecc/annotations

Consulta la sección Directorios de Data Mesh para obtener información sobre las ubicaciones de los directorios.

Reemplazar

Advertencia: Lee esta sección en detalle antes de usar la opción de reemplazo.

De forma predeterminada, la implementación de Data Mesh no reemplazará ningún recurso ni anotación existentes. Sin embargo, la marca --overwrite se puede habilitar cuando se implementa solo Data Mesh para cambiar la implementación de las siguientes maneras.

Si reemplazas recursos de metadatos, como lagos, plantillas de etiquetas de catálogo y etiquetas de políticas, se borrarán los recursos existentes que compartan los mismos nombres. Sin embargo, no se modificarán los recursos existentes con nombres diferentes. Esto significa que, si se quita por completo una especificación de recursos del archivo YAML y, luego, se vuelve a implementar la malla de datos con la opción de reemplazo habilitada, esa especificación de recursos no se borrará porque no habrá una colisión de nombres. Esto se hace para que la implementación de Cortex Data Mesh no afecte los recursos existentes que podrían estar en uso.

En el caso de los recursos anidados, como lagos y zonas, si se reemplaza un recurso, se quitan todos sus recursos secundarios. Por ejemplo, si reemplazas un lake, también se quitan sus zonas y referencias de recursos existentes. En el caso de las Plantillas de etiquetas de catálogo y las Etiquetas de políticas que se reemplazan, las referencias de anotaciones asociadas existentes también se quitan de los activos. Si reemplazas las etiquetas de catálogo en una anotación de activo, solo se reemplazarán las instancias existentes de las etiquetas de catálogo que comparten la misma plantilla.

Las anulaciones de descripciones de activos y campos solo se aplican si hay una descripción nueva válida que no esté vacía, siempre que entre en conflicto con la descripción existente.

Por otro lado, las ACL se comportan de manera diferente. Si reemplazas las ACL, se quitan todos los principales existentes (excepto los propietarios a nivel del recurso). Esto se debe a que las principales que se omiten de las políticas de acceso son igual de importantes para las principales a las que se les otorga acceso.

Explora la malla de datos

Después de implementar la malla de datos, los usuarios pueden buscar y ver los recursos de datos con Data Catalog. Esto incluye la capacidad de descubrir recursos según los valores de la etiqueta del catálogo que se aplicaron. Los usuarios también pueden crear y aplicar términos del Glosario del catálogo manualmente si es necesario.

Las políticas de acceso que se implementaron se pueden ver en la página de esquemas de BigQuery para ver las políticas aplicadas a un activo en particular en cada nivel.

Linaje de datos

Es posible que a los usuarios les resulte útil habilitar y visualizar el linaje entre los recursos de BigQuery. También se puede acceder a Lineage de manera programática a través de la API. El linaje de datos solo admite el linaje a nivel del activo. El linaje de datos no está entrelazado con Cortex Data Mesh, pero es posible que se presenten funciones nuevas en el futuro que utilicen el linaje.

Para cualquier solicitud de Cortex Data Mesh o Cortex Framework, ve a la sección de asistencia.