摘要：受會(huì)議的論文的啟發(fā)，聊一下流式計(jì)算未來(lái)的趨勢(shì)?？偨Y(jié)用一句話概括就是，流計(jì)算的發(fā)展還是得益于用戶(hù)對(duì)實(shí)時(shí)性的需求的增長(zhǎng)。文中所指的流計(jì)算本來(lái)并不單純是，甚至還包括了這類(lèi)，但是又所講的內(nèi)容又基本上和大數(shù)據(jù)相關(guān)的事情。

受 SIGMOD 會(huì)議的論文 Beyond Analytics: The Evolution of Streaming Processing Systems 的啟發(fā)，聊一下流式計(jì)算未來(lái)的趨勢(shì)。

有興趣的同學(xué)可以讀一下論文，論文前半部分主要講的是流式計(jì)算的發(fā)展，說(shuō)了很多流計(jì)算里特有的概念，在這里略過(guò)，從第 4 節(jié)開(kāi)始看。

4.1 Emerging Applications
Cloud Application
Machine Learning
Streaming Graphs
第一點(diǎn)，云原生的概念火熱的飛起，不過(guò)確實(shí)，過(guò)往經(jīng)驗(yàn)中使用過(guò) AWS 的云服務(wù)和 IDC 的物理機(jī)，維護(hù)成本完全是不能比。隨著資本從互聯(lián)網(wǎng)向其他方向轉(zhuǎn)移，融資困難的情況下，互聯(lián)網(wǎng)公司的硬件成本想必也會(huì)在創(chuàng)業(yè)初期成為很重要的一個(gè)考慮因素。在以前使用 AWS 云服務(wù)的過(guò)程中，舉兩個(gè)簡(jiǎn)單的例子：

對(duì)象存儲(chǔ)按量收費(fèi)，對(duì)象存儲(chǔ)有點(diǎn)類(lèi)似于冷存，因?yàn)樵品?wù)提供商有全局視角，所以可以很合理地來(lái)配置存儲(chǔ)資源，使得資源利用率非常高，所以對(duì)象存儲(chǔ)的存儲(chǔ)費(fèi)用極低，但是每次訪問(wèn)占用的帶寬和 CPU 是要按量付費(fèi)。我覺(jué)得這個(gè)就很合理了，將歷史的明細(xì)數(shù)據(jù)作為冷存放入到對(duì)象存儲(chǔ)中，只需要將近期數(shù)據(jù)和熱點(diǎn)數(shù)據(jù)放在 HDFS 或者其他 OLAP 存儲(chǔ)里，可以極大地壓低大數(shù)據(jù)量公司的存儲(chǔ)成本
廉價(jià)的不穩(wěn)定機(jī)型，這也是當(dāng)時(shí)讓我很吃驚的點(diǎn)。AWS 的機(jī)型中有一種很廉價(jià)，但是穩(wěn)定性保證很差的機(jī)型，不適合常駐的服務(wù)，但是在做好推測(cè)執(zhí)行、Shuffle Service 的情況下，非常適合跑 BATCH 任務(wù)，因?yàn)?BATCH 任務(wù)本身就是離線任務(wù)，且 DAG 的任務(wù)天生可以通過(guò)拓?fù)渲g的關(guān)系進(jìn)行容錯(cuò)。
第二點(diǎn)是機(jī)器學(xué)習(xí)，這個(gè)應(yīng)該是沒(méi)有爭(zhēng)議的，就不解釋了。

第三點(diǎn)是流式計(jì)算中特有的概念，值得說(shuō)一下。以 Spark、Flink 為例，這些計(jì)算框架通常是把用戶(hù)寫(xiě)的代碼或者 SQL 轉(zhuǎn)化為一個(gè) DAG，然后根據(jù) DAG 來(lái)進(jìn)行調(diào)度。我們把這種預(yù)先生成的 DAG 叫做 Static Graph，即使是迭代計(jì)算的場(chǎng)景，其計(jì)算的拓?fù)浜凸揭捕际遣蛔兊?。而在目前深度學(xué)習(xí)的場(chǎng)景中，我們會(huì)在執(zhí)行過(guò)程中不斷調(diào)整計(jì)算的公式和模式，所以拓?fù)湟矔?huì)發(fā)生相應(yīng)的變化，我們把這種拓?fù)浣凶?Dynamic Graph，目前在 Ray 中有所提到。

4.2 The road ahead
Programming Models
這個(gè)也很值得一提，不管是流式還是批式作業(yè)，我們編寫(xiě)分布式應(yīng)用的方式就兩種，1 是用框架中的專(zhuān)屬概念，比如 Spark 中的 RDD，F(xiàn)link 中的 DataStream 等，2 是用 SQL。

使用代碼來(lái)開(kāi)發(fā)，需要了解很多分布式計(jì)算框架中專(zhuān)屬的概念，而在流式計(jì)算中使用 SQL 上手門(mén)檻依舊很高（批式 SQL 還好），所以現(xiàn)在大數(shù)據(jù)領(lǐng)域也開(kāi)始出現(xiàn)很多類(lèi)似 Faas、Actor Model 的編程模式，比如 Flink 創(chuàng)始公司推的 Stateful Function、Ray 的 Actor 編程模型等。

長(zhǎng)遠(yuǎn)來(lái)看，這確實(shí)是一個(gè)趨勢(shì)。從和業(yè)務(wù)方打交道的經(jīng)驗(yàn)來(lái)看，對(duì)于從事算法工作的同學(xué)來(lái)說(shuō)，了解分布式的部署、執(zhí)行、高可用等概念實(shí)在是太痛苦，而且學(xué)習(xí)成本太高，而站在他們的角度來(lái)看，他們只是想法自己的算法邏輯跑在遠(yuǎn)端的服務(wù)器上，本來(lái)并不需要了解這些事情。從這點(diǎn)看，我就特別喜歡 Ray 這種簡(jiǎn)潔的編程模型，直接一個(gè)注解就把函數(shù)跑在了分布式服務(wù)上，

import ray
ray.init()

@ray.remote
def f(x):

return x * x

futures = [f.remote(i) for i in range(4)]
print(ray.get(futures))
Transactions
流計(jì)算的事務(wù)支持。這里主要指的是有狀態(tài)的服務(wù)，需要對(duì)狀態(tài)做到 ACID 的保證，只有做到這點(diǎn)之后，流計(jì)算才具有對(duì)線上業(yè)務(wù)提供服務(wù)的能力。

Advanced State Backends
這塊跟我從事的方向也很有關(guān)系。一個(gè)是剛剛上面提到的事務(wù)能力，二是對(duì) State Backend 能力上的增強(qiáng)。目前還不存在一個(gè)比較完美的和流式計(jì)算相匹配的狀態(tài)存儲(chǔ)，F(xiàn)link 的話使用 RocksDB 作為狀態(tài)存儲(chǔ)，在 update 的性能上很成問(wèn)題。

我對(duì) State Backend 中比較好的設(shè)想是

狀態(tài)使用的介質(zhì)可以是類(lèi)似單機(jī) RocksDB 這樣 Embedded 的，也可以是 HBase 這樣 Remote 形式的，做到一個(gè)完全的可插拔，并且數(shù)據(jù)序列化的方式不依賴(lài)于存儲(chǔ)介質(zhì)，用戶(hù)可以選擇在不同的存儲(chǔ)介質(zhì)進(jìn)行切換。
狀態(tài)隨時(shí)可查，就像一個(gè)分布式存儲(chǔ)一樣，這樣流計(jì)算中產(chǎn)生的狀態(tài)不止可以作為輸出結(jié)果使用，還能做真正實(shí)時(shí)的分析，搭配應(yīng)用里一些抽象的邏輯，我們可以在實(shí)時(shí)分析、計(jì)算產(chǎn)生狀態(tài)、結(jié)果輸出這三個(gè)方面形成一個(gè)服務(wù)線上業(yè)務(wù)的閉環(huán)。
Loops & Cycles
這里提到的是一個(gè)反饋閉環(huán)的問(wèn)題，倒是更屬于 Stateful Function 的范疇。在已有的大數(shù)據(jù)計(jì)算框架上去實(shí)現(xiàn)，我覺(jué)得還是非常困難的一個(gè)事情。

Elasticity & Reconfiguration
Cloud Native，彈性伸展，目前對(duì)于無(wú)狀態(tài)的服務(wù)，使用 Kubernetes 或是其他的計(jì)算框架都比較容易實(shí)現(xiàn)，而對(duì)于有狀態(tài)的服務(wù)，如何重新分配狀態(tài)，并且不中斷對(duì)線上的服務(wù)，這也是比較難的。

目前工業(yè)界的主要做法，

停止作業(yè)、修改配置、重啟作業(yè)，將這個(gè)流程自動(dòng)化，去除一些冗余的步驟，但整體的 cost 跟手動(dòng)操作起來(lái)差別不會(huì)太大。
雙跑作業(yè)，同時(shí)跑兩個(gè)作業(yè)，Hot 和 Standby，通過(guò) zk 選主，線上服務(wù)不中斷，但是資源使用需要翻倍，編寫(xiě)代碼時(shí)需要考慮雙跑的容錯(cuò)，比如兩個(gè)作業(yè)的消費(fèi)起點(diǎn)能否對(duì)齊等，使用難度還是偏大。
Dynamic Topologies
需求決定框架實(shí)現(xiàn)，上面講了，總之還是因?yàn)樯疃葘W(xué)習(xí)、神經(jīng)網(wǎng)絡(luò)的流行，對(duì)計(jì)算調(diào)度的靈活性要求未來(lái)會(huì)越來(lái)越高，尤其是機(jī)器人對(duì)環(huán)境實(shí)時(shí)反饋的場(chǎng)景，每秒可能需要調(diào)度成千上萬(wàn)的小型任務(wù)，完成各個(gè)傳感器對(duì)環(huán)境中不同因素的感知。

Shared Mutable State
現(xiàn)有大數(shù)據(jù)計(jì)算框架的缺點(diǎn)之一，JobManager 和 TaskManager 的交互模式，使得 Task Manager 之間的資源、狀態(tài)無(wú)法共享，在 Apache Flink 中甚至不能互相通信。那么自然，Task A 計(jì)算得到的狀態(tài) X 不能給 Task B 用，如果需要實(shí)現(xiàn)這樣的需求，往往是將發(fā)往 Task A 的數(shù)據(jù)多 copy 一份發(fā)送到 Task B，在 Task B 中實(shí)現(xiàn)一個(gè)同樣的邏輯生成狀態(tài) X。

如果需要讓 Task 之間共享狀態(tài)，那么一致性保證將會(huì)是個(gè)難題，這種情況下使用 Embeded 模式的 State Backend 肯定就不太合適了，在 Ray 中使用的是 Plasma 共享內(nèi)存存儲(chǔ)。

Queryable State
之前提到過(guò)，skip。

State Versioning
這個(gè)需求的話個(gè)人感覺(jué)還好，如果是對(duì) State 的版本有要求，其實(shí)用現(xiàn)有的 Snapshot 和 Checkpoint 也可以實(shí)現(xiàn)。

Hardware Acceleration
硬件的加速。

總結(jié)
用一句話概括就是，流計(jì)算的發(fā)展還是得益于用戶(hù)對(duì)實(shí)時(shí)性的需求的增長(zhǎng)。

文中所指的流計(jì)算本來(lái)并不單純是 Apache Flink，甚至還包括了 Akka Stream 這類(lèi) Streaming Service，但是又所講的內(nèi)容又基本上和大數(shù)據(jù)相關(guān)的事情。從大數(shù)據(jù)領(lǐng)域的角度來(lái)講，流計(jì)算在數(shù)據(jù)分析，實(shí)時(shí)報(bào)表展示方面，已經(jīng)是作為一個(gè)比較成熟的技術(shù)棧在廣泛使用，工業(yè)界中的各大互聯(lián)網(wǎng)公司也都基本上完成了數(shù)倉(cāng)、報(bào)表從離線到實(shí)時(shí)的轉(zhuǎn)換，也都基本具備了這樣的能力。

所以流計(jì)算的下一個(gè)趨勢(shì)，必然是從實(shí)時(shí)分析到賦能業(yè)務(wù)，具體來(lái)看，會(huì)產(chǎn)出兩個(gè)方向：

在已有的流計(jì)算模型之上，支持更復(fù)雜的數(shù)據(jù)計(jì)算，并且做到更快、更穩(wěn)定，有一些功能的增強(qiáng)，但不對(duì)整體的架構(gòu)做出大的改變。
支持深度學(xué)習(xí)、神經(jīng)網(wǎng)絡(luò)等賦能業(yè)務(wù)的技術(shù)棧，這就需要一定程度上顛覆我們過(guò)去有的一些東西，比如 DAG。