programing

일괄 처리를 위해 Spark / Flink에 비해 Apache Beam의 이점은 무엇인가요?

nasanasas 2020. 12. 25. 10:06
반응형

일괄 처리를 위해 Spark / Flink에 비해 Apache Beam의 이점은 무엇인가요?


Apache Beam 은 Apache Spark 및 Flink를 포함한 여러 러너 백엔드를 지원합니다. 저는 Spark / Flink에 익숙하며 일괄 처리를위한 Beam의 장단점을 확인하려고합니다.

Beam 단어 수 예제를 살펴보면 약간 더 자세한 구문을 사용하여 기본 Spark / Flink 등가물과 매우 유사하다고 느낍니다.

나는 현재 그러한 작업에 대해 Spark / Flink보다 Beam을 선택하는 것이 큰 이점을 보지 못합니다. 지금까지 내가 할 수있는 유일한 관찰 :

  • 장점 : 다른 실행 백엔드에 대한 추상화.
  • 단점 :이 추상화는 Spark / Flink에서 정확히 실행되는 것을 제어 할 수있는 비용이 듭니다.

Beam 모델의 다른 장단점을 강조하는 더 좋은 예가 있습니까? 통제력 상실이 성능에 미치는 영향에 대한 정보가 있습니까?

이 질문 에서 부분적으로 다루고이 기사 에서 요약 한 스트리밍 측면의 차이를 요구하지 않습니다 (Spark 1.X로 인해 구식).


Beam이 기존 엔진에 추가하는 몇 가지 사항이 있습니다.

  • 일괄 및 스트리밍 통합. 많은 시스템이 배치와 스트리밍을 모두 처리 할 수 ​​있지만 종종 별도의 API를 통해 처리합니다. 그러나 Beam에서 배치 및 스트리밍은 지연 시간, 완전성 및 비용의 두 지점에 불과합니다. 배치에서 스트리밍에 이르기까지 학습 / 재 작성 절벽이 없습니다. 따라서 오늘 일괄 파이프 라인을 작성했지만 내일 지연 시간을 변경해야하는 경우 조정이 매우 쉽습니다. 모바일 게임 예제 에서 이러한 종류의 여정을 볼 수 있습니다 .

  • 추상화 수준을 높이는 API : Beam의 API는 기본 런타임의 세부 정보를 유출하는 대신 데이터 및 로직의 속성을 캡처하는 데 중점을 둡니다. 이것은 이식성의 핵심이며 (다음 단락 참조) 런타임에 실행 방법에 많은 유연성을 제공 할 수도 있습니다. ParDo 융합 (함수 구성이라고도 함)과 같은 것은 대부분의 러너가 이미 수행하고있는 매우 기본적인 최적화입니다. 일부 러너에 대해 다른 최적화가 여전히 구현되고 있습니다. 예 : Beam의 소스 API파이프 라인 내의 샤딩을 과도하게 지정하지 않도록 특별히 제작되었습니다. 대신, 러너에게 올바른 후크를 제공하여 사용 가능한 시스템에서 작업의 균형을 동적으로 재조정합니다. 이것은 본질적으로 스 트래 글러 샤드를 제거함으로써 성능에 큰 차이를 만들 수 있습니다. 일반적으로, 우리가 주자에게 더 똑똑해질수록 우리는 더 나아질 것입니다. 데이터, 코드 및 환경이 변화함에 따라 가장 세심한 수동 조정조차도 실패합니다.

  • 런타임 간 이식성. : 데이터 형태와 런타임 요구 사항이 깔끔하게 분리되어 있기 때문에 동일한 파이프 라인을 여러 방식으로 실행할 수 있습니다. 즉, 온 프레미스에서 클라우드로 또는 검증 된 실제 시스템에서 최첨단 시스템으로 이동해야 할 때 코드를 다시 작성하지 않아도됩니다. 옵션을 매우 쉽게 비교하여 현재 요구 사항에 가장 적합한 환경과 성능의 조합을 찾을 수 있습니다. 이는 오픈 소스 러너를 사용하여 사내에서 민감한 데이터를 처리하고 클라우드의 관리 형 서비스에서 다른 데이터를 처리하는 것의 혼합 일 수 있습니다.

다양한 엔진에 대해 유용한 추상화가되도록 Beam 모델을 설계하는 것은 까다 롭습니다. 빔은 모든 엔진 (너무 제한적입니다!)의 기능의 교차점도 아니고 (너무 많은 주방 싱크대!) 조합도 ​​아닙니다. 대신 Beam은 데이터 처리가 진행되는 최전선에 서서 기능을 런타임 엔진으로 밀어 넣고 패턴을 끌어 내려고합니다.

  • Keyed State 는 다양한 엔진에 존재하고 흥미롭고 일반적인 사용 사례를 가능하게했지만 원래 Beam에서 표현할 수 없었던 기능의 훌륭한 예입니다. 최근에 Beam의 설계 원칙 에 따라이 기능의 버전을 포함하도록 Beam 모델을 확장했습니다 .
  • 그 반대의 경우에도 Beam이 다양한 엔진의 로드맵에도 영향을 미치 길 바랍니다. 예를 들어 Flink의 DataStream의 의미 체계 는 Beam (née Dataflow) 모델의 영향을 받았습니다.
  • 이는 또한 주어진 시점에서 서로 다른 Beam 러너에서 기능이 항상 정확히 동일하지는 않음을 의미합니다. 그래서 우리는 사물의 상태를 명확하게 전달하기 위해 능력 매트릭스사용하고 있습니다 .

참조 URL : https://stackoverflow.com/questions/43581127/what-are-the-benefits-of-apache-beam-over-spark-flink-for-batch-processing

반응형