久久久久亚洲精品男人的天堂,精品无码人妻一区二区免费蜜桃,久久久久久久99精品免费观看

2.2 技術(shù)問題
我們對問題進(jìn)行了一個(gè)簡單的分析，問題的核心還是前面提到的——被計(jì)算的數(shù)據(jù)規(guī)模。

我們目前是300億——600億的IO規(guī)模，標(biāo)簽數(shù)量2000+，由于標(biāo)簽下面還可能會(huì)有枚舉值，所以最終會(huì)有大概300萬左右的tag 。對全部數(shù)據(jù)進(jìn)行一個(gè)掃表操作就要花非常多的時(shí)間。
另一個(gè)核心問題是，我們之前的業(yè)務(wù)場景過于復(fù)雜，為了配合業(yè)務(wù)場景在選擇技術(shù)方案是做了很多的讓步——更多的考慮滿足業(yè)務(wù)需求而非性能。所以早期在計(jì)算邏輯層面沒有處理的特別好，整個(gè)計(jì)算效率是比較低的。
但是這一類需求在我們的業(yè)務(wù)當(dāng)中卻展現(xiàn)的尤為強(qiáng)烈，我們非常迫切的想解決性能和功能的問題。所以在調(diào)研了非常多類似業(yè)務(wù)的方案后，我們提出了一種高性能標(biāo)簽索引的解決思路，并且考慮開發(fā)一套專用的系統(tǒng)來實(shí)現(xiàn)和解決類似的問題。
2.3 技術(shù)思路

（1）解決IO規(guī)模問題
原先的方法無論是基于MapReduce還是其他類似的邏輯，核心的問題在于我們要對全局?jǐn)?shù)據(jù)進(jìn)行遍歷掃。因?yàn)槲覀兪且?uid 為 key 的一個(gè)正向的數(shù)據(jù)結(jié)構(gòu)，對標(biāo)簽進(jìn)行掃必須要掃全量。
這里我們的解決辦法是做倒排索引，以標(biāo)簽為 key 把 uid 作為value 。這樣構(gòu)建一個(gè)反向索引之后，原來我們是全表掃，現(xiàn)在變成只處理關(guān)注的標(biāo)簽，這樣整體的IO規(guī)模會(huì)瞬間下降好幾個(gè)數(shù)量級。
其次我們要做一個(gè)計(jì)算加速的優(yōu)化，這里面主要是邏輯的變化。把原來圈選的邏輯變成交并集的處理。
在細(xì)節(jié)上需要做考慮兩個(gè)問題：
一個(gè)是把原來標(biāo)簽的枚舉變成二值化的 tag 。
比如：標(biāo)簽球類運(yùn)動(dòng)，它的每一個(gè)枚舉值，就需要拆解為具體的 tag，如籃球、足球等 ?；谶@個(gè)轉(zhuǎn)化，可以把條件圈選變成交集、并集計(jì)算的組合。例如，選擇喜歡籃球運(yùn)動(dòng)、不喜歡足球運(yùn)動(dòng)，就可以變成 tag-籃球 1，tag-足球 0 的交集。
另一個(gè)是我們有超過300萬個(gè) tag，在對 tag 做倒排索引時(shí)存儲(chǔ)空間會(huì)成為一個(gè)非常大的問題，所以需要進(jìn)一步降低存儲(chǔ)，提升計(jì)算效率。
我們選擇采用 Bitmap 來優(yōu)化標(biāo)簽索引，用一個(gè) bit 來標(biāo)記一個(gè) value，將用戶作為整個(gè) Bitmap 里的一個(gè)位，這樣可以實(shí)現(xiàn)在存儲(chǔ)上的空間節(jié)省。同時(shí)由于位運(yùn)算在交并集上天然的優(yōu)勢，在計(jì)算上也能帶來性能提升。
（2）加速計(jì)算過程
在解決計(jì)算規(guī)模問題時(shí)，核心的邏輯是用并行計(jì)算來加速過程。由于數(shù)據(jù)的 tag 是 key 構(gòu)建的，尤其一些基礎(chǔ)的標(biāo)簽的數(shù)據(jù)覆蓋率非常高，有些可以達(dá)到90%以上，整個(gè) Bitmap 會(huì)非常長。
這個(gè)情況下，對于一個(gè)百億級的 uid 范圍，bitmap 的 size 將會(huì)非常大，這些 bitmap 會(huì)成為計(jì)算平響，需要進(jìn)一步對 bitmap 進(jìn)行縱向的分桶，以加速計(jì)算，減少長尾 ?？紤] tag 數(shù)乘以分桶的情況，這是一個(gè)數(shù)量可觀的分布式并行的儲(chǔ)存與計(jì)算過程，對于分布式系統(tǒng)有著很高的要求，也是一種典型的 MPP 場景。
比較巧的是，在和 Doris 同學(xué)的交流過程當(dāng)中，我們得知 Doris 正在做相似的工作。Doris 的 MPP 架構(gòu)和正在進(jìn)行的 Bitmap 集成，剛好是我們業(yè)務(wù)需要的能力。可以說是不謀而合。
我們也調(diào)研了其他開源解決方案比如說 Kylin 和 Druid，Kylin 在這個(gè)場景下有一定的局限性，它需要預(yù)計(jì)算，這就帶來了維度和空間的爆炸，并且不能滿足我們對細(xì)粒度數(shù)據(jù)的需求。Druid 在這方面可以滿足我們的需求，但是在一些特定使用場景下我們是依賴Doris 的，所以我們最終選擇了 Doris 。