이 페이지에서는 Cortex Framework의 핵심인 Cortex Framework Data Foundation을 배포하는 다섯 번째 단계를 설명합니다. 이 단계에서는 Cortex Framework Data Foundation 저장소의 구성 파일을 요구사항에 맞게 수정합니다.
구성 파일
배포 동작은 Cortex Framework Data Foundation의 구성 파일 config.json에 의해 제어됩니다. 이 파일에는 전역 구성과 각 워크로드의 특정 구성이 포함되어 있습니다.
다음 단계에 따라 필요에 맞게 config.json 파일을 수정합니다.
더 빠른 배포를 위해 동일한 Cloud Build 프로세스의 단계로 모든 뷰 빌드를 병렬로 실행합니다. false로 설정하면 각 보고 뷰가 자체 순차적 빌드 단계에서 생성됩니다. 테스트 데이터를 사용하거나 보고 열과 소스 데이터 간의 불일치가 해결된 후에만 true로 설정하는 것이 좋습니다.
projectIdSource
소스 프로젝트 ID
-
소스 데이터 세트가 있고 빌드가 실행되는 프로젝트입니다.
projectIdTarget
타겟 프로젝트 ID
-
사용자 대상 데이터 세트의 타겟 프로젝트입니다.
targetBucket
생성된 DAG 스크립트를 저장할 타겟 버킷
-
DAG (및 Dataflow 임시 파일)가 생성되는 이전에 생성된 버킷입니다.
실제 Airflow 버킷을 사용하지 마세요.
보고 아티팩트는 뷰로 만들거나 DAG를 통해 정기적으로 새로고침되는 테이블로 만들 수 있습니다. 뷰는 쿼리가 실행될 때마다 데이터를 계산하므로 결과가 항상 최신 상태로 유지됩니다.
반면 테이블은 계산을 한 번 실행하며 더 높은 컴퓨팅 비용을 발생시키지 않고 더 빠른 런타임을 달성하여 결과를 여러 번 쿼리할 수 있습니다. 각 고객은 필요에 따라 자체 구성을 만듭니다.
구체화된 결과가 테이블에 업데이트됩니다. 이러한 테이블에 파티션 나누기 및 클러스터링을 추가하여 테이블을 더 세부적으로 조정할 수 있습니다.
각 워크로드의 구성 파일은 Cortex 프레임워크 데이터 파운데이션 저장소의 다음 경로에 있습니다.
reporting_settings 파일은 보고 데이터 세트의 BigQuery 객체(테이블 또는 뷰)가 생성되는 방식을 결정합니다. 다음 매개변수 설명으로 파일을 맞춤설정합니다. 이 파일에는 다음 두 섹션이 포함되어 있다고 가정해 보겠습니다.
bq_independent_objects: 다른 종속 항목 없이 독립적으로 만들 수 있는 모든 BigQuery 객체입니다. Turbo mode이 사용 설정되면 이러한 BigQuery 객체가 배포 중에 병렬로 생성되어 배포 프로세스가 빨라집니다.
bq_dependent_objects: 다른 BigQuery 객체에 대한 종속성으로 인해 특정 순서로 생성해야 하는 모든 BigQuery 객체입니다. Turbo mode은(는) 이 섹션에 적용되지 않습니다.
배포자는 먼저 bq_independent_objects에 나열된 모든 BigQuery 객체를 만든 다음 bq_dependent_objects에 나열된 모든 객체를 만듭니다. 각 객체에 대해 다음 속성을 정의합니다.
sql_file: 지정된 객체를 만드는 SQL 파일의 이름입니다.
type: BigQuery 객체의 유형입니다. 가능한 값은 다음과 같습니다.
view : 객체를 BigQuery 뷰로 만들려는 경우
table: 객체가 BigQuery 테이블인 경우
script: 다른 유형의 객체(예: BigQuery 함수 및 저장된 프로세스)를 만드는 데 사용됩니다.
type이 table으로 설정된 경우 다음 선택적 속성을 정의할 수 있습니다.
load_frequency: 이 테이블을 새로고침하기 위해 Composer DAG가 실행되는 빈도입니다. 가능한 값에 대한 자세한 내용은 Airflow 문서를 참고하세요.
partition_details: 테이블을 파티셔닝하는 방법입니다.
이 값은 선택사항입니다. 자세한 내용은 표 파티션 섹션을 참고하세요.
cluster_details: 테이블을 클러스터링하는 방법입니다.
이 값은 선택사항입니다. 자세한 내용은 클러스터 설정 섹션을 참고하세요.
표 파티션
특정 설정 파일을 사용하면 맞춤 클러스터링 및 파티셔닝 옵션으로 구체화된 테이블을 구성할 수 있습니다. 이렇게 하면 대규모 데이터 세트의 쿼리 성능이 크게 향상될 수 있습니다. 이 옵션은 SAP cdc_settings.yaml 및 모든 reporting_settings.yaml 파일에만 적용됩니다.
다음 partition_details를 지정하여 테이블 파티션 나누기를 사용 설정할 수 있습니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-09-04(UTC)"],[[["\u003cp\u003eThis step involves modifying the \u003ccode\u003econfig.json\u003c/code\u003e file in the Cortex Framework Data Foundation repository to configure the deployment according to your specific needs, and is designed specifically for deployments from the official GitHub repository.\u003c/p\u003e\n"],["\u003cp\u003eThe \u003ccode\u003econfig.json\u003c/code\u003e file controls the deployment's behavior, allowing you to set global configurations and workload-specific parameters such as deploying test data, SAP, Salesforce, marketing sources, Oracle EBS, and Data Mesh.\u003c/p\u003e\n"],["\u003cp\u003eYou can enable \u003ccode\u003eturboMode\u003c/code\u003e in the \u003ccode\u003econfig.json\u003c/code\u003e file for faster deployment by executing all view builds in parallel, which is recommended when using test data or after resolving mismatches between reporting columns and source data.\u003c/p\u003e\n"],["\u003cp\u003eThe \u003ccode\u003ereporting_settings.yaml\u003c/code\u003e files, located within each workload's directory, manage the creation of BigQuery objects (tables, views, and scripts) for reporting datasets, allowing customization of objects in two categories: independent and dependent objects, which can also specify materialization details.\u003c/p\u003e\n"],["\u003cp\u003eTable partitioning and clustering can be configured within the \u003ccode\u003ereporting_settings.yaml\u003c/code\u003e files to improve query performance for large datasets, by specifying the \u003ccode\u003epartition_details\u003c/code\u003e and \u003ccode\u003ecluster_details\u003c/code\u003e properties, respectively, applicable to \u003ccode\u003eSAP cdc_settings.yaml\u003c/code\u003e and all \u003ccode\u003ereporting_settings.yaml\u003c/code\u003e files.\u003c/p\u003e\n"]]],[],null,["# Step 5: Configure deployment\n============================\n\nThis page describes the fifth step to deploy Cortex Framework Data Foundation,\nthe core of Cortex Framework. In this step, you modify the configuration\nfile in the Cortex Framework Data Foundation repository to match your requirements.\n| **Note:** The steps outlined in this page are specifically designed for deploying Cortex Framework Data Foundation from the [official GitHub repository](https://github.com/GoogleCloudPlatform/cortex-data-foundation).\n\nConfiguration file\n------------------\n\nThe behavior of the deployment is controlled by the configuration file `config.json`\nin the [Cortex Framework Data Foundation](https://github.com/GoogleCloudPlatform/cortex-data-foundation). This file contains global configuration, specific configuration to each workload.\nEdit the `config.json` file according to your needs with the following steps:\n\n1. Open the file [`config.json`](https://github.com/GoogleCloudPlatform/cortex-data-foundation/blob/main/config/config.json) from Cloud Shell.\n2. Edit the `config.json` file according to the following parameters:\n\n | **Note:** See more parameters specifically for [Cortex for Meridan](/cortex/docs/meridian) on [Additional deployment parameters for Meridian](/cortex/docs/meridian#additional_deployment_parameters_for_merdian).\n\n3. Configure your required workload(s) as needed. You don't need to configure\n them if the deployment parameter (for example, `deploySAP` or `deployMarketing`)\n for the workload is set to `False`. For more information, see\n [Step 3: Determine integration mechanism](/cortex/docs/deployment-step-three).\n\n| **Note:** When installing multiple Cortex Framework workloads, you need to increase the `Build and Operation Get requests per minute` and `Build and Operation Get requests per minute per user` quotas. For more information, see [Quotas and system limits](https://cloud.google.com/cortex/quotas).\n\nFor a better customization of your deployment, see the following **optional steps**:\n\n- [Telemetry Opt Out](/cortex/docs/optional-step-telemetry).\n- [External datasets configuration for K9](/cortex/docs/optional-step-external-datasets).\n- [Check for `CORTEX-CUSTOMER` tags](/cortex/docs/deployment-step-six#customize_and_prepare_for_upgrade).\n\nPerformance optimization for reporting views\n--------------------------------------------\n\nReporting artifacts can be created as views or as tables refreshed\nregularly through DAGs. On one hand, views compute the data on\neach execution of a query, which keep the results always fresh.\nOn the other hand, the table runs the computations once, and the\nresults can be queried multiple times without incurring higher computing\ncosts and achieving faster runtime. Each customer creates their own\nconfiguration according to their needs.\n\nMaterialized results are updated into a table. These tables can be\nfurther fine-tuned by adding [Partitioning](#table_partition) and\n[Clustering](#cluster_settings) to these tables.\n\nThe configuration files for each workload are located in the following paths\nwithin the Cortex Framework Data Foundation repository:\n\nCustomizing reporting settings file\n-----------------------------------\n\nThe `reporting_settings` files drives how the BigQuery objects\n(tables or views) are created for reporting datasets. Customize your file with\nthe following parameters descriptions. Consider that this file contains two sections:\n\n1. `bq_independent_objects`: All BigQuery objects that can be created independently, without any other dependencies. When [`Turbo mode`](/cortex/docs/optional-step-turbo-mode) is enabled, these BigQuery objects are created in parallel during the deployment time, speeding up the deployment process.\n2. `bq_dependent_objects`: All BigQuery objects that need to be created in a specific order due to dependencies on other BigQuery objects. [`Turbo mode`](/cortex/docs/optional-step-turbo-mode) doesn´t apply to this section.\n\nThe deployer first creates all the BigQuery objects listed\nin `bq_independent_objects`, and then all the objects listed in\n`bq_dependent_objects`. Define The following properties for each object:\n\n1. `sql_file`: Name of the SQL file that creates a given object.\n2. `type`: Type of BigQuery object. Possible values:\n - `view` : If you want the object to be a BigQuery view.\n - `table`: If you want the object to be a BigQuery table.\n - `script`: This is to create other types of objects (for example, BigQuery functions and stored processes).\n3. If `type` is set to `table`, the following optional properties can be defined:\n - `load_frequency`: Frequency at which a Composer DAG is executed to refresh this table. See [Airflow documentation](https://airflow.apache.org/docs/apache-airflow/stable/authoring-and-scheduling/cron.html) for details on possible values.\n - `partition_details`: How the table should be partitioned. This value is **optional** . For more information, see section [Table partition](#table_partition).\n - `cluster_details`: How the table should be clustered. This value is **optional** . For more information, see section [Cluster settings](#cluster_settings).\n\n| **Note:** If you enabled Task dependent DAGs by setting the `enableTaskDependencies` field to `True`, make sure to create a dedicated reporting settings file with the suffix `_task_dep.yaml` for each data source requiring task dependencies. For more information, see [Task dependent DAGs](/cortex/docs/optional-step-task-dependent-dags)\n\n### Table partition\n\nCertain settings files let you configure materialized tables with custom\nclustering and partitioning options. This can significantly improve query\nperformance for large datasets. This option applies only for `SAP cdc_settings.yaml`\nand all `reporting_settings.yaml` files.\n\nTable Partitioning can be enabled by specifying the following`partition_details`: \n\n - base_table: vbap\n load_frequency: \"@daily\"\n partition_details: {\n column: \"erdat\", partition_type: \"time\", time_grain: \"day\" }\n\nUse the following parameters to control partitioning details for a given table:\n\nFor more information about options and related limitations, see [BigQuery Table Partition](/bigquery/docs/partitioned-tables).\n\n### Cluster settings\n\nTable clustering can be enabled by specifying `cluster_details`: \n\n - base_table: vbak\n load_frequency: \"@daily\"\n cluster_details: {columns: [\"vkorg\"]}\n\nUse the following parameters to control cluster details for a given table:\n\nFor more information about options and related limitations,\nsee [Table cluster documentation](/bigquery/docs/clustered-tables).\n\nNext steps\n----------\n\nAfter you complete this step, move on to the following deployment step:\n\n1. [Establish workloads](/cortex/docs/deployment-step-one).\n2. [Clone repository](/cortex/docs/deployment-step-two).\n3. [Determine integration mechanism](/cortex/docs/deployment-step-three).\n4. [Set up components](/cortex/docs/deployment-step-four).\n5. [Configure deployment](/cortex/docs/deployment-step-five) (this page).\n6. [Execute deployment](/cortex/docs/deployment-step-six)."]]
