分享嘉賓：Jason Xu@阿里巴巴

• 流量分析與業(yè)務(wù)背景：什么是流量分析，以及我們的業(yè)務(wù)背景
  

• "大數(shù)據(jù)"帶來(lái)的難題：當(dāng)你的數(shù)據(jù)量是守恒的時(shí)候，需要怎么處理你的數(shù)據(jù)
  

• 技術(shù)選型與產(chǎn)品考慮：在以上背景下，我們?cè)诩夹g(shù)選擇和產(chǎn)品考慮時(shí)，都做了哪些考慮，以及為什么最終選擇ClickHouse，并給大家介紹一些技術(shù)解決方案

1. 流量分析

首先，流量分析到底是什么？?從最基本的角度來(lái)說(shuō)流量分析就是底層的數(shù)據(jù)模型加上指標(biāo)體系。

底層數(shù)據(jù)模型：

底層數(shù)據(jù)模型是把不同的用戶(hù)行為數(shù)據(jù)，先放到一個(gè)最基本的叫做“事件”的數(shù)據(jù)模型中，這是一個(gè)單事件的數(shù)據(jù)模型。與此單個(gè)事件數(shù)據(jù)模型的上一層，形成一個(gè)路徑的實(shí)現(xiàn)模型，可以把一些數(shù)據(jù)，比如一些流量數(shù)據(jù)或者一些業(yè)務(wù)內(nèi)部數(shù)據(jù)同交易數(shù)據(jù)做關(guān)聯(lián)。在此基礎(chǔ)上，可以做規(guī)定的分析，后續(xù)也可以做更多的不同分析。既可以從企業(yè)整體來(lái)看，也可以從單個(gè)業(yè)務(wù)著手，例如：淘寶有很多個(gè)行業(yè)，可以從行業(yè)視角來(lái)分析數(shù)據(jù)；淘寶有許多新用戶(hù)和老用戶(hù)，可以從用戶(hù)角度來(lái)分析數(shù)據(jù)。所以，一旦有了這個(gè)底層數(shù)據(jù)后， 我們用很多不同的方法來(lái)分析這些數(shù)據(jù)，每一種分析方法產(chǎn)出的指標(biāo)其實(shí)是一樣的。

指標(biāo)體系：

我們通常用以下四種指標(biāo)來(lái)分析數(shù)據(jù)：

• 流量規(guī)模是多少，有多少UV，PV。

• 參與度，比如說(shuō)停留時(shí)長(zhǎng)，瀏覽深度。以目前火爆的直播為例，我們要看下直播的參與度，例如：在一次直播中，交互多少次，點(diǎn)擊多少次等一系列操作。

• 轉(zhuǎn)化，行業(yè)對(duì)轉(zhuǎn)化的理解就是讓用戶(hù)做你想讓他做的事情，比如說(shuō)轉(zhuǎn)發(fā)、收藏、購(gòu)買(mǎi)。此外，還有一些其他類(lèi)型的轉(zhuǎn)化：對(duì)于視頻產(chǎn)品， 轉(zhuǎn)化就是電視劇的完播率；對(duì)與社交產(chǎn)品，轉(zhuǎn)化是用戶(hù)注冊(cè)或者分享頁(yè)面；以及根據(jù)業(yè)務(wù)場(chǎng)景定義的轉(zhuǎn)化。

• 粘性，就是你花了多長(zhǎng)時(shí)間把用戶(hù)拉過(guò)來(lái)，讓用戶(hù)完成一件事情，并且了解用戶(hù)對(duì)此具體業(yè)務(wù)有沒(méi)有粘性。

由于業(yè)務(wù)的復(fù)雜度，我們會(huì)理解這些不同的數(shù)據(jù)，并且按照不同的維度來(lái)做切分和匯總。在大數(shù)據(jù)背景下，很多東西和ClickHouse自有技術(shù)是密切相關(guān)的，這也是為什么最終選擇了ClickHouse做我們的技術(shù)方案。

通常我們?cè)诘讓訑?shù)據(jù)模型的基礎(chǔ)上創(chuàng)建一些指標(biāo)體系，由于我們擁有很多業(yè)務(wù)方以及眾多的用戶(hù)，所以需要非常靈活的切分這些數(shù)據(jù)模型和指標(biāo)體系，從而為每個(gè)個(gè)體提供對(duì)他本人最有價(jià)值的指標(biāo)分析功能。

2. 全域消費(fèi)者互動(dòng)與觸達(dá)

從業(yè)務(wù)角度來(lái)看，現(xiàn)在的全域消費(fèi)者都在做什么？消費(fèi)者可以在抖音、小紅書(shū)或者淘寶店鋪搜索一件商品，與此同時(shí)消費(fèi)者也可以從其他網(wǎng)站繼續(xù)瀏覽該商品，并且有可能從多個(gè)渠道來(lái)購(gòu)買(mǎi)該商品，這就形成了一個(gè)網(wǎng)狀型的路徑。這就存在一個(gè)很大的問(wèn)題，就是按照這個(gè)路徑，數(shù)據(jù)復(fù)雜度會(huì)變得非常高，在沒(méi)有大數(shù)據(jù)或者很多數(shù)據(jù)量的情況下，很難回答消費(fèi)者到底瀏覽了此商品多少次，最后在哪購(gòu)買(mǎi)的。

對(duì)廣告主而言，需要投入多少?gòu)V告，才能讓消費(fèi)者記住或者購(gòu)買(mǎi)這件商品。同樣的，現(xiàn)在廣告投放渠道多種多樣，比如說(shuō)微信、抖音；哪個(gè)投放渠道成本最低，哪個(gè)渠道能達(dá)到最高的投入產(chǎn)出比，是大部分廣告主需要關(guān)注的問(wèn)題。因?yàn)?，目前的現(xiàn)狀是流量成本確實(shí)比較高，如果能降低獲客成本，并且提高轉(zhuǎn)化率，就為其在競(jìng)爭(zhēng)上提供了很大的優(yōu)勢(shì)。比如說(shuō)一個(gè)企業(yè)，可以通過(guò)眾多的渠道通過(guò)更低的價(jià)格來(lái)獲取更多的用戶(hù)，獲取用戶(hù)之后，就可以吸引更多的電商入駐，或者更多的商家入駐， 通過(guò)賣(mài)更多的貨，從而形成一個(gè)很好的閉環(huán)。在開(kāi)通電商業(yè)務(wù)前，至少需要考慮是否在微信，抖音，淘寶，或者其他地方深耕某一渠道，當(dāng)面臨非常復(fù)雜的選擇時(shí)來(lái)決定到底做哪個(gè)渠道，賣(mài)什么商品。

3. 流量分析的難題

從產(chǎn)品角度分析后，我們發(fā)現(xiàn)如下幾個(gè)問(wèn)題：

• 數(shù)據(jù)時(shí)效性：比如說(shuō)傳統(tǒng)的解決方案，都是次天（T+1）看數(shù)據(jù)，今天做該做的事情，第二天看數(shù)據(jù)的結(jié)果。在傳統(tǒng)的方案里，由于當(dāng)時(shí)無(wú)法查看實(shí)時(shí)數(shù)據(jù)，所以只能這么做。現(xiàn)在的方式不同以往，大家希望根據(jù)更及時(shí)、更實(shí)時(shí)的數(shù)據(jù)來(lái)做決定。及時(shí)數(shù)據(jù)就是當(dāng)想觀察數(shù)據(jù)時(shí)，快速產(chǎn)生數(shù)據(jù)；實(shí)時(shí)數(shù)據(jù)就是在運(yùn)營(yíng)或者做活動(dòng)時(shí)，可以參考當(dāng)天的數(shù)據(jù)，而不是今天需要運(yùn)營(yíng)，卻查看昨天的數(shù)據(jù)。

• 通用的指標(biāo)體系：數(shù)據(jù)倉(cāng)庫(kù)的技術(shù)壁壘，比如說(shuō)在抖音上，能觀察到一些指標(biāo)，那么在其他的渠道或行業(yè)中運(yùn)營(yíng)，這些指標(biāo)體系是不通用的。這里一部分指標(biāo)是場(chǎng)景所特有的，但另一部分指標(biāo)是數(shù)據(jù)對(duì)特定的技術(shù)要求。如果主要的指標(biāo)體系是不通用的，很難在不同渠道進(jìn)行對(duì)比。比如說(shuō)，在渠道A，提供的指標(biāo)是1,2,3，但是渠道B和渠道C提供的指標(biāo)是A,B,C，從而對(duì)哪個(gè)指標(biāo)更好，產(chǎn)生疑惑。所以，在建設(shè)數(shù)據(jù)分析時(shí)， 需要使用一些通用的指標(biāo)，比如剛才的例子，如果是大寬表的話(huà)，通過(guò)一些技術(shù)就能很好的解決這個(gè)問(wèn)題；而在傳統(tǒng)研發(fā)模式中，只能分別對(duì)每一個(gè)渠道做一個(gè)報(bào)表的口徑，若是有不一致，或者存在其他一些小問(wèn)題，就會(huì)在后續(xù)運(yùn)營(yíng)中產(chǎn)生很多問(wèn)題。

• 靈活的OLAP分析：在傳統(tǒng)的行業(yè)或者方法中，需要一個(gè)BI， 讓他產(chǎn)出數(shù)據(jù)，這里產(chǎn)生的問(wèn)題就是如果你有很多業(yè)務(wù)，每個(gè)團(tuán)隊(duì)都需要這個(gè)BI來(lái)支持，讓他產(chǎn)出數(shù)據(jù)，然后這個(gè)人每天就寫(xiě)sql，無(wú)暇顧及其他業(yè)務(wù)。我們希望賦能我們的每個(gè)行業(yè)，比如說(shuō)分析師，或者小二，當(dāng)賣(mài)家想問(wèn)問(wèn)題時(shí)，可以通過(guò)我們的產(chǎn)品進(jìn)行交互式的分析，來(lái)解決問(wèn)題。未來(lái)，我們希望小二能通過(guò)語(yǔ)音，說(shuō)“今天賣(mài)的最好的東西是什么？”。當(dāng)然了，解決這個(gè)問(wèn)題可能需要五到十年的時(shí)間，這是我們未來(lái)的發(fā)展方向。對(duì)于當(dāng)下，迫切需要解決的問(wèn)題是一大堆小伙伴們天天只寫(xiě)sql，無(wú)暇顧及其他的業(yè)務(wù)。

• 流量+業(yè)務(wù)數(shù)據(jù)：目前存在的痛點(diǎn)是我們有一些流量數(shù)據(jù)，但是對(duì)于業(yè)務(wù)，例如一個(gè)具體的BU，或者說(shuō)一個(gè)BU再加上他的三方代理商準(zhǔn)備做一個(gè)活動(dòng)，我們需要觀察這個(gè)活動(dòng)的效果。其中存在的問(wèn)題是，需要先把目前已有數(shù)據(jù)和外部數(shù)據(jù)做一個(gè)關(guān)聯(lián)，然后，再做這個(gè)事情。這就從一個(gè)業(yè)務(wù)問(wèn)題變成了一個(gè)技術(shù)問(wèn)題，我們希望能讓這種問(wèn)題通過(guò)技術(shù)來(lái)快速解決，來(lái)降低門(mén)檻。同時(shí)，我們也希望能從產(chǎn)品的角度來(lái)解決問(wèn)題，雖然不能完全解決問(wèn)題，但是至少能快速的配置解決問(wèn)題，所以這些是我們當(dāng)時(shí)在流量分析前考慮的事情和需要做的事情。

4. 問(wèn)題思考

針對(duì)這些難點(diǎn)，我們做了一些思考：

• 時(shí)效性：傳統(tǒng)的方案時(shí)效性受限，不過(guò)可以通過(guò)Flink或者Blink來(lái)產(chǎn)出一些簡(jiǎn)單的指標(biāo)，但是這些指標(biāo)，又和后面離線(xiàn)的數(shù)據(jù)不一致?？赡苁怯捎谥挥幸粋€(gè)指標(biāo)，但是沒(méi)有其他分析維度，所以就需要依賴(lài)ClickHouse的其他功能，比如說(shuō)實(shí)時(shí)計(jì)算功能來(lái)解決這些問(wèn)題。

• 指標(biāo)體系：是一個(gè)與業(yè)務(wù)緊密相關(guān)的設(shè)計(jì)問(wèn)題，在此不再贅述。

• OLAP分析：關(guān)于分析寬表和明細(xì)數(shù)據(jù)，首先簡(jiǎn)單介紹一下寬表，通常前面可能有十個(gè)維度的數(shù)據(jù)，后面可能有十個(gè)指標(biāo)，然后，我們通過(guò)寬表跨數(shù)據(jù)庫(kù)來(lái)做查詢(xún)。其實(shí)我們更想做的是一個(gè)明細(xì)的數(shù)據(jù)，例如ClickHouse有一個(gè)功能，可以把半加工的數(shù)據(jù)放到數(shù)據(jù)庫(kù)里，當(dāng)需要再做查詢(xún)的時(shí)候，其往往可以做更復(fù)雜的查詢(xún)。所以，我們可以把一層數(shù)據(jù)壓縮好，從而服務(wù)更多的業(yè)務(wù)。同樣，也可以通過(guò)物化視圖materialized view來(lái)做出復(fù)雜的查詢(xún)，我們最后的解決方案是materialized view和明細(xì)數(shù)據(jù)一起應(yīng)用。如果需要一個(gè)定制的查詢(xún)，就采取materialized view解決方案，如果說(shuō)需要一個(gè)靈活的查詢(xún)，就用明細(xì)數(shù)據(jù)方案。

• 自定義維度：動(dòng)態(tài)的schema，是一個(gè)比較復(fù)雜的問(wèn)題， 如何讓用戶(hù)自定義維度而且不需要我們事先設(shè)定好，這是一個(gè)比較頭疼的問(wèn)題。

接下來(lái)介紹的，就是大數(shù)據(jù)以及淘寶流量數(shù)據(jù)帶來(lái)的一些問(wèn)題：

• 計(jì)算和存儲(chǔ)的成本

• pipeline管理：比如有很多數(shù)據(jù)在前面的表格里已經(jīng)計(jì)算完畢，然后需要在其它的表格中重復(fù)計(jì)算，這其中包含了非常復(fù)雜的management，如果你需要在規(guī)定的時(shí)間產(chǎn)出數(shù)據(jù)的話(huà)，你需要管理好pipeline，一旦其中某一個(gè)pipeline失敗的話(huà)，你至少需要知道，這個(gè)pipeline失敗到重啟，下游會(huì)有哪些延遲。

• 高峰QPS與95%查詢(xún)時(shí)間：是內(nèi)部做產(chǎn)品的一個(gè)標(biāo)準(zhǔn)，在高峰QPS時(shí)，95%的查詢(xún)時(shí)間應(yīng)小于8s。

下圖來(lái)源于官網(wǎng)，主要通過(guò)其中幾個(gè)功能來(lái)解決我們所遇到的問(wèn)題。

1. 計(jì)算&存儲(chǔ)成本

關(guān)于計(jì)算存儲(chǔ)成本，ClickHouse有非常高的數(shù)據(jù)壓縮比例，其本身就是一個(gè)列的數(shù)據(jù)庫(kù)，在這里著重介紹一些ClickHouse比較有效的功能：

Data Compression：Encoding本身具有很多數(shù)據(jù)，并且支持ClickHouse做出來(lái)的Unicode，例如：Delta，delta其本質(zhì)就是時(shí)間差，在很多事件中如果使用date encoding，通?？梢允『芏鄷r(shí)間，可以在后續(xù)做一些優(yōu)化。另外就是lowcardinality，假設(shè)其有一個(gè)string，但是這個(gè)string變得不會(huì)太大，通過(guò)使用這種encoding可以減少它的查詢(xún)和存儲(chǔ)的時(shí)間。然后還有很多類(lèi)似date-time function的方式，比如yyyydd格式的時(shí)間，其通常會(huì)把一些時(shí)間的function事先壓縮好，允許在計(jì)算的時(shí)候，做許多優(yōu)化。

Support for Approximated Calculations：ClickHouse其實(shí)是支持多種HL算法優(yōu)化的：比如準(zhǔn)確度和查詢(xún)時(shí)間，假設(shè)業(yè)務(wù)方在查詢(xún)結(jié)果上能接受百分之一的不準(zhǔn)確，那么ClickHouse可以在三到五秒內(nèi)得出結(jié)果，我們認(rèn)為這是個(gè)合理的過(guò)程。因?yàn)樵诤芏鄷r(shí)候，有些BI是做一種探索性分析的，而在做探索性分析時(shí)，假如要考察紅襪和藍(lán)襪哪個(gè)更受市場(chǎng)歡迎，如果兩種品類(lèi)的偏差只有百分之一，也沒(méi)有達(dá)到一個(gè)絕對(duì)性的結(jié)論證明紅襪比藍(lán)襪賣(mài)的好，鑒于這種情況，我們用HL算法來(lái)支持用戶(hù)體驗(yàn)，是值得的。如果真需要一個(gè)精準(zhǔn)的數(shù)據(jù)，可以通過(guò)uniq，uniqexact來(lái)算出一個(gè)精準(zhǔn)的數(shù)據(jù)，通常情況下，uniq能直接得出很好的結(jié)果，會(huì)得到一個(gè)很好的體驗(yàn)。

Disk Srorage of Data：storage policy可以按照disk storage policy把部分?jǐn)?shù)據(jù)，比如一個(gè)星期的數(shù)據(jù)，放在硬盤(pán)或者ssd上，其中包含storage policy與data TTL， TTL就是在數(shù)據(jù)失敗的時(shí)候，能暫時(shí)控制一下。其中哪些數(shù)據(jù)，我們?cè)试S做熱查詢(xún)，哪些數(shù)據(jù)，可以做冷查詢(xún)，這些都是我們?cè)趦?yōu)化解決計(jì)算和存儲(chǔ)成本的一些事情。

2. Pipeline，HA，時(shí)效性

Data Replication and Data Integrity Support：在做Pipline管理，HA，時(shí)效性時(shí)，還可以把clusters和sharding一起使用，我們可以通過(guò)底層的不同的sharding 來(lái)快速導(dǎo)入數(shù)據(jù)，然后在上面通過(guò)replication來(lái)增加查詢(xún)的性能。

Real-time Data Updates：另外就是上文提到的實(shí)時(shí)，在insert distributed中我們可以通過(guò)各種不同的接口，直接把數(shù)據(jù)導(dǎo)入。其次，materialized view的一個(gè)優(yōu)點(diǎn)是自動(dòng)計(jì)算，每次有insert時(shí)都會(huì)check上面的計(jì)算。在大部分的情況下，其都是定制的distributed，可以在減少pipeline管理的情況下，直接把數(shù)據(jù)導(dǎo)入并且計(jì)算出結(jié)果。除此之外，其他的方面通常屬于具體的技術(shù)層面，都是用來(lái)輔助我們管理數(shù)據(jù)的導(dǎo)入情況。

3. 查詢(xún)性能&靈活性

接下來(lái)就是在做查詢(xún)性能和靈活性時(shí)，采用的一些方法：

高峰：

• materialized view寬表：使用materialized view來(lái)做一個(gè)大寬表，通過(guò)此寬表可以快速服務(wù)60%-70%的查詢(xún)

• aggregatingMergeTree：可以把state放在其中，其本質(zhì)上是半加工的半加工體，后續(xù)每當(dāng)需要做復(fù)雜查詢(xún)時(shí)就可以直接從這里查詢(xún)，merge起來(lái)。

• quota：可以控制一下在每次查詢(xún)時(shí)所使用的rom，memory等，就是類(lèi)似primary的功能， 控制查詢(xún)的結(jié)果，或者是資源的消耗。

• primary index：當(dāng)在做表設(shè)計(jì)時(shí)，考慮好將需要的字段作為primary index，那么在掃描時(shí)候能快速掃描。

靈活性：

針對(duì)靈活性有以下幾個(gè)功能：

• Dictionary：可以解決很多在做join時(shí)的問(wèn)題，是TB的一個(gè)字典，支持放在sql里，也可以放在memory里，比較靈活

• join：ClickHouse舊版本的join操作不是特別好用，但是現(xiàn)在做的不錯(cuò)，現(xiàn)在我們可以通過(guò)dictionary，做很多靈活的匯總和join。可惜的是，以前沒(méi)有這項(xiàng)功能，join就是普通的join

• external tables：是指可以把ClickHouse和mysql同時(shí)使用，通常我們會(huì)把很多的尾表，或者其他的東西存儲(chǔ)在mysql上，因?yàn)閙ysql成本更低，并且ClickHouse支持mysql的表可以在上面直接進(jìn)行查詢(xún)，因此允許它們一起使用

• 嵌套性模型數(shù)據(jù)和JSONAsString：在自定義維度的時(shí)候，可以通過(guò)嵌套式的數(shù)據(jù)格式來(lái)支持自定義維度，然后通過(guò)ClickHouse快速完成解析，從而得出查詢(xún)結(jié)果

4. 產(chǎn)品考慮

最后，需要從產(chǎn)品方面考慮選擇的技術(shù)，我需要做什么？

• 查詢(xún)：我們知道大部分的人通常采取高準(zhǔn)度查詢(xún)，在這種情況下，通過(guò)materialized view的功能，就可以把大部分的查詢(xún)推到materialized view。materialized view，也支持實(shí)時(shí)計(jì)算功能，所以我們就可以通過(guò)materialized view對(duì)用戶(hù)解釋?zhuān)舆t三到五分鐘就可以得出結(jié)果。

• 復(fù)雜查詢(xún)：很多復(fù)雜的查詢(xún)都是近期數(shù)據(jù)，而不是幾年前的數(shù)據(jù)，table中通常只是三個(gè)月或者幾個(gè)月的數(shù)據(jù)，我們通過(guò)table ttl，就能進(jìn)行自動(dòng)的管理。從而，節(jié)約了我們維護(hù)的成本。

• 靈活查詢(xún)：可以通過(guò)各種不同的功能，比如樹(shù)引擎、字典、mysql，來(lái)支持移動(dòng)靈活的查詢(xún)。由于這些功能，我們也可以進(jìn)行快速的配置，不需要像以前一樣進(jìn)行開(kāi)發(fā)。

• 表格優(yōu)化：在設(shè)計(jì)表格時(shí)，需要適量補(bǔ)充表格，哪些表格選擇index合適，哪些表格選擇group by合適，然后做一些測(cè)試實(shí)驗(yàn)。

• 按需數(shù)據(jù)加工：因?yàn)镃lickHouse壓縮數(shù)據(jù)比例非常高，可以把它放到底層。當(dāng)在復(fù)雜的查詢(xún)情況下，按客戶(hù)的需求，進(jìn)行復(fù)雜的查詢(xún)；然后再把一些數(shù)據(jù)從某一些數(shù)據(jù)庫(kù)挪到其他任何的數(shù)據(jù)庫(kù)中，從而加工出來(lái)一個(gè)單獨(dú)的表格，之后把這個(gè)表格，落到客戶(hù)的odps上。我們能否通過(guò)這種方式來(lái)更好的服務(wù)我們的用戶(hù)，而不像傳統(tǒng)的方案那樣，需要維護(hù)一個(gè)很大的集群用來(lái)支持所有的查詢(xún)或者計(jì)算；能否嚴(yán)格按照用戶(hù)需要調(diào)動(dòng)任務(wù)，從而調(diào)動(dòng)此任務(wù)所產(chǎn)出的數(shù)據(jù)，就可以直接把結(jié)果數(shù)據(jù)分享給客戶(hù)，這份數(shù)據(jù)可以通過(guò)下面table的TTL ，幾天后可以把這些數(shù)據(jù)刪除，從而減少整個(gè)查詢(xún)所消耗的集群成本。

今天的分享就到這里，謝謝大家。

特別推薦一個(gè)分享架構(gòu)+算法的優(yōu)質(zhì)內(nèi)容，還沒(méi)關(guān)注的小伙伴，可以長(zhǎng)按關(guān)注一下：

長(zhǎng)按訂閱更多精彩▼
如有收獲，點(diǎn)個(gè)在看，誠(chéng)摯感謝