Below you will find pages that utilize the taxonomy term “Note_temp”

OAuth Grant Type란?

OAuth 2.0의 Grant Type(권한 부여 유형)은 클라이언트가 인증 서버로부터 액세스 토큰을 받기 위해 사용하는 인증 및 권한 위임 방식입니다. 각각의 Grant Type은 다양한 환경(웹, 모바일, 서버 등)과 보안 요구사항에 맞춰 설계되어 있으며, 각 방식마다 인증 절차와 필요한 정보가 다릅니다¹²³.

주요 OAuth 2.0 Grant Type 종류

Grant Type	특징 및 사용 환경	주요 용도
Authorization Code	서버사이드(웹) 애플리케이션, 가장 안전	사용자가 브라우저에서 인증 후, 클라이언트가 받은 코드를 서버에서 토큰으로 교환²⁴⁵
PKCE (Proof Key for Code Exchange)	모바일/SPA 등 공개 클라이언트, Authorization Code 보안 강화	코드 탈취 방지, 추가 검증값(code verifier/challenge) 사용²⁴
Implicit (Deprecated)	SPA, 모바일 등 클라이언트 사이드	토큰을 브라우저로 직접 반환, 보안 취약해 OAuth 2.1에서 폐기 예정²⁴⁵
Resource Owner Password Credentials (Deprecated)	신뢰할 수 있는 앱(내부), 보안 취약	사용자의 ID/PW를 직접 받아 토큰 발급, 외부 앱에는 권장하지 않음²⁴
Client Credentials	서버 간 통신, 사용자 개입 없음	클라이언트의 ID/Secret만으로 토큰 발급, 서버-서버, 데몬 등²⁴⁵
Device Code	입력장치 제한된 디바이스(스마트TV 등)	별도 기기에서 인증 후 디바이스에 토큰 발급⁵
Refresh Token	Access Token 재발급	Access Token 만료 시 재인증 없이 새 토큰 발급, Authorization Code/Password 방식에서 주로 사용²⁴

각 Grant Type의 간단 설명

1. Authorization Code Grant

export PROJECT_ID=$(gcloud config list --format 'value(core.project)')
echo "PROJECT_ID=${PROJECT_ID}"

export INSTANCE_NAME=eval-instance
export ENV_NAME=eval
export PREV_INSTANCE_STATE=

echo "waiting for runtime instance ${INSTANCE_NAME} to be active"

while : ; do
  export INSTANCE_STATE=$(
    curl -s -H "Authorization: Bearer $(gcloud auth print-access-token)" \
      -X GET "https://apigee.googleapis.com/v1/organizations/${PROJECT_ID}/instances/${INSTANCE_NAME}" |
      jq "select(.state != null) | .state" --raw-output
  )

  [[ "${INSTANCE_STATE}" == "${PREV_INSTANCE_STATE}" ]] || (
    echo
    echo "INSTANCE_STATE=${INSTANCE_STATE}"
  )

  export PREV_INSTANCE_STATE=${INSTANCE_STATE}

  [[ "${INSTANCE_STATE}" != "ACTIVE" ]] || break

  echo -n "."
  sleep 5
done

echo
echo "instance created, waiting for environment ${ENV_NAME} to be attached to instance"

while : ; do
  export ATTACHMENT_DONE=$(
    curl -s -H "Authorization: Bearer $(gcloud auth print-access-token)" \
      -X GET "https://apigee.googleapis.com/v1/organizations/${PROJECT_ID}/instances/${INSTANCE_NAME}/attachments" |
      jq "select(.attachments != null) | .attachments[] | select(.environment == \"${ENV_NAME}\") | .environment" --join-output
  )

  [[ "${ATTACHMENT_DONE}" != "${ENV_NAME}" ]] || break

  echo -n "."
  sleep 5
done

echo "***ORG IS READY TO USE***"

apigee를 테스트해 보면서 제일 적응 안 되는 부분이 인스턴스를 붙이는 부분이라고 생각된다.


gcloud config set project

gcloud config set compute/region 

gcloud config set compute/zone 

export GOOGLE_CLOUD_PROJECT=$(gcloud config get-value core/project)

gcloud container clusters create fancy-prod-268 --num-nodes 3

gcloud compute instances list


gcloud services enable cloudbuild.googleapis.com

# build
cd ~/monolith-to-microservices/monolith
gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/fancy-monolith-220:1.0.0 .

# deploy
kubectl create deployment fancy-monolith-220 --image=gcr.io/${GOOGLE_CLOUD_PROJECT}/fancy-monolith-220:1.0.0

# check
kubectl get all

# Show pods
kubectl get pods

# Show deployments
kubectl get deployments

# Show replica sets
kubectl get rs

#You can also combine them
kubectl get pods,deployments
kubectl get services


# delete
kubectl delete pod/<POD_NAME>

# expose
kubectl expose deployment fancy-monolith-220 --type=LoadBalancer --port 80 --target-port 8080

# Accessing the service
kubectl get service

~/monolith-to-microservices/microservices/src/orders
gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/fancy-orders-430:1.0.0 .

kubectl create deployment fancy-orders-430 --image=gcr.io/${GOOGLE_CLOUD_PROJECT}/fancy-orders-430:1.0.0
kubectl expose deployment fancy-orders-430 --type=LoadBalancer --port 80 --target-port 8081

~/monolith-to-microservices/microservices/src/products
gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/fancy-products-721:1.0.0 .


kubectl delete deployment fancy-products-721
kubectl create deployment fancy-products-721 --image=gcr.io/${GOOGLE_CLOUD_PROJECT}/products-721:1.0.0
kubectl expose deployment fancy-products-721 --type=LoadBalancer --port 80 --target-port 8082


~/monolith-to-microservices/microservices/src/frontend
gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/fancy-frontend-189:1.0.0 .

kubectl create deployment fancy-frontend-189 --image=gcr.io/${GOOGLE_CLOUD_PROJECT}/fancy-frontend-189:1.0.0
kubectl expose deployment fancy-frontend-189 --type=LoadBalancer --port 80 --target-port 8080

------------------


# scale
kubectl scale deployment monolith --replicas=3

kubectl get all

# Make changes to the website
gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:2.0.0 .

# Update website with zero downtime
kubectl set image deployment/monolith monolith=gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:2.0.0

kubectl get pods



# delete
# Delete the container image for version 1.0.0 of the monolith
gcloud container images delete gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:1.0.0 --quiet

# Delete the container image for version 2.0.0 of the monolith
gcloud container images delete gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:2.0.0 --quiet

# The following command will take all source archives from all builds and delete them from cloud storage

# Run this command to print all sources:
# gcloud builds list | awk 'NR > 1 {print $4}'

gcloud builds list | grep 'SOURCE' | cut -d ' ' -f2 | while read line; do gsutil rm $line; done

kubectl delete service monolith
kubectl delete deployment monolith

gcloud container clusters delete fancy-cluster lab region


# App Build &  Docker Deploy

# artifactregistry Repository
gcloud auth configure-docker us-east1-docker.pkg.dev

gcloud services enable artifactregistry.googleapis.com \
    cloudbuild.googleapis.com \
    run.googleapis.com

# Submit
gcloud builds submit --tag us-east1-docker.pkg.dev/${GOOGLE_CLOUD_PROJECT}/monolith-demo/monolith:1.0.0    


# Cloud Build  에서 진행상태 볼 수 있다.

# Deploy Container
gcloud run deploy monolith --image us-east1-docker.pkg.dev/${GOOGLE_CLOUD_PROJECT}/monolith-demo/monolith:1.0.0 --region us-east1

# check
gcloud run services list

#  Create new revision with lower concurrency ??
gcloud run deploy monolith --image us-east1-docker.pkg.dev/${GOOGLE_CLOUD_PROJECT}/monolith-demo/monolith:1.0.0 --region us-east1 --concurrency 1

gcloud run deploy monolith --image us-east1-docker.pkg.dev/${GOOGLE_CLOUD_PROJECT}/monolith-demo/monolith:1.0.0 --region us-east1 --concurrency 80

# Cloud Run에서 확인가능

# node module 지우고 올리기
cd ~
rm -rf monolith-to-microservices/*/node_modules
gsutil -m cp -r monolith-to-microservices gs://fancy-store-$DEVSHELL_PROJECT_ID/

# 인스턴스 만들기
gcloud compute instances create backend \
    --zone=$ZONE \
    --machine-type=e2-standard-2 \
    --tags=backend \
   --metadata=startup-script-url=https://storage.googleapis.com/fancy-store-$DEVSHELL_PROJECT_ID/startup-script.sh


# ip확인
gcloud compute instances list


# Firewall. 적용하고 3분 기다려야 된다.
gcloud compute firewall-rules create fw-fe \
    --allow tcp:8080 \
    --target-tags=frontend

gcloud compute firewall-rules create fw-be \
    --allow tcp:8081-8082 \
    --target-tags=backend    

# 끄고
gcloud compute instances stop frontend --zone=$ZONE    

gcloud compute instances stop backend --zone=$ZONE


# 인스턴스를 템플릿으로 만든다. 
gcloud compute instance-templates create fancy-fe \
    --source-instance-zone=$ZONE \
    --source-instance=frontend

gcloud compute instance-templates create fancy-be \
    --source-instance-zone=$ZONE \
    --source-instance=backend    

gcloud compute instance-templates list    


# 기존의 것을 지우고
gcloud compute instances delete backend --zone=$ZONE


# managed 로 다시 만든다
gcloud compute instance-groups managed create fancy-fe-mig \
    --zone=$ZONE \
    --base-instance-name fancy-fe \
    --size 2 \
    --template fancy-fe

gcloud compute instance-groups managed create fancy-be-mig \
    --zone=$ZONE \
    --base-instance-name fancy-be \
    --size 2 \
    --template fancy-be    

# set-named-port라는 명령이 있네
gcloud compute instance-groups set-named-ports fancy-fe-mig \
    --zone=$ZONE \
    --named-ports frontend:8080

gcloud compute instance-groups set-named-ports fancy-be-mig \
    --zone=$ZONE \
    --named-ports orders:8081,products:8082        

# 핼스체크 추가
gcloud compute health-checks create http fancy-fe-hc \
    --port 8080 \
    --check-interval 30s \
    --healthy-threshold 1 \
    --timeout 10s \
    --unhealthy-threshold 3

gcloud compute health-checks create http fancy-be-hc \
    --port 8081 \
    --request-path=/api/orders \
    --check-interval 30s \
    --healthy-threshold 1 \
    --timeout 10s \
    --unhealthy-threshold 3

gcloud compute firewall-rules create allow-health-check \
    --allow tcp:8080-8081 \
    --source-ranges 130.211.0.0/22,35.191.0.0/16 \
    --network default        


# 헬스체크한 뒤 업데이트 해야 하나 보다
gcloud compute instance-groups managed update fancy-fe-mig \
    --zone=$ZONE \
    --health-check fancy-fe-hc \
    --initial-delay 300

gcloud compute instance-groups managed update fancy-be-mig \
    --zone=$ZONE \
    --health-check fancy-be-hc \
    --initial-delay 300        


# Create load balancers
gcloud compute http-health-checks create fancy-fe-frontend-hc \
  --request-path / \
  --port 8080    

gcloud compute http-health-checks create fancy-be-orders-hc \
  --request-path /api/orders \
  --port 8081

gcloud compute http-health-checks create fancy-be-products-hc \
  --request-path /api/products \
  --port 8082

# 엥?
# Note: These health checks are for the load balancer, and only handle directing traffic from the load balancer; they do not cause the managed instance groups to recreate instances.      

gcloud compute backend-services create fancy-fe-frontend \
  --http-health-checks fancy-fe-frontend-hc \
  --port-name frontend \
  --global

gcloud compute backend-services create fancy-be-orders \
  --http-health-checks fancy-be-orders-hc \
  --port-name orders \
  --global

gcloud compute backend-services create fancy-be-products \
  --http-health-checks fancy-be-products-hc \
  --port-name products \
  --global

# 로드 밸런서도?... 이렇게 복잡하게 해야하는건가? 보다.
gcloud compute backend-services add-backend fancy-fe-frontend \
  --instance-group-zone=$ZONE \
  --instance-group fancy-fe-mig \
  --global      

gcloud compute backend-services add-backend fancy-be-orders \
  --instance-group-zone=$ZONE \
  --instance-group fancy-be-mig \
  --global  

gcloud compute backend-services add-backend fancy-be-products \
  --instance-group-zone=$ZONE \
  --instance-group fancy-be-mig \
  --global  

# Create a URL map. 악!
gcloud compute url-maps create fancy-map \
  --default-service fancy-fe-frontend  

# 아... 이건 Nginx에서 라우팅 하는 것 처럼 보인다.
#Create a path matcher to allow the /api/orders and /api/products paths to route to their respective services:
gcloud compute url-maps add-path-matcher fancy-map \
   --default-service fancy-fe-frontend \
   --path-matcher-name orders \
   --path-rules "/api/orders=fancy-be-orders,/api/products=fancy-be-products"

# 맵을 만들고... 용어가 달라서 그렇군.
# Create the proxy which ties to the URL map:
gcloud compute target-http-proxies create fancy-proxy \
  --url-map fancy-map   

# 포워딩
# Create a global forwarding rule that ties a public IP address and port to the proxy:
gcloud compute forwarding-rules create fancy-http-rule \
  --global \
  --target-http-proxy fancy-proxy \
  --ports 80  


# Find the IP address for the Load Balancer:  
gcloud compute forwarding-rules list --global


# ip가 바뀌었을테네.. .env 파일 바꿔준다. 음.. 이건 좀.

# 다시 빌드하고 다시 배포 한다.... 음.. .env를 안쓰면 되나? 거참.
cd ~/monolith-to-microservices/react-app
npm install && npm run-script build

cd ~
rm -rf monolith-to-microservices/*/node_modules
gsutil -m cp -r monolith-to-microservices gs://fancy-store-$DEVSHELL_PROJECT_ID/

gcloud compute instance-groups managed rolling-action replace fancy-fe-mig \
    --zone=$ZONE \
    --max-unavailable 100%

# 체크
watch -n 2 gcloud compute backend-services get-health fancy-fe-frontend --global




# 스케일 변경
gcloud compute instance-groups managed set-autoscaling \
  fancy-fe-mig \
  --zone=$ZONE \
  --max-num-replicas 2 \
  --target-load-balancing-utilization 0.60

gcloud compute instance-groups managed set-autoscaling \
  fancy-be-mig \
  --zone=$ZONE \
  --max-num-replicas 2 \
  --target-load-balancing-utilization 0.60

# CDN...은 어떻게 설정되는지?
# Enable content delivery network
gcloud compute backend-services update fancy-fe-frontend \
    --enable-cdn --global    



# 인스턴스 사이즈 변경
gcloud compute instances set-machine-type frontend \
  --zone=$ZONE \
  --machine-type e2-small

gcloud compute instance-templates create fancy-fe-new \
    --region=$REGION \
    --source-instance=frontend \
    --source-instance-zone=$ZONE

gcloud compute instance-groups managed rolling-action start-update fancy-fe-mig \
  --zone=$ZONE \
  --version template=fancy-fe-new

# 와치? 3분 정도 걸린다고 함.
watch -n 2 gcloud compute instance-groups managed list-instances fancy-fe-mig \
  --zone=$ZONE            

gcloud compute instances describe [VM_NAME] --zone=$ZONE | grep machineType  


# ssh
gcloud compute instance-groups list-instances fancy-fe-mig --zone=$ZONE

gcloud compute ssh [INSTANCE_NAME] --zone=$ZONE

Visualize Data

데이터 시각화가 왜 중요한가?

무엇보다도 디지털 소비는 클라우드 데이터 팀이 데이터와 상호 작용하는 매체를 이해하는 것. 다음으로, 데이터 시각화를 공유할 대상 고객이 누구인지 아는것이 중요. 하지만 디지털 매체의 경우, 청중이 데이터와 어떻게 상호작용하는지, 그리고 상호작용을 통해 무엇을 기대하는지도 고려해야 함. 클라우드 데이터 분석가로서 귀하의 대상 고객은 여러 곳에서 얻은 정보를 사용합니다. 그리고 사용자들은 정보가 최신이고 대화형기를 기대합니다. 또한 그들은 중요한 콘텐츠만 표시하기 위해 데이터를 필터링하고 싶어할 것입니다.

디지털 사용자는 직관적이고 사용하기 쉬우며, 지침이나 설명이 거의 없거나 전혀 없는 사용자 경험을 기대합니다.

gcloud config set project qwiklabs-gcp-00-acf9d7b837de

export GOOGLE_CLOUD_PROJECT=$(gcloud config get-value core/project)

gcloud iam service-accounts create my-natlang-sa \
  --display-name "my natural language service account"

gcloud iam service-accounts keys create ~/key.json \
  --iam-account my-natlang-sa@${GOOGLE_CLOUD_PROJECT}.iam.gserviceaccount.com


gcloud compute ssh [INSTANCE_NAME] --zone=[ZONE]

gcloud compute ssh linux-instance --zone=us-east4-b


gcloud ml language analyze-entities --content="Michelangelo Caravaggio, Italian painter, is known for 'The Calling of Saint Matthew'." > result.json


export API_KEY=<YOUR_API_KEY>

export API_KEY=AIzaSyCO4c7jJCH-ZaMGAld9KLbLUBbrVgpsauI


touch request.json

nano request.json

{
  "config": {
      "encoding":"FLAC",
      "languageCode": "en-US"
  },
  "audio": {
      "uri":"gs://cloud-samples-tests/speech/brooklyn.flac"
  }
}


curl -s -X POST -H "Content-Type: application/json" --data-binary @request.json \
"https://speech.googleapis.com/v1/speech:recognize?key=${API_KEY}"


curl -s -X POST -H "Content-Type: application/json" --data-binary @request.json \
"https://speech.googleapis.com/v1/speech:recognize?key=${API_KEY}" > result.json

AI Lifecycle

[라이프사이클]

Data: Data ingestion > Data analytics > Data engineering > to AI
AI: Model training > Model testing > Model deployment > to Data

[구분]

Predictive AI: 예측 AI
Generative AI: 생성형 AI

[Supervised vs. Unsupervised]

Supervised: Labeled data Classification: 사진에 나온 것이 고양이인지 개인지 구분. 로지스틱 회귀같은 것으로 해결 Regression: 숫자형 변수를 예측하는 회귀. 과거 판매를 바탕으로 제품 매출을 예측. 선형회귀 같은 것으로 해결.
Unsupervised: Unlabeled data Clustering. 비슷한 특성을 같는 데이터 포인트를 그룹화. 고객인구통계를 사용해 고객 세분화를 결정. k-평균 클러스터링 같은 것으로 해결. Association: 연결로 기본관계를 식별. 식료품 매장의 경우 두 제품의 상관관계를 파악하여 시너지 효과를 위해 서롭 가깝게 배치. 사용자는 연결 규칙 학습 기술, Apriori와 같은 알고리즘을 사용하여 연결문제 해결. Dimensionality reduction: 차원축소. 데이터 세트의 차원 또는 특성의 개수를 줄여 모델의 효율성을 향상. (예)연령, 교통 규정 위반 이력, 자동차 유형과 같은 고객 특성을 결합하여 보험 견적을 생성하는 것. 주요 구성요소 분석(principal component analysis) 같은 방식으로 해결.

위 분류를 기준으로 BigQuery에서 제공하는 모델을 선택하고, 데이터를 입력해서 바로 학습시킬수 있음. (예)구매예측.

Generative AI vs. LLM

생성형 AI는 텍스트외에 다앙한 유형의 콘텐트를 생성하는 더 넓은 범위의 모델을 포괄하는 반면, LLM은 생성형 AI 모델의 한 유형으로 언어 작업에 특화된 모델을 의미.

생성형 AI:

생성 모델을 사용하여 텍스트, 이미지, 기타 데이터를 생성할 수 있는 인공지능의 한 분야이며 주로 프롬프트에 응답합니다.
입력된 학습 데이터에서 패턴과 구조를 학습한 후 유사한 특성을 가진 새로운 데이터를 생성합니다.
LLM의 학습원리와 학습목적. LLM은 대규모 범용 언어 모델로 선행 학습 후 특정 목적에 맞게 미세 조정이 가능. 이때 대규모란 경우에 따라 페타바이트급에 달하는 학습 데이터 세트의 규모와 파라미터 수를 의미. 파라미터는 머신이 모델 학습을 통해 학습한 메모리와 지식. 파라미터는 텍스트 예측 등 모델의 문제 해결 능력을 결정하며 그 수는 수십억에서 수조 개에 이름. 범용이란 모델이 일반적인 문제를 충분히 해결할 수 있다는 뜻. 이는 작업의 종류와 무관하게 적용되는 인간 언어의 공통성 때문.
LLM이 선행 학습되고 미세 조정되었다고 하면 이 모델이 대규모 데이터 세트를 사용해 범용으로 선행 학습된 후 특정 목표에 맞게 더 적은 데이터 세트로 미세 조정되었음을 뜻함.
LLM의 학습: LLM에 프롬프트를 제출하면 선행 학습된 모델에서 정답의 확율을 계산함. 이 확율은 선행 학습이라고 불리는 작업을 통해 결정됨. 선행 학습은 방대한 텍스트, 이미지, 코드 데이터 세트를 모델에 피드하는 것으로 모델이 이 언어의 기본 구조와 패턴을 익힐 수 있게 함. 이 프로세스를 통해 모델은 인간의 언어를 효과적으로 이해하고 생성하게 됨. 이처럼 LLM은 고급형 자동 완성 기능처럼 작동하면서 프롬프트에 대해 가장 일반적인 정답을 제안함.

프롬프트 엔지니어링:

Storage

[Storage 종류]

Standard Storage: Hot data용
Nearline Storage: Once per month. 백업이나 롱테일 멀티미디어.
Coldline Storage: Once every 90 days.
Archive Storage: Once a year

[Autoclass 자동클래스]

각 객체의 액세스 패턴에 따라 객체를 적절한 스토리 클래스로 자동전환
스토리지 비용 감소를 위해 액세스하지 않는 데이터를 콜드 스토리지 클래스로 향후 액세스 최적화를 위해 액세스하는 데이터를 Standard Storage로 옮깁니다.

[비용]

클라우드 스토리지는 최소비용이 없음 사전에 용량을 프로비저닝할 필요가 없기 때문.

[보안]

클라우드 스토리지는 데이터를 디스크에 쓰기전에 추가 요금 없이 언제나 서버 측에서 데이터를 암호화 함.
고객의 기기와 Google 사이를 이동하는 데이터는 기본적으로 HTTPS/TLS. 전송 계층 보안으로 암호화됨.

[이동]

Course 3

[The data journey]

Collection
Processing: 데이터를 사용 가능한 형식으로 변환. 문제를 식별하기 위해 데이터를 검토+탐색+정리+구성 및 표준화.
Storage: 비지니스 요구에 따라 로컬 또는 클라우드에 데이터를 저장.
Analyze: 사용자에게 필요한 통찰력을 발견하기 위해 추세와 패턴을 식별
Activate: 활성화. 관계자에게 시각화를 제시하고 데이터에서 얻은 통찰력을 홣용하여 의사결정과 조치를 취하는 최종 결과.

데이터의 여정은 선형적이지 않다는 것이 중요.

Iterative
Repeated
Tailored
Transformation

[The data pipeline]

Extraction
Transformation
Loading

[And]

Data transformation plan
Transformation strategies

[Data collection steps]

매출 예측 델

매출 예측 모형을 학습하는 방법은 데이터의 특성과 목표에 따라 다르지만, 일반적으로 다음과 같은 절차를 따릅니다.

1. 데이터 수집 및 전처리

매출 예측을 위해 필요한 데이터를 준비합니다.

(1) 데이터 수집

정형 데이터: 매출, 날짜, 가격, 할인율, 광고비, 재고량 등
비정형 데이터: 리뷰, 소셜미디어 언급량, 뉴스 기사 등
외부 데이터: 날씨, 경기 지수, 유가 변동, 경쟁사 정보 등

(2) 데이터 전처리

결측치 처리: 평균 대체, 중앙값 대체, 삭제 등
이상치 제거: IQR, Z-score 등을 활용
정규화/표준화: Min-Max Scaling, Standard Scaling
카테고리 변수 변환: One-Hot Encoding, Label Encoding
시계열 데이터 변환: 이동 평균, 시차 변수 추가 등

2. 특성(Feature) 엔지니어링

모델의 성능을 높이기 위해 중요한 변수를 선정하고 생성합니다.

Course 2

Data storage
Data connection
Data types
Data structures
Table schemas
Batch and streaming data processing
Denormalized data
Data governance
Metadata
Data catalogs
Data lakehouse architecture
Dataplex
Identify and trace data sources
Access data libraries
Explore data reference architectures
Manage tables in BigQuery
Add and export data
Query tables
Access data from Google Cloud services
Manage Dataproc
Benefits of data partitioning

Manage Access Control with Google Cloud IAM | Google Cloud Labs 통찰력은 그것을 얻은 데이터만큼만 유효합니다. 시작하기 전에 데이터 소스가 정확하고 전반적인 그림을 정확하게 나타내는지 확인하세요.

Systems of Record(SOR)란?

Google Data storage and connection이라는 강의를 보고 있는데, Systems of record라는 단어가 나왔고. 그 번역을 보고 있으려니 무슨 개소린가 싶었지만.

금융권 기준으로 계정계를 말하는것으로 생각해도 될 거 같기는한데. 기술이 어려운게 아니라. 문화적 용어가 상이해서 어렵다.

**System of Record (SOR)**과 **Transactional Database (TDB)**는 관련 개념이지만, 목적과 역할이 다릅니다. SOR은 데이터 관리의 개념, TDB는 데이터 저장소의 유형입니다.

이렇게 설명하면 말이된다.

🔹 Systems of Record(SOR)란?

**System of Record (SOR)**는 기업이나 조직에서 가장 신뢰할 수 있는 공식 데이터 저장소를 의미합니다.
즉, 특정 데이터를 최종적으로 보관하고 유지하는 “진실의 단일 원본(Single Source of Truth)” 역할을 합니다.

GData ananysis Module 1

[Data lifecycle]

Introduction to the data management

회사가 사용자에 대한 데이터를수 수집한다고 가정.
모든 사용자가 전체 데이터에 접근 할 수 있다면 재앙이 됨. –> Data Management
Data Management는 수집, 저자으 활용에 대한 명확한 계획을 수립하고 전달하는 과정
각 단계에 대한 처리과정을 모든 직원이 이해할수 있도록 계획수립. == 데이터 거버넌스라고도 부름.
1. 원할한 협업이 보장. 문서화된 절차에 따라 데이터에 엑세스 할 수 있음으로. 데이터는 거버넌스 및 규정 준수 요구사항 내에서 유지.
2. 데이터 보안 프로그램 지원. 데이터 침해나 데이터 손실을 방지하기 위한 매개변수를 설정하는데 도움.
3. 명확한 절차를 갖추어 확장성을 높이는데 도움.
고려 핵심 측면.

Note_temp

OAuth Grant Type란?