# OS HW4: MLOps

- **學號: F74076124**
- **姓名: 向景亘**
- **系級: 資訊 111**

## MLOps 的 OS 設計

### 機器學習的基本步驟

1. **資料搜集與整理**

透過各式各樣不同的方法來搜集資料，並萃取出其中對於模型訓練有效的特徵即可。並且透過 normaliztion 或是 dimesion reduction 的方式減少運算成本。

2. **模型架構規劃與建置**

依照我們所要預測的目標與資料特性來建立對應的模型，例如圖片類的資料較適合 Convolution Network，而對話或語句則適合 Recurrent Network 等等。

3. **訓練模型與參數調整**

根據模型與資料的特徵選擇較合適的參數或是 optizer 或甚至是 learning rate 來進行模型的訓練並逼近較高的準確率與較低的損失率。

4. **資料預測**

利用在前三個階段訓練好的模型進行下一步地運用或是針對目前所有的資料進行運算或分析

### 系統架構

因為我們的目標是要設計一個用於 Machine Learning 開發的作業系統，所以我將作業系統的一些部分進行拆解並非為下列幾部分進行說明：

- **資源與儲存空間配置**: 儲存測試資料，並取出作為機器學習的訓練資料使用。
- **排程演算法**: 因為在進行機器學學模型開發的作業系統上各個部分的使用情況不同，因此我會將排程器拆分在不同的部分，每個部分由獨立的排程器來運作與挑選。
- **進行模型調整與訓練之時機**: 為了方便開發者在彙整資料與模型開發上能有更大的效率，我希望系統可以在特定的時間點開始訓練模型，減少開發者的負擔。
- **模型的測試與使用**: 除了收集資料與建立模型之外，開發者或甚至使用者要能夠使用到我們在系統中所訓練好的模型，所以在這個部分我會著重在模型的使用方式和可能的介面設計。

## 資源與儲存空間配置

考慮到當今在用來訓練機器學習模型的資料量越來越大，所以我會希望以分散式的檔案系統來儲存模型所需要使用到的資料。

並且為了兼顧跨平台與建置的難易度等議題，我會希望使用 Java 主要的程式語言來進行開發，因此就能夠在不同的檔案系統會甚至不同架構的硬體上建立類似且一致的儲存環境，以方便開發者進行維護或是資料移轉等動作。

有了一致的存取介面之後，因為考慮到機器學習的資料還是以一行一行來讀取或是寫入的，所以我會希望這個檔案系統可以使用 SQL 語法來進行資料的操作。並減少 name node server 在儲存大量小容量資料的問題。

因為要使用 SQL 的語法來操作資料，所以在儲存資料結構的選用上就可以考慮 Log-structured merge-tree 來實作，因為該資料結構在寫入的時間複雜度上可以達到 $O(1)$ 的效果。在此之上可以搭配 XOR filter 等工具來加速讀取與判斷資料存在性等等用途。

digraph {
    node[shape=box]
    
    
    {"data node 1" ,"data node 2" ,"data node 3", "data node 4", "data node 5"} -> "file system interface" -> "data validation" -> "data augumentation"
    
    "users" -> "SQL interface" -> "file system interface"
    
    "data augumentation" -> "model training pipeline"
}

## 排程演算法設計

因為在這個系統中所強調的特性是用來進行機器學習模型的運算與訓練，所以我主要拆分為三個部分並依據每個部分的用途與特性來挑選不同的排程演算法來使用

### 資料庫與資料之存取

在這個部分主要希望開發者在寫入與讀取這些資料的時候可以有高度響應與互動性，所以在排程器的演算法上我會希望使用像是 **Round-Robin** 或是 **Preemptive** 等演算法來實作，從而兼顧互動性與效率。

### 模型訓練與演算

而在模型訓練的部分主要不太需要與開發者進行互動，所以在這個部分可能會採取像是**批次執行**的方式，或是使用 **FIFO** 的策略來處理模型訓練的 task，而在這個部分因為開發者較無法即時的對訓練中的模型進行更改或進一步的操作，所以只要模型訓練的過程中能夠定期回傳當前訓練的進度，或是 measure matrix 等資訊就可以了。

並且如裹在這個部分可以採取批次處理的方式，考慮到機器學習需要重複更改 hyperparameter 來逼近更高的準確率，所以如果頻繁地在不同的模型訓練的程序間切換的話，容易造成較高的 cache miss ，因此採取 FIFO 或是批次執行的方式較能夠在維持較好的 cache locality 的情況下進行演算，減少因為頻繁切換或是 cache miss 所帶來的執行與運算成本。

### 訓練好的模型使用

而當模型做完參數的調整以及訓練之後，接下來就來到了上架與使用的階段。因此在這個階段又回歸到與開發者與使用者的互動性的部分，所以在這個部分所採取的演算法又會回到在檔案與資料系統時所選用的 **Round-Robin** 或是 **Preemptive** 的演算法，在盡可能提高 Throughput 的情況下為使用者提供服務。

## 機器學習管線設計

為了流程化機器學習模型的設計與訓練，我們在這個系統中規劃了 machine learning 的 pipeline。資料流動的流程大致如下：

digraph {
    rankdir=LR
    node[shape=box]
    
    data -> "data validation" -> "data augumentation" -> "parameters modifying" -> "model training" -> "deploying model"
    
    "model training" -> "parameters modifying"
}

### data validation

資料在進到訓練之前會先經過 data validation 的檢查，確定每筆資料都是有效而沒有任何錯誤的資料被輸入到管線中，避免 anormal data 的產生。

### data augumentation

透過在資料上產生些許的 noise 與訓練用的圖片進行變形、旋轉或是縮放等等的處理，增加目標 model 的可靠性與增加資料的多樣性。

### parameters modifying

開發者在這個階段需要不斷調整 model 的架構與相關參數，包括 optimizer, learning rate 等等的調整，以利模型進行逼近。

### model training

系統在這個階段會利用在前一個階段由開發者所給定的模型架構，並使用我們在前兩個階段所篩選與擴充出來的資料進行訓練。

### model deploying

如果訓練後的模型準確率符合開發者的期待的話，我們可以將這些模型部署到系統的服務之中，供開發者與其他使用者進行使用。

## 進行模型調整與訓練的時機

在本系統中，為了方便開發者在進行模型開發的時候，不需要再額外使用 Jupyter Notebook 等外部工具來撰寫，我們將「資料搜集」、「資料整理」、「模型架構設計」、「參數調整」等等的步驟整合在作業系統之中，並且透過 CI / CD 的方式來運作整個流程。

而構成 CI / CD 的要素之中，非常關鍵的部分就是觸發這些 CI / CD 的時間點。本作業系統幾與以下的考量點設計 3 個時間驅動 CI / CD 的 pipeline 來進行作業：

1. **初次進行模型訓練：**

因為在初次建立模型的時候，在部屬的部分暫時是無法提供服務的，所以為了能夠盡快將服務提供給使用者，系統應該要在資料大小足夠，完成模型架構設計的時候，盡快的完成模型的訓練與部署，縮短開發與使用者無法使用服務的時間與經驗。

2. **模型架構更改或是參數調整：**

因為模型架構的調整有可能涉及到準確率或是預測行為的變更，所以在開發者送出模型變更的請求之後，系統需要排入新的 task 在訓練模型的排程中，以利用全新的架構來進行訓練，並進行部署。

3. **資料變更與增減：**

資料的增減與變更也會影響到模型的準確率，但是如果每一次的更改都需要重新訓練模型的話，不僅十分的沒有效率，也沒有必要。

因此我認為在關於資料變更而導致系統需要重新訓練模型的時機點的部分，應該是要在資料的變更達到一定的容量大小之後 (例如每變動 1 GB 的容量) 才進行模型的再訓練。

而如果只依照資料變更大小來判斷是否要重新訓練模型的話，可能會因為每次資料變更的大小遠小於訓練門檻，而造成模型長時間無法變更以響應當前資料的趨勢。為了避免這樣的情況產生，我認為也應該要設定重新訓練的週期，如果該模型的訓練資料在更新週期中有發生改動，但是改動的資料大小不及訓練的容量門檻時，就會觸發週期性的訓練來彌補光是透過資話大小變動的條件所造成的偏頗。

在滿足上述的兩個情況下，我認為就可以做到不頻繁的重新訓練模型，但又能維持模型在資料不定期改動的情況下週期性更新的目的。

## 模型的測試與使用

模型的測試與使用算是在這個系統中相當重要的一個部分，訓練好的模型與參數需要放在與訓練資料不同的儲存空間，方便區隔之外也可以獨立存取。

而在這個部分如果模型的訓練不如預期，我們可以在這個階段重新調整參數進行訓練，而因為這個部分涉及到了模型架構的調整，所以當我們調整參數之後，就會觸發架構調整的 pipeline 進而重新將新的模型放入訓練的排程中等待再度訓練。

而完成訓練的模型我希望系統可以利用 Web API 的方式開放給開發者與使用者來使用，因為 Web API 相較於其他 API 有更好的適用性只要透過 HTTP request 就可以使用到模型所提供的服務，且因為是透過 Web API 的方式釋出，所以我們不需要頻繁地將新版本的服務發佈在函式庫等檔案中，系統只需要更新 Web API 所提供的內容就可以達到更新的目的了。

## 參考資料

[1] [Machine Learning by Standford University](https://www.coursera.org/learn/machine-learning)
[2] [Architecture for MLOps using TFX, Kubeflow Pipelines, and Cloud Build](https://cloud.google.com/solutions/machine-learning/architecture-for-mlops-using-tfx-kubeflow-pipelines-and-cloud-build)
[3] [Intro to ML Ops: Tensorflow Extended (TFX)](https://towardsdatascience.com/intro-to-ml-ops-tensorflow-extended-tfx-39b6ab1c7dd7)

###### tags: `os`