# GCP 進階技術課3

## serverless

### serverless 服務有：
- cloudrun: Container Image
- app engine：node.js, java 的專案 -> 要被淘汰
- cloud function: 只有程式碼

### cloud run:
- 全託管基礎設施
- 用多少算多少
- container 平台，快速部署 container 化程序
- 好處： 不用先建一個 vm，再起 container
- 計費分配：
- 費用
- 流量型態
- 執行個體上限
- default 1000
- cpu < 4000
- mem < 16000
- container 相關設定
- CUP and mem 設定
- cpu 上限 8Gb
- mem 上限 32Gb
- request 設定：
- *待補*
- 第一代：更快的冷啟動時間
- 第二代：必須 mem > 512m, 需要 network file system,cold start 情況很少見, 要更快的網路性能, 需要使用 Linux cgroup 功能
- 計費： 跟 region 有關, 機器開多久算多久, cpu, mem

### cloud function
- serverless: 全託管, 用多少算多少
- 跑得算是簡單的程式碼服務
- 協助透過單一用途程式碼架構及連結事件導向服務
- 逾時時間：60s ~ 9 min（第一代），因此爬蟲服務的話，要以小一點的爬取單位
- 設定自動調度資源: 最高可達20億(單位)
- 服務如果比較簡單、次數又多 就選用 cloud function or cloud run
- 費用：機器運行時間，呼叫前 200 萬次免費
- 第二代： http-triggered function 可以達 60min，其實第一代就很好用

https://cloud.google.com/blog/products/serverless/cloud-run-vs-cloud-functions-for-serverlessr

- development flow 部署:
- flow(或許還有其他種 先放這種！): func() -> gcs -> cloud build -> push to artifact registry, deploy
- 最好的驗證方法： 建立 CI/CD 流程

- source code
- 要有特定的目錄結構

## log and monitor

### ops agent
- 收集 log 與 指標的代理
- 無須任何配置即可收集標準系統日誌
- Linux and windows 都可以使用
- 需訪問 Oauth2
- 建立 vm 時，可以在 observibility 把 ops agent 打勾

### Alert
- 系統指標: CPU RAM 使用率
- log metric
- 運作時間檢查：server 是否正常服務
- uptime check: 需要開防火牆，來讓 google 戳服務，會因為region設定不同要開不同的 ip
- transform data
- 滾動週期: 支援s, min, hr, d
- 滾動週期函式: min, day...
- Configure alert trigger
- threshold
- 最高門檻, 最低門檻
- 門檻值
- metric absence
- 缺少觸發條件的時間(這會複寫滾動週期)
- forecast: 最近出來的,針對目前網路流量 cpu, mem 預估接下來的走向
- alert trigger: 有時間序列的概念，時間序列的百分比違反條件時, 時間序列樹違反條件時, 所有時間序列違反條件時
- notification channels: mobile device, webhook, emailm sms, pub/sub
- alert 可以在 incidents 上看，如果一直是 ！ 代表還沒被解決

### logging

#### Log Type
- 管理員活動審核日誌
- 沒辦法排除寫進 cloud logging
- 即使停用 cloud logging API, 仍然產生管理活動審核日誌
- 大多是建立vm, iam 之類的 log
- 資料存取審核日誌
- 像是存取 BQ 資料之類的
- 除了 bq 以外的，基本上 log 都是關閉的，因為資料存取的 log 會是很大量的，避免費用暴增！

- 系統事件審計日誌
- 像是 cloud sql 要更新之類
- 無法排除的
- 策略拒絕審核日誌
- 像是 cloud armour
- 可以用 log sink 做接收器 filter
- log metric: 針對 log 來設定 alert
- log retention:
- _default: 預設保留 30d, 保留上限 3650d
- _required: 預設保留 400d, 管理員 log 通常是這個, 上限400d
- custom: 預設保留 30d ,上限 3650d
- logging price 要很小心！！ 像是 vpc log price 就很貴

## bigquery
### overview
- 速度極快的 dataware house
- 可處理 pb 等級
- serverless
- 支援幾乎所有 sql 語法

### security
- 可用 iam 來做控管
- always encrypted: 也可以用地端 key 來加密 gcp 金鑰
- Discover, classify and redact sensitive data: 透過 cloud DLP 發現,識別機敏資訊

### 非結構化資料
- bq 產 table -> unstructed img

### BQML
- 可建 ml model
- 無需使用 python 或是 jave 撰寫, 透過 SQL 語法即可
- 支援多種 model, tensorflow model import
- fast~

### table and views
- table 可以是 bq 原生 or 外部的
- table 上面可以打 label: ex: 資料過期時間設定
- 資料來源： local db, google driver, aws s3 ...
- native table: 儲存類型是 bq 最佳化型態, time travel 可以選時間區間，做資料死亡的復原（近 7 天），預設情況下：會免費幫每個使用者24hr內快取 query 結果，也就是針對快取就不會因為 query 收取費用
- native table 格式：csv, avro, json,...
- federated query 聯合查詢：會把 query 傳到外部資料表，效能一定不高啦～
- bigquery omni: 如果有一組 datawarehouse 這麼大規模的資料在 aws，會需要很長的時間跟費用，omni 會直接在別的雲端建 bq，因此就不用把資料傳回 gcp bq 在做運算，使用上不太建議XD 因為架構一定不如gcp bq 如果真的要，還是建議把資料丟回 gcp 吧～

### external data source
- etl operation
- frequently changing data
- data lake feeds other systems
- data must live outside bq

### views
- type:
1. logical views: 一次性查詢, 不積極的，無建立實體表，每次query 每次查詢
2. Materialized views: 定期 view query 的內容, 會積極分析, 會自動化的資料導向，是已經建立實體表了

### pricing
- 主要來自 analysis, storage 其次：data transfer, ingestion, extration, 再來：ml, bq omni,

### bq fair scheduler
大致參考 意思是說正在執行的 query 也可能被停掉嗎???!!!
會一直 re-allocate slots??
- bq 透過 slots 來做 query
Slots are distributed fairly among projects and then within the jobs in the project. This means that every query has access to all available slots at any time, and capacity is dynamically and automatically re-allocated among active queries as each query's capacity demands change.
- Whenever a new query is submitted, capacity is automatically re-allocated across executing queries. Individual units of work can be gracefully paused, resumed, and queued up as more capacity becomes available to each query.
- Whenever a query completes, capacity consumed by that query automatically becomes immediately available for all other queries to use.
- Whenever a query's capacity demands change due to changes in query's dynamic DAG, BigQuery automatically re-evaluates capacity availability for this and all other queries, re-allocating and pausing slots as necessary.

https://cloud.google.com/blog/topics/developers-practitioners/bigquery-admin-reference-guide-jobs-reservation-model

### bq edition
- 標準
- 企業
- 企業＋

### storage pricing
- active logical storage
- long-term logical storage
- active physical storage
- long-term physical storage
- 儲存空間： physical < logical (因為 table 資料可壓縮)
--> 這樣幹嘛要用 logical? logical tablel 差異是甚麼?
我看 logical data 是不壓縮的 好問題 我還看不懂><
- physical 要支付 time travel, fail-safe 功能的錢

### partition
- 目前無法將一般table轉成partition table
(--> 感覺好廢，如果突然想要怎麼辦 ( --> 重新建表 塞表 (--> 天啊~ 一開始就要決定好的意思
- As estabishing partition table,要設定 partition table 類型
- 最多 4000 個 partitions
- time-unit column: date, timestamp, datetime
- 可以用 only-partition scan

### clustering
- 會搭配 partition (--> 可以不搭配嗎?
- 可針對 type: date, datetime, string, numeric...
- 越常查詢放越前面
-

## AI platform

### vertex AI
- unified AI platform
- pre-trained model: cv, language, conversation
- workbench -> jupyter notebook

### generative AI
- to C(consumer): 大方向, ex: chatGPT, Bard
- to B(business): 正確性, 費用, 如何 train, ex: vertex AI, open AI

### VPC service control
- 並不是一個服務，比較像是 policy，控制人員存取資料的功能，限制 api 流量，限制只有某些 ip 可以進來
- 類似白名單： 只有給 ingress, egress 才會能進入，否則一率拒絕
- 建議在測試環境先測，不要直接上 prod
- 搭配 access context manager: 建立存取層級 ex: define company-ip
- 限制人存取專案 -> vpc service control, 限制存取服務 -> iam
- 適合用於大部分都是 google 託管的服務，沒辦法設定網路的服務，例如: bq

1/12 回饋HW
1/16 刪除帳號