1 用戶行為數倉業務總結
1.1 數倉分幾層？每層做什么的？
1）ODS層（原始數據層）
存儲原始數據，直接加載原始日志、數據，數據保持原貌不做處理。
2）DWD層（明細層）
對ODS層數據進行清洗（去除空值、臟數據，超過極限范圍的數據）
3）DWS層（服務數據層）
以DWD層為基礎，進行輕度匯總。比如：用戶當日、設備當日、商品當日。
4）ADS層（數據應用層）
1.2 Tez引擎優點？
Tez可以將多個有依賴的作業轉換為一個作業，這樣只需寫一次HDFS，且中間節點較少，從而大大提升作業的計算性能。
1.3 在項目中是否自定義過UDF、UDTF函數，以及用他們處理了什么問題？
自定義過。
用UDF函數解析公共字段；用UDTF函數解析事件字段。
1.4 如何分析用戶活躍？
在啟動日志中統計不同設備id 出現次數。
1.5 如何分析用戶新增？
用活躍用戶表 left join 用戶新增表，用戶新增表中mid為空的即為用戶新增。
1.6 如何分析用戶1天留存？
留存用戶=前一天新增 join 今天活躍
用戶留存率=留存用戶/前一天新增
1.7 如何分析沉默用戶？
按照設備id對日活表分組，登錄次數為1，且是在一周前登錄。
1.8 如何分析本周回流用戶？
本周活躍left join本周新增 left join上周活躍，且本周新增id和上周活躍id都為null
1.9 如何分析流失用戶？
按照設備id對日活表分組，且七天內沒有登錄過。
1.10 如何分析最近連續3周活躍用戶數？
按照設備id對周活進行分組，統計次數等於3次。
1.11 如何分析最近七天內連續三天活躍用戶數？
1）查詢出最近7天的活躍用戶，並對用戶活躍日期進行排名
2）計算用戶活躍日期及排名之間的差值
3）對同用戶及差值分組，統計差值個數
4）將差值相同個數大於等於3的數據取出，然后去重，即為連續3天及以上活躍的用戶
1.12 整個文檔中涉及的所有層級及表
2 Hive總結
2.1 Hive的架構
2.2 Hive和數據庫比較
Hive 和數據庫除了擁有類似的查詢語言，再無類似之處。
1）數據存儲位置
Hive 存儲在 HDFS 。數據庫將數據保存在塊設備或者本地文件系統中。
2）數據更新
Hive中不建議對數據的改寫。而數據庫中的數據通常是需要經常進行修改的，
3）執行延遲
Hive 執行延遲較高。數據庫的執行延遲較低。當然，這個是有條件的，即數據規模較小，當數據規模大到超過數據庫的處理能力的時候，Hive的並行計算顯然能體現出優勢。
4）數據規模
Hive支持很大規模的數據計算；數據庫可以支持的數據規模較小。
2.3 內部表和外部表
1）管理表：當我們刪除一個管理表時，Hive也會刪除這個表中數據。管理表不適合和其他工具共享數據。
2）外部表：刪除該表並不會刪除掉原始數據，刪除的是表的元數據
2.4 4個By區別
1）Sort By：分區內有序；
2）Order By：全局排序，只有一個Reducer；
3）Distrbute By：類似MR中Partition，進行分區，結合sort by使用。
4） Cluster By：當Distribute by和Sorts by字段相同時，可以使用Cluster by方式。Cluster by除了具有Distribute by的功能外還兼具Sort by的功能。但是排序只能是升序排序，不能指定排序規則為ASC或者DESC。
2..5 窗口函數
1）窗口函數：
（1） OVER()：指定分析函數工作的數據窗口大小，這個數據窗口大小可能會隨着行的變而變化。常用partition by 分區order by排序。
（2）CURRENT ROW：當前行
（3）n PRECEDING：往前n行數據
（4） n FOLLOWING：往后n行數據
（5）UNBOUNDED：起點，UNBOUNDED PRECEDING 表示從前面的起點， UNBOUNDED FOLLOWING表示到后面的終點
（6） LAG(col,n)：往前第n行數據
（7）LEAD(col,n)：往后第n行數據
（8） NTILE(n)：把有序分區中的行分發到指定數據的組中，各個組有編號，編號從1開始，對於每一行，NTILE返回此行所屬的組的編號。注意：n必須為int類型。
2）排序函數：
（1）RANK() 排序相同時會重復，總數不會變
（2）DENSE_RANK() 排序相同時會重復，總數會減少
（3）ROW_NUMBER() 會根據順序計算
2.6 在項目中是否自定義過UDF、UDTF函數，以及用他們處理了什么問題？
1）自定義過。
2）用UDF函數解析公共字段；用UDTF函數解析事件字段。
3）自定義UDF步驟：定義一個類繼承UDF，重寫evaluate方法
4）自定義UDTF步驟：定義一個類繼承GenericUDTF，重寫初始化方法、關閉方法和process方法。
2.7 Hive優化
- 1）MapJoin
如果不指定MapJoin或者不符合MapJoin的條件，那么Hive解析器會將Join操作轉換成Common Join，即：在Reduce階段完成join。容易發生數據傾斜。可以用MapJoin把小表全部加載到內存在map端進行join，避免reducer處理。
- 2）行列過濾
列處理：在SELECT中，只拿需要的列，如果有，盡量使用分區過濾，少用SELECT *。
行處理：在分區剪裁中，當使用外關聯時，如果將副表的過濾條件寫在Where后面，那么就會先全表關聯，之后再過濾。
- 3）采用分桶技術
- 4）采用分區技術
- 5）合理設置Map數
（1）通常情況下，作業會通過input的目錄產生一個或者多個map任務。
主要的決定因素有：input的文件總個數，input的文件大小，集群設置的文件塊大小。
（2）是不是map數越多越好？
答案是否定的。如果一個任務有很多小文件（遠遠小於塊大小128m），則每個小文件也會被當做一個塊，用一個map任務來完成，而一個map任務啟動和初始化的時間遠遠大於邏輯處理的時間，就會造成很大的資源浪費。而且，同時可執行的map數是受限的。
（3）是不是保證每個map處理接近128m的文件塊，就高枕無憂了？
答案也是不一定。比如有一個127m的文件，正常會用一個map去完成，但這個文件只有一個或者兩個小字段，卻有幾千萬的記錄，如果map處理的邏輯比較復雜，用一個map任務去做，肯定也比較耗時。
針對上面的問題2和3，我們需要采取兩種方式來解決：即減少map數和增加map數；
- 6）小文件進行合並
在Map執行前合並小文件，減少Map數：CombineHiveInputFormat具有對小文件進行合並的功能（系統默認的格式）。HiveInputFormat沒有對小文件合並功能。
- 7）合理設置Reduce數
Reduce個數並不是越多越好
（1）過多的啟動和初始化Reduce也會消耗時間和資源；
（2）另外，有多少個Reduce，就會有多少個輸出文件，如果生成了很多個小文件，那么如果這些小文件作為下一個任務的輸入，則也會出現小文件過多的問題；
在設置Reduce個數的時候也需要考慮這兩個原則：處理大數據量利用合適的Reduce數；使單個Reduce任務處理數據量大小要合適；
- 8）常用參數
// 輸出合並小文件
SET hive.merge.mapfiles = true; -- 默認true，在map-only任務結束時合並小文件
SET hive.merge.mapredfiles = true; -- 默認false，在map-reduce任務結束時合並小文件
SET hive.merge.size.per.task = 268435456; -- 默認256M
SET hive.merge.smallfiles.avgsize = 16777216; -- 當輸出文件的平均大小小於該值時，啟動一個獨立的map-reduce任務進行文件merge