爱奇艺大数据分析平台的演进之路
首先講一下愛奇藝大數(shù)據(jù)平臺業(yè)務背景，目前日均DAU接近三億，愛奇藝在業(yè)務初期主要關(guān)注于長視頻，隨后發(fā)展業(yè)務有PPC、UPC，同時還發(fā)展了游戲、直播、小說等業(yè)務。目前業(yè)務線達到20多條，存量的設備信息達到30億，每天處理的用戶行為日志超過300T。這種業(yè)務數(shù)據(jù)量對數(shù)據(jù)運維、開發(fā)人員提出了很高的要求。
1. 起始時代
愛奇藝剛剛起步時平臺架構(gòu)很簡單，數(shù)據(jù)流從日志通過RSYNC流入到Hive，然后通過腳驅(qū)動Hive SQL語句統(tǒng)計分析，結(jié)果導入到MySQL，最后形成報表展示。整個流程的驅(qū)動基于Shell腳本完成，報表系統(tǒng)和數(shù)據(jù)處理是利用Java實現(xiàn)。然后進入第二階段，原先所有業(yè)務需求都是手工處理，所有報表都要寫Java代碼開發(fā)，這個給開發(fā)人員造成了很大的工作量，并且用戶獲取數(shù)據(jù)周期長，速度慢。
2. 魔鏡時代
因此開發(fā)了一個魔鏡系統(tǒng)。在魔鏡系統(tǒng)中進行投遞管理、投遞驗證，通過自研的日志收集器Accio Log將日志從Pingback服務器上傳到HDFS；再通過Transfiguration解析框架做日志格式轉(zhuǎn)化和分拆入庫。然后分析人員可以再魔鏡系統(tǒng)上通過配置進行自助取數(shù)，不再需要等待開發(fā)排期
但是隨著業(yè)務不斷發(fā)展，數(shù)據(jù)需求不斷增多，很快遇到了新的問題。開發(fā)魔鏡系統(tǒng)是由于需求較多開發(fā)人員處理不過來，現(xiàn)在是取數(shù)計算太多，Hadoop集群處理不過來。因為在魔鏡系統(tǒng)中消費的大多都是日志數(shù)據(jù)，數(shù)據(jù)量非常大，任務又多，導致集群計算壓力非常大。而且數(shù)據(jù)開發(fā)人員仍然是主要進行腳本開發(fā)，調(diào)度方式也不成體系。所以我們基于魔鏡系統(tǒng)的思路進行進一步設計，研發(fā)了大數(shù)據(jù)平臺“通天塔”系統(tǒng)。
3. 通天塔時代
通天塔集合了整個愛奇藝技術(shù)部門所有數(shù)據(jù)、所有計算資源和服務框架，重新構(gòu)建形成一個大數(shù)據(jù)平臺框架。底層是大數(shù)據(jù)平臺所用的計算資源，離線計算主要是Hive、Spark，流式計算主要是Spark Streaming和Flink；OLAP主要是Impala和Kylin。數(shù)據(jù)方面Pingback是用戶行為日志，機器日志就是程序產(chǎn)生的相關(guān)日志。線上數(shù)據(jù)庫主要是MySQL、MongoDB等，大數(shù)據(jù)存儲主要是HDFS、HBase、Kudu，Kudu主要是支持實時，分布式存儲主要是HBase、HDFS。再往上層是開發(fā)平臺層，主要負責工作流開發(fā)。流計算通過專門的開發(fā)工具進行管理，就是將任務開發(fā)進行重新構(gòu)建。數(shù)據(jù)開發(fā)針對于系統(tǒng)數(shù)據(jù)進行血緣管理，提供數(shù)據(jù)集成管理，實現(xiàn)數(shù)據(jù)在不同集群、引擎間的同步。如機房中有很多機器分成3-4個集群，相互之間要進行數(shù)據(jù)同步，先前主要是手寫程序完成,現(xiàn)在可以通過數(shù)據(jù)集成來進行跨DC的數(shù)據(jù)同步。數(shù)倉管理主要是埋點投遞管理、指標維度管理、數(shù)倉模型管理。最上層就是直接面向用戶的分析報表平臺，自助分析工具有漏斗分析、畫像分析、路徑分析，還有自助查詢工具、BI報表工具，接下來會詳細講解。
4. 工作流管理與開發(fā)方式的演變
接下來講一下工作流管理與開發(fā)方式的演變，剛開始的時候在這方面投入量不是很大，使用Crontab直接驅(qū)動數(shù)據(jù)處理腳本運行。隨著任務量逐漸增多，crontab會變得不可維護，就利用Shell寫了一個框架，可以自動批量維護很多計算。隨著業(yè)務發(fā)展又無法滿足需求，引入Linkedin公司的開源工作流調(diào)度器Azkaban。由于當時Azkaban只能單機，可維護性也不是很高，自研發(fā)了一個工作流管理系統(tǒng)Gear，但是Gear的管理基于配置文件，開發(fā)調(diào)試起來麻煩又自研了通天塔數(shù)據(jù)開發(fā)Babel BD。
Slytherin完全是一個Shell腳本，有一個驅(qū)動腳本和一個執(zhí)行腳本。驅(qū)動腳本主要是調(diào)動執(zhí)行腳本運行，并關(guān)注其運行生命周期，感知整個并發(fā)量，避免對集群造成過大的壓力。執(zhí)行腳本保證自己的唯一性，處理完成后打好標志文件，保證唯一性的方式就是記錄自己的process ID作為ID鎖，如果檢測自己有ID鎖存在，就不再重復執(zhí)行。隨著后續(xù)發(fā)展發(fā)現(xiàn)其可視化程度不高，維護成本大，于是引入了Azkaban，其優(yōu)點是使用簡單、開源、可視化程度很高，缺點是當年只能單機，在使用Azkaban時愛奇藝集群有3-4個，涉及的集群機器有上百臺，每個集群都會有很多臺入口Client機器，只能一臺機器一臺機器去維護，整體大局性控制不高。
基于上述缺點，云服務部門的同事著手開發(fā)Gear工作流管理。 這是一個基于appache的Oozie在上層進行二次開發(fā)的工具，沒有直接使用Oozie是由于其配置過于繁瑣，可視化不是很好。因此在Oozie基礎上進行配置簡化，并且提供更友好的界面和開發(fā)方式，主要是使用GitLab-CI和SDK的方式提交。上圖是一個并行的工作流，配置文件通過GitLab提交，Gitlab-CI會自動提交發(fā)布，然后實例化，同時會調(diào)用相應的API將計算過程進行監(jiān)控。
在開發(fā)過程中還是感覺配置Gear過程比較復雜，配置文件編寫容易出錯，平均需要提交三次調(diào)試三次才能成功執(zhí)行。因此在通天塔系統(tǒng)中進行進一步封裝，形成BabelBD開發(fā)IDE。BabelBD可以直接拖拽節(jié)點的方式開發(fā)工作流，這樣開發(fā)人員只需要關(guān)注核心SQL語句編寫和整個基礎流程，其他都交給IDE完成，上圖是實際開發(fā)效果和執(zhí)行效果。
報表制作最開始是開發(fā)人員寫代碼開發(fā)報表，后來是配置系統(tǒng)去配置報表，然后是讓用戶從自助系統(tǒng)和工具去自助發(fā)布報表，最后是生成一些個性化報告。最開始的報表系統(tǒng)是龍源報表系統(tǒng)，就是一個報表系統(tǒng)，幾乎沒有管理后臺，僅有用戶權(quán)限管理。其架構(gòu)是最基礎的MVC模式，開發(fā)的每一張報表都是一個小的JavaWeb項目。需要為每一張報表編寫JSP頁面，隨著業(yè)務量增加，開發(fā)人員任務加重，因此將報表配置抽象化。形成一個報表配置平臺-龍源2.0，配置流程最核心的就是寫SQL，定義相關(guān)圖表信息、條件信息，將其配置成一張報表。最后利用bootstrap的一個可視化配置管理工具，通過拖拽方式搭建報表。由于業(yè)務線發(fā)展，愛奇藝發(fā)展成為一個多元平臺，各種業(yè)務層出不窮，先前一體化的報表模式不能滿足需求，大BI系統(tǒng)應運而生。
5. 愛奇藝BI
愛奇藝BI平臺是一個很大的平臺系統(tǒng)，報表只是其中的一部分，最核心的部分就是對不同業(yè)務線進行拆分。在前期的基礎上，配置方式進一步抽象，思路也進行了變更。之前從SQL語句開始配置是基于開發(fā)的思路，現(xiàn)在是從報表構(gòu)建的思路去配置，先配置報表的雛形，然后詳細配置報表的各個組件，這種方式更加符合數(shù)據(jù)分析者的思路。
愛奇藝BI核心不在報表開發(fā)，核心在于業(yè)務線劃分以及權(quán)限的劃分。數(shù)據(jù)安全越來越重要，在業(yè)務線和權(quán)限方面做了很多工作。除了開發(fā)人員開發(fā)報表外，還可以讓用戶通過一些自助分析的系統(tǒng)發(fā)布自己的報表到BI進行展示。
在消費數(shù)據(jù)時有個很重要的一點就是要保證數(shù)據(jù)是可用的，有時我們會去猜測數(shù)據(jù)在某一時刻是完整的，但是如果某一集群發(fā)生延遲，就會消費掉一個空數(shù)據(jù)。因此設置了Done文件機制。將Done文件放到HDFS上，每生成一個表都有相應的Done文件，每當消費某張數(shù)據(jù)表都會先檢測其Done文件是否存在。HDFS很怕小文件，但是每個表每天都會有若干done文件產(chǎn)生，而且表非常多，就會有海量空文件產(chǎn)生。所以為了避免HDFS壓力過大，我們就制作了Done服務，這樣直接在做依賴判斷的時候，直接使用Done服務，不再在HDFS上查找，依賴管理最終采用的方案是數(shù)據(jù)管理。
數(shù)據(jù)管理會將數(shù)據(jù)的整個生命周期管理起來，對數(shù)據(jù)進行可用性管理并提供服務給其他業(yè)務調(diào)用，用來替代Done服務。它通過元數(shù)據(jù)抓取、手動錄入、投遞注冊管理、外部系統(tǒng)注冊管理，通過數(shù)據(jù)血緣分析、數(shù)據(jù)標注、數(shù)據(jù)生命周期分析等對各種元數(shù)據(jù)進行系統(tǒng)性管理。
接下來講一下我們的數(shù)據(jù)倉庫演變，最開始的時候我們的分析統(tǒng)計都是直接消費日志表，所有報表結(jié)果都是從日志表中計算產(chǎn)生，產(chǎn)生的結(jié)果是造成資源浪費，并且定義不清楚，缺乏周知性。接著就針對視頻播放設計了播放數(shù)倉模型，制作了中間大寬表，方便使用。但是對于有些簡單表或者其他一些條件不適用，目前采用分層建模的方式。
直接消費日志表優(yōu)點是最底層、簡單，數(shù)據(jù)原始，無任何聚合處理，可以探查細節(jié)，缺點就是數(shù)據(jù)量大，消耗計算資源大，未進行反刷量。中間大寬表就是按照一定的主題進行聚合，盡量使用最全面的字段盡量方便使用；同時也進行了反刷量過濾，只有少量數(shù)據(jù)會用到日志，大寬表有個缺點就是數(shù)據(jù)量不適合在Impala等OLAP引擎使用。分層建模有日志層、明細層、聚合層、應用層，不同主題都在聚合層，根據(jù)不同的應用場景會上升到應用層構(gòu)建。明細層和日志層利用魔鏡和SQL語句進行管理查詢，應用層針對BI報表和莫奈系統(tǒng)，日志層默認不開放，業(yè)務簡單時會開放查詢。
基于上述需求使用了一些數(shù)倉工具，主要負責數(shù)倉模型管理，其核心是指標維度管理，基于指標維度進行數(shù)據(jù)開發(fā)，然后進行一些分析，尤其是莫奈系統(tǒng)中利用指標維度統(tǒng)一的標準信息制作場景和場景間關(guān)聯(lián)，在BI報表直接引用指標維度信息制作報表。
OLAP在數(shù)倉的上一層，最開始只使用MySQL，通過分庫分表來解決大數(shù)據(jù)量問題；之后就借助MySQL+HBase，將一部分數(shù)據(jù)提前計算好存入HBase,根據(jù)不同的查詢進行提取。接著就引入Kylin/Impala作為查詢引擎，目前考慮的是不同框架綜合使用，不局限于一個查詢，根據(jù)分析目標數(shù)據(jù)源不同，智能選擇不同的引擎。
一個典型的例子就是劇集統(tǒng)計，愛奇藝有海量視頻數(shù)據(jù)，剛開始是幾十萬，現(xiàn)在是一億+的視頻資源。原先按可加項不可加項分表，分表維度也有很多（來源、提供商），隨著視頻量增加這種方式無法滿足需求，查詢速度很慢。接著采用冷熱數(shù)據(jù)分表，保證日常最常用數(shù)據(jù)的查詢速度，數(shù)據(jù)按天、月、年進行分表。后來考慮將一部分數(shù)據(jù)存入HBase中，每天會進行播放數(shù)據(jù)排行計算，最難的也是計算排行，將不同組合的排行數(shù)據(jù)預先組合計算存入HBase中。接著將所有數(shù)據(jù)都存入HBase中，這種思想就是Kylin思想，將不同維度組合提前算好存入HBase，這樣就可以提供給自助查詢系統(tǒng)使用。
6. 魔鏡與庖丁刃
前面主要講報表，接下來講一下分析人員和運維人員取數(shù)分析方式的變化。最開始是運營人員提出數(shù)據(jù)需求，首先看報表是否滿足，滿足直接查報表，不滿足作為臨時報表讓開發(fā)人員完成報表取數(shù)。這種方式工作量大、周期長，后來用戶通過魔鏡看結(jié)果或者運行SQL，如果魔鏡不滿足再去看報表或者開發(fā)。目前和未來思想就是先看報表是不是滿足，不滿足提供專門的分析工具，如漏斗分析、畫像分析去定制化分析需求，再不滿足通過OLAP分析進行拖拽式分析，或者通過魔鏡去寫SQL，生成結(jié)果后看是否滿足，是否需要進一步分析，如果需要就回到OLAP系統(tǒng)進行分析。
整體的思路是最開始靠人工，分析師通過人工導數(shù)、Excel分析等工具進行分析。后來發(fā)展為主要依據(jù)魔鏡進行報表導數(shù)，后續(xù)分析主要還是Excel等其他分析工具。現(xiàn)在是將用戶往莫奈分析系統(tǒng)上引導，后續(xù)是希望去掉像Excel等其他分析工具，所有分析都在莫奈系統(tǒng)中完成。魔鏡是通過勾選配置的方式寫SQL達到取數(shù)的目的，通過定義指標、選取維度、定義詳細的條件、排序方式，通過勾選方式生成SQL，最后落在SQL執(zhí)行的引擎上。庖丁刃就是提供給用戶一個SQL編輯的工具，同時還提供一些數(shù)據(jù)源的管理。魔鏡和庖丁刃是一個相相成的工具，庖丁刃的SQL不一定能轉(zhuǎn)化為魔鏡的定制計算，但是魔鏡的定制計算一定能轉(zhuǎn)化為庖丁刃的SQL。
庖丁刃的技術(shù)架構(gòu)，上層網(wǎng)頁層是SQL編輯器以及魔鏡定制計算的界面。服務器會根據(jù)不同的數(shù)據(jù)源路由到不同的執(zhí)行引擎上執(zhí)行，同時會進行權(quán)限的驗證。最下層是實際SQL執(zhí)行引擎，可以依據(jù)不同數(shù)據(jù)特點智能選擇不同的引擎，并且根據(jù)執(zhí)行情況進行智能下沉。如Impala滿足不了會直接下沉到Spark，分為兩種一種是Impala沒有數(shù)據(jù)，另一種是Impala執(zhí)行失敗。整個架構(gòu)構(gòu)建在企業(yè)云計算架構(gòu)上，全部微服務化，這樣易于監(jiān)控和維護不容易掛掉。
孔明計算引擎是提供數(shù)據(jù)查詢的統(tǒng)一接口，實施智能選擇執(zhí)行引擎的一個工具。在執(zhí)行的時候?qū)崿F(xiàn)智能下沉，確保計算的可靠性。在SQL解析開始后進行權(quán)限驗證，依據(jù)SQL解析后數(shù)據(jù)源的結(jié)果進行引擎路由。目前如果不同數(shù)據(jù)源數(shù)據(jù)存在關(guān)聯(lián)會出現(xiàn)報錯，未來會開發(fā)底層觸發(fā)自動同步維護。
7. 莫奈系統(tǒng)
莫奈系統(tǒng)目標是只需鼠標如作畫般劃過屏幕，即可進行大數(shù)據(jù)分析，將抽象數(shù)據(jù)變成畫作。上圖是莫奈系統(tǒng)界面，給出的是事先制作好的報表進行的展示，可以直接將其發(fā)布到BI系統(tǒng)。將相應維度拖到工作區(qū)，支持不同行列的維度；同時還支持不同的圖形可視化方式；支持下載Excel數(shù)據(jù)，后續(xù)將其去掉采用生成報告的方式。后臺是場景分析配置，每一個場景是根據(jù)數(shù)倉應用層進行的進一步抽象，將維度和指標全部抽象成場景配置到系統(tǒng)中去。
在普通場景基礎上支持多分析場景的自動組合，將已經(jīng)定義好的場景合并到一起，同樣的字段進行合并形成一個新的大場景。組合場景會根據(jù)用戶的勾選和當前場景維護情況自動生成查詢，并判斷當前條件維度選擇是否滿足需求。
莫奈系統(tǒng)架構(gòu)，最上層的展現(xiàn)層是基于定義去開發(fā)的前后端系統(tǒng)，網(wǎng)關(guān)層網(wǎng)關(guān)相關(guān)配置，接下來的權(quán)限控制、DSL邏輯、SQL層等都是微服務。最底層的查詢引擎用的最多就是Kylin，MySQL和IMPALA在系統(tǒng)中也可用，實現(xiàn)MySQL和Kylin并行使用。如果用戶需要對BI報表進行進一步分析，可以將報表數(shù)據(jù)直接拉到莫奈系統(tǒng)中進行進一步分析，當數(shù)據(jù)量過大時可以將MySQL下沉到IMPALA中執(zhí)行。
8. 愛奇藝大數(shù)據(jù)分析體系
上圖中的任務構(gòu)成愛奇藝大數(shù)據(jù)分析體系，上層是BI報表、莫奈分析、魔鏡與庖丁刃、分析工具。
BI報表：BI報表直接查看報告結(jié)果，定制自己的報告；
莫奈分析：拖拽式數(shù)據(jù)可視化分析工具；
魔鏡與庖丁刃：離線取數(shù)，SQL分析工具；
分析工具：留存，漏斗，路徑，畫像等分析工具。
作者介紹
杜益凡，愛奇藝****商業(yè)智能部高級技術(shù)經(jīng)理，畢業(yè)于南京大學，2010年加入愛奇藝，專注于大數(shù)據(jù)相關(guān)技術(shù)，負責愛奇藝大數(shù)據(jù)處理平臺和大數(shù)據(jù)分析產(chǎn)品方面的研發(fā)，對Hadoop及其相關(guān)生態(tài)工具有深入的研究和豐富的應用實踐經(jīng)驗。
本文來自杜益凡在 DataFun 社區(qū)的演講，由 DataFun 編輯整理。
總結(jié)
以上是生活随笔為你收集整理的爱奇艺大数据分析平台的演进之路的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： hyperledge工具-cryptog
- 下一篇： 数组随机排列