Paso 5: Configura la implementación

En esta página, se describe el quinto paso para implementar Cortex Data Foundation de Cortex Framework, el núcleo de Cortex Framework. En este paso, modificarás el archivo de configuración en el repositorio de Data Foundation de Cortex Framework para que coincida con tus requisitos.

Archivo de configuración

El comportamiento de la implementación se controla mediante el archivo de configuración config.json en la base de datos de Cortex Framework. Este archivo contiene la configuración global y la configuración específica de cada carga de trabajo. Sigue estos pasos para editar el archivo config.json según tus necesidades:

  1. Abre el archivo config.json desde Cloud Shell.

  2. Edita el archivo config.json según los siguientes parámetros:

    Parámetro Significado Valor predeterminado Descripción
    testData Implementa los datos de prueba. true Es el proyecto en el que se encuentra el conjunto de datos fuente y se ejecuta la compilación. Nota: La implementación de datos de prueba solo se ejecutará si el conjunto de datos sin procesar está vacío y no tiene tablas.
    deploySAP Implementa SAP true Ejecuta la implementación para la carga de trabajo de SAP (ECC o S/4HANA).
    deploySFDC Implementa Salesforce true Ejecuta la implementación para la carga de trabajo de Salesforce.
    deployMarketing Implementa el marketing true Ejecuta la implementación para las fuentes de marketing (Google Ads, CM360 y TikTok).
    deployOracleEBS Implementa EBS de Oracle true Ejecuta la implementación para la carga de trabajo de EBS de Oracle.
    deployDataMesh Implementa la malla de datos true Ejecuta la implementación de Data Mesh. Para obtener más información, consulta la Guía del usuario de Data Mesh.
    turboMode Implementa en el modo Turbo. true Ejecuta todas las compilaciones de vistas como un paso en el mismo proceso de Cloud Build, en paralelo para lograr una implementación más rápida. Si se establece en false, cada vista de informes se genera en su propio paso de compilación secuencial. Te recomendamos que solo lo configures en true cuando uses datos de prueba o después de que se resuelva cualquier discrepancia entre las columnas de informes y los datos de origen.
    projectIdSource ID del proyecto de origen - Es el proyecto en el que se encuentra el conjunto de datos fuente y se ejecuta la compilación.
    projectIdTarget ID del proyecto de destino - Es el proyecto de destino para los conjuntos de datos orientados al usuario (informes y conjuntos de datos de AA).
    targetBucket Bucket de destino para almacenar las secuencias de comandos de DAG generadas - Bucket creado anteriormente en el que se generan los DAG (y los archivos temporales de Dataflow). Evita usar el bucket de Airflow real.
    location Ubicación o región "US" Es la ubicación en la que se encuentran el conjunto de datos de BigQuery y los buckets de Cloud Storage.

    Consulta las restricciones que se indican en Ubicaciones de los conjuntos de datos de BigQuery.

    testDataProject Fuente del agente de prueba kittycorn-public Es la fuente de los datos de prueba para las implementaciones de demostración. Se aplica cuando testData es true.

    No cambies este valor, a menos que tengas tu propio entorno de pruebas.

    k9.datasets.processing Conjuntos de datos de K9: procesamiento "K9_PROCESSING" Ejecuta plantillas de carga de trabajo múltiple (por ejemplo, dimensión de fecha) como se define en el archivo de configuración de K9. Por lo general, las cargas de trabajo downstream requieren estas plantillas.
    k9.datasets.reporting Conjuntos de datos de K9: Informes "K9_REPORTING" Ejecuta plantillas de cargas de trabajo múltiples y fuentes de datos externas (por ejemplo, clima) como se define en el archivo de configuración de K9. Se comenta de forma predeterminada.
    DataMesh.deployDescriptions Malla de datos: Descripciones de los activos true Implementa descripciones de esquemas de activos de BigQuery.
    DataMesh.deployLakes Data Mesh: Lakes y zonas false La implementación de Dataplex Lakes y Zonas que organizan las tablas por capa de procesamiento requiere configuración antes de habilitarlas.
    DataMesh.deployCatalog Data Mesh: Plantillas y etiquetas del catálogo false La implementación de etiquetas de Data Catalog que permiten metadatos personalizados en activos o campos de BigQuery requiere configuración antes de habilitarlas.
    DataMesh.deployACLs Data Mesh: Control de acceso false Para implementar el control de acceso a nivel de los recursos, las filas o las columnas en los recursos de BigQuery, se requiere la configuración antes de habilitarlo.

  3. Configura las cargas de trabajo necesarias según sea necesario. No es necesario que los configures si el parámetro de implementación (por ejemplo, deploySAP o deployMarketing) de la carga de trabajo está configurado en False. Para obtener más información, consulta Paso 3: Determina el mecanismo de integración.

Para personalizar mejor tu implementación, consulta los siguientes pasos opcionales:

Optimización del rendimiento para las vistas de informes

Los artefactos de informes se pueden crear como vistas o como tablas que se actualizan con regularidad a través de DAG. Por un lado, las vistas calculan los datos en cada ejecución de una consulta, lo que mantiene los resultados siempre actualizados. Por otro lado, la tabla ejecuta los cálculos una vez, y los resultados se pueden consultar varias veces sin incurrir en costos de procesamiento más altos y lograr un tiempo de ejecución más rápido. Cada cliente crea su propia configuración según sus necesidades.

Los resultados materializados se actualizan en una tabla. Para ajustar mejor estas tablas, puedes agregar particiones y agrupación en clústeres.

Los archivos de configuración de cada carga de trabajo se encuentran en las siguientes rutas dentro del repositorio de Data Foundation de Cortex Framework:

Fuente de datos Archivos de configuración
Operaciones: SAP src/SAP/SAP_REPORTING/reporting_settings_ecc.yaml
Operaciones: Salesforce Sales Cloud src/SFDC/config/reporting_settings.yaml
Operativo: Oracle EBS src/oracleEBS/config/reporting_settings.yaml
Marketing - Google Ads src/marketing/src/GoogleAds/config/reporting_settings.yaml
Marketing - CM360 src/marketing/src/CM360/config/reporting_settings.yaml
Marketing: Meta src/marketing/src/Meta/config/reporting_settings.yaml
Marketing: Salesforce Marketing Cloud src/marketing/src/SFMC/config/reporting_settings.yaml
Marketing: TikTok src/marketing/src/TikTok/config/reporting_settings.yaml
Marketing: YouTube (con DV360) src/marketing/src/DV360/config/reporting_settings.yaml
Marketing: Google Analytics 4 src/marketing/src/GA4/config/reporting_settings.yaml
Marketing: Estadísticas de productos conectados y multimedios src/marketing/src/CrossMedia/config/reporting_settings.yaml

Personaliza el archivo de configuración de informes

Los archivos reporting_settings determinan cómo se crean los objetos de BigQuery (tablas o vistas) para los conjuntos de datos de informes. Personaliza tu archivo con las siguientes descripciones de parámetros. Ten en cuenta que este archivo contiene dos secciones:

  1. bq_independent_objects: Todos los objetos de BigQuery que se pueden crear de forma independiente, sin ninguna otra dependencia. Cuando se habilita Turbo mode, estos objetos de BigQuery se crean en paralelo durante el tiempo de implementación, lo que acelera el proceso de implementación.
  2. bq_dependent_objects: Todos los objetos de BigQuery que se deben crear en un orden específico debido a dependencias en otros objetos de BigQuery. Turbo mode no se aplica a esta sección.

El implementador primero crea todos los objetos de BigQuery que se enumeran en bq_independent_objects y, luego, todos los objetos que se enumeran en bq_dependent_objects. Define las siguientes propiedades para cada objeto:

  1. sql_file: Es el nombre del archivo SQL que crea un objeto determinado.
  2. type: Es el tipo de objeto de BigQuery. Valores posibles:
    • view : Si deseas que el objeto sea una vista de BigQuery.
    • table: Si deseas que el objeto sea una tabla de BigQuery.
    • script: Esto se usa para crear otros tipos de objetos (por ejemplo, funciones y procesos almacenados de BigQuery).
  3. Si type se establece en table, se pueden definir las siguientes propiedades opcionales:
    • load_frequency: Es la frecuencia con la que se ejecuta un DAG de Composer para actualizar esta tabla. Consulta la documentación de Airflow para obtener detalles sobre los valores posibles.
    • partition_details: Indica cómo se debe particionar la tabla. Este valor es opcional. Para obtener más información, consulta la sección Partición de tablas.
    • cluster_details: Indica cómo se debe agrupar la tabla. Este valor es opcional. Para obtener más información, consulta la sección Configuración del clúster.

Partición de tablas

Algunos archivos de configuración te permiten configurar tablas materializadas con opciones de clúster y partición personalizadas. Esto puede mejorar de manera significativa el rendimiento de las consultas para conjuntos de datos grandes. Esta opción solo se aplica a SAP cdc_settings.yaml y a todos los archivos reporting_settings.yaml.

Para habilitar el particionamiento de tablas, especifica el siguientepartition_details:

- base_table: vbap
  load_frequency: "@daily"
  partition_details: {
    column: "erdat", partition_type: "time", time_grain: "day" }

Usa los siguientes parámetros para controlar los detalles de partición de una tabla determinada:

Propiedad Descripción Valor
column Es la columna por la que se particiona la tabla de CDC. Es el nombre de la columna.
partition_type Es el tipo de partición. "time" para la partición basada en el tiempo. Para obtener más información, consulta Tablas particionadas por marca de tiempo. "integer_range" para la partición basada en números enteros. Para obtener más información, consulta la documentación sobre el rango de números enteros.
time_grain Es la parte de tiempo con la que se debe particionar. Obligatorio cuando partition_type = "time". "hour", "day", "month" o "year"
integer_range_bucket Rango de bucket Obligatorio cuando partition_type = "integer_range" "start" = Valor inicial, "end" = Valor final y "interval" = Intervalo de rango.

Para obtener más información sobre las opciones y las limitaciones relacionadas, consulta Partición de tablas de BigQuery.

Configuración del clúster

Para habilitar el agrupamiento de tablas, especifica cluster_details:

  - base_table: vbak
    load_frequency: "@daily"
    cluster_details: {columns: ["vkorg"]}

Usa los siguientes parámetros para controlar los detalles del clúster de una tabla determinada:

Propiedad Descripción Valor
columns Son las columnas por las que se agrupa una tabla. Es la lista de nombres de las columnas. Por ejemplo, "mjahr" y "matnr".

Para obtener más información sobre las opciones y las limitaciones relacionadas, consulta la documentación del clúster de tablas.

Próximos pasos

Después de completar este paso, continúa con el siguiente paso de implementación:

  1. Establece cargas de trabajo.
  2. Clona el repositorio.
  3. Determina el mecanismo de integración.
  4. Configura los componentes.
  5. Configura la implementación (esta página).
  6. Ejecuta la implementación.