摘要：關(guān)于友盟數(shù)據(jù)架構(gòu)友盟架構(gòu)思想友盟的架構(gòu)主要參考了提出的架構(gòu)思想。關(guān)于友盟實(shí)踐通過以上的介紹，大家可能對(duì)整個(gè)大數(shù)據(jù)平臺(tái)的結(jié)構(gòu)和概念有了初步的了解。所以接下來(lái)，我給大家分享一些友盟在實(shí)踐中得到的一些經(jīng)驗(yàn)。友盟的數(shù)據(jù)平臺(tái)經(jīng)歷了一個(gè)發(fā)展的過程。

摘要：友盟大數(shù)據(jù)平臺(tái)的架構(gòu)借鑒了Lambda架構(gòu)思想，數(shù)據(jù)接入層讓Kafka集群承擔(dān)，后面由Storm消費(fèi)，存儲(chǔ)在MongoDB里面，通過Kafka自帶的Mirror功能同步，兩個(gè)Kafka集群，可以分離負(fù)載；計(jì)算有離線和實(shí)時(shí)兩部分，實(shí)時(shí)是Storm，離線是Hadoop，數(shù)據(jù)倉(cāng)庫(kù)用Hive，數(shù)據(jù)挖掘正在從Pig遷移到Spark，大量的數(shù)據(jù)通過計(jì)算之后，存儲(chǔ)在HDFS上，最后存儲(chǔ)在HBase里面，通過ES來(lái)提供多級(jí)索引，以彌補(bǔ)HBase二級(jí)索引的缺失......

友盟從 2010 年成立開始就專注移動(dòng)大數(shù)據(jù)， 5 年來(lái)不僅積累了大量的數(shù)據(jù)，而且積累了豐富的技術(shù)和經(jīng)驗(yàn)，那么友盟的大數(shù)據(jù)平臺(tái)是怎樣架構(gòu)的呢？在剛剛結(jié)束的MDCC 2015 大會(huì)上，友盟的數(shù)據(jù)平臺(tái)負(fù)責(zé)人吳磊在 Android 專場(chǎng)為大家做了技術(shù)分享。

以下是吳磊的口述，整理時(shí)略有刪減。

關(guān)于友盟大數(shù)據(jù)平臺(tái)

目前，友盟合作的 App 超過 64 萬(wàn) ，同時(shí)為 23 萬(wàn)開發(fā)者團(tuán)隊(duì)提供服務(wù)，截止到2015年7月底，友盟數(shù)據(jù)平臺(tái)總量 9 PB，每天增量壓縮后有 7TB，每天要處理接近 82 億的對(duì)話，實(shí)時(shí)處理 100K QPS，離線處理 800 多個(gè)常規(guī)任務(wù)，集群規(guī)模是 500 多臺(tái)服務(wù)器， 14000 個(gè) CPU 核心。

關(guān)于友盟數(shù)據(jù)架構(gòu)

友盟架構(gòu)思想

友盟的架構(gòu)主要參考了Twitter提出的Lambda架構(gòu)思想。

如上圖所示，最下面是快速處理層，新增數(shù)據(jù)在快速處理層計(jì)算，這部分?jǐn)?shù)據(jù)比較小，可以快速完成，生成實(shí)時(shí)視圖。

同時(shí)，新增數(shù)據(jù)會(huì)并入全量數(shù)據(jù)集，進(jìn)行批處理，生成批處理視圖。這樣，系統(tǒng)同時(shí)具有了低延遲實(shí)時(shí)處理能力，也具有離線大數(shù)據(jù)處理能力。之后通過數(shù)據(jù)服務(wù)層，把兩個(gè)視圖合并起來(lái)，對(duì)外提供服務(wù)。在外部看來(lái)，這是一個(gè)完整的視圖。 就這樣，通過 lambda 架構(gòu)我們可以將實(shí)時(shí)處理和批處理系統(tǒng)巧妙的結(jié)合起來(lái)。

友盟數(shù)據(jù)平臺(tái)整體架構(gòu)

根據(jù)友盟的業(yè)務(wù)特點(diǎn)，數(shù)據(jù)平臺(tái)由下向上分成這幾個(gè)部分：最基礎(chǔ)的是日志收集，接下來(lái)進(jìn)入離線計(jì)算和實(shí)時(shí)分析，計(jì)算后的結(jié)果，會(huì)進(jìn)行數(shù)據(jù)挖掘，有價(jià)值的數(shù)據(jù)進(jìn)入數(shù)據(jù)倉(cāng)庫(kù)。接下來(lái)友盟會(huì)提供一個(gè)基于 REST Service的數(shù)據(jù)服務(wù)，在此服務(wù)之上做各種數(shù)據(jù)應(yīng)用例如：報(bào)表、數(shù)據(jù)分析報(bào)告，數(shù)據(jù)下載等等。兩邊的部分提供輔助的功能：包括任務(wù)調(diào)度和監(jiān)控管理。

友盟數(shù)據(jù)流水線

結(jié)合友盟的業(yè)務(wù)架構(gòu)和 lambda 架構(gòu)思想，最終的系統(tǒng)如下圖所示：最左邊是數(shù)據(jù)采集層，友盟提供手機(jī)、平板、盒子的SDK給App集成，App通過SDK發(fā)送日志到友盟平臺(tái)；首先進(jìn)入到Nginx，負(fù)載均衡之后傳給基于finagle框架的日志接收器，接著來(lái)到數(shù)據(jù)接入層。

友盟使用兩個(gè) Kafka 集群來(lái)承擔(dān)數(shù)據(jù)接入功能。上面這個(gè)Kafka集群被實(shí)時(shí)計(jì)算消費(fèi)。下面的kafka是用于離線數(shù)據(jù)消費(fèi)，兩個(gè)集群之間通過Kafka的mirror功能進(jìn)行同步。這么做的主要目的是IO負(fù)載的分離，避免離線部分過大的IO請(qǐng)求影響到實(shí)時(shí)計(jì)算部分；以及實(shí)時(shí)離線部分的業(yè)務(wù)解耦，方便兩部分業(yè)務(wù)獨(dú)立發(fā)展。

接下來(lái)是數(shù)據(jù)計(jì)算層，分別由離線計(jì)算層和實(shí)時(shí)計(jì)算層組成。離線部分，我們主要是基于Hadoop Mapreduce框架開發(fā)了一系列的MR任務(wù)。同時(shí)使用Hive建立我們的數(shù)據(jù)倉(cāng)庫(kù)，使用pig進(jìn)行數(shù)據(jù)挖掘，現(xiàn)在我們也在逐步使用Spark來(lái)承擔(dān)數(shù)據(jù)挖掘相關(guān)的工作。實(shí)時(shí)部分是通過storm來(lái)進(jìn)行流式計(jì)算。

實(shí)時(shí)部分的計(jì)算結(jié)果會(huì)存儲(chǔ)到 MongoDB，離線部分的數(shù)據(jù)存儲(chǔ)在 HDFS 。離線分析的結(jié)果存儲(chǔ)在 HBase 。因?yàn)?HBase 缺少二級(jí)索引的相關(guān)功能，所以我們引入了 Elastic Search 來(lái)為 HBase 相關(guān)表提供索引查詢功能。最后通過統(tǒng)一的 REST Service 來(lái)對(duì)外提供數(shù)據(jù)服務(wù)。

關(guān)于友盟實(shí)踐

通過以上的介紹，大家可能對(duì)整個(gè)大數(shù)據(jù)平臺(tái)的結(jié)構(gòu)和概念有了初步的了解。正如Linux 之父的名言，“Talk is cheap, show me the code！”一樣，其實(shí)知道是相對(duì)容易的，難的是如何去實(shí)現(xiàn)。所以接下來(lái)，我給大家分享一些友盟在實(shí)踐中得到的一些經(jīng)驗(yàn)。

友盟實(shí)踐之?dāng)?shù)據(jù)采集

首先是從數(shù)據(jù)采集來(lái)說起，數(shù)據(jù)采集部分面臨了很大的挑戰(zhàn)。

第一是大流量，友盟服務(wù)大量開發(fā)者，接受數(shù)以億計(jì)的設(shè)備發(fā)來(lái)日志，每天要處理80億次對(duì)話，數(shù)據(jù)量非常大。
高并發(fā)也是移動(dòng)互聯(lián)網(wǎng)的特點(diǎn)。比如：用戶在早上上班路上，中午吃飯后以及晚上睡覺前，是使用的高峰期，這個(gè)時(shí)候會(huì)對(duì)我們?cè)斐煞浅８叩牟l(fā)請(qǐng)求。
還有擴(kuò)展性，因?yàn)橐苿?dòng)互聯(lián)網(wǎng)是在高速發(fā)展的，最開始我們一臺(tái)機(jī)器就可以抗住，隨著發(fā)展我們現(xiàn)在可能需要10臺(tái)，20臺(tái)，如果系統(tǒng)沒有橫向擴(kuò)展能力將會(huì)是很痛苦的事情。

友盟的數(shù)據(jù)平臺(tái)經(jīng)歷了一個(gè)發(fā)展的過程。在2010年剛開始的時(shí)候，因?yàn)榭焖偕暇€的要求，我們是基于RoR開發(fā)的，在后臺(tái)通過Resque進(jìn)行一些離線的處理。這個(gè)架構(gòu)，隨著互聯(lián)網(wǎng)的爆發(fā)，面臨巨大的數(shù)據(jù)壓力，很快就不能適用了。

接下來(lái)，我們就切換到基于Finagle Server的日志服務(wù)器。這個(gè)Finagle Server是Twitter開源出來(lái)的一個(gè)異步服務(wù)器框架，很適合移動(dòng)互聯(lián)網(wǎng)的訪問特點(diǎn)：高并發(fā)，小數(shù)據(jù)量。切換到Finagle Server之后，我們單臺(tái)服務(wù)器的處理能力得到了極大的提升。同時(shí)日志收集服務(wù)的無(wú)狀態(tài)特性可以支持橫向擴(kuò)展，所以當(dāng)我們面臨非常高壓力的時(shí)候可以簡(jiǎn)單地通過增加臨時(shí)服務(wù)器來(lái)解決。

友盟實(shí)踐之?dāng)?shù)據(jù)清洗

大數(shù)據(jù)的特點(diǎn)之一是數(shù)據(jù)多樣化，如果不進(jìn)行清洗會(huì)對(duì)后面的計(jì)算產(chǎn)生困擾。在數(shù)據(jù)清洗方面，我們花了很多精力，并踩了很多的坑。

1、首先說“唯一標(biāo)識(shí)”。

做數(shù)據(jù)分析，第一件事情就是要拿到“唯一標(biāo)識(shí)”。安卓系統(tǒng)里作為唯一標(biāo)識(shí)的，常用的是IMEI，MAC， AndroidID。首先因?yàn)榘沧克槠瘑栴}，通過API在采集這些數(shù)據(jù)的時(shí)候，常常會(huì)有采集不到的情況。

還有其他一些異常的情況，比如有很多山寨機(jī)沒有合法的 IMEI，所以會(huì)很多機(jī)器共用一個(gè) IMEI，導(dǎo)致IMEI重復(fù)；有些 ROM 刷機(jī)后會(huì)更改 MAC 地址，導(dǎo)致 MAC 重復(fù)；大部分電視盒子本身就沒有IMEI。這種情況下我們單純用 IMEI 或者 MAC ，或者安卓 ID ，來(lái)進(jìn)行標(biāo)識(shí)的的話，就會(huì)出現(xiàn)問題。

友盟采用的辦法是由多帶帶的服務(wù)來(lái)統(tǒng)一計(jì)算。后臺(tái)會(huì)有離線任務(wù)來(lái)進(jìn)行計(jì)算，發(fā)現(xiàn)重復(fù)率很高的標(biāo)識(shí)符，加入到黑名單里。在計(jì)算的時(shí)候，直接跳過黑名單里的標(biāo)識(shí)，換用另一種算法進(jìn)行計(jì)算。

2、在“數(shù)據(jù)標(biāo)準(zhǔn)化”時(shí)，也遇到了很多的坑

比如：“設(shè)備型號(hào)”，并不是直接采集 model 這個(gè)字段就可以解決的。拿小米 3 舉例，這個(gè)手機(jī)會(huì)有很多版本，不同的批次 model 字段不一樣。對(duì)于這種情況，如果我們不進(jìn)行統(tǒng)一標(biāo)準(zhǔn)化，我們算出來(lái)的結(jié)果，肯定有問題。

還會(huì)出現(xiàn)多機(jī)一型的情況，例如 m1，大家都知道是這是一款2011年出現(xiàn)的熱門手機(jī)，很有意思的是時(shí)過三年之后活躍設(shè)備數(shù)量發(fā)生了再次突增。經(jīng)過調(diào)查發(fā)現(xiàn)，原來(lái)是他的一個(gè)對(duì)手廠家，在2014年底生產(chǎn)了一款暢銷的產(chǎn)品，model字段也叫m1。因此，我們就需要把設(shè)備型號(hào)，通過專門手段來(lái)和產(chǎn)品名稱對(duì)應(yīng)上，統(tǒng)一標(biāo)準(zhǔn)化。

另外在數(shù)據(jù)標(biāo)準(zhǔn)化過程中，還會(huì)遇到“地域識(shí)別”的問題。地域識(shí)別是用 IP 地址來(lái)識(shí)別的。因?yàn)橹袊?guó) IP 地址管理并不是非常規(guī)范，所以經(jīng)常會(huì)出現(xiàn)，上一秒鐘大家還在北京，下一秒就到深圳的情況。對(duì)于解決這樣的問題，我們是選用設(shè)備一天中最常出現(xiàn)的 IP 地址作為當(dāng)天的地域標(biāo)識(shí)。

還有“時(shí)間識(shí)別”，也是很大的問題。最開始我們采用的都是客戶端時(shí)間。但是客戶時(shí)間有很大的隨意性，用戶的一個(gè)錯(cuò)誤設(shè)置，就會(huì)導(dǎo)致時(shí)間不一致；另外一些山寨機(jī)會(huì)有 Bug，機(jī)器重啟之后，時(shí)間直接就變成1970年1月1號(hào)了；還有一種可能，產(chǎn)生數(shù)據(jù)的時(shí)候沒有網(wǎng)絡(luò)連接，當(dāng)他重新聯(lián)網(wǎng)了，日志才會(huì)匯報(bào)到平臺(tái)，這樣的話數(shù)據(jù)就會(huì)產(chǎn)生延遲。

為了解決這些時(shí)間不一致的問題，我們統(tǒng)一使用服務(wù)器端時(shí)間。但是這樣又帶來(lái)了新的問題：統(tǒng)計(jì)時(shí)間和真實(shí)時(shí)間的差異，但是這個(gè)差異值是從小時(shí)間窗口（例如一個(gè)小時(shí)，或一天）觀察出來(lái)的，從大的時(shí)間窗口來(lái)看是正確的。

3、“數(shù)據(jù)格式的歸一化”也很重要。

因?yàn)槲覀?SDK，經(jīng)過很多版的進(jìn)化，上報(bào)上來(lái)的日志會(huì)有多種格式。早期的時(shí)候我們是采用 Json 格式，后期的話我們使用Thrift的格式。在數(shù)據(jù)平臺(tái)處理的時(shí)候，兩種格式切換很麻煩，所在我們?cè)谔幚碇?，我們把它統(tǒng)一成 Protobuf ，來(lái)進(jìn)行后期計(jì)算。

友盟實(shí)踐之?dāng)?shù)據(jù)計(jì)算

在數(shù)據(jù)計(jì)算的時(shí)候，根據(jù)不同業(yè)務(wù)對(duì)于時(shí)延的容忍程度的高低，分為實(shí)時(shí)計(jì)算，離線計(jì)算和準(zhǔn)實(shí)時(shí)計(jì)算。

實(shí)時(shí)計(jì)算，面臨的挑戰(zhàn)之一是時(shí)效性。因?yàn)閷?shí)時(shí)計(jì)算是對(duì)延時(shí)非常敏感的，毫秒級(jí)的水平。如果說，你把不合適的計(jì)算，比如一些很耗cpu的計(jì)算放進(jìn)來(lái)，會(huì)直接導(dǎo)致實(shí)時(shí)計(jì)算的延遲。所以在架構(gòu)時(shí)，需要考量，把哪些放到實(shí)時(shí)部分合適，哪些不適合。另外實(shí)時(shí)計(jì)算往往會(huì)在寫數(shù)據(jù)庫(kù)時(shí)會(huì)產(chǎn)生IO延遲，需要對(duì)實(shí)時(shí)數(shù)據(jù)庫(kù)專門進(jìn)行專門優(yōu)化。我們實(shí)時(shí)計(jì)算部分選用了MongoDB存儲(chǔ)數(shù)據(jù)，同時(shí)不斷優(yōu)化MongoDB的寫請(qǐng)求來(lái)解決這個(gè)問題。

另外一個(gè)挑戰(zhàn)是突發(fā)流量。用戶使用 App 的頻率并不均勻，早上、中午、晚上會(huì)有很高的使用率，尤其是晚上10:00-12:00這個(gè)時(shí)間段會(huì)對(duì)我們系統(tǒng)帶來(lái)非常大的壓力，得益于之前的架構(gòu)設(shè)計(jì)，在達(dá)到一定的閾值之后，會(huì)觸發(fā)報(bào)警，運(yùn)維的同學(xué)會(huì)進(jìn)行臨時(shí)擴(kuò)容來(lái)應(yīng)對(duì)這些突發(fā)流量。
因?yàn)閷?shí)時(shí)計(jì)算通常是增量計(jì)算，因此會(huì)產(chǎn)生誤差積累的問題。Lambda架構(gòu)決定了實(shí)時(shí)和離線是兩套獨(dú)立的計(jì)算系統(tǒng)，所以必然會(huì)出現(xiàn)誤差。如果你長(zhǎng)時(shí)間使用實(shí)時(shí)計(jì)算的結(jié)果，這個(gè)誤差會(huì)越來(lái)越大。我們現(xiàn)在解決的辦法是在實(shí)時(shí)處理時(shí)，不要給他太大的時(shí)間窗口，比如說最多不要超過一天，超過一天之后，就要開始清理，離線部分的計(jì)算每天計(jì)算一次，保證在這個(gè)時(shí)候離線部分的數(shù)據(jù)計(jì)算完成，這樣我們就可以用離線的數(shù)據(jù)來(lái)覆蓋實(shí)時(shí)數(shù)據(jù)，從而消除這個(gè)數(shù)據(jù)誤差。

離線計(jì)算，也會(huì)面臨一些問題。最常遇到的麻煩是數(shù)據(jù)傾斜問題。數(shù)據(jù)傾斜這個(gè)事情，幾乎是天然存在的，比如說一些大App的數(shù)據(jù)量，和小的App的數(shù)據(jù)量存在著巨大的差距，常常會(huì)在離線計(jì)算的時(shí)候產(chǎn)生長(zhǎng)尾現(xiàn)象，并行的MR作業(yè)中總是有一兩個(gè)任務(wù)拖后腿，甚至超出單機(jī)計(jì)算能力。

產(chǎn)生數(shù)據(jù)傾斜的原因有很多種，針對(duì)不同的原因，有不同的解決辦法。最常見的原因是因?yàn)榱６葎澐痔謱?dǎo)致的，比如說我們計(jì)算的時(shí)候，如果以App ID來(lái)進(jìn)行分區(qū)，很容易導(dǎo)致數(shù)據(jù)傾斜。針對(duì)這種情況，友盟的解決辦法的是進(jìn)行更細(xì)一步的劃分，比如說我們通過App ID 加設(shè)備ID進(jìn)行分區(qū)，然后再將結(jié)果聚合起來(lái)，這樣就可以減少數(shù)據(jù)傾斜的發(fā)生。

第二個(gè)問題是數(shù)據(jù)壓縮的問題。離線計(jì)算的時(shí)候，往往輸入輸出都會(huì)很大，因此我們要注意時(shí)時(shí)刻刻進(jìn)行壓縮，用消耗cpu時(shí)間來(lái)?yè)Q取存儲(chǔ)空間的節(jié)省。這樣做能夠節(jié)省數(shù)據(jù)傳輸中的IO延遲，反而能夠降低整個(gè)任務(wù)的完成時(shí)間。

接下來(lái)會(huì)面臨資源調(diào)度的困難，因?yàn)槲覀兏鞣N任務(wù)優(yōu)先級(jí)是不一樣的，比如一些關(guān)鍵的指標(biāo)，要在特定時(shí)間算出來(lái)，有些任務(wù)則是早幾個(gè)小時(shí)都可以。Hadoop自帶的調(diào)度器無(wú)論是公平調(diào)度還是能力調(diào)度器都不能實(shí)現(xiàn)我們的需求, 我們是通過修改hadoop的調(diào)度器代碼來(lái)實(shí)現(xiàn)的。

另外我們還有一類任務(wù)對(duì)時(shí)延比較敏感，但是又不適合放到實(shí)時(shí)計(jì)算中的。這類任務(wù)我們稱之為準(zhǔn)實(shí)時(shí)任務(wù)。例如報(bào)表的下載服務(wù)，因?yàn)槭荌O密集型任務(wù)，放入實(shí)時(shí)不太合適，但是它又對(duì)時(shí)間比較敏感，可能用戶等三五分鐘還是可以接受的，但是等一兩個(gè)小時(shí)就很難接受了。對(duì)于這些準(zhǔn)實(shí)時(shí)任務(wù)我們之前采用的是通過預(yù)留一定資源來(lái)運(yùn)行MR來(lái)實(shí)現(xiàn)的?，F(xiàn)在用spark Streaming 專門來(lái)做這些事情。

在進(jìn)行準(zhǔn)實(shí)時(shí)計(jì)算時(shí)，里面也有一個(gè)資源占用的問題，在預(yù)留的過程中，會(huì)導(dǎo)致你的資源占用率過低，如何平衡是個(gè)問題；第二點(diǎn)很多實(shí)時(shí)計(jì)算的任務(wù)，往往也采用了增量計(jì)算模式，需要解決增量計(jì)算的誤差累計(jì)問題，我們通過一定時(shí)間的全量計(jì)算來(lái)彌補(bǔ)這個(gè)缺陷。

友盟實(shí)踐之?dāng)?shù)據(jù)存儲(chǔ)

數(shù)據(jù)存儲(chǔ)，根據(jù)我們之前的計(jì)算模式，我們也分為在線存儲(chǔ)和離線存儲(chǔ)兩部分。在實(shí)時(shí)部分的計(jì)算結(jié)果我們主要存在 MongoDB 里面，必須對(duì)寫IO進(jìn)行優(yōu)化。離線數(shù)據(jù)計(jì)算結(jié)果一般存儲(chǔ)在 HBase 里。但是HBase缺少二級(jí)索引。我們引入了Elastic Search，來(lái)幫助HBaes進(jìn)行索引相關(guān)的工作。

在做數(shù)據(jù)服務(wù)的時(shí)候通過數(shù)據(jù)緩存能夠解決數(shù)據(jù)冷熱的問題。友盟數(shù)據(jù)緩存用的是 Redis，同時(shí)使用了 TwemProxy 來(lái)作負(fù)載均衡。友盟在數(shù)據(jù)緩存這方面的經(jīng)驗(yàn)就是需要預(yù)加數(shù)據(jù)，比如：每天凌晨計(jì)算完數(shù)據(jù)之后，在用戶真正訪問之前，需要把部分計(jì)算結(jié)果預(yù)先加載上去，這樣等到用戶訪問的時(shí)候，就已經(jīng)在內(nèi)存里了。

友盟實(shí)踐之?dāng)?shù)據(jù)增值

整個(gè)大數(shù)據(jù)的系統(tǒng)，價(jià)值最大的部分，就在于數(shù)據(jù)增值，對(duì)于友盟來(lái)說，目前數(shù)據(jù)增值主要分兩個(gè)大的方向。

1、首先是內(nèi)部數(shù)據(jù)打通。

友盟實(shí)現(xiàn)了個(gè)性化“微”推送，基于用戶事件，結(jié)合用戶畫像、以及和阿里百川合作提供更多的維度信息，來(lái)為開發(fā)者提供更精準(zhǔn)的推送。
比如：對(duì)一個(gè)汽車電商類的 App，可以圈定一部分有車的用戶來(lái)推送汽車配件相關(guān)信息；然后圈定一部分無(wú)車用戶來(lái)推送售車相關(guān)信息。

2、友盟在數(shù)據(jù)挖掘方面做了很多工作。

友盟針對(duì)現(xiàn)有的設(shè)備，進(jìn)行了用戶畫像相關(guān)計(jì)算，通過用戶畫像能夠了解用戶的屬性和興趣，方便后續(xù)的數(shù)據(jù)橫向打通。同時(shí)我們提供了設(shè)備評(píng)級(jí)這個(gè)產(chǎn)品。這主要是針對(duì)一些作弊行為來(lái)設(shè)計(jì)的。比如說一些App，進(jìn)行推廣的時(shí)候會(huì)發(fā)現(xiàn)，有些渠道的推廣數(shù)據(jù)會(huì)有不真實(shí)的情況。

為此通過數(shù)據(jù)平臺(tái)的統(tǒng)計(jì)算法和機(jī)器學(xué)習(xí)算法，把我們現(xiàn)有的所有設(shè)備，進(jìn)行評(píng)級(jí)，哪些是垃圾設(shè)備，哪些是真實(shí)設(shè)備，能夠很好的識(shí)別出來(lái)。這樣一來(lái)，如果開發(fā)者有相關(guān)需求，我們可以提供設(shè)備評(píng)級(jí)相關(guān)指標(biāo)，來(lái)幫助開發(fā)者測(cè)評(píng)這些推廣渠道，到底哪些可信，哪些不可信。

圍繞著這些渠道刷量的問題，我們還推出了健康指數(shù)。設(shè)備評(píng)級(jí)產(chǎn)品，只是從設(shè)備和渠道的角度，來(lái)觀察作弊的問題；而健康指數(shù)是從一個(gè)App整體的角度來(lái)觀察作弊情況。