使用DataFlow表達ControlFlow的一些思考

1、控制流

從接觸面向過程語言開始，使用控制流編程的概念已經是司空見慣。

if (condition) {
  // do something
} else {
  // do something else
}

分支和循環是最多見的控制流形式。因爲控制條件的存在，總有一部分代碼片斷會執行，另外一部分不會執行。

在控制流中，想要進行數據傳遞，最關鍵的是藉助於變量保存中間狀態。所以，控制流編程看起來是將數據嵌套在控制流內的編程方式。

使用變量保存程序狀態有個很大的優點。經過變量緩存，能夠將編程任務劃分爲不一樣的階段，每一個階段只須要完成一部分功能子邏輯便可，這大大下降了複雜流程的思惟成本。

但同時，也有一個比較大的劣勢，就是在分佈式處理環境下，中間狀態的維護一直是一個很繁瑣的問題。這從另外一個方面加大了程序設計的成本。

2、數據流

而數據流編程的概念最初能夠探尋到函數式編程語言，以及靈感源於此的FlumeJava類系統（如Spark、Flink等）的編程API。

rdd.map(lambda).filter(lambda).reduce(lambda);

這種相似管道流水線形式的編程接口，每次處理的數據是列表形式的（LISP）。固然，這些列表放在分佈式環境下換了一個新的名詞——分佈式數據集（RDD/DataSet）。

數據流編程最大的特色是抽象了豐富的算子，經過UDF爲算子指定用戶處理邏輯。所以，數據流編程其實蘊含了控制流嵌套在數據流內的編程方式。

使用數據流編程最大的優點就是無需使用變量維護計算中間狀態，另外基本的列表數據格式自然知足分佈式數據存儲的要求。這也是函數式語言在自我宣傳時比較注重的一個優點：對並行計算支持得更好。

不過，數據流編程的方式也並非完美。因爲事先規劃好的流水線結構，致使了數據處理沒法自主地選擇流水線分支進行處理。因此，有時候看似很簡單的控制邏輯，使用數據流表達時就顯得比較繁瑣。

3、數據流表達的控制流

例如：下面的控制流程使用控制流編程很好表達。

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的分支邏輯，只不過任什麼時候候總有一個分支的流水線上的數據集爲空罷了。

4、思考

經過前面的討論，能夠獲得一些比較明顯的結論：

• 控制流自然擅長描述控制邏輯，不過使用變量緩存中間結果不利於分佈式計算抽象。
• 數據流自然對分佈式並行計算支持良好，可是在描述控制邏輯時顯得十分乏力。

在計算編程語言設計領域，對控制流和數據流的討論不絕於耳。如何讓開發者更好的操縱這兩類概念也在不斷地探索，要否則也不會出現面向過程和函數式編程等各類編程範式。

而目前主流的計算系統，如Flink、Spark等，基本上處於使用driver的概念表達控制流，使用算子鏈接數據流這樣的模式。不過這都是創建在driver經過全局collect操做，將數據集的數據拉取到driver基礎之上的。本質上是driver根據條件分支的運行時結果，從新提交任務而已，這稱不上一個精彩的設計。由於，它並無作到讓數據流具有自主選擇流水線的能力。

那如何讓數據流具有自主選擇流水線的能力呢？說白了，自主選擇流水線，本質上是擁有任務運行時修改任務執行計劃的能力，也就是所謂的動態DAG。Ray的設計中，函數是基本的任務調度單元，而非將UDF鏈接起來的DAG，或許這種底層的任務抽象能力對於表達動態DAG的能力具備更大的優點。

詳細瞭解Ray的設計，能夠參考文章：高性能分佈式執行框架——Ray

個人博客即將同步至騰訊雲+社區，邀請你們一同入駐。