Criação de módulos de produtos de dados

Para definir sua própria lógica de negócios e modelos analíticos, crie um módulo de produto de dados personalizado. Isso permite executar cálculos nas tabelas de base ou em produtos de dados upstream e agrupar os resultados em conjuntos de dados implantáveis.

Observação: siga as instruções de configuração manual ou use habilidades de IA pré-empacotadas para fazer o scaffolding e verificar seus módulos de forma autônoma. Para mais detalhes sobre fluxos de trabalho assistidos por IA, consulte Criação de produtos de dados com agentes.

Pré-requisitos

Recomendamos criar módulos de produtos de dados personalizados em um namespace personalizado dedicado para melhorar o gerenciamento do ciclo de vida. Além disso, verifique se a tabela de origem que você planeja usar existe no conjunto de dados da base de dados.

Criação de um módulo de produto de dados

A definição do módulo de produto de dados exige estas etapas:

• Registro do módulo de produto de dados no arquivo config/config.yaml, estendendo a lista data.modules.products com a entrada:

data:
  # Configuration for data foundation and product modules.
  modules:
    # List of data product modules.
    products:
        # Recommended naming for product_module_id:
        # custom_namespace_product_name
      - moduleId:  product_module_id
        # Path of the data product (namespaced).
        modulePath:  custom_namespace.system_type.products.product_name
        # Map of module dependencies.
        dependencyBindings:
          sapModule: erp
          sapModuleCustNS:  foundation_module_id
        # Reference to the target dataset ID.
        dataTargetId: product_target
        # Whether the module is enabled.
        # enabled: true
        # Whether the foundation is external (does not create target dataset).
        # external: false
        # Custom table settings file, relative to 'config/' file directory
        # Recommended path: '{custom_namespace}/{system_type}/products/{product_name}/table_settings.yaml'
        # If omitted, defaults to '../src/data_modules/{custom_namespace}/{system_type}/products/{product_name}/table_settings.default.yaml'
        # tableSettings: "{custom_namespace}/{system_type}/products/{product_name}/table_settings.yaml"
        

• Criação do arquivo tableSettings padrão (por exemplo, src/data_modules/custom_namespace/system_type/products/product_name/table_settings.default.yaml).

Esse YAML controla configurações de tabela, como materializações e detalhes de otimização do BigQuery:

common:
  custom_sales_summary:
    materializationType: "table"
    bigQueryLabels:
      - key: data_class
        value: transactional
    dataformTags: ["custom", "sales", "reporting"]
    partitionDetails:
      column: "created_date"
      partitionType: "date"
      timeGrain: "day"
    clusterDetails:
      columns:
        - "customer_id"

• Criação de arquivo de anotação

O arquivo de anotação tablename.yaml é criado para cada artefato de saída do produto de dados (tabela, visualização) e descreve colunas e campos no formato YAML. Durante a compilação, o builder pesquisa automaticamente anotações na pasta annotations/ do produto (por exemplo, src/data_modules/custom_namespace/system_type/products/product_name/annotations/custom_sales_summary.yaml) e mescla essas strings diretamente nas definições de esquema de saída do Dataform para que sejam preservadas nos metadados da tabela do BigQuery.

Um arquivo de anotação src/data_modules/custom_namespace/system_type/products/product_name/annotations/tablename.yaml tem o formato:

description: "Description of the table or view purpose"
fields:
  - name: "customer_id"                     # column name
    description: "Customer identifier"      # column description
  - name: "column2"
    description: "Description of Column 2"
  - name: "column3"
    description: "Description of Column 3"

• Crie um arquivo manifest.yaml na pasta do produto de dados src/data_modules/custom_namespace/system_type/products/product_name/, mantendo o tipo, a categoria, as tabelas e as dependências do módulo. O arquivo de manifesto segue este formato:

displayName: Sales Performance Summary
description: Sales performance analytical data product.
category: product
type: generic
builder: sap_product     # Automatically resolves to the global SapProductBuilder fallback
dependencies:
  sapModule:
    modulePath: cortex.sap.foundations.sap
    supportedVersions:
      - ecc
      - s4

Exemplo de módulo de produto de dados

As etapas para implementar o produto de dados flights_usd no namespace sap_bookingdatamodel do exemplo de voos são:

• Registro do módulo de produto de dados no arquivo config/config.yaml, estendendo a lista data.modules.products com a entrada:

data:
  modules:
    products:
      - moduleId: sap_bookingdatamodel_flights_usd
        modulePath: sap_bookingdatamodel.sap.products.flights_usd
        dependencyBindings:
          sapModule: erp
          sapModuleCustNS: sap_bookingdatamodel
        dataTargetId: product_target

• Em seguida, crie src/data_modules/sap_bookingdatamodel/sap/products/flights_usd/manifest.yaml com o conteúdo

displayName: Flights USD
description: Flight scheduling and pricing USD data product.
category: product
type: generic
dependencies:
  sapModule:
    modulePath: cortex.sap.foundations.sap
    supportedVersions:
      - ecc
      - s4
    tables:
      common:
        - tcurr
  sapModuleCustNS:
    # Type of the dependent Module.
    # use cortex.sap.foundations.sap if you followed "Configure multiple instances of a data foundation module"
    # https://docs.cloud.google.com/cortex/docs/deployment-configuration#multiple-data-foundation-instances
    modulePath: cortex.sap.foundations.sap
    # use sap_bookingdatamodel.sap.foundations.sap if you are connecting to custom-data foundation module:
    # https://docs.cloud.google.com/cortex/docs/extensibility-guide-data-foundation
    #modulePath: sap_bookingdatamodel.sap.foundations.sap
    supportedVersions:
      - ecc
      - s4
    tables:
      common:
        - sflight
builder: sap_product

• Na próxima etapa, crie o arquivo de configurações de tabela referenciado para configurar o esquema e os metadados das tabelas ou visualizações de saída no BigQuery.

No exemplo usado, crie: src/data_modules/sap_bookingdatamodel/sap/products/flights_usd/table_settings.default.yaml com o conteúdo:

ecc:
  flights_usd:
    materializationType: incremental
    bigQueryLabels:
      - key: data_class
        value: transactional
    dataformTags: [sap, dataproduct, masterdata]
s4:
  flights_usd:
    materializationType: incremental
    bigQueryLabels:
      - key: data_class
        value: transactional
    dataformTags: [sap, dataproduct, masterdata]

• Crie anotações para tabelas de produtos de dados para enriquecer o esquema de armazenamento com descrições.

No exemplo usado, crie o arquivo: src/data_modules/sap_bookingdatamodel/sap/products/flights_usd/annotations/flights_usd.yaml com o conteúdo:

description: "Flight scheduling and pricing information, including currency conversion to USD."
fields:
  - name: "client_mandt"
    description: "Client (Mandant), PK"
  - name: "airline_code_carrid"
    description: "Airline Carrier ID, PK"
  - name: "flight_connection_number_connid"
    description: "Flight Number, PK"
  - name: "flight_date_fldate"
    description: "Flight Date"
  - name: "price_usd"
    description: "Price in USD"
  - name: "price"
    description: "Price in local currency"
  - name: "currency"
    description: "Local currency"

• A lógica de negócios do produto de dados é armazenada em arquivos js ou sqlx.

Observação: para produtos de dados com diferenças na lógica de dialetos diferentes (por exemplo, SAP ECC e S/4HANA), use as subpastas ecc e s4 da pasta definitions.

Observação: os arquivos criados na pasta definitions/ do módulo local são compilados pelo cortex-build e sincronizados com o espaço de trabalho remoto do Dataform durante a implantação. Se você precisar adicionar código personalizado diretamente no espaço de trabalho remoto do Dataform usando o Google Cloud console sem criar um módulo no controle de origem, coloque os arquivos em definitions/custom/ no repositório remoto do Dataform. Todos os arquivos não gerenciados no repositório remoto do Dataform fora de definitions/custom/ serão substituídos ou excluídos na próxima execução de implantação (cortex-deploy).

No exemplo fornecido, crie o arquivo src/data_modules/sap_bookingdatamodel/sap/products/flights_usd/definitions/flights_usd.js com o conteúdo:

// ___MODULE_CONTEXT___
// ___TABLE_CONFIG___

const moduleConfig = config.product[moduleContext.moduleId];
const sapModuleConfigDatasetId = moduleConfig.sources.sapModule.datasetId;
const sapModuleCustNSConfigDatasetId = moduleConfig.sources.sapModuleCustNS.datasetId;

const materializationType = tableConfig.materializationType || "incremental";

const incremental = require("includes/cortex/incremental.js");
const publish_config = require("includes/cortex/publish_config.js");

const publishConfig = publish_config.getPublishConfig(
   materializationType,
   tableConfig,
   moduleConfig,
   [
       "client_mandt",
       "airline_code_carrid",
       "flight_connection_number_connid",
       "flight_date_fldate"
   ]
);

publish("flight_usd", publishConfig).query(
   (ctx) => `
WITH flight_base AS (
   SELECT
       mandt,
       carrid,
       connid,
       fldate,
       price,
       currency,
       -- Convert flight date string (YYYYMMDD) to an integer to calculate SAP's inverted date key
       CAST(99999999 - CAST(fldate AS INT64) AS STRING) AS inverted_fldate
   FROM   ${ctx.ref(sapModuleCustNSConfigDatasetId, 'sflight')} AS flight
),
ranked_exchange_rates AS (
   SELECT
       f.mandt,
       f.carrid,
       f.connid,
       f.fldate,
       f.price,
       f.currency,
       t.ukurs,
       -- Window function to grab the closest historical exchange rate
       ROW_NUMBER() OVER (
           PARTITION BY f.mandt, f.carrid, f.connid, f.fldate
           ORDER BY t.gdatu ASC
       ) AS latest_rate_rank
   FROM flight_base f
   LEFT JOIN ${ctx.ref(sapModuleConfigDatasetId, 'tcurr')} AS t
     ON f.mandt = t.mandt
    AND t.kurst = 'M'       -- 'M' is the standard SAP default for average exchange rates
    AND t.fcurr = f.currency
    AND t.tcurr = 'USD'
    -- Chronological (rate_date <= flight_date) translates to (t.gdatu >= inverted_fldate)
    AND t.gdatu >= f.inverted_fldate
)

SELECT
   client_mandt,
   airline_code_carrid,
   flight_connection_number_connid,
   flight_date_fldate,
   price,
   currency,
   price_usd,
   CURRENT_TIMESTAMP() AS bq_loaded_at
FROM (
  SELECT
    mandt              AS client_mandt,
    carrid             AS airline_code_carrid,
    connid             AS flight_connection_number_connid,
    PARSE_TIMESTAMP('%Y%m%d', fldate) AS flight_date_fldate,
    price              AS price,
    currency           AS currency,
    -- Currency Conversion Logic
    CASE
       WHEN currency = 'USD' THEN price
       WHEN ukurs IS NULL   THEN NULL -- Handles cases where no exchange rate is found
       -- If UKURS is negative, it's an indirect quotation (1 USD = X Local) -> Divide
       WHEN ukurs < 0       THEN ROUND(price / ABS(ukurs), 2)
       -- If UKURS is positive, it's a direct quotation (1 Local = X USD) -> Multiply
       ELSE ROUND(price * ukurs, 2)
     END AS price_usd
  FROM ranked_exchange_rates
  WHERE latest_rate_rank = 1
)
${incremental.getWhere(ctx, ["flight_date_fldate"])}
`
);

Verificação da extensão do namespace personalizado

Para verificar a criação bem-sucedida de módulos de produtos de dados do Google Cloud Cortex Framework, siga estas etapas:

• Execute a implantação do Cortex Framework referenciando o arquivo config.yaml atualizado.
• Siga as etapas pós-implantação para executar as ações do Dataform e verificar os resultados no BigQuery.

---

• Etapa anterior: criação de módulos da base de dados
• Próxima etapa: etapas pós-implantação
• Voltar à visão geral