Passo 5: configure a implementação

Esta página descreve o quinto passo para implementar a Data Foundation do Cortex Framework, o núcleo do Cortex Framework. Neste passo, modifica o ficheiro de configuração no repositório da base de dados do Cortex Framework para corresponder aos seus requisitos.

Ficheiro de configuração

O comportamento da implementação é controlado pelo ficheiro de configuração config.json na Cortex Framework Data Foundation. Este ficheiro contém a configuração global e a configuração específica de cada carga de trabalho. Edite o ficheiro config.json de acordo com as suas necessidades através dos seguintes passos:

  1. Abra o ficheiro config.json a partir do Cloud Shell.

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

    Parâmetro Significado Valor predefinido Descrição
    testData Implemente dados de teste true Projeto onde o conjunto de dados de origem está e a compilação é executada. Nota: a implementação de dados de teste só é executada se o conjunto de dados não processados estiver vazio e não tiver tabelas.
    deploySAP Implemente o SAP true Execute a implementação para a carga de trabalho SAP (ECC ou S/4 HANA).
    deploySFDC Implemente o Salesforce true Execute a implementação para a carga de trabalho do Salesforce.
    deployMarketing Implemente o marketing true Execute a implementação para origens de marketing (Google Ads, CM360 e TikTok).
    deployOracleEBS Implemente o Oracle EBS true Execute a implementação para a carga de trabalho do Oracle EBS.
    deployDataMesh Implemente uma malha de dados true Execute a implementação para a malha de dados. Para mais informações, consulte o manual do utilizador da malha de dados.
    enableTaskDependencies DAGs dependentes de tarefas false Ative os DAGs dependentes de tarefas para que as tabelas SQL suportadas sejam executadas com base na ordem de dependência, em DAGs únicos. Para mais informações, consulte o artigo DAGs dependentes de tarefas.
    turboMode Implemente no Modo turbo. true Executar todas as compilações de visualizações como um passo no mesmo processo do Cloud Build, em paralelo, para uma implementação mais rápida. Se estiver definido como false, cada vista de relatórios é gerada no seu próprio passo de compilação sequencial. Recomendamos que a defina apenas como true quando usar dados de teste ou depois de resolver qualquer incompatibilidade entre as colunas de relatórios e os dados de origem.
    projectIdSource ID do projeto de origem - Projeto onde o conjunto de dados de origem está e a compilação é executada.
    projectIdTarget ID do projeto de destino - Projeto de destino para conjuntos de dados orientados para o utilizador.
    targetBucket Segmentar contentor para armazenar scripts DAG gerados - Recipiente criado anteriormente onde os DAGs (e os ficheiros temporários do Dataflow) são gerados. Evite usar o contentor do Airflow real.
    location Localização ou região "US" Localização onde se encontram o conjunto de dados do BigQuery e os contentores do Cloud Storage.

    Consulte as restrições indicadas em Localizações do conjunto de dados do BigQuery.

    testDataProject Origem da estrutura de teste kittycorn-public Origem dos dados de teste para implementações de demonstração. Aplica-se quando testData é true.

    Não altere este valor, a menos que tenha o seu próprio ambiente de teste.

    k9.datasets.processing Conjuntos de dados K9 – Em processamento "K9_PROCESSING" Executar modelos de várias cargas de trabalho (por exemplo, dimensão de data) conforme definido no ficheiro de configuração K9. Normalmente, estes modelos são necessários para as cargas de trabalho a jusante.
    k9.datasets.reporting Conjuntos de dados de cães – Relatórios "K9_REPORTING" Executar modelos de várias cargas de trabalho e origens de dados externas (por exemplo: meteorologia) conforme definido no ficheiro de configuração K9. Por predefinição, estão comentadas.
    DataMesh.deployDescriptions Data Mesh – Descrições dos recursos true Implemente descrições do esquema de recursos do BigQuery.
    DataMesh.deployLakes Data Mesh – Lagos e zonas false Implemente lagos e zonas do catálogo universal do Dataplex que organizam as tabelas por camada de processamento. Requer configuração antes da ativação.
    DataMesh.deployCatalog Data Mesh – Etiquetas e modelos de catálogo false A implementação de etiquetas do Data Catalog que permitem metadados personalizados em recursos ou campos do BigQuery, requer configuração antes da ativação.
    DataMesh.deployACLs Data Mesh – Controlo de acesso false Implemente o controlo de acesso ao 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 conforme necessário. Não precisa de os configurar se o parâmetro de implementação (por exemplo, deploySAP ou deployMarketing) para a carga de trabalho estiver definido como False. Para mais informações, consulte o Passo 3: determine o mecanismo de integração.

Para uma melhor personalização da implementação, consulte os seguintes passos opcionais:

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

Os artefactos de relatórios podem ser criados como vistas ou como tabelas atualizadas regularmente através de DAGs. Por um lado, as vistas 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 incorrer em custos de computação mais elevados e alcançar um tempo de execução mais rápido. Cada cliente cria a sua própria configuração de acordo com as suas necessidades.

Os resultados materializados são atualizados numa tabela. Pode ajustar ainda mais estas tabelas adicionando Particionamento e Agrupamento a estas tabelas.

Os ficheiros de configuração de cada carga de trabalho encontram-se nos seguintes caminhos no repositório da base de dados do Cortex Framework:

Origem de dados Ficheiros de definiçõ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 – Estatísticas de produtos e multimédia cruzados src/marketing/src/CrossMedia/config/reporting_settings.yaml

Personalizar o ficheiro de definições de relatórios

Os ficheiros reporting_settings determinam como os objetos do BigQuery (tabelas ou vistas) são criados para conjuntos de dados de relatórios. Personalize o ficheiro com as descrições dos seguintes parâmetros. Tenha em atenção que este ficheiro contém duas secções:

  1. bq_independent_objects: todos os objetos do BigQuery que podem ser criados independentemente, sem outras dependências. Quando a opção Turbo mode está ativada, estes objetos do BigQuery são criados em paralelo durante o tempo de implementação, o que acelera o processo de implementação.
  2. bq_dependent_objects: todos os objetos do BigQuery que têm de ser criados por uma ordem específica devido a dependências de outros objetos do BigQuery. Turbo mode não se aplica a esta secção.

O implementador cria primeiro todos os objetos do BigQuery indicados em bq_independent_objects e, em seguida, todos os objetos indicados em bq_dependent_objects. Defina as seguintes propriedades para cada objeto:

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

Partição de tabela

Determinados ficheiros de definições permitem-lhe configurar tabelas materializadas com opções de particionamento e agrupamento personalizadas. Isto pode melhorar significativamente o desempenho das consultas para conjuntos de dados grandes. Esta opção aplica-se apenas a ficheiros SAP cdc_settings.yaml e a todos os ficheiros reporting_settings.yaml.

A partição de tabelas pode ser ativada especificando 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 da partição 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 a partição baseada no tempo. Para mais informações, consulte o artigo Tabelas particionadas por data/hora. "integer_range" para a partição baseada em números inteiros. Para mais informações, consulte a documentação sobre o intervalo de números inteiros.
time_grain Time part to partition with Obrigatório quando partition_type = "time". "hour", "day", "month" ou "year".
integer_range_bucket Intervalo de limites Obrigatório quando partition_type = "integer_range" "start" = Valor de início, "end" = Valor de fim e "interval" = Intervalo do intervalo.

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

Definições do cluster

Pode ativar o agrupamento em cluster de tabelas especificando cluster_details:

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

Use os seguintes parâmetros 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.

Passos seguintes

Depois de concluir este passo, avance para o passo de implementação seguinte:

  1. Estabeleça cargas de trabalho.
  2. Clonar repositório.
  3. Determine o mecanismo de integração.
  4. Configure os componentes.
  5. Configure a implementação (esta página).
  6. Execute a implementação.