解讀 2018：13 家開源框架誰能統(tǒng)一流計(jì)算？

018 年接近尾聲，我018 年接近尾聲，我策劃了“解讀 2018”年終技術(shù)盤點(diǎn)系列文章，希望能夠給讀者清晰地梳理出重要技術(shù)領(lǐng)域在這一年來的發(fā)展和變化。本文是實(shí)時(shí)流計(jì)算 2018 年終盤點(diǎn)，作者對(duì)實(shí)時(shí)流計(jì)算技術(shù)的發(fā)展現(xiàn)狀進(jìn)行了深入剖析，并對(duì)當(dāng)前大火的各個(gè)主流實(shí)時(shí)流計(jì)算框架做了全面、客觀的對(duì)比，同時(shí)對(duì)未來流計(jì)算可能的發(fā)展方向進(jìn)行預(yù)測(cè)和展望。
策劃了“解讀 2018”年終技術(shù)盤點(diǎn)系列文章，希望能夠給讀者清晰地梳理出重要技術(shù)領(lǐng)域在這一年來的發(fā)展和變化。本文是實(shí)時(shí)流計(jì)算 2018 年終盤點(diǎn)，作者對(duì)實(shí)時(shí)流計(jì)算技術(shù)的發(fā)展現(xiàn)狀進(jìn)行了深入剖析，并對(duì)當(dāng)前大火的各個(gè)主流實(shí)時(shí)流計(jì)算框架做了全面、客觀的對(duì)比，同時(shí)對(duì)未來流計(jì)算可能的發(fā)展方向進(jìn)行預(yù)測(cè)和展望。

今年實(shí)時(shí)流計(jì)算技術(shù)為何這么火

今年除了正在熱火落地的 AI 技術(shù)，實(shí)時(shí)流計(jì)算技術(shù)也開始步入主流，各大廠都在不遺余力地試用新的流計(jì)算框架，升級(jí)替換 Storm 這類舊系統(tǒng)。上半年 P2P 狂想曲的驟然破滅，讓企業(yè)開始正視價(jià)值投資?；ヂ?lián)網(wǎng)下半場(chǎng)已然開始，線上能夠榨錢的不多了，所以，技術(shù)和資本開始賦能線下，如拼多多這類奇思妙想劍走偏鋒實(shí)在不多。

而物聯(lián)網(wǎng)這個(gè)早期熱炒的領(lǐng)域連接線上線下，如今已積累的足夠。物聯(lián)網(wǎng)卡包年資費(fèi)降到百元以下，NB-IoT 技術(shù)的興起在畜牧業(yè)、新農(nóng)業(yè)、城市管理方面都凸顯極大價(jià)值。各大廠都在血拼智能城市、智慧工廠、智慧醫(yī)療、車聯(lián)網(wǎng)等實(shí)體領(lǐng)域。但，這些跟實(shí)時(shí)流計(jì)算有幾毛錢的關(guān)系？

上述領(lǐng)域有一個(gè)共同的特點(diǎn)，那就是實(shí)時(shí)性。城市車流快速移動(dòng)、工廠流水線不等人、醫(yī)院在排號(hào)、叫的外賣在快跑，打車、點(diǎn)餐、網(wǎng)購(gòu)等等，人們無法忍受長(zhǎng)時(shí)間等待，等待意味著訂單流失。所以，毫秒級(jí)、亞秒級(jí)大數(shù)據(jù)分析就凸顯極大價(jià)值。流計(jì)算框架和批計(jì)算幾乎同時(shí)起步，只不過流計(jì)算現(xiàn)在能挖掘更大的利益價(jià)值，才會(huì)火起來。

實(shí)時(shí)流計(jì)算框架一覽

目前首選的流計(jì)算引擎主要是 Flink 和 Spark，第二梯隊(duì) Kafka、Pulsar，小眾的有 Storm、JStorm、nifi、samza 等。下面逐一簡(jiǎn)單介紹下每個(gè)系統(tǒng)優(yōu)缺點(diǎn)。

Flink 和 Spark是分布式流計(jì)算的首選，下文會(huì)單獨(dú)對(duì)二者做對(duì)比分析。

Storm、JStorm、Heron：較早的流計(jì)算平臺(tái)。相對(duì)于 MapReduce，Storm 為流計(jì)算而生，是早期分布式流計(jì)算框架首選。但 Storm 充其量是個(gè)半成品，ack 機(jī)制并不優(yōu)雅，exactly-once 恰好一次的可靠性語義不能保證。不丟數(shù)據(jù)、不重復(fù)數(shù)據(jù)、不丟也不重地恰好送達(dá)，是不同可靠性層次。Clojure 提供的 LISP 方言反人類語法，學(xué)習(xí)成本極為陡峭。后來阿里中間件團(tuán)隊(duì)另起爐灶開發(fā)了 JStorm。JStorm 在架構(gòu)設(shè)計(jì)理念上比 Storm 好些，吞吐、可靠性、易用性都有大幅提升，容器化跟上了大勢(shì)。遺憾的是，阿里還有 Blink（Flink 改進(jìn)版），一山不容二虎，JStorm 團(tuán)隊(duì)擁抱變化，項(xiàng)目基本上停滯了。另起爐灶的還有 twitter 團(tuán)隊(duì)，搞了個(gè) Heron，據(jù)說在 twitter 內(nèi)部替換了 Storm，也經(jīng)過了大規(guī)模業(yè)務(wù)驗(yàn)證。但是，Heron 明顯不那么活躍，乏善可陳。值得一提的是，Heron 的存儲(chǔ)用了 twitter 開源的另一個(gè)框架 DistributedLog。

DistributedLog、Bookkeeper、Pulsar、Pravega：大家寫 Spark Streaming 作業(yè)時(shí)，一定對(duì)里面 kafka 接收到數(shù)據(jù)后，先保存到 WAL（write ahead log）的代碼不陌生。DistributedLog 就是一個(gè)分布式的 WAL（write ahead log）框架，提供毫秒級(jí)時(shí)延，保存多份數(shù)據(jù)確保數(shù)據(jù)可靠性和一致性，優(yōu)化了讀寫性能。又能跑在 Mesos 和 Yarn 上，同時(shí)提供了多租戶能力，這跟公有云的多租戶和企業(yè)多租戶特性契合。Bookeeper 就是對(duì) DistributedLog 的再次封裝，提供了高層 API 和新的特性。而 Pulsar 則是自己重點(diǎn)做計(jì)算和前端數(shù)據(jù)接入，趕上了 serverless 潮流，提供輕量級(jí)的 function 用于流計(jì)算，而存儲(chǔ)交給了 DistributedLog。Pulsar 在流計(jì)算方面有新意，但也只是對(duì) Flink 和 Spark 這類重量級(jí)框架的補(bǔ)充。筆者認(rèn)為，Pulsar 如果能在 IoT 場(chǎng)景做到舍我其誰，或許還有機(jī)會(huì)。 Pravega 是 Dell 收購(gòu)的團(tuán)隊(duì)，做流存儲(chǔ)，內(nèi)部也是使用 Bookeeper，主要用于 IoT 場(chǎng)景。四者關(guān)系大致如此。

Beam、Gearpump、Edgent：巨頭的布局。三個(gè)項(xiàng)目都進(jìn)入 Apache 基金會(huì)了。Beam 是 Google 的，Gearpump 是 Intel 的，Edgent 是 IBM 的，三巨頭提前對(duì)流計(jì)算做出了布局。Gearpump 是以 Akka 為核心的分布式輕量級(jí)流計(jì)算，Akka stream 和 Akka http 模塊享譽(yù)技術(shù)圈。Spark 早期的分布式消息傳遞用 Akka，F(xiàn)link 一直用 Akka 做模塊間消息傳遞。Akka 類似 erlang，采用 Actor 模型，對(duì)線程池充分利用，響應(yīng)式、高性能、彈性、消息驅(qū)動(dòng)的設(shè)，CPU 跑滿也能響應(yīng)請(qǐng)求且不死，可以說是高性能計(jì)算中的奇葩戰(zhàn)斗機(jī)。Gearpum 自從主力離職后項(xiàng)目進(jìn)展不大，且在低功耗的 IoT 場(chǎng)景里沒有好的表現(xiàn)，又干不過 Flink 和 Spark。Edgent 是為 IoT 而生的，內(nèi)嵌在網(wǎng)關(guān)或邊緣設(shè)備上，實(shí)時(shí)分析流數(shù)據(jù)，目前還在 ASF 孵化中。物聯(lián)網(wǎng)和邊緣計(jì)算要依托 Top 級(jí)的云廠商才能風(fēng)生水起，而各大廠商都有 IoT 主力平臺(tái)，僅靠 Edgent 似乎拼不過。

Kafka Stream： Kafka 是大數(shù)據(jù)消息隊(duì)列標(biāo)配，基于 log append-only，得益于零拷貝，Kafka 成為大數(shù)據(jù)場(chǎng)景做高吞吐的發(fā)布訂閱消息隊(duì)列首選。如今，不甘寂寞的 Kafka 也干起了流計(jì)算，要處理簡(jiǎn)單的流計(jì)算場(chǎng)景，Kafka SQL 是夠用的。但計(jì)算和存儲(chǔ)分離是行業(yè)共識(shí)，資源受限的邊緣計(jì)算場(chǎng)景需要考慮計(jì)算存儲(chǔ)一體化。重量級(jí)的 Kafka 在存儲(chǔ)的同時(shí)支持流分析，有點(diǎn)大包大攬。第一，存儲(chǔ)計(jì)算界限不明確，都在 Kafka 內(nèi)；第二，Kafka 架構(gòu)陳舊笨重，與基于 DistributedLog 的流存儲(chǔ)體系相比仍有差距；計(jì)算上又不如 Pulsar 等輕量。Kafka Stream SQL 輪子大法跟 Flink SQL 和 Spark SQL 有不小差距。個(gè)人感覺，危機(jī)大于機(jī)遇。

實(shí)時(shí)流計(jì)算技術(shù)的進(jìn)一步發(fā)展，需要 IoT、工業(yè) IoT、智慧 xx 系列、車聯(lián)網(wǎng)等新型行業(yè)場(chǎng)景催生，同時(shí)背靠大樹才好活。

后來者 Flink

Flink 到 16 年才開始嶄露頭角，不得不八卦一下其發(fā)家史。

Stratosphere項(xiàng)目最早在 2010 年 12 月由德國(guó)柏林理工大學(xué)教授 Volker Markl 發(fā)起，主要開發(fā)人員包括 Stephan Ewen、Fabian Hueske。Stratosphere 是以 MapReduce 為超越目標(biāo)的系統(tǒng)，同時(shí)期有加州大學(xué)伯克利 AMP 實(shí)驗(yàn)室的 Spark。相對(duì)于 Spark，Stratosphere 是個(gè)徹底失敗的項(xiàng)目。所以 Volker Markl 教授參考了谷歌的流計(jì)算最新論文 MillWheel，決定以流計(jì)算為基礎(chǔ)，開發(fā)一個(gè)流批結(jié)合的分布式流計(jì)算引擎 Flink。Flink 于 2014 年 3 月進(jìn)入 Apache 孵化器并于 2014 年 11 月畢業(yè)成為 Apache 頂級(jí)項(xiàng)目。

流批合一，是以流為基礎(chǔ)，批是流的特例或上層 API；批流合一，是以批計(jì)算為基礎(chǔ)，微批為特例，粘合模擬流計(jì)算。

Spark vs. Flink

丑話說在前面，筆者無意于撩撥 Flink 和 Spark 兩個(gè)群體的矛盾，社區(qū)間取長(zhǎng)補(bǔ)短也好，互相抄襲也好，都不是個(gè)事，關(guān)鍵在于用戶群體的收益。

在各種會(huì)上，經(jīng)常會(huì)被問到 Spark 和 Flink 的區(qū)別，如何取舍？

下面從數(shù)據(jù)模型、運(yùn)行時(shí)架構(gòu)、調(diào)度、時(shí)延和吞吐、反壓、狀態(tài)存儲(chǔ)、SQL 擴(kuò)展性、生態(tài)、適用場(chǎng)景等方面來逐一分析。

數(shù)據(jù)模型

Spark RDD 關(guān)系圖。圖片來自 JerryLead 的 SparkInternals 項(xiàng)目

Flink 框架圖

Flink 運(yùn)行時(shí)
Spark 的數(shù)據(jù)模型

Spark 最早采用 RDD 模型，達(dá)到比 MapReduce 計(jì)算快 100 倍的顯著優(yōu)勢(shì)，對(duì) Hadoop 生態(tài)大幅升級(jí)換代。RDD 彈性數(shù)據(jù)集是分割為固定大小的批數(shù)據(jù)，RDD 提供了豐富的底層 API 對(duì)數(shù)據(jù)集做操作。為持續(xù)降低使用門檻，Spark 社區(qū)開始開發(fā)高階 API：DataFrame/DataSet，Spark SQL 作為統(tǒng)一的 API，掩蓋了底層，同時(shí)針對(duì)性地做 SQL 邏輯優(yōu)化和物理優(yōu)化，非堆存儲(chǔ)優(yōu)化也大幅提升了性能。

Spark Streaming 里的 DStream 和 RDD 模型類似，把一個(gè)實(shí)時(shí)進(jìn)來的無限數(shù)據(jù)分割為一個(gè)個(gè)小批數(shù)據(jù)集合 DStream，定時(shí)器定時(shí)通知處理系統(tǒng)去處理這些微批數(shù)據(jù)。劣勢(shì)非常明顯，API 少、難勝任復(fù)雜的流計(jì)算業(yè)務(wù)，調(diào)大吞吐量而不觸發(fā)背壓是個(gè)體力活。不支持亂序處理，把前面的 Kafka topic 設(shè)置為 1 個(gè)分區(qū)，雞賊式緩解亂序問題。Spark Streaming 僅適合簡(jiǎn)單的流處理，會(huì)被 Structured Streaming 完全替代。

Spark Structured Streaming 提供了微批和流式兩個(gè)處理引擎。微批的 API 雖不如 Flink 豐富，窗口、消息時(shí)間、trigger、watermarker、流表 join、流流 join 這些常用的能力都具備了。時(shí)延仍然保持最小 100 毫秒。當(dāng)前處在試驗(yàn)階段的流式引擎，提供了 1 毫秒的時(shí)延，但不能保證 exactly-once 語義，支持 at-least-once 語義。同時(shí)，微批作業(yè)打了快照，作業(yè)改為流式模式重啟作業(yè)是不兼容的。這一點(diǎn)不如 Flink 做的完美。

綜上，Spark Streaming 和 Structured Streaming 是用批計(jì)算的思路做流計(jì)算。其實(shí)，用流計(jì)算的思路開發(fā)批計(jì)算才是最優(yōu)雅的。對(duì) Spark 來講，大換血不大可能，只有局部?jī)?yōu)化。其實(shí)，Spark 里 core、streaming、structured streaming、graphx 四個(gè)模塊，是四種實(shí)現(xiàn)思路，通過上層 SQL 統(tǒng)一顯得不純粹和諧。

Flink 的數(shù)據(jù)模型

Flink 采用 Dataflow 模型，和 Lambda 模式不同。Dataflow 是純粹的節(jié)點(diǎn)組成的一個(gè)圖，圖中的節(jié)點(diǎn)可以執(zhí)行批計(jì)算，也可以是流計(jì)算，也可以是機(jī)器學(xué)習(xí)算法，流數(shù)據(jù)在節(jié)點(diǎn)之間流動(dòng)，被節(jié)點(diǎn)上的處理函數(shù)實(shí)時(shí) apply 處理，節(jié)點(diǎn)之間是用 netty 連接起來，兩個(gè) netty 之間 keepalive，網(wǎng)絡(luò) buffer 是自然反壓的關(guān)鍵。經(jīng)過邏輯優(yōu)化和物理優(yōu)化，Dataflow 的邏輯關(guān)系和運(yùn)行時(shí)的物理拓?fù)湎嗖畈淮?。這是純粹的流式設(shè)計(jì)，時(shí)延和吞吐理論上是最優(yōu)的。

Flink 在流批計(jì)算上沒有包袱，一開始就走在對(duì)的路上。

運(yùn)行時(shí)架構(gòu)

Spark 運(yùn)行時(shí)架構(gòu)

批計(jì)算是把 DAG 劃分為不同 stage，DAG 節(jié)點(diǎn)之間有血緣關(guān)系，在運(yùn)行期間一個(gè) stage 的 task 任務(wù)列表執(zhí)行完畢，銷毀再去執(zhí)行下一個(gè) stage；Spark Streaming 則是對(duì)持續(xù)流入的數(shù)據(jù)劃分一個(gè)批次，定時(shí)去執(zhí)行批次的數(shù)據(jù)運(yùn)算。Structured Streaming 將無限輸入流保存在狀態(tài)存儲(chǔ)中，對(duì)流數(shù)據(jù)做微批或?qū)崟r(shí)的計(jì)算，跟 Dataflow 模型比較像。

Flink 運(yùn)行時(shí)架構(gòu)

Flink 有統(tǒng)一的 runtime，在此之上可以是 Batch API、Stream API、ML、Graph、CEP 等，DAG 中的節(jié)點(diǎn)上執(zhí)行上述模塊的功能函數(shù)，DAG 會(huì)一步步轉(zhuǎn)化成 ExecutionGraph，即物理可執(zhí)行的圖，最終交給調(diào)度系統(tǒng)。節(jié)點(diǎn)中的邏輯在資源池中的 task 上被 apply 執(zhí)行，task 和 Spark 中的 task 類似，都對(duì)應(yīng)線程池中的一個(gè)線程。

在流計(jì)算的運(yùn)行時(shí)架構(gòu)方面，F(xiàn)link 明顯更為統(tǒng)一且優(yōu)雅一些。

時(shí)延和吞吐

兩家測(cè)試的 Yahoo benchmark，各說各好。benchmark 雞肋不可信，筆者測(cè)試的結(jié)果，F(xiàn)link 和 Spark 的吞吐和時(shí)延都比較接近。

反壓

Flink 中，下游的算子消費(fèi)流入到網(wǎng)絡(luò) buffer 的數(shù)據(jù)，如果下游算子處理能力不夠，則阻塞網(wǎng)絡(luò) buffer，這樣也就寫不進(jìn)數(shù)據(jù)，那么上游算子發(fā)現(xiàn)無法寫入，則逐級(jí)把壓力向上傳遞，直到數(shù)據(jù)源，這種自然反壓的方式非常合理。Spark Streaming 是設(shè)置反壓的吞吐量，到達(dá)閾值就開始限流，從批計(jì)算上來看是合理的。

狀態(tài)存儲(chǔ)

Flink 提供文件、內(nèi)存、RocksDB 三種狀態(tài)存儲(chǔ)，可以對(duì)運(yùn)行中的狀態(tài)數(shù)據(jù)異步持久化。打快照的機(jī)制是給 source 節(jié)點(diǎn)的下一個(gè)節(jié)點(diǎn)發(fā)一條特殊的 savepoint 或 checkpoint 消息，這條消息在每個(gè)算子之間流動(dòng)，通過協(xié)調(diào)者機(jī)制對(duì)齊多個(gè)并行度的算子中的狀態(tài)數(shù)據(jù)，把狀態(tài)數(shù)據(jù)異步持久化。

Flink 打快照的方式，是筆者見過最為優(yōu)雅的一個(gè)。Flink 支持局部恢復(fù)快照，作業(yè)快照數(shù)據(jù)保存后，修改作業(yè)，DAG 變化，啟動(dòng)作業(yè)恢復(fù)快照，新作業(yè)中未變化的算子的狀態(tài)仍舊可以恢復(fù)。而且 Flink 也支持增量快照，面對(duì)內(nèi)存超大狀態(tài)數(shù)據(jù)，增量無疑能降低網(wǎng)絡(luò)和磁盤開銷。

Spark 的快照 API 是 RDD 基礎(chǔ)能力，定時(shí)開啟快照后，會(huì)對(duì)同一時(shí)刻整個(gè)內(nèi)存數(shù)據(jù)持久化。Spark 一般面向大數(shù)據(jù)集計(jì)算，內(nèi)存數(shù)據(jù)較大，快照不宜太頻繁，會(huì)增加集群計(jì)算量。

SQL 擴(kuò)展性

Flink 要依賴 Apache Calcite 項(xiàng)目的 Stream SQL API，而 Spark 則完全掌握在自己手里，性能優(yōu)化做的更足。大數(shù)據(jù)領(lǐng)域有一個(gè)共識(shí)：SQL 是一等公民，SQL 是用戶界面。SQL 的邏輯優(yōu)化和物理優(yōu)化，如 Cost based optimizer 可以在下層充分優(yōu)化。UDX 在 SQL 之上可以支持在線機(jī)器學(xué)習(xí) StreamingML、流式圖計(jì)算、流式規(guī)則引擎等。由于 SQL 遍地，很難有一個(gè)統(tǒng)一的 SQL 引擎適配所有框架，一個(gè)個(gè) SQL-like 煙囪同樣增加使用者的學(xué)習(xí)成本。

生態(tài)和適用場(chǎng)景

這兩個(gè)方面 Spark 更有優(yōu)勢(shì)。

Spark 在各大廠實(shí)踐多年，跟 HBase、Kafka、AWS OBS 磨合多年，已經(jīng)成為大數(shù)據(jù)計(jì)算框架的事實(shí)標(biāo)準(zhǔn)，但也有來自 TensorFlow 的壓力。14 年在生產(chǎn)環(huán)境上跑機(jī)器學(xué)習(xí)算法，大多會(huì)選擇 Spark，當(dāng)時(shí)我們團(tuán)隊(duì)還提了個(gè) ParameterServer 的 PR，社區(qū)跟進(jìn)慢也就放棄了。社區(qū)為趕造 SQL，錯(cuò)過了 AI 最佳切入時(shí)機(jī)。這兩年 Spark+AI 勢(shì)頭正勁，Matei 教授的論文 Weld 想通過 monad 把批、流、圖、ML、TensorFlow 等多個(gè)系統(tǒng)粘合起來，統(tǒng)一底層優(yōu)化，想法很贊；處于 beta 階段的 MLFlow 項(xiàng)目，把 ML 的生命周期全部管理起來，這些都是 Spark 新的突破點(diǎn)。

反觀 Flink 社區(qū)，對(duì)周邊的大數(shù)據(jù)存儲(chǔ)框架支持較好，但在 FlinkML 和 Gelly 圖計(jì)算方面投入極匱乏，16 年給社區(qū)提 PS 和流式機(jī)器學(xué)習(xí)，沒一點(diǎn)進(jìn)展。筆者在華為云這兩年多時(shí)間，選擇了 Flink 作為流計(jì)算平臺(tái)核心，索性在 Flink 基礎(chǔ)之上開發(fā)了 StreamingML、Streaming Time GeoSpatial、CEP SQL 這些高級(jí)特性，等社區(qū)搞，黃花菜都涼了。

企業(yè)和開發(fā)者對(duì)大數(shù)據(jù) AI 框架的選擇，是很重的技術(shù)投資，選錯(cuò)了損失會(huì)很大。不僅要看框架本身，還要看背后的公司。

Spark 后面是 Databricks，Databricks 背靠伯克利分校，Matei、Reynold Xin、孟祥瑞等高手如云。Databricks Platform 選擇 Azure，14 年 DB 就用改造 notebook 所見即所得的大數(shù)據(jù)開發(fā)平臺(tái)，前瞻性強(qiáng)，同時(shí)對(duì) AWS 又有很好的支持。商業(yè)和技術(shù)上都是無可挑剔的。

Flink 后面是 DataArtisans，今年也推出了 data Artisans Platform，筆者感覺沒太大新意，對(duì)公有云私有云沒有很好的支持。DataArtisans 是德國(guó)公司，團(tuán)隊(duì)二三十人，勤勉活躍在 Flink 社區(qū)，商業(yè)上或許勢(shì)力不足。

開源項(xiàng)目后面的商業(yè)公司若不在，項(xiàng)目本身必然走向滅亡，純粹靠分散的發(fā)燒友的力量無法支撐一個(gè)成功的開源項(xiàng)目。Databricks 估值 1.4 億美元，DataArtisans 估值 600 萬美元，23 倍的差距。DataArtisans 的風(fēng)險(xiǎn)在于變現(xiàn)能力，因?yàn)楸P子小所以有很大風(fēng)險(xiǎn)被端盤子，好在 Flink 有個(gè)好的 Dataflow 底子。這也是每個(gè)開源項(xiàng)目的難題，既要商業(yè)支撐開銷，又要中立發(fā)展。

對(duì)比小結(jié)

啰嗦這么多，對(duì)比下 Flink 和 Spark：

Flink 和 Spark 在流計(jì)算方面各有優(yōu)缺點(diǎn)，分值等同。Flink 在流批計(jì)算方面已經(jīng)成熟，Spark 還有很大提升空間，此消彼長(zhǎng)，未來不好說。

邊緣計(jì)算的機(jī)會(huì)

邊緣計(jì)算近兩年概念正盛，其中依靠的大數(shù)據(jù)能力主要是流計(jì)算。公有云、私有云、混合云這么成熟，為何會(huì)冒出來個(gè)邊緣計(jì)算？

IoT 技術(shù)快速成熟，賦能了車聯(lián)網(wǎng)、工業(yè)、智慧城市、O2O 等線下場(chǎng)景。線下數(shù)據(jù)高速增長(zhǎng)，敏感數(shù)據(jù)不上云，數(shù)據(jù)量太大無法上云，毫秒級(jí)以下的時(shí)延，這些需求催生了靠近業(yè)務(wù)的邊緣計(jì)算。在資源受限的硬件設(shè)備上，業(yè)務(wù)數(shù)據(jù)流實(shí)時(shí)產(chǎn)生，需要實(shí)時(shí)處理流數(shù)據(jù)，一般可以用 lambda 跑腳本，實(shí)時(shí)大數(shù)據(jù)可以運(yùn)行 Flink。華為云已商用的 IEF 邊緣計(jì)算服務(wù)，在邊緣側(cè)跑的就是 Flink lite，Azure 的流計(jì)算也支持流作業(yè)下發(fā)到邊緣設(shè)備上運(yùn)行。

邊緣設(shè)備上不僅可以運(yùn)行腳本和 Flink，也可以執(zhí)行機(jī)器學(xué)習(xí)和深度學(xué)習(xí)算法推理。視頻攝像頭隨處可見，4K 高清攝像頭也越來越普遍，交警蜀黎的罰單開的越來越省心。視頻流如果全部實(shí)時(shí)上傳到數(shù)據(jù)中心，成本不劃算，如果這些視頻流數(shù)據(jù)能在攝像頭上或攝像頭周邊完成人臉識(shí)別、物體識(shí)別、車牌識(shí)別、物體移動(dòng)偵測(cè)、漂浮物檢測(cè)、拋灑物檢測(cè)等，然后把視頻片段和檢測(cè)結(jié)果上傳，將極大節(jié)省流量。這就催生了低功耗 AI 芯片如昇騰 310、各種智能攝像頭和邊緣盒子。

Flink 這類能敏捷瘦身且能力不減的流計(jì)算框架，正適合在低功耗邊緣盒子上大展身手?？梢耘芤恍?CEP 規(guī)則引擎、在線機(jī)器學(xué)習(xí) Streaming、實(shí)時(shí)異常檢測(cè)、實(shí)時(shí)預(yù)測(cè)性維護(hù)、ETL 數(shù)據(jù)清洗、實(shí)時(shí)告警等。

行業(yè)應(yīng)用場(chǎng)景

實(shí)時(shí)流計(jì)算常見的應(yīng)用場(chǎng)景有：日志分析、物聯(lián)網(wǎng)、NB-IoT、智慧城市、智慧工廠、車聯(lián)網(wǎng)、公路貨運(yùn)、高速公路監(jiān)測(cè)、鐵路、客運(yùn)、梯聯(lián)網(wǎng)、智能家居、ADAS 高級(jí)輔助駕駛、共享單車、打車、外賣、廣告推薦、電商搜索推薦、股票交易市場(chǎng)、金融實(shí)時(shí)智能反欺詐等。只要實(shí)時(shí)產(chǎn)生數(shù)據(jù)、實(shí)時(shí)分析數(shù)據(jù)能產(chǎn)生價(jià)值，那么就可以用實(shí)時(shí)流計(jì)算技術(shù)，單純地寫一寫腳本和開發(fā)應(yīng)用程序，已經(jīng)無法滿足這些復(fù)雜的場(chǎng)景需求。

數(shù)據(jù)計(jì)算越實(shí)時(shí)越有價(jià)值，Hadoop 造就的批計(jì)算價(jià)值已被榨干。在線機(jī)器學(xué)習(xí)、在線圖計(jì)算、在線深度學(xué)習(xí)、在線自動(dòng)學(xué)習(xí)、在線遷移學(xué)習(xí)等都有實(shí)時(shí)流計(jì)算的影子。對(duì)于離線學(xué)習(xí)和離線分析應(yīng)用場(chǎng)景，都可以問一下，如果是實(shí)時(shí)的，是否能產(chǎn)生更大價(jià)值？

去新白鹿用二維碼點(diǎn)餐，會(huì)享受到快速上菜和在線結(jié)賬；叫個(gè)外賣打個(gè)車，要是等十分鐘沒反應(yīng)，必須要取消訂單?；ヂ?lián)網(wǎng)催化各個(gè)行業(yè)，實(shí)時(shí)計(jì)算是其中潮頭，已***在生活、生產(chǎn)、環(huán)境的方方面面。

對(duì)比各家云廠商的流計(jì)算服務(wù)

不重復(fù)造輪子已成業(yè)界共識(shí)。使用公有云上 serverless 大數(shù)據(jù) AI 服務(wù)（全托管、按需收費(fèi)、免運(yùn)維），會(huì)成為新的行業(yè)共識(shí)。高增長(zhǎng)的企業(yè)構(gòu)筑大數(shù)據(jù) AI 基礎(chǔ)設(shè)施需要較高代價(jià)且周期不短，長(zhǎng)期維護(hù)成本也高。

企業(yè)上云主要擔(dān)心三個(gè)問題：

數(shù)據(jù)安全，數(shù)據(jù)屬于企業(yè)核心資產(chǎn)；
被廠商鎖定；
削弱自身技術(shù)能力。
對(duì)于數(shù)據(jù)安全，國(guó)內(nèi)的《網(wǎng)絡(luò)安全法》已經(jīng)正式實(shí)施，對(duì)個(gè)人隱私數(shù)據(jù)保護(hù)有法可依；另外歐盟 GDPR《通用數(shù)據(jù)保護(hù)條例（General Data Protection Regulation）》正式生效，都說明法律要管控?cái)?shù)據(jù)亂象了。

選擇中立的云廠商很關(guān)鍵。云廠商大都會(huì)選擇開源系統(tǒng)作為云服務(wù)的基石，如果擔(dān)心被鎖定，用戶選擇云服務(wù)的時(shí)候留意下內(nèi)核就好。當(dāng)然，這會(huì)導(dǎo)致開源社區(qū)和云廠商的矛盾，提供企業(yè)化大數(shù)據(jù)平臺(tái)可能會(huì)被公有云搶生意，開源社區(qū)要活下去，DataBricks 跟 Azure 的合作例子就是聰明的選擇。

擔(dān)心削弱公司技術(shù)能力，倒是不必。未來大數(shù)據(jù)框架會(huì)越來越傻瓜化，運(yùn)維和使用門檻也會(huì)越來越低，企業(yè)不如把主要精力聚焦于用大數(shù)據(jù)創(chuàng)造價(jià)值上，不為了玩數(shù)據(jù)而玩數(shù)據(jù)，是為了 make more money。

目前常見的流計(jì)算服務(wù)包括：

AWS Kinesis
Azure 流分析
Huawei Cloud 實(shí)時(shí)流計(jì)算服務(wù)
Aliyun 實(shí)時(shí)計(jì)算
AWS Kinesis 流計(jì)算服務(wù)推出較早，目前已經(jīng)比較成熟，提供 serverless 能力，按需收費(fèi)、全托管、動(dòng)態(tài)擴(kuò)容縮容，是 AWS 比較賺錢的產(chǎn)品。Kinesis 包含 Data Streams、Data Analytics、Data Firehose、Video Streams 四個(gè)部分。Data Streams 做數(shù)據(jù)接入，Data Firehose 做數(shù)據(jù)加載和轉(zhuǎn)儲(chǔ)，Data Analytics 做實(shí)時(shí)流數(shù)據(jù)分析，Video Streams 用于流媒體的接入、編解碼和持久化等。Azure 的流分析做的也不錯(cuò)，主打 IoT 和邊緣計(jì)算場(chǎng)景。從 Kinesis 和 Azure 流分析能看出，IoT 是流分析的主戰(zhàn)場(chǎng)。產(chǎn)品雖好，國(guó)內(nèi)用的不多，數(shù)據(jù)中心有限而且貴。

華為云實(shí)時(shí)流計(jì)算服務(wù)是以 Flink 和 Spark 為核心的 serverless 流計(jì)算服務(wù)，早在 2012 年華為就開始了自研的 StreamSmart 產(chǎn)品，廣泛在海外交付。由于生態(tài)閉源，團(tuán)隊(duì)放棄了 StreamSmart，轉(zhuǎn)投 Flink 和 Spark 雙引擎。提供 StreamSQL 為主的產(chǎn)品特性：CEP SQL、StreamingML、Time GeoSpartial 時(shí)間地理位置分析、實(shí)時(shí)可視化等高級(jí)特性。首創(chuàng)獨(dú)享集群模式，提供用戶間物理隔離，即使是兩個(gè)競(jìng)爭(zhēng)對(duì)手也可以同時(shí)使用實(shí)時(shí)流計(jì)算服務(wù)，用戶之間物理隔離也斷絕了用戶間突破沙箱的小心思。

阿里云的流計(jì)算服務(wù)，最早是基于 Storm 的 galaxy 系統(tǒng)，同樣是基于 StreamSQL，產(chǎn)品早年不溫不火。自從去年流計(jì)算徹底轉(zhuǎn)變，內(nèi)核改為 Flink，經(jīng)過雙 11 的流量檢驗(yàn)，目前較為活躍。

總結(jié) & 展望

實(shí)時(shí)流計(jì)算技術(shù)已經(jīng)成熟，大家可以放心使用。目前的問題在于應(yīng)用場(chǎng)景推廣，提升企業(yè)對(duì)云廠商的信任度，廣泛應(yīng)用流計(jì)算創(chuàng)造價(jià)值。而流計(jì)算與 AI 的結(jié)合，也會(huì)是未來可能的方向：