本文是實(shí)時(shí)流計(jì)算 2018 年終盤(pán)點(diǎn)，作者對(duì)實(shí)時(shí)流計(jì)算技術(shù)的發(fā)展現(xiàn)狀進(jìn)行了深入剖析，并對(duì)當(dāng)前大火的各個(gè)主流實(shí)時(shí)流計(jì)算框架做了全面、客觀的對(duì)比，同時(shí)對(duì)未來(lái)流計(jì)算可能的發(fā)展方向進(jìn)行預(yù)測(cè)和展望。

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

今年除了正在熱火落地的 AI 技術(shù)，實(shí)時(shí)流計(jì)算技術(shù)也開(kāi)始步入主流，各大廠都在不遺余力地試用新的流計(jì)算框架，升級(jí)替換 Storm 這類舊系統(tǒng)。上半年 P2P 狂想曲的驟然破滅，讓企業(yè)開(kāi)始正視價(jià)值投資。互聯(lián)網(wǎng)下半場(chǎng)已然開(kāi)始，線上能夠榨錢的不多了，所以，技術(shù)和資本開(kāi)始賦能線下，如拼多多這類奇思妙想劍走偏鋒實(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)等等，人們無(wú)法忍受長(zhǎng)時(shí)間等待，等待意味著訂單流失。所以，毫秒級(jí)、亞秒級(jí)大數(shù)據(jù)分析就凸顯極大價(jià)值。流計(jì)算框架和批計(jì)算幾乎同時(shí)起步，只不過(guò)流計(jì)算現(xiàn)在能挖掘更大的利益價(jià)值，才會(huì)火起來(lái)。

實(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 恰好一次的可靠性語(yǔ)義不能保證。不丟數(shù)據(jù)、不重復(fù)數(shù)據(jù)、不丟也不重地恰好送達(dá)，是不同可靠性層次。Clojure 提供的 LISP 方言反人類語(yǔ)法，學(xué)習(xí)成本極為陡峭。后來(lái)阿里中間件團(tuán)隊(duì)另起爐灶開(kāi)發(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ù)說(shuō)在 twitter 內(nèi)部替換了 Storm，也經(jīng)過(guò)了大規(guī)模業(yè)務(wù)驗(yàn)證。但是，Heron 明顯不那么活躍，乏善可陳。值得一提的是，Heron 的存儲(chǔ)用了 twitter 開(kāi)源的另一個(gè)框架 DistributedLog。

DistributedLog、Bookkeeper、Pulsar、Pravega：大家寫(xiě) 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)化了讀寫(xiě)性能。又能跑在 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)景做到舍我其誰(shuí)，或許還有機(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)求且不死，可以說(shuō)是高性能計(jì)算中的奇葩戰(zhàn)斗機(jī)。Gearpum 自從主力離職后項(xiàng)目進(jìn)展不大，且在低功耗的 IoT 場(chǎng)景里沒(méi)有好的表現(xiàn)，又干不過(guò) 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 似乎拼不過(guò)。

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è)人感覺(jué)，危機(jī)大于機(jī)遇。

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

后來(lái)者 Flink

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

Stratosphere項(xiàng)目最早在 2010 年 12 月由德國(guó)柏林理工大學(xué)教授 Volker Markl 發(fā)起，主要開(kāi)發(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ǔ)，開(kāi)發(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

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

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

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

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

 

 

Spark RDD 關(guān)系圖。圖片來(lái)自 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ù)降低使用門(mén)檻，Spark 社區(qū)開(kāi)始開(kāi)發(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)來(lái)的無(wú)限數(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ū)，雞賊式緩解亂序問(wèn)題。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 語(yǔ)義，支持 at-least-once 語(yǔ)義。同時(shí)，微批作業(yè)打了快照，作業(yè)改為流式模式重啟作業(yè)是不兼容的。這一點(diǎn)不如 Flink 做的完美。

綜上，Spark Streaming 和 Structured Streaming 是用批計(jì)算的思路做流計(jì)算。其實(shí)，用流計(jì)算的思路開(kāi)發(fā)批計(jì)算才是最優(yōu)雅的。對(duì) Spark 來(lái)講，大換血不大可能，只有局部?jī)?yōu)化。其實(shí)，Spark 里 core、streaming、structured streaming、graphx 四個(gè)模塊，是四種實(shí)現(xiàn)思路，通過(guò)上層 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 連接起來(lái)，兩個(gè) netty 之間 keepalive，網(wǎng)絡(luò) buffer 是自然反壓的關(guān)鍵。經(jīng)過(guò)邏輯優(yōu)化和物理優(yōu)化，Dataflow 的邏輯關(guān)系和運(yùn)行時(shí)的物理拓?fù)湎嗖畈淮�。這是純粹的流式設(shè)計(jì)，時(shí)延和吞吐理論上是最優(yōu)的。

Flink 在流批計(jì)算上沒(méi)有包袱，一開(kāi)始就走在對(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 將無(wú)限輸入流保存在狀態(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，各說(shuō)各好。benchmark 雞肋不可信，筆者測(cè)試的結(jié)果，F(xiàn)link 和 Spark 的吞吐和時(shí)延都比較接近。

反壓

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

狀態(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)，通過(guò)協(xié)調(diào)者機(jī)制對(duì)齊多個(gè)并行度的算子中的狀態(tài)數(shù)據(jù)，把狀態(tài)數(shù)據(jù)異步持久化。

Flink 打快照的方式，是筆者見(jiàn)過(guò)最為優(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ú)疑能降低網(wǎng)絡(luò)和磁盤(pán)開(kāi)銷。

Spark 的快照 API 是 RDD 基礎(chǔ)能力，定時(shí)開(kāi)啟快照后，會(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)，但也有來(lái)自 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ò)過(guò)了 AI 最佳切入時(shí)機(jī)。這兩年 Spark+AI 勢(shì)頭正勁，Matei 教授的論文 Weld 想通過(guò) monad 把批、流、圖、ML、TensorFlow 等多個(gè)系統(tǒng)粘合起來(lái)，統(tǒng)一底層優(yōu)化，想法很贊;處于 beta 階段的 MLFlow 項(xiàng)目，把 ML 的生命周期全部管理起來(lái)，這些都是 Spark 新的突破點(diǎn)。

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

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

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

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

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

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

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

 

 

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

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

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

IoT 技術(shù)快速成熟，賦能了車聯(lián)網(wǎng)、工業(yè)、智慧城市、O2O 等線下場(chǎng)景。線下數(shù)據(jù)高速增長(zhǎng)，敏感數(shù)據(jù)不上云，數(shù)據(jù)量太大無(wú)法上云，毫秒級(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í)算法推理。視頻攝像頭隨處可見(jiàn)，4K 高清攝像頭也越來(lái)越普遍，交警蜀黎的罰單開(kāi)的越來(lái)越省心。視頻流如果全部實(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ì)算常見(jiàn)的應(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ù)，單純地寫(xiě)一寫(xiě)腳本和開(kāi)發(fā)應(yīng)用程序，已經(jīng)無(wú)法滿足這些復(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)景，都可以問(wèn)一下，如果是實(shí)時(shí)的，是否能產(chǎn)生更大價(jià)值?

去新白鹿用二維碼點(diǎn)餐，會(huì)享受到快速上菜和在線結(jié)賬;叫個(gè)外賣打個(gè)車，要是等十分鐘沒(méi)反應(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è)問(wèn)題：

♦ 數(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)》正式生效，都說(shuō)明法律要管控?cái)?shù)據(jù)亂象了。

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

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

目前常見(jiàn)的流計(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 年華為就開(kāi)始了自研的 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)過(guò)雙 11 的流量檢驗(yàn)，目前較為活躍。

總結(jié) & 展望

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

StreamingML 在線機(jī)器學(xué)習(xí)

StreamingGraph 在線圖計(jì)算

StreamingAI 實(shí)時(shí) AI

流批合一

流存儲(chǔ)

實(shí)時(shí)流計(jì)算 + 邊緣計(jì)算、工業(yè) IoT、車聯(lián)網(wǎng)、智慧城市

作者介紹

時(shí)金魁，華為云高級(jí)技術(shù)專家，負(fù)責(zé)華為云實(shí)時(shí)流計(jì)算服務(wù)。多年來(lái)從事高性能計(jì)算和大數(shù)據(jù)方面的工作，近兩年專注于 Flink 和 Spark 及周邊生態(tài)框架的研究和產(chǎn)品落地。曾就職于搜狐、淘寶和阿里云。標(biāo)準(zhǔn)的 Scala 程序員。

標(biāo)簽： Google isp O2O 安全 大數(shù)據(jù) 大數(shù)據(jù)分析 大數(shù)據(jù)開(kāi)發(fā) 大數(shù)據(jù)平臺(tái) 代碼 電商 公有云 谷歌 互聯(lián)網(wǎng) 腳本 金融 開(kāi)發(fā)者 媒體 數(shù)據(jù)分析 搜索 推廣

版權(quán)申明：本站文章部分自網(wǎng)絡(luò)，如有侵權(quán)，請(qǐng)聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點(diǎn)！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請(qǐng)與原作者聯(lián)系。