시간과 공간을 통해 이동할 수있는 실시간 컴퓨팅 프레임 워크-플린 링의 시간 처리

Flink는 스트림 처리 아키텍처에 매우 중요합니다. Kafka는 메시지에 지속될 수있는 능력을 제공하며 데이터 및 시간 여행을 처리하는 능력은 Flink에 달려 있습니다.

스트리밍-빅 데이터의 미래에서 우리는 스트리밍 처리에 가장 중요한 두 가지가 정확성과 시간 추론 도구라는 것을 알고 있습니다. Flink는 두 가지 모두에 대해 매우 잘 지원합니다.

Flink는 정확성을 보장합니다

연속 이벤트 스트리밍 데이터의 경우, 처리 할 때 아직 도착하지 않은 이벤트가있을 수 있으므로 데이터의 정확성에 영향을 줄 수 있습니다. 고도의 오프라인 컴퓨팅을 사용하는 일반적인 관행은 이제 보장되지만 낮은 대기 시간을 희생합니다.

Flink의 정확성은 데이터 생성의 자연 법칙에 따라 계산 창의 정의에 반영됩니다. 예를 들어, 클릭 스트림 이벤트는 3 명의 사용자 A, B 및 C의 액세스 상태를 추적합니다. 세션 창인 데이터에 간격이있을 수 있음을 알 수 있습니다.

SparkStreaming의 Microbatch 방법 (점선은 계산 창이고 실선은 세션 창입니다)을 사용하면 계산 창과 세션 창과 일치하기가 어렵습니다. Flink의 스트림 처리 API를 사용하면 계산 창을 유연하게 정의 할 수 있습니다. 예를 들어, 값을 설정할 수 있습니다.이 값을 초과하면 활동이 끝나는 것으로 간주됩니다.

일반 스트림 처리와 달리 Flink는 이벤트 시간을 채택 할 수 있으며 이는 정확성에 매우 유용합니다.

실패의 정확성을 위해서는 계산 상태를 추적해야합니다. 대부분의 경우, 주 보증은 개발자에 의해 완료되지만 연속 스트림 처리 계산은 끝이 없습니다. Flink는 Checkpoint-Checkpoint 기술을 사용 하여이 문제를 해결합니다. 각 체크 포인트에서 시스템은 중간 계산 상태를 기록하며 결함이 발생할 때 재설정하기가 정확합니다. 이 방법을 사용하면 시스템이 오버 헤드 방식으로 결함 공차를 가질 수 있습니다. 모든 것이 정상인 경우 체크 포인트 메커니즘은 시스템에 매우 작은 영향을 미칩니다.

Flink가 제공하는 인터페이스에는 컴퓨팅 작업을 추적하고 동일한 기술을 사용하여 스트림 처리 및 배치 처리를 구현하고 운영 및 유지 보수 개발 작업을 단순화하는 것이 포함되며, 이는 정확성을 보장합니다.

Flink의 시간 처리

스트림 처리와 배치 처리의 가장 큰 차이점은 시간 처리입니다.

배치 처리 아키텍처 사용

이 아키텍처에서는 예를 들어 HDF에 데이터를 한 번씩 저장하고 스케줄러가 정기적으로 실행하여 결과를 출력 할 수 있습니다.

이 아키텍처는 실현 가능하지만 몇 가지 문제가 있습니다.

별도의 부품이 너무 많습니다. 데이터의 이벤트 수를 계산하기 위해이 아키텍처는 너무 많은 시스템을 사용합니다. 모든 시스템에는 학습 비용과 관리 비용이 있으며 버그가있을 수 있습니다. 시간을 처리하는 방법은 불분명합니다. 대신 30 분마다 계산해야한다고 가정하십시오. 이 변경에는 워크 플로 스케줄링 로직 (애플리케이션 코드 로직이 아닌)이 비즈니스 요구 사항에 대한 DevOps 문제를 혼동하는 것이 포함됩니다. 조기 경고. 한 시간에 한 번 계산하는 것 외에도 가능한 빨리 카운트 경고를 받아야한다고 가정하십시오 (예 : 이벤트 수가 10을 초과하는 경우). 이를 위해 STORM을 도입하여 주기적으로 배치 작업을 실행하는 것 외에도 메시지 흐름을 수집 할 수 있습니다. Storm은 실시간으로 대략적인 수를 제공하며 배치 작업은 시간당 정확한 수를 제공합니다. 그러나 이런 식으로 시스템은 아키텍처에 추가되고 새로운 프로그래밍 모델이 추가됩니다. 위의 아키텍처를 Lambda Architecture라고합니다.

​

주문 외 이벤트 스트림. 실제 세계에서는 대부분의 이벤트 스트림이 순서가 좋지 않습니다. 즉, 발생하는 실제 이벤트 순서는 데이터 센터에서 기록한 순서와 다릅니다. 이는 원래 이전 배치에 속한 이벤트가 실수로 현재 배치로 분류 될 수 있음을 의미합니다. 배치 아키텍처는이 문제를 해결하기가 어렵고 대부분의 사람들은이 문제를 무시하기로 선택합니다. 배치 작업의 경계는 불분명합니다. 분할 시간 주변의 이벤트는 이전 배치 또는 현재 배치로 분류 될 수 있습니다. 스트림 처리를 채택하십시오

먼저, 메시지는 메시지 전송 시스템 Kafka에 중앙에 서면으로 작성되며 이벤트 스트림은 메시지 전송 시스템에 의해 제공되며 단일 플린트 작업에 의해서만 처리됩니다.

이벤트 스트림을 시간 단위로 작업의 배치로 나누고이 논리는 플링크 프로그램의 응용 프로그램 논리에 완전히 포함됩니다. 경고는 동일한 프로그램에 의해 생성되며, 외부 이벤트는 Flink 자체에 의해 처리됩니다. 데이터가 생성되는 기간에 따라 고정 된 시간으로 그룹화에서 그룹화로 변경하려면 Flink 프로그램에서 창의 정의를 수정하십시오. 또한 응용 프로그램의 코드가 변경된 경우 Kafka 테마를 간단히 재생하여 응용 프로그램을 재생할 수 있습니다. 스트리밍 아키텍처를 사용하면 코드를 학습, 관리 및 작성 해야하는 시스템을 크게 줄일 수 있습니다. Flink 응용 프로그램 코드 예 :

코드 언어 : JavaScript 코드 실행 수 : 0 달리다 복사

 <code class="javascript">DataStream<LogEvent> stream = env // 通过Kafka生成数据流.addSource(new FlinkKafkaConsumer(...)) // 分组.keyBy("country") // 将时间窗口设为60分钟.timeWindow(Time.minutes(60)) // 针对每个时间窗口进行操作.apply(new CountPerWindowFunction());</code>

스트림 처리에는 두 가지 주요 시간 개념이 있습니다.

이벤트 시간, 즉 이벤트가 실제로 발생하는 시간입니다. 보다 정확하게, 각 이벤트에는 이와 관련된 타임 스탬프가 있으며 타임 스탬프는 데이터 레코드의 일부입니다.

처리 시간, 즉 이벤트가 처리되는 시간. 처리 시간은 실제로 이벤트를 처리하는 기계에서 측정 한 시간입니다.

스타 워즈 시리즈를 예로 들어 보겠습니다. 첫 3 편의 영화는 시리즈의 4, 5, 6 위이며 (이 행사의 시간), 출시 년도는 1977, 1980 및 1983입니다 (이것은 프로세스의 시간입니다). 이벤트 시간에 의해 출시 된 1, 2, 3, 7 번째 시리즈는 해당 처리 시간이 각각 1999, 2002, 2005 및 2015였습니다. 이벤트 흐름의 순서는 지저분 할 수 있음을 알 수 있습니다 (년의 순서는 일반적으로 지저분하지는 않지만)

일반적으로 시간의 세 번째 개념, 즉 입학 시간이라고도하는 섭취 시간이 있습니다. 이벤트가 스트림 처리 프레임 워크에 들어가는 시간을 나타냅니다. 실제 이벤트 시간이없는 데이터는 스트림 프로세서에 의해 타임 스탬프됩니다. 즉 스트림 프로세서가 처음 볼 때 (이 작업은 프로그램의 첫 번째 처리 지점 인 소스 기능에 의해 수행됩니다).

실제 세계에서는 여러 가지 요인 (예 : 다양한 이유로 인한 네트워크 지연, 분산 시스템의 동기화, 데이터 속도의 가파른 증가, 물리적 이유 또는 불운과 같은 많은 요인으로 인해 이벤트 시간 및 처리 시간이 편향되어 있습니다 (즉, 이벤트 시간 편차). 이벤트 시간 순서 및 처리 시간 순서 대기 순서는 종종 일관성이 없으므로 이벤트는 스트림 프로세서에 순서대로 도착 함을 의미합니다.

Flink를 사용하면 사용자가 필요한 의미 및 정확도에 대한 요구 사항에 따라 이벤트 시간, 처리 시간 또는 섭취 시간 정의 Windows를 채택 할 수 있습니다.

창문

시간 창이 가장 쉽고 가장 유용한 것입니다. 스크롤 및 슬라이딩을 지원합니다.

예를 들어, 1 분 스크롤 창은 마지막 순간의 값을 수집하고 1 분의 끝에 합을 출력합니다.

1 분의 슬라이딩 윈도우는 마지막 순간의 값의 합을 계산하지만 반분마다 슬라이드하고 결과를 출력합니다.

Flink에서 1 분 분량의 스크롤 창은 다음과 같이 정의됩니다.

코드 언어 : JavaScript 코드 실행 수 : 0 달리다 복사

 <code class="javascript">stream.timeWindow(Time.minutes(1))</code>

반 분마다 미끄러지는 1 분의 슬라이딩 윈도우 (즉, 30 초)는 다음과 같습니다.

코드 언어 : JavaScript 코드 실행 수 : 0 달리다 복사

 <code class="javascript">stream.timeWindow(Time.minutes(1), Time.seconds(30))</code>

Flink가 지원하는 또 다른 일반적인 창을 카운팅 창이라고합니다. 카운트 창을 사용하면 그룹화가 더 이상 타임 스탬프가 아니라 요소 수입니다.

슬라이딩 윈도우는 또한 두 요소마다 한 번씩 4 개의 요소와 슬라이드로 구성된 카운팅 창으로 해석 할 수 있습니다. 스크롤 및 슬라이딩 카운팅 창은 다음과 같이 정의됩니다.

코드 언어 : JavaScript 코드 실행 수 : 0 달리다 복사

 <code class="javascript">stream.countWindow(4) stream.countWindow(4, 2)</code>

카운팅 창이 유용하지만 정의는 시간 창만큼 엄격하지 않으므로주의해서 사용해야합니다. 시간은 멈추지 않으며 시간 창은 항상 "닫힙니다". 그러나 정의 된 요소의 수가 100이고 키의 해당 요소가 100에 도달하지 않으며 창이 닫히지 않으며 창에 의해 점유 된 메모리가 낭비되는 것으로 가정하면, 윈도우 계산에 관한 한, 키의 해당 요소가 100에 도달하지 않으면.

Flink가 지원하는 또 다른 유용한 창은 세션 창입니다. 세션 창은 시간 초과 시간, 즉 세션이 종료되었다고 생각하기 전에 얼마나 기다리는 데 얼마나 걸립니까? 예는 다음과 같습니다.

코드 언어 : JavaScript 코드 실행 수 : 0 달리다 복사

 <code class="javascript">stream.window(SessionWindows.withGap(Time.minutes(5))</code>

방아쇠

Windows 외에도 Flink는 트리거 메커니즘을 제공합니다. 트리거는 결과가 생성되는 시간, 즉 창 콘텐츠가 집계되고 결과가 사용자에게 반환 될 때를 제어합니다. 각 기본 창에는 트리거가 있습니다. 예를 들어, 이벤트 시간이 걸리는 시간 창이 워터 마크를 수신 할 때 트리거됩니다. 사용자의 경우 워터 마크를 수신 할 때 완전하고 정확한 결과를 생성하는 것 외에도 사용자 정의 트리거도 구현할 수 있습니다.

시간 역 추적

스트림 처리 아키텍처의 핵심 기능은 시간 역 추적 메커니즘입니다. 그것은 데이터 스트림을 과거의 시간으로 되 감고 현재 시간이 처리 될 때까지 핸들러를 다시 시작하는 것을 의미합니다. Kafka는이 기능을 지원합니다.

실시간 스트림 처리는 항상 최신 데이터 (즉, 그림에서 "현재 시간"데이터)를 처리하는 반면, 과거 스트림 처리는 과거부터 시작하여 현재 시간까지 처리 될 수 있습니다. 스트리밍 프로세서는 이벤트 시간을 지원합니다. 즉, 데이터 스트림을 "되감기"하고 동일한 데이터 세트로 동일한 프로그램을 다시 시작하면 동일한 결과가 나타납니다.

양수표

Flink는 워터 마크를 통해 이벤트 시간을 발전시킵니다. 워터 마크는 스트림에 내장 된 기존의 레코드입니다. 계산 프로그램은 워터 마크를 사용하여 특정 시점이 도착했음을 알 수 있습니다. 워터 마크를받는 창은 해당 시간보다 더 이상 기록이 나타나지 않을 것임을 알게됩니다. 타임 스탬프가있는 모든 이벤트가 해당 당시보다 적거나 동일하기 때문입니다. 이 시점에서 창은 안전하게 계산하고 결과를 제공 할 수 있습니다 (합). 워터 마크는 이벤트 시간을 처리 시간과 완전히 독립적으로 만듭니다. 늦은 워터 마크 ( "늦은"은 처리 시간의 관점에서 나온)는 결과의 정확성에 영향을 미치지 않고 수신 된 결과의 속도에만 영향을 미칩니다.

워터 마크는 응용 프로그램 개발자에 의해 생성되며, 일반적으로 해당 필드에 대한 특정 이해가 필요합니다. 완벽한 워터 마크는 결코 잘못 될 수 없습니다. 타임 스탬프가 워터 마크 마크 시간보다 작은 이벤트는 다시 나타나지 않습니다.

워터 마크가 너무 늦으면 결과는 매우 느리게 수신 될 수 있습니다. 해결책은 워터 마크가 도착하기 전에 대략적인 결과를 출력하는 것입니다 (Flink가 할 수 있음). 워터 마크가 너무 일찍 도착하면 오류 결과를받을 수 있지만 늦은 데이터를 처리하는 Flink의 메커니즘은이 문제를 해결할 수 있습니다.

관련 기사 : 스트리밍-빅 데이터의 미래

실시간 컴퓨팅 빅 데이터 처리의 초석 - Google Dataflow

데이터 아키텍처의 미래 - 스트리밍 처리 아키텍처에 대한 간단한 토론

위 내용은 시간과 공간을 통해 이동할 수있는 실시간 컴퓨팅 프레임 워크-플린 링의 시간 처리의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!