스트리밍 수집

스트리밍 수집은 지연 시간이 짧고 빠른 속도로 Amazon Kinesis Data Streams 및 Amazon Managed Streaming for Apache Kafka에서 Amazon Redshift 프로비저닝된 또는 Amazon Redshift 서버리스 구체화된 뷰로 스트림 데이터를 수집할 수 있습니다. 데이터에 액세스하는 데 걸리는 시간이 단축되고 스토리지 비용이 절감됩니다. Amazon Redshift에서 구체화된 뷰 생성에 설명된 대로 Amazon Redshift 클러스터 또는 Amazon Redshift Serverless에 대한 스트리밍 수집을 구성하고 SQL 문을 사용하여 구체화된 뷰를 생성할 수 있습니다. 그런 다음 구체화된 뷰 새로 고침을 사용하여 초당 수백 메가바이트의 데이터를 수집할 수 있습니다. 따라서 빠르게 새로 고쳐지는 외부 데이터에 빠르게 액세스할 수 있습니다.

데이터 흐름

Amazon Redshift 프로비저닝된 클러스터 또는 Amazon Redshift 서버리스 작업 그룹이 스트림 소비자입니다. 구체화된 뷰는 스트림에서 읽은 데이터의 랜딩 영역으로, 데이터가 도착하면 처리됩니다. 예를 들어 익숙한 SQL을 사용하여 JSON 값을 사용하고 구체화된 뷰의 데이터 열에 매핑할 수 있습니다. 구체화된 뷰가 새로 고쳐지면 Redshift는 뷰가 Kinesis 스트림의 SEQUENCE_NUMBER 또는 Kafka 주제의 마지막 Offset과 패리티에 도달할 때까지 할당된 Kinesis 데이터 샤드 또는 Kafka 파티션의 데이터를 소비합니다 후속 구체화된 뷰는 이전에 새로 고침한 마지막 SEQUENCE_NUMBER의 읽은 데이터를 스트림 또는 주제 데이터와 패리티가 될 때까지 새로 고칩니다.

스트리밍 수집 사용 사례

Amazon Redshift 스트리밍 수집의 사용 사례에는 지속적으로 생성(스트리밍)되고 짧은 생성 기간(지연 시간) 내에 처리되어야 하는 데이터 작업이 포함됩니다. 이를 실시간에 가까운 분석이라고 합니다. 데이터 소스는 다양할 수 있으며 IoT 디바이스, 시스템 원격 측정 데이터 또는 사용량이 많은 웹 사이트 또는 애플리케이션의 클릭스트림 데이터를 포함할 수 있습니다.

스트리밍 수집 고려 사항

다음은 스트리밍 수집 환경을 설정할 때 성능 및 청구에 대한 중요한 고려 사항 및 모범 사례입니다.

• 자동 새로 고침 및 활성화 - 구체화된 뷰에 대한 자동 새로 고침 쿼리는 다른 사용자 워크로드로 처리됩니다. 자동 새로 고침은 데이터가 도착하면 스트림에서 데이터를 로드합니다.

  스트리밍 수집을 위해 생성된 구체화된 뷰에 대해 자동 새로 고침을 명시적으로 설정할 수 있습니다. 이렇게 하려면 구체화된 뷰 정의에서 AUTO REFRESH를 지정합니다. 기본값은 수동 새로 고침입니다. 스트리밍 수집을 위해 기존 구체화된 뷰에 대한 자동 새로 고침을 지정하려면, ALTER MATERIALIZED VIEW를 실행하여 새로 고침을 켜야 합니다. 자세한 내용은 구체화된 뷰 생성 또는 구체화된 뷰 변경을 참조하세요.

• 스트리밍 수집 및 Amazon Redshift Serverless - 프로비저닝된 클러스터의 Amazon Redshift 스트리밍 수집에 적용되는 것과 동일한 설정 및 구성 지침이 Amazon Redshift Serverless의 스트리밍 수집에도 적용됩니다. 자동 새로 고침 및 기타 워크로드로 스트리밍 수집을 지원하려면 필요한 수준의 RPU로 Amazon Redshift Serverless의 크기를 조정하는 것이 중요합니다. 자세한 내용은 Amazon Redshift Serverless에 대한 청구를 참조하세요.

• Amazon MSK 클러스터와 다른 가용 영역에 있는 Amazon Redshift 노드 - 스트리밍 수집을 구성할 때 Amazon MSK에 대해 랙 인식이 활성화된 경우 Amazon Redshift는 동일한 가용 영역에 있는 Amazon MSK 클러스터에 연결을 시도합니다. 모든 노드가 Amazon Redshift 클러스터와 다른 가용 영역에 있는 경우 교차 가용 영역 데이터 전송 비용이 발생할 수 있습니다. 이를 방지하려면 Redshift 프로비저닝 클러스터 또는 작업 그룹과 동일한 AZ에 하나 이상의 Amazon MSK 브로커 클러스터 노드를 유지하세요.

• 새로 고침 시작 위치 - 구체화된 뷰를 생성한 후 초기 새로 고침은 Kinesis 스트림의 TRIM_HORIZON 또는 Amazon MSK 주제의 오프셋 0에서 시작됩니다.

• 데이터 형식 - 지원되는 데이터 형식은 VARBYTE에서 변환할 수 있는 형식으로 제한됩니다. 자세한 내용은 VARBYTE 형식 및 VARBYTE 연산자 단원을 참조하세요.

• 테이블에 레코드 추가 - ALTER TABLE APPEND를 실행하여 기존 소스 구체화된 뷰에서 대상 테이블에 행을 추가할 수 있습니다. 구체화된 뷰가 스트리밍 수집을 위해 구성된 경우에만 작동합니다. 자세한 내용은 ALTER TABLE APPEND을 참조하세요.

• TRUNCATE 또는 DELETE 실행 - 다음 방법을 사용하여 스트리밍 수집에 사용되는 구체화된 뷰에서 레코드를 제거할 수 있습니다.

  • TRUNCATE - 이 명령은 스트리밍 수집을 위해 구성된 구체화된 뷰에서 행을 모두 삭제합니다. 테이블 스캔은 수행하지 않습니다. 자세한 내용은 TRUNCATE를 참조하세요.

  • DELETE - 이 명령은 스트리밍 수집을 위해 구성된 구체화된 뷰에서 행을 모두 삭제합니다. 자세한 내용은 DELETE를 참조하세요.

스트리밍 수집 모범 사례 및 권장 사항

스트리밍 수집을 구성하는 방법에 대한 옵션이 제공되는 경우가 있습니다. 다음 모범 사례를 따르는 것이 좋습니다. 이는 자체 테스트를 기반으로 하며 고객이 데이터 손실을 초래할 수 있는 문제를 방지하도록 지원합니다.

• 스트리밍된 데이터에서 값 추출 - 구체화된 뷰 정의에서 JSON_EXTRACT_PATH_TEXT 함수를 사용하여 들어오는 스트리밍 JSON을 나누는 경우 성능과 지연 시간에 큰 영향을 미칠 수 있습니다. 설명하자면, JSON_EXTRACT_PATH_TEXT를 사용하여 추출한 각 열에 대해 수신되는 JSON이 다시 구문 분석됩니다. 그 후에는 데이터 형식 변환, 필터링, 비즈니스 로직이 발생합니다. 즉, 예를 들어 JSON 데이터에서 10개의 열을 추출하면 각 JSON 레코드가 10번 구문 분석되며 여기에는 형식 변환 및 추가 로직이 포함됩니다. 이에 따라 수집 지연 시간이 길어집니다. 또한 JSON_PARSE 함수를 사용하여 JSON 레코드를 Redshift의 SUPER 데이터 형식으로 변환하는 대안적인 접근 방식도 권장합니다. 스트리밍된 데이터가 구체화된 뷰에 도착한 후 PartiQL을 사용하여 SUPER의 JSON 데이터 표현에서 개별 문자열을 추출합니다. 자세한 내용은 비정형 데이터 쿼리를 참조하세요.

  JSON_EXTRACT_PATH_TEXT의 최대 데이터 크기는 64KB라는 점에도 유의해야 합니다. 따라서 JSON 레코드가 64KB보다 큰 경우 JSON_EXTRACT_PATH_TEXT로 처리 시 오류가 발생합니다.

• Amazon Kinesis Data Streams 스트림 또는 Amazon MSK 주제를 Amazon Redshift 스트리밍 수집 구체화된 뷰에 매핑 - 단일 Amazon Kinesis Data Streams 스트림 또는 Amazon MSK 주제에서 데이터를 수집하기 위해 스트리밍 수집 구체화된 뷰를 여러 개 생성하지 않는 것이 좋습니다. 각각의 구체화된 뷰가 Kinesis Data Streams 스트림 또는 Kafka 주제의 파티션에 있는 각 샤드에 대한 소비자를 생성하기 때문입니다. 이로 인해 스트림 또는 주제의 처리량이 제한되거나 초과될 수 있습니다. 또한 동일한 데이터를 여러 번 수집하므로 비용이 더 많이 들 수도 있습니다. 각 스트림 또는 주제에 대해 하나의 스트리밍 구체화된 뷰를 생성하는 것이 좋습니다.

  사용 사례에서 하나의 KDS 스트림 또는 MSK 주제의 데이터를 여러 구체화된 뷰에 배치해야 하는 경우 그렇게 하기 전에 AWS 빅 데이터 블로그, 특히 Amazon MSK에서 Amazon Redshift 스트리밍 수집을 사용하여 거의 실시간 분석을 구현하는 모범 사례를 참조하세요.

Amazon S3의 스테이징 데이터와 스트리밍 수집 사용 비교

Amazon Redshift 또는 Amazon Redshift Serverless로 데이터를 스트리밍하는 데는 몇 가지 옵션이 있습니다. 잘 알려진 두 가지 옵션은 이 주제에서 설명한 것과 같은 스트리밍 수집이나 Firehose를 사용하여 Amazon S3로 전송 스트림을 설정하는 것입니다. 다음 목록에 각 방법이 설명되어 있습니다.

1. Kinesis Data Streams 또는 Amazon Managed Streaming for Apache Kafka에서 Amazon Redshift 또는 Amazon Redshift Serverless로 스트리밍을 수집하려면 데이터를 수신하도록 구체화된 뷰를 구성해야 합니다.

2. Kinesis Data Streams를 사용하여 Amazon Redshift로 데이터를 전송하고 Firehose를 통해 스트리밍하려면 소스 스트림을 Amazon Data Firehose에 연결하고 Firehose가 Amazon S3에 데이터를 스테이징할 때까지 기다려야 합니다. 이 프로세스는 다양한 길이의 버퍼 간격에서 다양한 크기의 배치를 사용합니다. Amazon S3로 스트리밍한 후 Firehose는 COPY 명령을 시작하여 데이터를 로드합니다.

스트리밍 수집을 사용하면 두 번째 프로세스에 필요한 몇 가지 단계를 생략할 수 있습니다.

• 스트리밍 수집을 사용하면 데이터를 Kinesis Data Streams에서 Redshift 데이터베이스의 구체화된 뷰로 직접 전송할 수 있으므로 Amazon Data Firehose 전송 스트림으로 데이터를 전송할 필요가 없습니다.

• 스트리밍 수집 데이터는 Redshift 구체화된 뷰로 직접 전송되므로 Amazon S3에 스트리밍된 데이터를 가져올 필요가 없습니다.

• 구체화된 뷰의 데이터가 스트림에서 직접 새로 고쳐지므로 COPY 명령을 작성하고 실행할 필요가 없습니다. Amazon S3에서 Redshift로 데이터를 로드하는 것은 프로세스의 일부가 아닙니다.

스트리밍 수집은 Amazon Kinesis Data Streams와 Amazon MSK의 주제로만 제한된다는 점에 유의하세요. Kinesis Data Streams에서 Amazon Redshift 이외의 대상으로 스트리밍하려면 Firehose 전송 스트림이 필요할 수 있습니다. 자세한 내용은 Amazon Data Firehose 전송 스트림으로 데이터 전송을 참조하세요.

고려 사항

다음은 Amazon Redshift 데이터를 공유하기 위한 고려 사항입니다.

기능 또는 특성	설명
Kafka 주제 길이 제한	이름이 128자(따옴표 제외)보다 긴 Kafka 주제를 사용할 수 없습니다. 자세한 내용은 이름 및 식별자 단원을 참조하세요.
구체화된 뷰에서의 증분 새로 고침 및 JOIN	구체화된 보기는 점진적으로 유지 관리할 수 있어야 합니다. Kinesis 또는 Amazon MSK는 기본적으로 24시간 또는 7일 동안의 스트림 또는 주제 기록을 보존하지 않기 때문에 전체 재계산이 불가능합니다. Kinesis 또는 Amazon MSK에서 더 긴 데이터 보존 기간을 설정할 수 있습니다. 그러나 이렇게 하면 더 많은 유지 관리 및 비용이 발생할 수 있습니다. 또한 JOIN은 현재 Kinesis 스트림 또는 Amazon MSK 주제에서 생성된 구체화된 뷰에서 지원되지 않습니다. 스트림 또는 주제에서 구체화된 뷰를 생성한 후 스트리밍 구체화된 뷰를 다른 구체화된 뷰, 테이블 또는 뷰에 조인하기 위해 다른 구체화된 뷰를 만들 수 있습니다. 자세한 내용은 구체화된 보기 새로 고침 섹션을 참조하세요.
레코드 구문 분석	Amazon Redshift 스트리밍 수집은 KPL 주요 개념 - 집계에 의해 집계된 레코드 구문 분석을 지원하지 않습니다. 집계된 레코드는 수집되지만 이진 프로토콜 버퍼 데이터로 저장됩니다. (자세한 내용은 프로토콜 버퍼를 참조하세요.) 데이터를 Kinesis로 푸시하는 방법에 따라 이 기능을 꺼야 할 수 있습니다.
압축 해제	VARBYTE는 현재 어떤 압축 해제 방법도 지원하지 않습니다. 이로 인해 압축 데이터가 포함된 레코드는 Redshift 내에서 쿼리할 수 없습니다. 데이터를 Kinesis 스트림 또는 Amazon MSK 주제로 푸시하기 전에 압축을 풉니다.
최대 레코드 크기	Amazon Redshift가 Kinesis 또는 Amazon MSK에서 수집할 수 있는 레코드 필드의 최대 크기는 1MB보다 약간 작습니다. 동작에 대한 자세한 내용은 다음과 같습니다. 최대 VARBYTE 길이 - 스트리밍 수집의 경우 VARBYTE 유형은 최대 1,024,000바이트 길이의 데이터를 지원합니다. Kinesis는 페이로드를 1MB로 제한합니다. 메시지 제한 - 기본 Amazon MSK 구성은 메시지를 1MB로 제한합니다. 또한 메시지에 헤더가 포함된 경우 데이터 양은 1,048,470바이트로 제한됩니다. 기본 설정을 사용하면 수집에 문제가 없습니다. 그러나 Kafka 및 Amazon MSK의 최대 메시지 크기를 더 큰 값으로 변경할 수 있습니다. 이 경우 Kafka 레코드의 키/값 필드 또는 헤더가 크기 제한을 초과할 수 있습니다. 이러한 레코드는 오류를 유발할 수 있으며 수집되지 않습니다. 참고 Amazon Redshift는 Kinesis 또는 Amazon MSK로부터의 스트리밍 수집에 대해 최대 크기 1,024,000바이트를 지원합니다. 하지만 Amazon Redshift는 VARBYTE 데이터 유형에 대해 최대 크기 16MB를 지원합니다.
오류 레코드	데이터 크기가 최대 크기를 초과하여 레코드를 Redshift로 수집할 수 없는 경우 해당 레코드를 건너뜁니다. 이 경우에도 구체화된 뷰 새로 고침은 여전히 성공하며 각 오류 레코드의 세그먼트가 SYS_STREAM_SCAN_ERRORS 시스템 테이블에 기록됩니다. 계산 오류 또는 형식 변환 오류와 같은 비즈니스 논리에서 발생하는 오류는 건너뛰지 않습니다. 이러한 문제를 방지하려면 구체화된 뷰 정의에 논리를 추가하기 전에 논리를 주의 깊게 테스트하세요.
Amazon MSK 다중 VPC 프라이빗 연결	Amazon MSK 다중 VPC 프라이빗 연결은 현재 Redshift 스트리밍 수집에 지원되지 않습니다. 그 대신 VPC 피어링을 사용하여 VPC를 연결하거나 AWS Transit Gateway를 사용하여 중앙 허브를 통해 VPC와 온프레미스 네트워크를 연결할 수 있습니다. 둘 중 하나를 사용하면 Redshift가 Amazon MSK 클러스터와 통신하거나 다른 VPC의 Amazon MSK Serverless와 통신할 수 있습니다.