iT邦幫忙

2021 iThome 鐵人賽

DAY 24
0
AI & Data

資料產品開發與專案管理系列 第 24

[Day 24] 資料產品在部署階段的五個大坑

上線之後才是開始。

第一坑 開發和部署環境不一致

如果一開始開發和部署沒有「喬好」環境的話,那上線的過程可是會吃一番苦頭。例如搞不清楚環境有哪些套件,只好正式環境亂裝一堆。如果每個開發工程師都用不同的套件,那正式環境會變得異常複雜。如果正式環境是分散式系統的話,狀況又會變得更複雜,需要確保每台節點都有相同的套件。現在大多人用的解法都會使用 Docker Image 來將程式和套件一起打包,這樣一來方便管理上線的版本,二來也是可以讓開發與部屬環境保持一至。

第二坑 出現不如預期的結果

不管是原始資料、加工資料、模型什麼的,上線之後永遠會產生意外的狀況。不是資料格式不對、筆數不對、轉換方式錯誤、或是意外的預測結果,總之「有可能發生的問題就會發生」。這些意外往往是來自於資料產品層層疊疊的影響,只要一層出錯,後面就很有可能接連產生錯誤。

舉例來說,之前我們都是透過 AWS Kinesis 來接收使用者手機傳送過來的資料,後續所有 ETL、使用者報表、模型都是依據這個資料來做處理。有一天 Kinesis 在半夜斷了兩小時,少了這兩小時資料,計算每日使用者數的報表自然就發生異常、另外一張根據每日使用者人數計算存活率的報表自然也不正確、少了那兩小時的資料,針對使用者觀看影片的訓練的推薦模型自然也會受到影響。

第三坑 非預期結果的後續影響持久

這些異常的後續效果會比想像中還來得久以及來的難處理。例如延續上面的例子,儘管後來 Kineis 修復後資料成功進來,但是像是「過去七天使用者人數」的報表、或是「過去三十日觀看熱門影片」都會有一天的資料是「不正確」的,直到那個有問題的資料不會再被查詢之後影響才會消失。

第四坑 稍微複雜的二階段部署

由於壞資料的影響會留存很久,所以我們必須盡量避免壞資料進入生產環境。這時候就很推薦使用「兩階段轉換」。將處理完的結果,先放到別的地方,等資料驗證沒有問題後,再進入正式的 DB。

然而二階段轉換並不是說單純把資料放到 Staging 環境而已,以下就來說明開發 Data Pipeline 通常的做法,以及環境的區分。

從測試到正式環境

ETL 的正確性涵蓋了兩部分:

  1. 原始資料的正確
  2. 商務邏輯的正確

所以一般來說,比較嚴謹的開發流程會是這樣子:

  • 測試資料 => 測試資料處理程式 => 測試 DB(先確認資料處理程式正確)
  • 測試資料 => 正式資料處理程式 => 測試 DB
  • 正式資料 => 正式資料處理程式 => 測試 DB (確認資料處理程式能應付正式資料)
  • 正式資料 => 正式資料處理程式 => 正式 DB

加入二階段轉換後最終會像這樣:
正式資料 => 正式資料處理程式 => 暫存區 => 確認資料品質 => 正式DB

其他變形應用

當然除了放到暫存區之外,也可以直接在程式裡確認程式品質,放在同一個處理程式中:

  • 正式資料 => 「正式資料處理程式 => 暫存區(in memory) => 確認資料品質」 => 正式DB

當然當資料量大,或是需要累積多一點資料一起驗證時,還是會先落地在檢查。

  • 正式資料 => 正式資料處理程式 => 暫存區(in db 或其他persistance storage) => 確認資料品質 => 正式DB

第五坑 安全性管理

由於資料產品包含許多隱私或是機敏內容,所以在安全性上一定要特別注意,這邊列幾個比較常被忽略的地方:

  • 使用者介面
    像 Airflow Web Server ,這是是使用者觀察 job 執行的和操作的入口。雖然不能直接刪除 Job,但是仍然可以可以看到 DAG 的 Code。那如果您用的是 Jenkins ,或其他可以直接在 UI 上刪除 Job 的套件,在權限控管上更要小心。

  • Job Runner
    Job Runner 通常是用來實際執行 ETL 程式的環境。Job Runner 由於要直接執行各式 ETL,通常會擁有比較多的權限,像是:存取 s3 bucket、存取 Database、Athena,甚至操作其他 AWS 元件等等。所以通常不會直接開放給使用者連線,而是僅開放從公司或特定內部連線存取。

我們可以從兩方面來控制:

  • 連線管理
    網路連線需要一邊管理使用者可以從哪連線,另一邊管理服務可以跟誰連線。一般來說會採取這樣的方式:
    使用者 > UI > Job Runner > Database。
    使用者 > UI > Metadata DB

  • 資源權限管理
    在 AWS 上很方便的就是可以透過給予機器 instance_profile 的方式來給予權限,讓 service 可以不用碰到權限管理的問題。但是另外一方面,如果我們都將 Airflow 的 UI / Job Runner 都部署在 k8s 上,要從機器來管理權限恐怕又不是那麼容易。比較理想當然是拆成 node pool,但是現實上…

帳密(Secret)管理

一個好的程式,就不該把帳號密碼寫在裡面。如果要用到 db connection,可以從環境變數拿,或是像 Airflow 這樣從 secret manager 拿。用統一的 secret manager 拿的好處很多。除了安全之外,當連線資訊要更改時(例如有些公司規定三個月要變更密碼一次),也可以很輕鬆的替換。

https://ithelp.ithome.com.tw/upload/images/20210925/201411401sfj9cpDEK.png


上一篇
[Day 23] 資料產品在設計與開發階段的五個大坑
下一篇
[Day 25] 資料產品在評估階段的五個大坑
系列文
資料產品開發與專案管理30

尚未有邦友留言

立即登入留言