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

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

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

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

1. 流量分析

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

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

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

指標體系：

我們通常用以下四種指標來分析數(shù)據(jù)：

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

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

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

• 粘性，就是你花了多長時間把用戶拉過來，讓用戶完成一件事情，并且了解用戶對此具體業(yè)務(wù)有沒有粘性。

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

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

2. 全域消費者互動與觸達

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

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

3. 流量分析的難題

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

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

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

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

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

4. 問題思考

針對這些難點，我們做了一些思考：

• 時效性：傳統(tǒng)的方案時效性受限，不過可以通過Flink或者Blink來產(chǎn)出一些簡單的指標，但是這些指標，又和后面離線的數(shù)據(jù)不一致。可能是由于只有一個指標，但是沒有其他分析維度，所以就需要依賴ClickHouse的其他功能，比如說實時計算功能來解決這些問題。

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

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

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

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

• 計算和存儲的成本

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

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

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

1. 計算&存儲成本

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

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

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

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

2. Pipeline，HA，時效性

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

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

3. 查詢性能&靈活性

接下來就是在做查詢性能和靈活性時，采用的一些方法：

高峰：

• materialized view寬表：使用materialized view來做一個大寬表，通過此寬表可以快速服務(wù)60%-70%的查詢

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

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

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

靈活性：

針對靈活性有以下幾個功能：

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

• join：ClickHouse舊版本的join操作不是特別好用，但是現(xiàn)在做的不錯，現(xiàn)在我們可以通過dictionary，做很多靈活的匯總和join?？上У氖?，以前沒有這項功能，join就是普通的join

• external tables：是指可以把ClickHouse和mysql同時使用，通常我們會把很多的尾表，或者其他的東西存儲在mysql上，因為mysql成本更低，并且ClickHouse支持mysql的表可以在上面直接進行查詢，因此允許它們一起使用

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

4. 產(chǎn)品考慮

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

• 查詢：我們知道大部分的人通常采取高準度查詢，在這種情況下，通過materialized view的功能，就可以把大部分的查詢推到materialized view。materialized view，也支持實時計算功能，所以我們就可以通過materialized view對用戶解釋，延遲三到五分鐘就可以得出結(jié)果。

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

• 靈活查詢：可以通過各種不同的功能，比如樹引擎、字典、mysql，來支持移動靈活的查詢。由于這些功能，我們也可以進行快速的配置，不需要像以前一樣進行開發(fā)。

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

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

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

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

長按訂閱更多精彩▼
如有收獲，點個在看，誠摯感謝