# 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。