導(dǎo)讀：首先講一下愛奇藝大數(shù)據(jù)平臺業(yè)務(wù)背景，目前日均DAU接近三億，愛奇藝在業(yè)務(wù)初期主要關(guān)注于長視頻，隨后發(fā)展業(yè)務(wù)有PPC、UPC，同時還發(fā)展了游戲、直播、小說等業(yè)務(wù)。目前業(yè)務(wù)線達(dá)到20多條，存量的設(shè)備信息達(dá)到30億，每天處理的用戶行為日志超過300T。這種業(yè)務(wù)數(shù)據(jù)量對數(shù)據(jù)運維、開發(fā)人員提出了很高的要求。

01

起始時代

愛奇藝剛剛起步時平臺架構(gòu)很簡單，數(shù)據(jù)流從日志通過RSYNC流入到Hive，然后通過腳驅(qū)動Hive SQL語句統(tǒng)計分析，結(jié)果導(dǎo)入到MySQL，最后形成報表展示。整個流程的驅(qū)動基于Shell腳本完成，報表系統(tǒng)和數(shù)據(jù)處理是利用Java實現(xiàn)。然后進(jìn)入第二階段，原先所有業(yè)務(wù)需求都是手工處理，所有報表都要寫Java代碼開發(fā)，這個給開發(fā)人員造成了很大的工作量，并且用戶獲取數(shù)據(jù)周期長，速度慢。

—

02

魔鏡時代

因此開發(fā)了一個魔鏡系統(tǒng)。在魔鏡系統(tǒng)中進(jìn)行投遞管理、投遞驗證，通過自研的日志收集器Accio Log將日志從Pingback服務(wù)器上傳到HDFS；再通過Transfiguration解析框架做日志格式轉(zhuǎn)化和分拆入庫。然后分析人員可以再魔鏡系統(tǒng)上通過配置進(jìn)行自助取數(shù)，不再需要等待開發(fā)排期

但是隨著業(yè)務(wù)不斷發(fā)展，數(shù)據(jù)需求不斷增多，很快遇到了新的問題。開發(fā)魔鏡系統(tǒng)是由于需求較多開發(fā)人員處理不過來，現(xiàn)在是取數(shù)計算太多，Hadoop集群處理不過來。因為在魔鏡系統(tǒng)中消費的大多都是日志數(shù)據(jù)，數(shù)據(jù)量非常大，任務(wù)又多，導(dǎo)致集群計算壓力非常大。而且數(shù)據(jù)開發(fā)人員仍然是主要進(jìn)行腳本開發(fā)，調(diào)度方式也不成體系。所以我們基于魔鏡系統(tǒng)的思路進(jìn)行進(jìn)一步設(shè)計，研發(fā)了大數(shù)據(jù)平臺“通天塔”系統(tǒng)。

—

03

通天塔時代

通天塔集合了整個愛奇藝技術(shù)部門所有數(shù)據(jù)、所有計算資源和服務(wù)框架，重新構(gòu)建形成一個大數(shù)據(jù)平臺框架。底層是大數(shù)據(jù)平臺所用的計算資源，離線計算主要是Hive、Spark，流式計算主要是Spark Streaming和Flink；OLAP主要是Impala和Kylin。數(shù)據(jù)方面Pingback是用戶行為日志，機(jī)器日志就是程序產(chǎn)生的相關(guān)日志。線上數(shù)據(jù)庫主要是MySQL、MongoDB等，大數(shù)據(jù)存儲主要是HDFS、HBase、Kudu，Kudu主要是支持實時，分布式存儲主要是HBase、HDFS。再往上層是開發(fā)平臺層，主要負(fù)責(zé)工作流開發(fā)。流計算通過專門的開發(fā)工具進(jìn)行管理，就是將任務(wù)開發(fā)進(jìn)行重新構(gòu)建。數(shù)據(jù)開發(fā)針對于系統(tǒng)數(shù)據(jù)進(jìn)行血緣管理，提供數(shù)據(jù)集成管理，實現(xiàn)數(shù)據(jù)在不同集群、引擎間的同步。如機(jī)房中有很多機(jī)器分成3-4個集群，相互之間要進(jìn)行數(shù)據(jù)同步，先前主要是手寫程序完成,現(xiàn)在可以通過數(shù)據(jù)集成來進(jìn)行跨DC的數(shù)據(jù)同步。數(shù)倉管理主要是埋點投遞管理、指標(biāo)維度管理、數(shù)倉模型管理。最上層就是直接面向用戶的分析報表平臺，自助分析工具有漏斗分析、畫像分析、路徑分析，還有自助查詢工具、BI報表工具，接下來會詳細(xì)講解。

—

04

工作流管理與開發(fā)方式的演變

接下來講一下工作流管理與開發(fā)方式的演變，剛開始的時候在這方面投入量不是很大，使用Crontab直接驅(qū)動數(shù)據(jù)處理腳本運行。隨著任務(wù)量逐漸增多，crontab會變得不可維護(hù)，就利用Shell寫了一個框架，可以自動批量維護(hù)很多計算。隨著業(yè)務(wù)發(fā)展又無法滿足需求，引入Linkedin公司的開源工作流調(diào)度器Azkaban。由于當(dāng)時Azkaban只能單機(jī)，可維護(hù)性也不是很高，自研發(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í)行腳本保證自己的唯一性，處理完成后打好標(biāo)志文件，保證唯一性的方式就是記錄自己的process ID作為ID鎖，如果檢測自己有ID鎖存在，就不再重復(fù)執(zhí)行。隨著后續(xù)發(fā)展發(fā)現(xiàn)其可視化程度不高，維護(hù)成本大，于是引入了Azkaban，其優(yōu)點是使用簡單、開源、可視化程度很高，缺點是當(dāng)年只能單機(jī)，在使用Azkaban時愛奇藝集群有3-4個，涉及的集群機(jī)器有上百臺，每個集群都會有很多臺入口Client機(jī)器，只能一臺機(jī)器一臺機(jī)器去維護(hù)，整體大局性控制不高。

基于上述缺點，云服務(wù)部門的同事著手開發(fā)Gear工作流管理。 這是一個基于appache的Oozie在上層進(jìn)行二次開發(fā)的工具，沒有直接使用Oozie是由于其配置過于繁瑣，可視化不是很好。因此在Oozie基礎(chǔ)上進(jìn)行配置簡化，并且提供更友好的界面和開發(fā)方式，主要是使用GitLab-CI和SDK的方式提交。上圖是一個并行的工作流，配置文件通過GitLab提交，Gitlab-CI會自動提交發(fā)布，然后實例化，同時會調(diào)用相應(yīng)的API將計算過程進(jìn)行監(jiān)控。

在開發(fā)過程中還是感覺配置Gear過程比較復(fù)雜，配置文件編寫容易出錯，平均需要提交三次調(diào)試三次才能成功執(zhí)行。因此在通天塔系統(tǒng)中進(jìn)行進(jìn)一步封裝，形成BabelBD開發(fā)IDE。BabelBD可以直接拖拽節(jié)點的方式開發(fā)工作流，這樣開發(fā)人員只需要關(guān)注核心SQL語句編寫和整個基礎(chǔ)流程，其他都交給IDE完成，上圖是實際開發(fā)效果和執(zhí)行效果。

報表制作最開始是開發(fā)人員寫代碼開發(fā)報表，后來是配置系統(tǒng)去配置報表，然后是讓用戶從自助系統(tǒng)和工具去自助發(fā)布報表，最后是生成一些個性化報告。最開始的報表系統(tǒng)是龍源報表系統(tǒng)，就是一個報表系統(tǒng)，幾乎沒有管理后臺，僅有用戶權(quán)限管理。其架構(gòu)是最基礎(chǔ)的MVC模式，開發(fā)的每一張報表都是一個小的JavaWeb項目。需要為每一張報表編寫JSP頁面，隨著業(yè)務(wù)量增加，開發(fā)人員任務(wù)加重，因此將報表配置抽象化。形成一個報表配置平臺-龍源2.0，配置流程最核心的就是寫SQL，定義相關(guān)圖表信息、條件信息，將其配置成一張報表。最后利用bootstrap的一個可視化配置管理工具，通過拖拽方式搭建報表。由于業(yè)務(wù)線發(fā)展，愛奇藝發(fā)展成為一個多元平臺，各種業(yè)務(wù)層出不窮，先前一體化的報表模式不能滿足需求，大BI系統(tǒng)應(yīng)運而生。

—

05

愛奇藝BI

愛奇藝BI平臺是一個很大的平臺系統(tǒng)，報表只是其中的一部分，最核心的部分就是對不同業(yè)務(wù)線進(jìn)行拆分。在前期的基礎(chǔ)上，配置方式進(jìn)一步抽象，思路也進(jìn)行了變更。之前從SQL語句開始配置是基于開發(fā)的思路，現(xiàn)在是從報表構(gòu)建的思路去配置，先配置報表的雛形，然后詳細(xì)配置報表的各個組件，這種方式更加符合數(shù)據(jù)分析者的思路。

愛奇藝BI核心不在報表開發(fā)，核心在于業(yè)務(wù)線劃分以及權(quán)限的劃分。數(shù)據(jù)安全越來越重要，在業(yè)務(wù)線和權(quán)限方面做了很多工作。除了開發(fā)人員開發(fā)報表外，還可以讓用戶通過一些自助分析的系統(tǒng)發(fā)布自己的報表到BI進(jìn)行展示。

在消費數(shù)據(jù)時有個很重要的一點就是要保證數(shù)據(jù)是可用的，有時我們會去猜測數(shù)據(jù)在某一時刻是完整的，但是如果某一集群發(fā)生延遲，就會消費掉一個空數(shù)據(jù)。因此設(shè)置了Done文件機(jī)制。將Done文件放到HDFS上，每生成一個表都有相應(yīng)的Done文件，每當(dāng)消費某張數(shù)據(jù)表都會先檢測其Done文件是否存在。HDFS很怕小文件，但是每個表每天都會有若干done文件產(chǎn)生，而且表非常多，就會有海量空文件產(chǎn)生。所以為了避免HDFS壓力過大，我們就制作了Done服務(wù)，這樣直接在做依賴判斷的時候，直接使用Done服務(wù)，不再在HDFS上查找，依賴管理最終采用的方案是數(shù)據(jù)管理。

數(shù)據(jù)管理會將數(shù)據(jù)的整個生命周期管理起來，對數(shù)據(jù)進(jìn)行可用性管理并提供服務(wù)給其他業(yè)務(wù)調(diào)用，用來替代Done服務(wù)。它通過元數(shù)據(jù)抓取、手動錄入、投遞注冊管理、外部系統(tǒng)注冊管理，通過數(shù)據(jù)血緣分析、數(shù)據(jù)標(biāo)注、數(shù)據(jù)生命周期分析等對各種元數(shù)據(jù)進(jìn)行系統(tǒng)性管理。

接下來講一下我們的數(shù)據(jù)倉庫演變，最開始的時候我們的分析統(tǒng)計都是直接消費日志表，所有報表結(jié)果都是從日志表中計算產(chǎn)生，產(chǎn)生的結(jié)果是造成資源浪費，并且定義不清楚，缺乏周知性。接著就針對視頻播放設(shè)計了播放數(shù)倉模型，制作了中間大寬表，方便使用。但是對于有些簡單表或者其他一些條件不適用，目前采用分層建模的方式。

直接消費日志表優(yōu)點是最底層、簡單，數(shù)據(jù)原始，無任何聚合處理，可以探查細(xì)節(jié)，缺點就是數(shù)據(jù)量大，消耗計算資源大，未進(jìn)行反刷量。中間大寬表就是按照一定的主題進(jìn)行聚合，盡量使用最全面的字段盡量方便使用；同時也進(jìn)行了反刷量過濾，只有少量數(shù)據(jù)會用到日志，大寬表有個缺點就是數(shù)據(jù)量不適合在Impala等OLAP引擎使用。分層建模有日志層、明細(xì)層、聚合層、應(yīng)用層，不同主題都在聚合層，根據(jù)不同的應(yīng)用場景會上升到應(yīng)用層構(gòu)建。明細(xì)層和日志層利用魔鏡和SQL語句進(jìn)行管理查詢，應(yīng)用層針對BI報表和莫奈系統(tǒng)，日志層默認(rèn)不開放，業(yè)務(wù)簡單時會開放查詢。

基于上述需求使用了一些數(shù)倉工具，主要負(fù)責(zé)數(shù)倉模型管理，其核心是指標(biāo)維度管理，基于指標(biāo)維度進(jìn)行數(shù)據(jù)開發(fā)，然后進(jìn)行一些分析，尤其是莫奈系統(tǒng)中利用指標(biāo)維度統(tǒng)一的標(biāo)準(zhǔn)信息制作場景和場景間關(guān)聯(lián)，在BI報表直接引用指標(biāo)維度信息制作報表。

OLAP在數(shù)倉的上一層，最開始只使用MySQL，通過分庫分表來解決大數(shù)據(jù)量問題；之后就借助MySQL+HBase，將一部分?jǐn)?shù)據(jù)提前計算好存入HBase,根據(jù)不同的查詢進(jìn)行提取。接著就引入Kylin/Impala作為查詢引擎，目前考慮的是不同框架綜合使用，不局限于一個查詢，根據(jù)分析目標(biāo)數(shù)據(jù)源不同，智能選擇不同的引擎。

一個典型的例子就是劇集統(tǒng)計，愛奇藝有海量視頻數(shù)據(jù)，剛開始是幾十萬，現(xiàn)在是一億+的視頻資源。原先按可加項不可加項分表，分表維度也有很多（來源、提供商），隨著視頻量增加這種方式無法滿足需求，查詢速度很慢。接著采用冷熱數(shù)據(jù)分表，保證日常最常用數(shù)據(jù)的查詢速度，數(shù)據(jù)按天、月、年進(jìn)行分表。后來考慮將一部分?jǐn)?shù)據(jù)存入HBase中，每天會進(jìn)行播放數(shù)據(jù)排行計算，最難的也是計算排行，將不同組合的排行數(shù)據(jù)預(yù)先組合計算存入HBase中。接著將所有數(shù)據(jù)都存入HBase中，這種思想就是Kylin思想，將不同維度組合提前算好存入HBase，這樣就可以提供給自助查詢系統(tǒng)使用。

—

06

魔鏡與庖丁刃

前面主要講報表，接下來講一下分析人員和運維人員取數(shù)分析方式的變化。最開始是運營人員提出數(shù)據(jù)需求，首先看報表是否滿足，滿足直接查報表，不滿足作為臨時報表讓開發(fā)人員完成報表取數(shù)。這種方式工作量大、周期長，后來用戶通過魔鏡看結(jié)果或者運行SQL，如果魔鏡不滿足再去看報表或者開發(fā)。目前和未來思想就是先看報表是不是滿足，不滿足提供專門的分析工具，如漏斗分析、畫像分析去定制化分析需求，再不滿足通過OLAP分析進(jìn)行拖拽式分析，或者通過魔鏡去寫SQL，生成結(jié)果后看是否滿足，是否需要進(jìn)一步分析，如果需要就回到OLAP系統(tǒng)進(jìn)行分析。

整體的思路是最開始靠人工，分析師通過人工導(dǎo)數(shù)、Excel分析等工具進(jìn)行分析。后來發(fā)展為主要依據(jù)魔鏡進(jìn)行報表導(dǎo)數(shù)，后續(xù)分析主要還是Excel等其他分析工具?，F(xiàn)在是將用戶往莫奈分析系統(tǒng)上引導(dǎo)，后續(xù)是希望去掉像Excel等其他分析工具，所有分析都在莫奈系統(tǒng)中完成。魔鏡是通過勾選配置的方式寫SQL達(dá)到取數(shù)的目的，通過定義指標(biāo)、選取維度、定義詳細(xì)的條件、排序方式，通過勾選方式生成SQL，最后落在SQL執(zhí)行的引擎上。庖丁刃就是提供給用戶一個SQL編輯的工具，同時還提供一些數(shù)據(jù)源的管理。魔鏡和庖丁刃是一個相相成的工具，庖丁刃的SQL不一定能轉(zhuǎn)化為魔鏡的定制計算，但是魔鏡的定制計算一定能轉(zhuǎn)化為庖丁刃的SQL。

庖丁刃的技術(shù)架構(gòu)，上層網(wǎng)頁層是SQL編輯器以及魔鏡定制計算的界面。服務(wù)器會根據(jù)不同的數(shù)據(jù)源路由到不同的執(zhí)行引擎上執(zhí)行，同時會進(jìn)行權(quán)限的驗證。最下層是實際SQL執(zhí)行引擎，可以依據(jù)不同數(shù)據(jù)特點智能選擇不同的引擎，并且根據(jù)執(zhí)行情況進(jìn)行智能下沉。如Impala滿足不了會直接下沉到Spark，分為兩種一種是Impala沒有數(shù)據(jù)，另一種是Impala執(zhí)行失敗。整個架構(gòu)構(gòu)建在企業(yè)云計算架構(gòu)上，全部微服務(wù)化，這樣易于監(jiān)控和維護(hù)不容易掛掉。

孔明計算引擎是提供數(shù)據(jù)查詢的統(tǒng)一接口，實施智能選擇執(zhí)行引擎的一個工具。在執(zhí)行的時候?qū)崿F(xiàn)智能下沉，確保計算的可靠性。在SQL解析開始后進(jìn)行權(quán)限驗證，依據(jù)SQL解析后數(shù)據(jù)源的結(jié)果進(jìn)行引擎路由。目前如果不同數(shù)據(jù)源數(shù)據(jù)存在關(guān)聯(lián)會出現(xiàn)報錯，未來會開發(fā)底層觸發(fā)自動同步維護(hù)。

—

07

莫奈系統(tǒng)

莫奈系統(tǒng)目標(biāo)是只需鼠標(biāo)如作畫般劃過屏幕，即可進(jìn)行大數(shù)據(jù)分析，將抽象數(shù)據(jù)變成畫作。上圖是莫奈系統(tǒng)界面，給出的是事先制作好的報表進(jìn)行的展示，可以直接將其發(fā)布到BI系統(tǒng)。將相應(yīng)維度拖到工作區(qū)，支持不同行列的維度；同時還支持不同的圖形可視化方式；支持下載Excel數(shù)據(jù)，后續(xù)將其去掉采用生成報告的方式。后臺是場景分析配置，每一個場景是根據(jù)數(shù)倉應(yīng)用層進(jìn)行的進(jìn)一步抽象，將維度和指標(biāo)全部抽象成場景配置到系統(tǒng)中去。

在普通場景基礎(chǔ)上支持多分析場景的自動組合，將已經(jīng)定義好的場景合并到一起，同樣的字段進(jìn)行合并形成一個新的大場景。組合場景會根據(jù)用戶的勾選和當(dāng)前場景維護(hù)情況自動生成查詢，并判斷當(dāng)前條件維度選擇是否滿足需求。

莫奈系統(tǒng)架構(gòu)，最上層的展現(xiàn)層是基于定義去開發(fā)的前后端系統(tǒng)，網(wǎng)關(guān)層網(wǎng)關(guān)相關(guān)配置，接下來的權(quán)限控制、DSL邏輯、SQL層等都是微服務(wù)。最底層的查詢引擎用的最多就是Kylin，MySQL和IMPALA在系統(tǒng)中也可用，實現(xiàn)MySQL和Kylin并行使用。如果用戶需要對BI報表進(jìn)行進(jìn)一步分析，可以將報表數(shù)據(jù)直接拉到莫奈系統(tǒng)中進(jìn)行進(jìn)一步分析，當(dāng)數(shù)據(jù)量過大時可以將MySQL下沉到IMPALA中執(zhí)行。

—

08

愛奇藝大數(shù)據(jù)分析體系

上圖中的任務(wù)構(gòu)成愛奇藝大數(shù)據(jù)分析體系，上層是BI報表、莫奈分析、魔鏡與庖丁刃、分析工具。

BI報表：BI報表直接查看報告結(jié)果，定制自己的報告；

莫奈分析：拖拽式數(shù)據(jù)可視化分析工具；

魔鏡與庖丁刃：離線取數(shù)，SQL分析工具；

分析工具：留存，漏斗，路徑，畫像等分析工具。

分享嘉賓：杜益凡 愛奇藝 高級技術(shù)經(jīng)理

內(nèi)容來源：DataFun Talk《愛奇藝大數(shù)據(jù)分析平臺的演進(jìn)之路》

出品社區(qū)：DataFun

分享嘉賓：

杜益凡，愛奇藝商業(yè)智能部高級技術(shù)經(jīng)理，畢業(yè)于南京大學(xué)，2010年加入愛奇藝，專注于大數(shù)據(jù)相關(guān)技術(shù)，負(fù)責(zé)愛奇藝大數(shù)據(jù)處理平臺和大數(shù)據(jù)分析產(chǎn)品方面的研發(fā)，對Hadoop及其相關(guān)生態(tài)工具有深入的研究和豐富的應(yīng)用實踐經(jīng)驗。

DataFun7月30日直播預(yù)告：

關(guān)于我們：

DataFun：專注于大數(shù)據(jù)、人工智能技術(shù)應(yīng)用的分享與交流。發(fā)起于2017年，在北京、上海、深圳、杭州等城市舉辦超過100+線下和100+線上沙龍、論壇及峰會，已邀請超過2000位專家和學(xué)者參與分享。其公眾號 DataFunTalk 累計生產(chǎn)原創(chuàng)文章700+，百萬+閱讀，14萬+精準(zhǔn)粉絲。

歡迎轉(zhuǎn)載分享評論，轉(zhuǎn)載請私信。