Spark-Alchemy中HyperLogLog如何使用

本篇文章給大家分享的是有關(guān)Spark-Alchemy中HyperLogLog如何使用，小編覺得挺實(shí)用的，因此分享給大家學(xué)習(xí)，希望大家閱讀完這篇文章后可以有所收獲，話不多說，跟著小編一起來看看吧。

Reaggregation的挑戰(zhàn)

Reaggregation的成立存在先決條件， 預(yù)先計(jì)算的維度可以再次進(jìn)行聚合， 在字典釋義中聚合表示可聚合性，通過進(jìn)一步擴(kuò)展該語義來解釋reaggregation - 具有可以再次進(jìn)行聚合的聚合， 求和，最大值，最小值都是可以reaggregation的， 但是distinct count是不支持reaggregation的，主要因?yàn)榇嬖诙斡?jì)數(shù)的問題， 統(tǒng)計(jì)每個(gè)網(wǎng)站的訪問人數(shù)的總和并不等于訪問網(wǎng)站的總?cè)藬?shù)，這是由于單個(gè)訪問者可以訪問多個(gè)網(wǎng)站。

這種不可重新聚合的特性使得計(jì)算distinct count的系統(tǒng)必須訪問最細(xì)粒度的數(shù)據(jù)，因此每個(gè)查詢需要訪問每一行數(shù)據(jù)去統(tǒng)計(jì)distinct count。

在大數(shù)據(jù)領(lǐng)域， distinct counts存在另外一個(gè)問題，在計(jì)算過程需要的內(nèi)存大小是更需要統(tǒng)計(jì)不同結(jié)果集的大小成正比的，為了避免上述問題，近年來一些大數(shù)據(jù)平臺如Apache Spark 以及面向分析的數(shù)據(jù)庫如Amazon RedShift引入基數(shù)估計(jì)的算法，該算法使用HyperLogLog（HLL）去估計(jì)distinct counts， 在spark 中如果要使用基數(shù)估計(jì)算法，只要使用approx_count_distinct(x [, rsd])代替COUNT(DISTINCT x)就可以運(yùn)行， 其中可選參數(shù)rsd代表可以容忍的誤差， 在databricks的測試報(bào)告， HLL的聚合性能可以達(dá)到精確計(jì)算distinct count性能的2-8倍，誤差率保持在1%以上，用戶可以追求更高精度，但是HLL算法的運(yùn)行時(shí)間可能要比精確計(jì)算distinct count時(shí)間更長。

2-8倍性能的提升的代價(jià)是誤差率始終保持在1%以上， 這在某些場景下是不可接受的， 此外在預(yù)先聚合能帶來1000倍的性能提升面前， 2-8倍性能顯得微不足道， 對此我們能做些什么？下面首先介紹下HLL算法。

HyperLogLog算法

HLL算法在Spark 處理流程可以分為以下幾個(gè)部分

• Map階段

• 初始化HLL sketch數(shù)據(jù)結(jié)構(gòu)

• 為每個(gè)HLL sketch加入輸入

• 發(fā)送HLL sketch

• Reduce

• 合并所有的HLL sketches到聚合的sketch

• Finalize

  HLL sketch是支持reaggreation， reduce階段合并產(chǎn)生的依舊是HLL sketch，用戶可以序列化該結(jié)果，并將該結(jié)果持久化存儲，作為預(yù)先聚合的一部分，為后續(xù)計(jì)算distinct count提供輸入，這樣就可以帶來1000倍的提升。

• 從聚合的sketch中計(jì)算出distinct count的估計(jì)值

這種方法還能另外一種好處，通過該方法用戶可以將誤差率控制1%以內(nèi)，由于預(yù)先聚合可以帶來1000倍的提升，我們可以花費(fèi)更長的時(shí)間來計(jì)算HLL以便達(dá)到更小的誤差率，在預(yù)先聚合階段，花費(fèi)2-5倍的計(jì)算預(yù)先聚合時(shí)間是可以接受的， 對大多數(shù)用戶而言，性能提升的同時(shí)基本沒有任何其他方面的犧牲。

Spark-Alchemy介紹：HLL 功能

由于Spark社區(qū)不支持HLL功能，Swoop將這部分功能作為spark-alchemy庫的一部分進(jìn)行開源，用戶可以參照HLL文檔提供的樣例， 相比BigQuery的HLL支持，Spark alchemy提供了更加豐富的功能。

下圖顯示spark alchemy HLL是如何處理聚合的初始化（hll_init_agg）, 重新聚合(hll_merg) 以及最后結(jié)果的展示(hll_cardinality)

如果用戶擔(dān)心HLL sketches的存儲開銷， 通過以下規(guī)則可以進(jìn)行簡單的估算：精度提高2倍， HLL sketches的存儲開銷將會提升4倍， 在大部分應(yīng)用程序中，記錄數(shù)目的減少帶來的存儲開銷的減少遠(yuǎn)遠(yuǎn)超過HLL sketch增加的開銷

HyperLogLog互操作性

Distinct count精確計(jì)算以及估算模式的相互切換以及將HLL sketches保存為列式數(shù)據(jù)可以避免用戶在查詢的時(shí)候遍歷所有記錄數(shù)據(jù)， 但是系統(tǒng)在準(zhǔn)備HLL數(shù)據(jù)的時(shí)候還是需要訪問所有的記錄數(shù)據(jù)。此外對于HLLsketches的序列化業(yè)界也沒有統(tǒng)一的標(biāo)準(zhǔn)，所以HLL的數(shù)據(jù)在不同的系統(tǒng)中不能夠共享， 這種互操作性的不便利性增加交互分析系統(tǒng)的分析成本以及復(fù)雜度。
交互式分析系統(tǒng)要求快速的響應(yīng)時(shí)間，但是這個(gè)要求不是大數(shù)據(jù)系統(tǒng)核心的設(shè)計(jì)目標(biāo)，這就是為什么現(xiàn)在交互式分析還運(yùn)行在在關(guān)系型或者NoSQL數(shù)據(jù)庫上的原因，沒有HLL sketches的互操作性便利，用戶可能在交互式查詢還是使用原有的方式。
為了解決這個(gè)問題， spark alchemey在開發(fā)HLL相關(guān)功能時(shí)，提供了一種存儲格式以及原生支持Postgres兼容的數(shù)據(jù)庫， 這樣對于要求快速響應(yīng)時(shí)間的系統(tǒng)而言， spark就可以作為數(shù)據(jù)預(yù)處理統(tǒng)一平臺， 這種架構(gòu)的好處如下

• 99%以上的數(shù)據(jù)通過spark進(jìn)行管理，沒有副本

• 99%以上處理發(fā)生在spark支持，包括預(yù)先聚合

• 交互式查詢性能更高以及需要的資源更少

以上就是Spark-Alchemy中HyperLogLog如何使用，小編相信有部分知識點(diǎn)可能是我們?nèi)粘９ぷ鲿姷交蛴玫降?。希望你能通過這篇文章學(xué)到更多知識。更多詳情敬請關(guān)注億速云行業(yè)資訊頻道。