一、控制流
從接觸面向過程語言開始，使用控制流編程的概念已是司空見慣。
if (condition) {
// do something
} else {
// do something else
}
分支和循環是最常見的控制流形式。由於控制條件的存在，總有一部分代碼片段會執行，另一部分不會執行。
在控制流中，想要進行數據傳遞，最關鍵的是借助於變量保存中間狀態。因此，控制流編程看起來是將數據嵌套在控制流內的編程方式。
使用變量保存程序狀態有個很大的優勢。通過變量緩存，可以將編程任務划分為不同的階段，每個階段只需要完成一部分功能子邏輯即可，這大大降低了復雜流程的思維成本。
但同時，也有一個比較大的劣勢，就是在分布式處理環境下，中間狀態的維護一直是一個很繁瑣的問題。這從另一個方面加大了程序設計的成本。
二、數據流
而數據流編程的概念最初可以探尋到函數式編程語言，以及靈感源於此的FlumeJava類系統（如Spark、Flink等）的編程API。
rdd.map(lambda).filter(lambda).reduce(lambda);
這種類似管道流水線形式的編程接口，每次處理的數據是列表形式的（LISP）。當然，這些列表放在分布式環境下換了一個新的名詞——分布式數據集（RDD/DataSet）。
數據流編程最大的特點是抽象了豐富的算子，通過UDF為算子指定用戶處理邏輯。因此，數據流編程其實蘊含了控制流嵌套在數據流內的編程方式。
使用數據流編程最大的優勢就是無需使用變量維護計算中間狀態，另外基本的列表數據格式天然滿足分布式數據存儲的要求。這也是函數式語言在自我宣傳時比較注重的一個優勢：對並行計算支持得更好。
不過，數據流編程的方式也並不是完美。由於事先規划好的流水線結構，導致了數據處理無法自主地選擇流水線分支進行處理。所以，有時候看似很簡單的控制邏輯，使用數據流表達時就顯得比較繁瑣。
三、數據流表達的控制流
例如：下面的控制流程使用控制流編程很好表達。
if (arg > MAX) {
vertices = vertices.map(lambda);
} else {
vertices = vertices.filter(lambda);
}
return vertices;
這里的參數arg可能來源於用戶輸入，或者Spark／Flink driver提供的變量。這種使用driver的單機控制流全局統籌的方式好像是解決了數據流選擇選擇流水線管道的目的，但是實際上這是通過重新提交新任務的方式完成的。即條件為真時，才會提交true分支內的計算任務，否則提交false分支的計算任務。
如果不借助於driver，該如何表達類似的分支控制流程呢？
假定參數arg的類型也是分布式數據集類型DataSet<Integer>，它可能來源於上游流水線的中間結果，那么表達分支控制流計算可能需要如下類似方式：
// 條件數據集
DataSet<Boolean> condition = arg.map(v -> v > MAX);
// 數據集 true/false 分離
DataSet<Tuple2<Vertex, Boolean>> labelVs = vertices.join(condition);
DataSet<Vertex> trueVs = labelVs.filter(v -> v.f1).map(v -> v.f0);
DataSet<Vertex> falseVs = labelVs.filter(v -> !v.f1).map(v -> v.f0);
// 各自分支處理
trueVs = trueVs.map();
falseVs = falseVs.filter();
return trueVs.union(falseVs);
這里通過將參數DataSet與輸入數據集vertices做join，然后分離（按條件true/false filter）出兩個新的數據集trueVs和falseVs。當條件為true時，trueVs就是原始數據集vertices，而falseVs為空數據集，反之則反。然后后續只要分別對這兩個數據集做相應的處理，最后把處理結果union合並起來就達到了目的。
通過這樣的方式，實際上是同時執行了條件的true和false的分支邏輯，只不過任何時候總有一個分支的流水線上的數據集為空罷了。
四、思考
通過前面的討論，可以得到一些比較明顯的結論：
- 控制流天然擅長描述控制邏輯，不過使用變量緩存中間結果不利於分布式計算抽象。
- 數據流天然對分布式並行計算支持良好，但是在描述控制邏輯時顯得十分乏力。
在計算編程語言設計領域，對控制流和數據流的討論不絕於耳。如何讓開發者更好的操縱這兩類概念也在不斷地探索，要不然也不會出現面向過程和函數式編程等各種編程范式。
而目前主流的計算系統，如Flink、Spark等，基本上處於使用driver的概念表達控制流，使用算子連接數據流這樣的模式。不過這都是建立在driver通過全局collect操作，將數據集的數據拉取到driver基礎之上的。本質上是driver根據條件分支的運行時結果，重新提交任務而已，這稱不上一個精彩的設計。因為，它並沒有做到讓數據流具備自主選擇流水線的能力。
那如何讓數據流具備自主選擇流水線的能力呢？說白了，自主選擇流水線，本質上是擁有任務運行時修改任務執行計划的能力，也就是所謂的動態DAG。Ray的設計中，函數是基本的任務調度單元，而非將UDF連接起來的DAG，或許這種底層的任務抽象能力對於表達動態DAG的能力具有更大的優勢。
詳細了解Ray的設計，可以參考文章：高性能分布式執行框架——Ray
我的博客即將同步至騰訊雲+社區，邀請大家一同入駐。