구체화된 뷰로 스트리밍 모으기 - Amazon Redshift
스트리밍 서비스에서 Redshift로 데이터가 이동하는 방법성능 향상을 위한 데이터 구문 분석 모범 사례스트리밍 모으기 동작 및 데이터 유형

구체화된 뷰로 스트리밍 모으기

이 주제에서는 스트리밍 데이터에 빠르게 액세스하기 위해 구체화된 뷰를 사용하는 방법을 설명합니다.

스트리밍 모으기를 사용하면 지연 시간이 짧고 빠른 속도로 Amazon Kinesis Data Streams 또는 Amazon Managed Streaming for Apache Kafka에서 Amazon Redshift 프로비저닝된 또는 Redshift Serverless 데이터베이스로 스트림 데이터를 모을 수 있습니다. 데이터는 용도에 맞게 구성된 Redshift 구체화된 뷰에 배치됩니다. 따라서 외부 데이터에 빠르게 액세스할 수 있습니다. 스트리밍 모으기는 데이터 액세스 시간을 단축하고 스토리지 비용을 절감합니다. 소수의 SQL 명령 모음을 사용하여 Amazon Redshift 클러스터 또는 Amazon Redshift Serverless 작업 그룹에 대해 구성할 수 있습니다. 그런 다음 매번 구체화된 뷰 새로 고침을 사용하여 초당 수백 메가바이트의 데이터를 모을 수 있습니다.

스트리밍 서비스에서 Redshift로 데이터가 이동하는 방법

스트리밍 모으기의 작동 방식과 프로세스에서 사용되는 데이터베이스 객체를 이해하는 데 도움이 됩니다. 데이터는 데이터 스트림 제공업체에서 Amazon Redshift 프로비저닝된 클러스터 또는 Amazon Redshift Serverless 작업 그룹으로 직접 이동합니다. Amazon S3 버킷과 같은 임시 랜딩 영역이 없습니다. 프로비저닝된 클러스터 또는 작업 그룹은 스트림 소비자입니다. Redshift 데이터베이스에서는 스트림에서 읽은 데이터가 구체화된 뷰에 표시됩니다. 데이터는 도착하는 대로 처리됩니다. 예를 들어 SQL을 통해 JSON 값을 사용하고 구체화된 뷰의 데이터 열에 매핑할 수 있습니다. 구체화된 뷰가 새로 고쳐지면 Redshift는 뷰가 스트림과 함께 최신 상태로 유지될 때까지 할당된 Kinesis 데이터 샤드 또는 Kafka 파티션의 데이터를 사용합니다.

Amazon Redshift 스트리밍 모으기의 사용 사례에는 지속적으로 생성되고 시작 시점에서 짧은 기간(지연 시간) 내에 처리되어야 하는 데이터가 포함됩니다. 이를 실시간에 가까운 분석이라고 합니다. 소스에는 IT 디바이스, 시스템 텔레메트리 디바이스 및 사용량이 많은 웹 사이트 또는 애플리케이션의 클릭 스트림 데이터가 포함될 수 있습니다.

성능 향상을 위한 데이터 구문 분석 모범 사례

스트리밍 모으기를 구성할 때 들어오는 데이터를 구문 분석하는 여러 가지 방법이 있습니다. 관행에는 데이터가 도착할 때 비즈니스 로직을 수행하거나 형식을 지정하는 것이 포함될 수 있습니다. 오류 또는 데이터 손실을 방지하기 위해 다음과 같은 모범 사례를 따르는 것이 좋습니다. 이는 내부 테스트를 통해 도출되었으며 고객이 구성 및 구문 분석 문제를 해결하는 데 도움이 됩니다.

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

    사용 사례에서 하나의 KDS 스트림 또는 MSK 주제의 데이터를 여러 구체화된 뷰에 모아야 하는 경우 그렇게 하기 전에 AWS 빅 데이터 블로그, 특히 Amazon MSK에서 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에서 수집할 수 있는 레코드의 최대 크기는 16,777,216바이트(16MiB)이며, 이는 Amazon Redshift의 VARBYTE 데이터 유형에서 지원하는 최대 크기입니다. 기본적으로 Kinesis 데이터 스트림 또는 Amazon MSK 주제에서 생성된 Amazon Redshift 스트리밍 구체화된 뷰는 데이터 열의 크기를 각각 1,048,576바이트(1MiB) 및 16,777,216바이트(16MiB)로 설정합니다.

참고

1MiB는 Kinesis 데이터 스트림에 배치할 수 있는 현재 레코드의 최대 크기입니다. Kinesis 크기 제한에 관한 자세한 내용은 Amazon Kinesis Data Streams 개발자 안내서의 할당량 및 제한을 참조하시기 바랍니다.
오류 레코드

데이터 크기가 최대값을 초과하여 레코드를 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와 통신할 수 있습니다.
자동 새로 고침 사용량 및 활성화

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

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

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