一、愛奇藝大數(shù)據(jù)介紹

1.愛奇藝大數(shù)據(jù)應用

圖片

愛奇藝大數(shù)據(jù)應用分為兩個方面：

• 看過去：針對以往數(shù)據(jù)，制作天級別、小時級別或?qū)崟r的報表；負責內(nèi)容、會員的運營工作，基于數(shù)據(jù)分析進行決策。
• 知未來：基于數(shù)據(jù)制作用戶產(chǎn)品，應用于實施廣告、推薦搜索等方面。

2.愛奇藝大數(shù)據(jù)實時應用

愛奇藝大數(shù)據(jù)實時應用包括實時廣告系統(tǒng)、實時推薦和搜索、實時熱度，以及實時風控。下方右圖是應用搜索界面，搜索推薦基于用戶及其他個性化信息實時計算生成。

圖片

3.愛奇藝大數(shù)據(jù)服務體系

圖片

以上提及的產(chǎn)品通過愛奇藝大數(shù)據(jù)服務體系實現(xiàn)。如上圖，愛奇藝大數(shù)據(jù)服務體系主要由數(shù)據(jù)采集、數(shù)據(jù)處理、數(shù)據(jù)應用等方面構成。

• 數(shù)據(jù)采集包括用戶和內(nèi)容數(shù)據(jù)、服務日志、監(jiān)控數(shù)據(jù)、第三方數(shù)據(jù)；
• 數(shù)據(jù)處理包括大數(shù)據(jù)基礎架構的存儲和計算層，以及上層的數(shù)據(jù)分析引擎和平臺；
• 最終通過報表、分析型查詢、機器學習和監(jiān)控排障功能，應用于各個業(yè)務線。

我們的集群部署模式由通用集群和少量專用集群組成，總共有1萬多臺機器、500PB以上的存儲，每天會運行50多萬個批處理任務及4000多個流計算任務。

二、愛奇藝實時計算技術演進

1.愛奇藝實時計算技術演進概覽

圖片

技術演進過程分為三個階段：

第一階段是比較原始的Hive on MapReduce。在此階段，我們借助Hive工具實現(xiàn)了SQL化的分析，通過SQL在Hadoop上構建離線數(shù)倉。SQL避免用戶自己寫MapReduce的Java代碼，解決了大數(shù)據(jù)的初步問題之一。但隨著業(yè)務發(fā)展、實時性需求增加，離線分析的處理延時難以滿足業(yè)務需要。

第二階段采用基于Spark SQL分析，大大加速離線數(shù)倉的構建進程，同時也探索基于Flink的實時數(shù)據(jù)處理。這個階段我們初步引入Flink，用戶直接寫Flink任務代碼，相比于基于SQL的離線分析，開發(fā)和運維的難度高了不少。同時，因為需要維護離線和實時兩條鏈路，成本較高，且存在流與批數(shù)據(jù)不一致等問題。

第三階段主要進行兩項工作：一方面是實時計算SQL化，我們引入了統(tǒng)一元數(shù)據(jù)，簡化了Flink SQL的開發(fā)，使得撰寫實時計算的邏輯與Hive SQL一樣簡單；另一方面，引入數(shù)據(jù)湖Iceberg，初步實現(xiàn)流批一體。

2.Spark SQL服務架構

愛奇藝的Spark SQL服務基于開源的Apache Kyuubi搭建，因為直接使用Spark Thrift Server服務有很多缺點，比如不支持多租戶、資源隔離較難實現(xiàn)等。

圖片

引入Kyuubi后，整體架構如上圖所示。我們在Hadoop集群上層搭建了Kyuubi Server集群，再上層通過Pilot統(tǒng)一SQL網(wǎng)關（自研服務）接入，最上層是離線計算的Gear工作流調(diào)度系統(tǒng)和魔鏡即席查詢平臺，分別承接定時工作流以及Ad-hoc的即席查詢。

除此之外，Kyuubi Server和Spark任務引擎會注冊到ZooKeeper服務發(fā)現(xiàn)集群中，供其調(diào)用方進行服務發(fā)現(xiàn)，由此實現(xiàn)了高可用性，去除了單點故障。

基于Kyuubi的這套體系具有以下6個好處：

• 多租戶：企業(yè)內(nèi)部包含各個業(yè)務線和不同的Hadoop user，只需部署一套服務即可支持不同用戶的訪問；
• 資源隔離：我們?yōu)槊總€來自定時工作流的例行化任務，啟動獨立的Spark引擎，各個任務間資源隔離，不會互相影響；
• 快速Ad-hoc支持：我們也為來自即席查詢的任務，啟動用戶級別的共享Spark引擎，無需在每次查詢時都花費1分鐘去啟動Spark，使得查詢響應低至秒級；
• 高擴展性：單個Kyuubi實例支持上千個連接，且每個查詢只需要花費Kyuubi實例很少的資源，因此每臺Kyuubi服務器都可承擔很高的工作負載；
• 高可用性：由于采用了ZooKeeper的服務注冊與發(fā)現(xiàn)機制，單個Kyuubi實例故障不影響任務運行；
• 執(zhí)行計劃優(yōu)化：為了加快SQL的運行速度，Kyuubi默認支持了一些查詢優(yōu)化規(guī)則，并且允許用戶在此基礎上擴展，添加新的優(yōu)化規(guī)則。

愛奇藝在作為Apache Kyuubi用戶的同時，也積極參與社區(qū)討論，回饋社區(qū)，目前共有70多個patches被社區(qū)接受。

3.Spark深入優(yōu)化

圖片

除了通過Kyuubi建立Spark SQL的服務之外，我們也對Spark本身進行了優(yōu)化，使得計算速度更快，資源更節(jié)省。

• 動態(tài)資源分配（Dynamic Resource Allocation，DRA）

由于我們平臺上每天都會運行大量的任務，用戶很難為每個任務配置一個合適的資源量，因此經(jīng)常出現(xiàn)任務的并行度不足或資源浪費的問題。DRA是Spark提供的已經(jīng)比較成熟的功能，開啟之后能夠根據(jù)并行度需求自動申請或釋放資源，在避免資源浪費的同時，還能在一定程度上加快任務運行。

• 自適應查詢執(zhí)行（Adaptive Query Execution，AQE）

AQE的定義是根據(jù)Spark任務運行時的數(shù)據(jù)，動態(tài)修改查詢計劃。因此它是一個優(yōu)化框架，而非特定功能，用戶可以擴展各種優(yōu)化規(guī)則。

社區(qū)版Spark自帶的優(yōu)化規(guī)則包括Shuffle分區(qū)合并、自動轉(zhuǎn)換為廣播Join、Join傾斜優(yōu)化等。我們基于Kyuubi進行功能擴展，比如自動合并小文件、末級Stage配置隔離等。其中，末級Stage配置隔離是一個非常好用的優(yōu)化規(guī)則，它允許在配置層面，為普通Stage和末級Stage分別配置處理并行度。

這樣，我們可以在末級Stage上按目標文件大小設置并行度，以合并小文件；在普通Stages上配置較高的并行度，加速任務處理，達成兩者兼顧的效果。

• 血緣集成Apache Atlas

愛奇藝內(nèi)部使用Apache Atlas管理數(shù)據(jù)血緣，為此我們將其元數(shù)據(jù)和血緣投遞的邏輯集成到了Kyuubi中，使得Kyuubi在運行Spark SQL任務時，能夠自動向Atlas投遞血緣。我們已將這一功能貢獻給了社區(qū)（KYUUBI #4814），將在即將發(fā)布的Kyuubi V1.8版本中可用。

• Apache Uniffle：Remote Shuffle Service

在Spark中使用Remote Shuffle Service是近兩年來比較流行的一個趨勢。愛奇藝采用的是Apache Uniffle這個開源產(chǎn)品。

在引入Apache Uniffle前，存在兩種問題：一個是Shuffle不穩(wěn)定，比如大數(shù)據(jù)量情況下，下載數(shù)據(jù)失敗，出現(xiàn)fetch failure的報錯；另一個是存算分離的云原生架構下，計算節(jié)點容量、IO性能不足。

引入Apache Uniffle后，原有問題得到改善：

• 減小磁盤IO壓力：利用內(nèi)存存儲數(shù)據(jù)，避免隨機IO
• 增強大數(shù)據(jù)量下的穩(wěn)定性：Shuffle 10TB以上不再失敗，可平穩(wěn)運行
• 提高Shuffle速度：1TB TeraSort 快30%+

愛奇藝作為Apache Uniffle的共同貢獻者，深度參與了社區(qū)討論和貢獻。歡迎大家試用并提出反饋意見。

4.從Hive遷移Spark SQL

圖片

在支持Spark SQL后，已有的大量Hive任務需要遷移過來。遷移過程會遇到兩種問題：

• 運行失?。篠park SQL的語法并不是100%兼容Hive，其語法更加嚴格；
• 數(shù)據(jù)不一致：相比于運行失敗更加麻煩，因為用戶無法立即發(fā)現(xiàn)，且對比數(shù)據(jù)一致性的工作也更加復雜。

為了解決遷移的問題，我們基于Pilot SQL網(wǎng)關開發(fā)了“雙跑對數(shù)”的功能，在遷移前自動預測遷移結果，運行步驟如下：

• SQL解析：輸入、輸出 
• 創(chuàng)建影子表：用戶模擬雙跑的輸出 
• 模擬運行：修改SQL的輸出表，指定Hive、Spark引擎分別運行 
• 結果一致性校驗：行數(shù)、CRC32（浮點型保留小數(shù)點后4位，避免因精度不同導致的判斷錯誤）

使用“雙跑對數(shù)”功能之后，我們在遷移的過程中發(fā)現(xiàn)了一些問題，其中有部分可以通過優(yōu)化Spark SQL的兼容性來解決，進一步降低用戶遷移的工作量：

• 支持UDAF/UDTF的私有化構造 
• 允許reflect拋出異常時返回NULL
• Hive參數(shù)映射到Spark參數(shù)，如 mapreduce.job.reduces→Spark.sql.shuffle.partitions

用戶在Hive中設置很多參數(shù)，比如reduce的個數(shù)，但這些參數(shù)在Spark中原本無法被識別，我們通過參數(shù)映射，將其轉(zhuǎn)化為Spark的相應參數(shù)，盡可能保留用戶的SQL邏輯。

最后，使用“自動降級”功能令遷移順利進行，即首次使用Spark運行失敗后，重試時降級為Hive引擎。由此，遷移分為兩個階段：第一階段開啟自動降級，用戶可以放心遷移，并通過降級的記錄梳理出遷移失敗的任務；第二階段，將這些失敗的任務修復后，再完全切換到Spark。

目前Hive遷移的總體進度已經(jīng)達成90%，對于這些遷移的任務，平均性能提升了67%，資源（包括CPU、內(nèi)存使用量）也降低了近一半。

5.Flink SQL + 統(tǒng)一元數(shù)據(jù)中心

圖片

在使用Spark SQL提高實時性的同時，我們也嘗試引入Flink SQL，希望能夠真正做到實時計算。但原生的Flink SQL如上示左圖，比Hive SQL長很多，需要定義輸入輸出表，字段名稱和類型，以及背后的數(shù)據(jù)源配置。應如何解決使用過程繁瑣的問題？

我們引入了“統(tǒng)一元數(shù)據(jù)中心”的概念，類似于Hive的Metastore。因為Hive具有Metastore，所以無需反復定義輸入輸出表，寫SQL非常簡單，如上圖中寫三行語句即可。

我們將內(nèi)部的各種數(shù)據(jù)，包括流式的Kafka和RocketMQ，傳統(tǒng)數(shù)據(jù)庫MySQL、Redis、HBase，以及數(shù)據(jù)湖產(chǎn)品，都集成到統(tǒng)一元數(shù)據(jù)中心，并開發(fā)了Flink Catalog、Flink Connectors與其對接。這樣依賴，我們無需在每個任務中，重新定義表的結構以及連接串等信息，做到開箱即用，有效提升開發(fā)效率。

6.SQL適合流計算開發(fā)

可能有同學會有疑問，SQL到底能否足夠表達流計算？

因為傳統(tǒng)SQL（比如Hive、MySQL），輸入是一個表，輸出也是一個表，從表到表的SQL究竟能否表達流式的計算邏輯？我們認為是可以的。

這個觀點具有理論支撐，一位來自Google的工程師Akidau在其著作《Streaming Systems》中，提出了流和表的“相對論”。他認為流和表本質(zhì)上是數(shù)據(jù)的兩種表現(xiàn)形式。他拆解了傳統(tǒng)SQL表到表的過程，將其拆分為表到流、流到表、流到流三種操作的組合。

以上圖右邊的SQL舉例，輸入是一組用戶得分，按照團隊進行聚合，計算出每個團隊的總分，輸出到新的表中。它的輸入表由4個字段組成：用戶、團隊、得分和時間。

讓我們來拆解這個SQL的執(zhí)行邏輯（假設這是離線計算）。首先，原始表并不是一次性加載到內(nèi)存的，而是通過一個SCAN算子，一條一條地讀入，變成內(nèi)部的流。然后經(jīng)過SELECT算子，去掉無用字段，保留team和score字段，得到了一個新的流。

最后，流的數(shù)據(jù)全部到齊后，一次性計算聚合的值，即把每個team的所有分數(shù)相加得到總分，再輸出到目標表。由此看出，第一個操作SCAN是表到流，第二個操作SELECT是流到流，第三個操作GROUP BY是流到表。

從上面的SQL執(zhí)行邏輯拆解可以看出，將傳統(tǒng)SQL描述為表到表的操作，黑盒地看是對的，但在微觀層面是不準確的，實際上是表到流、流到表、流到流三種操作的組合，唯一不存在的是直接的流到流的操作。

流計算的過程中包括很多要素，比如Map或Filter可以認為是一個流到流的操作，分組的聚合或窗口的聚合，就是流到表的過程；而通過定時的trigger或Watermark引起的trigger，是表到流的過程。

當把上面的SQL看成流計算時，會發(fā)現(xiàn)其拆解過程與離線計算一模一樣，都是由SCAN（表到流）、SELECT（流到流）、GROUP BY（流到表）組成的。

因此，SQL對于流計算和離線計算來說，沒有本質(zhì)區(qū)別，所以它非常適合流計算的開發(fā)。SQL開發(fā)優(yōu)勢如下：

• 開發(fā)門檻低：相較于通過Java/Scala代碼開發(fā)Flink任務，SQL的開發(fā)門檻較低。引入開箱即用的元數(shù)據(jù)后，SQL就更加簡潔，用戶無需學習Flink的API。
• 版本升級容易：Flink SQL對齊了SQL標準，語法相對穩(wěn)定，跨版本升級改動較小。
• 運行效率高：因為Flink SQL具有一些參數(shù)，控制SQL執(zhí)行的計劃優(yōu)化，無需復雜的代碼邏輯實現(xiàn)這些功能。

在愛奇藝的實時計算平臺上，目前SQL的任務占比已經(jīng)達到2/3，已經(jīng)能覆蓋大部分的功能，所以較推薦內(nèi)部用戶使用SQL進行流計算的開發(fā)。

7.Lambda到流批一體架構

圖片

我們在存儲側也做了技術革新。傳統(tǒng)方案使用Lambda架構，即離線一條通路、實時一條通路，在下游合并這兩條通路。但這種架構存在明顯問題：

• 離線通路時效性差，實時通路容量低
• 維護兩套邏輯，開發(fā)效率低
• 兩條通路數(shù)據(jù)不一致
• 維護多套服務，成本高

我們通過引入數(shù)據(jù)湖技術，可以做到流批一體架構，即使用Flink與數(shù)據(jù)湖交互，實時寫入、實時更新。數(shù)據(jù)湖技術解決了兩條鏈路、實時性、以及實時通路容量不足的問題。由于無需維護兩條通路，計算成本與存儲成本比之前的模式更低。

8.基于Iceberg的數(shù)據(jù)湖

圖片

愛奇藝選擇的數(shù)據(jù)湖產(chǎn)品是Apache Iceberg，其具體好處將通過案例介紹。

上圖是會員訂單分析的應用場景。愛奇藝的會員業(yè)務有10多年的歷史，每個會員訂單都對應一條記錄，訂單表存儲在MySQL中，這些表非常大。會員團隊進行用戶會員運營分析時，如果直接用MySQL對這些表進行查詢，速度非常慢，因為MySQL對這種OLAP分析的場景支持不佳。

最原始的方案是通路1（上圖標號1和2），先用內(nèi)部數(shù)據(jù)集成工具BabelX將MySQL表全量導出到Hive，再使用Hive、Spark SQL或Impala查詢。這條通路的問題是，MySQL的全量導出是一個天級別的任務，數(shù)據(jù)分析的時效性很差；每次導出的數(shù)據(jù)量很大，對MySQL產(chǎn)生很大壓力；每天都在反復導出相同的數(shù)據(jù)，效率很低。

后來會員團隊和我們合作了另外一條通路2（即上圖標號3和4），通過內(nèi)部工具，將MySQL的變更流實時導出到Kudu，用Impala進行查詢。Kudu介于HDFS和HBase之間，既有實時寫入的能力，又有分析型查詢能力。這條通路的問題在于：

• Impala+Kudu需要搭建單獨的集群，成本比較高；
• Kudu集群的擴展性差，因為集群上線只能達到幾十個節(jié)點；
• Impala+Kudu運維比較復雜，經(jīng)常出現(xiàn)故障。

基于這些痛點，我們調(diào)研后發(fā)現(xiàn)Iceberg比較適合完成這種任務，我們選擇了圖中最下面的新通路：通過內(nèi)部的RCP平臺，使用Flink CDC技術實時導出到Iceberg中，在下游使用Spark SQL進行查詢。

改造效果如下：

• 時延低：整體時延大幅降低，從原來的天級延遲可以降低到分鐘級
• 查詢快：我們對查詢性能進行了優(yōu)化，使其達到了接近Impala+Kudu的查詢性能
• 成本低：利用現(xiàn)成的HDFS集群，無需獨立部署
• 運維易：對MySQL壓力較小，鏈路穩(wěn)定，運維工作量也較小

在查詢性能上，我們做了兩處優(yōu)化：

1）小文件智能合并：Iceberg表在寫入過程中會產(chǎn)生很多小文件，積累到一定程度會嚴重影響查詢性能；而合并小文件時，如果每次都全表合并，又會造成嚴重的寫放大。為此我們開發(fā)了智能合并策略，基于分區(qū)下文件大小均方差，自動選擇待合并的分區(qū)，最大程度地避免了寫放大。

2）寫Parquet文件開啟BloomFilter：BloomFilter可以判斷一組數(shù)據(jù)中是否不含指定數(shù)據(jù)，被Parquet等存儲格式廣泛使用，用來降低讀取數(shù)據(jù)量。愛奇藝將這一特性集成到Iceberg中，在寫Parquet文件時允許開啟BloomFilter，在內(nèi)部場景中取得了很好的效果。這一功能已貢獻給社區(qū)（PR #4831）。

最終，查詢的時間從900秒降低到10秒，達到了交互式查詢的性能，很好地滿足了會員運營分析的需求。

三、愛奇藝實時計算平臺建設

1.平臺建設與數(shù)據(jù)處理架構

圖片

愛奇藝的實時計算主要又兩個平臺：負責通用型計算任務的RCP實時計算平臺、負責特定分析型需求的RAP實時分析平臺。

基于原始數(shù)據(jù)，可通過RCP進行通用分析，將結果寫入新的流、數(shù)據(jù)庫或Iceberg，供線上服務和數(shù)據(jù)分析直接使用。如需根據(jù)事件流，制作實時報表等特定的復雜目標，可使用RAP平臺。

2.RCP實時計算平臺

圖片

RCP（Real-time Computing Platform，愛奇藝統(tǒng)一實時計算平臺）的特點是：

• 流程完整：具備數(shù)據(jù)讀入、計算及分發(fā)的全流程
• 支持多種開發(fā)模式：JAR/SQL/DAG，其中DAG模式是對SQL模式的進一步簡化，通過圖形化界面配置即可完成開發(fā)
• 集成統(tǒng)一元數(shù)據(jù)中心：各種類型的數(shù)據(jù)源均由平臺統(tǒng)一注冊和管理

如上圖架構所示，Server層負責資源管理、任務管理、任務提交、監(jiān)控報警等功能。Launcher層負責直接提交任務到運行集群，這一層包含內(nèi)部的Flink版本和Spark版本，對于Flink，又包含了JAR/SQL/DAG引擎、接入統(tǒng)一元數(shù)據(jù)、以及各種數(shù)據(jù)源的connector。

1）接入傳統(tǒng)數(shù)據(jù)庫

圖片

RCP平臺能結合各個數(shù)據(jù)庫的Connnector，將傳統(tǒng)數(shù)據(jù)庫接入實時計算。

上圖是針對廣告庫存計算的實時化改造。業(yè)務需要對多個MySQL表做Join，寫入Redis中，供下游的實時任務查詢。

原有方案是，使用Spark批處理作業(yè)，每10分鐘全量拉取這些MySQL表，在Spark任務里進行Join。這個方案的問題是，每10分鐘進行全量拉表，對MySQL壓力較大，且整體寫入Redis的數(shù)據(jù)時效性較差，至少延遲10分鐘，這會導致業(yè)務數(shù)據(jù)的準確性下降。

改造后的方案見圖中綠框，我們采用Flink CDC的方案。在Flink任務中配置三個CDC的source，由此實現(xiàn)對MySQL全量同步以及自動轉(zhuǎn)增量拉取的過程；緊接著一個Join節(jié)點，負責實時計算Join結果。如此一來，Join的輸出是實時更新的結果，上游MySQL表的更新會實時地反映到Redis中。

改造效果：

• 將以上三個實時的表Join數(shù)據(jù)寫入Redis后，業(yè)務準確性明顯提升，達到7個9；
• 時效性方面，從20分鐘左右降低到秒級，降低了MySQL的服務壓力；
• 由于沒有重復的數(shù)據(jù)處理，資源節(jié)省了50%，處理效率大幅提升。

RCP支持了各類CDC connector，降低了將數(shù)據(jù)庫接入實時計算的門檻，主要的優(yōu)勢有：

• 可以實現(xiàn)存量+增量的無縫對接
• 對源庫影響較小
• 相較其他實時同步方案，F(xiàn)link方案可以實現(xiàn)讀取和數(shù)據(jù)加工的一體性，比如無需借助Kafka實時隊列，整個鏈路更加簡單。

2）故障診斷

RCP平臺支持故障診斷功能。針對單個任務，平臺可自助排查故障原因，如下圖所示：

• 日志分析：報錯信息，比如checkpoint失敗次數(shù)過多
• 指標分析：GC、流量傾斜指標等

圖片

3）鏈路血緣

如下圖所示，平臺展示了該任務上游、下游的血緣關系。

圖片

4）鏈路診斷

如果需要分析整條鏈路，平臺也提供了一鍵鏈路診斷的功能。只需點擊一下，即可對鏈路上的所有實時計算作業(yè)，進行健康度情況分析，獲取其最近的重啟次數(shù)和消費延遲等信息。

圖片

3.RAP實時分析平臺

圖片

愛奇藝RAP（Real-time Analytics Platform）實時分析平臺，提供一站式的大數(shù)據(jù)攝取、計算和分析能力，支持超大規(guī)模實時數(shù)據(jù)多維度的分析，并生成分鐘級延時的可視化報表。主要特色是：

• 提供實時、多維度的聚合分析
• 配置化：通過頁面配置完成大部分功能，相較實時計算平臺更簡單
• 實時報表：自動生成的可視化報表（內(nèi)部BI平臺+Grafana）
• 實時報警、數(shù)據(jù)接口

RAP的架構包含4個模塊：

• 數(shù)據(jù)源接入方面，支持公司內(nèi)部各流式數(shù)據(jù)源；
• 數(shù)據(jù)處理方面，通過RCP平臺或Druid KIS進行；
• 兩個OLAP引擎包括Druid和ClickHouse；
• 最后將可視化報表發(fā)布在Grafana或內(nèi)部BI平臺。

1）典型案例

圖片

上圖是一張直播報表，展示直播實時的卡頓比（HCDN團隊）情況。

右圖是直播期間每分鐘的總UV值（同步在線人數(shù)），只需三個步驟就能完成該報表的配置：

• 首先選擇接入數(shù)據(jù)源：此處選擇一張Iceberg表（用戶行為表），包含時間、設備ID、事件類型、app版本、運營商、省份等字段。
• 然后配置模型：指明時間戳字段，計算哪些指標，哪些字段是維度
• 最后報表配置：指明用戶想要的報表展現(xiàn)方式

總體來說，只需少量的頁面操作，即可配置一張實時報表，整個過程非常迅速。原先使用通用型工具開發(fā)此類報表，可能需要一周時間，但在RAP進行配置，僅需小時級別的時間，并且支持靈活的需求變更。目前，RAP平臺已在愛奇藝的直播、會員監(jiān)控等業(yè)務中廣泛應用。

四、未來展望

下一步，愛奇藝實時計算的發(fā)展方向包括：

• 實時計算SQL化：進一步提升SQL化的比例，豐富 SQL化的配套支持，比如調(diào)試功能，增強使用SQL開發(fā)的便捷性。
• 實時化的數(shù)據(jù)集成平臺：基于配置化的方式，完成同種數(shù)據(jù)源的不同集群、甚至不同種類數(shù)據(jù)源之間的數(shù)據(jù)同步。
• 流批一體新方案探索：跟進社區(qū)新動向，比如Hybrid Source和Apache Paimon等流批一體的存儲和計算產(chǎn)品。

Q&A

Q1：實時計算平臺后續(xù)演進規(guī)劃是怎樣的？

A1：進一步提升SQL化開發(fā)的成熟度，優(yōu)化調(diào)試和診斷功能，對Flink SQL進行性能優(yōu)化，流批一體。

Q2：數(shù)據(jù)服務支持實時計算的同時，能否保存所有數(shù)據(jù)？存儲有期限嗎？

A2：可以，Iceberg存儲利用HDFS集群實現(xiàn)，其容量非常大。但用戶仍需要配置期限，無論何種數(shù)據(jù)、何種容量，所有數(shù)據(jù)都無限保存是不實際的，成本方面也不經(jīng)濟。

Q3：實時計算場景有必要提升到秒級延遲嗎？

A3：延遲級別由業(yè)務場景決定。比如天級別的運營報表本身具有意義，如果提升到秒級，數(shù)據(jù)量非常大，就失去了統(tǒng)計意義。但如果是前文分享的廣告案例，數(shù)據(jù)越實時，準確性越高，業(yè)務上的效果就越好。

Q4：RCP和Apache DolphinScheduler一樣嗎？

A4：不一樣，DolphinScheduler具有工作流調(diào)度的功能，RCP主要負責實時計算的流任務管理。

劉騁昺

•  愛奇藝 大數(shù)據(jù)團隊 高級經(jīng)理
• 愛奇藝大數(shù)據(jù)計算組負責人，負責愛奇藝大數(shù)據(jù)計算服務、實時計算平臺、實時分析平臺、機器學習平臺等系統(tǒng)的建設工作，擁有豐富的大數(shù)據(jù)領域?qū)崙?zhàn)經(jīng)驗。