摘要：本文由阿里巴巴技術(shù)專(zhuān)家賀小令（曉令）分享，主要介紹 Apache Flink 新場(chǎng)景 OLAP 引擎，內(nèi)容分為以下四部分：

背景介紹

Flink OLAP 引擎

案例介紹

未來(lái)計(jì)劃

一、背景介紹

1.OLAP 及其分類(lèi)

OLAP 是一種讓用戶(hù)可以用從不同視角方便快捷的分析數(shù)據(jù)的計(jì)算方法。主流的 OLAP 可以分為3類(lèi)：多維 OLAP ( Multi-dimensional OLAP )、關(guān)系型 OLAP ( Relational OLAP ) 和混合 OLAP ( Hybrid OLAP ) 三大類(lèi)。

（1）多維 OLAP ( MOLAP )

傳統(tǒng)的 OLAP 分析方式
數(shù)據(jù)存儲(chǔ)在多維數(shù)據(jù)集中

（2）關(guān)系型 OLAP ( ROLAP )

以關(guān)系數(shù)據(jù)庫(kù)為核心，以關(guān)系型結(jié)構(gòu)進(jìn)行多維數(shù)據(jù)的表示
通過(guò) SQL 的 where 條件以呈現(xiàn)傳統(tǒng) OLAP 的切片、切塊功能

（3）混合 OLAP ( HOLAP )

將 MOLAP 和 ROLPA 的優(yōu)勢(shì)結(jié)合起來(lái)，以獲得更快的性能

以下將詳細(xì)介紹每種分類(lèi)的具體特征。

■ 多維 OLAP ( MOLAP )

MOLAP 的典型代表是 Kylin 和 Druid。

• MOLAP 處理流程

首先，對(duì)原始數(shù)據(jù)做數(shù)據(jù)預(yù)處理；然后，將預(yù)處理后的數(shù)據(jù)存至數(shù)據(jù)倉(cāng)庫(kù)，用戶(hù)的請(qǐng)求通過(guò) OLAP server 即可查詢(xún)數(shù)據(jù)倉(cāng)庫(kù)中的數(shù)據(jù)。

• MOLAP 的優(yōu)點(diǎn)和缺點(diǎn)

MOLAP 的優(yōu)點(diǎn)和缺點(diǎn)都來(lái)自于其數(shù)據(jù)預(yù)處理 ( pre-processing ) 環(huán)節(jié)。數(shù)據(jù)預(yù)處理，將原始數(shù)據(jù)按照指定的計(jì)算規(guī)則預(yù)先做聚合計(jì)算，這樣避免了查詢(xún)過(guò)程中出現(xiàn)大量的臨時(shí)計(jì)算，提升了查詢(xún)性能，同時(shí)也為很多復(fù)雜的計(jì)算提供了支持。

但是這樣的預(yù)聚合處理，需要預(yù)先定義維度，會(huì)限制后期數(shù)據(jù)查詢(xún)的靈活性；如果查詢(xún)工作涉及新的指標(biāo)，需要重新增加預(yù)處理流程，損失了靈活度，存儲(chǔ)成本也很高；同時(shí)，這種方式不支持明細(xì)數(shù)據(jù)的查詢(xún)。

因此，MOLAP 適用于對(duì)性能要求非常高的場(chǎng)景。

■ 關(guān)系型 OLAP ( ROLAP )

ROLAP 的典型代表是 Presto 和 Impala。

• 處理流程

ROLAP 的處理流程上，用戶(hù)的請(qǐng)求直接發(fā)送給 OLAP server，然后 OLAP server 將用戶(hù)的請(qǐng)求轉(zhuǎn)換成關(guān)系型操作算子，再通過(guò) SCAN 掃描原始數(shù)據(jù)，在原始數(shù)據(jù)基礎(chǔ)上做過(guò)濾、聚合、關(guān)聯(lián)等處理，最后將計(jì)算結(jié)果返回給用戶(hù)。

• ROLAP 的優(yōu)點(diǎn)和缺點(diǎn)

ROLAP 不需要進(jìn)行數(shù)據(jù)預(yù)處理 ( pre-processing )，因此查詢(xún)靈活，可擴(kuò)展性好。這類(lèi)引擎使用 MPP 架構(gòu) ( 與Hadoop相似的大型并行處理架構(gòu)，可以通過(guò)擴(kuò)大并發(fā)來(lái)增加計(jì)算資源 )，可以高效處理大量數(shù)據(jù)。

但是當(dāng)數(shù)據(jù)量較大或 query 較為復(fù)雜時(shí)，查詢(xún)性能也無(wú)法像 MOLAP 那樣穩(wěn)定。所有計(jì)算都是臨時(shí)發(fā)生 ( 沒(méi)有預(yù)處理 )，因此會(huì)耗費(fèi)更多的計(jì)算資源。

因此，ROLAP 適用于對(duì)查詢(xún)靈活性高的場(chǎng)景。

■ 混合 OLAP ( HOLAP )

混合 OLAP，是 MOLAP 和 ROLAP 的一種融合。當(dāng)查詢(xún)聚合性數(shù)據(jù)的時(shí)候，使用MOLAP 技術(shù)；當(dāng)查詢(xún)明細(xì)數(shù)據(jù)時(shí)，使用 ROLAP 技術(shù)。在給定使用場(chǎng)景的前提下，以達(dá)到查詢(xún)性能的最優(yōu)化。

2.Apache Flink 介紹

■ Flink 支持的應(yīng)用場(chǎng)景

Apache Flink 支持的3種典型應(yīng)用場(chǎng)景：

（1）事件驅(qū)動(dòng)的應(yīng)用

• 反欺詐
• 基于規(guī)則的監(jiān)控報(bào)警

（2）流式 Pipeline

• 數(shù)據(jù) ETL
• 實(shí)時(shí)搜索引擎的索引

（3）批處理 & 流處理分析

• 網(wǎng)絡(luò)質(zhì)量監(jiān)控
• 消費(fèi)者實(shí)時(shí)數(shù)據(jù)分析

■ Flink 架構(gòu)及優(yōu)勢(shì)

Flink 的整體架構(gòu)如上圖所示，在此架構(gòu)下，Flink 的優(yōu)勢(shì)也十分突出，主要分為6個(gè)方面：

（1）統(tǒng)一框架 ( 不區(qū)分流處理和批處理 )

• 用戶(hù) API 統(tǒng)一
• 執(zhí)行引擎統(tǒng)一

（2）多層次 API

• 標(biāo)準(zhǔn) SQL APL
• Table API
• DataStream API ( 靈活，無(wú) schema 限制 )

（3）高性能

• 支持內(nèi)存計(jì)算
• 支持代價(jià)模型優(yōu)化
• 支持代碼動(dòng)態(tài)生成

（4）方便集成

• 支持豐富的 Connectors
• 方便對(duì)接現(xiàn)有 Catalog

（5）靈活的 Failover 策略

• 在 Pipeline 下支持快速 failover
• 類(lèi)似 MapReduce、Spark 一樣支持 shuffle 數(shù)據(jù)落盤(pán)

（6）易部署維護(hù)

• 靈活部署方案
• 支持高可用

二、Apache Flink OLAP 引擎

1.為什么 Flink 可以做 ROLAP 引擎？

• Flink 的核心和基礎(chǔ)是流計(jì)算，支持高性能、低延遲的大規(guī)模計(jì)算。
• Blink 將批看作有限流，批處理是針對(duì)有限數(shù)據(jù)集的優(yōu)化，因此批處理引擎也是構(gòu)建在流引擎上 ( 已開(kāi)源 )。
• OLAP 是響應(yīng)時(shí)間要求更短的批處理，因此 OLAP 可以看作是一種特殊的批。OLAP 引擎也可以構(gòu)建在現(xiàn)有的批引擎上。

注：Flink OLAP 引擎目前不帶存儲(chǔ)，只是一個(gè)計(jì)算框架。

2.Flink 做 OLAP 引擎的優(yōu)勢(shì)

（1）統(tǒng)一引擎：流處理、批處理、OLAP 統(tǒng)一使用 Flink 引擎。

降低學(xué)習(xí)成本，僅需要學(xué)習(xí)一個(gè)引擎
提高開(kāi)發(fā)效率，很多 SQL 是流批通用
提高維護(hù)效率，可以更集中維護(hù)好一個(gè)引擎

（2）既有優(yōu)勢(shì)：利用 Flink 已有的很多特性，使 OLAP 使用場(chǎng)景更為廣泛。

使用流處理的內(nèi)存計(jì)算、Pipeline
支持代碼動(dòng)態(tài)生成
也可以支持批處理數(shù)據(jù)落盤(pán)能力

（3）相互增強(qiáng)：OLAP 能享有現(xiàn)有引擎的優(yōu)勢(shì)，同時(shí)也能增強(qiáng)引擎能力

• 無(wú)統(tǒng)計(jì)信息場(chǎng)景的優(yōu)化
• 開(kāi)發(fā)更高效的算子
• 使 Flink 同時(shí)兼?zhèn)淞?、批、OLAP 處理的能力，成為更通用的框架

3.性能優(yōu)化

OLAP 對(duì)查詢(xún)時(shí)間非常敏感，當(dāng)前很多組件的性能不滿(mǎn)足要求，因此我們對(duì) Flink 做了很多相關(guān)優(yōu)化。

■ 服務(wù)架構(gòu)的優(yōu)化

• 客戶(hù)端服務(wù)化

下圖介紹了一條 SQL 怎么在客戶(hù)端一步一步變?yōu)?JobGraph，最終提交給 JM：

在改動(dòng)之前，每次接受一個(gè) query 時(shí)會(huì)啟動(dòng)一個(gè)新的 JVM 進(jìn)程來(lái)進(jìn)行作業(yè)的編譯。其中 JVM 的啟動(dòng)、Class 的加載、代碼的動(dòng)態(tài)編譯 ( 如 Optimizer 模塊由于需要通過(guò) Janino 動(dòng)態(tài)編譯進(jìn)行 cost 計(jì)算 ) 等操作都非常耗時(shí) ( 需要約3~5s )。因此，我們將客戶(hù)端進(jìn)行服務(wù)化，將整個(gè) Client 做成 Service，當(dāng)接收到用戶(hù)的 query 時(shí)，無(wú)需重復(fù)各項(xiàng)加載工作，可將延時(shí)降低至 100ms 左右。

• 自定義 CollectionTableSink
  

這部分優(yōu)化，源于 OLAP 的一個(gè)特性：OLAP 會(huì)將最終計(jì)算結(jié)果發(fā)給客戶(hù)端，通過(guò)JobManager 轉(zhuǎn)發(fā)給 Client。假如某個(gè) query 的結(jié)果數(shù)據(jù)量很大，會(huì)讓 JobManager OOM ( OutOfMemory )；如果同時(shí)執(zhí)行多個(gè) query，也會(huì)相互影響。

因此，我們從新實(shí)現(xiàn)了一個(gè) CollectionTableSink，限制數(shù)據(jù)的條數(shù)和數(shù)據(jù)大小，避免出現(xiàn) OOM，保證多個(gè) Query 同時(shí)運(yùn)行時(shí)的穩(wěn)定性。

• 調(diào)度優(yōu)化

在 Batch 模式下的調(diào)度存在以下問(wèn)題：

• 使用 Lazy_from_sources 模式調(diào)度，會(huì)導(dǎo)致整體運(yùn)行時(shí)間較長(zhǎng)，也可能造成死鎖。
• RM ( Resource Manager ) 按 OnDemand 方式分配 Slot 需求，也會(huì)造成死鎖。
• RM 以單線程同步模式向 TM ( Transaction Manager ) 分配 Slot 請(qǐng)求，會(huì)造成等待時(shí)間更長(zhǎng)。

注：調(diào)度死鎖是指在資源有限的情況下，多個(gè) Job 同時(shí)運(yùn)行時(shí)，如果多個(gè) Job都只申請(qǐng)到了部分資源并沒(méi)有剩余資源可以申請(qǐng)，導(dǎo)致 Job 沒(méi)法繼續(xù)執(zhí)行，新的 Job 也沒(méi)法提交。

針對(duì)上述問(wèn)題，我們提出了以下幾點(diǎn)改動(dòng)：

• 采用 Eager 調(diào)度模式 ( 確保所有的資源都申請(qǐng)到后才開(kāi)始運(yùn)行 )。
• 使用 FIFO ( 先進(jìn)先出隊(duì) ) 模式申請(qǐng)資源 ( 確保當(dāng)前 Job 的資源分配結(jié)束后才開(kāi)始下一個(gè) Job 的資源分配 )。
• 將單線程同步模式改為多線程異步模式，減少任務(wù)啟動(dòng)時(shí)間和執(zhí)行時(shí)間。

■ 針對(duì) source 的優(yōu)化

在 ROLAP 的執(zhí)行場(chǎng)景中，所有數(shù)據(jù)都是通過(guò)掃描原始數(shù)據(jù)表后進(jìn)行處理；因此，基于 Source 的讀取性能非常關(guān)鍵，直接影響 Job 的執(zhí)行效率。

• Project&Filter 下堆

像 Parquet 這類(lèi)的列存文件格式，支持按需讀取相所需列，同時(shí)支持 RowGroup 級(jí)別的過(guò)濾。利用該特性，可以將 Project 和 Filter 下推到 TableSource，從而只需要掃描 Query 中涉及的字段和滿(mǎn)足條件的 RowGroup，大大提升讀取效率。

• Aggregate 下堆

這個(gè)優(yōu)化也是充分利用了 TableSource 的特性：例如 Parquet 文件的 metadata 中已經(jīng)存儲(chǔ)了每個(gè) RowGroup 的統(tǒng)計(jì)信息 ( 如 max、min等 )，因此在做 max、min 這類(lèi)聚合統(tǒng)計(jì)時(shí)，可直接讀取 metadata 信息，而不需要先讀取所有原始數(shù)據(jù)再計(jì)算。

■ 在沒(méi)有統(tǒng)計(jì)信息場(chǎng)景下做的優(yōu)化

• 消除 CrossJoin

CrossJoin 是沒(méi)有任何 Join 條件，將 Join 的兩張表的數(shù)據(jù)做笛卡爾積，導(dǎo)致 Join 的結(jié)果膨脹非常厲害，這類(lèi) Join 應(yīng)該盡量避免。我們對(duì)含有 CrossJoin 的 Plan 進(jìn)行改寫(xiě)：將有 join 條件的表格先做 join ( 通常會(huì)因?yàn)橐恍?shù)據(jù) Join 不上而減少數(shù)據(jù) )，從而提高執(zhí)行效率。這是一個(gè)確定性的改寫(xiě)，即使在沒(méi)有統(tǒng)計(jì)信息的情況下，也可以使用該優(yōu)化。

• 自適應(yīng)的 Local Aggregate

通常情況下，兩階段的 Aggregate 是非常高效的，因?yàn)?LocalAggregate 能聚合大量數(shù)據(jù)，導(dǎo)致 Shuffle 的數(shù)據(jù)量會(huì)變少。但是當(dāng) LocalAggregate 的聚合度很低的時(shí)候， Local 聚合操作的意義不大，反而會(huì)浪費(fèi) CPU。

在沒(méi)有任何統(tǒng)計(jì)信息的情況下，優(yōu)化器沒(méi)法決定是否要產(chǎn)生 LocalAggregate 算子；因此，我們采用運(yùn)行時(shí)采樣的方式來(lái)判斷聚合度，如果聚合度低于設(shè)定的閾值，我們將關(guān)閉聚合操作，改為僅做數(shù)據(jù)轉(zhuǎn)發(fā)；經(jīng)我們測(cè)試，部分場(chǎng)景有 30% 的性能提升。

4.測(cè)試結(jié)果

上圖是 Flink 和 Presto基于 1T 數(shù)據(jù)做的 SSB ( Star Schema Benchmark ) 測(cè)試，從圖中可以看出 Flink 和 Presto 整體上不相上下，甚至有些 Query Flink 性能優(yōu)于Presto。

注：Flink OLAP 從開(kāi)始到嘉賓分享時(shí)，只有3個(gè)月時(shí)間。

案例介紹

1.Flink OLAP 在數(shù)據(jù)探查上的應(yīng)用

上圖描述了一個(gè)數(shù)據(jù)湖應(yīng)用的完整架構(gòu)，Flink OLAP 主要用于"數(shù)據(jù)探查"。

數(shù)據(jù)探查是對(duì)數(shù)據(jù)結(jié)構(gòu)做智能判斷，給出數(shù)據(jù)的探查結(jié)果，快速了解數(shù)據(jù)的信息和質(zhì)量情況。即用戶(hù)可以在管控平臺(tái)上了解數(shù)據(jù)湖中任意一份數(shù)據(jù)的數(shù)據(jù)特性。用戶(hù)通過(guò) Web 交互操作選擇相應(yīng)的表和指標(biāo)后立即展示相關(guān)結(jié)果指標(biāo)，因此要求低延遲、實(shí)時(shí)反饋。而且數(shù)據(jù)湖中很多數(shù)據(jù)沒(méi)有任何統(tǒng)計(jì)信息；前述的各種查詢(xún)、聚合層面的優(yōu)化，主要為這類(lèi)場(chǎng)景服務(wù)。

2.整體架構(gòu)

上圖是這類(lèi)應(yīng)用的整體架構(gòu)。整套服務(wù)托管到 Kubernetes 上，最終訪問(wèn)的數(shù)據(jù)是OSS。

未來(lái)計(jì)劃

當(dāng)前，Flink OLAP 引擎性能優(yōu)化及應(yīng)用主要是基于內(nèi)部 Flink，后續(xù)工作主要分為以下三塊：

推回社區(qū)：目前所有工作都是基于內(nèi)部 Flink，希望推回社區(qū)；

資源隔離：后期很多功能的開(kāi)發(fā)和優(yōu)化會(huì)圍繞多 Query 運(yùn)行時(shí)的"資源隔離"；

優(yōu)化&性能：圍繞 OLAP 的特性，在此場(chǎng)景下會(huì)進(jìn)一步做優(yōu)化和性能提升等方面的工作。

原文鏈接
本文為云棲社區(qū)原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。

總結(jié)

以上是生活随笔為你收集整理的Flink 新场景：OLAP 引擎性能优化及应用案例的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

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