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

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

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

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

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

第三點是流式計算中特有的概念，值得說一下。以 Spark、Flink 為例，這些計算框架通常是把用戶寫的代碼或者 SQL 轉化為一個 DAG，然后根據 DAG 來進行調度。我們把這種預先生成的 DAG 叫做 Static Graph，即使是迭代計算的場景，其計算的拓撲和公式也都是不變的。而在目前深度學習的場景中，我們會在執(zhí)行過程中不斷調整計算的公式和模式，所以拓撲也會發(fā)生相應的變化，我們把這種拓撲叫做 Dynamic Graph，目前在 Ray 中有所提到。

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

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

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

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
流計算的事務支持。這里主要指的是有狀態(tài)的服務，需要對狀態(tài)做到 ACID 的保證，只有做到這點之后，流計算才具有對線上業(yè)務提供服務的能力。

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

我對 State Backend 中比較好的設想是

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

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

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

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

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

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

Queryable State
之前提到過，skip。

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

Hardware Acceleration
硬件的加速。

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

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

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

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