0

導(dǎo)語(yǔ)

生活在信息爆炸時(shí)代的我們?cè)絹?lái)越清晰的認(rèn)識(shí)到海量信息與數(shù)據(jù)分析的重要性，如提高數(shù)據(jù)挖掘能力、為運(yùn)營(yíng)決策提供關(guān)鍵數(shù)據(jù)、通過(guò)數(shù)據(jù)分析助力業(yè)務(wù)創(chuàng)新、在商業(yè)決策中的提供較有價(jià)值的信息等成為關(guān)鍵，于是大數(shù)據(jù)分析平臺(tái)作為在各大公司迅速崛起。如何為企業(yè)個(gè)性化打造高效性、準(zhǔn)確性、敏捷型等的大數(shù)據(jù)實(shí)時(shí)分析平臺(tái)成為了技術(shù)團(tuán)隊(duì)的挑戰(zhàn)。

RAP（RealtimeAnalysis Platform）是愛(ài)奇藝技術(shù)產(chǎn)品團(tuán)隊(duì)基于Apache Druid [1] + Spark/ Flink? 構(gòu)建的分鐘級(jí)延時(shí)的實(shí)時(shí)聯(lián)機(jī)分析處理OLAP（On-Line Analytical Processing）的實(shí)時(shí)分析平臺(tái)，支持通過(guò)Web向?qū)渲猛瓿沙笠?guī)模實(shí)時(shí)數(shù)據(jù)的多維度分析，能為用戶提供一體化的OLAP分析操作流程，只需要幾步簡(jiǎn)單的配置，即可自動(dòng)建立OLAP模型、并生成分鐘級(jí)延時(shí)的可視化報(bào)表。也可以通過(guò)RAP API獲取聚合數(shù)據(jù)，與業(yè)務(wù)平臺(tái)進(jìn)行集成。服務(wù)于會(huì)員、推薦、BI等諸多個(gè)業(yè)務(wù)，總計(jì)上線總計(jì)上線數(shù)百個(gè)流計(jì)算任務(wù)，支持上千張多維分析報(bào)表。

本文將介紹愛(ài)奇藝大數(shù)據(jù)實(shí)時(shí)分析平臺(tái)RAP的設(shè)計(jì)思路、技術(shù)架構(gòu)演進(jìn)以及業(yè)務(wù)應(yīng)用實(shí)踐。

1

實(shí)時(shí)分析需求

自2010年開(kāi)始愛(ài)奇藝開(kāi)展了大數(shù)據(jù)業(yè)務(wù)，打造了基于Hive + MySQL的第一代OLAP數(shù)據(jù)分析平臺(tái)。但隨著業(yè)務(wù)的快速發(fā)展和數(shù)據(jù)量的急劇增長(zhǎng)，Hive的離線分析已經(jīng)無(wú)法滿足業(yè)務(wù)對(duì)數(shù)據(jù)實(shí)時(shí)性的需求。于是逐漸引入Kylin、Impala、Kudu、Druid、ElasticSearch等不同的數(shù)據(jù)存儲(chǔ)/查詢引擎，演化出離線數(shù)倉(cāng)、實(shí)時(shí)數(shù)倉(cāng)、流式數(shù)倉(cāng)等不同OLAP形態(tài)。

在推出RAP實(shí)時(shí)分析平臺(tái)之前，業(yè)務(wù)自行構(gòu)建實(shí)時(shí)分析服務(wù)面臨以下困難：

·? OLAP選型困難：眾多OLAP引擎滿足多樣化需求，但也帶來(lái)了不少問(wèn)題。業(yè)務(wù)需要了解不同OLAP引擎的優(yōu)缺點(diǎn)，花費(fèi)大量精力學(xué)習(xí)，依然可能選錯(cuò)；

·??開(kāi)發(fā)成本高：用戶需要寫Spark或Flink代碼進(jìn)行實(shí)時(shí)流數(shù)據(jù)處理，并進(jìn)行報(bào)表前端開(kāi)發(fā)，流程冗長(zhǎng)而復(fù)雜；

·??數(shù)據(jù)實(shí)時(shí)性差：從數(shù)據(jù)產(chǎn)生到數(shù)據(jù)可被查詢，中間存在較高時(shí)延（從數(shù)十分鐘到天級(jí)別不等），且查詢較慢；

·??維護(hù)耗費(fèi)時(shí)間：數(shù)據(jù)源發(fā)生改變時(shí)，修改的范圍會(huì)覆蓋整個(gè)流程，從數(shù)據(jù)處理到報(bào)表配置全部需要變更，很難操作和維護(hù)；

針對(duì)以上問(wèn)題，我們搭建了支持通過(guò)Web向?qū)渲猛瓿沙笠?guī)模實(shí)時(shí)數(shù)據(jù)的多維度分析，生成分鐘級(jí)延時(shí)的可視化報(bào)表，在保證數(shù)據(jù)實(shí)時(shí)性和分析靈活性的同時(shí)，降低開(kāi)發(fā)和維護(hù)成本，并將整個(gè)分析流程平臺(tái)化的RAP實(shí)時(shí)分析平臺(tái)。

2

實(shí)時(shí)分析平臺(tái)架構(gòu)演變

2.1?RAP 1.x

▌2.1.1?OLAP選型

在開(kāi)發(fā)大數(shù)據(jù)實(shí)時(shí)分析平臺(tái)RAP平臺(tái)之前，需要選擇一款適合實(shí)時(shí)分析場(chǎng)景的OLAP引擎。

大數(shù)據(jù)實(shí)時(shí)分析的典型場(chǎng)景具備以下幾個(gè)特征：

·? 時(shí)序數(shù)據(jù)：基于時(shí)間的系列數(shù)據(jù)，比如實(shí)時(shí)VV、實(shí)時(shí)監(jiān)控?cái)?shù)據(jù)

·? 時(shí)延低：要求幾分鐘甚至秒級(jí)延時(shí)

·? 查詢快：大規(guī)模查詢秒級(jí)返回結(jié)果

根據(jù)典型場(chǎng)景的需求，我們綜合評(píng)估了常見(jiàn)的幾款OLAP引擎，最終選擇Druid（Druid是一款開(kāi)源的為時(shí)序數(shù)據(jù)設(shè)計(jì)的亞秒級(jí)查詢延遲的數(shù)據(jù)存儲(chǔ)引擎，主要用于進(jìn)行OLAP聚合分析。）做為RAP的底層OLAP引擎。針對(duì)實(shí)時(shí)聚合分析場(chǎng)景（絕大部分是時(shí)序數(shù)據(jù)），Druid是更適合使用的數(shù)據(jù)引擎。基于Druid，我們?cè)O(shè)計(jì)了第一代的實(shí)時(shí)分析平臺(tái) RAP。

▌2.1.2?產(chǎn)品設(shè)計(jì)

RAP將實(shí)時(shí)分析的開(kāi)發(fā)流程抽象為五個(gè)步驟：數(shù)據(jù)接入、數(shù)據(jù)處理、聚合分析、報(bào)表配置和實(shí)時(shí)報(bào)警，并且將這些步驟通過(guò)向?qū)Щ腤eb頁(yè)面指導(dǎo)用戶配置。

數(shù)據(jù)接入

無(wú)需輸入集群IP等信息，可通過(guò)下拉框選擇接入的實(shí)時(shí)數(shù)據(jù)源，目前支持4大類型數(shù)據(jù)：用戶數(shù)據(jù)、服務(wù)日志、監(jiān)控?cái)?shù)據(jù)、其他Kafka數(shù)據(jù)源。

數(shù)據(jù)處理

為了擴(kuò)展和優(yōu)化Druid的功能，RAP支持基于流計(jì)算的數(shù)據(jù)處理功能，在對(duì)數(shù)據(jù)進(jìn)行處理后寫入Druid。在2.x版本中，我們同時(shí)支持使用Flink流計(jì)算引擎。

用戶在頁(yè)面上配置數(shù)據(jù)處理規(guī)則，RAP將這些規(guī)則翻譯成愛(ài)奇藝自研的StreamingSQL語(yǔ)句，最終生成Spark Streaming流任務(wù)進(jìn)行處理，用戶無(wú)需編寫流任務(wù)。

除了Spark SQL自帶的預(yù)定義函數(shù)外，RAP還內(nèi)置了一些用戶常用的函數(shù)，比如將IP到省份、城市、運(yùn)營(yíng)商等常用轉(zhuǎn)換函數(shù)。

聚合分析

用戶通過(guò)界面化的操作定義實(shí)時(shí)分析OLAP模型，配置聚合分析所需的維度和聚合方式，如計(jì)數(shù)、獨(dú)立計(jì)數(shù)、求和等，根據(jù)模型配置對(duì)實(shí)時(shí)數(shù)據(jù)進(jìn)行預(yù)聚合。

在這個(gè)過(guò)程中，無(wú)需關(guān)心底層數(shù)據(jù)存儲(chǔ)及OLAP引擎，RAP會(huì)自動(dòng)翻譯并優(yōu)化相關(guān)參數(shù)。例如，接入Druid時(shí)需要根據(jù)經(jīng)驗(yàn)配置參數(shù)（如task.partition，windowPeriod，queryGranularity等），RAP可以根據(jù)用戶的配置（數(shù)據(jù)最大延時(shí)時(shí)間、watermark）以及數(shù)據(jù)源的信息（Kafka QPS）自動(dòng)調(diào)節(jié)配置信息。

報(bào)表配置

用戶可以基于實(shí)時(shí)分析模型的維度和指標(biāo)配置報(bào)表（圖表展示方式、以及查詢條件等），RAP根據(jù)報(bào)表配置自動(dòng)生成Druid查詢，獲取結(jié)果后提供給報(bào)表平臺(tái)，并可以自動(dòng)推薦合適的查詢粒度，支持設(shè)置動(dòng)態(tài)的過(guò)濾條件，用戶無(wú)需關(guān)心查詢語(yǔ)句如何配置。

實(shí)時(shí)報(bào)警

RAP支持對(duì)數(shù)據(jù)配置報(bào)警，可以配置閾值、同比/環(huán)比等報(bào)警。由于Kafka數(shù)據(jù)存在晚到的可能，實(shí)時(shí)報(bào)警支持配置延時(shí)時(shí)間獲取一段時(shí)間前的數(shù)據(jù)進(jìn)行判斷，減少誤報(bào)可能。

通過(guò)以上幾步簡(jiǎn)單配置，就可以完成實(shí)時(shí)分析的整體流程。相比于傳統(tǒng)方式，RAP將整體耗時(shí)從天級(jí)別縮短到30分鐘，大幅提升開(kāi)發(fā)和分析效率。

▌2.1.3?RAP架構(gòu)

RAP的整體架構(gòu)如下圖所示，其中部分功能模塊為RAP 2.x 支持：

2.2?RAP 2.x

RAP發(fā)布后發(fā)現(xiàn)了一些不足之處，如：在任務(wù)重啟階段的數(shù)據(jù)會(huì)被丟失，報(bào)表出現(xiàn)問(wèn)題無(wú)法自行排障等。同時(shí)由于Kafka版本為0.8.2，無(wú)法通過(guò)KIS功能接入，導(dǎo)致Druid的很多功能并不能集成到RAP里，而且舊版接入方式（Tranquility [2]）即將被廢棄。因此我們?cè)黾訉?duì)某些Druid高級(jí)功能的支持，并對(duì)架構(gòu)進(jìn)行了一系列的重構(gòu)，上線了RAP2.x版本。

▌2.2.1?集成Druid KIS接入方式

Kafka Indexing Service [3]是為 Kafka 數(shù)據(jù)源設(shè)計(jì)的索引服務(wù)，可以保證消息攝入的 Exactly Once 語(yǔ)義，由Kafka索引任務(wù)直接從Kafka數(shù)據(jù)源讀取消息寫入Druid。Kafka索引任務(wù)的啟動(dòng)和生命周期管理由運(yùn)行在Overlord上的Supervisor進(jìn)行管理，Overlord是Druid上負(fù)責(zé)接受任務(wù)，協(xié)調(diào)任務(wù)分配，創(chuàng)建任務(wù)間的鎖和返回給調(diào)用方任務(wù)狀態(tài)的進(jìn)程。每個(gè)Druid數(shù)據(jù)源對(duì)應(yīng)一個(gè)Supervisor，只需向Overlord提交一個(gè)配置文件啟動(dòng)Supervisor，即可實(shí)現(xiàn)將Kafka數(shù)據(jù)攝入至Druid，唯一的條件是使用KIS的Kafka數(shù)據(jù)源版本必須在0.10.x及以上。當(dāng)使用KIS接入Druid時(shí)，可以使用一些Tranquility接入不支持的高級(jí)功能，如更精確的獨(dú)立計(jì)數(shù)HLL Sketch [4]等。

在RAP 2.x版本中，支持用戶選擇使用KIS接入Druid。當(dāng)選擇了KIS接入，如果用戶的Kafka數(shù)據(jù)源版本在0.10.x及以上且沒(méi)有進(jìn)行數(shù)據(jù)處理，RAP會(huì)直接將Kafka數(shù)據(jù)源按配置通過(guò)KIS接入Druid；反之，如果Kafka數(shù)據(jù)源低于0.10.x或使用了數(shù)據(jù)處理，RAP會(huì)將數(shù)據(jù)處理的結(jié)果投遞到RAP管理的公共Kafka集群，再通過(guò)KIS接入Druid。同時(shí)，在2.x版本中，RAP已經(jīng)支持設(shè)置HLL Sketch獨(dú)立計(jì)數(shù)指標(biāo)（RAP 1.x使用Approximate histogram進(jìn)行獨(dú)立計(jì)數(shù)，其誤差較大、且沒(méi)有置信區(qū)間）。

▌2.2.2?支持Flink計(jì)算引擎和函數(shù)管理功能

Apache Flink [5]是支持?jǐn)?shù)據(jù)流處理和批量處理的分布式數(shù)據(jù)處理引擎，能夠?qū)崿F(xiàn)秒級(jí)處理數(shù)據(jù)，并且支持Exactly Once語(yǔ)義。通過(guò)使用Flink計(jì)算引擎，RAP數(shù)據(jù)處理可以從分鐘級(jí)降到秒級(jí)，結(jié)合KIS接入的使用，可以保證從數(shù)據(jù)處理到Druid的Exactly Once攝入。而流任務(wù)函數(shù)管理功能可以讓用戶提交定制化的處理方式，可以應(yīng)用在數(shù)據(jù)的字段上進(jìn)行處理，豐富了數(shù)據(jù)處理功能。

▌2.2.3?增強(qiáng)任務(wù)診斷功能

為解決當(dāng)報(bào)表出現(xiàn)問(wèn)題時(shí)，無(wú)法自行排查這樣的問(wèn)題，在RAP 2.x版本中豐富了數(shù)據(jù)質(zhì)量監(jiān)控的內(nèi)容。主要包含兩個(gè)方面：流任務(wù)監(jiān)控和Druid攝入監(jiān)控，流任務(wù)監(jiān)控是關(guān)于流任務(wù)運(yùn)行情況的監(jiān)控信息，Druid攝入監(jiān)控是Druid數(shù)據(jù)攝入的監(jiān)控信息。流任務(wù)監(jiān)控包括流任務(wù)延時(shí)情況圖、實(shí)時(shí)攝入監(jiān)控圖、延時(shí)丟棄數(shù)據(jù)采樣和錯(cuò)誤數(shù)據(jù)采樣。其中，流任務(wù)延時(shí)情況圖記錄了每個(gè)時(shí)間的任務(wù)延時(shí)情況，可以幫助定位是不是由于堆積任務(wù)過(guò)多導(dǎo)致的問(wèn)題；實(shí)時(shí)攝入監(jiān)控圖中記錄了流任務(wù)處理數(shù)據(jù)的歷史，如果出現(xiàn)丟棄數(shù)據(jù)或者錯(cuò)誤數(shù)據(jù)的點(diǎn)，點(diǎn)擊后會(huì)在采樣表格里展示具體丟棄或錯(cuò)誤的數(shù)據(jù)，這樣可以快速排查是否是數(shù)據(jù)時(shí)間戳超過(guò)了延時(shí)時(shí)間，或者數(shù)據(jù)處理設(shè)置的問(wèn)題。Druid攝入監(jiān)控展示的是Druid實(shí)時(shí)攝入的指標(biāo)（見(jiàn)Ingestion metrics (Realtime process)小節(jié) [6]）。

3

實(shí)時(shí)分析業(yè)務(wù)應(yīng)用

3.1?會(huì)員業(yè)務(wù)日志實(shí)時(shí)數(shù)據(jù)監(jiān)控

2019年6月 愛(ài)奇藝會(huì)員規(guī)模突破1億，為了提供更好的會(huì)員服務(wù)，RAP被會(huì)員業(yè)務(wù)用于對(duì)線上日志數(shù)據(jù)進(jìn)行實(shí)時(shí)分析、實(shí)時(shí)報(bào)警。其中，會(huì)員業(yè)務(wù)的實(shí)時(shí)數(shù)據(jù)主要是日志數(shù)據(jù)，日均處理數(shù)百億數(shù)據(jù)，結(jié)合RAP的分鐘級(jí)分析和秒級(jí)查詢的特性，已實(shí)現(xiàn)分鐘粒度報(bào)警，且能夠快速響應(yīng)問(wèn)題。同時(shí)會(huì)員團(tuán)隊(duì)將相關(guān)數(shù)據(jù)生成對(duì)應(yīng)質(zhì)量服務(wù)報(bào)表，提供給運(yùn)維人員以數(shù)據(jù)指導(dǎo)。

RAP同時(shí)為會(huì)員監(jiān)控體系提供數(shù)據(jù)支持，可短時(shí)間內(nèi)快速接入95%系統(tǒng)，提供60+種維度的數(shù)據(jù)統(tǒng)計(jì)，能快速生成700+張實(shí)時(shí)報(bào)表，報(bào)警時(shí)效提升80%，大幅提升線上故障排查效率與響應(yīng)速度。

3.2?推薦算法效果監(jiān)測(cè)

合理的推薦算法可幫助愛(ài)奇藝從海量視頻中挑選出高度定制化的內(nèi)容推送給用戶，而過(guò)去每次新算法的上線都需要1天的時(shí)間去分析用戶效果。這樣會(huì)引發(fā)2個(gè)問(wèn)題：算法上線流程長(zhǎng)、不好的算法影響時(shí)間長(zhǎng)。所以通過(guò)實(shí)時(shí)數(shù)據(jù)來(lái)驗(yàn)證算法的有效性，指導(dǎo)算法迭代更新是非常必要的。

愛(ài)奇藝推薦業(yè)務(wù)使用RAP平臺(tái)對(duì)推薦視頻點(diǎn)擊量（UV、VV）、用戶觀影時(shí)長(zhǎng)（PPUI）等數(shù)據(jù)進(jìn)行實(shí)時(shí)分析，監(jiān)控分桶算法的效果，實(shí)現(xiàn)在30分鐘內(nèi)及時(shí)切換推薦算法提高用戶體驗(yàn)。

3.3 智能電視實(shí)時(shí)預(yù)警

線上視頻播放可能出現(xiàn)各種問(wèn)題，需要有效的方法對(duì)線上故障進(jìn)行監(jiān)控，并及時(shí)向相關(guān)人員預(yù)警。視頻播放故障有多方面原因，可以利用播放時(shí)收集的各種信息進(jìn)行排查，如基于客戶端版本、服務(wù)器IP、所在城市等多維度對(duì)錯(cuò)誤率、卡頓比等指標(biāo)進(jìn)行分析，從而定位故障根因。

智能電視業(yè)務(wù)使用RAP分析實(shí)時(shí)數(shù)據(jù)監(jiān)控故障，幫助實(shí)現(xiàn)“監(jiān)控-報(bào)警-分析-解決-驗(yàn)證”的閉環(huán)流程，實(shí)現(xiàn)5分鐘實(shí)時(shí)報(bào)警，并且可以通過(guò)多維度分析追溯故障根因，保障視頻播放質(zhì)量。

4

RAP的未來(lái)

未來(lái)RAP將會(huì)繼續(xù)增加實(shí)時(shí)分析鏈路的監(jiān)控，提供更細(xì)粒度的分析鏈路診斷功能，完善流計(jì)算處理引擎的處理能力，提高資源利用率，增強(qiáng)各環(huán)節(jié)的Exactly Once能力。提供更完備的數(shù)據(jù)分析能力，支持留存、智能分析等，讓愛(ài)奇藝大數(shù)據(jù)實(shí)時(shí)分析平臺(tái)RAP更具高性能。

5

參考資料

[1]?https://druid.apache.org/

[2]?https://druid.apache.org/docs/latest/ingestion/tranquility.html

[3]?https://druid.apache.org/docs/0.14.2-incubating/development/extensions-core/kafka-ingestion.html

[4]?https://druid.apache.org/docs/latest/development/extensions-core/datasketches-hll.html

[5]?https://flink.apache.org/flink-architecture.html

[6]?https://druid.apache.org/docs/latest/operations/metrics.html

猜你喜歡

1、過(guò)往記憶大數(shù)據(jù)，2019年原創(chuàng)精選69篇

2、Hadoop 2.7 不停服升級(jí)到 3.2 在滴滴的實(shí)踐

3、深入學(xué)習(xí) Redis 集群搭建方案及實(shí)現(xiàn)原理

4、Kafka 集群在馬蜂窩大數(shù)據(jù)平臺(tái)的優(yōu)化與應(yīng)用擴(kuò)展

過(guò)往記憶大數(shù)據(jù)微信群，請(qǐng)?zhí)砑游⑿?#xff1a;fangzhen0219,備注【進(jìn)群】

總結(jié)

以上是生活随笔為你收集整理的爱奇艺大数据实时分析平台的建设与实践的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。