Guía del usuario de la malla de datos (obsoleta)

Advertencia: La función de malla de datos dentro del Google Cloud Cortex Framework ahora está obsoleta y se inhabilitó. Este cambio se debe a la evolución de los servicios de administración de datos de Google Cloud. La solución de malla de datos se creó con Data Catalog para la administración de metadatos, que ahora se reemplaza por el más avanzado Knowledge Catalog. Knowledge Catalog proporciona una API unificada, capacidades de metadatos mejoradas y funciones nuevas para una experiencia de administración de datos más completa.

La malla de datos para 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 Knowledge Catalog. Esto se implementa proporcionando un conjunto base 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 base proporcionan una configuración personalizada que es la base de los metadatos para complementar Cortex Framework Data Foundation. Consulta Conceptos de malla de datos antes de continuar con esta guía.

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

Advertencia: Esta guía de malla de datos puede cambiar con el tiempo. Comunícate con el equipo de Cortex para enviar comentarios o informar problemas relacionados.

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

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 los recursos base: Con cada versión, Cortex actualiza las especificaciones de los recursos base, 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 la malla de datos: Los usuarios pueden habilitar la malla de datos 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.

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

Directorios de malla de datos

Busca los archivos de configuración base de la malla de datos 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.

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
	Salesforce Marketing Cloud (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: La malla de datos no admite datos de LiveRamp ni 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 especificaciones de recursos adicionales dentro de ese directorio si es necesario.

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 la malla de datos te permite implementar funciones más allá de las descripciones. Si necesitas modificar los valores predeterminados de la malla de datos 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 proyectos de origen y de destino diferentes, asegúrate de que estas APIs y permisos estén habilitados en ambos proyectos donde se usen esas funciones.

Función	Roles de usuario	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 recursos y Permisos requeridos para los roles de filas.
Acceso a las columnas de BigQuery	Administrador de etiquetas de políticas	Para obtener más información, consulta la documentación sobre los roles que se usan con el control de acceso a nivel de columna y cómo restringir el acceso con el control de acceso a nivel de columna.
Etiquetas de catálogo	Propietario de TagTemplate de Data Catalog	Para obtener más información, consulta la documentación de Etiqueta una tabla de BigQuery con Data Catalog y de IAM de Data Catalog.
Lakes de Knowledge Catalog	Editor de Dataplex	Para obtener más información, consulta la documentación de Crea un lake.

Nota: Cortex Data Mesh no requiere la integración de las APIs de Managed Service para Apache Spark y Managed Service para Apache Spark Metastore.

Información sobre las especificaciones de los recursos base

La interfaz principal para configurar la malla de datos para Cortex es a través de las especificaciones de recursos base, que son un conjunto de archivos YAML que se proporcionan de forma predeterminada y que definen los recursos de metadatos y las anotaciones que se implementan. Las especificaciones base 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 empresariales.
• 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 proporcionan ejemplos básicos de cada tipo de especificación y se explica cómo personalizarlas. Las especificaciones base 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 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 puede generar 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. Uno para las zonas sin procesar y de CDC, y otro para los informes.

Lakes de Knowledge Catalog

Los lakes, las zonas y los recursos de Knowledge 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 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 multirregión. La zona location_type debe establecerse en SINGLE_REGION | MULTI_REGION para que coincida con eso. 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 de Lake.

• Requisitos
  • El lake display_name se usa como lake_id y debe cumplir con los requisitos oficiales. Esto también ocurre con la zona y el recurso display_name. Los IDs de zona deben ser únicos en todos los data lakes del proyecto.
  • Las especificaciones del lake deben estar asociadas 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
  • Knowledge Catalog solo admite el registro de conjuntos de datos de BigQuery, en lugar de tablas individuales, como recursos de Knowledge Catalog.
  • Un recurso solo se puede registrar en una zona.
  • Knowledge Catalog solo se admite en ciertas ubicaciones. Para obtener más información, consulta Ubicaciones de Knowledge 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 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 se integra con las herramientas de búsqueda de Knowledge 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 o 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 del 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 compatibles, consulta Tipos de campos de Data Catalog.

Cortex Data Mesh crea todas las plantillas de etiquetas como legibles de forma pública. 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 recurso completo, a campos individuales dentro de un recurso o a ambos, con los valores posibles: ASSET | FIELD | ANY. Si bien esto no se aplica de forma estricta 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 recursos.

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

Cortex Framework ofrece la capacidad de habilitar el control de acceso a nivel de recurso o de columna en todos los artefactos asociados con una plantilla de etiquetas 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 del catálogo de line_of_business con diferentes principales especificadas para cada dominio empresarial. Cada política acepta filters que se pueden usar para que solo coincidan con 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 indican varios filtros, los resultados deben satisfacerlos todos (por ejemplo, filter_a AND filter_b). El conjunto final de políticas de recursos es la unión de las que se definen directamente en las anotaciones y las de las políticas de plantilla.

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 coincidentes. Sin embargo, debido a que 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 coincidencias de plantilla de etiquetas: De lo contrario, el acceso se determina según la primera política de coincidencias definida en un campo dentro de la plantilla de etiquetas de Catalog 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) juntas. 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 entenderse de forma universal. Los usuarios pueden agregar términos de forma manual en la consola, pero no hay asistencia 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 en los recursos de datos sensibles de forma estandarizada. Por ejemplo, podría haber una taxonomía para las etiquetas que controlan los datos de IIP 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 etiquetas de políticas, consulta la documentación de Introducción al enmascaramiento de datos de columnas. Las siguientes secciones son especialmente pertinentes:

• Interacción de los roles
• Herencia de autorización
• Reglas de enmascaramiento y jerarquía
• Prácticas recomendadas para las etiquetas de política

Cortex Framework proporciona etiquetas de política de ejemplo 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 la malla de datos 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 recursos

Las anotaciones especifican los metadatos aplicables a un recurso 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 recurso, fila y columna

Nota: Si modificas un archivo de anotaciones, ten en cuenta que la consola solo renderiza las líneas nuevas en las descripciones como un espacio 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 de informes)
• SAP S4 HANA (sin procesar, CDC y 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 recurso 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.

Especifica los lectores y las 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 la vinculación de la política de IAM.

Acceso a nivel de recurso

Puedes otorgar acceso a recursos completos de BigQuery con varios permisos:

• READER: Ver 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 equivalen 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 las principales existentes con el rol OWNERS. Cuando se agregan propietarios nuevos con la opción de reemplazar habilitada, solo se agregan a los propietarios existentes. Esta es una medida de protección para evitar la pérdida involuntaria del acceso. Para quitar propietarios de activos, usa la consola. Si reemplazas, se quitarán 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 fila

Puedes otorgar acceso a conjuntos de filas según ciertos filtros de valores de columna. Cuando se especifica la política de acceso de 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 filas existentes antes de aplicar las nuevas.

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

• Agregar cualquier política de acceso de fila significa que 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 la política de acceso a nivel de fila. 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 fila, consulta las prácticas recomendadas para la seguridad a nivel de fila.

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 no deseadas. Sin embargo, también existe la capacidad de 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 solo a través de estas especificaciones de recursos si deployACLs está habilitado. Esto evita que se agregue o quite acceso de forma involuntaria.

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

Implementa con la base de datos

De forma predeterminada, config.json > deployDataMesh habilita la implementación de las descripciones de los recursos de malla de datos al final de cada paso de compilación de la carga de trabajo. Esta configuración predeterminada no requiere habilitar ninguna API ni rol adicional. Las funciones adicionales de la malla de datos 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 por separado

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 la malla 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 habilitarse 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 estás implementando 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 malla de datos para obtener información sobre las ubicaciones de los directorios.

Reemplazar

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

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

Reemplazar los recursos de metadatos, como los lagos, las plantillas de etiquetas de catálogo y las etiquetas de política, borra los recursos existentes que comparten los mismos nombres, pero no modificará 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 la malla de datos con la opción de reemplazar habilitada, esa especificación de recurso no se borrará porque no habrá colisión de nombres. Esto es 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 los lagos y las zonas, reemplazar un recurso quita todos sus elementos secundarios. Por ejemplo, reemplazar un lake también quita sus zonas y referencias de recursos existentes. En el caso de las plantillas de etiquetas de catálogo y las etiquetas de política que se reemplazan, las referencias de anotación asociadas existentes también se quitan de los recursos. Reemplazar las etiquetas de catálogo en una anotación de recurso solo reemplaza las instancias existentes de etiquetas de catálogo que comparten la misma plantilla.

Los reemplazos de descripciones de recursos y campos solo se aplican 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 LCA se comportan de manera diferente. Reemplazar las ACL quita todas las principales existentes (con la excepción de 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 de 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 recurso 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 forma programática a través de la API. El linaje de datos solo admite el linaje a nivel de recurso. El linaje de datos no está entrelazado con la malla de datos de Cortex. Sin embargo, es posible que se introduzcan nuevas funciones en el futuro que utilicen el linaje.

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