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.
   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 malha de dados.
   enableTaskDependencies	DAGs dependentes de tarefas	false	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.
   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 em que o conjunto de dados do BigQuery e os buckets do Cloud Storage estão. Consulte as restrições listadas em Locais de conjuntos de dados do BigQuery.
   testDataProject	Origem para 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 sua própria estrutura de teste.
   k9.datasets.processing	Conjuntos de dados 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 entre cargas de trabalho e fontes de dados externas (por exemplo, clima), conforme definido no arquivo de configuração K9. Por padrão, esse campo é comentado.
   DataMesh.deployDescriptions	Malha de dados: descrições de recursos	true	Implantar descrições de esquema de recursos do BigQuery.
   DataMesh.deployLakes	Data mesh: lagos e zonas	false	Implante data lakes e zonas do Dataplex Universal Catalog que organizam tabelas por camada de processamento. Isso requer configuração antes da ativação.
   DataMesh.deployCatalog	Data Mesh: tags e modelos do catálogo	false	Implante tags do Data Catalog que permitem metadados personalizados em recursos ou campos do BigQuery. Isso requer configuração antes da ativação.
   DataMesh.deployACLs	Data Mesh: controle de acesso	false	Implante o controle de acesso no nível do recurso, da linha ou da coluna em recursos do BigQuery. Isso exige configuração antes da ativação.

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:

• Desativação da telemetria.
• Configuração de conjuntos de dados externos para o K9.
• Verifique se há tags CORTEX-CUSTOMER.

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 do Cortex Framework Data Foundation:

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 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.

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: 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 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 grandes conjuntos de dados. 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:

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:

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. Estabelecer cargas de trabalho.
2. Clonar 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.