Flink는 Spark와 비교되었습니다. Spark 와 비교하면 창 이벤트 처리 시스템과 마이크로 배치를 비교하기 때문에 잘못된 비교입니다. 마찬가지로, Flink와 Samza를 비교하는 것은 그다지 의미가 없습니다. 두 경우 모두 Samza의 경우 "규모"가 더 작더라도 실시간 이벤트와 배치 이벤트 처리 전략을 비교합니다. 그러나 나는 Flink가 Storm과 어떻게 비교되는지 알고 싶습니다. 이것은 개념적으로 훨씬 더 비슷합니다.

Flink에 대한 "조정 가능한 대기 시간"으로 주요 차이점을 설명하는 이 (슬라이드 # 4)를 발견 했습니다 . 또 다른 힌트는 Slicon Angle 의 기사 로, Flink가 Spark 또는 HadoopMR 세계에 더 잘 통합된다고 제안하지만 실제 세부 사항은 언급하거나 언급하지 않았습니다. 마지막으로 Fabian Hueske 는 인터뷰 에서 "Flink의 스트림 분석 기능은 Apache Storm과 비교하여 높은 수준의 API를 제공하고보다 가벼운 내결함성 전략을 사용하여 정확히 한 번의 처리 보장을 제공합니다."

그것은 저에게 조금 희박하며 나는 요점을 얻지 못합니다. 누군가 스톰에서 스트림 처리와 관련된 문제가 Flink에 의해 정확히 어떻게 해결되는지 설명 할 수 있습니까? Hueske는 API 문제와 "보다 가벼운 내결함성 전략"으로 무엇을 언급합니까?

면책 조항 : 저는 Apache Flink 커미터 및 PMC 회원이며 내부가 아닌 Storm의 고급 디자인에만 익숙합니다.

Apache Flink는 통합 스트림 및 일괄 처리를위한 프레임 워크입니다. Flink의 런타임은 파이프 라인 셔플을 포함하는 병렬 작업간에 파이프 라인 데이터 전송으로 인해 기본적으로 두 도메인을 모두 지원합니다. 레코드는 생산 작업에서 수신 작업으로 즉시 배송됩니다 (네트워크 전송을 위해 버퍼에 수집 된 후). 블로킹 데이터 전송을 사용하여 배치 작업을 선택적으로 실행할 수 있습니다.

Apache Spark는 배치 및 스트림 처리도 지원하는 프레임 워크입니다. Flink의 배치 API는 매우 유사 해 보이고 Spark와 유사한 사용 사례를 다루지 만 내부에서는 다릅니다. 스트리밍의 경우 두 시스템 모두 매우 다른 접근 방식 (미니 배치와 스트리밍)을 따르므로 다양한 종류의 응용 프로그램에 적합합니다. Spark와 Flink를 비교하는 것이 유효하고 유용하지만 Spark는 Flink와 가장 유사한 스트림 처리 엔진이 아닙니다.

원래 질문에 따르면 Apache Storm은 배치 기능이없는 데이터 스트림 프로세서입니다. 실제로 Flink의 파이프 라인 엔진은 내부적으로 Storm과 약간 비슷해 보입니다. 즉, Flink의 병렬 작업 인터페이스는 Storm의 볼트와 유사합니다. Storm과 Flink는 공통적으로 파이프 라인 데이터 전송에 의한 낮은 대기 시간 스트림 처리를 목표로합니다. 그러나 Flink는 Storm에 비해 더 높은 수준의 API를 제공합니다. Flink의 DataStream API는 하나 이상의 리더 및 수집기로 볼트 기능을 구현하는 대신 Map, GroupBy, Window 및 Join과 같은 기능을 제공합니다. 이 기능은 Storm을 사용할 때 수동으로 구현해야합니다. 또 다른 차이점은 처리 의미론입니다. Storm은 최소 1 회 처리를 보장하고 Flink는 정확히 1 회 처리를 제공합니다. 이러한 처리 보증을 제공하는 구현은 약간 다릅니다. Storm은 레코드 수준 승인을 사용하지만 Flink는 Chandy-Lamport 알고리즘의 변형을 사용합니다. 간단히 말해서, 데이터 소스는 주기적으로 마커를 데이터 스트림에 주입합니다. 운영자가 이러한 마커를 수신 할 때마다 내부 상태를 체크 포인트합니다. 모든 데이터 싱크가 마커를 수신하면 마커 (및 이전에 처리 된 모든 레코드)가 커밋됩니다. 실패한 경우 모든 소스 운영자는 마지막 커미트 된 마커를보고 처리가 계속 될 때 상태로 재설정됩니다. 이 마커 체크 포인트 방식은 Storm의 레코드 수준 승인보다 더 가볍습니다. 이 데이터 소스는 주기적으로 마커를 데이터 스트림에 주입합니다. 운영자가 이러한 마커를 수신 할 때마다 내부 상태를 체크 포인트합니다. 모든 데이터 싱크가 마커를 수신하면 마커 (및 이전에 처리 된 모든 레코드)가 커밋됩니다. 실패한 경우 모든 소스 운영자는 마지막 커미트 된 마커를보고 처리가 계속 될 때 상태로 재설정됩니다. 이 마커 체크 포인트 방식은 Storm의 레코드 수준 승인보다 더 가볍습니다. 이 데이터 소스는 주기적으로 마커를 데이터 스트림에 주입합니다. 운영자가 이러한 마커를 수신 할 때마다 내부 상태를 체크 포인트합니다. 모든 데이터 싱크가 마커를 수신하면 마커 (및 이전에 처리 된 모든 레코드)가 커밋됩니다. 실패한 경우 모든 소스 운영자는 마지막 커미트 된 마커를보고 처리가 계속 될 때 상태로 재설정됩니다. 이 마커 체크 포인트 방식은 Storm의 레코드 수준 승인보다 더 가볍습니다. 이 모든 소스 운영자는 마지막 커미트 된 마커를보고 처리가 계속 될 때 상태로 재설정됩니다. 이 마커 체크 포인트 방식은 Storm의 레코드 수준 승인보다 더 가볍습니다. 이 모든 소스 운영자는 마지막 커미트 된 마커를보고 처리가 계속 될 때 상태로 재설정됩니다. 이 마커 체크 포인트 방식은 Storm의 레코드 수준 승인보다 더 가볍습니다. 이슬라이드 세트 및 해당 토크 는 내결함성, 검사 점 및 상태 처리를 포함한 Flink의 스트리밍 처리 방식에 대해 설명합니다.

Storm은 또한 Trident라고하는 정확히 한 번 높은 수준의 API를 제공합니다. 그러나 Trident는 미니 배치를 기반으로하므로 Flink보다 Spark와 더 유사합니다.

Flink의 조정 가능한 대기 시간은 Flink가 한 작업에서 다른 작업으로 레코드를 보내는 방식을 나타냅니다. 이전에 Flink는 파이프 라인 데이터 전송을 사용하고 레코드가 생성 되 자마자 전달합니다. 효율성을 위해 이러한 레코드는 버퍼가 가득 차거나 버퍼가 가득 차거나 특정 시간 임계 값이 충족되면 네트워크를 통해 전송됩니다. 이 임계 값은 레코드가 다음 작업으로 전송되지 않고 버퍼에 머무를 최대 시간을 지정하므로 레코드 대기 시간을 제어합니다. 그러나 작업 내 처리 시간 및 네트워크 전송 수에 따라 달라지기 때문에 레코드가 프로그램을 시작하는 데 걸리는 시간에 대해 확실한 보증을 제공하는 데 사용할 수 없습니다.

Fabian Hueske의 답변에 추가 :

Flink는 다음과 같은 방법으로 추가로 Storm에서 향상됩니다.

• 역 압력 : 네트워크 계층의 버퍼 풀을 관리하지만 다운 스트림 운영자는 업스트림 운영자를 매우 압박하기 때문에 Flink의 스트리밍 런타임은 다른 운영자가 다른 속도로 실행할 때 잘 작동합니다.

• 사용자 정의 상태 : Flink를 사용하면 프로그램에서 운영자의 사용자 정의 상태를 유지할 수 있습니다. 이 상태는 실제로 내결함성 검사 점에 참여하여 사용자 정의 사용자 정의 상태를 정확히 한 번 보장합니다. 데이터 스트림과 함께 일관되게 체크 포인트되는 운영자 내부의 사용자 정의 상태 머신 예제 를 참조하십시오 .

• 스트리밍 창 : 스트림 창 및 창 집계는 데이터 스트림 분석을위한 중요한 구성 요소입니다. Flink는 다양한 유형의 창을 지원하는 강력한 윈도우 시스템을 제공합니다.

Storm and Flink에 대한 나의 경험을 바탕으로합니다. 이러한 도구가 다른 접근 방식으로 동일한 문제를 해결할 수 있다고 생각합니다. @Stephan 에원 언급 FLINK의 모든 기능을 내부 API (즉, 폭풍에 의해 일치 할 수 spolts 및 볼트 )와 삼지창 지금 API. 누군가 Trident 가 미니 배치 스타일 이라고 주장하지만 상태 관련 또는 집계가있는 대부분의 복잡한 앱은 창 스타일의 배치 처리에만 의존 할 수 있다고 생각합니다. 그래서 나는 여기에 어느 것이 더 낫다는 말없이 주요 차이점을 나열합니다.

• 개발 스타일 . Flink의 컴퓨팅 지향 (예 : 체인 가능 연산자 addSpolt()/addBolt())과 Storm의 데이터 스트림 지향 (예 :)
• 고급 API . Flink vs. Native Window 및 Trident in Storm의 기능 (예 : 맵, 창, 스트리밍 수준의 조인).
• 보장 된 메시지 처리 (GMP. 즉, 정확히 한 번에 ) . Flink의 2 상 커밋 커넥터 (예 : KafkaConsumer)를 사용하는 체크 포인트와 외부 상태 시스템이있는 튜플 트리 또는 Storm의 Trident가 있습니다.
• 내결함성 . Flink의 마커 검사 점 대 Storm의 레코드 수준 ACK
• 내부 아키텍처 . Flink의 단순 추상화 및 상대 병렬 처리 (예 : CPU 코어로 간주되는 각 스레드의 슬롯) 대 Storm의 멀티 레이어 추상화 (예 : 관리자의 작업자로서 각 JVM의 슬롯 및 각 관리자가 많은 작업자를 가질 수 있음)

면책 조항 : 저는 Storm 및 (곧) Flink의 주요 후원자 인 Cloudera의 직원입니다.

기능의

많은 좋은 기술적 요점이 이미 제시되었습니다. 주요 내용 요약 :

• Flink와 Storm은 이벤트별로 처리 할 수 ​​있습니다.
• 폭풍이 즉시 이벤트 타임을 지원하지 않는 것 같습니다
• Storm은 실험 단계에서 SQL 지원을 해제하지 않았습니다.

비 기능

• 많은 고객이 사용하기 어려운 Storm (너무)을 발견했습니다
• 폭풍 채택이 느려지고 이제 Flink 커뮤니티가 폭풍보다 더 활발한 것으로 보입니다
• Flink는 여전히 할 일이 많지만 (예 : 문서화 된 예) 전반적으로 생각할 수있는 거의 모든 영역에서 발생했습니다.

결론

Cloudera는 최근 HDP에서 Storm의 지원 중단을 발표했습니다. 동시에 Flink는 그 후속으로 발표되었습니다.

따라서 폭풍에 유스 케이스가 있으면 물론 계속 작동합니다. 그러나 새로운 유스 케이스의 경우 Flink 또는 다른 스트리밍 엔진을 살펴볼 것입니다.