一、控制流 從接觸 面向過程語言 開始，使用控制流編程的概念已是司空見慣。 分支 和 迴圈 是最常見的控制流形式。由於控制條件的存在，總有一部分代碼片段會執行，另一部分不會執行。 在控制流中，想要進行數據傳遞，最關鍵的是藉助於 變數 保存中間狀態。因此，控制流編程看起來是 將數據嵌套在控制流內 的編 ...
一、控制流
從接觸面向過程語言開始，使用控制流編程的概念已是司空見慣。
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
