本篇文章給大家分享的是有關(guān)Spark-Alchemy中HyperLogLog如何使用，小編覺(jué)得挺實(shí)用的，因此分享給大家學(xué)習(xí)，希望大家閱讀完這篇文章后可以有所收獲，話不多說(shuō)，跟著小編一起來(lái)看看吧。
成都網(wǎng)站設(shè)計(jì)、成都做網(wǎng)站的開(kāi)發(fā)，更需要了解用戶，從用戶角度來(lái)建設(shè)網(wǎng)站，獲得較好的用戶體驗(yàn)。創(chuàng)新互聯(lián)建站多年互聯(lián)網(wǎng)經(jīng)驗(yàn)，見(jiàn)的多，溝通容易、能幫助客戶提出的運(yùn)營(yíng)建議。作為成都一家網(wǎng)絡(luò)公司，打造的就是網(wǎng)站建設(shè)產(chǎn)品直銷的概念。選擇創(chuàng)新互聯(lián)建站，不只是建站，我們把建站作為產(chǎn)品，不斷的更新、完善，讓每位來(lái)訪用戶感受到浩方產(chǎn)品的價(jià)值服務(wù)。
Reaggregation的成立存在先決條件， 預(yù)先計(jì)算的維度可以再次進(jìn)行聚合， 在字典釋義中聚合表示可聚合性，通過(guò)進(jìn)一步擴(kuò)展該語(yǔ)義來(lái)解釋reaggregation - 具有可以再次進(jìn)行聚合的聚合， 求和，最大值，最小值都是可以reaggregation的， 但是distinct count是不支持reaggregation的，主要因?yàn)榇嬖诙斡?jì)數(shù)的問(wèn)題， 統(tǒng)計(jì)每個(gè)網(wǎng)站的訪問(wèn)人數(shù)的總和并不等于訪問(wèn)網(wǎng)站的總?cè)藬?shù)，這是由于單個(gè)訪問(wèn)者可以訪問(wèn)多個(gè)網(wǎng)站。
這種不可重新聚合的特性使得計(jì)算distinct count的系統(tǒng)必須訪問(wèn)最細(xì)粒度的數(shù)據(jù)，因此每個(gè)查詢需要訪問(wèn)每一行數(shù)據(jù)去統(tǒng)計(jì)distinct count。
在大數(shù)據(jù)領(lǐng)域， distinct counts存在另外一個(gè)問(wèn)題，在計(jì)算過(guò)程需要的內(nèi)存大小是更需要統(tǒng)計(jì)不同結(jié)果集的大小成正比的，為了避免上述問(wèn)題，近年來(lái)一些大數(shù)據(jù)平臺(tái)如Apache Spark 以及面向分析的數(shù)據(jù)庫(kù)如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的測(cè)試報(bào)告， HLL的聚合性能可以達(dá)到精確計(jì)算distinct count性能的2-8倍，誤差率保持在1%以上，用戶可以追求更高精度，但是HLL算法的運(yùn)行時(shí)間可能要比精確計(jì)算distinct count時(shí)間更長(zhǎng)。
2-8倍性能的提升的代價(jià)是誤差率始終保持在1%以上， 這在某些場(chǎng)景下是不可接受的， 此外在預(yù)先聚合能帶來(lái)1000倍的性能提升面前， 2-8倍性能顯得微不足道， 對(duì)此我們能做些什么？下面首先介紹下HLL算法。
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é)果持久化存儲(chǔ)，作為預(yù)先聚合的一部分，為后續(xù)計(jì)算distinct count提供輸入，這樣就可以帶來(lái)1000倍的提升。
從聚合的sketch中計(jì)算出distinct count的估計(jì)值
這種方法還能另外一種好處，通過(guò)該方法用戶可以將誤差率控制1%以內(nèi)，由于預(yù)先聚合可以帶來(lái)1000倍的提升，我們可以花費(fèi)更長(zhǎng)的時(shí)間來(lái)計(jì)算HLL以便達(dá)到更小的誤差率，在預(yù)先聚合階段，花費(fèi)2-5倍的計(jì)算預(yù)先聚合時(shí)間是可以接受的， 對(duì)大多數(shù)用戶而言，性能提升的同時(shí)基本沒(méi)有任何其他方面的犧牲。
由于Spark社區(qū)不支持HLL功能，Swoop將這部分功能作為spark-alchemy庫(kù)的一部分進(jìn)行開(kāi)源，用戶可以參照HLL文檔提供的樣例， 相比BigQuery的HLL支持，Spark alchemy提供了更加豐富的功能。
下圖顯示spark alchemy HLL是如何處理聚合的初始化（hll_init_agg）, 重新聚合(hll_merg) 以及最后結(jié)果的展示(hll_cardinality)
如果用戶擔(dān)心HLL sketches的存儲(chǔ)開(kāi)銷， 通過(guò)以下規(guī)則可以進(jìn)行簡(jiǎn)單的估算：精度提高2倍， HLL sketches的存儲(chǔ)開(kāi)銷將會(huì)提升4倍， 在大部分應(yīng)用程序中，記錄數(shù)目的減少帶來(lái)的存儲(chǔ)開(kāi)銷的減少遠(yuǎn)遠(yuǎn)超過(guò)HLL sketch增加的開(kāi)銷
HyperLogLog互操作性
Distinct count精確計(jì)算以及估算模式的相互切換以及將HLL sketches保存為列式數(shù)據(jù)可以避免用戶在查詢的時(shí)候遍歷所有記錄數(shù)據(jù)， 但是系統(tǒng)在準(zhǔn)備HLL數(shù)據(jù)的時(shí)候還是需要訪問(wèn)所有的記錄數(shù)據(jù)。此外對(duì)于HLLsketches的序列化業(yè)界也沒(méi)有統(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ù)庫(kù)上的原因，沒(méi)有HLL sketches的互操作性便利，用戶可能在交互式查詢還是使用原有的方式。
為了解決這個(gè)問(wèn)題， spark alchemey在開(kāi)發(fā)HLL相關(guān)功能時(shí)，提供了一種存儲(chǔ)格式以及原生支持Postgres兼容的數(shù)據(jù)庫(kù)， 這樣對(duì)于要求快速響應(yīng)時(shí)間的系統(tǒng)而言， spark就可以作為數(shù)據(jù)預(yù)處理統(tǒng)一平臺(tái)， 這種架構(gòu)的好處如下
99%以上的數(shù)據(jù)通過(guò)spark進(jìn)行管理，沒(méi)有副本
99%以上處理發(fā)生在spark支持，包括預(yù)先聚合
交互式查詢性能更高以及需要的資源更少
以上就是Spark-Alchemy中HyperLogLog如何使用，小編相信有部分知識(shí)點(diǎn)可能是我們?nèi)粘９ぷ鲿?huì)見(jiàn)到或用到的。希望你能通過(guò)這篇文章學(xué)到更多知識(shí)。更多詳情敬請(qǐng)關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道。
重慶分公司
重慶分公司
