2.1 Platform Independence
애플리케이션은 주로 특정 플랫폼에 연결된다. 이것은 2가지 이유로 이상적인 경우를 구성하지 않을 수 있다.
첫째, 보다 효율적인 플랫폼을 이용할 수 있게 되면서 개발자들은 이러한 새로운 플랫폼 위에 기존 애플리케이션을 다시 구현할 필요가 있다. 예를들어 Spart SQL과 MLlib는 Hive와 Mahout의 Spark 대응관계이다. 한 플랫폼에서 다른 플랫폼으로 애플리케이션을 마이그레이션하는 것은 시간이 많이 걸리고 비용이 많이 드는 작업이므로 항상 실행 가능한 선택은 아니다.
둘째, 특정 업무의 다른 입력의 경우, 다른 플랫폼이 가장 효율적은 플랫폼일 수 있으므로, 최선의 플랫폼은 정적으로 결정할 수 없다. 예를 들어 대규모 데이터셋을 위해 빅데이터 플랫폼에서 특정 작업을 실행하는 것이 종종 좋은 선택인 반면 오직 간접비용만 적은 단일 노드 플랫폼은 종종 소규모 데이터셋에 더 나은 선택이다. 따라서 입력 데이터셋과 작업에 따라 애플리케이션이 한 플랫폼에서 다른 플랫폼으로 원할하게 전환되도록 하는 것이 중요하다.
Rheem은 들어오는 작업을 수행하는데 가장 적합한 플랫폼을 동적으로 결정한다.
장점
플랫폼 독립성을 제공함으로써 얻을 수 있는 이점을 증명하기 위해 BigDansing을 사용한다. 사용자는 개의 논리 연산자를 가진 데이터 정리 작업을 지정한다.
- Scope(관련 데이터 식별)
- Block(오류가 발생할 수 있는 데이터 그룹 정의)
- Iterate(후보자 오류 열거)
- Detect(후보자 오류가 실제 오류인지 여부 결정)
- GenFix(가능한 수리셋 생성)
Rheem은 이러한 연산자를 Rheem 연산자에게 매핑하여 최상의 기본 플랫폼을 결정한다. 널리 사용되는 세금 데이트셋에 오류 감지 테스트를 실행하여 교체 플랫폼 데이터 처리를 지원하는 능력을 보여준다. 작업은 거부 제약조건 ∀t1, t2, ¬(t1.Salary > t2.Salary ∧t1.Tax < t2.Tax)인 한명은 급여를 더 많이 받지만 세금은 적게낼 경우 두 명의 다른 사람을 대표하는 두개의 튜플이 일치하지 않는다고 기술 하는것을 기반으로 한다. 데이터 정리 툴인 NADEEF와 범용 프레임워크인 SparkSQL을 기준선으로 고려하고 Rheem이 실행 당 Spark 또는 JavaStreams을 사용하도록 강제했다.
그림 3은 결과를 나타낸다. 전반적으로, Rheem(DC@Rheem)은 데이터 정리 작업을 대규모 데이터 셋으로 확장하고 기준선보다 최소 3배 더 빠르게 수행한다는 것을 알 수 있다. Rheem이 플랫폼을 자동으로 전환할 수 있는 능력에서 하나의 큰 증가폭이 있다. Rheem은 Spark의 오버 헤드를 피하여 데이터 정리 작업을 가속화하는 작은 데이터 세트에 JavaStream을 사용했으며, 가장 큰 데이터 세트에는 Spark을 사용했다. 또한 불균형을 효율적으로 처리할 수없는 SparkSQL과 비교하여 Rheem의 확장성은 우리가 더 효율적인 불균형 결합 알고리즘을 연결할 수 있게 해주었고, 따라서 이러한 기준선들을 통해 더 개선되었다.
요약하면 BigDansing은 플랫폼을 효과적으로 전환하는 능력과 최적화된 알고리즘을 쉽게 연결할 수 있는 확장성 때문에
Rheem으로 부터 이득을 얻었다.
