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

01

起始時(shí)代

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

—

02

魔鏡時(shí)代

因此開發(fā)了一個(gè)魔鏡系統(tǒng)。在魔鏡系統(tǒng)中進(jìn)行投遞管理、投遞驗(yà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ù)計(jì)算太多，Hadoop集群處理不過來。因?yàn)樵谀хR系統(tǒng)中消費(fèi)的大多都是日志數(shù)據(jù)，數(shù)據(jù)量非常大，任務(wù)又多，導(dǎo)致集群計(jì)算壓力非常大。而且數(shù)據(jù)開發(fā)人員仍然是主要進(jìn)行腳本開發(fā)，調(diào)度方式也不成體系。所以我們基于魔鏡系統(tǒng)的思路進(jìn)行進(jìn)一步設(shè)計(jì)，研發(fā)了大數(shù)據(jù)平臺(tái)“通天塔”系統(tǒng)。

—

03

通天塔時(shí)代

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

—

04

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

接下來講一下工作流管理與開發(fā)方式的演變，剛開始的時(shí)候在這方面投入量不是很大，使用Crontab直接驅(qū)動(dòng)數(shù)據(jù)處理腳本運(yùn)行。隨著任務(wù)量逐漸增多，crontab會(huì)變得不可維護(hù)，就利用Shell寫了一個(gè)框架，可以自動(dòng)批量維護(hù)很多計(jì)算。隨著業(yè)務(wù)發(fā)展又無法滿足需求，引入Linkedin公司的開源工作流調(diào)度器Azkaban。由于當(dāng)時(shí)Azkaban只能單機(jī)，可維護(hù)性也不是很高，自研發(fā)了一個(gè)工作流管理系統(tǒng)Gear，但是Gear的管理基于配置文件，開發(fā)調(diào)試起來麻煩又自研了通天塔數(shù)據(jù)開發(fā)Babel BD。

Slytherin完全是一個(gè)Shell腳本，有一個(gè)驅(qū)動(dòng)腳本和一個(gè)執(zhí)行腳本。驅(qū)動(dòng)腳本主要是調(diào)動(dòng)執(zhí)行腳本運(yùn)行，并關(guān)注其運(yùn)行生命周期，感知整個(gè)并發(fā)量，避免對(duì)集群造成過大的壓力。執(zhí)行腳本保證自己的唯一性，處理完成后打好標(biāo)志文件，保證唯一性的方式就是記錄自己的process ID作為ID鎖，如果檢測(cè)自己有ID鎖存在，就不再重復(fù)執(zhí)行。隨著后續(xù)發(fā)展發(fā)現(xiàn)其可視化程度不高，維護(hù)成本大，于是引入了Azkaban，其優(yōu)點(diǎn)是使用簡單、開源、可視化程度很高，缺點(diǎn)是當(dāng)年只能單機(jī)，在使用Azkaban時(shí)愛奇藝集群有3-4個(gè)，涉及的集群機(jī)器有上百臺(tái)，每個(gè)集群都會(huì)有很多臺(tái)入口Client機(jī)器，只能一臺(tái)機(jī)器一臺(tái)機(jī)器去維護(hù)，整體大局性控制不高。

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

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

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

—

05

愛奇藝BI

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

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

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

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

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

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

基于上述需求使用了一些數(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)信息制作場(chǎng)景和場(chǎng)景間關(guān)聯(lián)，在BI報(bào)表直接引用指標(biāo)維度信息制作報(bào)表。

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

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

—

06

魔鏡與庖丁刃

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

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

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

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

—

07

莫奈系統(tǒng)

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

在普通場(chǎng)景基礎(chǔ)上支持多分析場(chǎng)景的自動(dòng)組合，將已經(jīng)定義好的場(chǎng)景合并到一起，同樣的字段進(jìn)行合并形成一個(gè)新的大場(chǎng)景。組合場(chǎng)景會(huì)根據(jù)用戶的勾選和當(dāng)前場(chǎng)景維護(hù)情況自動(dòng)生成查詢，并判斷當(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)中也可用，實(shí)現(xiàn)MySQL和Kylin并行使用。如果用戶需要對(duì)BI報(bào)表進(jìn)行進(jìn)一步分析，可以將報(bào)表數(shù)據(jù)直接拉到莫奈系統(tǒng)中進(jìn)行進(jìn)一步分析，當(dāng)數(shù)據(jù)量過大時(shí)可以將MySQL下沉到IMPALA中執(zhí)行。

—

08

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

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

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

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

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

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

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

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

出品社區(qū)：DataFun

分享嘉賓：

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

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

關(guān)于我們：

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

歡迎轉(zhuǎn)載分享評(píng)論，轉(zhuǎn)載請(qǐng)私信。