이 페이지는 Cloud Translation API를 통해 번역되었습니다.

업그레이드 추천

이 페이지에서는 맞춤설정된 Cortex Framework Data Foundation에서 새 버전으로 업그레이드하기 위한 권장사항을 설명합니다. Cortex팀은 매 출시마다 Cortex Framework에 새로운 기능을 추가하는 동안 서비스 중단을 최소화하기 위해 최선을 다하고 있습니다. 새 업데이트는 이전 버전과의 호환성을 우선시합니다. 하지만 이 가이드를 따르면 발생할 수 있는 문제를 최소화할 수 있습니다.

Cortex Framework 데이터 기반은 BigQuery에 복제된 데이터의 가치를 높이는 사전 정의된 콘텐츠 및 템플릿을 제공합니다. 조직은 이러한 템플릿, 모듈, SQL, Python 스크립트, 파이프라인, 기타 제공된 콘텐츠를 필요에 맞게 조정합니다.

핵심 구성요소

Cortex Framework Data Foundation 콘텐츠는 개방성의 원칙을 염두에 두고 설계되었습니다. 조직은 제공된 BigQuery 데이터 모델을 사용할 때 가장 적합한 도구를 사용할 수 있습니다. 재단이 밀접하게 종속되는 유일한 플랫폼은 BigQuery입니다. 다른 모든 도구는 필요에 따라 교체할 수 있습니다.

데이터 통합: 원시 테이블과 구조를 복제할 수 있는 경우 BigQuery와 상호 연결되는 모든 통합 도구를 활용할 수 있습니다. 예를 들어 원시 테이블은 SAP에서 생성된 것과 동일한 스키마 (동일한 이름, 필드, 데이터 유형)와 유사해야 합니다. 또한 통합 도구는 BigQuery 호환성을 위해 대상 데이터 유형을 업데이트하는 것과 같이 기본 변환 서비스를 제공하고 새 레코드와 변경된 레코드를 강조 표시하기 위한 타임스탬프 또는 작업 플래그와 같은 필드를 추가할 수 있어야 합니다.
데이터 처리: 변경 데이터 캡처 (CDC) 처리 스크립트는 Cloud Composer(또는 Apache Airflow)를 사용하는 작업을 제공하며 선택사항입니다. 반대로 SQL 문은 가능하면 Airflow별 파일과 별도로 생성되므로 고객이 필요에 따라 다른 도구에서 별도의 SQL 파일을 사용할 수 있습니다.
데이터 시각화: Looker 대시보드 템플릿이 제공되고 시각화 및 최소 로직이 포함되어 있지만, 핵심 로직은 설계상 BigQuery 내 데이터 기반에서 계속 사용할 수 있으므로 원하는 보고 도구로 시각화를 만들 수 있습니다.

주요 이점

Cortex Framework Data Foundation은 다양한 비즈니스 요구사항에 맞게 조정할 수 있도록 설계되었습니다. 구성요소는 유연하게 빌드되므로 조직은 플랫폼을 특정 요구사항에 맞게 조정하고 다음과 같은 이점을 얻을 수 있습니다.

개방성: BigQuery 외에도 다양한 데이터 통합, 처리, 시각화 도구와 원활하게 통합됩니다.
맞춤설정: 조직은 데이터 모델 및 비즈니스 로직에 맞게 SQL 뷰와 같은 사전 빌드된 구성요소를 수정하고 확장할 수 있습니다.
성능 최적화: 파티션, 데이터 품질 검사, 클러스터링과 같은 기법은 개별 워크로드 및 데이터 양에 따라 조정할 수 있습니다.
하위 호환성: Cortex는 향후 출시에서 하위 호환성을 유지하여 기존 구현의 중단을 최소화하기 위해 노력하고 있습니다. 버전 변경사항에 관한 자세한 내용은 출시 노트를 참고하세요.
커뮤니티 참여: 사용자 간의 지식 공유 및 공동작업을 장려합니다.

프로세스 업데이트

다음 섹션에서는 개발자가 맞춤설정을 유지하면서 Cortex Framework Data Foundation 저장소를 사용하여 코드를 최신 상태로 유지하는 한 가지 방법에 관한 안내를 제공합니다. CI/CD 파이프라인에서 사전 제공된 배포 스크립트 사용 그러나 조직은 선호사항에 따라 Dataform과 같은 대체 도구와 방법론을 사용하거나 GitHub 액션과 같이 다양한 Git 호스트에서 제공하는 자동화 도구를 사용할 수 있습니다.

저장소 설정

이 섹션에서는 저장소를 설정하는 한 가지 방법을 간략히 설명합니다. 이 단계를 따르기 전에 Git을 확실히 이해하는 것이 좋습니다.

핵심 저장소 포크: Cortex Framework Data Foundation 저장소의 포크를 만듭니다. 포크는 해당 저장소가 Google Cloud 저장소에서 업데이트를 수신하도록 유지하고 회사의 기본 저장소를 위한 별도의 저장소를 유지합니다.
회사 저장소 만들기: 회사 저장소의 새 Git 호스트 (예: Cloud Source)를 설정합니다. 새 호스트에서 포크된 저장소와 동일한 이름으로 저장소를 만듭니다.
회사 저장소 초기화: 포크된 저장소의 코드를 새로 만든 회사 저장소에 복사합니다. 다음 명령어를 사용하여 원래 포크된 저장소를 업스트림 원격 저장소로 추가하고 원격이 추가되었는지 확인합니다. 이렇게 하면 회사 저장소와 원래 저장소 간에 연결이 설정됩니다.
```
git remote add google <<remote URL>>
git remote -v
git push --all google
```
저장소 설정 확인: 회사 저장소에 클론된 코드와 기록이 포함되어 있는지 확인합니다. 명령어를 사용한 후 원본과 추가한 원격 두 개가 표시됩니다.
```
git remote -v:
```
이제 개발자가 변경사항을 제출할 수 있는 저장소인 회사의 저장소가 생겼습니다. 이제 개발자는 새 저장소의 브랜치를 클론하고 브랜치에서 작업할 수 있습니다.

변경사항을 새 Cortex 출시와 병합

이 섹션에서는 회사의 저장소의 변경사항과 Google Cloud 저장소의 변경사항을 병합하는 프로세스를 설명합니다.

포크 업데이트: 포크 동기화를 클릭하여 저장소의 포크를 저장소의 변경사항으로 업데이트합니다. Google Cloud 예를 들어 회사의 저장소에 다음과 같은 변경사항이 적용됩니다. 또한 새 버전에서는 Google Cloud 에 의해 데이터 기반 저장소에 몇 가지 다른 변경사항이 적용되었습니다.
- SQL에서 새 뷰를 만들고 사용하도록 통합했습니다.
- 기존 뷰 수정됨
- 스크립트를 Google 자체 로직으로 완전히 대체했습니다.
다음 명령어 시퀀스는 포크 저장소를 업스트림 원격 저장소로 추가하여 업데이트된 출시 버전을 GitHub에서 가져오고 기본 브랜치를 GitHub-main으로 체크아웃합니다. 그런 다음 이 예에서는 Google Cloud 소스의 회사 저장소에서 기본 브랜치를 체크아웃하고 merging_br라는 병합 브랜치를 만듭니다.
```
git remote add github <<github fork>>
git fetch github main
git checkout -b github-main github/main
git checkout  main
git checkout -b merging_br
```
이 흐름을 빌드하는 방법에는 여러 가지가 있습니다. 병합 프로세스는 GitHub의 포크에서 발생할 수도 있고, 병합 대신 리베이스로 대체될 수도 있으며, 병합 브랜치가 병합 요청으로 전송될 수도 있습니다. 이러한 프로세스 변형은 현재 조직 정책, 변경사항의 심도, 편의성에 따라 달라집니다.

이 설정을 사용하면 수신되는 변경사항을 로컬 변경사항과 비교할 수 있습니다. 원하는 그래픽 IDE의 도구를 사용하여 변경사항을 확인하고 병합할 항목을 선택하는 것이 좋습니다. 예를 들어 Visual Studio가 있습니다.

차이점 확인 프로세스를 더 쉽게 진행할 수 있도록 시각적으로 눈에 띄는 주석을 사용하여 맞춤설정을 신고하는 것이 좋습니다.
병합 프로세스 시작: 만든 브랜치 (이 예에서는 merging_br라는 브랜치)를 사용하여 모든 변경사항을 수렴하고 파일을 삭제합니다. 준비가 되면 이 브랜치를 회사 저장소의 기본 브랜치 또는 다른 브랜치로 다시 병합하여 병합 요청을 만들 수 있습니다. 회사 저장소의 기본(git checkout merging_br)에서 체크아웃한 병합 브랜치에서 원격 포크의 수신 변경사항을 병합합니다.
```
    ## git branch -a
    ## The command shows github-main which was created from the GitHub fork
    ## You are in merging_br

    git merge github-main

    ## If you don't want a list of the commits coming from GitHub in your history, use `--squash`
```
이 명령어는 충돌 목록을 생성합니다. 그래픽 IDE 비교를 사용하여 변경사항을 파악하고 현재, 수신, 둘 다 중에서 선택합니다. 이때 코드에 맞춤설정에 관한 주석을 달면 유용합니다. 변경사항을 모두 삭제하거나, 병합하고 싶지 않은 파일을 삭제하거나, 이미 맞춤설정한 뷰 또는 스크립트의 변경사항을 무시하도록 선택합니다.
변경사항 병합: 적용할 변경사항을 결정한 후 요약을 확인하고 다음 명령어로 커밋합니다.
```
    git status
    ## If something doesn't look right, you can use git rm or git restore accordingly
    git add --all #Or . or individual files
    git commit -m "Your commit message"
```
어떤 단계에 대해 확신이 서지 않는다면 Git 기본 실행취소를 참고하세요.
테스트 및 배포: 지금까지는 '임시' 브랜치에만 병합했습니다. 이 시점에서 cloudbuild\*.yaml 스크립트에서 테스트 배포를 실행하여 모든 것이 예상대로 실행되는지 확인하는 것이 좋습니다. 자동화 테스트를 사용하면 이 프로세스를 간소화할 수 있습니다. 병합 브랜치가 제대로 보이면 기본 타겟 브랜치를 체크아웃하고 merging_br 브랜치를 병합할 수 있습니다.