使用者訪問session分析的基礎資料結構及大資料的基本架構
使用者訪問session分析模組
使用者訪問session介紹：
- 使用者在電商網站上，通常會有很多的點選行為：
- 首先通常都是進入首頁；
- 然後可能點選首頁上的一些商品；
- 點選首頁上的一些品類；
- 隨時在搜尋框裡面搜尋關鍵詞；
- 將一些商品加入購物車；
- 對購物車中的多個商品下訂單；
- 最後對訂單中的多個商品進行支付。
- 使用者的每一次操作，其實可以理解為一個action，比如點選、搜尋、下單、支付
- 使用者session，指的就是，從使用者第一次進入首頁，session就開始了。然後在一定時間範圍內，直到最後操作完（可能做了幾十次、甚至上百次操作）。離開網站，關閉瀏覽器，或者長時間沒有做操作；那麼session就結束了。
- 以上使用者在網站內的訪問過程，就稱之為一次session。簡單理解，session就是某一天某一個時間段內，某個使用者對網站從開啟/進入，到做了大量操作，到最後關閉瀏覽器。的過程。就叫做session。
- session實際上就是一個電商網站中最基本的資料和大資料。那麼大資料，面向customer端，消費者，使用者端的分析。
模組的目標：對使用者訪問session進行分析
- 可以根據使用者指定的某些條件，篩選出指定的一些使用者（有特定年齡、職業、城市）；
- 對這些使用者在指定日期範圍內發起的session，進行聚合統計，比如，統計出訪問時長在0~3s的session佔總session數量的比例；
- 按時間比例，比如一天有24個小時，其中12:00~13:00的session數量佔當天總session數量的50%，當天總session數量是10000個，那麼當天總共要抽取1000個session，ok，12:00~13:00的使用者，就得抽取1000*50%=500。而且這500個需要隨機抽取。
- 獲取點選量、下單量和支付量都排名10的商品種類
- 獲取top10的商品種類的點選數量排名前10的session
- 開發完畢了以上功能之後，需要進行大量、複雜、高階、全套的效能調優
- 十億級資料量的troubleshooting（故障解決）的經驗總結
- 資料傾斜的完美解決方案
- 使用mock（模擬）的資料，對模組進行除錯、執行和演示效果
將session做成表，表的資料結構介紹
表名：user_visit_action（Hive表）
date：日期，代表這個使用者點選行為是在哪一天發生的
user_id：代表這個點選行為是哪一個使用者執行的
session_id ：唯一標識了某個使用者的一個訪問session
page_id ：點選了某些商品/品類，也可能是搜尋了某個關鍵詞，然後進入了某個頁面，頁面的id
action_time ：這個點選行為發生的時間點
search_keyword ：如果使用者執行的是一個搜尋行為，比如說在網站/app中，搜尋了某個關鍵詞，然後會跳轉到商品列表頁面；搜尋的關鍵詞
click_category_id ：可能是在網站首頁，點選了某個品類（美食、電子裝置、電腦）
click_product_id ：可能是在網站首頁，或者是在商品列表頁，點選了某個商品（比如呷哺呷哺火鍋XX路店3人套餐、iphone 6s）
order_category_ids ：代表了可能將某些商品加入了購物車，然後一次性對購物車中的商品下了一個訂單，這就代表了某次下單的行為中，有哪些
商品品類，可能有6個商品，但是就對應了2個品類，比如有3根火腿腸（食品品類），3個電池（日用品品類）
order_product_ids ：某次下單，具體對哪些商品下的訂單
pay_category_ids ：代表的是，對某個訂單，或者某幾個訂單，進行了一次支付的行為，對應了哪些品類
pay_product_ids：代表的，支付行為下，對應的哪些具體的商品
user_visit_action表，其實就是比如說網站，或者是app，每天的點選流的資料。可以理解為，使用者對網站/app每點選一下，就會代表在這個表裡面的一條資料。
這個表，其實進行了某些改造和簡化，真實的電商企業中，使用的基礎資料表的結構，絕對是至少是這個表的10倍複雜度以上。
表名：user_info（Hive表）
user_id：其實就是每一個使用者的唯一標識，通常是自增長的Long型別，BigInt型別
username：是每個使用者的登入名
name：每個使用者自己的暱稱、或者是真實姓名
age：使用者的年齡
professional：使用者的職業
city：使用者所在的城市
user_info表，實際上，就是一張最普通的使用者基礎資訊表；這張表裡面，其實就是放置了網站/app所有的註冊使用者的資訊。那麼我們這裡也是對使用者資訊表，進行了一定程度的簡化。比如略去了手機號等這種資料。因為我們這個專案裡不需要使用到某些資料。那麼我們就保留一些最重要的資料，即可。
表名：task（MySQL表）
task_id：表的主鍵
task_name：任務名稱
create_time：建立時間
start_time：開始執行的時間
finish_time：結束執行的時間
task_type：任務型別，就是說，在一套大資料平臺中，肯定會有各種不同型別的統計分析任務，比如說使用者訪問session分析任務，頁面單跳轉化率統計任務；所以這個欄位就標識了每個任務的型別
task_status：任務狀態，任務對應的就是一次Spark作業的執行，這裡就標識了，Spark作業是新建，還沒執行，還是正在執行，還是已經執行完畢
task_param：最最重要，用來使用JSON的格式，來封裝使用者提交的任務對應的特殊的篩選引數
task表，其實是用來儲存平臺的使用者，通過J2EE系統，提交的基於特定篩選引數的分析任務的資訊，就會通過J2EE系統儲存到task表中來。之所以使用MySQL表，是因為J2EE系統是要實現快速的實時插入和查詢的。
大資料平臺架構
- 終端使用者/平臺的使用者可以通過J2EE平臺，提交一個建立任務的請求，進入任務建立頁面，填寫任務引數，提交各種不同型別的統計分析任務；然後可以查詢自己提交的任務列表， 任務執行結束後，點選對應的連結，檢視結果資料的展示圖表和報表。
- J2EE平臺會將使用者提交的任務資訊插入到MySQL中的task表中去。MySQL資料庫裡包含了各種業務需要使用的表
- J2EE平臺在將任務資訊儲存到MySQL表中後，就會用Runtime、Process等API去執行一個封裝了spark-submit命令的linux shell指令碼。（提交之後就會設定task的開始時間，如果監控到spark作業結束，那麼就會設定task的結束時間，同時會維護任務狀態）
- 封裝了spark-submit命令的shell將執行Spark作業的jar包提交到Spark Standalone叢集上去執行；YARN叢集上去執行（Spark作業）
- Spark作業在執行時的第一件事情，就是從MySQL的task表中，讀取本任務需要使用的一些篩選引數，比如年齡範圍。。。
- 在spark作業執行過程中，或者執行完之後，會將統計分析的結果資料，插入到MySQL中，對應的表裡面去。以供J2EE平臺在後面展示這些資料。
- J2EE平臺從MySQL業務表中讀取結果資料，封裝為對應的JSON資料格式，並返回前端頁面，展示（一種是表格；另外一張是圖表，比如說柱狀圖、餅狀圖、折線圖等。。。）