91超碰碰碰碰久久久久久综合_超碰av人澡人澡人澡人澡人掠_国产黄大片在线观看画质优化_txt小说免费全本

溫馨提示×

溫馨提示×

您好,登錄后才能下訂單哦!

密碼登錄×
登錄注冊×
其他方式登錄
點擊 登錄注冊 即表示同意《億速云用戶服務條款》

HyperLogLog函數在Spark中的如何應用

發布時間:2021-12-06 14:03:40 來源:億速云 閱讀:170 作者:小新 欄目:大數據

這篇文章給大家分享的是有關HyperLogLog函數在Spark中的如何應用的內容。小編覺得挺實用的,因此分享給大家做個參考,一起跟隨小編過來看看吧。


再聚合(Reaggregation)的挑戰

預聚合是數據分析領域的一個強大的技術手段,前提就是所要計算的指標是可重聚合的。聚合操作,顧名思義,是滿足結合律的,所以很容易引入再聚合操作,因為聚合操作可以再被進一步聚合。Counts 可以在通過 SUM 再聚合,最小值可以通過 MIN 再聚合,最大值也可以通過 MAX 再聚合。而 distinct counts 是特例,無法做再聚合,例如,不同網站訪問者的 distinct count 的總和并不等于所有網站訪問者的 distinct count 值,原因很簡單,同一個用戶可能訪問了不同的網站,直接求和就存在了重復統計的問題。
Distinct count 的不可再聚合的特性造成了很大的影響,計算 distinct count 必須要訪問到最細粒度的數據,更進一步來說,就是計算 distinct count 的查詢必須讀取每一行數據。

HyperLogLog函數在Spark中的如何應用  
當這個問題遇上大數據,就會產生新的挑戰:   計算過程所需的內存和 distinct count 的結果數量是成正比的。   近年來,諸如 Apache Spark 的大數據系統以及諸如 Amazon Redshift 的分析型數據庫都引入了 distinct count 的近似計算功能——基數估計(cardinality estimation),利用 HyperLogLog(HLL)概率數據結構來實現。   在 Spark 中使用近似計算,只需要將 COUNT(DISTINCT x) 替換為 approx_count_distinct(x [, rsd]),其中額外的參數 rsd 表示最大允許的偏差率,默認值為 5%。   Databricks 給出的 HLL 性能分析表明,只要最大偏差率大于等于 1%,Spark 的 distinct count 近似計算的運行速度比精確計算高2~8倍。   不過,如果我們需要更小的偏差率,近似計算可能會比精確計算耗時更長。  
  2~8倍的性能提升是相當可觀的,不過它犧牲的精確性,大于等于 1% 的最大偏差率在某些場合可能是無法被接受的。   另外,2~8倍的性能提升在預聚合所帶來的上千倍的性能提升面前也是微不足道的,那我們能做什么?  

 
 

HyperLogLog 算法回顧

答案其實就在 HyperLogLog 算法本身,Spark 通過 partition 分片執行 MapReduce 實現 HLL 算法的偽代碼如下所示:  
  • Map (每個 partition)

    • 初始化 HLL 數據結構,稱作 HLL sketch

    • 將每個輸入添加到 sketch 中

    • 發送 sketch

  • Reduce

    • 聚合所有 sketch 到一個 aggregate sketch 中

  • Finalize

    • 計算 aggregate sketch 中的 distinct count 近似值

值得注意的是,HLL sketch 是可再聚合的:   在 reduce 過程合并之后的結果就是一個 HLL sketch。   如果我們可以將 sketch 序列化成數據,那么我們就可以在預聚合階段將其持久化,在后續計算 distinct count 近似值時,就能獲得上千倍的性能提升!  
  另外這個算法還能帶來另一個同樣重要的好處:   我們不再限于性能問題向估算精度妥協(大于等于1%的估算偏差)。   由于預聚合能夠帶來上千倍的性能提升,我們可以創建估算偏差非常低的 HLL sketch,因為在上千倍的查詢性能提升面前,我們完全能夠接受預聚合階段2~5倍的計算耗時。   這在大數據業務中基本相當于是免費的午餐:   帶來巨大性能提升的同時,又不會對大部分業務端的用戶造成負面影響。  


 

Spark-Alchemy 簡介:HLL Native 函數

由于 Spark 沒有提供相應功能,Swoop開源了高性能的 HLL native 函數工具包,作為 spark-alchemy項目的一部分,具體使用示例可以參考 HLL docs。   提供了大數據領域最為齊全的 HyperLogLog 處理工具,超過了 BigQuery 的 HLL 支持。  
  下圖所示為 spark-alchemy 處理 initial aggregation (通過    hll_init_agg   ), reaggregation (通過    hll_merge   ) 和 presentation (通過    hll_cardinality   )。  
HyperLogLog函數在Spark中的如何應用  
如果你想了解 HLL sketch 的內存使用量,可以遵循這樣一個準則,HLL cardinality estimation 精度每提升2倍, HLL sketch 所需內存提升4倍。   大部分場景下,數據行數的較少所帶來的收益遠超過 HLL sketch 帶來的額外存儲。  
 

HyperLogLog 互通性

通過近似計算 distinct count 代替精確計算,并且將 HLL sketch 保存成列式數據,最終的查詢階段可以不再需要處理每一行最細粒度的數據,但是仍舊有一個隱性的需求,那就是使用 HLL 數據的系統需要訪問所有最細粒度的數據,這是因為目前還沒有工業標準來序列化 HLL 數據結構。大部分實現,例如 BigQuery,使用了不透明的二進制數據,也沒有相關文檔說明,這使得跨系統互通變得困難。這個互通性的問題極大增加了交互式分析系統的成本和復雜度。  
  交互式分析系統的一個關鍵要求是快速的查詢響應。而這并不是很多諸如 Spark 和 BigQuery 的大數據系統的設計核心,所以很多場景下,交互式分析查詢通過關系型或者 NoSQL 數據庫來實現。如果 HLL sketch 不能實現數據層面的互通性,那我們又將回到原點。  
  為了解決這個問題,在 spark-alchemy 項目里,使用了公開的 存儲標準,內置支持 Postgres 兼容的數據庫,以及 JavaScript。這樣使得 Spark 能夠成為全局的數據預處理平臺,能夠滿足快速查詢響應的需求,例如 portal 和 dashboard 的場景。這樣的架構可以帶來巨大的受益:  
  • 99+%的數據僅通過 Spark 進行管理,沒有重復

  • 在預聚合階段,99+%的數據通過 Spark 處理

  • 交互式查詢響應時間大幅縮短,處理的數據量也大幅較少

感謝各位的閱讀!關于“HyperLogLog函數在Spark中的如何應用”這篇文章就分享到這里了,希望以上內容可以對大家有一定的幫助,讓大家可以學到更多知識,如果覺得文章不錯,可以把它分享出去讓更多的人看到吧!

向AI問一下細節

免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。

AI

民乐县| 宜州市| 丹江口市| 时尚| 苍山县| 靖边县| 张家口市| 巴南区| 东丰县| 正定县| 宁晋县| 昌图县| 安阳市| 连平县| 峨眉山市| 拉孜县| 桐梓县| 湘潭市| 益阳市| 永福县| 普宁市| 讷河市| 道真| 岳池县| 万安县| 永定县| 满城县| 潞城市| 左贡县| 襄城县| 梁河县| 枝江市| 霸州市| 漳州市| 瓮安县| 海口市| 葵青区| 万安县| 项城市| 建水县| 油尖旺区|