當前位置:首頁 » 編程語言 » hive漏斗分析sql
擴展閱讀
webinf下怎麼引入js 2023-08-31 21:54:13
堡壘機怎麼打開web 2023-08-31 21:54:11

hive漏斗分析sql

發布時間: 2022-12-30 23:33:08

㈠ Hive sql語句執行順序

Hive 中 sql 語句的執行順序如下:

from .. where .. join .. on .. select .. group by .. select .. having .. distinct .. order by .. limit .. union/union all

下面我們通過一個 sql 語句分析下:

上面這條 sql 語句是可以成功執行的,我們看下它在 MR 中的執行順序:

Map 階段

Rece 階段

上面這個執行順序到底對不對呢,我們可以通過 explain 執行計劃來看下,內容過多,我們分階段來看。

我們看到 Stage-5 是根,也就是最先執行 Stage-5,Stage-2 依賴 Stage-5,Stage-0 依賴 Stage-2。

圖中標 ① 處是表掃描操作,注意先掃描的 b 表,也就是 left join 後面的表,然後進行過濾操作(圖中標 ② 處),我們 sql 語句中是對 a 表進行的過濾,但是 Hive 也會自動對 b 表進行相同的過濾操作,這樣可以減少關聯的數據量。

先掃描 a 表(圖中標 ① 處);接下來進行過濾操作 idno > �'(圖中標 ② 處);然後進行 left join,關聯的 key 是 idno(圖中標 ③ 處);執行完關聯操作之後會進行輸出操作,輸出的是三個欄位,包括 select 的兩個欄位加 group by 的一個欄位(圖中標 ④ 處);然後進行 group by 操作,分組方式是 hash(圖中標 ⑤ 處);然後進行排序操作,按照 idno 進行正向排序(圖中標 ⑥ 處)。

首先進行 group by 操作,注意此時的分組方式是 mergepartial 合並分組(圖中標 ① 處);然後進行 select 操作,此時輸出的欄位只有兩個了,輸出的行數是 30304 行(圖中標 ② 處);接下來執行 having 的過濾操作,過濾出 count_user>1 的欄位,輸出的行數是 10101 行(圖中標 ③ 處);然後進行 limit 限制輸出的行數(圖中標 ④ 處);圖中標 ⑤ 處表示是否對文件壓縮,false 不壓縮。

限制最終輸出的行數為 10 行。

通過上面對 SQL 執行計劃的分析,總結以下幾點:

㈡ Hive簡易教程 - 數據分析

Hive是一個HDFS上的sql執行引擎,它將sql語句轉化為Hadoop上的map-rece任務來執行。由於是寫sql,所以使用Hive進行數據分析的好處是沒有什麼額外的學習成本,但是它是批量式處理的,可能會比較慢。本文將通過幾個案例來簡單介紹如何使用Hive。

** 隨機生成一批訂單數據(order_id, price, tag, order_date) **

** 存儲數據到Hive **

** 統計出近一周每天成功支付的訂單總數,gmv,客單價 **

** 統計出近一周每天成功支付 及支付失敗 各自的訂單總數,gmv,客單價 **

count函數和if條件組合,而不是兩個sql join

** 挑選出近一周gmv>1000並且訂單量>2單的賣家ID及其訂單 **

  在使用group by之後只能select出group key以及相關的統計數字,但也可以以集合的形式select出任何其他的非group key,比如按賣家ID聚合之後又想查看在這個賣家下單的買家ID:sellect collect_set(buyer_id) from t group by seller_id。

  與collect_set類似,元素可重復

  explode函數可以把一個array類型的數據扁平化。比如,現在每行是一個seller_id集合,使用explode可以扁平化為每行一個seller_id。但explode不可以直接與group by一起使用,比如我想按某些條件篩選一些賣家然後在查看該店鋪的買家的情況:select explode(b.buyer_ids) from (select collect_set(buyer_id) as buyer_ids from t group by seller_id) b;

  當前時間

  將系統時間戳轉化為人可讀的數據格式 如:select from_unixtime(unix_timestamp(), 'yyyy-MM-dd');

  求幾天前的日期

  nvl函數用於處理null值,當一個欄位是null時,這個欄位和其它欄位進行算術運算時的結果依然為null。這時可以使用這個函數為值可能為null的欄位賦予一個默認值,即v2.

  判斷字元串'xxx'是否出現在str1中,如果str1是null或者不存在xxx返回值都是0

  返回數組a1的大小

  合並兩個查詢結果,但結果的列數需要一致!!!

㈢ 【數據分析】Excel數據分析全流程

作為數據分析師, 清晰了解數據分析的步驟是非常重要的,有助於清楚把控整個數據分析的流程。

作為想要學習數據分析的人員,了解整個數據分析的流程, 這樣在面對一個數據分析問題的時候,知道如何去開展。

那麼數據分析流程包含哪些環節呢?

我將一次完整的數據分析流程主要分為六個環節,包括明確 分析目的、數據獲取、數據處理、數據分析、數據可視化、總結與建議

做任何事情都有其對應的目的,數據分析也是如此。每一次分析前,都必須要先明確做這次分析的目的是什麼,只有先明確了目的,後面的分析才能圍繞其展開, 常見的數據分析目標包括以下三種類型:

指標波動型 : 主要是針對某個指標下降了,上漲或者異常所做的分析, 比如DAU(日活躍用戶數)降低了, 留存率降低了, 電商平台的訂單數量減少了, 收入降低了,質量指標如卡頓率上漲的,分析的主要目的是挖掘指標波動的原因, 及時發現業務的問題。

評估決策型 :主要是針對某個活動上線, 某個功能上線, 某個策略上線的效果評估以及下一步迭代方向的建議,這些建議是指導產品經理或者其他業務方決策的依據。

專題探索型 : 主要是針對業務發起的一些專題的分析, 比如增長類的專題分析, 怎麼提高用戶新增,活躍,留存,付費, 比如體驗類的專題分析, 如何提高用戶查找表情的效率, 比如方向性的探索, 微信引入視頻號的功能的用戶需求分析以及潛在機會分析。

明確了數據分析目的之後, 第二步就是根據我們的分析目的,提取相對應的數據,通常這一個環節是利用 hive sql 從數據倉庫中提取數據。

提取的數據通常要注意提取的維度和對應的指標個數,以電商app 的付費流失嚴重分析案例,我們需要提取的維度和指標可以根據具體的業務流程來(如圖):

首先從維度上,我們需要確定好,比如時間維度我們提取的時間跨度是多長,比如今天的數據和昨天的對比,那就是取2天的數據,如果是這周和上周那就是十四天的數據。

設備維度的值是否需要提取ios和安卓的用戶進行不同的平台的對比,分析付費流失嚴重是否主要發生在某個平台。

年齡、性別、地域維度,就是提取用戶這些維度的信息, 主要是為了在哪一個年齡層, 哪一個性別,哪一個地域流失最嚴重。

新老用戶的維度, 主要是從新舊維度上分析流失嚴重是否是集中在新用戶還是老用戶(如圖所示)

確定好了維度以後, 接下來就是指標信息, 維度+ 指標才是一個完整的數據

因為需要分析每一個環節的流失情況,所以需要提取下單的每一個環節對應的指標的人數和次數。
基於這些人數和次數,我們可以計算每一個環節之間的轉化率。

活躍瀏覽比 = 瀏覽的人數/活躍的人數

瀏覽添加比 = 添加的人數/瀏覽的人數

添加下單比 = 點擊下單人數/添加購物車人數

成功下單率 = 成功下單的人數/點擊下單的人數

當我們知道我們應該從哪裡獲取數據, 以及獲取哪些指標數據後,為了保證我們提取的數據的質量,我們通常要對數據進行處理。

常見的數據處理有異常值處理,空值處理。舉個例子, 比如我們在提取用戶的年齡數據之前,我們需要去除掉年齡中的空的數據以及異常的數據, 異常的數據指得是比如年齡超過120歲這種。

數據處理好了之後,就可以開始分析,根據我們的分析目標,我們要選擇合適的分析方法和分析思路去做拆解和挖掘。

常見的分析方法包括:漏斗分析, 相關性分析, 5w2h 分析, aha 時刻分析, 麥肯錫邏輯樹分析法,用戶畫像分析,RFM用戶分群,對比分析等方法,這些方法詳細的介紹會在第三章展開, 在這里不做贅述

針對我們的訂單流失的問題,典型的分析思路和方法是利用漏斗分析和用戶畫像分析。

漏斗分析主要是可以挖掘付費流失嚴重的主要流失環節是在哪裡。我們發現付費流失嚴重主要是因為用戶活躍到瀏覽商品的轉化率從50%跌倒30%, 減少了20%,那就可以把問題定位到為什麼用戶瀏覽變少的問題上。

用戶畫像分析,可以幫助我們分析流失嚴重的用戶是什麼特徵,比如什麼樣的年齡, 性別, 地域等, 那就可以知道這種流失是集中在哪一個年齡群體,哪一個地域群體以及其他的行為特徵。

通過數據分析得出結論後,還需要用圖表展示出來,俗話說得好,「文不如表,表不如圖",用圖表可以更清晰展現你的結論,通常的可視化我們可以利用excel 自帶的可視化的功能, 也可以通過python或者R腳本進行可視化。

常見的圖表有: 柱形圖,折線圖,餅圖,條形圖,面積圖, 散點圖,組合圖,箱線圖

當我們利用圖表把我們的數據分析結論展示出來以後,最後就是數據分析的總結的部分,主要分成我們得出了什麼具體的結論以及給業務具體的建議,告訴他們改進的方向。

這就是一次完整的數據分析的流程,從分析目的到提取數據,到分析數據給出結論的完整的過程。

㈣ hive什麼進行sql處理

是指在(getdate()-7)的那天注冊並登錄的用戶數sumUser和在getdate()里有登錄的用戶數userNum(getdate()-7注冊並登陸的),這兩個數的比例?

select cast(case when sumUser=0 then 0 else userNum/sumUser*100 end as varchar(2))+'%' as 留存率 from
(select
count(nowlogin.openid) as userNum,
count(newlogin.openid)as sumUser
from
(select aa.openid,aa.ftime from t_login_all as aa right join t_login_new as bb on aa.openid=bb.openid and bb.ftime=getdate()-7) as nowlogin,
(select openid from t_login_new where ftime=getdate()-7) as newlogin
where nowlogin.ftime=getdate() and nowlogin.openid=newlogin.openid
) as a

㈤ 大數據開發工程師Hive(Hive Sql的執行順序)

Hive中SQL的執行順序:

(1) from :對from左邊的表和右邊的表計算笛卡爾積,產生虛表VT1;

(2) on : 對虛表VT1進行on過濾,只有那些符合 的行才會被記錄在虛表VT2中;

(3) join :如果指定了outer join(比如left join、 right join),那麼保留表中未匹配的行就會作為外部行添加到虛擬表VT2中,產生虛擬表VT3;

(4) where :對虛擬表VT3進行where條件過濾。只有符合 的記錄才會被插入到虛擬表VT4中;

(5) group by :根據group by子句中的列,對VT4中的記錄進行分組操作,產生VT5;

(6) having : 對虛擬表VT5應用having過濾,只有符合 的記錄才會被 插入到虛擬表VT6中;

(7) select :執行select操作,選擇指定的列,插入到虛擬表VT7中;

(8) distinct :對VT7中的記錄進行去重。產生虛擬表VT8;

(9) order :將虛擬表VT8中的記錄按照 進行排序操作,產生虛擬表VT9;

(10) limit :取出指定行的記錄,產生虛擬表VT10, 並將結果返回;

partition by 通常會用於和開窗及分析函數一起使用,partition by是在select執行完 的結果集上進行的;


(每日1小題,進步1點點)

㈥ 數據分析課程筆記 - 19 - HiveSQL 常用優化技巧

大家好呀,這節課學習 HiveSQL 的常用優化技巧。由於 Hive 主要用來處理非常大的數據,運行過程由於通常要經過 MapRece 的過程,因此不像 MySQL 一樣很快出結果。而使用不同方法寫出來的 HiveSQL 語句執行效率也是不一樣的,因此為了減少等待的時間,提高伺服器的運行效率,我們需要在 HiveSQL 的語句上進行一些優化。

本節課的主要內容

引言
1、技巧一:列裁剪和分區裁剪
(1)列裁剪
(2)分區裁剪
2、技巧二:排序技巧——sort by代替order by
3、技巧三:去重技巧——用group by來替換distinct
4、技巧四:聚合技巧——grouping sets、cube、rollup
(1)grouping sets
(2)cube
(3)rollup
5、技巧五:換個思路解題
6、技巧六:union all時可以開啟並發執行
7、技巧七:表連接優化
8、技巧八:遵循嚴格模式

Hive 作為大數據領域常用的數據倉庫組件,在平時設計和查詢時要特別注意效率。影響Hive效率的幾乎從不是數據量過大,而是數據傾斜、數據冗餘、job 或 I/O 過多、MapRece 分配不合理等等。對 Hive 的調優既包含對HiveSQL 語句本身的優化,也包含 Hive 配置項和 MR 方面的調整。

列裁剪就是在查詢時只讀取需要的列。當列很多或者數據量很大時,如果select 所有的列或者不指定分區,導致的全表掃描和全分區掃描效率都很低。Hive中與列裁剪優化相關的配置項是 hive.optimize.cp ,默認是 true 。

分區裁剪就是在查詢時只讀需要的分區。Hive中與分區裁剪優化相關的則是 hive.optimize.pruner ,默認是 true 。

HiveSQL中的 order by 與其他 SQL 語言中的功能一樣,就是將結果按某個欄位全局排序,這會導致所有map端數據都進入一個 rece 中,在數據量大時可能會長時間計算不完。

如果使用 sort by ,那麼就會視情況啟動多個 recer 進行排序,並且保證每個 recer 內局部有序。為了控制 map 端數據分配到 rece 的 key,往往還要配合 distribute by 一同使用。如果不加 distribute by 的話,map 端數據就會隨機分配給 recer。

這里需要解釋一下, distribute by 和 sort by 結合使用是如何相較於 order by 提升運行效率的。

假如我們要對一張很大的用戶信息表按照年齡進行分組,優化前的寫法是直接 order by age 。使用 distribute by 和 sort by 結合進行優化的時候, sort by 後面還是 age 這個排序欄位, distribute by 後面選擇一個沒有重復值的均勻欄位,比如 user_id 。

這樣做的原因是,通常用戶的年齡分布是不均勻的,比如20歲以下和50歲以上的人非常少,中間幾個年齡段的人又非常多,在 Map 階段就會造成有些任務很大,有些任務很小。那通過 distribute by 一個均勻欄位,就可以讓系統均勻地進行「分桶」,對每個桶進行排序,最後再組合,這樣就能從整體上提升 MapRece 的效率。

取出 user_trade 表中全部支付用戶:

原有寫法的執行時長:

優化寫法的執行時長:

考慮對之前的案例進行優化:

注意: 在極大的數據量(且很多重復值)時,可以先 group by 去重,再 count() 計數,效率高於直接 count(distinct **) 。

如果我們想知道用戶的性別分布、城市分布、等級分布,你會怎麼寫?

通常寫法:

缺點 :要分別寫三次SQL,需要執行三次,重復工作,且費時。

那該怎麼優化呢?

注意 :這個聚合結果相當於縱向地堆在一起了(Union all),分類欄位用不同列來進行區分,也就是每一行數據都包含 4 列,前三列是分類欄位,最後一列是聚合計算的結果。

GROUPING SETS() :在 group by 查詢中,根據不同的維度組合進行聚合,等價於將不同維度的 group by 結果集進行 union all。聚合規則在括弧中進行指定。

如果我們想知道用戶的性別分布以及每個性別的城市分布,你會怎麼寫?

那該怎麼優化呢?

注意: 第二列為NULL的,就是性別的用戶分布,其餘有城市的均為每個性別的城市分布。

cube:根據 group by 維度的所有組合進行聚合

注意 :跑完數據後,整理很關鍵!!!

rollup:以最左側的維度為主,進行層級聚合,是cube的子集。

如果我想同時計算出,每個月的支付金額,以及每年的總支付金額,該怎麼辦?

那應該如何優化呢?

條條大路通羅馬,寫SQL亦是如此,能達到同樣效果的SQL有很多種,要學會思路轉換,靈活應用。

來看一個我們之前做過的案例:

有沒有別的寫法呢?

Hive 中互相沒有依賴關系的 job 間是可以並行執行的,最典型的就是
多個子查詢union all。在集群資源相對充足的情況下,可以開啟並
行執行。參數設置: set hive.exec.parallel=true;

時間對比:

所謂嚴格模式,就是強制不允許用戶執行3種有風險的 HiveSQL 語句,一旦執行會直接報錯。

要開啟嚴格模式,需要將參數 hive.mapred.mode 設為 strict 。

好啦,這節課的內容就是這些。以上優化技巧需要大家在平時的練習和使用中有意識地去注意自己的語句,不斷改進,就能掌握最優的寫法。

㈦ 如何查看hive的sql解析過程

hivesql sql — 獲取指定hive表或指定文件中所有hive表的DDL,如果有按天的分區則默認執行最近7天的分區DDL。同時,table支持符合sql語法的正則表達式,如果有多個表匹配,則提示用戶選擇(使用file則自動關閉該交互功能)。

㈧ Hive Sql優化集(on where過濾)

分析:這三個sql區別就在於log表和a表的過濾條件是在where字句上還是on字句上。
sql1的結果:
a表和log表的所有數據做連接,只是在a表的dt!=񟭑-09-17'記錄上a表上所有欄位都為空
sql2的結果:
a表和log表的所有數據先做連接,然後過濾出兩個表只在񟭑-09-17'分區上的數據
sql3的結果:
a表和log表分別查詢出񟭑-09-17'分區上數據,兩個小數據集做關聯,結果和sql2的相同

sql3的執行效率最高,推薦使用;sql2的效率較低,因為需要全表關聯;sql1有bug,不建議直接在on中使用過濾條件
但是注意不要將where過濾條件放到on中,除非你很了解SQL執行後的結果;另外不要將on連接條件放到where中,hive並不會像mysq那樣做連接優化,這樣會導致不可控的情況

㈨ Hive SQL執行計劃深度解析

Hive SQL執行計劃深度解析 - An342647823的專欄 - 博客頻道 - CSDN.NET
http://blog.csdn.net/an342647823/article/details/36385479

美團網技術陳純大作,值得擁有。

Hive是基於Hadoop的一個數據倉庫系統,在各大公司都有廣泛的應用。美團數據倉庫也是基於Hive搭建,每天執行近萬次的Hive ETL計算流程,負責每天數百GB的數據存儲和分析。Hive的穩定性和性能對我們的數據分析非常關鍵。

在幾次升級Hive的過程中,我們遇到了一些大大小小的問題。通過向社區的咨詢和自己的努力,在解決這些問題的同時我們對Hive將SQL編譯為MapRece的過程有了比較深入的理解。對這一過程的理解不僅幫助我們解決了一些Hive的bug,也有利於我們優化Hive SQL,提升我們對Hive的掌控力,同時有能力去定製一些需要的功能。

㈩ hive sql 優化的常用手段有哪些

1、join連接時的優化:當三個或多個以上的表進行join操作時,如果每個on使用相同的欄位連接時只會產生一個maprece。
2、join連接時的優化:當多個表進行查詢時,從左到右表的大小順序應該是從小到大。原因:hive在對每行記錄操作時會把其他表先緩存起來,直到掃描最後的表進行計算
3、在where字句中增加分區過濾器。
4、當可以使用left semi join 語法時不要使用inner join,前者效率更高。原因:對於左表中指定的一條記錄,一旦在右表中找到立即停止掃描。