Guía del usuario de la malla de datos

Data Mesh para Cortex Framework extiende la base de datos para habilitar la administración, la detección y el control de acceso de los datos a través de los metadatos de BigQuery y el catálogo universal de Dataplex. Esto se implementa proporcionando 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 son la base de los 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 Data Mesh para Cortex Framework. Busca los archivos de configuración de Data Mesh en las carpetas específicas de cada carga de trabajo en la sección de directorios de Data Mesh.

Diseño

La malla de datos de Cortex se diseñó de manera similar a la base de datos general y consta de tres fases con diferentes subcomponentes administrados por Cortex o los usuarios:

1. Actualización de las especificaciones de recursos básicos: Con cada lanzamiento, Cortex actualiza las especificaciones de recursos básicos, lo que proporciona una base de metadatos estandarizada para la malla de datos.
2. Personalización de las especificaciones de recursos: Antes de la implementación, los usuarios pueden adaptar las especificaciones de 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 recursos de datos durante la implementación de Cortex. Además, los usuarios tienen la flexibilidad de implementar la malla de datos de forma independiente para realizar más actualizaciones.

Directorios de la malla de datos

Encuentra los archivos de configuración base 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 archivos diferente, pero todas las especificaciones se encuentran de manera similar en la carpeta config.

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

Las anotaciones de recursos se definen a nivel del recurso 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 indica en la siguiente tabla. Cuando implementes la malla de datos 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 diferentes proyectos de origen y destino, asegúrate de que estas APIs y permisos estén habilitados en ambos proyectos siempre que se empleen esas funciones.

Información sobre las especificaciones de recursos básicos

La interfaz principal para configurar la malla de datos para Cortex se realiza 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 según las necesidades del usuario. 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 Catalog que definen cómo se pueden etiquetar los recursos con dominios comerciales.
• 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 explican ejemplos básicos de cada tipo de especificación y cómo personalizarlos. Las especificaciones básicas se etiquetan con ## CORTEX-CUSTOMER, donde se deben modificar para que se ajusten a una implementación si la opción de implementación asociada está habilitada. 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 que está 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, el display_name también se usa como 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 destino, debe haber una especificación definida para cada proyecto. Por ejemplo, Cortex Salesforce (SFDC) contiene dos especificaciones de Lake. Una para las zonas sin procesar y de CDC, y otra para los informes.

Lakes de Dataplex Universal Catalog

Los lakes, las zonas y los recursos de Dataplex Universal Catalog 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 están 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 una sola región o varias. 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 y la zona de Cortex location_type son multirregionales, selecciona una sola región dentro de ese grupo para la región del Lake.

• Requisitos
  • El lago display_name se usa como lake_id y debe cumplir con los requisitos oficiales. Este también es el caso de los display_name de zona y recurso. Los IDs de zona deben ser únicos en todos los lagos del proyecto.
  • Las especificaciones de los lagos deben asociarse a una sola región.
  • El asset_name debe coincidir con el ID del conjunto de datos de BigQuery, pero el display_name puede ser una etiqueta más fácil de usar.
• Limitaciones
  • Dataplex Universal Catalog solo admite el registro de conjuntos de datos de BigQuery, en lugar de tablas individuales, como recursos de Dataplex Universal Catalog.
  • Es posible que un activo solo esté registrado en una zona.
  • Dataplex Universal Catalog solo se admite en ciertas ubicaciones. Para obtener más información, consulta Ubicaciones de Dataplex Universal Catalog.

Consulta el siguiente ejemplo en lakes.yaml.

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

Plantillas de etiquetas de Catalog

Las plantillas de etiquetas de Data Catalog se pueden usar para agregar contexto a las tablas de BigQuery o a las columnas individuales. Te ayudan a categorizar y comprender tus datos desde una perspectiva técnica y empresarial de una manera integrada con las herramientas de búsqueda de Dataplex Universal Catalog. 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 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 legibles públicamente. También introduce un concepto adicional de level en las especificaciones de la plantilla de etiquetas, que define si una etiqueta se debe aplicar 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 ahora, las futuras verificaciones de validación 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 columna y de recursos con plantillas de etiquetas

Cortex Framework proporciona la capacidad de habilitar el control de acceso a nivel de recurso o columna en todos los artefactos asociados con una plantilla de etiquetas del 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 del catálogo line_of_business con diferentes principales especificados para cada dominio comercial. Cada política acepta filters que se puede usar para hacer coincidir solo las 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 recursos es la unión de las políticas definidas directamente en las anotaciones y las políticas de la plantilla.

El control de acceso a nivel de columna con etiquetas de Catalog se comporta de manera similar, ya que aplica etiquetas de política en los campos coincidentes. Sin embargo, debido a que solo se puede aplicar una etiqueta de política a una columna, la precedencia 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 tendrá prioridad.
2. Política de plantilla de etiquetas coincidente: De lo contrario, el acceso se determina según la primera política coincidente definida en un campo dentro de la plantilla de etiquetas del catálogo asociada.

Cuando uses esta función, te recomendamos que habilites o inhabilite la implementación de etiquetas de catálogo y listas de control de acceso (LCA) en conjunto. 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 utilizan columnas específicas dentro de los recursos de datos que podrían no comprenderse de forma universal. Los usuarios pueden agregar términos de forma manual en la consola, pero no hay compatibilidad a través de las especificaciones de recursos.

Taxonomías y etiquetas de políticas

Las taxonomías y etiquetas de políticas permiten el 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 sin enmascarar o no tener acceso de lectura en absoluto.

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

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

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

Consulta el siguiente ejemplo.

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

Anotaciones de recursos

Las anotaciones especifican metadatos aplicables a un activo en particular y pueden hacer referencia a los recursos de metadatos compartidos que se definieron. Las anotaciones incluyen lo siguiente:

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

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 tener 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 Spec en data_mesh_types.CatalogTag.

Cómo especificar 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énes (principales) pueden acceder a recursos de datos específicos, filas dentro de un recurso o incluso columnas individuales. Las principales deben seguir un formato específico definido por 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: Ver datos en el recurso
• WRITER: Modifica y agrega datos al recurso.
• OWNER : Control total sobre el activo, incluida la administración del acceso.

Estos permisos son equivalentes a la instrucción GRANT DCL en SQL.

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

Consulta el siguiente ejemplo.

Consulta la definición de Spec 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 a nivel de la fila, la cadena de filtro proporcionada se insertará en un CREATE DDL statement. Si la marca overwrite está habilitada, se descartan todas las políticas de acceso a nivel de la fila existentes antes de aplicar las nuevas.

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

• Si agregas políticas de acceso a filas, los usuarios que no se especifiquen en esas políticas no tendrán acceso para ver ninguna fila.
• Las políticas de filas solo funcionan con tablas, no con vistas.
• Evita usar columnas particionadas en los filtros de tus políticas de acceso a las filas. Consulta el archivo YAML de configuración de informes asociado para obtener información sobre el tipo de recurso 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 Spec en data_mesh_types.BqRowPolicy.

Acceso a nivel de columna

Para habilitar el acceso a nivel de columna, anota los 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 Spec 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 pertinentes, como los nombres de los conjuntos de datos de BigQuery y las opciones de implementación. De forma predeterminada, la implementación de la malla de datos no quitará ni reemplazará ningún recurso o anotación existente para evitar pérdidas involuntarias. Sin embargo, también existe la posibilidad de reemplazar los recursos existentes cuando se implementa por sí solo.

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.

Implementación con Data Foundation

De forma predeterminada, config.json > deployDataMesh permite implementar las descripciones de los activos de la malla de datos al final de cada paso de compilación de la carga de trabajo. Esta configuración predeterminada no requiere que se habiliten APIs o roles adicionales. Se pueden implementar funciones adicionales de la malla de datos 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 sin acompañante

Para implementar la malla de datos por sí sola, los usuarios pueden usar el archivocommon/data_mesh/deploy_data_mesh.py. Esta utilidad se usa durante los procesos de compilación para implementar la malla de datos de 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 la malla de datos 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

A continuación, se muestra 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

De forma predeterminada, la implementación de Data Mesh no reemplazará ningún recurso ni anotación existente. Sin embargo, la marca --overwrite se puede habilitar cuando se implementa la malla de datos por sí sola para cambiar la implementación de las siguientes maneras.

Cuando se reemplazan recursos de metadatos, como lagos, plantillas de etiquetas del catálogo y etiquetas de política, se borran los recursos existentes que comparten el mismo nombre, pero no se modifican los recursos existentes con nombres diferentes. Esto significa que, si se quita por completo una especificación de recurso del archivo YAML y, luego, se vuelve a implementar Data Mesh con la opción de sobrescribir habilitada, esa especificación de recurso no se borrará porque no habrá colisión de nombres. Esto se debe a que la implementación de Cortex Data Mesh no afecta los recursos existentes que podrían estar en uso.

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

Las anulaciones de la descripción del campo y del activo solo surten efecto si se proporciona una descripción nueva válida y no vacía que entre en conflicto con la descripción existente.

Por otro lado, las ACL se comportan de manera diferente. Las LCA de reemplazo quitan todas las 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 que 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 las etiquetas del catálogo que se aplicaron. Los usuarios también pueden crear y aplicar manualmente términos del Glosario del catálogo si es necesario.

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

Linaje de datos

A los usuarios les puede resultar útil habilitar y visualizar el linaje entre los recursos de BigQuery. También se puede acceder al linaje de manera programática a través de la API. El linaje de datos solo admite el linaje a nivel del recurso. El linaje de datos no está entrelazado con la malla de datos de Cortex, pero es posible que se introduzcan nuevas funciones en el futuro que utilicen el linaje.

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