업그레이드 추천

이 페이지에서는 맞춤설정된 Cortex Framework 데이터 파운데이션에서 새 버전으로 업그레이드하는 방법을 설명합니다. Cortex팀은 모든 출시에서 Cortex Framework에 새로운 기능을 추가하는 동안 중단을 최소화하기 위해 노력합니다. 새 업데이트에서는 이전 버전과의 호환성을 우선시합니다. 하지만 이 가이드를 통해 발생할 수 있는 문제를 최소화할 수 있습니다.

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

핵심 구성요소

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

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

주요 이점

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

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

프로세스 업데이트

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

저장소 설정

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

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

변경사항을 새 Cortex 버전과 병합

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

포크 업데이트: 포크 동기화를 클릭하여 Google Cloud 저장소의 변경사항으로 저장소의 포크를 업데이트합니다. 예를 들어 회사 저장소에 다음과 같은 변경사항이 적용됩니다. 또한 새 버전에서 Google Cloud 에 의해 데이터 파운데이션 저장소에 몇 가지 다른 변경사항이 적용되었습니다.
- SQL에서 새 뷰 사용을 만들어 통합했습니다.
- 기존 보기가 수정됨
- 스크립트를 자체 로직으로 완전히 대체
다음 명령어 시퀀스는 업데이트된 버전을 GitHub에서 가져오기 위해 포크 저장소를 업스트림 원격 저장소로 추가하고 기본 브랜치를 GitHub-main으로 체크아웃합니다. 그런 다음 이 예시에서는 Google Cloud Source의 회사 저장소에서 기본 브랜치를 체크아웃하고 병합을 위한 브랜치(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 브랜치를 병합하면 됩니다.