資料科學家 L 的奇幻旅程 Vol.2 如何用資料工程當個時間旅人

在奇幻旅程的第一篇裡頭你已經看到，為何了解企業內部使用的 KPI 以及熟悉公司內部的「數據流動」能讓一個資料科學家在工作上更如魚得水。

那是一篇稍微正經嚴肅，但我認為對資料科學家來說（Data Scientist，後簡稱 DS）很有幫助的一篇文章。不過今天，我想跟你分享一個輕鬆話題：身為 DS 的我，是如何利用資料工程（Data Engineering）在公司裡頭當個「時間旅人」的。

「時間旅人？你在開玩笑嗎？」

「資料工程跟時間旅行八竿子沒關係吧！」

這可能是現在困惑的你的最佳寫照

對對對我知道。

你或許正歪著頭，想著我是不是下了個釣魚標題騙你進來。我得承認自己是個浪漫主義者，常常會將工作上的任務跟看的小說、電影做聯想。但我想，聯想力或許就是人類跟 AI 最大的差距吧！我也不覺得這是件壞事：）

拉回正題。

所以什麼是時間旅人¶

對我來說，一個理想的「時間旅人」要能掌握兩種超能力：

能夠預測未來，洞察先機
能夠回到過去，修正錯誤

而事實上後面我們會發現要實現這兩個能力，尤其是後者，除了「資料科學」以外，我們還需要「資料工程」。

掌握資料工程讓我們彷彿可以穿越時空

預測未來，洞察先機¶

如果你也是一名 DS 或是分析人員的話，應該可以猜得到，在資料科學領域裡頭，所謂的「預測未來」是指「建立某些預測模型」。

只不過，光是建立出一個可以做預測的模型並不足夠。

不管是簡單的 Random Forest 還是複雜的 Neural Network，要讓你的預測模型真正發揮影響力，你需要讓它實際上線做預測，而不只是活在你的 Jupyter Notebook 裡頭。

在資料工程領域裡，讓預測模型實際部署上線，才代表你能真正地開始「預測未來」。

你需要資料工程的知識來將一個 DS 做的預測模型「弄上線」

一些常見的預測模型案例：

使用者在安裝 App 7 天以後會不會繼續使用
顯示給使用者的廣告的點擊率
推薦給使用者的文章會不會被閱讀
預測使用者性別（儘管她/他沒說）

等等。

在目前的公司，我主要使用 Amazon SageMaker 、 Amazon ECS 並搭配 Airflow 來將這些預測模型部署到 Production 環境，以對真實世界做預測。

眼尖的讀者會發現，撇除模型或演算法，上述提到的工具並不實際跟「分析」有關，而比較偏向「工程」。為了發揮這些工具的最大效用，你可能需要了解 ETL 的概念以及如何使用 Docker。

想要有效地預測真實世界，這些工具不可或缺。

在下篇文章，我將說明如何應用上述工具以建立可靠的預測流程。而在本文，我想強調的是另一個你能透過資料工程培養的超能力：「回到過去」。

回到過去，修正錯誤¶

如果你現在正努力學習資料科學，期待未來能成為一個 DS，你可能會「想像」進了一間新公司以後，前人都已經幫你把所有專案 / 產品分析需要的關鍵績效指標（Key Performance Indicators，即 KPI）定義完成。

除此之外，所有需要分析的數據也都事先被計算好並存放在資料倉儲或是資料湖裡頭供你大展身手。

而你所需要做的，就是開始下 SQL 查詢並建立分析模型。

如果你的公司規模如 Facebook、Google 或是 Netflix 那麽龐大，裡頭已經有非常專業的資料平台團隊，則或許上述為真。身為一個小小的 DS，你無須擔心什麼 KPI 的定義或是數據品質。

規模非常大的企業讓你看到自己的渺小，但好處是身為一個 DS，你要擔心的東西可能也比較少（數據品質、KPI 定義 etc）

但很多時候，這種抱持著「KPI 永遠是對的！」的假設需要承擔不小風險。

一般企業（尤其是新創）在事後發現，一直以來追蹤、監視的 KPI 計算需要做修正是常有的事情。

最常見的一個例子就是發現當時用來計算 KPI 的 SQL 查詢需要修正，而其原因可能是：

之前產品釋出新功能，但使用者利用該功能的歷史紀錄沒有被反映到 KPI 裡頭
少做了數據品質的檢查，導致表格裡頭有 NULL 的使用者 ID 等問題，無法識別用戶
KPI 裡頭包含了不該被計算在裡頭的雜訊

不管是哪項，我們都需要做修正。

具體來說，是修正該 SQL 查詢的邏輯、更新 KPI 定義，並將改變反映到 Production 環境。

這樣你才能確保在新的一天，該 KPI 能以最正確的方式被計算出來（假設我們一天算一次該 KPI）。

畢竟如同我們在奇幻旅程的第一篇：新人不得不問的 2 個問題裡頭看到的，錯誤的 KPI 數字會讓整個數據團隊或是公司策略走錯方向，影響可說是非常深遠，得及早修正。

在你修正該 SQL 查詢並部署到 Production 環境以後，唷呼！明天我們的 KPI 就會用最正確的邏輯被計算了！

不過別開心得太早。

過去的數個月，甚至數年間持續被顯示在儀表板（Dashboard）上的數字可不會全部「自動地」被以新的邏輯重新計算。

但同時每個 PM 都拉著你，急著向你確認，到底用了最新的定義以後，該 KPI 過去的數字會變得如何、以及其對過去的分析的影響有多大。

這時你需要用新的計算邏輯 / KPI 定義來「更新」過去全部的計算結果，才能讓你公平地比較過去、現在以及未來的數字。

修正 KPI 定義以後，你會想要確保過去的數據也都隨之更新

這時候資料分析能力幫不了你，你需要的是資料工程的知識（或是一個老實的資料工程師，Data Engineer，DE）。

好消息是，如果你已經有在使用如 Airflow 等工作流程管理工具來管理你的 ETL，要「回到過去」並利用最新的計算邏輯來修正過去所有「錯誤數字」並不是一件太難的事情。

事實上，「將過去執行過的 ETL 工作重新執行」這個任務在各個公司屢見不鮮，在資料工程領域裡頭甚至有其專業術語：Backfill。

Backfill：行家才懂的資料工程關鍵字

Backfill 本身直接翻譯成「回填」，在資料工程領域裡頭，代表著「用新的計算邏輯 / SQL 查詢」將過去執行過的 ETL 工作重新執行。

更白話的比喻，你可以想像 Backfill 就是把以前的你或是前人挖的坑、犯的錯「填好填滿」。

在這邊，「計算 KPI 」就是所謂的 ETL 工作。

目前我常常使用 Airflow 以及 Amazon EMR 來重新執行 ETL 工作，並讓實際的計算運行在 EMR 環境上以 scale。

Backfill 常見到 Airbnb 甚至自己建立了一個 Backfill Framework。而在一段 Airflow 與資料工程的故事：談如何用 Python 追漫畫連載裡頭，我則詳細探討了 Airflow 與資料工程的關係，以及你可以如何利用 Airflow 來「回到過去」，修正一切的錯誤。