4.2 Executor
Executor은 Optimizer로부터 선택된 데이터 처리 플랫폼에서 실행하기 위한 execution을 받는다. (Algorithm 1의 Lines 3과 Lines 7) 예를 들어 Optimizer은 Figure 4(a)의 SGD 예제를 위해 Spark와 JavaStreams를 선택했다. 전반적으로 Executor은 여러 계산 노드에서 작업을 병렬화하는 잘 알려진 접근을 따르지만, Execution 계획을 나누는 방식에는 차이가 거의 없다. 특히 Execution을 stage별로 구분한다. stage는 (i) 모든 Execution Operator가 동일한 플랫폼의 subplan 이며 (ii) Execution 종료 시 플랫폼은 Executor에게 Execution 통제권을 돌려주어야 하며, (iii) 마지막 Operator은 다음 Operator로 파이프라인화되는 대신 데이터 구조로 출력 data quanta를 구체화 한다.
Figure 4(b)의 SGD예제에서, Executor은 execution 계획을 Figure 7과 같이 6개의 Stage로 나눈다. Executor은 루프상태를 평가하기 위한 execution 제어를 가져야 하므로 Stage3에는 RepeatLoop Operator만 포함되어 있다는점을 유의하라. 이것이 Executor이 Stage1과 Stage5를 구분하는 이유다. 그 다음, 관련 플랫폼 드라이버에 Stage들을 배분하고, 기본 플랫폼에 Job으로 Stage들을 전달 한다. Stage들은 데이터 흐름 의존성으로 연결되어 있어 의존성이 없는 Stage(e.g., Stage1과 Stage2)가 먼저 병렬로 전달되고 입력 의존성이 충족되면 다른 Stage가 모두 전달된다.(e.g., Stage2 이후 Stage3)
Data Exploration.
데이터탐색이 데이터 과학 분야의 핵심 요소인 만큼 Executor은 선택적으로 응용프로그램을 탐색모드에서 실행하여 언제든지 작업의 실행을 일시중지하고 다시 시작할 수 있다. Spark, Flink, Giraph, Postgres, Hadoop과 같은 대부분의 플랫폼은 중간 상태에서 작업을 다시 시작하는 작업 계산을 일시 중지할 수 없으므로 Cross-platform 설정에서 이를 달성하는 것은 매우 어려운 일이다. 따라서 문제는 기본 플랫폼이 데이터탐색을 효율적으로 지원하는데 있다. 따라서 과제는 기본 플랫폼이 데이터탐색을 효율적으로 지원하도록 하는데 있다. Rheem은 Excution계획에 스니퍼를 주입하고 보조 Execution계획을 첨부하여 이를 달성한다. 스니퍼는 중간 결과를 복제하여 보조 Execution계획으로 보내는 Execution Operator를 말한다. 예를들어 사용자는 SGD의 각 반복에서 가중치를 추적하기를 원하므로 가중치를 업데이트한 직후에 스니퍼가 필요하다(Stage5 in Figure 7.)
스니퍼는 가중치를 사용자에게 다시 보고할 책임이 있는 보조계획에 보낸다.(Figure 7의 소켓 링크 싱크 Operaotr)
이 보조계획은 효율적인 업무 재개를 위한 추가 메타데이터의 계산 및 저장을 담당한다.(Figure 7의 보조계획의 수집 링크 Operator 및 맵)
작업을 재개할 때 Executor은 이전에 계산된 메타데이터에서 최대한 재사용하여 작업을 수행한다. 예를 들어 사용자가 반복 i에서 SGD 작업을 일지 중지하고 나중에 재개하는 경우 Executor은 이전에 계산한 반복 i의 가중치를 가져오고 작업을 재개한다.