Pinkoi資料團隊的主要任務,就是要透過優化站內搜尋引擎、推薦系統及商品排序技術,來讓用戶快速找到喜歡的品項。

圖片來源: 

圖/取自Pinkoi官網

全臺最大的設計品購物網站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,如何快速擴張運算資源來滿足一次性的工作需求,是為一大挑戰。第二,則是要做到更即時的模型決策,甚至在用戶剛看過某一類別的商品時,下一秒,就能根據這個行為來提供回饋。第三,則是仍有許多事件無法被記錄下來,資料庫往往只有當前的用戶行為資料,這部分也是團隊努力精進的方向。

熱門新聞


Advertisement