17 Media 資料生命週期概述 - Medium

支撐17 Media 營運的數據分析是怎麼完成的呢？就請大家繼續往下看這篇文介紹的主角：資料團隊。

GetunlimitedaccessOpeninappHomeNotificationsListsStoriesWritePublishedin17LIVETechInsight17Media資料生命週期概述引言過往，企業依賴顧問的經驗來提升經營績效、開拓新市場、或是解決問題。

而今天，企業則是透過數據分析來完成上述的所有事情。

數據分析是指用適當的統計分析方法對收集來的數據進行分析，從中提取對人們有意義的資訊，詳加研究，最後概括總結的過程。

從字面上看，數據分析本身就是「數據」和「分析」兩塊工作。

一方面是採集、加工、整理數據，另一方面是結合數據背景分析數據，從中提取出對業務有幫助的結論。

那支撐17Media營運的數據分析是怎麼完成的呢？就請大家繼續往下看這篇文介紹的主角：資料團隊。

17Media的資料是如何收集的首先，簡單介紹一下目前公司本身的系統架構：為了讓讀者方便理解，本文會分成三個部分來介紹，分別是application本身的資料來源、後端所產生的資料來源、資料庫的資料來源。

這些資料就是讓資料團隊變成數據王國。

從app收集使用者資訊首先，要介紹的第一個部分就是資料來自application本身，有三個工具讓我們收集使用者的操作行為。

透過Firebase追蹤手機appUI上的使用紀錄，這在分析使用者的行為數據是非常重要的，為了要做出能打中觀眾的直播內容與產品，故蒐集使用者在app的行為來使產品更完善，包含使用者在哪個畫面做了什麼點擊，瀏覽了什麼資料等。

另外在開發新功能時，我們也會使用Firebase的custommetrics功能來紀錄對於該功能有意義的資料點，以作後續分析。

另一個來源，則透過AppsFlyer這個平台，與行銷部門做資料交換，目的是要讓行銷部門知道每個廣告渠道的數位行銷成效與指標，例如CPI跟CPA，會這樣做的目的在於行銷部門需要投廣告，透過這些資料知道哪些廣告商的績效是否如他說得好。

透過曝光所有廣告成效相關資料，使合作無論對外對內都公平。

又因為AppsFlyer產生的資料量非常大，且沒有像Firebase一樣跟BigQuery有整合，故透過使用Fluentd這個資料蒐集工具做緩衝，不要讓資料一口氣全部進入BigQuery中。

圖下方有個工具叫OneSignal，是個推播管理工具。

主要用以區分用戶，並提供簡單介面讓行銷決定發不同的訊息內容給不同類別的用戶並做訊息管理。

在訊息發出後，資料團隊就可以蒐集推播資料，以及推播的時間點等。

光是從app端就有多種資料來源，整理方面就非常地麻煩，17Media使用Google的BigQuery服務，作為所有資料的集散中心。

從後端收集資料17的後端是透過log機制紀錄使用者資訊，並將這些資訊推播到BigQuery裡面。

使用schema-lesslog是因為他對開發者很輕量化，只需要一行代碼就可傳遞所需訊息，而不需額外定義schema。

後端發出的log透過兩個工具傳遞處理：CloudPub/Sub跟CloudDataflow。

CloudPub/Sub是GCP推出的訊息佇列工具，用來暫存傳入的大量訊息以避免下一級工具處理不及。

CloudDataflow是個專門用來處理資料的worker，他讓開發者自定義資料處理邏輯以處理不同類別的資料事件。

同時CloudDataflow是個全代管服務，會自動處理應該要有worker數量，不需維運人員擔心。

從資料庫收集資料17目前使用的資料庫包括MongoDB、MySQL以及Redis。

其中MongoDB負責絕大部分的商業邏輯資料，與交易有關需要確保一致性與完整性的資料存放在MySQL，Redis則是負責快取以及少部分需要大量讀取的即時性資料。

17App每天透過使用者產生的後端相關數據約是2億多筆，這些資料透過embulk框架將大量資料搬移至BigQuery。

目前資料庫每小時同步一次，透過digdag作為排程伺服器，確保每小時的資料同步如期完成，而不讓資料的時間序列錯誤。

這些資料會透過腳本同步至BigQuery中的layer1dataset。

資料處理如上所述，不同來源的原始資料都會匯集至BigQuery。

這是資料匯集的終點，也是分析的起點。

17Media的資料分析以資料整理的想法出發，將原始資料一層一層匯總成具商業價值的資料報表。

以下介紹各層之間的轉換，以及執行數據分析的手法。

layer1到layer2Layer1是17的原始資料集散地，收集了不同來源的資料，每個來源的資料格式都不盡相同。

這些原始資料會先進行預處理以利後續分析：以來自Firebase的事件為例，我們會按照UI或是app的功能把事件做分類，這些整理好的資料就會存放到layer2。

由於layer1每張資料表之間沒有交互關係，所以不同layer1資料表到layer2的工作可以平行進行互不干擾。

layer2到layerN不同表格之間會有不同的交互作用，例如把使用者資料與他相關的付費記錄組合起來，就可以針對用戶付費行為做後續分析。

從layer2到layerN之間，需要不同資料來源或是資訊，聚合(aggregation)成下一個層級需要的資料。

同時也會加入非BigQuery來的資料，舉例來說：行銷部門針對各個廣告渠道整理出的試算表，或是節目部門所維護的直播主帳號名單。

這些非系統或軟體所產生的資料，與其他數據整合之後，就可以輔助決策組織的下一步，像是前面提到的節目部配合數據，協助直播主產生更多元的直播內容吸引觀眾，如此就能比競爭對手更有效率地拿下市場。

從前面提供的架構圖中省略了好幾層layer，原因是中間經過不少的邏輯演算、資料處理，有些資料在某層就產生了人們想要知道的結果，但有些資料則是要經過非常多層的演變才能提供可分析的樣態。

經過多道程序後完成的資料表，資料格式更適合分析，可以隨時讓分析師或內部人員取用。

一般我們會把同性質的資料整合成一張表格，例如UserBehavior這張表格包含用戶基本資料、追蹤主播、送禮點數、直播觀看次數、App功能使用情形。

匯總的資料表利於非工程人員透過簡單的操作達到分析目的。

最後對於業務需求高度相關的資料，團隊會建立dashboard讓公司所有人一目了然。

每張dashboard背後會有一個對應的資料表稱為view，針對dashboard上所想要呈現的資料跟型態做最終的資料整理。

資料支撐營運如果只是單純要產生營運資訊，為什麼要刻意用那麼多層資料處理程序呢？其實過程中資料產出物，除了內部自己的團隊要使用，也有兩個主要用途。

推薦主播給用戶當一則直播結束時，觀眾會收到名為「猜你喜歡」的推薦，這是一個由用戶的關注紀錄、主播資料、互相追蹤的事件，透過資料分析所產生的推薦。

資料團隊會計算每個用戶對每位主播的喜好程度，透過一個綜合了非常多的維度的公式產生分數，再根據這個計算結果去推斷每位用戶可能會喜好的主播，進而推薦給他。

這些計算是以Spark撰寫，利用其中的推薦模型執行機器學習，將運算得到的結果寫進Redis。

當用戶看完一則直播後，後端服務會從Redis拉取該用戶專屬的推薦名單，希望用戶能更快的找到喜歡的主播。

日前17media在印度及新加坡成立了機器學習團隊，為了讓機器學習團隊更方便取得資料，日後會重整資料提供流程，將這些data產品轉變成api服務。

提供資料給公司營運另外一種會主動提供給其他部門的，就是公司內部營運用的資料，例如點數的購買及消耗紀錄。

這些交易紀錄都存在MySQL中，但如果直接從MySQL中撈取資料，處理上會非常耗時；透過BigQuery的服務以及整理過後的資料表，直接讓系統去撈整理好的資料並做呈現。

每日報表v.s.即時報表以上數據工程所執行的流程是以產生日報表為主，在每日固定時間產生報表給營運團隊。

這一類資訊不需要即時呈現，所以每日只執行一次，例如新安裝app以及註冊人數，營運團隊會在每日整理出前一天相關的資訊，以作為策略改進方針。

對於營收相關報表，由於對公司影響較大，營運團隊需要即時數據以作更快的應變。

與金流相關的報表會透過另外一個流程產生，此流程下報表與實際數據的時間差約為五分鐘，讓營運團隊第一時間可以應變。

資料生命週期範例：功能使用率17產品團隊平均每週都有新功能上線。

為了讓團隊更了解一個功能的使用情形，包括：營運成效如何計算、是否達成部門目標、新功能是否有表現較好等。

資料團隊會針對每個功能算出使用率並且視覺化；同時也須克服各種不同的功能有不同的資料格式的問題，及要如何呈現在同一個dashboard來比較成效。

功能的資料生命週期示意圖上圖是簡化的資料流向圖，在此我們拿兩個功能作為範例：一是遊戲功能、一是聊天功能。

當用戶使用該功能時，後端會將使用資訊記載在資料庫中；這些資料會定時同步至位於BigQuery的layer1。

Layer1的資料會包含一些無效紀錄，例如遊戲資料欄位中player_id或timestamp為空值，或是聊天功能中時長小於1分鐘的對話時間，這些都會在layer1到layer2的預處理中刪除。

目前難以在這個階段判讀出一個結果，所以從layer2到layerN的過程中，與不同的資料表交集、匯總計算出目標資料內容，找出不重複的用戶數，以及這個功能的id，寫進report_summary這張資料表中。

有了這些資料內容，就可以將各功能不重複的使用次數視覺化成如下的使用率比較圖，從中了解不同功能的被使用率。

日均功能使用率比較。

由圖上可知第一個功能的使用率有48.13%。

這數據可讓產品經理判斷是否要花更多的心力來加強功能。

我們也可以在分析的過程中找出單一功能的使用次數是否逐日增加，例如遊戲功能的使用是否有成長的趨勢。

我們一樣可按照前面的分析流程，將遊戲功能的資料格式加入時間戳記，利用不同天數作為比較基準進行交集，經過幾層的數據分析所產生的結果寫進report_summary中，透過每日定時的時間戳記進行比較，就可以知道此功能是否有逐漸被多數人使用，是否有達到預期的成效。

單從功能與使用人數來看，是呈現上漲的趨勢結語任何從事數據工作的人，尊重數據結果，並分析形成結論。

數據分析是條企業永遠會持續要走的路，在任何情境下都會有數據分析的需求，從中產生洞見，掘發商機，也許你會想知道怎麼加快壯大自己的數據分析技能組。

在17你可以遇到頂尖好手，加速您上手data相關技能，這是一個多元化app的壯大旅程，歡迎加入我們！職缺列表：http://bit.ly/2qnPLwmMorefrom17LIVETechInsightThoughtsandideasfrom17LIVE’sproduct,engineeringanddatateam.Readmorefrom17LIVETechInsightAboutHelpTermsPrivacyGettheMediumappGetstarted17MediaTechnology361Followers17MeidaTechnology希望能夠構築一個專屬於技術的社群，讓知識得以流轉FollowHelpStatusWritersBlogCareersPrivacyTermsAboutKnowable