Etapa 5: configurar a implantação

Esta página descreve a quinta etapa para implantar a Data Foundation do Cortex Framework, que é 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:

    <td"> Parâmetro <td">Significado <td">Valor padrão <td">Descrição </td"></td"></td"></td"><td">testData <td">Implantar dados de teste <td">true <td">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. </td"></td"></td"><td">deploySAP <td">Implantar o SAP <td">true <td">Execute a implantação para a carga de trabalho do SAP (ECC ou S/4 HANA). </td"></td"></td"></td"><td">deploySFDC <td">Implantar o Salesforce <td">true <td">Execute a implantação da carga de trabalho do Salesforce. </td"></td"></td"></td"><td">deployMarketing <td">Implantar marketing <td">true <td">Execute a implantação para fontes de marketing (Google Ads, CM360 e TikTok). </td"></td"></td"></td"><td">deployOracleEBS <td">Implantar o Oracle EBS <td">true <td">Execute a implantação para a carga de trabalho do Oracle EBS. </td"></td"></td"></td"><td">enableTaskDependencies <td">DAGs dependentes de tarefas <td">false <td">Ative os 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. </td"></td"></td"></td"><td">turboMode <td">Implante no modo turbo. <td">true <td">Execute todos os builds de visualizações como uma etapa no mesmo processo de build do Cloud Build, em paralelo para uma implantação mais rápida. Se definido como false, cada vista de relatórios será generada 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. </td"></td"></td"></td"><td">projectIdSource <td">ID do projeto de origem <td">- <td">Projeto em que o conjunto de dados de origem está e a build é executada. </td"></td"></td"></td"><td">projectIdTarget <td">ID do projeto de destino <td">- <td">Projeto de destino para conjuntos de dados voltados ao usuário. </td"></td"></td"></td"><td">targetBucket <td">Bucket de destino para armazenar scripts de DAG gerados <td">- <td">Bucket criado anteriormente em que os DAGs (e arquivos temporários do Dataflow) são gerados. Evite usar o bucket real do Airflow. </td"></td"></td"></td"><td">location <td">Local ou região <td">"US" <td">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.

    </td"></td"></td"></td"><td">testDataProject <td">Fonte para o ambiente de teste <td">kittycorn-public <td">Fonte 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 sua própria estrutura de teste.

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

  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 computam 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 incorrer em custos de computação mais altos e alcançar 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 do Cortex Framework Data Foundation:

<td">Origem de dados <td">Arquivos de configurações </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 (com 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: insights de produtos e crossmedia conectados <td">src/marketing/src/CrossMedia/config/reporting_settings.yaml </td"></td">

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 seguintepartition_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:

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

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:

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

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.