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

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

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

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

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

實時流計算框架一覽

 

 

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

Flink 和 Spark是分布式流計算的首選，下文會單獨對二者做對比分析。

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

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

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

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

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

后來者 Flink

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

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

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

Spark vs. Flink

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

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

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

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

 

 

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

 

 

Flink 框架圖

 

 

Flink 運行時

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

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

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

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

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

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

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

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

運行時架構(gòu)

Spark 運行時架構(gòu)

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

Flink 運行時架構(gòu)

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

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

時延和吞吐

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

反壓

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

狀態(tài)存儲

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

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

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

SQL 擴展性

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

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

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

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

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

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

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

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

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

對比小結(jié)

啰嗦這么多，對比下 Flink 和 Spark：

 

 

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

邊緣計算的機會

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

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

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

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

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

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

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

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

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

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

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

♦ 數(shù)據(jù)安全，數(shù)據(jù)屬于企業(yè)核心資產(chǎn);

♦ 被廠商鎖定;

♦ 削弱自身技術(shù)能力。

對于數(shù)據(jù)安全，國內(nèi)的《網(wǎng)絡(luò)安全法》已經(jīng)正式實施，對個人隱私數(shù)據(jù)保護有法可依;另外歐盟 GDPR《通用數(shù)據(jù)保護條例(General Data Protection Regulation)》正式生效，都說明法律要管控數(shù)據(jù)亂象了。

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

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

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

♦ AWS Kinesis

♦ Azure 流分析

♦ Huawei Cloud 實時流計算服務(wù)

♦ Aliyun 實時計算

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

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

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

總結(jié) & 展望

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

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

StreamingGraph 在線圖計算

StreamingAI 實時 AI

流批合一

流存儲

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

作者介紹

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

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

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