생성 데이터 인텔리전스

스트림 데이터 처리를 통해 실시간으로 데이터를 처리할 수 있습니다. 실시간 데이터 분석을 통해 적시에 최적화된 응답을 제공하는 동시에 전반적인 고객 경험을 개선할 수 있습니다.

아파치 플 링크 상태 저장 실시간 데이터 처리를 허용하는 분산 계산 프레임워크입니다. 일괄 및 스트리밍 작업을 빌드하기 위한 단일 API 세트를 제공하므로 개발자가 제한되지 않은 데이터로 쉽게 작업할 수 있습니다. Apache Flink는 다양한 이벤트 처리 사용 사례를 다루기 위해 다양한 수준의 추상화를 제공합니다.

Amazon Kinesis 데이터 분석 Apache Flink 애플리케이션을 실행하기 위한 서버리스 인프라를 제공하는 AWS 서비스입니다. 이를 통해 개발자는 AWS에서 Apache Flink 클러스터를 구축, 구성 및 유지 관리하는 전문가가 될 필요 없이 가용성이 높고 내결함성이 있으며 확장 가능한 Apache Flink 애플리케이션을 쉽게 구축할 수 있습니다.

데이터 스트리밍 워크로드는 종종 외부 소스(예: 데이터베이스 또는 기타 데이터 스트림)를 통해 스트림의 데이터를 보강해야 합니다. 예를 들어 GPS 장치에서 좌표 데이터를 수신하고 이러한 좌표가 물리적 지리적 위치와 매핑되는 방식을 이해해야 한다고 가정합니다. 지리 위치 데이터로 이를 보강해야 합니다. 여러 접근 방식을 사용하여 사용 사례 및 Apache Flink 추상화 수준에 따라 Kinesis Data Analytics에서 실시간 데이터를 보강할 수 있습니다. 각 방법은 처리량, 네트워크 트래픽 및 CPU(또는 메모리) 사용률에 서로 다른 영향을 미칩니다. 이 게시물에서 우리는 이러한 접근 방식을 다루고 장점과 단점에 대해 논의합니다.

데이터 강화 패턴

데이터 보강은 추가 컨텍스트를 추가하고 수집된 데이터를 향상시키는 프로세스입니다. 추가 데이터는 종종 다양한 소스에서 수집됩니다. 데이터 업데이트의 형식과 빈도는 한 달에 한 번에서 XNUMX초에 여러 번까지 다양할 수 있습니다. 다음 표는 다양한 소스, 형식 및 업데이트 빈도의 몇 가지 예를 보여줍니다.

사용 사례에 따라 데이터 보강 애플리케이션은 대기 시간, 처리량 또는 기타 요소 측면에서 요구 사항이 다를 수 있습니다. 게시물의 나머지 부분에서는 Kinesis Data Analytics의 다양한 데이터 보강 패턴에 대해 자세히 설명합니다. 이러한 패턴은 주요 특성과 함께 다음 표에 나열되어 있습니다. 이러한 특성의 균형을 기반으로 최상의 패턴을 선택할 수 있습니다.

참조 데이터를 미리 로드하여 스트리밍 데이터 강화

참조 데이터가 크기가 작고 본질적으로 정적인 경우(예: 국가 코드 및 국가 이름을 포함한 국가 데이터), 여러 가지 방법으로 수행할 수 있는 참조 데이터를 미리 로드하여 스트리밍 데이터를 보강하는 것이 좋습니다.

다양한 방법으로 참조 데이터를 미리 로드하기 위한 코드 구현을 보려면 다음을 참조하십시오. GitHub 레포. GitHub 리포지토리의 지침에 따라 코드를 실행하고 데이터 모델을 이해합니다.

Apache Flink 작업 관리자 메모리에 참조 데이터 사전 로드

가장 간단하고 빠른 보강 방법은 보강 데이터를 Apache Flink 작업 관리자의 온힙 메모리에 로드하는 것입니다. 이 메서드를 구현하려면 다음을 확장하여 새 클래스를 만듭니다. RichFlatMapFunction 추상 클래스. 클래스 정의에서 전역 정적 변수를 정의합니다. 변수는 모든 유형이 될 수 있지만 유일한 제한은 확장해야 한다는 것입니다. java.io.Serializable-예를 들어, java.util.HashMap. 내 open() 메서드를 사용하여 정의된 변수에 정적 데이터를 로드하는 논리를 정의합니다. 그만큼 open() 메서드는 Apache Flink의 작업 관리자에서 각 작업을 초기화하는 동안 항상 먼저 호출되어 처리가 시작되기 전에 전체 참조 데이터가 로드되도록 합니다. 재정의하여 처리 논리를 구현합니다. processElement() 방법. 처리 논리를 구현하고 정의된 전역 변수의 키로 참조 데이터에 액세스합니다.

다음 아키텍처 다이어그램은 작업 관리자의 각 작업 슬롯에 있는 전체 참조 데이터 로드를 보여줍니다.

이 방법에는 다음과 같은 이점이 있습니다.

• 손쉬운 구현
• 낮은 대기 시간
• 높은 처리량을 지원할 수 있습니다.

그러나 다음과 같은 단점이 있습니다.

• 참조 데이터의 크기가 크면 Apache Flink 작업 관리자의 메모리가 부족할 수 있습니다.
• 참조 데이터는 일정 기간 동안 유효하지 않을 수 있습니다.
• 동일한 참조 데이터의 여러 복사본이 작업 관리자의 각 작업 슬롯에 로드됩니다.
• 참조 데이터는 단일 작업 슬롯에 할당된 메모리에 맞게 작아야 합니다. Kinesis Data Analytics에서 각 Kinesis Processing Unit(KPU)에는 4GB의 메모리가 있으며 이 중 3GB는 힙 메모리에 사용할 수 있습니다. 만약에 ParallelismPerKPU Kinesis Data Analytics에서 1로 설정되고 각 작업 관리자에서 하나의 작업 슬롯이 실행되며 작업 슬롯은 전체 3GB 힙 메모리를 사용할 수 있습니다. 만약에 ParallelismPerKPU 가 1보다 큰 값으로 설정되면 3GB의 힙 메모리가 작업 관리자의 여러 작업 슬롯에 분산됩니다. Apache Flink를 배포하는 경우 아마존 EMR 또는 자체 관리 모드에서 taskmanager.memory.task.heap.size 작업 관리자의 힙 메모리를 늘리십시오.

Apache Flink State에서 참조 데이터의 분할된 사전 로드

이 접근 방식에서 참조 데이터는 Apache Flink 애플리케이션 시작 시 Apache Flink 상태 저장소에 로드되고 유지됩니다. 메모리 활용을 최적화하기 위해 먼저 메인 데이터 스트림을 지정된 필드로 나눕니다. keyBy() 모든 작업 슬롯에서 연산자. 또한 각 작업 슬롯에 해당하는 참조 데이터 부분만 상태 저장소에 로드됩니다.

이것은 클래스를 생성하여 Apache Flink에서 달성됩니다. PartitionPreLoadEnrichmentData, 확장 RichFlatMapFunction 추상 클래스. open 메서드 내에서 재정의합니다. ValueStateDescriptor 상태 핸들을 생성하는 메소드. 참조된 예에서 디스크립터의 이름은 locationRefData, 상태 키 유형은 문자열이고 값 유형은 Location. 이 코드에서 우리는 ValueState 반면 MapState 특정 키에 대한 위치 참조 데이터만 보유하고 있기 때문입니다. 예를 들어 위치 참조 데이터를 가져오기 위해 Amazon S3에 쿼리할 때 특정 역할을 쿼리하고 특정 위치를 값으로 가져옵니다.

아파치 플링크에서는 ValueState 키에 대한 특정 값을 유지하는 데 사용되는 반면 MapState 키-값 쌍의 조합을 유지하는 데 사용됩니다.

이 기술은 각 파티션의 전체 메모리에 맞추기 어려운 큰 정적 데이터 세트가 있는 경우에 유용합니다.

다음 아키텍처 다이어그램은 스트림의 각 파티션에 대한 특정 키에 대한 참조 데이터 로드를 보여줍니다.

예를 들어 샘플 GitHub 코드의 참조 데이터에는 각 건물에 매핑되는 역할이 있습니다. 스트림이 역할별로 분할되기 때문에 역할별 특정 건물 정보만 참조 데이터로 각 분할에 대해 로드되어야 합니다.

이 방법에는 다음과 같은 이점이 있습니다.

• 낮은 대기 시간.
• 높은 처리량을 지원할 수 있습니다.
• 특정 파티션에 대한 참조 데이터는 키 입력 상태로 로드됩니다.
• Kinesis Data Analytics에서 구성된 기본 상태 저장소는 RocksDB입니다. RocksDB는 각 KPU에서 제공하는 1GB의 관리 메모리와 50GB의 디스크 공간의 상당 부분을 활용할 수 있습니다. 이는 참조 데이터가 증가할 수 있는 충분한 공간을 제공합니다.

그러나 다음과 같은 단점이 있습니다.

• 참조 데이터는 일정 기간 동안 유효하지 않을 수 있습니다.

Apache Flink State에서 참조 데이터의 주기적 분할 사전 로드

이 접근 방식은 각 분할된 참조 데이터가 참조 데이터를 새로 고치기 위해 주기적으로 다시 로드되는 이전 기술의 미세 조정입니다. 이는 참조 데이터가 가끔 변경되는 경우에 유용합니다.

다음 아키텍처 다이어그램은 스트림의 각 파티션에 대한 특정 키에 대한 참조 데이터의 주기적 로드를 보여줍니다.

이 접근 방식에서 클래스 PeriodicPerPartitionLoadEnrichmentData 생성, 확장 KeyedProcessFunction 수업. GitHub 예제의 컨텍스트에서 이전 패턴과 유사하게, ValueState 각 파티션은 키에 대해 단일 값만 로드하기 때문에 여기에서 권장됩니다. 앞서 언급한 것과 같은 방식으로, open 방법, 당신은 정의 ValueStateDescriptor 값 상태를 처리하고 상태에 액세스하기 위한 런타임 컨텍스트를 정의합니다.

내 processElement 메서드에서 값 상태를 로드하고 참조 데이터를 첨부합니다(참조된 GitHub 예제에서, buildingNo 고객 데이터). 또한 처리 시간이 지정된 시간이 지나면 호출될 타이머 서비스를 등록합니다. 샘플 코드에서 타이머 서비스는 주기적으로(예: 60초마다) 호출되도록 예약되어 있습니다. 에서 onTimer 메서드에서 특정 역할에 대한 참조 데이터를 다시 로드하도록 호출하여 상태를 업데이트합니다.

이 방법에는 다음과 같은 이점이 있습니다.

• 낮은 대기 시간.
• 높은 처리량을 지원할 수 있습니다.
• 특정 파티션에 대한 참조 데이터는 키 입력 상태로 로드됩니다.
• 참조 데이터는 주기적으로 갱신됩니다.
• Kinesis Data Analytics에서 구성된 기본 상태 저장소는 RocksDB입니다. 또한 각 KPU에서 50GB의 디스크 공간을 제공합니다. 이는 참조 데이터가 증가할 수 있는 충분한 공간을 제공합니다.

그러나 다음과 같은 단점이 있습니다.

• 참조 데이터가 자주 변경되는 경우 상태가 다시 로드되는 빈도에 따라 응용 프로그램에 여전히 부실 데이터가 있습니다.
• 애플리케이션은 참조 데이터를 다시 로드하는 동안 로드 스파이크에 직면할 수 있습니다.

레코드별 조회를 사용하여 스트리밍 데이터 강화

참조 데이터의 사전 로드는 짧은 대기 시간과 높은 처리량을 제공하지만 다음과 같은 특정 유형의 워크로드에는 적합하지 않을 수 있습니다.

• 높은 빈도로 참조 데이터 업데이트
• Apache Flink는 비즈니스 로직을 계산하기 위해 외부 호출을 해야 합니다.
• 출력의 정확성이 중요하며 애플리케이션에서 오래된 데이터를 사용해서는 안 됩니다.

일반적으로 이러한 유형의 사용 사례의 경우 개발자는 데이터 정확도를 위해 높은 처리량과 짧은 대기 시간을 절충합니다. 이 섹션에서는 레코드별 데이터 강화를 위한 몇 가지 일반적인 구현과 그 장점과 단점에 대해 알아봅니다.

순서가 지정되지 않은 맵을 사용한 레코드별 비동기 조회

동기식 레코드별 조회 구현에서 Apache Flink 애플리케이션은 모든 요청을 보낸 후 응답을 수신할 때까지 기다려야 합니다. 이로 인해 프로세서가 상당한 처리 시간 동안 유휴 상태를 유지합니다. 대신 애플리케이션은 첫 번째 요소에 대한 응답을 기다리는 동안 스트림의 다른 요소에 대한 요청을 보낼 수 있습니다. 이러한 방식으로 대기 시간은 여러 요청에 걸쳐 분할 상환되므로 프로세스 처리량이 증가합니다. Apache Flink 제공 외부 데이터 액세스를 위한 비동기 I/O. 이 패턴을 사용하는 동안 다음 중에서 결정해야 합니다. unorderedWait (여기서 스트림의 요소 순서는 무시하고 응답이 수신되는 즉시 다음 연산자에게 결과를 내보냄) orderedWait (여기서 모든 진행 중인 I/O 작업이 완료될 때까지 기다린 다음 원래 요소가 스트림에 배치된 것과 동일한 순서로 결과를 다음 연산자로 보냅니다). 일반적으로 다운스트림 소비자가 스트림의 요소 순서를 무시할 때 unorderedWait 더 나은 처리량과 더 적은 유휴 시간을 제공합니다. 방문 Apache Flink용 Kinesis Data Analytics를 사용하여 비동기식으로 데이터 스트림 강화 이 패턴에 대해 자세히 알아보세요.

다음 아키텍처 다이어그램은 Kinesis Data Analytics의 Apache Flink 애플리케이션이 외부 데이터베이스 엔진(예: 아마존 DynamoDB) 메인 스트림의 모든 이벤트에 대해.

이 방법에는 다음과 같은 이점이 있습니다.

• 여전히 합리적으로 간단하고 구현하기 쉽습니다.
• 최신 참조 데이터를 읽습니다.

그러나 다음과 같은 단점이 있습니다.

• 참조 데이터를 호스팅하는 외부 시스템(예: 데이터베이스 엔진 또는 외부 API)에 대한 읽기 로드가 많이 발생합니다.
• 전반적으로 낮은 대기 시간과 높은 처리량이 필요한 시스템에는 적합하지 않을 수 있습니다.

외부 캐시 시스템에서 레코드별 비동기 조회

이전 패턴을 향상시키는 방법은 캐시 시스템을 사용하여 모든 조회 I/O 호출에 대한 읽기 시간을 향상시키는 것입니다. 당신이 사용할 수있는 아마존 엘라스티캐시 for 캐싱, 애플리케이션 및 데이터베이스 성능을 가속화하거나 세션 저장소, 게임 순위표, 스트리밍 및 분석과 같이 내구성이 필요하지 않은 사용 사례를 위한 기본 데이터 저장소로 사용할 수 있습니다. ElastiCache는 Redis 및 Memcached와 호환됩니다.

이 패턴이 작동하려면 캐시 저장소에 데이터를 채우기 위한 캐싱 패턴을 구현해야 합니다. 애플리케이션 목표와 대기 시간 요구 사항에 따라 사전 예방적 또는 사후 대응적 접근 방식 중에서 선택할 수 있습니다. 자세한 내용은 캐싱 패턴.

다음 아키텍처 다이어그램은 Apache Flink 애플리케이션이 외부 캐시 스토리지에서 참조 데이터를 읽기 위해 호출하는 방법을 보여줍니다(예: Redis용 Amazon ElastiCache). 데이터 변경 사항은 기본 데이터베이스에서 복제되어야 합니다(예: Amazon Aurora) 중 하나를 구현하여 캐시 스토리지에 캐싱 패턴.

이 데이터 강화 패턴의 구현은 레코드별 비동기 조회 패턴과 유사합니다. 유일한 차이점은 Apache Flink 애플리케이션이 기본 데이터베이스에 연결하는 대신 캐시 저장소에 연결한다는 것입니다.

이 방법에는 다음과 같은 이점이 있습니다.

• 캐싱이 애플리케이션 및 데이터베이스 성능을 가속화할 수 있으므로 처리량 향상
• 스트림 처리 애플리케이션에서 생성된 읽기 트래픽으로부터 기본 데이터 소스를 보호합니다.
• 모든 조회 호출에 대해 더 낮은 읽기 지연 시간을 제공할 수 있습니다.
• 전반적으로 데이터 신선도를 향상시키려는 중간에서 높은 처리량 시스템에는 적합하지 않을 수 있습니다.

그러나 다음과 같은 단점이 있습니다.

• 기본 데이터베이스와 캐시 스토리지 간에 데이터를 채우고 동기화하기 위한 캐시 패턴 구현의 추가 복잡성
• 구현된 캐싱 패턴에 따라 Apache Flink 스트림 처리 애플리케이션이 오래된 참조 데이터를 읽을 가능성이 있습니다.
• 선택한 캐시 패턴(사전 또는 사후)에 따라 각 보강 I/O에 대한 응답 시간이 다를 수 있으므로 스트림의 전체 처리 시간을 예측할 수 없습니다.

또는 다음을 사용하여 이러한 복잡성을 피할 수 있습니다. Flink SQL API용 Apache Flink JDBC 커넥터. 이 게시물 뒷부분에서 Flink SQL API를 통한 강화 스트림 데이터에 대해 자세히 설명합니다.

다른 스트림을 통해 스트림 데이터 강화

이 패턴에서 기본 스트림의 데이터는 다른 데이터 스트림의 참조 데이터로 보강됩니다. 이 패턴은 참조 데이터가 자주 업데이트되고 변경 데이터 캡처(CDC)를 수행하고 이벤트를 Apache Kafka 또는 Amazon Kinesis 데이터 스트림. 이 패턴은 다음과 같은 사용 사례에서 유용합니다.

• 고객 구매 주문은 Kinesis 데이터 스트림에 게시된 다음 고객 청구 정보와 결합됩니다. DynamoDB 스트림
• IoT 장치에서 캡처한 데이터 이벤트는 다음 표의 참조 데이터로 풍부해야 합니다. Amazon 관계형 데이터베이스 서비스 (아마존 RDS)
• 네트워크 로그 이벤트는 소스(및 대상) IP 주소의 시스템 이름으로 풍부해야 합니다.

다음 아키텍처 다이어그램은 Kinesis Data Analytics의 Apache Flink 애플리케이션이 메인 스트림의 데이터를 DynamoDB 스트림의 CDC 데이터와 결합하는 방법을 보여줍니다.

다른 스트림에서 스트리밍 데이터를 강화하기 위해 공통 스트림을 사용하여 다음 섹션에서 설명하는 스트림 결합 패턴을 사용합니다.

Table API를 사용하여 스트림 강화

Apache Flink Table API는 데이터 이벤트 작업을 위한 더 높은 추상화를 제공합니다. 와 함께 테이블 API, 데이터 스트림을 테이블로 정의하고 여기에 데이터 스키마를 첨부할 수 있습니다.

이 패턴에서는 각 데이터 스트림에 대한 테이블을 정의한 다음 해당 테이블을 조인하여 데이터 강화 목표를 달성합니다. Apache Flink 테이블 API 지원 다양한 유형의 조인 조건, 내부 조인 및 외부 조인과 같습니다. 그러나 리소스 집약적이기 때문에 무제한 스트림을 처리하는 경우 이러한 스트림을 피하고 싶습니다. 리소스 사용률을 제한하고 조인을 효과적으로 실행하려면 간격 또는 임시 조인을 사용해야 합니다. 간격 조인에는 하나의 동등 조인 조건자와 양쪽의 시간을 제한하는 조인 조건이 필요합니다. 간격 조인을 구현하는 방법을 더 잘 이해하려면 다음을 참조하십시오. Kinesis Data Analytics Studio에서 Apache Flink SQL API 시작하기.

간격 조인과 비교할 때 시간 테이블 조인은 다른 버전의 레코드가 보관되는 기간에는 작동하지 않습니다. 메인 스트림의 레코드는 항상 워터마크로 지정된 시간에 해당 버전의 참조 데이터와 결합됩니다. 따라서 더 적은 수의 참조 데이터 버전이 상태에 남아 있습니다.

참조 데이터에는 연결된 시간 요소가 있을 수도 있고 없을 수도 있습니다. 그렇지 않은 경우 시간 기반 스트림과의 조인에 대한 처리 시간 요소를 추가해야 할 수 있습니다.

다음 예제 코드 조각에서 update_time 열이 추가됩니다. currency_rates Debezium과 같은 변경 데이터 캡처 메타데이터의 참조 테이블입니다. 또한 다음을 정의하는 데 사용됩니다. 워터 마크 테이블에 대한 전략.

CREATE TABLE currency_rates (
    currency STRING,
    conversion_rate DECIMAL(32, 2),
    update_time TIMESTAMP(3) METADATA FROM `values.source.timestamp` VIRTUAL,
        WATERMARK FOR update_time AS update_time,
    PRIMARY KEY(currency) NOT ENFORCED
) WITH (
   'connector' = 'kafka',
   'value.format' = 'debezium-json',
   /* ... */
);

저자에 관하여

알리 알레미 AWS의 스트리밍 전문가 솔루션 아키텍트입니다. Ali는 AWS 고객에게 아키텍처 모범 사례를 조언하고 안정적이고 안전하며 효율적이고 비용 효율적인 실시간 분석 데이터 시스템을 설계할 수 있도록 지원합니다. 그는 고객의 사용 사례에서 거꾸로 작업하고 비즈니스 문제를 해결하기 위한 데이터 솔루션을 설계합니다. AWS에 합류하기 전에 Ali는 여러 공공 부문 고객과 AWS 컨설팅 파트너의 애플리케이션 현대화 여정과 클라우드로의 마이그레이션을 지원했습니다.

수밤 락시트 영국에 기반을 둔 AWS의 분석용 스트리밍 전문가 솔루션 설계자입니다. 그는 고객과 협력하여 비즈니스 목표를 달성하는 데 도움이 되는 검색 및 스트리밍 데이터 플랫폼을 설계하고 구축합니다. 직장 밖에서 그는 딸과 함께 직소 퍼즐을 푸는 데 시간을 보내는 것을 즐깁니다.

샘 목타리 박사 AWS의 수석 솔루션 아키텍트입니다. 그의 주요 심층 영역은 데이터 및 분석이며 이 분야에서 30개 이상의 영향력 있는 기사를 발표했습니다. 그는 또한 에너지, 건강, 통신 및 운송을 포함한 다양한 산업 전반에 걸쳐 여러 대규모 구현 프로젝트를 주도한 존경받는 데이터 및 분석 고문입니다.