導語

生活在資訊爆炸時代的我們越來越清晰的認識到海量資訊與資料分析的重要性，如提高資料探勘能力、為運營決策提供關鍵資料、透過資料分析助力業務創新、在商業決策中的提供較有價值的資訊等成為關鍵，於是大資料分析平臺作為在各大公司迅速崛起。如何為企業個性化打造高效性、準確性、敏捷型等的大資料實時分析平臺成為了技術團隊的挑戰。

RAP（RealtimeAnalysis Platform）是愛奇藝技術產品團隊基於Apache Druid [1] + Spark/ Flink  構建的分鐘級延時的實時聯機分析處理OLAP（On-Line Analytical Processing）的實時分析平臺，支援透過Web嚮導配置完成超大規模實時資料的多維度分析，能為使用者提供一體化的OLAP分析操作流程，只需要幾步簡單的配置，即可自動建立OLAP模型、並生成分鐘級延時的視覺化報表。也可以透過RAP API獲取聚合資料，與業務平臺進行整合。服務於會員、推薦、BI等諸多個業務，總計上線總計上線數百個流計算任務，支援上千張多維分析報表

本文將介紹愛奇藝大資料實時分析平臺RAP的設計思路、技術架構演進以及業務應用實踐。

實時分析需求

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

在推出RAP實時分析平臺之前，業務自行構建實時分析服務面臨以下困難：

·  OLAP選型困難：眾多OLAP引擎滿足多樣化需求，但也帶來了不少問題。業務需要了解不同OLAP引擎的優缺點，花費大量精力學習，依然可能選錯；

·  開發成本高：使用者需要寫Spark或Flink程式碼進行實時流資料處理，並進行報表前端開發，流程冗長而複雜；

·  資料實時性差：從資料產生到資料可被查詢，中間存在較高時延（從數十分鐘到天級別不等），且查詢較慢；

·  維護耗費時間：資料來源發生改變時，修改的範圍會覆蓋整個流程，從資料處理到報表配置全部需要變更，很難操作和維護；

針對以上問題，我們搭建了支援透過Web嚮導配置完成超大規模實時資料的多維度分析，生成分鐘級延時的視覺化報表，在保證資料實時性和分析靈活性的同時，降低開發和維護成本，並將整個分析流程平臺化的RAP實時分析平臺。

實時分析平臺架構演變

2.1 RAP 1.x

▌2.1.1 OLAP選型

在開發大資料實時分析平臺RAP平臺之前，需要選擇一款適合實時分析場景的OLAP引擎。

大資料實時分析的典型場景具備以下幾個特徵：

·  時序資料：基於時間的系列資料，比如實時VV、實時監控資料

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

·  查詢快：大規模查詢秒級返回結果

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

▌2.1.2 產品設計

RAP將實時分析的開發流程抽象為五個步驟：資料接入、資料處理、聚合分析、報表配置和實時報警，並且將這些步驟透過嚮導化的Web頁面指導使用者配置。

資料接入

無需輸入叢集IP等資訊，可透過下拉框選擇接入的實時資料來源，目前支援4大型別資料：使用者資料、服務日誌、監控資料、其他Kafka資料來源。

資料處理

為了擴充套件和最佳化Druid的功能，RAP支援基於流計算的資料處理功能，在對資料進行處理後寫入Druid。在2.x版本中，我們同時支援使用Flink流計算引擎。

使用者在頁面上配置資料處理規則，RAP將這些規則翻譯成愛奇藝自研的StreamingSQL語句，最終生成Spark Streaming流任務進行處理，使用者無需編寫流任務。

除了Spark SQL自帶的預定義函式外，RAP還內建了一些使用者常用的函式，比如將IP到省份、城市、運營商等常用轉換函式。

聚合分析

使用者透過介面化的操作定義實時分析OLAP模型，配置聚合分析所需的維度和聚合方式，如計數、獨立計數、求和等，根據模型配置對實時資料進行預聚合。

在這個過程中，無需關心底層資料儲存及OLAP引擎，RAP會自動翻譯並最佳化相關引數。例如，接入Druid時需要根據經驗配置引數（如task.partition，windowPeriod，queryGranularity等），RAP可以根據使用者的配置（資料最大延時時間、watermark）以及資料來源的資訊（Kafka QPS）自動調節配置資訊。

報表配置

使用者可以基於實時分析模型的維度和指標配置報表（圖表展示方式、以及查詢條件等），RAP根據報表配置自動生成Druid查詢，獲取結果後提供給報表平臺，並可以自動推薦合適的查詢粒度，支援設定動態的過濾條件，使用者無需關心查詢語句如何配置。

實時報警

RAP支援對資料配置報警，可以配置閾值、同比/環比等報警。由於Kafka資料存在晚到的可能，實時報警支援配置延時時間獲取一段時間前的資料進行判斷，減少誤報可能。

透過以上幾步簡單配置，就可以完成實時分析的整體流程。相比於傳統方式，RAP將整體耗時從天級別縮短到30分鐘，大幅提升開發和分析效率。

▌2.1.3 RAP架構

RAP的整體架構如下圖所示，其中部分功能模組為RAP 2.x 支援：

2.2 RAP 2.x

RAP釋出後發現了一些不足之處，如：在任務重啟階段的資料會被丟失，報表出現問題無法自行排障等。同時由於Kafka版本為0.8.2，無法透過KIS功能接入，導致Druid的很多功能並不能整合到RAP裡，而且舊版接入方式（Tranquility [2]）即將被廢棄。因此我們增加對某些Druid高階功能的支援，並對架構進行了一系列的重構，上線了RAP2.x版本。

▌2.2.1 整合Druid KIS接入方式

Kafka Indexing Service [3]是為 Kafka 資料來源設計的索引服務，可以保證訊息攝入的 Exactly Once 語義，由Kafka索引任務直接從Kafka資料來源讀取訊息寫入Druid。Kafka索引任務的啟動和生命週期管理由執行在Overlord上的Supervisor進行管理，Overlord是Druid上負責接受任務，協調任務分配，建立任務間的鎖和返回給呼叫方任務狀態的程式。每個Druid資料來源對應一個Supervisor，只需向Overlord提交一個配置檔案啟動Supervisor，即可實現將Kafka資料攝入至Druid，唯一的條件是使用KIS的Kafka資料來源版本必須在0.10.x及以上。當使用KIS接入Druid時，可以使用一些Tranquility接入不支援的高階功能，如更精確的獨立計數HLL Sketch [4]等。

在RAP 2.x版本中，支援使用者選擇使用KIS接入Druid。當選擇了KIS接入，如果使用者的Kafka資料來源版本在0.10.x及以上且沒有進行資料處理，RAP會直接將Kafka資料來源按配置透過KIS接入Druid；反之，如果Kafka資料來源低於0.10.x或使用了資料處理，RAP會將資料處理的結果投遞到RAP管理的公共Kafka叢集，再透過KIS接入Druid。同時，在2.x版本中，RAP已經支援設定HLL Sketch獨立計數指標（RAP 1.x使用Approximate histogram進行獨立計數，其誤差較大、且沒有置信區間）。

▌2.2.2 支援Flink計算引擎和函式管理功能

Apache Flink [5]是支援資料流處理和批次處理的分散式資料處理引擎，能夠實現秒級處理資料，並且支援Exactly Once語義。透過使用Flink計算引擎，RAP資料處理可以從分鐘級降到秒級，結合KIS接入的使用，可以保證從資料處理到Druid的Exactly Once攝入。而流任務函式管理功能可以讓使用者提交定製化的處理方式，可以應用在資料的欄位上進行處理，豐富了資料處理功能。

▌2.2.3 增強任務診斷功能

為解決當報表出現問題時，無法自行排查這樣的問題，在RAP 2.x版本中豐富了資料質量監控的內容。主要包含兩個方面：流任務監控和Druid攝入監控，流任務監控是關於流任務執行情況的監控資訊，Druid攝入監控是Druid資料攝入的監控資訊。流任務監控包括流任務延時情況圖、實時攝入監控圖、延時丟棄資料取樣和錯誤資料取樣。其中，流任務延時情況圖記錄了每個時間的任務延時情況，可以幫助定位是不是由於堆積任務過多導致的問題；實時攝入監控圖中記錄了流任務處理資料的歷史，如果出現丟棄資料或者錯誤資料的點，點選後會在取樣表格裡展示具體丟棄或錯誤的資料，這樣可以快速排查是否是資料時間戳超過了延時時間，或者資料處理設定的問題。Druid攝入監控展示的是Druid實時攝入的指標（見Ingestion metrics (Realtime process)小節 [6]）。

實時分析業務應用

3.1 會員業務日誌實時資料監控

2019年6月 愛奇藝會員規模突破1億，為了提供更好的會員服務，RAP被會員業務用於對線上日誌資料進行實時分析、實時報警。其中，會員業務的實時資料主要是日誌資料，日均處理數百億資料，結合RAP的分鐘級分析和秒級查詢的特性，已實現分鐘粒度報警，且能夠快速響應問題。同時會員團隊將相關資料生成對應質量服務報表，提供給運維人員以資料指導。

RAP同時為會員監控體系提供資料支援，可短時間內快速接入95%系統，提供60+種維度的資料統計，能快速生成700+張實時報表，報警時效提升80%，大幅提升線上故障排查效率與響應速度。

3.2 推薦演算法效果監測

合理的推薦演算法可幫助愛奇藝從海量影片中挑選出高度定製化的內容推送給使用者，而過去每次新演算法的上線都需要1天的時間去分析使用者效果。這樣會引發2個問題：演算法上線流程長、不好的演算法影響時間長。所以透過實時資料來驗證演算法的有效性，指導演算法迭代更新是非常必要的。

愛奇藝推薦業務使用RAP平臺對推薦影片點選量（UV、VV）、使用者觀影時長（PPUI）等資料進行實時分析，監控分桶演算法的效果，實現在30分鐘內及時切換推薦演算法提高使用者體驗。

3.3 智慧電視實時預警

線上影片播放可能出現各種問題，需要有效的方法對線上故障進行監控，並及時向相關人員預警。影片播放故障有多方面原因，可以利用播放時收集的各種資訊進行排查，如基於客戶端版本、伺服器IP、所在城市等多維度對錯誤率、卡頓比等指標進行分析，從而定位故障根因。

智慧電視業務使用RAP分析實時資料監控故障，幫助實現“監控-報警-分析-解決-驗證”的閉環流程，實現5分鐘實時報警，並且可以透過多維度分析追溯故障根因，保障影片播放質量。

4

RAP的未來

未來RAP將會繼續增加實時分析鏈路的監控，提供更細粒度的分析鏈路診斷功能，完善流計算處理引擎的處理能力，提高資源利用率，增強各環節的Exactly Once能力。提供更完備的資料分析能力，支援留存、智慧分析等，讓愛奇藝大資料實時分析平臺RAP更具高效能。

參考資料

[1] 

[2] docs/latest/ingestion/tranquility.html

[3] docs/0.14.2-incubating/development/extensions-core/kafka-ingestion.html

[4] docs/latest/development/extensions-core/datasketches-hll.html

[5] 

[6] docs/latest/operations/metrics.html