あなたは関係のMapReduceとスパークとは何か尋ねる、または共通のプロパティがどのようであれば、あなたは彼らがビッグデータ処理エンジンであることを答えることがあります。あなたが火花を尋ねると、それをtensorflow場合、それは少し混乱するかもしれませんが、多分気になる部分は同じああではありません。しかし、それとMPIの火付け役頼みますか？これが遠くなります。分散コンピューティングフレームワーク：やや不正確尋ねたが、それらはすべて共通部分を持っているが、これは我々が今日、大きな話題を話している話題です。
MapReduceのかどうか、またはスパークあるいはtensorflowう、彼らは分散機能を利用している、いくつかの特定の問題を解決するために、いくつかの計算を実行します。計算方法を提示し、「分散コンピューティングモデル」を定義し、このレベルからは、この計算方法により、我々は、コンピューティング、分散データの問題の多くを解決することができます。両者の違いは、異なる分散コンピューティングモデルが提案されていることにあります。名前が示すように、それは非常に基本的なマップ-削減スタイルのコンピューティング・モデルであるMapReduceの（のような同じことを言っていません）。スパークモデルはRDDのセットを定義し、DAGは、本質的に成る低減/マップのシリーズです。Tensorflow計算モデルは、より「複雑」の点のように見えるためにマップが、スパークよりも、マップtensorflowです。あなたは、グラフのノードとエッジのそれぞれの定義が必要です。これらの定義によると、あなたはこの数字を計算する方法tensorflow導くことができます。Tensorflowのこの特定の定義は、ニューラルネットワークであるtensorflowの点で、計算処理の特定のタイプのためにそれをより適したものとなります。RDDモデルとその火花にとってより適したものにするには、相互にデータパラレルタスクではありません。一般的な、シンプルでありながら高性能な分散コンピューティングモデルはありますか？私はかなり難しいと感じました。一般的なパフォーマンスは、多くの場合、特定の状況に合わせて最適化を意味行うことはできません。タスクのために特別に書かれており、一般的なタスクは、分散ん、もちろん、簡単な操作を行うことはできません。
さておき、分散コンピューティングモデルは、添付コンテンツを持って挿入し、スケジュールされています。あまり注目が、これは、分散コンピューティングエンジン不可欠なものです。MapReduceのスケジューリングは、スパークスケジューリングがtensorflowすぎて、独自の組み込みのスケジューラを持って、糸です。MPIそれ？そのスケジュールはプルアップするSSHですべてのタスクは、すべてのクラスタリソースを持っていると仮定して、ほとんどのスケジュールではありません。スケジューリングは、実際にリソーススケジューラとタスクスケジューラに分割する必要があります。前者はいくつかのリソースマネージャにコンピューティングのためにこれらのリモートリソースにタスクを発行した数値を計算するために使用されるいくつかのハードウェアリソースを、適用するために使用され、実際には、いわゆる2段階のスケジューリングです。近年、いくつかのTensorflowOnSparkようなプロジェクト。そのようなプロジェクトの性質は、実際には、計算モデルtensorflowと結合リソーススケジューリングスパークを、使用されています。
私たちは、スタンドアロンのプログラムを書き終え、そして自然のアイデアは、私はそれは、分散環境で実行するために得ることができないときにデータの量に関する質問に直面したときは？分散技術を作ることができますが、少し変更を追加または変更できない場合、それは素晴らしいことです。もちろん、現実はもっと残酷です。一般的に、一般的なプログラムのために、ユーザーは通常、彼は災害復旧の作業を行うことができなかった自分自身の分布データの要約（無容量を制御するために、手動でそのようなMPIの枠組みなどの使用など、独自の分散型バージョンを、記述する必要があります災害）。目標は、データのバッチが正確にバッチ処理で処理する場合は、MapReduceのを使用するか、事前に定義されたAPIを刺激することができます。このタイプのタスクのために、計算フレームワークは、ビジネスだけでなく外（足場コード）部分に私たちを支援してきました。同様に、私たちの使命は十分のようpytorch tensorflowフレームワークを使用して、ニューラルネットワークを訓練することである場合。この一節の意味は、あなたが対応するフレームに対処する必要があれば、問題は、その後、それらの使用はうまく作ることです。しかし、それなし？自分の実現に加えて、それを行うには、他の方法はありませんか？
今日は、プロジェクト、と指摘レイは、あなたがわずかにあなたのコードを変更する必要があると主張し、あなたが分散し（実際には、このプロジェクトは、長い間リリースされているが、それへの意図的な配慮はなされていない）にそれを作ることができます。もちろん、これは、次の例のように、コードのPythonに限定されます
+------------------------------------------------+----------------------------------------------------+
| **Basic Python** | **Distributed with Ray** |
+------------------------------------------------+----------------------------------------------------+
| | |
| # Execute f serially. | # Execute f in parallel. |
| | |
| | @ray.remote |
| def f(): | def f(): |
| time.sleep(1) | time.sleep(1) |
| return 1 | return 1 |
| | |
| | |
| | ray.init() |
| results = [f() for i in range(4)] | results = ray.get([f.remote() for i in range(4)]) |
+------------------------------------------------+----------------------------------------------------+だから、簡単な？だから私は思ったopenmp（ではないに注意してくださいopenmpi）。見てください、
#include<iostream>
#include"omp.h"
using namespace std;
void main() {
#pragma omp parallel for
for(int i = 0; i < 10; ++i) {
cout << "Test" << endl;
}
system("pause");
}インポート・ヘッダ・ファイルは、その上にライン前処理指令を添加、直ちに並列実行コードとなります。もちろん分散が、コンパイラは、処理をマルチスレッド動作自体の一部をコンパイルするために必要なコードの並列化を可能にするので、並列度は、CPUスレッドの限定された数を受信していないのOpenMP。CPUはデュアルスレッドであれば、それだけで2倍に加速することができます。いくつかのサーバ、CPUに、スレッド32は、シングルコア、32倍加速することができる天然の（並列部分）を楽しむことができます。しかし、これらは重要ではありません、ユーザーの視点、レイとこのような行為はやや似のOpenMPされていませんか？あなたは、コードは（コンパイラのためにそれが唯一の行のコメントでのOpenMPをサポートしていないため、さらに独特であることをコースのOpenMPの）分散実行になることができるようになり、あまりにも多くのコードの変更を行う必要はありません。
だから、レイはこのそれを行う方法ですか？実際には、レイの練習は比較的単純であると言われ、定義されたMPI通信プリミティブに似たAPIの数を、定義することです。使用される場合、これらのAPIは、コードの適切な位置に「注入」、コードは、混合なるAPIのユーザコード番号が線フレームの層を呼び出すと、実際には、全体のコードは、計算グラフが形成されています。次のことは、レイはうまくこの計算チャートを完成するために戻るのを待つことです。レイの論文は、例を挙げました。
@ray.remote
def create_policy():
# Initialize the policy randomly.
return policy
@ray.remote(num_gpus=1)
class Simulator(object):
def __init__(self):
# Initialize the environment.
self.env = Environment()
def rollout(self, policy, num_steps):
observations = []
observation = self.env.current_state()
for _ in range(num_steps):
action = policy(observation)
observation = self.env.step(action)
observations.append(observation)
return observations
@ray.remote(num_gpus=2)
def update_policy(policy, *rollouts):
# Update the policy.
return policy
@ray.remote
def train_policy():
# Create a policy.
policy_id = create_policy.remote()
# Create 10 actors.
simulators = [Simulator.remote() for _ in range(10)]
# Do 100 steps of training.
for _ in range(100):
# Perform one rollout on each actor.
rollout_ids = [s.rollout.remote(policy_id)
for s in simulators]
# Update the policy with the rollouts.
policy_id = update_policy.remote(policy_id, *rollout_ids)
return ray.get(policy_id)画像は、算出結果として生じるを示します
そのため、ユーザーが行う必要があり、あなたのコード内の適切なレイのAPIの呼び出しを追加し、その後、そのコードが、実際に計画を分散コンピューティングになります。比較として、私たちはtensorflowマップの定義を見てみましょう
import tensorflow as tf
# 创建数据流图：y = W * x + b，其中W和b为存储节点，x为数据节点。
x = tf.placeholder(tf.float32)
W = tf.Variable(1.0)
b = tf.Variable(1.0)
y = W * x + b
with tf.Session() as sess:
tf.global_variables_initializer().run() # Operation.run
fetch = y.eval(feed_dict={x: 3.0}) # Tensor.eval
print(fetch) # fetch = 1.0 * 3.0 + 1.0
'''
输出：
4.0
'''図から分かるように、tensorflowは明示的に、明確ノードの定義を示す、独自に必要であるplaceholder Variable図レイに定義された暗黙的な方法であるのに対し、（これらは、グラフノードの特定のタイプである）等。私は、前者が、ホイールに合わせて自分のロジックをtensorflow使用するために、より多くのコードのようなものである一方、後者は、開発者の観点に立って、より自然な方法だと思います。
那么 ray 是不是就我们要寻找的那个即通用、又简单、还灵活的分布式计算框架呢？由于笔者没有太多的 ray 的使用经验，这个问题不太好说。从官方介绍来看，有限的几个 API 确实是足够简单的。仅靠这几个 API 能不能达成通用且灵活的目的还不好讲。本质上来说，Tensorflow 对图的定义也足够 General，但是它并不是一个通用的分布式计算框架。由于某些问题不在于框架，而在于问题本身的分布式化就存在困难，所以试图寻求一种通用分布式计算框架解决单机问题可能是个伪命题。
话扯远了。假设 ray 能够让我们以一种比较容易的方式分布式地执行程序，那么会怎么样呢？前不久 Databricks 开源了一个新项目，Koalas，试图以 RDD 的框架并行化 pandas。由于 pandas 的场景是数据分析，和 spark 面对的场景类似，两者的底层存储结构、概念也是很相似的，因此用 RDD 来分布式化 pandas 也是可行的。我想，如果 ray 足够简单好用，在 pandas 里加一些 ray 的 api 调用花费的时间精力可能会远远小于开发一套 koalas。但是在 pandas 里加 ray 就把 pandas 绑定到了 ray 上，即便单机也是这样，因为 ray 做不到像 openmp 那样如果支持，很好，不支持也不影响代码运行。
ロングったらしいそんなに、実際には、非常に多くのエンジンからの詳細は、それぞれが問題を解決するために設計されて、出てくると、分散コンピューティングフレームワークで最後に何を考えたかったのか、何の利点と欠点。最後に、この記事のビューギャングの端を取ります。デビッド・パターソンは、より高い効率性を実現したいために、一般的なハードウェアに近いと限界に近い、「コンピュータアーキテクチャのための新しい黄金時代」の演説で述べた、我々は、設計指向するアーキテクチャ（ドメイン固有のアーキテクチャ）が必要です。これは、各アーキテクチャはその問題領域は、外観に直面し、その問題の特別な最適化が含まれている必要があり解決することで、コンピューティングアーキテクチャの新たな時代です。汎用性が出発点の問題を解決するためのユーザーではありませんが、「希望的観測」のフレームワーク設計のより、ユーザーは常に、問題領域を心配になります。この意味で、フィールドは、コンピューティング・アーキテクチャは正しい方向で配向される必要があります。
免責事項：文の内容に誤りがある可能性がありように制限それは、限られています。ようこそ批判。