轉(zhuǎn)載本文需注明出處：微信公眾號EAWorld，違者必究。

本文介紹了 SparkSQL 和 Flink 對于批流支持的特性以及批流一體化支持框架的難點。在介紹批流一體化實現(xiàn)的同時，重點分析了基于普元 SparkSQL－Flow 框架對批流支持的一種實現(xiàn)方式。希望對大家的工作有所幫助，也希望能對 DatasetFlow 模型作為框架實現(xiàn)提供一些啟發(fā)。

目錄：

1．SparkSQL 和 Flink 對于批流支持的特性介紹

2．基于SparkSQL－Flow的批量分析框架

3．基于SparkStreaming SQL模式的流式處理支持

4．對于批流一體化ETL的思考

一、SparkSQL 和 Flink

對于批流支持的特性介紹

關(guān)于流和批的一些爭論

對于廣泛使用的Spark和新秀Flink，對于批和流實現(xiàn)方式上，以及在論壇和一些文章上，對批和流都有不同看法。批是流的特例 還是 流是批的特例？

1．從批的角度看，流是多個批次一份一份的進(jìn)行。無限個這樣批次構(gòu)成整個流處理流程，類如SparkStreaming的處理模式；

2．從流的角度看，批是流的有限流處理。它只不過在某個時間點，完成某個條件停止了而已；類如 Flink 的處理模式；

Spark 和 Flink 都具有流和批處理能力，但是他們的做法是截然相反。Spark Streaming是把流轉(zhuǎn)化成一個個小的批來處理，這種方案的一個問題是我們需要的延遲越低，額外開銷占的比例就會越大，這導(dǎo)致了Spark Streaming很難做到秒級甚至亞秒級的延遲。Flink是把批當(dāng)作一種有限的流，這種做法的一個特點是在流和批共享大部分代碼的同時還能夠保留批處理特有的一系列的優(yōu)化。數(shù)據(jù)倉庫早期以及大數(shù)據(jù)早期都是從批處理開始的，所以很多系統(tǒng)都是從批處理做起，包括Spark。在批處理上Spark有著較深的積累，是一個比較優(yōu)秀的系統(tǒng)。隨著技術(shù)的發(fā)展，很多原來只有批處理的業(yè)務(wù)都有了實時的需求，流處理將會變得越來越重要，甚至成為一些數(shù)據(jù)分析的主要場景，如實時管控、預(yù)警相關(guān)。

Spark 和 Flink 的異同點

Flink 早期僅支持流式處理，這幾年的Flink無論從API組織，還是運(yùn)行方式，還是多樣性都越來越像Spark。

批和流是數(shù)據(jù)融合的兩種應(yīng)用形態(tài)

傳統(tǒng)的數(shù)據(jù)融合通�；�于批模式。在批的模式下，我們會通過一些周期性運(yùn)行的ETL JOB，將數(shù)據(jù)從關(guān)系型數(shù)據(jù)庫、文件存儲向下游的目標(biāo)數(shù)據(jù)庫進(jìn)行同步，中間可能有各種類型的轉(zhuǎn)換。

與批模式相比相比， 其最核心的區(qū)別是將批量變?yōu)閷崟r：輸入的數(shù)據(jù)不再是周期性的去獲取，而是源源不斷的來自于業(yè)務(wù)的日志、消息隊列的消息。進(jìn)而通過一個實時計算引擎，進(jìn)行各種聚合運(yùn)算，產(chǎn)生輸出結(jié)果，并且寫入下游。Spark 和 Flink 都能夠支持批和流兩種概念。只不過像 Flink，其原生就是為流而生，所以在流處理上更自然。

Spark 是有太多包袱，Spark 最早采用 RDD 模型，達(dá)到比 MapReduce 計算快 100 倍的顯著優(yōu)勢，對 Hadoop 生態(tài)大幅升級換代。RDD 彈性數(shù)據(jù)集是分割為固定大小的批數(shù)據(jù)，自動容錯、位置感知、本地計算、可調(diào)度可伸縮等眾多重要特性。RDD 提供了豐富的底層 API 對數(shù)據(jù)集做操作，為持續(xù)降低使用門檻，Spark 社區(qū)開始開發(fā)高階 API：DataFrame／DataSet，Spark SQL 作為統(tǒng)一的 API，掩蓋了底層，同時針對性地做 SQL 邏輯優(yōu)化和物理優(yōu)化。Spark 早期的主要目標(biāo)是替代 MapReduce，MapReduce 是大數(shù)據(jù)批處理的核心模型。