作為推送行業(yè)領(lǐng)導(dǎo)者，截止目前個(gè)推SDK累計(jì)安裝覆蓋量達(dá)100億（含海外），接入應(yīng)用超過(guò)43萬(wàn)，獨(dú)立終端覆蓋超過(guò)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è)推有很多來(lái)自客戶和公司各部門(mén)的數(shù)據(jù)分析和統(tǒng)計(jì)需求，例如：消息推送技術(shù)和數(shù)據(jù)報(bào)表。雖然部分?jǐn)?shù)據(jù)分析工作是離線模式，但開(kāi)源數(shù)據(jù)處理系統(tǒng)穩(wěn)定性并不很高，保障數(shù)據(jù)分析服務(wù)的高可用性也是一個(gè)挑戰(zhàn)。另外，推送業(yè)務(wù)并不是單純的消息下發(fā)，它需幫助客戶通過(guò)數(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ù)處理無(wú)太復(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í)別但日志種類(lèi)較單一；只需使用PHP、Shell腳本來(lái)運(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ǔ)的問(wèn)題，使用Hive做數(shù)據(jù)倉(cāng)庫(kù)和離線分析,并且使用Mahout做機(jī)器學(xué)習(xí)。個(gè)推完成了由單機(jī)或多機(jī)模式向集群方向的轉(zhuǎn)變。整個(gè)運(yùn)轉(zhuǎn)流程和原來(lái)類(lèi)似，差別在于將日志傳輸?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ù)，這類(lèi)取數(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來(lái)解決日志收集問(wèn)題，用Flume收集各個(gè)業(yè)務(wù)節(jié)點(diǎn)的日志，并寫(xiě)入到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)開(kāi)源的Redis集群方案-Codis 。
個(gè)推大數(shù)據(jù)系統(tǒng)演進(jìn)第三階段：工具化+服務(wù)化+產(chǎn)品化
基礎(chǔ)建設(shè)過(guò)程中，個(gè)推發(fā)現(xiàn)雖有了整體框架，但依然不能比較便捷地響應(yīng)業(yè)務(wù)方的需求。所以個(gè)推選擇提供工具給業(yè)務(wù)方，并增加一個(gè)服務(wù)代理層，也就是上圖紅色部分，把批處理任務(wù)等抽象成任務(wù)模板，配置到代理層，最終提給業(yè)務(wù)方調(diào)用，他們只要做簡(jiǎn)單的二次開(kāi)發(fā)，就可以使用個(gè)推集群的計(jì)算服務(wù)，提高業(yè)務(wù)開(kāi)發(fā)速度。
這個(gè)階段，個(gè)推在架構(gòu)上主要完成了以下工作：增加Job調(diào)度管理：引入Azkaban和進(jìn)行改造（變量共享、多集群支持等）；增加服務(wù)代理層：引入DataService和Job Proxy(開(kāi)放給更多產(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ù)是開(kāi)發(fā)前必備工作。數(shù)據(jù)處理之前需要探索有哪些臟數(shù)據(jù)，這些臟數(shù)據(jù)的分布，以及無(wú)效數(shù)據(jù)和缺省情況的發(fā)現(xiàn)等。第二，數(shù)據(jù)存儲(chǔ)方案向分析和計(jì)算需要靠攏。可以考慮使用類(lèi)似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)品化提高整體效率。在開(kāi)發(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)控等。
