Migración de DAGs externos de la versión 4.2 a la 5.0

En esta guía, se describen los pasos necesarios para reubicar las tablas de salida de los gráficos acíclicos dirigidos (DAG) externos a sus nuevas ubicaciones dentro de la arquitectura de Cortex Data Foundation v5.0. Por ejemplo, Clima y Tendencias. Esta guía está diseñada específicamente para los usuarios que implementaron DAG externos en versiones anteriores de Data Foundation de Framework de Cortex (de 4.2 a 5.0) y ahora realizan la actualización. Si no usaste DAG externos ni implementaste SAP, esta guía no es aplicable.

Contexto

Las versiones anteriores a la 4.2 de Cortex Framework Data Foundation usaban una marca _GEN_EXT para administrar la implementación de fuentes de datos externas, con algunas fuentes vinculadas a cargas de trabajo específicas (como la conversión de moneda para SAP). Sin embargo, con la versión 5.0, se quitó esta marca. Ahora, hay un nuevo módulo dedicado a administrar DAGs que pueden entregar varias cargas de trabajo. En esta guía, se describen los pasos para ajustar tus canalizaciones de datos existentes para que funcionen con esta nueva estructura.

DAG reutilizables entre cargas de trabajo

La versión 5.0 de la base de datos de Cortex Framework presenta K9, un nuevo componente responsable de la transferencia, el procesamiento y el modelado de elementos de datos reutilizables que se comparten en varias fuentes de datos. Las vistas de informes ahora hacen referencia al conjunto de datos K9_PROCESSING para acceder a estos componentes reutilizables, lo que optimiza el acceso a los datos y reduce la redundancia. Las siguientes fuentes de datos externas ahora se implementan como parte de K9 en el conjunto de datos K9_PROCESSING:

  • date_dimension
  • holiday_calendar
  • trends
  • weather

DAGs dependientes de SAP

La siguiente secuencia de comandos de generate_external_dags.sh sigue activando los DAGs dependientes de SAP, pero ahora se ejecuta durante el paso de compilación de informes y escribe en el conjunto de datos de informes de SAP en lugar de la etapa de CDC (captura de datos modificados).

  • currency_conversion
  • inventory_snapshots
  • prod_hierarchy_texts

Guía de migración

En esta guía, se describen los pasos para actualizar tu base de datos de Cortex Framework a la versión 5.0.

Implementa Cortex Framework Data Foundation 5.0

Primero, implementa la versión más reciente (v5.0) de Cortex Framework Data Foundation en tus proyectos con los siguientes lineamientos:

  1. Usa tus conjuntos de datos sin procesar y de CDC existentes de implementaciones anteriores de desarrollo o pruebas como tus conjuntos de datos sin procesar y de CDC de esta implementación, ya que no se les hace ninguna modificación durante la implementación.
  2. Establece testData y SAP.deployCDC en False en config/config.json.
  3. Crea un nuevo proyecto de informes de SAP independiente de tu entorno v4.2 existente para realizar pruebas. Esto evalúa de forma segura el proceso de actualización sin afectar tus operaciones actuales.
  4. Opcional. Si tienes DAG de Airflow activos en ejecución para tu versión anterior de Data Foundation de Framework de Cortex, deténlos antes de continuar con la migración. Esto se puede hacer a través de la IU de Airflow. Para obtener instrucciones detalladas, consulta Cómo abrir la IU de Airflow desde Composer y la documentación sobre cómo pausar el DAG.

Si sigues estos pasos, puedes realizar la transición de forma segura a la versión 5.0 de Cortex Framework Data Foundation y validar las nuevas funciones y funcionalidades.

Cómo migrar tablas existentes

Para migrar tus tablas existentes a su nueva ubicación, usa jinja-cli para dar formato a la plantilla de secuencia de comandos de migración proporcionada y completar la migración.

  1. Instala jinja-cli con el siguiente comando:

    pip install jinja-cli

  2. Identifica los siguientes parámetros de tu implementación existente de la versión 4.2 y de la nueva versión 5.0:

    Nombre Descripción
    project_id_src Proyecto Google Cloud de origen: Es el proyecto en el que se encuentra tu conjunto de datos de CDC de SAP existente de la implementación de la versión 4.2. El conjunto de datos K9_PROCESSING también se crea en este proyecto.
    project_id_tgt Es el objetivo Google Cloud en el que se encuentra el conjunto de datos de informes de SAP que se implementó recientemente en la nueva implementación de la versión 5.0. Esto puede ser diferente del proyecto de origen.
    dataset_cdc_processed Conjunto de datos de BigQuery de CDC: Es el conjunto de datos de BigQuery en el que los datos procesados por la CDC llegan a los registros más recientes disponibles. Puede ser igual que el conjunto de datos de origen.
    dataset_reporting_tgt Conjunto de datos de informes de BigQuery de destino: Es el conjunto de datos de BigQuery en el que se implementan los modelos de datos predefinidos de Data Foundation for SAP.
    k9_datasets_processing Conjunto de datos de BigQuery de K9: Es el conjunto de datos de BigQuery en el que se implementa K9 (fuentes de datos aumentadas).

  3. Crea un archivo JSON con los datos de entrada necesarios. Asegúrate de quitar los DAG que no quieras migrar de la sección migrate_list:

    {
  "project_id_src": "your-source-project",
  "project_id_tgt": "your-target-project",
  "dataset_cdc_processed": "your-cdc-processed-dataset",
  "dataset_reporting_tgt": "your-reporting-target-dataset-OR-SAP_REPORTING",
  "k9_datasets_processing": "your-k9-processing-dataset-OR-K9_REPORTING",
  "migrate_list":
    [
        "holiday_calendar",
        "trends",
        "weather",
        "currency_conversion",
        "inventory_snapshots",
        "prod_hierarchy_texts"
    ]
}
EOF

    Por ejemplo, si quieres quitar weather y trends, la secuencia de comandos se vería de la siguiente manera:

    {
  "project_id_src": "kittycorn-demo",
  "project_id_tgt": "kittycorn-demo",
  "dataset_cdc_processed": "CDC_PROCESSED",
  "dataset_reporting_tgt": "SAP_REPORTING",
  "k9_datasets_processing": "K9_PROCESSING",
  "migrate_list":
    [
        "holiday_calendar",
        "currency_conversion",
        "inventory_snapshots",
        "prod_hierarchy_texts"
    ]
    }

  4. Crea una carpeta de salida con el siguiente comando:

      mkdir output

  5. Genera la secuencia de comandos de migración analizada con el siguiente comando (este comando asume que te encuentras en la raíz del repositorio):

      jinja -d data.json -o output/migrate_external_dags.sql docs/external_dag_migration/scripts/migrate_external_dags.sql

  6. Examina el archivo SQL de salida y ejecútalo en BigQuery para migrar tus tablas a la nueva ubicación.

Actualiza y reanuda los DAG de Airflow

Crea una copia de seguridad de los archivos DAG actuales en tu bucket de Airflow. Luego, reemplázalos por los archivos generados recientemente de la implementación de la versión 5.0 de Data Foundation de Cortex Framework. Para obtener instrucciones detalladas, consulta la siguiente documentación:

Validación y limpieza

Se completó la migración. Ahora puedes validar que todas las vistas de informes de la nueva implementación de informes de la versión 5.0 funcionen correctamente. Si todo funciona correctamente, vuelve a realizar el proceso, esta vez, segmentando la implementación de la versión 5.0 para tu conjunto de informes de producción. Luego, no dudes en quitar todas las tablas con la siguiente secuencia de comandos:

    jinja -d data.json -o output/delete_old_dag_tables.sql docs/external_dag_migration/scripts/delete_old_dag_tables.sql