Paso 5: Configura la implementación

En esta página, se describe el quinto paso para implementar Cortex Framework Data Foundation, 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 con el archivo de configuración config.json en la Cortex Framework Data Foundation. Este archivo contiene la configuración global y la configuración específica para cada carga de trabajo. Edita el archivo config.json según tus necesidades con los siguientes pasos:

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

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

    <td"> Parámetro <td">Significado <td">Valor predeterminado <td">Descripción </td"></td"></td"></td"><td">testData <td">Implementar datos de prueba <td">true <td">Es el 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. </td"></td"></td"></td"><td">deploySAP <td">Implementación de SAP <td">true <td">Ejecuta la implementación para la carga de trabajo de SAP (ECC o S/4HANA). </td"></td"></td"></td"><td">deploySFDC <td">Implementación de Salesforce <td">true <td">Ejecuta la implementación para la carga de trabajo de Salesforce. </td"></td"></td"></td"><td">deployMarketing <td">Implementación de Marketing <td">true <td">Ejecuta la implementación para las fuentes de Marketing (Google Ads, CM360 y TikTok). </td"></td"></td"></td"><td">deployOracleEBS <td">Implementación de Oracle EBS <td">true <td">Ejecuta la implementación para la carga de trabajo de Oracle EBS. </td"></td"></td"></td"><td">enableTaskDependencies <td">DAGs dependientes de tareas <td">false <td">Habilita los DAGs dependientes de tareas para que las tablas SQL compatibles se ejecuten según el orden de dependencia dentro de los DAGs individuales. Para obtener más información, consulta DAGs dependientes de tareas. </td"></td"></td"></td"><td">turboMode <td">Implementa en modo Turbo. <td">true <td">Ejecuta todas las compilaciones de vistas como un paso en el mismo proceso de compilación de Cloud Build, en paralelo para una implementación más rápida. Si se configura como false, cada vista de informes se genera en su propio paso de compilación secuencial. Recomendamos que solo establezcas el valor en true cuando uses datos de prueba o después de que se haya resuelto cualquier discrepancia entre las columnas de informes y los datos fuente. </td"></td"></td"></td"><td">projectIdSource <td">ID del proyecto fuente <td">- <td">Proyecto en el que se encuentra el conjunto de datos fuente y se ejecuta la compilación. </td"></td"></td"></td"><td">projectIdTarget <td">ID del proyecto de destino <td">- <td">Es el proyecto de destino para los conjuntos de datos orientados al usuario. </td"></td"></td"></td"><td">targetBucket <td">Bucket de destino para almacenar los scripts de DAG generados <td">- <td">Bucket creado anteriormente en el que se generan los DAGs (y los archivos temporales de Dataflow). Evita usar el bucket de Airflow real. </td"></td"></td"></td"><td">location <td">Ubicación o región <td">"US" <td">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 conjuntos de datos de BigQuery.

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

    </td"></td"></td"></td"><td">k9.datasets.processing <td">Conjuntos de datos de K9: procesamiento <td">"K9_PROCESSING" <td">Ejecuta plantillas de cargas de trabajo cruzadas (por ejemplo, la dimensión de fecha) según se definen en el archivo de configuración de K9. Por lo general, las cargas de trabajo de downstream requieren estas plantillas. </td"></td"></td"></td"><td">k9.datasets.reporting <td">Conjuntos de datos de K9: Informes <td">"K9_REPORTING" <td">Ejecuta plantillas de cargas de trabajo cruzadas y fuentes de datos externas (por ejemplo, el clima) según se definen en el archivo de configuración de K9. Está comentado de forma predeterminada. </td"></td"></td"></td">

  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á establecido 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 periódicamente a través de DAGs. 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 sola vez, y los resultados se pueden consultar varias veces sin incurrir en costos de procesamiento más altos 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 ajustar aún más agregando particiones y agrupaciones en clústeres.

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

<td">Fuente de datos <td">Archivos de configuración </td"></td"><td">Operacional: SAP <td">src/SAP/SAP_REPORTING/reporting_settings_ecc.yaml </td"></td"><td">Operacional: Salesforce Sales Cloud <td">src/SFDC/config/reporting_settings.yaml </td"></td"><td">Operacional: Oracle EBS <td">src/oracleEBS/config/reporting_settings.yaml </td"></td"><td">Marketing: Google Ads <td">src/marketing/src/GoogleAds/config/reporting_settings.yaml </td"></td"><td">Marketing: CM360 <td">src/marketing/src/CM360/config/reporting_settings.yaml </td"></td"><td">Marketing: Meta <td">src/marketing/src/Meta/config/reporting_settings.yaml </td"></td"><td">Marketing: Salesforce Marketing Cloud <td">src/marketing/src/SFMC/config/reporting_settings.yaml </td"></td"><td">Marketing: TikTok <td">src/marketing/src/TikTok/config/reporting_settings.yaml </td"></td"><td">Marketing: YouTube (con DV360) <td">src/marketing/src/DV360/config/reporting_settings.yaml </td"></td"><td">Marketing: Google Analytics 4 <td">src/marketing/src/GA4/config/reporting_settings.yaml </td"></td"><td">Marketing: Cross Media & Product Connected Insights <td">src/marketing/src/CrossMedia/config/reporting_settings.yaml </td"></td">

Cómo personalizar 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 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.

Primero, el implementador crea todos los objetos de BigQuery que se indican en bq_independent_objects y, luego, 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: 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: 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: Es la forma en que 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 personalizadas de agrupamiento y partición. Esto puede mejorar significativamente el rendimiento de las consultas en conjuntos de datos grandes. 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, especifica lo 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 la partición de una tabla determinada:

<td">Propiedad <td">Descripción <td">Valor </td"></td"></td"><td">column <td">Columna por la que se particiona la tabla de CDC. <td">Nombre de la columna. </td"></td"></td"><td">partition_type <td">Tipo de partición. <td">"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 rangos de números enteros. </td"></td"></td"><td">time_grain <td">Parte de tiempo para particionar Obligatorio cuando es partition_type = "time". <td">"hour", "day", "month" o "year". </td"></td"></td"><td">integer_range_bucket <td">Intervalo de discretización Se requiere cuando partition_type = "integer_range" <td">"start" = Valor inicial, "end" = Valor final y "interval = Intervalo del rango. </td"></td"></td">

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 del clúster de una tabla determinada:

<td">Propiedad <td">Descripción <td">Valor </td"></td"></td"><td">columns <td">Columnas por las que se agrupa una tabla en clústeres. <td">Lista de nombres de columnas. Por ejemplo, "mjahr" y "matnr". </td"></td"></td">

Para obtener más información sobre las opciones y las limitaciones relacionadas, consulta la documentación sobre clústeres 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.