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

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

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

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

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

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

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

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

長遠(yuǎn)來看，這確實是一個趨勢。從和業(yè)務(wù)方打交道的經(jīng)驗來看，對于從事算法工作的同學(xué)來說，了解分布式的部署、執(zhí)行、高可用等概念實在是太痛苦，而且學(xué)習(xí)成本太高，而站在他們的角度來看，他們只是想法自己的算法邏輯跑在遠(yuǎn)端的服務(wù)器上，本來并不需要了解這些事情。從這點看，我就特別喜歡 Ray 這種簡潔的編程模型，直接一個注解就把函數(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
流計算的事務(wù)支持。這里主要指的是有狀態(tài)的服務(wù)，需要對狀態(tài)做到 ACID 的保證，只有做到這點之后，流計算才具有對線上業(yè)務(wù)提供服務(wù)的能力。

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

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

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

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

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

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

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

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

Queryable State
之前提到過，skip。

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

Hardware Acceleration
硬件的加速。

總結(jié)
用一句話概括就是，流計算的發(fā)展還是得益于用戶對實時性的需求的增長。

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

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

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