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

?

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

?

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

?

一、實時分析需求

?

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

?

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

?

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

• 開發(fā)成本高：用戶需要寫Spark或Flink代碼進行實時流數(shù)據(jù)處理，并進行報表前端開發(fā)，流程冗長而復(fù)雜；

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

• 維護耗費時間：數(shù)據(jù)源發(fā)生改變時，修改的范圍會覆蓋整個流程，從數(shù)據(jù)處理到報表配置全部需要變更，很難操作和維護。

?

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

?

二、實時分析平臺架構(gòu)演變

?

2.1 RAP 1.x

?

▌2.1.1 OLAP選型

?

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

?

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

?

• 時序數(shù)據(jù)：基于時間的系列數(shù)據(jù)，比如實時VV、實時監(jiān)控數(shù)據(jù)

• 時延低：要求幾分鐘甚至秒級延時

• 查詢快：大規(guī)模查詢秒級返回結(jié)果

?

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

?

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

?

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

?

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

?

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

?

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

?

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

?

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

?

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

?

聚合分析

?

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

?

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

?

報表配置

?

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

?

實時報警

?

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

?

通過以上幾步簡單配置，就可以完成實時分析的整體流程。相比于傳統(tǒng)方式，RAP將整體耗時從天級別縮短到30分鐘，大幅提升開發(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ù)會被丟失，報表出現(xiàn)問題無法自行排障等。同時由于Kafka版本為0.8.2，無法通過KIS功能接入，導(dǎo)致Druid的很多功能并不能集成到RAP里，而且舊版接入方式（Tranquility [2]）即將被廢棄。因此我們增加對某些Druid高級功能的支持，并對架構(gòu)進行了一系列的重構(gòu)，上線了RAP2.x版本。

?

▌2.2.1 集成Druid KIS接入方式

?

Kafka Indexing Service [3]是為 Kafka 數(shù)據(jù)源設(shè)計的索引服務(wù)，可以保證消息攝入的 Exactly Once 語義，由Kafka索引任務(wù)直接從Kafka數(shù)據(jù)源讀取消息寫入Druid。

?

Kafka索引任務(wù)的啟動和生命周期管理由運行在Overlord上的Supervisor進行管理，Overlord是Druid上負責(zé)接受任務(wù)，協(xié)調(diào)任務(wù)分配，創(chuàng)建任務(wù)間的鎖和返回給調(diào)用方任務(wù)狀態(tài)的進程。

?

每個Druid數(shù)據(jù)源對應(yīng)一個Supervisor，只需向Overlord提交一個配置文件啟動Supervisor，即可實現(xiàn)將Kafka數(shù)據(jù)攝入至Druid，唯一的條件是使用KIS的Kafka數(shù)據(jù)源版本必須在0.10.x及以上。當(dāng)使用KIS接入Druid時，可以使用一些Tranquility接入不支持的高級功能，如更精確的獨立計數(shù)HLL Sketch [4]等。

?

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

?

?

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

?

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

?

▌2.2.3 增強任務(wù)診斷功能

?

為解決當(dāng)報表出現(xiàn)問題時，無法自行排查這樣的問題，在RAP 2.x版本中豐富了數(shù)據(jù)質(zhì)量監(jiān)控的內(nèi)容。主要包含兩個方面：流任務(wù)監(jiān)控和Druid攝入監(jiān)控，流任務(wù)監(jiān)控是關(guān)于流任務(wù)運行情況的監(jiān)控信息，Druid攝入監(jiān)控是Druid數(shù)據(jù)攝入的監(jiān)控信息。

?

流任務(wù)監(jiān)控包括流任務(wù)延時情況圖、實時攝入監(jiān)控圖、延時丟棄數(shù)據(jù)采樣和錯誤數(shù)據(jù)采樣。其中，流任務(wù)延時情況圖記錄了每個時間的任務(wù)延時情況，可以幫助定位是不是由于堆積任務(wù)過多導(dǎo)致的問題；實時攝入監(jiān)控圖中記錄了流任務(wù)處理數(shù)據(jù)的歷史，如果出現(xiàn)丟棄數(shù)據(jù)或者錯誤數(shù)據(jù)的點，點擊后會在采樣表格里展示具體丟棄或錯誤的數(shù)據(jù)，這樣可以快速排查是否是數(shù)據(jù)時間戳超過了延時時間，或者數(shù)據(jù)處理設(shè)置的問題。Druid攝入監(jiān)控展示的是Druid實時攝入的指標(biāo)（見參考資料Ingestion metrics (Realtime process)小節(jié) ）。

?

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

?

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

?

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

?

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

?

?

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

?

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

?

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

?

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

?

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

?

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

?

?

四、RAP的未來

?

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

?

>>>>

參考資料

?

• [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

總結(jié)

以上是生活随笔為你收集整理的拥有一亿会员的爱奇艺如何搭建大数据实时分析平台的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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