企業最終的資料往往都隐藏在日志背後，如果從日志背後挖掘出有價值的資訊，勾畫出平台或網站的使用者畫像對精準化營運有着重要的幫助。阿裡雲技術專家祎休帶來阿裡在處理日志、建構數倉上的最佳實踐分享。主要從數倉開發開始談起，重點講解了資料加工使用者畫像的五大步驟，最後進行了示範解析。 直播視訊回顧請點選 以下是精彩視訊内容整理：
資料融合加工-數倉開發
大資料倉庫特殊引擎提供我們一站式的PB級大資料倉庫解決方案，那麼，我們如何基于MaxCompute去建構倉庫，如何去幫資料進行清洗加工，然後去挖掘出有價值的資訊？MaxCompute2.0推出了一些新功能，比如說非結構化資料的處理， MaxCompute支援非結構化資料存儲在OSS上，以前的方式是通過資料內建工具或者自己去寫一些任務，将這些資料周期性或者一次性同步到MaxCompute上來，既有開發成本，又有運維成本，在2.0裡面我們支援直接建立外部表的方式連接配接資料源，直接對資料進行處理。
在數倉上的開發規範如圖，從日志資料、使用者基本資訊資料等裡面去挖掘出價值資訊，然後涉及到資料開發人員做一些ETL的設計，包括我們的一些開發編碼、設定，将任務送出到線上，線上上我們會遇到過去的一些資料運維工作，這些運維工作是不是可以在Dataworks裡面去完成？下面我們一起來了解操作細節。
1. 需求分析
通常情況下會以一個這樣的鍊路圖去做使用者畫像，可以看到，使用者畫像通常情況下會包含兩個部分，動态資料和靜态資料。動态資料包括行為資料、頁面行為、交易資料，比如說你的使用者點選浏覽資料等都可以放在動态的資料裡面去，比如說在我們的網站整個的通路深度，是不是在頁面上形成了時長有多少，在某一整個鍊路上注冊開通再到資料開發的跳失率是多少等等；靜态資料更多的是關于人的一些屬性，比如說姓名、星座、年齡、長居地以及通常使用什麼樣的裝置去通路我們的網站等等，是以有一些終端裝置的偏好資訊。
數倉建立
做數倉要進行數倉分層，底層是ODS層，通常情況下将原始的資料先采集到MaxCompute上來，對一些非結構化資料進行一定的結構化，包括一些資料的規範化， DWD層有我們的一些明細資料，我們要在這些資料之間能夠産生一些價值，做一些資料清潔工作、資料交換工作，将資料進行打包，再向上我們要根據資料去做一些公共名額加工和應用名額加工，比如PVUV的通路、裝置的通路等等。
2. 原始日志分析
原始資料可以通過這些字段裡面去獲得什麼樣的資訊？一個日志資訊裡面，包含使用者來通路網站或者平台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節點和測試運作。
本文由雲栖志願小組毛鶴整理，編輯百見