Paso 5: Configura la implementación

En esta página se describe el quinto paso para desplegar la infraestructura de datos de Cortex Framework, que es el componente principal de Cortex Framework. En este paso, modificará el archivo de configuración del repositorio Data Foundation de Cortex Framework para que se ajuste a sus requisitos.

Archivo de configuración

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

  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 Implementar datos de prueba true Proyecto en el que se encuentra el conjunto de datos de origen 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 Desplegar SAP true Ejecuta el despliegue de la carga de trabajo de SAP (ECC o S/4 HANA).
    deploySFDC Implementar Salesforce true Ejecuta el despliegue de la carga de trabajo de Salesforce.
    deployMarketing Deploy Marketing true Implementar las fuentes de marketing (Google Ads, CM360 y TikTok).
    deployOracleEBS Implementar Oracle EBS true Ejecuta el despliegue de la carga de trabajo de Oracle EBS.
    deployDataMesh Implementar una malla de datos true Ejecuta la implementación de la malla de datos. Para obtener más información, consulta la guía de usuario de Data Mesh.
    enableTaskDependencies DAGs dependientes de tareas false Habilita los DAGs dependientes de tareas para que las tablas SQL admitidas se ejecuten en función del orden de las dependencias en los DAGs individuales. Para obtener más información, consulta DAGs dependientes de tareas.
    turboMode Implementa en modo Turbo. true Ejecuta todas las compilaciones de vistas como un paso del mismo proceso de Cloud Build, en paralelo, para que la implementación sea más rápida. Si se define como false, cada vista de informes se genera en su propio paso de compilación secuencial. Te recomendamos que solo lo definas como true cuando utilices datos de prueba o después de que se hayan resuelto las discrepancias entre las columnas de los informes y los datos de origen.
    projectIdSource ID de proyecto de origen - Proyecto en el que se encuentra el conjunto de datos de origen y se ejecuta la compilación.
    projectIdTarget ID del proyecto de destino - Proyecto de destino de los conjuntos de datos visibles para los usuarios.
    targetBucket Segmento de destino para almacenar los scripts de DAG generados - El bucket creado anteriormente en el que se generan los DAGs (y los archivos temporales de Dataflow). No uses el bucket de Airflow real.
    location Ubicación o región "US" Ubicación del conjunto de datos de BigQuery y de los segmentos de Cloud Storage.

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

    testDataProject Fuente del agente de prueba kittycorn-public 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 arnés de prueba.

    k9.datasets.processing Conjuntos de datos de K9: procesamiento "K9_PROCESSING" Ejecuta plantillas de cargas de trabajo cruzadas (por ejemplo, la dimensión de fecha) tal como se define en el archivo de configuración de K9. Normalmente, las cargas de trabajo posteriores requieren estas plantillas.
    k9.datasets.reporting Conjuntos de datos de K9: informes "K9_REPORTING" Ejecuta plantillas de cargas de trabajo cruzadas y fuentes de datos externas (por ejemplo, el tiempo) tal como se define en el archivo de configuración de K9. Se comenta de forma predeterminada.
    DataMesh.deployDescriptions Data Mesh: descripciones de los recursos true Despliega descripciones de esquemas de recursos de BigQuery.
    DataMesh.deployLakes Malla de datos: lagos y zonas false Para implementar lagos y zonas de Universal Catalog de Dataplex que organicen las tablas por capa de procesamiento, es necesario configurar el servicio antes de habilitarlo.
    DataMesh.deployCatalog Malla de datos: etiquetas y plantillas de catálogo false Para desplegar etiquetas de Data Catalog que permitan metadatos personalizados en recursos o campos de BigQuery, es necesario configurar la función antes de habilitarla.
    DataMesh.deployACLs Data Mesh: control de acceso false Para implementar el control de acceso a nivel de recurso, fila o columna en recursos de BigQuery, es necesario configurar el control de acceso antes de habilitarlo.

  3. Configura las cargas de trabajo que necesites. No es necesario que los configure si el parámetro de implementación (por ejemplo, deploySAP o deployMarketing) de la carga de trabajo está definido como False. Para obtener más información, consulta el Paso 3: Determinar el mecanismo de integración.

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

Optimizar el rendimiento de las vistas de informes

Los artefactos de informes se pueden crear como vistas o como tablas que se actualizan periódicamente mediante DAGs. Por un lado, las vistas calculan los datos en cada ejecución de una consulta, lo que hace que los resultados estén siempre actualizados. Por otro lado, la tabla ejecuta los cálculos una vez y los resultados se pueden consultar varias veces sin incurrir en costes de computación más elevados y con 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. Estas tablas se pueden optimizar aún más añadiendo particiones y clústeres.

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

Fuente de datos Archivos de configuración
Operacional - SAP src/SAP/SAP_REPORTING/reporting_settings_ecc.yaml
Operativo - Salesforce Sales Cloud src/SFDC/config/reporting_settings.yaml
Operacional - 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 y cross-media src/marketing/src/CrossMedia/config/reporting_settings.yaml

Personalizar el archivo de configuración de los 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 el archivo con las descripciones de los siguientes 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 Turbo mode está habilitado, 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 deben crearse en un orden específico debido a las dependencias de otros objetos de BigQuery. Turbo mode no se aplica a esta sección.

En primer lugar, el implementador crea todos los objetos de BigQuery que se indican en bq_independent_objects y, a continuación, todos los objetos que se indican en bq_dependent_objects. Define las siguientes propiedades para cada objeto:

  1. sql_file: nombre del archivo SQL que crea un objeto determinado.
  2. type: tipo de objeto de BigQuery. Posibles valores:
    • view : si quieres que el objeto sea una vista de BigQuery.
    • table: si quieres que el objeto sea una tabla de BigQuery.
    • script: se usa para crear otros tipos de objetos (por ejemplo, funciones y procesos almacenados de BigQuery).
  3. Si type tiene el valor table, se pueden definir las siguientes propiedades opcionales:
    • load_frequency: frecuencia con la que se ejecuta un DAG de Composer para actualizar esta tabla. Consulta la documentación de Airflow para obtener información sobre los valores posibles.
    • partition_details: 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: 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 tabla

Algunos archivos de configuración te permiten configurar tablas materializadas con opciones de clustering y partición personalizadas. Esto puede mejorar significativamente el rendimiento de las consultas en conjuntos de datos de gran tamaño. Esta opción solo se aplica a los archivos SAP cdc_settings.yaml y a todos los archivos reporting_settings.yaml.

Para habilitar la partición de tablas, debe especificar lo siguiente:partition_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 las particiones de una tabla determinada:

Propiedad Descripción Valor
column Columna por la que se crea la partición de la tabla de CDC. Nombre de la columna.
partition_type 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 intervalos de números enteros.
time_grain Parte temporal para la partición. Obligatorio cuando partition_type = "time". "hour", "day", "month" o "year".
integer_range_bucket Intervalo del segmento Obligatorio cuando partition_type = "integer_range" "start" = Valor inicial, "end" = Valor final y "interval" = Intervalo del rango.

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

Configuración del clúster

Para habilitar la agrupación en clústeres de tablas, especifica cluster_details:

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

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

Propiedad Descripción Valor
columns Columnas por las que se agrupa una tabla en clústeres. Lista de nombres de columna. Por ejemplo: "mjahr" y "matnr".

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

Pasos siguientes

Cuando haya completado este paso, vaya al siguiente:

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