離線計算系統綜合案例
本文目標
- 理解網站點選流資料分析的業務背景
- 理解網站點選流資料分析中常用分析指標的業務含義
- 掌握網站點選流資料分析系統的技術架構
- 掌握網站點選流資料分析系統中各環節的技術實現
- 能獨立設計完成一個初步的網站點選流資料分析系統
網站點選流資料分析，業務知識，推薦書籍：
《網站分析實戰——如何以資料驅動決策，提升網站價值》王彥平，吳盛鋒編著
- 一、網站點選流資料分析專案業務背景
- 1.1 什麼是點選流資料
- 1.1.1 WEB訪問日誌
即指使用者訪問網站時的所有訪問、瀏覽、點選行為資料。比如點選了哪一個連結，在哪個網頁停留時間最多，採用了哪個搜尋項、總體瀏覽時間等。而所有這些資訊都可被儲存在網站日誌中。通過分析這些資料，可以獲知許多對網站運營至關重要的資訊。採集的資料越全面，分析就能越精準。
- 日誌的生成渠道：
1）是網站的web伺服器所記錄的web訪問日誌；
2）是通過在頁面嵌入自定義的js程式碼來獲取使用者的所有訪問行為（比如滑鼠懸停的位置，點選的頁面元件等），然後通過ajax請求到後臺記錄日誌；這種方式所能採集的資訊最全面；
3）通過在頁面上埋點1畫素的圖片，將相關頁面訪問資訊請求到後臺記錄日誌；
- 日誌資料內容詳述：
在實際操作中，有以下幾個方面的資料可以被採集：
- 訪客的系統屬性特徵。比如所採用的作業系統、瀏覽器、域名和訪問速度等。
- 訪問特徵。包括停留時間、點選的URL等。
- 來源特徵。包括網路內容資訊型別、內容分類和來訪URL等。
- 產品特徵。包括所訪問的產品編號、產品類別、產品顏色、產品價格、產品利潤、產品數量和特價等級等。
以電商某東為例，其點選日誌格式如下：
| GET /log.gif?t=item.010001&m=UA-J2011-1&pin=-&uid=1679790178&sid=1679790178|12&v=je=1$sc=24-bit$sr=1600x900$ul=zh-cn$cs=GBK$dt=【雲南白藥套裝】雲南白藥 牙膏 180g×3 （留蘭香型）【行情 報價 價格 評測】-京東$hn=item.jd.com$fl=16.0 r0$os=win$br=chrome$bv=39.0.2171.95$wb=1437269412$xb=1449548587$yb=1456186252$zb=12$cb=4$usc=direct$ucp=-$umd=none$uct=-$ct=1456186505411$lt=0$tad=-$sku=1326523$cid1=1316$cid2=1384$cid3=1405$brand=20583$pinid=-&ref=&rm=1456186505411 HTTP/1.1 |
- 1.1.2 點選流資料模型
點選流概念
點選流這個概念更注重使用者瀏覽網站的整個流程，網站日誌中記錄的使用者點選就像是圖上的“點”，而點選流更像是將這些“點”串起來形成的“線”。也可以把“點”認為是網站的Page，而“線”則是訪問網站的Session。所以點選流資料是由網站日誌中整理得到的，它可以比網站日誌包含更多的資訊，從而使基於點選流資料統計得到的結果更加豐富和高效。
點選流模型生成
點選流資料在具體操作上是由散點狀的點選日誌資料梳理所得，從而，點選資料在資料建模時應該存在兩張模型表（Pageviews和visits）：
- a用於生成點選流的訪問日誌表
| 時間戳 |
IP地址 |
Cookie |
Session |
請求URL |
Referal |
| 2012-01-01 12:31:12 |
101.0.0.1 |
User01 |
S001 |
/a/... |
somesite.com |
| 2012-01-01 12:31:16 |
201.0.0.2 |
User02 |
S002 |
/a/... |
- |
| 2012-01-01 12:33:06 |
101.0.0.2 |
User03 |
S002 |
/b/... |
baidu.com |
| 2012-01-01 15:16:39 |
234.0.0.3 |
User01 |
S003 |
/c/... |
google.com |
| 2012-01-01 15:17:11 |
101.0.0.1 |
User01 |
S004 |
/d/... |
/c/... |
| 2012-01-01 15:19:23 |
101.0.0.1 |
User01 |
S004 |
/e/... |
/d/.... |
- b頁面點選流模型Pageviews表
| Session |
userid |
時間 |
訪問頁面URL |
停留時長 |
第幾步 |
| S001 |
User01 |
2012-01-01 12:31:12 |
/a/.... |
30 |
1 |
| S002 |
User02 |
2012-01-01 12:31:16 |
/a/.... |
10 |
1 |
| S002 |
User02 |
2012-01-01 12:33:06 |
/b/.... |
110 |
2 |
| S002 |
User02 |
2012-01-01 12:35:06 |
/e/.... |
30 |
3 |
- c點選流模型Visits表
| Session |
起始時間 |
結束時間 |
進入頁面 |
離開頁面 |
訪問頁面數 |
IP |
cookie |
referal |
| S001 |
2012-01-01 12:31:12 |
2012-01-01 12:31:12 |
/a/... |
/a/... |
1 |
101.0.0.1 |
User01 |
somesite.com |
| S002 |
2012-01-01 12:31:16 |
2012-01-01 12:35:06 |
/a/... |
/e/... |
3 |
201.0.0.2 |
User02 |
- |
| S003 |
2012-01-01 12:35:42 |
2012-01-01 12:35:42 |
/c/... |
/c/... |
1 |
234.0.0.3 |
User03 |
baidu.com |
| S003 |
2012-01-01 15:16:39 |
2012-01-01 15:19:23 |
/c/... |
/e/... |
3 |
101.0.0.1 |
User01 |
google.com |
| …… |
…… |
…… |
…… |
…… |
…… |
…… |
…… |
…… |
這就是點選流模型。當WEB日誌轉化成點選流資料的時候，很多網站分析度量的計算變得簡單了，這就是點選流的“魔力”所在。基於點選流資料我們可以統計出許多常見的網站分析度量
- 1.2網站流量資料分析的意義
網站流量統計分析，可以幫助網站管理員、運營人員、推廣人員等實時獲取網站流量資訊，並從流量來源、網站內容、網站訪客特性等多方面提供網站分析的資料依據。從而幫助提高網站流量，提升網站使用者體驗，讓訪客更多的沉澱下來變成會員或客戶，通過更少的投入獲取最大化的收入。
如下表：
| 網站的眼睛 |
網站的神經 |
網站的大腦 |
| 訪問者來自哪裡？ 訪問者在尋找什麼？ 哪些頁面最受歡迎？ 訪問者從哪裡進入？
|
網頁佈局合理嗎？ 網站導航清晰嗎？ 哪些功能存在問題 網站內容有效嗎 轉化路徑靠譜嗎？ |
如何分解目標？ 如何分配廣告預算？ 如何衡量產品表現？ 哪些產品需要優化？ 哪些指標需要關注？ |
點選流分析的意義可分為兩大方面：
1、技術上
可以合理修改網站結構及適度分配資源，構建後臺伺服器群組，比如
輔助改進網路的拓撲設計，提高效能
在有高度相關性的節點之間安排快速有效的訪問路徑
幫助企業更好地設計網站主頁和安排網頁內容
2、業務上
- 幫助企業改善市場營銷決策，如把廣告放在適當的Web頁面上。
- 優化頁面及業務流程設計，提高流量轉化率。
- 幫助企業更好地根據客戶的興趣來安排內容。
- 幫助企業對客戶群進行細分，針對不同客戶制定個性化的促銷策略等。
終極目標是：改善網站(電商、社交、電影、小說)的運營，獲取更高投資回報率（ROI）
- 1.3 如何進行網站流量分析
流量分析整體來說是一個內涵非常豐富的體系，其整體過程是一個金字塔結構：
- 1.3.1 流量分析模型舉例
通常有以下幾大類的分析需求：
1)網站流量質量分析
流量對於每個網站來說都是很重要，但流量並不是越多越好，應該更加看重流量的質量，換句話來說就是流量可以為我們帶來多少收入。
2)網站流量多維度細分
細分是指通過不同維度對指標進行分割，檢視同一個指標在不同維度下的表現，進而找出有問題的那部分指標，對這部分指標進行優化。
3)網站內容及導航分析
對於所有網站來說，頁面都可以被劃分為三個類別：
- 導航頁
- 功能頁
- 內容頁
首頁和列表頁都是典型的導航頁；
站內搜尋頁面、登錄檔單頁面和購物車頁面都是典型的功能頁，
而產品詳情頁、新聞和文章頁都是典型的內容頁。
比如從內容導航分析中，以下兩類行為就是網站運營者不希望看到的行為：
第一個問題：訪問者從導航頁進入，在還沒有看到內容頁面之前就從導航頁離開網站，需要分析導航頁造成訪問者中途離開的原因。
第二個問題：訪問者從導航頁進入內容頁後，又返回到導航頁，說明需要分析內容頁的最初設計，並考慮中內容頁提供交叉的資訊推薦
4)網站轉化及漏斗分析
所謂轉化，即網站業務流程中的一個封閉渠道，引導使用者按照流程最終實現業務目標（比如商品成交）；而漏斗模型則是指進入渠道的使用者在各環節遞進過程中逐漸流失的形象描述；
對於轉化渠道，主要進行兩部分的分析：
訪問者的流失和迷失
- 阻力和流失
造成流失的原因很多，如：
不恰當的商品或活動推薦
對支付環節中專業名詞的解釋、幫助資訊等內容不當
- 迷失
造成迷失的主要原因是轉化流量設計不合理，訪問者在特定階段得不到需要的資訊，並且不能根據現有的資訊作出決策
總之，網站流量分析是一門內容非常豐富的學科，本課程中主要關注網站分析過程中的技術運用，更多關於網站流量分析的業務知識可學習推薦資料。
- 1.3.2 流量分析常見指標
課程中涉及的分析指標主要位於以下幾大方面：
1)基礎分析（PV,IP,UV）
- 趨勢分析：根據選定的時段，提供網站流量資料，通過流量趨勢變化形態，為您分析網站訪客的訪問規律、網站發展狀況提供參考。
- 對比分析：根據選定的兩個對比時段，提供網站流量在時間上的縱向對比報表，幫您發現網站發展狀況、發展規律、流量變化率等。
- 當前線上：提供當前時刻站點上的訪客量，以及最近15分鐘流量、來源、受訪、訪客變化情況等，方便使用者及時瞭解當前網站流量狀況。
- 訪問明細：提供最近7日的訪客訪問記錄，可按每個PV或每次訪問行為（訪客的每次會話）顯示，並可按照來源、搜尋詞等條件進行篩選。 通過訪問明細，使用者可以詳細瞭解網站流量的累計過程，從而為使用者快速找出流量變動原因提供最原始、最準確的依據。
2)來源分析
- 來源分類：提供不同來源形式（直接輸入、搜尋引擎、其他外部連結、站內來源）、不同來源項引入流量的比例情況。通過精確的量化資料，幫助使用者分析什麼型別的來路產生的流量多、效果好，進而合理優化推廣方案。
- 搜尋引擎：提供各搜尋引擎以及搜尋引擎子產品引入流量的比例情況。從搜尋引擎引入流量的的角度，幫助使用者瞭解網站的SEO、SEM效果，從而為制定下一步SEO、SEM計劃提供依據。
- 搜尋詞：提供訪客通過搜尋引擎進入網站所使用的搜尋詞，以及各搜尋詞引入流量的特徵和分佈。幫助使用者瞭解各搜尋詞引入流量的質量，進而瞭解訪客的興趣關注點、網站與訪客興趣點的匹配度，為優化SEO方案及SEM提詞方案提供詳細依據。
- 最近7日的訪客搜尋記錄，可按每個PV或每次訪問行為（訪客的每次會話）顯示，並可按照訪客型別、地區等條件進行篩選。為您搜尋引擎優化提供最詳細的原始資料。
- 來路域名：提供具體來路域名引入流量的分佈情況，並可按“社會化媒體”、“搜尋引擎”、“郵箱”等網站型別對來源域名進行分類。 幫助使用者瞭解哪類推廣渠道產生的流量多、效果好，進而合理優化網站推廣方案。
- 來路頁面：提供具體來路頁面引入流量的分佈情況。 尤其對於通過流量置換、包廣告位等方式從其他網站引入流量的使用者，該功能可以方便、清晰地展現廣告引入的流量及效果，為優化推廣方案提供依據。
- 來源升降榜：提供開通統計後任意兩日的TOP10000搜尋詞、來路域名引入流量的對比情況，並按照變化的劇烈程度提供排行榜。 使用者可通過此功能快速找到哪些來路對網站流量的影響比較大，從而及時排查相應來路問題。
3)受訪分析
- 受訪域名：提供訪客對網站中各個域名的訪問情況。 一般情況下，網站不同域名提供的產品、內容各有差異，通過此功能使用者可以瞭解不同內容的受歡迎程度以及網站運營成效。
- 受訪頁面：提供訪客對網站中各個頁面的訪問情況。 站內入口頁面為訪客進入網站時瀏覽的第一個頁面，如果入口頁面的跳出率較高則需要關注並優化；站內出口頁面為訪客訪問網站的最後一個頁面，對於離開率較高的頁面需要關注並優化。
- 受訪升降榜：提供開通統計後任意兩日的TOP10000受訪頁面的瀏覽情況對比，並按照變化的劇烈程度提供排行榜。 可通過此功能驗證經過改版的頁面是否有流量提升或哪些頁面有巨大流量波動，從而及時排查相應問題。
- 熱點圖：記錄訪客在頁面上的滑鼠點選行為，通過顏色區分不同區域的點選熱度；支援將一組頁面設定為"關注範圍"，並可按來路細分點選熱度。 通過訪客在頁面上的點選量統計，可以瞭解頁面設計是否合理、廣告位的安排能否獲取更多佣金等。
- 使用者視點：提供受訪頁面對頁面上鍊接的其他站內頁面的輸出流量，並通過輸出流量的高低繪製熱度圖，與熱點圖不同的是，所有記錄都是實際打開了下一頁面產生了瀏覽次數（PV）的資料，而不僅僅是擁有滑鼠點選行為。
- 訪問軌跡：提供觀察焦點頁面的上下游頁面，瞭解訪客從哪些途徑進入頁面，又流向了哪裡。 通過上游頁面列表比較出不同流量引入渠道的效果；通過下游頁面列表瞭解使用者的瀏覽習慣，哪些頁面元素、內容更吸引訪客點選。
4)訪客分析
- 地區運營商：提供各地區訪客、各網路運營商訪客的訪問情況分佈。 地方網站、下載站等與地域性、網路鏈路等結合較為緊密的網站，可以參考此功能資料，合理優化推廣運營方案。
- 終端詳情：提供網站訪客所使用的瀏覽終端的配置情況。 參考此資料進行網頁設計、開發，可更好地提高網站相容性，以達到良好的使用者互動體驗。
- 新老訪客：當日訪客中，歷史上第一次訪問該網站的訪客記為當日新訪客；歷史上已經訪問過該網站的訪客記為老訪客。 新訪客與老訪客進入網站的途徑和瀏覽行為往往存在差異。該功能可以輔助分析不同訪客的行為習慣，針對不同訪客優化網站，例如為製作新手導航提供資料支援等。
- 忠誠度：從訪客一天內回訪網站的次數（日訪問頻度）與訪客上次訪問網站的時間兩個角度，分析訪客對網站的訪問粘性、忠誠度、吸引程度。 由於提升網站內容的更新頻率、增強使用者體驗與使用者價值可以有更高的忠誠度，因此該功能在網站內容更新及使用者體驗方面提供了重要參考。
- 活躍度：從訪客單次訪問瀏覽網站的時間與網頁數兩個角度，分析訪客在網站上的活躍程度。 由於提升網站內容的質量與數量可以獲得更高的活躍度，因此該功能是網站內容分析的關鍵指標之一。
5)轉化路徑分析
轉化定義
·訪客在您的網站完成了某項您期望的活動，記為一次轉化，如註冊或下載。
目標示例
·獲得使用者目標：線上註冊、建立賬號等。
·諮詢目標：諮詢、留言、電話等。
·互動目標：視訊播放、加入購物車、分享等。
·收入目標：線上訂單、付款等。
轉化資料的應用
·在報告的自定義指標中勾選轉化指標，實時掌握網站的推廣及運營情況。
·結合“全部來源”、“轉化路徑”、“頁面上下游”等報告分析訪問漏斗，提高轉化率。
·對“轉化目標”設定價值，預估轉化收益，衡量ROI。
路徑分析：根據設定的特定路線，監測某一流程的完成轉化情況，算出每步的轉換率和流失率資料，如註冊流程，購買流程等。
轉化型別：
- 頁面
- 事件
- 二、 整體技術流程及架構
- 2.1 資料處理流程
該專案是一個純粹的資料分析專案，其整體流程基本上就是依據資料的處理流程進行，依此有以下幾個大的步驟：
- a資料採集
首先，通過頁面嵌入JS程式碼的方式獲取使用者訪問行為，併發送到web服務的後臺記錄日誌
然後，將各伺服器上生成的點選流日誌通過實時或批量的方式匯聚到HDFS檔案系統中
當然，一個綜合分析系統，資料來源可能不僅包含點選流資料，還有資料庫中的業務資料（如使用者資訊、商品資訊、訂單資訊等）及對分析有益的外部資料。
- b資料預處理
通過mapreduce程式對採集到的點選流資料進行預處理，比如清洗，格式整理，濾除髒資料等
- c資料入庫
將預處理之後的資料匯入到HIVE倉庫中相應的庫和表中
- d資料分析
專案的核心內容，即根據需求開發ETL分析語句，得出各種統計結果
- e資料展現
將分析所得資料進行視覺化
- 2.2 專案結構
由於本專案是一個純粹資料分析專案，其整體結構亦跟分析流程匹配，並沒有特別複雜的結構，如下圖：
其中，需要強調的是：
系統的資料分析不是一次性的，而是按照一定的時間頻率反覆計算，因而整個處理鏈條中的各個環節需要按照一定的先後依賴關係緊密銜接，即涉及到大量任務單元的管理排程，所以，專案中需要新增一個任務排程模組
- 2.3 資料展現
資料展現的目的是將分析所得的資料進行視覺化，以便運營決策人員能更方便地獲取資料，更快更簡單地理解資料
- 三、模組開發——資料採集
- 3.1 需求
資料採集的需求廣義上來說分為兩大部分。
1）是在頁面採集使用者的訪問行為，具體開發工作：
- 開發頁面埋點js，採集使用者訪問行為
- 後臺接受頁面js請求記錄日誌
此部分工作也可以歸屬為“資料來源”，其開發工作通常由web開發團隊負責
2）是從web伺服器上匯聚日誌到HDFS，是資料分析系統的資料採集，此部分工作由資料分析平臺建設團隊負責，具體的技術實現有很多方式：
- Shell指令碼
優點：輕量級，開發簡單
缺點：對日誌採集過程中的容錯處理不便控制
- Java採集程式
優點：可對採集過程實現精細控制
缺點：開發工作量大
- Flume日誌採集框架
成熟的開源日誌採集系統，且本身就是hadoop生態體系中的一員，與hadoop體系中的各種框架元件具有天生的親和力，可擴充套件性強
- 3.2 技術選型
在點選流日誌分析這種場景中，對資料採集部分的可靠性、容錯能力要求通常不會非常嚴苛，因此使用通用的flume日誌採集框架完全可以滿足需求。
本專案即使用flume來實現日誌採集。
- 3.3 Flume日誌採集系統搭建
- a資料來源資訊
本專案分析的資料用nginx伺服器所生成的流量日誌，存放在各臺nginx伺服器上，如：
/var/log/httpd/access_log.2015-11-10-13-00.log
/var/log/httpd/access_log.2015-11-10-14-00.log
/var/log/httpd/access_log.2015-11-10-15-00.log
/var/log/httpd/access_log.2015-11-10-16-00.log
資料的具體內容在採集階段其實不用太關心。
| 58.215.204.118 - - [18/Sep/2013:06:51:35 +0000] "GET /wp-includes/js/jquery/jquery.js?ver=1.10.2 HTTP/1.1" 304 0 "http://blog.fens.me/nodejs-socketio-chat/" "Mozilla/5.0 (Windows NT 5.1; rv:23.0) Gecko/20100101 Firefox/23.0" |
欄位解析：
1、訪客ip地址： 58.215.204.118
2、訪客使用者資訊： - -
3、請求時間：[18/Sep/2013:06:51:35 +0000]
4、請求方式：GET
5、請求的url：/wp-includes/js/jquery/jquery.js?ver=1.10.2
6、請求所用協議：HTTP/1.1
7、響應碼：304
8、返回的資料流量：0
9、訪客的來源url：http://blog.fens.me/nodejs-socketio-chat/
10、訪客所用瀏覽器：Mozilla/5.0 (Windows NT 5.1; rv:23.0) Gecko/20100101 Firefox/23.0
基本規律為：
當前正在寫的檔案為access_log；
檔案體積達到64M，或時間間隔達到60分鐘，即滾動重新命名切換成歷史日誌檔案；
形如： access_log.2015-11-10-13-00.log
當然，每個公司的web伺服器日誌策略不同，可在web程式的log4j.properties中定義，如下：
| log4j.appender.logDailyFile = org.apache.log4j.DailyRollingFileAppender log4j.appender.logDailyFile.layout = org.apache.log4j.PatternLayout log4j.appender.logDailyFile.layout.ConversionPattern = [%-5p][%-22d{yyyy/MM/dd HH:mm:ssS}][%l]%n%m%n log4j.appender.logDailyFile.Threshold = DEBUG log4j.appender.logDailyFile.ImmediateFlush = TRUE log4j.appender.logDailyFile.Append = TRUE log4j.appender.logDailyFile.File = /var/logs/access_log log4j.appender.logDailyFile.DatePattern = '.'yyyy-MM-dd-HH-mm'.log' log4j.appender.logDailyFile.Encoding = UTF-8 |
- d Flume採集實現
Flume採集系統的搭建相對簡單：
- 在個web伺服器上部署agent節點，修改配置檔案
- 啟動agent節點，將採集到的資料匯聚到指定的HDFS目錄中
如下圖：
- 版本選擇：apache-flume-1.6.0
- 採集規則設計：
- 採集源：nginx伺服器日誌目錄
- 存放地：hdfs目錄/home/hadoop/weblogs/
- 採集規則配置詳情
| agent1.sources = source1 agent1.sinks = sink1 agent1.channels = channel1
# Describe/configure spooldir source1 #agent1.sources.source1.type = spooldir #agent1.sources.source1.spoolDir = /var/logs/nginx/ #agent1.sources.source1.fileHeader = false
# Describe/configure tail -F source1 #使用exec作為資料來源source元件 agent1.sources.source1.type = exec #使用tail -F命令實時收集新產生的日誌資料 agent1.sources.source1.command = tail -F /var/logs/nginx/access_log agent1.sources.source1.channels = channel1
#configure host for source #配置一個攔截器外掛 agent1.sources.source1.interceptors = i1 agent1.sources.source1.interceptors.i1.type = host #使用攔截器外掛獲取agent所在伺服器的主機名 agent1.sources.source1.interceptors.i1.hostHeader = hostname
#配置sink元件為hdfs agent1.sinks.sink1.type = hdfs #a1.sinks.k1.channel = c1 #agent1.sinks.sink1.hdfs.path=hdfs://hdp-node-01:9000/weblog/flume-collection/%y-%m-%d/%H%M%S #指定檔案sink到hdfs上的路徑 agent1.sinks.sink1.hdfs.path= hdfs://hdp-node-01:9000/weblog/flume-collection/%y-%m-%d/%H-%M_%hostname #指定檔名字首 agent1.sinks.sink1.hdfs.filePrefix = access_log agent1.sinks.sink1.hdfs.maxOpenFiles = 5000 #指定每批下沉資料的記錄條數 agent1.sinks.sink1.hdfs.batchSize= 100 agent1.sinks.sink1.hdfs.fileType = DataStream agent1.sinks.sink1.hdfs.writeFormat =Text #指定下沉檔案按1G大小滾動 agent1.sinks.sink1.hdfs.rollSize = 1024*1024*1024 #指定下沉檔案按1000000條數滾動 agent1.sinks.sink1.hdfs.rollCount = 1000000 #指定下沉檔案按30分鐘滾動 agent1.sinks.sink1.hdfs.rollInterval = 30 #agent1.sinks.sink1.hdfs.round = true #agent1.sinks.sink1.hdfs.roundValue = 10 #agent1.sinks.sink1.hdfs.roundUnit = minute agent1.sinks.sink1.hdfs.useLocalTimeStamp = true
# Use a channel which buffers events in memory #使用memory型別channel agent1.channels.channel1.type = memory agent1.channels.channel1.keep-alive = 120 agent1.channels.channel1.capacity = 500000 agent1.channels.channel1.transactionCapacity = 600
# Bind the source and sink to the channel agent1.sources.source1.channels = channel1 agent1.sinks.sink1.channel = channel1 |
啟動採集
在部署了flume的nginx伺服器上，啟動flume的agent，命令如下：
bin/flume-ng agent --conf ./conf -f ./conf/weblog.properties.2 -n agent
注意：啟動命令中的 -n 引數要給配置檔案中配置的agent名稱
- 四、模組開發——資料預處理
- 4.1 主要目的：
過濾“不合規”資料
格式轉換和規整
根據後續的統計需求，過濾分離出各種不同主題的基礎資料
- 4.2 實現方式：
開發一個mr程式WeblogPreProcess(簡略)
| public class WeblogPreProcess { static class WeblogPreProcessMapper extends Mapper<LongWritable, Text, Text, NullWritable> { Text k = new Text(); NullWritable v = NullWritable.get(); @Override protected void map(LongWritable key, Text value, Context context) throws IOException, InterruptedException { String line = value.toString(); WebLogBean webLogBean = WebLogParser.parser(line); // WebLogBean productWebLog = WebLogParser.parser2(line); // WebLogBean bbsWebLog = WebLogParser.parser3(line); // WebLogBean cuxiaoBean = WebLogParser.parser4(line); if (!webLogBean.isValid()) return; k.set(webLogBean.toString()); context.write(k, v); // k.set(productWebLog); // context.write(k, v); } } public static void main(String[] args) throws Exception {
Configuration conf = new Configuration(); Job job = Job.getInstance(conf); job.setJarByClass(WeblogPreProcess.class); job.setMapperClass(WeblogPreProcessMapper.class); job.setOutputKeyClass(Text.class); job.setOutputValueClass(NullWritable.class); FileInputFormat.setInputPaths(job, new Path(args[0])); FileOutputFormat.setOutputPath(job, new Path(args[1])); job.waitForCompletion(true);
} }
|
- 執行mr對資料進行預處理
| hadoop jar weblog.jar cn.itcast.bigdata.hive.mr.WeblogPreProcess /weblog/input /weblog/preout |
- 4.3 點選流模型資料梳理
由於大量的指標統計從點選流模型中更容易得出，所以在預處理階段，可以使用mr程式來生成點選流模型的資料
- 4.3.1 點選流模型pageviews表
Pageviews表模型資料生成
| 程式碼見工程
hadoop jar weblogpreprocess.jar \ cn.itcast.bigdata.hive.mr.ClickStreamThree \ /user/hive/warehouse/dw_click.db/test_ods_weblog_origin/datestr=2013-09-20/ /test-click/pageviews/ |
表結構：
(表定義及資料匯入見6.2節)
- 4.3.2 點選流模型visit資訊表
注：“一次訪問”=“N次連續請求”
直接從原始資料中用hql語法得出每個人的“次”訪問資訊比較困難，可先用mapreduce程式分析原始資料得出“次”資訊資料，然後再用hql進行更多維度統計
用MR程式從pageviews資料中，梳理出每一次visit的起止時間、頁面資訊
| 程式碼見工程 hadoop jar weblogpreprocess.jar cn.itcast.bigdata.hive.mr.ClickStreamVisit /weblog/sessionout /weblog/visitout |
然後，在hive倉庫中建點選流visit模型表
| drop table if exist click_stream_visit; create table click_stream_visit( session string, remote_addr string, inTime string, outTime string, inPage string, outPage string, referal string, pageVisits int) partitioned by (datestr string); < |