---
# System prepended metadata

title: Case Study for E&I Specialits (Cloud focus)

---

# Case Study for E&I Specialits (Cloud focus)


### 架構流程圖

![](https://hackmd.io/_uploads/rJdkWnIw2.jpg)


### 1. 將CRM數據和Oracle數據庫遷移到雲平台：

#### 1.1 搬遷CRM數據：
由於X公司的CRM數據以csv文件形式存儲在本地系統中，這邊選擇 GCP Cloud Storage 去存放客戶的CRM數據，並使用 Storage Transfer Service 將這些文件傳輸到 Cloud Storage 中。

**好處：CSV文件一旦上傳到 Cloud Storage，可以輕易地和其他 Google Cloud 服務，例如：Dataflow（用於數據處理）、BigQuery（用於數據分析）等服務整合。**
    
**Cloud Storage Lifecycle Management：可以使用生命週期管理功能來自動轉移到儲存比較便宜的 Coldline 或 Archive Storage，這樣既可以節省存儲費用，又能符合X公司數據歸檔的要求。**

#### 1.2 搬遷Oracle數據庫:
由於X公司的 Orcal 資料庫，這部分可以使用 Cloud SQL 在 GCP 上實現 Oracle DB 的需求，並透過 GCP 的搬遷工具：Database Migration Service，在最小的停機時間下實現資料庫遷移，且可以確保數據在遷移過程中的安全。

---

### 2. 數據處理

#### 2.1 Pub/Sub:
使用 Pub/Sub 做為 Cloud Storage 與 Data Flow 之間的自動觸發處理流程，當有新的CRM csv文件被上傳到 Cloud Storage 時，可以設定一個 Pub/Sub 通知，然後使用這個通知來觸發 Dataflow 的數據處理流程。
    
#### 2.2 Dataflow:
使用 Dataflow 創建一個數據處理流程。這個流程將處理 Cloud Storage 的CSV文件與 Cloud SQL 中的 User Info，並根據文中需求清洗超過2年的數據，或處理X公司的其他資料需求
在 Dataflow 中進行數據質量檢查，例如，檢查數據是否缺失、是否符合預期的格式等等。且將這些指標傳送到 Google Cloud Monitoring

此方式提供了一種自動化的機制，即每次有新的數據可供處理時，都會自動啟動數據處理流程。

---

### 3. 數據質量監控

#### 3.1 Cloud Monitoring:
當 Dataflow 自動將這些指標傳送到 Cloud Monitoring時，可以在 Cloud Monitoring 頁面上，查看和分析這些指標。

並且建立警報規則在 Cloud Monitoring 中，當這些指標存在值，可以透過電子郵件發出警報給相關負責人員。

---

### 4. 處理完的資料儲存
當資料處理完成後，可以選擇將資料存放在 Cloud Storage or Big Query

#### Cloud Storage:
若X公司在此沒有分析與查看需求，可以選擇放在 Cloud Storage，對於大量的數據，Cloud Storage 是一種相對便宜的存儲選擇。

**Cloud Storage Lifecycle Management：可以使用生命週期管理功能來自動轉移到儲存比較便宜的Coldline或Archive Storage，這樣既可以節省存儲費用，又能符合X公司數據歸檔的要求。**
    
#### Big Query:
若X公司在 Dataflow 做完資料清洗後，對此時的資料有察看或分析需求，可將資料存放於此，Big Query 允許 User 透過 SQL 進行查詢。 

需要注意：BigQuery 的儲存價格可能會高於 Cloud Storage

---

### 5. 建立 Python 審查與部署流程
    
#### 5.1 GitHub:
在 GitHub 上進行 Python 的代碼審查，並設定只有通過審查的代碼才會合併到主分支。
    
#### 5.2 Cloud Source Repository:
在 Google Cloud 中建立一個新的 Cloud Source Repository，建立一個與外部 Github repository的連結，然後設定 Cloud Source Repositories 只同步主分支，此步會自動將 GitHub 上的更改同步到 Google Cloud 中
    
#### 5.3 Cloud Deployment Manager:
建立一個 YAML 的模板，用來定義相關資源和配置，會在此 YAML 中描述如何創建並配置一個虛擬機以運行Python腳本。
    
#### 5.4 Cloud Build:
建立一個 Cloud Build Triggers，監視在 Cloud Source Repositories 中的更改，並根據這些更改去自動執行 Cloud Build 的建置，Cloud Build可以根據你在 Google Cloud Deployment Manager 上定義的YAML模板文件自動創建和設定虛擬機，然後按照該文件中定義的步驟執行。
    
#### 5.5 Compute Engine:
部署好的Python腳本會在 Compute Engine 上運行，並可以從 Cloud Storage or Big Query 上抓取資料來執行聚合查詢和機器學習

< 日後，當有代碼更新時，開發人員將他們的代碼推到Git上並通過代碼審查，就會自動執行這段CD流程 >

### 6. 建立每晚排程作業

#### Cloud Scheduler + Cloud Functions:
設置一個 Cloud Scheduler 在每晚固定的時間發出請求，觸發 Cloud Function 去控制 Compute Engine 開機執行作業，並且在完成Python腳本後執行關機，在平時沒有使用需求時維持關機狀態可節省X公司的成本 

補充：需要在前面的Python腳本中去加上關閉Compute Engine的程式碼。
   
   
---    

### 7.

#### 7.1 Cloud Monitoring:
當 Compute Engine 在執行Python腳本時，透過 Cloud Monitoring 可以在頁面上，查看和分析這些指標。

並且建立警報規則在 Cloud Monitoring 中，當這些指標存在值，可以透過電子郵件發出警報給相關負責人員。


---

### 8. 將處理完的資料結果儲存在Big Query or Cloud Storage
當資料處理完成後，可以選擇將資料存放在 Cloud Storage or Big Query

#### Cloud Storage:
若X公司在此沒有分析與查看需求，可以選擇放在 Cloud Storage，對於大量的數據，Cloud Storage 是一種相對便宜的存儲選擇。
    
#### Big Query:
若X公司在完成用戶聚合與細分後，對此時的資料有察看或分析需求，可將資料存放於此，Big Query 允許 User 透過 SQL 進行查詢。 
但需要注意：BigQuery 的價格可能會高於 Cloud Storage

---

### 9. 將資料結果推送至Salesforce
使用 Cloud Functions 將資料拋轉至 Salesforce 的功能，打包成一個獨立的觸發事件功能，可利於日後維護與除錯
    
#### 9.1 pub/sub:
建立一個 Pub/Sub Topic 為 Cloud Functions 的觸發機制。觸發 在處理完資料並存入 BigQuery 後，發送一個 Pub/Sub 消息到剛建立的 Topic，觸發與該 Topic 相關聯的 Cloud Functions。
    
#### 9.2 Cloud Functions:
Cloud Functions 接收到由 Pub/Sub 通知後，處理這個事件。在 Cloud Functions 中，從 BigQuery 中提取處理後的資料，然後使用 Salesforce 的 REST API 將這些資料發送給 Salesforce。