Etapa 5: configurar a implantação

Esta página descreve a quinta etapa para implantar a Cortex Data Foundation, 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 no Cortex Framework Data Foundation. Esse arquivo contém a configuração global e específica de 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 Implante dados de teste. true Projeto em que o conjunto de dados de origem está e o build é executado. Observação: a implantação de dados de teste só será executada se o conjunto de dados brutos 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/4HANA).
    deploySFDC Implantar o Salesforce true Execute a implantação para a carga de trabalho do Salesforce.
    deployMarketing Implantar o marketing true Execute a implantação para origens de marketing (Google Ads, CM360 e TikTok).
    deployOracleEBS Implantar o Oracle EBS true Execute a implantação para a carga de trabalho do Oracle EBS.
    deployDataMesh Implantar a malha de dados true Execute a implantação da malha de dados. Para mais informações, consulte o Guia do usuário da Data Mesh.
    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ório é gerada na própria etapa de build sequencial. Recomendamos definir o valor como true apenas quando usar dados de teste ou depois que qualquer incompatibilidade entre as colunas do relatório e os dados de origem for resolvida.
    projectIdSource ID do projeto de origem - Projeto em que o conjunto de dados de origem está e o build é executado.
    projectIdTarget ID do projeto de destino - Projeto de destino para conjuntos de dados voltados ao usuário (relatórios e conjuntos de dados de ML).
    targetBucket Bucket de destino para scripts de DAG gerados no armazenamento - Bucket criado anteriormente em que os DAGs (e arquivos temporários do Dataflow) são gerados. Evite usar o bucket do Airflow.
    location Local ou região "US" Local onde estão os buckets do BigQuery e 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 harness de teste.

    k9.datasets.processing Conjuntos de dados do K9: processamento "K9_PROCESSING" Executar modelos de carga de trabalho (por exemplo, dimensão de data) conforme definido no arquivo de configuração K9. Esses modelos normalmente são necessários para as cargas de trabalho downstream.
    k9.datasets.reporting Conjuntos de dados do K9: relatórios "K9_REPORTING" Executar modelos de carga de trabalho e fontes de dados externas (por exemplo, clima) conforme definido no arquivo de configuração do K9. Desativado por padrão.
    DataMesh.deployDescriptions Data Mesh: descrições de recursos true Implante descrições de esquema de recursos do BigQuery.
    DataMesh.deployLakes Data Mesh: lagos e zonas false Implantar lagos e zonas do Dataplex que organizam tabelas por camada de processamento exige configuração antes da ativação.
    DataMesh.deployCatalog Data Mesh: tags e modelos do catálogo false Implantar tags do Data Catalog que permitem metadados personalizados em recursos ou campos do BigQuery requer configuração antes da ativação.
    DataMesh.deployACLs Data Mesh: controle de acesso false Implantar o controle de acesso no nível do recurso, da linha ou da coluna em recursos do BigQuery requer configuração antes da ativação.

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

Para personalizar melhor a 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 como tabelas atualizadas regularmente pelos 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 as computações 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. É possível fazer ajustes adicionais nessas tabelas adicionando particionamento e clustering.

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

Fonte de dados Arquivos de configuração
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 mídias cruzadas src/marketing/src/CrossMedia/config/reporting_settings.yaml

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

Os arquivos reporting_settings determinam como os objetos do BigQuery (tabelas ou visualizações) são criados para gerar relatórios de conjuntos de dados. Personalize seu arquivo com as descrições de parâmetros a seguir. Considere que este 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 a Turbo mode está ativada, esses objetos do BigQuery são criados em paralelo durante a 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.

O implantador primeiro 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.
  2. type: tipo de objeto do BigQuery. Valores possíveis:
    • view : se você quiser que o objeto seja uma visualização do BigQuery.
    • table: se você quiser que o objeto seja uma tabela do BigQuery.
    • script: serve para criar outros tipos de objetos, como 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 em que um DAG do Composer é executado para atualizar essa tabela. Consulte a documentação do Airflow para saber mais sobre os valores possíveis.
    • partition_details: como a tabela deve ser particionada. Esse valor é opcional. Para mais informações, consulte a seção Particionamento de tabelas.
    • 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ção permitem que você configure tabelas materializadas com opções personalizadas de clustering e particionamento. Isso pode melhorar significativamente a performance da consulta em grandes conjuntos de dados. Essa opção se aplica apenas a SAP cdc_settings.yaml e a todos os arquivos reporting_settings.yaml.

Para ativar o particionamento de tabelas, 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 os detalhes de particionamento de uma determinada tabela:

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

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

Configurações de cluster

É possível ativar o clustering de tabelas especificando 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 em que 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 do cluster de tabelas.

Próximas etapas

Depois de concluir esta etapa, passe para a próxima etapa de implantação:

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