個推實戰(zhàn)分享：如何打造100億SDK累計覆蓋量的大數(shù)據(jù)系統(tǒng)

大數(shù)據(jù) 大數(shù)據(jù)系統(tǒng) 個推

個推 | 2016-08-05 16:25

【數(shù)據(jù)猿導讀】個推大數(shù)據(jù)系統(tǒng)面臨著數(shù)據(jù)存儲、日志傳輸、日志分析處理、大量任務調(diào)度和管理、數(shù)據(jù)分析處理服務高可用、海量多維度報表和快速響應分析和取數(shù)需求等方面的挑戰(zhàn)。這種情況下，這家企業(yè)是如何打造高覆蓋量的大數(shù)據(jù)系統(tǒng)呢

個推實戰(zhàn)分享：如何打造100億SDK累計覆蓋量的大數(shù)據(jù)系統(tǒng)

作為推送行業(yè)領導者，截止目前個推SDK累計安裝覆蓋量達100億(含海外)，接入應用超過43萬，獨立終端覆蓋超過10億 (含海外)。個推系統(tǒng)每天會產(chǎn)生大量的日志和數(shù)據(jù)，面臨許多數(shù)據(jù)處理方面的挑戰(zhàn)。

首先數(shù)據(jù)存儲方面，個推每天產(chǎn)生10TB以上的數(shù)據(jù)，并且累積數(shù)據(jù)已在PB級別。其次，作為推送技術服務商，個推有很多來自客戶和公司各部門的數(shù)據(jù)分析和統(tǒng)計需求，例如：消息推送和數(shù)據(jù)報表。雖然部分數(shù)據(jù)分析工作是離線模式，但開源數(shù)據(jù)處理系統(tǒng)穩(wěn)定性并不很高，保障數(shù)據(jù)分析服務的高可用性也是一個挑戰(zhàn)。另外，推送業(yè)務并不是單純的消息下發(fā)，它需幫助客戶通過數(shù)據(jù)分析把合適的內(nèi)容在合適的場景送達給合適的人,這要求系統(tǒng)支持數(shù)據(jù)挖掘，并保證數(shù)據(jù)實時性。最后，個推要求快速響應數(shù)據(jù)分析需求。因此，個推大數(shù)據(jù)系統(tǒng)面臨著數(shù)據(jù)存儲、日志傳輸、日志分析處理、大量任務調(diào)度和管理、數(shù)據(jù)分析處理服務高可用、海量多維度報表和快速響應分析和取數(shù)需求等方面的挑戰(zhàn)。

大數(shù)據(jù)系統(tǒng)演進之路

面臨諸多挑戰(zhàn)，個推大數(shù)據(jù)系統(tǒng)在逐步發(fā)展中不斷完善。其發(fā)展可分為三個階段。一是統(tǒng)計報表，即傳統(tǒng)意義的BI;二是大數(shù)據(jù)系統(tǒng)的基礎建設階段;三是工具、服務和產(chǎn)品化。

個推大數(shù)據(jù)系統(tǒng)演進第一階段：統(tǒng)計報表計算

早期由于數(shù)據(jù)處理無太復雜的需求，個推選擇幾臺高性能的機器，把所有數(shù)據(jù)分別放在這些機器上計算。只需在機器上多進程運行PHP或Shell腳本即可完成處理和統(tǒng)計。數(shù)據(jù)處理更多關注客戶今天推送多少條消息，某個推送任務有多少回執(zhí)等，執(zhí)行相對較簡單的報表。

此階段個推大數(shù)據(jù)系統(tǒng)的特點是，只需運維定時腳本傳輸?shù)街付ㄖ虚g節(jié)點;用戶雖然有億級別但日志種類較單一;只需使用PHP、Shell腳本來運行和數(shù)據(jù)只需短期保存(結果集長期保存、中間數(shù)據(jù)和原始數(shù)據(jù)保存很短時間)。

個推大數(shù)據(jù)系統(tǒng)演進第二階段：大數(shù)據(jù)基礎建設，離線批處理系統(tǒng)

2014年個推推出智能推送解決方案。用戶體量大的明星App接入，系統(tǒng)覆蓋用戶數(shù)爆增。且客戶接入個推系統(tǒng)后，提出了很多新的需求如：報表統(tǒng)計維度更豐富，它要求在數(shù)據(jù)量翻倍的情況下進行更復雜的計算，計算壓力增大。其次，智能推送本質(zhì)是數(shù)據(jù)深度挖掘，數(shù)據(jù)保存周期越長，覆蓋維度越多越好。

這樣的情況下，個推引進Hadoop生態(tài)體系，用HDFS基本解決存儲的問題，使用Hive做數(shù)據(jù)倉庫和離線分析,并且使用Mahout做機器學習。個推完成了由單機或多機模式向集群方向的轉變。整個運轉流程和原來類似，差別在于將日志傳輸?shù)街修D節(jié)點之后，使用hdfs命令put數(shù)據(jù)到hdfs，并添加hive表分區(qū)，然后對日志做進一步的處理，導入到數(shù)據(jù)倉儲里去。最后個推對數(shù)據(jù)倉庫中數(shù)據(jù)進行挖掘，給用戶打標簽，入庫到HBase和線上ES等。這是離線批處理系統(tǒng)的基本建設。

個推大數(shù)據(jù)系統(tǒng)演進第二階段：大數(shù)據(jù)基礎建設，實時處理系統(tǒng)

隨著業(yè)務不斷發(fā)展，需求也相應增加。如很多統(tǒng)計分析任務提出了要求在T+0的時間內(nèi)滿足，或者客戶上午推送的消息，下午要求給到反映推送效果的數(shù)據(jù)報表，而不能等到T+1的時間，這些需求都對數(shù)據(jù)處理實時性提出了更高要求。而且很多客戶會提出要檢索一些數(shù)據(jù)，或查看某種標簽相關數(shù)據(jù)，這類取數(shù)需要快速響應。于是個推對原有的架構進行了一些調(diào)整，引入了一個主要包含離線處理、實時處理和數(shù)據(jù)服務(包含檢索)的架構模式。

從上方看，原有的數(shù)據(jù)存到HDFS，使用Spark，MR等進行離線批處理。引入Kafka來解決日志收集問題，用Flume收集各個業(yè)務節(jié)點的日志，并寫入到Kafka集群，再依照業(yè)務的分級進行小時級別和秒級別處理。最終個推會落地一份數(shù)據(jù)，將它同步給業(yè)務線的DB或ES中使用。

基礎建設階段個推完成幾項工作：采用Lambda架構(Batch Layer、Speed Layer、ServingLayer);引入Hadoop(Hdfs、Hive/MR、Hbase、Mahout等);采用ES、SolrCloud+ HBase方案實現(xiàn)多維度檢索;引入Flume 、Kafka、Camus和優(yōu)化改造日志傳輸和引入和優(yōu)化國產(chǎn)開源的Redis集群方案-Codis 。

個推大數(shù)據(jù)系統(tǒng)演進第三階段：工具化+服務化+產(chǎn)品化

基礎建設過程中，個推發(fā)現(xiàn)雖有了整體框架，但依然不能比較便捷地響應業(yè)務方的需求。所以個推選擇提供工具給業(yè)務方，并增加一個服務代理層，也就是上圖紅色部分，把批處理任務等抽象成任務模板，配置到代理層，最終提給業(yè)務方調(diào)用，他們只要做簡單的二次開發(fā)，就可以使用個推集群的計算服務，提高業(yè)務開發(fā)速度。

這個階段，個推在架構上主要完成了以下工作：增加Job調(diào)度管理：引入Azkaban和進行改造(變量共享、多集群支持等);增加服務代理層：引入DataService和Job Proxy(開放給更多產(chǎn)品線使用并解耦);增加應用層：基于服務代理層研發(fā)相應的工具和取數(shù)產(chǎn)品。

個推大數(shù)據(jù)系統(tǒng)演進的經(jīng)驗與總結

第一，探索數(shù)據(jù)和理解數(shù)據(jù)是開發(fā)前必備工作。數(shù)據(jù)處理之前需要探索有哪些臟數(shù)據(jù)，這些臟數(shù)據(jù)的分布，以及無效數(shù)據(jù)和缺省情況的發(fā)現(xiàn)等。第二，數(shù)據(jù)存儲方案向分析和計算需要靠攏。可以考慮使用類似Carbondata等帶有索引的文件格式。第三，數(shù)據(jù)標準化是提高后續(xù)處理首要手段。絕大部分數(shù)據(jù)需要標準化后供給后續(xù)使用(基本清洗、統(tǒng)一內(nèi)部ID、增加必備屬性)，如對實時性數(shù)據(jù)，應先做標準化處理后，再發(fā)布到Kafka里，最后供所有其他實時系統(tǒng)做處理，減少常規(guī)清洗和轉化處理在多個業(yè)務中重復做，并且統(tǒng)一ID，便于和數(shù)據(jù)打通。第四，工具化、服務化、產(chǎn)品化提高整體效率。在開發(fā)層面可以將MR、Spark進行API封裝并且提供足夠的工具包。第五，大數(shù)據(jù)系統(tǒng)全鏈路監(jiān)控很重要。批處理監(jiān)控主要包括：日常任務運行時間監(jiān)控、是否出現(xiàn)傾斜、結果集每日曲線、異常數(shù)據(jù)曲線，GC監(jiān)控;流式處理監(jiān)控包括：原數(shù)據(jù)波動監(jiān)控、消費速率監(jiān)控報警、計算節(jié)點delay監(jiān)控等。

來源：個推

收藏分享

聲明：數(shù)據(jù)猿尊重媒體行業(yè)規(guī)范，相關內(nèi)容都會注明來源與作者；轉載我們原創(chuàng)內(nèi)容時，也請務必注明“來源：數(shù)據(jù)猿”與作者名稱，否則將會受到數(shù)據(jù)猿追責。