당신이 관계 맵리 듀스와 스파크, 또는 어떤 공통의 속성을 것입니다 무엇인지 묻는다면, 당신은 그들이 빅 데이터 처리 엔진 것을 대답 할 수있다. 당신이 불꽃을 요구하고 tensorflow 경우, 어쩌면 관심 분야가 같은 아하지 않습니다, 조금 혼란 될 수 있습니다. 그러나 그것으로 MPI를 촉발 물어? 이것은 멀리 것이다. 분산 컴퓨팅 프레임 워크 : 다소 부정확 물었지만, 그들은 모두 공통 부분이 있지만, 이것은 우리가 오늘에 대해 얘기하고 주제, 더 큰 주제입니다.
그들은 분산 기능을 활용하고 tensorflow 것 맵리 듀스, 또는 스파크 여부, 몇 가지 문제점을 해결하기 위해, 몇 가지 계산을 실행합니다. 이 계산 방법에 의해 계산 방법을 제시하는 '분산 컴퓨팅 모델을 "정의이 수준에서, 우리는 컴퓨팅 분산 된 데이터의 많은 문제를 해결할 수 있습니다. 그들 사이의 차이는 다른 분산 컴퓨팅 모델이 제안에있다. 이름에서 알 수 있듯이, 그것은 아주 기본적인지도-감소 스타일의 컴퓨팅 모델입니다 맵리 듀스 (같은 같은 말을하지 않음). 스파크 모델은 RDD 세트를 정의의 DAG는 / 본질적으로 구성된 줄일지도의 시리즈입니다. Tensorflow 계산 모델은지도이지만, 불꽃보다 맵 tensorflow 더 "복잡한"점으로 나타납니다. 당신은 그래프의 노드와 엣지의 각각에 대한 정의가 필요합니다. 이러한 정의에 따르면,이 그림을 계산하는 방법을 tensorflow 안내 할 수 있습니다. Tensorflow이 특정 정의 tensorflow 환산 신경망은, 연산 처리의 특정 타입에 더 적합하다. 그 스파크 태스크 병렬 데이터를 상호 관련되어 있지 않으나 위해 RDD 모델 것이 더 적합하다. A, 일반적인 간단하면서도 고성능의 분산 컴퓨팅 모델이 있습니까? 나는 아주 열심히 느꼈다. 일반 성능을 자주 할 수없는 특정 상황에 최적화 된 의미합니다. 작업을 위해 특별히 쓰고 물론, 분산 일반적인 작업을 수행 간단 할 수 없습니다.
옆으로, 분산 컴퓨팅 모델은,이 예약 된 첨부 내용이 삽입합니다. 작은 관심이지만, 그러나 이것은 분산 컴퓨팅 엔진 필수적인 일이다. 맵리 듀스 스케줄링은 스파크 스케줄링 tensorflow도 자체 내장 스케줄러를 가지고, 원사입니다. MPI 그것? 그 일정은 모든 클러스터 자원이 있다고 가정 거의 일정입니다, SSH 모든 작업은 끌어합니다. 예약은 실제로 자원 스케줄러 및 작업 스케줄러로 나눌 수 있습니다. 전자는 일부 리소스 관리자에게 컴퓨팅이 원격 자원에 대한 작업을 발행 한 수치를 계산하는 데 사용되는 일부 하드웨어 리소스를 적용하는 데 사용됩니다, 사실, 소위 두 단계 스케줄링이다. 일부 TensorflowOnSpark 최근 몇 년 동안 같은 프로젝트. 그러한 프로젝트의 특성은 실제로 계산 모델 tensorflow 결합 자원 디스패치 점화를 사용한다.
우리는 독립 실행 형 프로그램을 작성 완료, 자연 아이디어는 내가 분산 환경에서 실행 얻을 수없는 경우 데이터의 양에 대한 질문에 직면 할 때? 추가하거나 분산 기술을 만들 수있는 작은 변화를 변경할 수 없다면, 그것은 좋은 것입니다. 물론, 현실은 더 잔인. 일반적으로, 일반적인 프로그램, 사용자가 수동으로 그런 그가 재해 복구 작업을 만들기 위해 실패 자신의 분포 데이터 요약을 제어 할 수 MPI의 프레임 워크를 사용하는 등, (일반적으로 어떤 용량으로, 자신의 배포 버전을 작성해야 재해). 목표는 데이터가 정확하게 일괄 처리 인의 배치를 처리하는 경우, 당신은 맵리 듀스를 사용하거나 미리 정의 된 API를 촉발 할 수 있습니다. 이러한 유형의 작업을 위해, 계산 프레임 워크는 물론 기업 외부 (비계 코드) 부분에 도움이되었습니다. 마찬가지로, 우리의 임무는 충분히처럼 pytorch tensorflow 프레임 워크를 사용하여, 신경 네트워크를 양성하는 것입니다 경우. 이 구절의 의미하면 해당 프레임을 처리해야하는 경우 문제가, 다음 중 사용은 잘 할 것입니다. 그러나없이? 자신의 실현뿐만 아니라 그것을 할 수있는 다른 방법이 없다?
오늘은 프로젝트 있다고 지적 레이 만 약간 코드를 수정해야한다는 주장은, 당신이 분산에 그것을 만들 수 있습니다 (이 프로젝트는 긴 릴리스되었습니다에서 사실 만에 더 신중한 관심이 없었다). 물론,이 코드를 파이썬으로 제한됩니다, 다음 예에서와 같이,
+------------------------------------------------+----------------------------------------------------+
| **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 那样如果支持，很好，不支持也不影响代码运行。
장황한 너무 많은 사실, 많은 엔진의 세부 사항은 각이 문제를 해결하기 위해 설계되었습니다 나와서 분산 컴퓨팅 프레임 워크이다 결국 무엇을 생각 원, 어떤 장점과 단점. 마지막으로,이 문서의보기 갱스 끝을. 데이비드 패터슨 연설 "컴퓨터 아키텍처를위한 새로운 황금 시대"에서 말했다, 일반 하드웨어 점점 더 가까이 한계, 더 큰 효율을 달성하려는, 우리가해야 할 디자인을 지향 아키텍처 (도메인 특정 아키텍처). 이 아키텍처 컴퓨팅의 새로운 시대, 각각의 아키텍처, 그 문제 영역이 모습을 직면 해결하기 위해 문제의 특별한 최적화를 포함해야합니다입니다. 다양한 기능이 출발점의 문제를 해결하기 위해 사용자가 아니라 "희망 사항"의 프레임 워크 디자이너의 이상, 사용자는 항상 문제 영역에 대해 우려됩니다. 이러한 의미에서, 분야는 아키텍처를 계산하는 것이 올바른 방향입니다 지향해야한다.
면책 조항 :이 올바르지 않을 수 있습니다 진술 내용과 같이이 제한되어 제한했다. 에 오신 것을 환영 비판.