最近很多雲栖社群的網友們看了上面一篇文章後都在追我下一篇，由于時間關系先給各位抱歉。那本篇文章我們來闡述如何通過maxcompute和quick bi來完成網站使用者畫像分析。還是和以往一樣，看看整個資料架構圖如下：
前提條件
資料來源于網站上的http通路日志資料，基于這份網站日志來實作如下分析需求：
n 統計并展現網站的pv和uv，并能夠按照使用者的終端類型（如android、ipad、iphone、pc等）分别統計。
n 統計并展現網站的流量來源。
n 統計并展現網站的使用者地域分布。
【說明】浏覽次數（pv）和獨立訪客（uv）是衡量網站流量的兩項最基本名額。使用者每打開一個網站頁面，記錄一個pv，多次打開同一頁面pv 累計多次。獨立訪客是指一天内，通路網站的不重複使用者數，一天内同一訪客多次通路網站隻計算1 次。
該資料的格式如下：
主要字段說明如下：
<b>字段名稱</b>
<b>字段說明</b>
$remote_addr
發送請求的用戶端ip位址
$remote_user
用戶端登入名
$time_local
伺服器本地時間
$request
請求，包括http請求類型+請求url+http協定版本号
$status
服務端傳回狀态碼
$body_bytes_sent
傳回給用戶端的位元組數（不含header）
$http_referer
該請求的來源url
$http_user_agent
發送請求的用戶端資訊，如使用的浏覽器等
真實源資料如下：
如上圖所示，紅色箭線部分為流式資料處理部分，主要拆解如下：
l 配置logstash，将coolshell.cn産生的日志實時采集至datahub。
l 申請開通datahub，建立項目project及topic（datahub服務訂閱和釋出的最小機關）。
l 開通maxcompute及大資料開發套件，建立項目project，并建立maxcompute表及資料同步任務。
l 将資料加工得到的結果表資料同步至analyticdb中便于quick bi進行分析。
離線分析的處理邏輯中主要設計到datahub topic、maxcompute表、analyticdb表。那這些表之間的邏輯結果以及資料鍊路是怎樣的呢？如下示例：
根據如上資料鍊路涉及到的datahub topic包括：coolshell_log_tracker。
coolshell_log_tracker
topic是datahub服務訂閱和釋出的最小機關，可以用來表示一類或者一種流資料。通過對日志結構的解析原始datahub topic：coolshell_log_tracker格式如下：
<b>字段類型</b>
ip
string
user
accesstime
method
url
protocol
status
bigint
byte_cnt
referer
agent
dt
ods_log_tracker
針對topic coolshell_log_tracker可進行歸檔至maxcompute 表中做進一步的離線分析和加工。（說明：資料歸檔的頻率為每個shard每5分鐘或者shard中新寫入的資料量達到64mb，connector服務會批量進行一次資料歸檔進入maxcompute表的操作。）
具體結構如下：
用戶端請求ip
請求方法
通路路徑或頁面
http協定版本号
伺服器傳回狀态碼
傳回給用戶端的位元組數
用戶端資訊，如浏覽器
時間分區yyyymmdd
dw_log_detail
根據agent字段的規律拆分出device（裝置）和identity（請求來源辨別）并将資料寫入maxcompute的dw_log_detail表中。表結果如下所示：
device
請求來源裝置情況
identity
請求來源辨別，如爬蟲
dim_user_info
假設基于簡單規則，ip、device、protocol、identity和agent字段資訊完全一緻可以認為是同一個使用者，來确認uid（識别唯一使用者）。同時根據ip2region的自定義函數将ip位址轉換為city字段，最終産生使用者次元表：dim_user_info，表結構如下所示：
uid
使用者唯一辨別
city
ip對應的城市
dw_log_fact
按照使用者維表進行聚合展現具體的資料産生事實表，具體表結構如下：
接着我們按照需要分析的主題進行加工資料，也就是資料倉庫領域中的adm（資料集市）層。具體如下：
adm_refer_info
按照請求來源類型進行統計，具體表結構如下所示：
請求來源
referer_count
請求來源總數
adm_user_measures
按照pv/uv來進行統計，具體表結構如下所示：
裝置類型
pv
頁面浏覽量
uv
頁面訪客數
adm_user_info
按照地域來統計使用者數，具體表結構如下：
城市
user_count
每個城市的使用者數
由于maxcompute更适合于做離線資料加工分析，最終的展現要将資料導入analyticdb進行quickbi的展現，對應的表結構同adm_refer_info、adm_user_measures、adm_user_info。
datahub topic的結構與上一篇流式資料處理的結構相同。
在大資料開發套件中建立好maxcompute表後，需要将adm資料集市層的表同步至analyticdb中，再利用quickbi進行資料分析和洞察。
<a></a>
<a>操作步驟</a>
步驟1 點選操作欄中的進入，進入dms for analyticdb。
步驟2 建立analyticdb表組，具體如下：
create tablegroup coolshell_log options(minredundancy=2 executetimeout=30000);
步驟3 建立analyticdb資料表，ddl語句分别如下。
各個處理邏輯的sql腳本如下
配置項說明如下：
函數名：getregion
類名：org.alidata.odps.udf.ip2region
資源：ip2region.jar
經過上述步驟，資料加工邏輯已經可以正常執行，那麼需要進行資料導出工作。建立三個同步任務将adm資料集市層的資料導入至分析型資料庫中，供後續quick bi更高效的洞察資料。
選擇資料源為ads，填寫配置資訊并測試連通性通過後，點選 确定 儲存配置。（其中accessid和accesskey都是大資料開發套件對應項目的生産賬号）
在maxcompute console中需要對[email protected] 與 [email protected]。如下進行：
在dms for analyticdb中建立授權，使用者為大資料開發套件項目對應的生産賬号（可從項目管理>項目配置中擷取）。
配置好maxcompute2analyticdb資料導出後，需要針對工作流任務的排程屬性尤其是排程時間進行配置（需要根據具體業務需要來進行）。配置完這些任務屬性之後需要送出并上線任務。
針對資料加工的結果，采用quick bi進行分析。其不同于傳統bi工具，quick bi提供端到端的解決方案，可以與整個阿裡雲數加大資料處理邏輯無縫對接，分析使用者在maxcompute、analyticdb上的資料。
經過資料大資料開發套件清洗/加工後的資料已經成功的寫入analyticdb，那麼通過quick bi可輕松的實作圖表、報表形式展現。
操作步驟
點選已經添加的資料源，在操作欄中分别點選 建立資料集。
點選adm_user_info
操作欄中的 分析。
在這裡需要特别注意的是，我們處理後的資料中city是字元型的，那麼如何轉為地圖可以識别的類型，需要進行類型轉化，如下圖所示：
點選選擇 dt 右鍵選擇将其轉化為次元，繼而右鍵dt 選擇類型轉化>日期（源資料格式）>yyyymmdd，在儲存彈出框中儲存為 城市分布。
點選左側
模闆 進入，選擇空白圖表模闆。按照自己需要的布局進行。
針對每個圖示可以在右側進行關聯資料集，如來自工作表..等。最終實作的效果如下：