Pinkoi資料團隊如何打造Data工作流？資料處理關鍵細節大解密

全臺最大的設計品購物網站Pinkoi，站上品牌超過一萬八千家，販售的商品更是琳瑯滿目，為了讓用戶快速找到喜歡的品項，Pinkoi資料團隊的任務，就是要不斷優化站內的搜尋引擎、推薦系統以及商品排序的技術，來提升用戶體驗。Pinkoi資料團隊工程師Ben，就在一場活動上揭露Pinkoi資料工作流（Data Pipeline）作法的演進，說明Pinkoi如何隨著更多資料分析的需求，逐步調整Data Pipeline的架構與資料工程作法，來進一步優化網站。

Pinkoi的資料團隊，從早期只有資料科學家的角色，至今已經成長為一個涵蓋4個角色的團隊，包括資料分析師、資料科學家、ML工程師以及資料工程師。其中，資料分析師屬於產品組與市場組，負責儀表板開發、資料視覺化等應用，資料科學家則負責資料庫查詢、數據轉換等應用，資料工程師主要負責資料工程相關的任務，ML工程師則偏向演算法的開發。Ben表示，每一個角色都有其主要擅長的技能，但也需對其他技能有基本的認識或涉獵，才能更緊密的協同合作。

從鑽木取火到火石取火：Pinkoi資料分析的演進歷程

Pinkoi早期主要以機器學習進行資料分析，來預測用戶對不同類別商品的喜好程度，最剛開始的Data Pipeline，是先用程式語言Python，將所需的資料從資料庫取出，放置到雲端儲存服務AWS S3之中，再以這些資料來訓練ML模型，同時將運算的結果放回S3與後端的資料庫，提供後端人員運用資料。這就是最初設計的Data Pipeline，由於整個流程較原始、單純，Ben也將這個資料運用方式，比喻為鑽木取火。

不過，隨著更多資料分析需求出現，若要回答出哪些商品頁被瀏覽過、特定商品被加入購物車的次數、哪些商品被放入慾望清單等問題，由於資料庫紀錄的資料（如使用者、品項、交易紀錄等），通常是最新狀態且不可回溯，換句話說，資料庫頂多記錄了當前購物車內有哪些商品，無法提供過去一段時間內的購物車狀態。

為了進一步找出數據洞察，Pinkoi導入了Server-side Tracking的機制，藉由用戶端（Client-side）在呼叫後端API時，將呼叫的內容轉換成定義好的事件（Event），來更詳細紀錄下每一筆用戶行為資料。

舉例來說，有個用戶將Pinkoi站上的商品加入購物車，透過Server-side Tracking就能記錄下這個事件，包括使用的裝置（Device）、發生時間（Created）、行為（Action）、對什麼物件進行操作（Entity）、商品的ID（Entity_id）以及對這個行為或物件的備註說明（Props），在紀錄下更多資料後，就能去回答前述想解決的問題，Ben也將這個更進階的資料蒐集方法，比喻為火石取火。

在運用了Server-side Tracking後，Pinkoi的Data Pipeline也隨之改變。Ben表示，現行的Data Pipeline可大致分為5個部分，第一為資料來源，主要從資料庫與Server-side Tracking機制來取得；第二是資料儲存位置，會在資料團隊將需要的資料取出（Ingest）後，以Parquet的格式存到S3；第三是資料的計算方式，早期資料團隊用數據倉儲工具Hive來計算資料，但後來轉用叢集運算框架Spark，「因為Hive基本上還是用來寫SQL，ML模型需要大量的特徵工程，用Hive比較難寫、也很難維護，所以我們後來轉用Spark。」

Data Pipeline的第四部分，則是資料的管理方法，Ben說明，Pinkoi主要用Hive Metastore來管理S3的Parquet文件，也用工作流管理平臺Airflow，來進行相依性（Dependency）的管理與排程；而最後一個部分，則是這些資料分析後的應用方式，其一是置於BI系統，讓PM、分析師來運用，其二則是回饋給站上的推薦系統或搜尋引擎使用。

運用了Server-side Tracking後的Data Pipeline。

資料分析無法面面俱到，需要權衡與選擇較佳做法

除了導入Server-side Tracking，Pinkoi也進一步導入了Client-side Tracking的機制，來蒐集更多用戶行為資料，比如特定商品在個頁面實際的曝光次數、新上線的功能是否被點擊使用、用戶停留在哪些頁面的時間最久？這些以前無法回答的問題，也在導入了Client-side Tracking的技術後迎刃而解。

不過，Ben也提醒，雖然導入了Client-side Tracking後，能蒐集更多用戶行為資料，但仍無法涵蓋站上所有發生的事情，也就是說，還是得做出權衡與選擇（Trade-Off），蒐集最需要了解的資料來應用。

比如說，為了提升用戶體驗，用戶在網站中各種操作的反應時間要越短越好，但如果要蒐集用戶行為資料，勢必要在更多程式碼中埋Log，就會導致API攜帶的資訊量變多，反而拖累了反應速度，這就需要權衡出較佳的解方。另一個例子，則是App與Web用戶的行為差異大，在埋事件追蹤碼時，要以App還是Web的用戶行為來規劃？也是一大需權衡的問題。

導入Client-side Tracking遇到的Trade-Off挑戰。

「如果要買Client-side Tracking，會需要進行很多討論，要先去衡量埋了Log可以帶來什麼價值，怎麼做才能降低成本，而不是全部都靠Client-side Tracking來解決。」Ben說。

Ben也舉例說明這些討論的必要性。假設要了解首頁上哪個版位的成效較佳，直接蒐集每個版位的曝光點擊，以點擊率作為版面曝光的成效優劣，可能是最直覺的作法，但是，也不排除部分版位可能因設計較佳，讓用戶可以很快找到喜歡的商品，進而被導流到其他頁面來瀏覽，以至於其他設計較差的版位根本沒有曝光機會，造成了資料偏誤（Bias）的問題；這時，就可能得靠A/B測試（A/B Testing）的方式，來找出更好成效的版位。而這些決策，就需要透過討論，來權衡出較好的作法。

透過良好的ETL Pipeline設計，來確保資料處理正確、高效

在Data Pipeline之中，Ben形容，還有一個如黑盒子般的存在，也就是ETL Pipeline。ETL也就是Extract-Transform-Load的縮寫，用來描述將資料從經過抽取（Extract）、轉換（Transform）、載入（Load）的流程。

Ben說明Pinkoi的ETL Pipeline作法。若簡單把ETL Pipeline分為三個階段，第一階段是資料擷取（Ingestion），也就是資料團隊將資料取出、放到S3的過程，在這之後進入資料精煉（Refined）的階段，將不需要的資料清除、並進行商業邏輯的轉換，最後則進入資料整合（Aggregate）階段，將資料整合到不同模型所需的資料中。

在設計ETL pipeline的過程中，Ben也特別點出幾個需注意之處，包括需確保Pipeline在不同時間點的執行結果一致，需透過良好的資料分割設計（Partition）來提升運算效能，且在Airflow上的任務越來越多的同時，也需注意不同工作相依性的設計，來確保資料被正確處理與運用。

最後，Ben也提出Pinkoi正在解決的問題。第一，是在資料團隊校核時，常需回滾大量資料，來執行新的POC，如何快速擴張運算資源來滿足一次性的工作需求，是為一大挑戰。第二，則是要做到更即時的模型決策，甚至在用戶剛看過某一類別的商品時，下一秒，就能根據這個行為來提供回饋。第三，則是仍有許多事件無法被記錄下來，資料庫往往只有當前的用戶行為資料，這部分也是團隊努力精進的方向。