作為推送行業(yè)領(lǐng)導(dǎo)者,截止目前個(gè)推SDK累計(jì)安裝覆蓋量達(dá)100億(含海外),接入應(yīng)用超過43萬,獨(dú)立終端覆蓋超過10億 (含海外)。個(gè)推系統(tǒng)每天會(huì)產(chǎn)生大量的日志和數(shù)據(jù),面臨許多數(shù)據(jù)處理方面的挑戰(zhàn)。
首先數(shù)據(jù)存儲(chǔ)方面,個(gè)推每天產(chǎn)生10TB以上的數(shù)據(jù),并且累積數(shù)據(jù)已在PB級(jí)別。其次,作為推送技術(shù)服務(wù)商,個(gè)推有很多來自客戶和公司各部門的數(shù)據(jù)分析和統(tǒng)計(jì)需求,例如:消息推送技術(shù)和數(shù)據(jù)報(bào)表。雖然部分?jǐn)?shù)據(jù)分析工作是離線模式,但開源數(shù)據(jù)處理系統(tǒng)穩(wěn)定性并不很高,保障數(shù)據(jù)分析服務(wù)的高可用性也是一個(gè)挑戰(zhàn)。另外,推送業(yè)務(wù)并不是單純的消息下發(fā),它需幫助客戶通過數(shù)據(jù)分析把合適的內(nèi)容在合適的場(chǎng)景送達(dá)給合適的人,這要求系統(tǒng)支持?jǐn)?shù)據(jù)挖掘,并保證數(shù)據(jù)實(shí)時(shí)性。最后,個(gè)推要求快速響應(yīng)數(shù)據(jù)分析需求。因此,個(gè)推大數(shù)據(jù)系統(tǒng)面臨著數(shù)據(jù)存儲(chǔ)、日志傳輸、日志分析處理、大量任務(wù)調(diào)度和管理、數(shù)據(jù)分析處理服務(wù)高可用、海量多維度報(bào)表和快速響應(yīng)分析和取數(shù)需求等方面的挑戰(zhàn)。
大數(shù)據(jù)系統(tǒng)演進(jìn)之路
面臨諸多挑戰(zhàn),個(gè)推大數(shù)據(jù)系統(tǒng)在逐步發(fā)展中不斷完善。其發(fā)展可分為三個(gè)階段。一是統(tǒng)計(jì)報(bào)表,即傳統(tǒng)意義的BI;二是大數(shù)據(jù)系統(tǒng)的基礎(chǔ)建設(shè)階段;三是工具、服務(wù)和產(chǎn)品化。
個(gè)推大數(shù)據(jù)系統(tǒng)演進(jìn)第一階段:統(tǒng)計(jì)報(bào)表計(jì)算
早期由于數(shù)據(jù)處理無太復(fù)雜的需求,個(gè)推選擇幾臺(tái)高性能的機(jī)器,把所有數(shù)據(jù)分別放在這些機(jī)器上計(jì)算。只需在機(jī)器上多進(jìn)程運(yùn)行PHP或Shell腳本即可完成處理和統(tǒng)計(jì)。數(shù)據(jù)處理更多關(guān)注客戶今天推送多少條消息,某個(gè)推送任務(wù)有多少回執(zhí)等,執(zhí)行相對(duì)較簡(jiǎn)單的報(bào)表。
此階段個(gè)推大數(shù)據(jù)系統(tǒng)的特點(diǎn)是,只需運(yùn)維定時(shí)腳本傳輸?shù)街付ㄖ虚g節(jié)點(diǎn);用戶雖然有億級(jí)別但日志種類較單一;只需使用PHP、Shell腳本來運(yùn)行和數(shù)據(jù)只需短期保存(結(jié)果集長(zhǎng)期保存、中間數(shù)據(jù)和原始數(shù)據(jù)保存很短時(shí)間)。
個(gè)推大數(shù)據(jù)系統(tǒng)演進(jìn)第二階段:大數(shù)據(jù)基礎(chǔ)建設(shè),離線批處理系統(tǒng)
2014年個(gè)推推出智能推送解決方案。用戶體量大的明星App接入,系統(tǒng)覆蓋用戶數(shù)爆增。且客戶接入個(gè)推系統(tǒng)后,提出了很多新的需求如:報(bào)表統(tǒng)計(jì)維度更豐富,它要求在數(shù)據(jù)量翻倍的情況下進(jìn)行更復(fù)雜的計(jì)算,計(jì)算壓力增大。其次,智能推送本質(zhì)是數(shù)據(jù)深度挖掘,數(shù)據(jù)保存周期越長(zhǎng),覆蓋維度越多越好。
這樣的情況下,個(gè)推引進(jìn)Hadoop生態(tài)體系,用HDFS基本解決存儲(chǔ)的問題,使用Hive做數(shù)據(jù)倉(cāng)庫(kù)和離線分析,并且使用Mahout做機(jī)器學(xué)習(xí)。個(gè)推完成了由單機(jī)或多機(jī)模式向集群方向的轉(zhuǎn)變。整個(gè)運(yùn)轉(zhuǎn)流程和原來類似,差別在于將日志傳輸?shù)街修D(zhuǎn)節(jié)點(diǎn)之后,使用hdfs命令put數(shù)據(jù)到hdfs,并添加hive表分區(qū),然后對(duì)日志做進(jìn)一步的處理,導(dǎo)入到數(shù)據(jù)倉(cāng)儲(chǔ)里去。最后個(gè)推對(duì)數(shù)據(jù)倉(cāng)庫(kù)中數(shù)據(jù)進(jìn)行挖掘,給用戶打標(biāo)簽,入庫(kù)到HBase和線上ES等。這是離線批處理系統(tǒng)的基本建設(shè)。
個(gè)推大數(shù)據(jù)系統(tǒng)演進(jìn)第二階段:大數(shù)據(jù)基礎(chǔ)建設(shè),實(shí)時(shí)處理系統(tǒng)
隨著業(yè)務(wù)不斷發(fā)展,需求也相應(yīng)增加。如很多統(tǒng)計(jì)分析任務(wù)提出了要求在T+0的時(shí)間內(nèi)滿足,或者客戶上午推送的消息,下午要求給到反映推送效果的數(shù)據(jù)報(bào)表,而不能等到T+1的時(shí)間,這些需求都對(duì)數(shù)據(jù)處理實(shí)時(shí)性提出了更高要求。而且很多客戶會(huì)提出要檢索一些數(shù)據(jù),或查看某種標(biāo)簽相關(guān)數(shù)據(jù),這類取數(shù)需要快速響應(yīng)。于是個(gè)推對(duì)原有的架構(gòu)進(jìn)行了一些調(diào)整,引入了一個(gè)主要包含離線處理、實(shí)時(shí)處理和數(shù)據(jù)服務(wù)(包含檢索)的架構(gòu)模式。
從上方看,原有的數(shù)據(jù)存到HDFS,使用Spark,MR等進(jìn)行離線批處理。引入Kafka來解決日志收集問題,用Flume收集各個(gè)業(yè)務(wù)節(jié)點(diǎn)的日志,并寫入到Kafka集群,再依照業(yè)務(wù)的分級(jí)進(jìn)行小時(shí)級(jí)別和秒級(jí)別處理。最終個(gè)推會(huì)落地一份數(shù)據(jù),將它同步給業(yè)務(wù)線的DB或ES中使用。
基礎(chǔ)建設(shè)階段個(gè)推完成幾項(xiàng)工作:采用Lambda架構(gòu)(Batch Layer、Speed Layer、ServingLayer);引入Hadoop(Hdfs、Hive/MR、Hbase、Mahout等);采用ES、SolrCloud+ HBase方案 實(shí)現(xiàn)多維度檢索;引入Flume 、Kafka、Camus和優(yōu)化改造日志傳輸和引入和優(yōu)化國(guó)產(chǎn)開源的Redis集群方案-Codis 。
個(gè)推大數(shù)據(jù)系統(tǒng)演進(jìn)第三階段:工具化+服務(wù)化+產(chǎn)品化
基礎(chǔ)建設(shè)過程中,個(gè)推發(fā)現(xiàn)雖有了整體框架,但依然不能比較便捷地響應(yīng)業(yè)務(wù)方的需求。所以個(gè)推選擇提供工具給業(yè)務(wù)方,并增加一個(gè)服務(wù)代理層,也就是上圖紅色部分,把批處理任務(wù)等抽象成任務(wù)模板,配置到代理層,最終提給業(yè)務(wù)方調(diào)用,他們只要做簡(jiǎn)單的二次開發(fā),就可以使用個(gè)推集群的計(jì)算服務(wù),提高業(yè)務(wù)開發(fā)速度。
這個(gè)階段,個(gè)推在架構(gòu)上主要完成了以下工作:增加Job調(diào)度管理:引入Azkaban和進(jìn)行改造(變量共享、多集群支持等);增加服務(wù)代理層:引入DataService和Job Proxy(開放給更多產(chǎn)品線使用并解耦);增加應(yīng)用層:基于服務(wù)代理層研發(fā)相應(yīng)的工具和取數(shù)產(chǎn)品。
個(gè)推大數(shù)據(jù)系統(tǒng)演進(jìn)的經(jīng)驗(yàn)與總結(jié)
第一,探索數(shù)據(jù)和理解數(shù)據(jù)是開發(fā)前必備工作。數(shù)據(jù)處理之前需要探索有哪些臟數(shù)據(jù),這些臟數(shù)據(jù)的分布,以及無效數(shù)據(jù)和缺省情況的發(fā)現(xiàn)等。第二,數(shù)據(jù)存儲(chǔ)方案向分析和計(jì)算需要靠攏?梢钥紤]使用類似Carbondata等帶有索引的文件格式。第三,數(shù)據(jù)標(biāo)準(zhǔn)化是提高后續(xù)處理首要手段。絕大部分?jǐn)?shù)據(jù)需要標(biāo)準(zhǔn)化后供給后續(xù)使用(基本清洗、統(tǒng)一內(nèi)部ID、增加必備屬性),如對(duì)實(shí)時(shí)性數(shù)據(jù),應(yīng)先做標(biāo)準(zhǔn)化處理后,再發(fā)布到Kafka里,最后供所有其他實(shí)時(shí)系統(tǒng)做處理,減少常規(guī)清洗和轉(zhuǎn)化處理在多個(gè)業(yè)務(wù)中重復(fù)做,并且統(tǒng)一ID,便于和數(shù)據(jù)打通。第四,工具化、服務(wù)化、產(chǎn)品化提高整體效率。在開發(fā)層面可以將MR、Spark進(jìn)行API封裝并且提供足夠的工具包。第五,大數(shù)據(jù)系統(tǒng)全鏈路監(jiān)控很重要。批處理監(jiān)控主要包括:日常任務(wù)運(yùn)行時(shí)間監(jiān)控、是否出現(xiàn)傾斜、結(jié)果集每日曲線、異常數(shù)據(jù)曲線,GC監(jiān)控;流式處理監(jiān)控包括:原數(shù)據(jù)波動(dòng)監(jiān)控、消費(fèi)速率監(jiān)控報(bào)警、計(jì)算節(jié)點(diǎn)delay監(jiān)控等。