Etapa 5: configurar a implantação

Esta página descreve a quinta etapa para implantar a Data Foundation do Cortex Framework, o núcleo do Cortex Framework. Nesta etapa, você vai modificar o arquivo de configuração no repositório do Cortex Framework Data Foundation para atender aos seus requisitos.

Arquivo de configuração

O comportamento da implantação é controlado pelo arquivo de configuração config.json na base de dados do Cortex Framework. Esse arquivo contém a configuração global e específica para cada carga de trabalho. Edite o arquivo config.json de acordo com suas necessidades seguindo estas etapas:

  1. Abra o arquivo config.json no Cloud Shell.

  2. Edite o arquivo config.json de acordo com os seguintes parâmetros:

    Parâmetro Significado Valor padrão Descrição
    testData Implantar dados de teste true Projeto em que o conjunto de dados de origem está e a build é executada. Observação: a implantação de dados de teste só será executada se o conjunto de dados bruto estiver vazio e não tiver tabelas.
    deploySAP Implantar o SAP true Execute a implantação para carga de trabalho do SAP (ECC ou S/4 HANA).
    deploySFDC Implantar o Salesforce true Execute a implantação da carga de trabalho do Salesforce.
    deployMarketing Implantar marketing true Execute a implantação para fontes de marketing (Google Ads, CM360 e TikTok).
    deployOracleEBS Implantar o Oracle EBS true Execute a implantação da carga de trabalho do Oracle EBS.
    enableTaskDependencies DAGs dependentes de tarefas false Ative DAGs dependentes de tarefas para que as tabelas SQL compatíveis sejam executadas com base na ordem de dependência em DAGs únicos. Para mais informações, consulte DAGs dependentes de tarefas.
    turboMode Implante no modo turbo. true Execute todos os builds de visualizações como uma etapa no mesmo processo do Cloud Build, em paralelo para uma implantação mais rápida. Se definido como false, cada visualização de relatórios será gerada em uma etapa de build sequencial própria. Recomendamos definir como true apenas ao usar dados de teste ou depois que qualquer incompatibilidade entre as colunas de relatórios e os dados de origem for resolvida.
    projectIdSource ID do projeto de origem - Projeto em que o conjunto de dados de origem está e a build é executada.
    projectIdTarget ID do projeto de destino - Projeto de destino para conjuntos de dados voltados ao usuário.
    targetBucket Bucket de destino para armazenar scripts de DAG gerados - Bucket criado anteriormente em que os DAGs (e arquivos temporários do Dataflow) são gerados. Evite usar o bucket real do Airflow.
    location Local ou região "US" Local onde estão o conjunto de dados do BigQuery e os buckets do Cloud Storage.

    Consulte as restrições listadas em Locais de conjuntos de dados do BigQuery.

    testDataProject Origem do arcabouço de testes kittycorn-public Origem dos dados de teste para implantações de demonstração. Aplicável quando testData é true.

    Não mude esse valor, a menos que você tenha seu próprio ambiente de teste.

    k9.datasets.processing Conjuntos de dados do K9: processamento "K9_PROCESSING" Execute modelos entre cargas de trabalho (por exemplo, dimensão de data) conforme definido no arquivo de configuração do K9. Esses modelos são normalmente exigidos pelas cargas de trabalho downstream.
    k9.datasets.reporting Conjuntos de dados do K9: relatórios "K9_REPORTING" Execute modelos de carga de trabalho cruzada e fontes de dados externas (por exemplo, clima) conforme definido no arquivo de configuração K9. Por padrão, esse campo é comentado.

  3. Configure as cargas de trabalho necessárias conforme necessário. Não é necessário configurar se o parâmetro de implantação (por exemplo, deploySAP ou deployMarketing) da carga de trabalho estiver definido como False. Para mais informações, consulte Etapa 3: determinar o mecanismo de integração.

Para uma melhor personalização da implantação, consulte as etapas opcionais a seguir:

Otimização de performance para visualizações de relatórios

Os artefatos de relatórios podem ser criados como visualizações ou tabelas atualizadas regularmente por DAGs. Por um lado, as visualizações calculam os dados em cada execução de uma consulta, o que mantém os resultados sempre atualizados. Por outro lado, a tabela executa os cálculos uma vez, e os resultados podem ser consultados várias vezes sem gerar custos de computação mais altos e alcançando um tempo de execução mais rápido. Cada cliente cria a própria configuração de acordo com as necessidades.

Os resultados materializados são atualizados em uma tabela. Essas tabelas podem ser ainda mais ajustadas com a adição de particionamento e clustering.

Os arquivos de configuração de cada carga de trabalho estão localizados nos seguintes caminhos no repositório da Data Foundation do Cortex Framework:

Fonte de dados Arquivos de configurações
Operacional: SAP src/SAP/SAP_REPORTING/reporting_settings_ecc.yaml
Operacional: 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 (com o DV360) src/marketing/src/DV360/config/reporting_settings.yaml
Marketing: Google Analytics 4 src/marketing/src/GA4/config/reporting_settings.yaml
Marketing: insights conectados de produtos e crossmedia src/marketing/src/CrossMedia/config/reporting_settings.yaml

Personalizar o arquivo de configurações de relatórios

Os arquivos reporting_settings orientam a criação dos objetos do BigQuery (tabelas ou visualizações) para conjuntos de dados de relatórios. Personalize seu arquivo com as descrições de parâmetros a seguir. Considere que esse arquivo contém duas seções:

  1. bq_independent_objects: todos os objetos do BigQuery que podem ser criados de forma independente, sem outras dependências. Quando o Turbo mode está ativado, esses objetos do BigQuery são criados em paralelo durante o tempo de implantação, acelerando o processo.
  2. bq_dependent_objects: todos os objetos do BigQuery que precisam ser criados em uma ordem específica devido a dependências de outros objetos do BigQuery. Turbo mode não se aplica a esta seção.

Primeiro, o implantador cria todos os objetos do BigQuery listados em bq_independent_objects e, em seguida, todos os objetos listados em bq_dependent_objects. Defina as seguintes propriedades para cada objeto:

  1. sql_file: nome do arquivo SQL que cria um objeto específico.
  2. type: tipo de objeto do BigQuery. Valores possíveis:
    • view : se você quer que o objeto seja uma visualização do BigQuery.
    • table: se você quer que o objeto seja uma tabela do BigQuery.
    • script: isso é para criar outros tipos de objetos (por exemplo, funções e processos armazenados do BigQuery).
  3. Se type estiver definido como table, as seguintes propriedades opcionais poderão ser definidas:
    • load_frequency: frequência com que um DAG do Composer é executado para atualizar essa tabela. Consulte a documentação do Airflow para detalhes sobre os valores possíveis.
    • partition_details: como a tabela deve ser particionada. Esse valor é opcional. Para mais informações, consulte a seção Partição de tabela.
    • cluster_details: como a tabela deve ser agrupada. Esse valor é opcional. Para mais informações, consulte a seção Configurações do cluster.

Partição de tabela

Alguns arquivos de configurações permitem configurar tabelas materializadas com opções personalizadas de clustering e particionamento. Isso pode melhorar significativamente o desempenho da consulta em conjuntos de dados grandes. Essa opção se aplica apenas a SAP cdc_settings.yaml e todos os arquivos reporting_settings.yaml.

Para ativar o particionamento de tabela, especifique o seguinte partition_details:

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

Use os seguintes parâmetros para controlar detalhes de particionamento de uma determinada tabela:

Propriedade Descrição Valor
column Coluna pela qual a tabela de CDC é particionada. Nome da coluna.
partition_type Tipo de partição. "time" para partição baseada em tempo. Para mais informações, consulte Tabelas particionadas por carimbo de data/hora. "integer_range" para partição com base em números inteiros. Para mais informações, consulte a documentação sobre intervalos de números inteiros.
time_grain Período para particionar. Obrigatório quando partition_type = "time". "hour", "day", "month" ou "year".
integer_range_bucket Intervalo do bucket Obrigatório quando partition_type = "integer_range" "start" = valor inicial, "end" = valor final e "interval = intervalo do período.

Para mais informações sobre opções e limitações relacionadas, consulte Partição de tabela do BigQuery.

Configurações de cluster

Para ativar o clustering de tabela, especifique cluster_details:

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

Use os parâmetros a seguir para controlar os detalhes do cluster de uma determinada tabela:

Propriedade Descrição Valor
columns Colunas pelas quais uma tabela é agrupada. Lista de nomes de colunas. Por exemplo, "mjahr" e "matnr".

Para mais informações sobre opções e limitações relacionadas, consulte a documentação sobre clusters de tabelas.

Próximas etapas

Depois de concluir esta etapa, passe para a seguinte etapa de implantação:

  1. Estabeleça cargas de trabalho.
  2. Clone o repositório.
  3. Determine o mecanismo de integração.
  4. Configurar componentes.
  5. Configurar a implantação (esta página).
  6. Executar a implantação.