企業最終的資料往往都隱藏在日誌背後， 如果從日誌背後挖掘出有價值的資訊， 勾畫出平臺或網站的用戶畫像對精准化運營有著重要的幫助。 阿裡雲技術專家禕休帶來阿裡在處理日誌、構建數倉上的最佳實踐分享。 主要從數倉開發開始談起， 重點講解了資料加工使用者畫像的五大步驟， 最後進行了演示解析。
以下是精彩視頻內容整理：
資料融合加工-數倉開發大資料倉庫特殊引擎提供我們一站式的PB級大資料倉庫解決方案， 那麼， 我們如何基於MaxCompute去構建倉庫， 如何去幫資料進行清洗加工，
在數倉上的開發規範如圖， 從日誌資料、使用者基本資訊資料等裡面去挖掘出價值資訊， 然後涉及到資料開發人員做一些ETL的設計， 包括我們的一些開發編碼、設置， 將任務提交到線上， 線上上我們會遇到過去的一些資料運維工作， 這些運維工作是不是可以在Dataworks裡面去完成？下面我們一起來瞭解操作細節。
1. 需求分析
通常情況下會以一個這樣的鏈路圖去做用戶畫像， 可以看到， 使用者畫像通常情況下會包含兩個部分， 動態資料和靜態資料。 動態資料包括行為資料、頁面行為、交易資料， 比如說你的使用者點擊流覽資料等都可以放在動態的資料裡面去， 比如說在我們的網站整個的訪問深度， 是不是在頁面上形成了時長有多少， 在某一整個鏈路上註冊開通再到資料開發的跳失率是多少等等；靜態資料更多的是關於人的一些屬性， 比如說姓名、星座、年齡、長居地以及通常使用什麼樣的設備去訪問我們的網站等等，
數倉創建
做數倉要進行數倉分層， 底層是ODS層， 通常情況下將原始的資料先採集到MaxCompute上來， 對一些非結構化資料進行一定的結構化， 包括一些資料的規範化， DWD層有我們的一些明細資料，
原始資料可以通過這些欄位裡面去獲得什麼樣的資訊？一個日誌資訊裡面，包含使用者來訪問網站或者平臺IP位址、用戶登錄名，然後通過一些欄位可以分析設備資訊，比如說我們可以從使用者真實的資料裡面看到IP位址，包括什麼時間去訪問，訪問了我們哪一個頁面，使用了什麼樣的流覽器，流覽器內容是什麼，有的直接用手機端等等，我們可以通過這些資訊去挖掘出更多的資訊，比如說可以通過IP位址知道用戶長居住在哪個城市來訪問我們網站，通過user_agent欄位可以獲取設備資訊，因為我們去訪問終端一些版本，設置可以通過這些資料進行一個結構化，然後把資料抽象處理。
使用者資訊表就是一張結構化的二維表，通常會包含一些使用者的資訊、性別、年齡、星座等等。
通過已有的這些資料，再去做使用者畫像時候可以看到，深色是已有資料，可以去刻畫出用戶在我們網站的流覽性，比如說整個網站的PVUV等等，通常訪問哪個頁面更高，然後在什麼時候去訪問。
3. 資料開發
接下來進入資料開發階段，資料開發階段要去實現如圖邏輯，左邊ods_log_info_d這張表存著我們的日誌資訊，我們要去公開一個結構，將使用者IP位址解析出來一個一個地域資訊。右邊ods_log_info_d使用者的基本資訊已經是結構化了，這兩個資料通過UID進行關聯，JOIN成一張大表，原封未動的將我們的資料獲取到MaxCompute上來，然後在DW層裡面做更多的關聯，關聯出一張用戶去訪問我們廣泛基本資訊的寬表，然後基於這個寬表之上，我們有一個IP位址，要知道這個使用者PV的具體資料，比如求平均值或者求在整個網站訪問的最佳深度等。
在創建表的時候怎麼更全面？我們發現，所有工作流任務、節點任務，包括我們的表，命名其實都有一個規則，如果你的資料量很大，通常情況下包含資料庫的倉庫分層、業務域、資料欄和資料分析時間，這張表屬於DW層，這張表刻劃了一個使用者的基本資訊，這就表示這張表的資料是一天更新一次的，通過這樣一張表可以明確知道刻劃什麼樣的業務價值，讓依賴于這張表的下游同學可以快速認識這張表的資料分析時間，描述什麼樣的資訊。
另外,我們的IP去轉地域資訊，在公共雲版本上面函數是沒有對外開放的，所以需要去解決自訂的函數，但有一些函數不能滿足配置，比如說大寫轉成小寫，將IP轉成region如何去做，通常情況下我們會去寫一些Java去做這樣的事情。將這些函數、資源包註冊到MaxCompute上來，通過堆頭註冊上來，然後去對函數進行解析。
4. 最佳實踐
我們強調每一個節點裡面最多輸出一張表，當你有多張表的時候，比如說任務失敗了，可能是因為其中某一條處理的邏輯失敗了，當你去重跑的時候，可能整個任務都要重新去跑，另外，你的輸出表表格一定要跟你的節點名稱一樣，這樣可以快速從你的輸出運維上，快速找到這張表的資料在哪個節點上沒有產生，是因為哪一些任務失敗了。
大家都知道，大資料裡面可能會有預測的insert overwrite，比如說測試資料任務時候會加資料庫，通常情況下會造成資料重複和資料產生，如果你去使用灰色的overwrite，或者是每一次的任務重跑或失敗之後，你要去手工再把這個任務調動起來，會根據你的分區表資料批量進行。這樣最多的好處是每一張表資料的產生，比如說代碼加一些注釋，比如說整個SQL邏輯是處於什麼樣的，一定要在前面去進行相關的注釋。
在操作過程中，大家儘量去減少Select*操作，因為你的計算成本比較高，在2.0裡面我們已經打開了全表推出，用戶去進行一個選表，上個月去拜訪什麼客戶，通常情況下每個月在平臺上消費3千多，在所有查看資料的時候，沒有加分區的全表掃的計算成本很高，所以建議大家在去使用的過程中多加一個分區排檢，可以減少我們的計算成本。
在公共雲上，我們有一些公共雲的服務，還有一些私有化服務，比如說安全行業、金融行業，通常都需要將大資料部署穩定，我們的項目創建的一個或者兩個如何區分？通常情況下會有開發和生成，開發就交給資料開發團隊去把資料任務開發好、調試好，然後發佈到生產環境上去，生產環境上更新一些配置的調度資訊，比如說按天、周、月等等去運維，對他的資料開發流程要求特別嚴，通常情況下有更多的事情發生，包的開發、測試，還有一些預發環境和生產，整個代碼環境都會去詳細的進行運維，你去創建的時候，可以在專案配置中去調試，比如說在開發專案裡面，通常情況是不打開調度參數，就是說你創建的客戶提交之後，不會每天自動去調度，當你把任務發佈到生產的專案上面，根據你的配置更新每天去同步。
調度參數方面，比如說將資料如何去寫到一個最新的分區，比如說分公司24號對應的分區裡面，25是新的一些事情，如何去起到新對應25號的分區裡面去，我們提供這樣的參數，當你配置這樣的系統參數時候，每次在我們調度系統的時候會自動進行切換，一些日期不需要你每次手動去創建分區。
5. 實驗操作
通常情況下，我們先去創建所謂的三張表，每張表簡單去適應如何分層，比方說第一層ODS層，第二層是DW層，從結構上面也可以看出來，每一個節點都是相當規則，當這張資料要同步到MaxCompute上，肯定是要建一個目標表，同樣有一張表可以存儲這張資料。然後創建工作流節點，接著創建自訂UDF，最後配置SQL節點和測試運行。
本文由雲棲志願小組毛鶴整理，編輯百見
原始資料可以通過這些欄位裡面去獲得什麼樣的資訊？一個日誌資訊裡面，包含使用者來訪問網站或者平臺IP位址、用戶登錄名，然後通過一些欄位可以分析設備資訊，比如說我們可以從使用者真實的資料裡面看到IP位址，包括什麼時間去訪問，訪問了我們哪一個頁面，使用了什麼樣的流覽器，流覽器內容是什麼，有的直接用手機端等等，我們可以通過這些資訊去挖掘出更多的資訊，比如說可以通過IP位址知道用戶長居住在哪個城市來訪問我們網站，通過user_agent欄位可以獲取設備資訊，因為我們去訪問終端一些版本，設置可以通過這些資料進行一個結構化，然後把資料抽象處理。
使用者資訊表就是一張結構化的二維表，通常會包含一些使用者的資訊、性別、年齡、星座等等。
通過已有的這些資料，再去做使用者畫像時候可以看到，深色是已有資料，可以去刻畫出用戶在我們網站的流覽性，比如說整個網站的PVUV等等，通常訪問哪個頁面更高，然後在什麼時候去訪問。
3. 資料開發
接下來進入資料開發階段，資料開發階段要去實現如圖邏輯，左邊ods_log_info_d這張表存著我們的日誌資訊，我們要去公開一個結構，將使用者IP位址解析出來一個一個地域資訊。右邊ods_log_info_d使用者的基本資訊已經是結構化了，這兩個資料通過UID進行關聯，JOIN成一張大表，原封未動的將我們的資料獲取到MaxCompute上來，然後在DW層裡面做更多的關聯，關聯出一張用戶去訪問我們廣泛基本資訊的寬表，然後基於這個寬表之上，我們有一個IP位址，要知道這個使用者PV的具體資料，比如求平均值或者求在整個網站訪問的最佳深度等。
在創建表的時候怎麼更全面？我們發現，所有工作流任務、節點任務，包括我們的表，命名其實都有一個規則，如果你的資料量很大，通常情況下包含資料庫的倉庫分層、業務域、資料欄和資料分析時間，這張表屬於DW層，這張表刻劃了一個使用者的基本資訊，這就表示這張表的資料是一天更新一次的，通過這樣一張表可以明確知道刻劃什麼樣的業務價值，讓依賴于這張表的下游同學可以快速認識這張表的資料分析時間，描述什麼樣的資訊。
另外,我們的IP去轉地域資訊，在公共雲版本上面函數是沒有對外開放的，所以需要去解決自訂的函數，但有一些函數不能滿足配置，比如說大寫轉成小寫，將IP轉成region如何去做，通常情況下我們會去寫一些Java去做這樣的事情。將這些函數、資源包註冊到MaxCompute上來，通過堆頭註冊上來，然後去對函數進行解析。
4. 最佳實踐
我們強調每一個節點裡面最多輸出一張表，當你有多張表的時候，比如說任務失敗了，可能是因為其中某一條處理的邏輯失敗了，當你去重跑的時候，可能整個任務都要重新去跑，另外，你的輸出表表格一定要跟你的節點名稱一樣，這樣可以快速從你的輸出運維上，快速找到這張表的資料在哪個節點上沒有產生，是因為哪一些任務失敗了。
大家都知道，大資料裡面可能會有預測的insert overwrite，比如說測試資料任務時候會加資料庫，通常情況下會造成資料重複和資料產生，如果你去使用灰色的overwrite，或者是每一次的任務重跑或失敗之後，你要去手工再把這個任務調動起來，會根據你的分區表資料批量進行。這樣最多的好處是每一張表資料的產生，比如說代碼加一些注釋，比如說整個SQL邏輯是處於什麼樣的，一定要在前面去進行相關的注釋。
在操作過程中，大家儘量去減少Select*操作，因為你的計算成本比較高，在2.0裡面我們已經打開了全表推出，用戶去進行一個選表，上個月去拜訪什麼客戶，通常情況下每個月在平臺上消費3千多，在所有查看資料的時候，沒有加分區的全表掃的計算成本很高，所以建議大家在去使用的過程中多加一個分區排檢，可以減少我們的計算成本。
在公共雲上，我們有一些公共雲的服務，還有一些私有化服務，比如說安全行業、金融行業，通常都需要將大資料部署穩定，我們的項目創建的一個或者兩個如何區分？通常情況下會有開發和生成，開發就交給資料開發團隊去把資料任務開發好、調試好，然後發佈到生產環境上去，生產環境上更新一些配置的調度資訊，比如說按天、周、月等等去運維，對他的資料開發流程要求特別嚴，通常情況下有更多的事情發生，包的開發、測試，還有一些預發環境和生產，整個代碼環境都會去詳細的進行運維，你去創建的時候，可以在專案配置中去調試，比如說在開發專案裡面，通常情況是不打開調度參數，就是說你創建的客戶提交之後，不會每天自動去調度，當你把任務發佈到生產的專案上面，根據你的配置更新每天去同步。
調度參數方面，比如說將資料如何去寫到一個最新的分區，比如說分公司24號對應的分區裡面，25是新的一些事情，如何去起到新對應25號的分區裡面去，我們提供這樣的參數，當你配置這樣的系統參數時候，每次在我們調度系統的時候會自動進行切換，一些日期不需要你每次手動去創建分區。
5. 實驗操作
通常情況下，我們先去創建所謂的三張表，每張表簡單去適應如何分層，比方說第一層ODS層，第二層是DW層，從結構上面也可以看出來，每一個節點都是相當規則，當這張資料要同步到MaxCompute上，肯定是要建一個目標表，同樣有一張表可以存儲這張資料。然後創建工作流節點，接著創建自訂UDF，最後配置SQL節點和測試運行。
本文由雲棲志願小組毛鶴整理，編輯百見