如何打造100億SDK累計覆蓋量的大資料系統

標籤：

作為推送行業領導者，截止目前個推SDK累計安裝覆蓋量達100億（含海外），接入應用超過43萬，獨立終端覆蓋超過10億 （含海外）。個推系統每天會產生大量的日誌和資料，面臨許多資料處理方面的挑戰。

首先資料存放區方面，個推每天產生10TB以上的資料，並且累積資料已在PB層級。其次，作為推送技術服務商，個推有很多來自客戶和公司各部門的資料分析和統計需求，例如：訊息推送和資料報表。雖然部分資料分析工作是離線模式，但開來源資料處理系統穩定性並不很高，保障資料分析服務的高可用性也是一個挑戰。另外，推送業務並不是單純的訊息下發，它需協助客戶通過資料分析把合適的內容在合適的情境送達給合適的人,這要求系統支援資料採礦，並保證資料即時性。最後，個推要求快速響應資料分析需求。因此，個推大資料系統面臨著資料存放區、日誌傳輸、日誌分析處理、大量任務調度和管理、資料分析處理服務高可用、海量多維度報表和快速響應分析和取數需求等方面的挑戰。

大資料系統演化之路

面臨諸多挑戰，個推大資料系統在逐步發展中不斷完善。其發展可分為三個階段。一是統計報表，即傳統意義的BI；二是大資料系統的基礎建設階段；三是工具、服務和產品化。

個推大資料系統演化第一階段：統計報表計算

 

早期由於資料處理無太複雜的需求，個推選擇幾台高效能的機器，把所有資料分別放在這些機器上計算。只需在機器上多進程運行PHP或Shell指令碼即可完成處理和統計。資料處理更多關注客戶今天推送多少條訊息，某個推送任務有多少回執等，執行相對較簡單的報表。

此階段個推大資料系統的特點是，只需營運定時指令碼傳輸到指定中間節點；使用者雖然有億層級但日誌種類較單一；只需使用PHP、Shell指令碼來運行和資料只需短期儲存（結果集長期儲存、中間資料和未經處理資料儲存很短時間）。

個推大資料系統演化第二階段：大資料基礎建設，離線批處理系統

 

2014年個推推出智能推送解決方案。使用者體量大的明星App接入，系統覆蓋使用者數爆增。且客戶接入個推系統後，提出了很多新的需求如：報表統計維度更豐富，它要求在資料量翻倍的情況下進行更複雜的計算，計算壓力增大。其次，智能推送本質是資料深度挖掘，資料儲存周期越長，覆蓋維度越多越好。

這樣的情況下，個推引進Hadoop生態體系，用HDFS基本解決儲存的問題，使用Hive做資料倉儲和離線分析,並且使用Mahout做機器學習。個推完成了由單機或多機模式向叢集方向的轉變。整個運轉流程和原來類似，差別在於將日誌傳輸到中轉節點之後，使用hdfs命令put資料到hdfs，並添加hive表分區，然後對日誌做進一步的處理，匯入到資料倉儲裡去。最後個推對資料倉儲中資料進行挖掘，給使用者打標籤，入庫到HBase和線上ES等。這是離線批處理系統的基本建設。

個推大資料系統演化第二階段：大資料基礎建設，即時處理系統

隨著業務不斷髮展，需求也相應增加。如很多統計分析任務提出了要求在T+0的時間內滿足，或者客戶上午推送的訊息，下午要求給到反映推送效果的資料報表，而不能等到T+1的時間，這些需求都對資料處理即時性提出了更高要求。而且很多客戶會提出要檢索一些資料，或查看某種標籤相關資料，這類取數需要快速響應。於是個推對原有的架構進行了一些調整，引入了一個主要包含離線處理、即時處理和資料服務（包含檢索）的架構模式。

 

從上方看，原有的資料存到HDFS，使用Spark，MR等進行離線批處理。引入Kafka來解決日誌收集問題，用Flume收集各個業務節點的日誌，並寫入到Kafka叢集，再依照業務的分級進行小時層級和秒層級處理。最終個推會落地一份資料，將它同步給業務線的DB或ES中使用。

基礎建設階段個推完成幾項工作：採用Lambda架構（Batch Layer、Speed Layer、ServingLayer）；引入Hadoop（Hdfs、Hive/MR、Hbase、Mahout等）；採用ES、SolrCloud+ HBase方案 實現多維度檢索；引入Flume 、Kafka、Camus和最佳化改造日誌傳輸和引入和最佳化國產開源的Redis叢集方案-Codis 。

個推大資料系統演化第三階段：工具化+服務化+產品化

 

基礎建設過程中，個推發現雖有了整體架構，但依然不能比較便捷地響應業務方的需求。所以個推選擇提供工具給業務方，並增加一個服務代理層，也就是紅色部分，把批處理任務等抽象成工作範本，配置到代理層，最終提給業務方調用，他們只要做簡單的二次開發，就可以使用個推叢集的計算服務，提高業務開發速度。

這個階段，個推在架構上主要完成了以下工作：增加Job調度管理：引入Azkaban和進行改造（變數共用、多叢集支援等）；增加服務代理層：引入DataService和Job Proxy(開放給更多產品線使用並解耦)；增加應用程式層：基於服務代理層研發相應的工具和取數產品。

個推大資料系統演化的經驗與總結

第一，探索資料和理解資料是開發前必備工作。資料處理之前需要探索有哪些髒資料，這些髒資料的分布，以及無效資料和預設情況的發現等。第二，資料存放區方案向分析和計算需要靠攏。可以考慮使用類似Carbondata等帶有索引的檔案格式。第三，資料標準化是提高後續處理首要手段。絕大部分資料需要標準化後供給後續使用（基本清洗、統一內部ID、增加必備屬性），如對即時性資料，應先做標準化處理後，再發布到Kafka裡，最後供所有其他即時系統做處理，減少常規清洗和轉化處理在多個業務中重複做，並且統一ID，便於和資料打通。第四，工具化、服務化、產品化提高整體效率。在開發層面可以將MR、Spark進行API封裝並且提供足夠的工具包。第五，大資料系統全鏈路監控很重要。批處理監控主要包括：日常任務已耗用時間監控、是否出現傾斜、結果集每日曲線、異常資料曲線，GC監控；串流監控包括：原資料波動監控、消費速率監控警示、計算節點delay監控等。

如何打造100億SDK累計覆蓋量的大資料系統