Apache Beam 은 Apache Spark 및 Flink를 포함한 여러 러너 백엔드를 지원합니다. 저는 Spark / Flink에 익숙하며 일괄 처리를위한 Beam의 장단점을 확인하려고합니다.
Beam 단어 수 예제를 살펴보면 약간 더 자세한 구문을 사용하여 기본 Spark / Flink 등가물과 매우 유사하다고 느낍니다.
나는 현재 그러한 작업에 대해 Spark / Flink보다 Beam을 선택하는 것이 큰 이점을 보지 못합니다. 지금까지 내가 할 수있는 유일한 관찰 :
Beam 모델의 다른 장단점을 강조하는 더 좋은 예가 있습니까? 통제력 상실이 성능에 미치는 영향에 대한 정보가 있습니까?
이 질문 에서 부분적으로 다루고이 기사 에서 요약 한 스트리밍 측면의 차이를 요구하지 않습니다 (Spark 1.X로 인해 구식).
답변:
Beam이 기존 엔진에 추가하는 몇 가지 사항이 있습니다.
일괄 및 스트리밍 통합. 많은 시스템이 배치와 스트리밍을 모두 처리 할 수 있지만 종종 별도의 API를 통해 처리합니다. 그러나 Beam에서 배치 및 스트리밍은 지연 시간, 완전성 및 비용의 두 지점에 불과합니다. 배치에서 스트리밍에 이르기까지 학습 / 재 작성 절벽이 없습니다. 따라서 오늘 일괄 파이프 라인을 작성했지만 내일 지연 시간을 변경해야한다면 조정이 매우 쉽습니다. 모바일 게임 예제 에서 이러한 종류의 여정을 볼 수 있습니다 .
추상화 수준을 높이는 API : Beam의 API는 기본 런타임의 세부 정보를 유출하는 대신 데이터 및 로직의 속성을 캡처하는 데 중점을 둡니다. 이것은 이식성의 핵심이며 (다음 단락 참조) 런타임에 실행 방법에 많은 유연성을 제공 할 수도 있습니다. ParDo 융합 (함수 구성이라고도 함)과 같은 것은 대다수의 러너가 이미 수행하고있는 매우 기본적인 최적화입니다. 일부 러너에 대해 다른 최적화가 여전히 구현되고 있습니다. 예 : Beam의 소스 API파이프 라인 내의 샤딩을 과도하게 지정하지 않도록 특별히 제작되었습니다. 대신, 러너에게 올바른 후크를 제공하여 사용 가능한 시스템에서 작업의 균형을 동적으로 재조정합니다. 이것은 본질적으로 스 트래 글러 샤드를 제거함으로써 성능에 큰 차이를 만들 수 있습니다. 일반적으로, 우리가 주자에게 더 똑똑해질수록 우리는 더 나아질 것입니다. 데이터, 코드 및 환경이 변화함에 따라 가장 세심한 수동 조정조차도 실패합니다.
런타임 간 이식성. : 데이터 형태와 런타임 요구 사항이 깔끔하게 분리되어 있기 때문에 동일한 파이프 라인을 여러 방식으로 실행할 수 있습니다. 즉, 온 프레미스에서 클라우드로 또는 검증 된 시스템에서 최첨단의 시스템으로 이동해야 할 때 코드를 다시 작성하지 않아도됩니다. 옵션을 매우 쉽게 비교하여 현재 요구 사항에 가장 적합한 환경과 성능의 조합을 찾을 수 있습니다. 이는 오픈 소스 러너를 사용하여 사내에서 민감한 데이터를 처리하고 클라우드의 관리 형 서비스에서 다른 데이터를 처리하는 것의 혼합 일 수 있습니다.
다양한 엔진에 대해 유용한 추상화가되도록 Beam 모델을 설계하는 것은 까다 롭습니다. 빔은 모든 엔진의 기능의 교차점 (너무 제한적입니다!)도 아니고 노조 (주방 싱크대가 너무 많습니다!)도 아닙니다. 대신 Beam은 데이터 처리가 진행되는 최전선에 서서 기능을 런타임 엔진으로 밀어 넣고 패턴을 끌어 내려고합니다.