생성 데이터 인텔리전스

빅 데이터

Amazon Kinesis Data Streams, Amazon MSK 및 Amazon Redshift 스트리밍 수집을 사용한 비 JSON 수집 | 아마존 웹 서비스

플라톤에 의해 재발행
플라톤에 의해 재발행

시간

조회 수 : 101

조직은 오늘날의 데이터 중심 환경에서 끊임없이 확장되는 데이터 형식의 스펙트럼과 씨름하고 있습니다. Avro의 바이너리 직렬화부터 Protobuf의 효율적이고 컴팩트한 구조까지, 데이터 형식의 환경은 CSV 및 JSON의 기존 영역을 훨씬 뛰어넘어 확장되었습니다. 조직이 이러한 다양한 데이터 스트림에서 통찰력을 얻으려고 노력할 때 이를 확장 가능한 솔루션에 원활하게 통합하는 것이 과제입니다.

이번 포스팅에서는 Amazon Redshift 스트리밍 수집 JSON이 아닌 데이터 형식을 수집, 처리, 분석합니다. Amazon Redshift 스트리밍 수집을 사용하면 다음에 연결할 수 있습니다. Amazon Kinesis 데이터 스트림 및 Apache Kafka 용 Amazon Managed Streaming (Amazon MSK) 구체화된 뷰를 통해 실시간으로 데이터 준비와 관련된 복잡성 없이 직접 아마존 단순 스토리지 서비스 (Amazon S3)을 클러스터에 로드합니다. 이러한 구체화된 뷰는 데이터 스트리밍을 위한 시작 영역을 제공할 뿐만 아니라 향상된 처리를 위해 SQL 변환을 통합하고 ELT(추출, 로드 및 변환) 파이프라인에 혼합하는 유연성도 제공합니다. 스트리밍 수집 구성 및 사용에 대한 자세한 내용은 아마존 레드 시프트, 인용하다 Amazon Redshift 스트리밍 수집을 통한 실시간 분석.

Amazon Redshift의 JSON 데이터

Amazon Redshift는 SUPER 데이터 유형, PartiQL 언어, 구체화된 보기 및 데이터 레이크 쿼리를 통해 JSON 데이터에 대한 저장, 처리 및 분석을 지원합니다. Amazon Redshift의 스트리밍 데이터에 액세스하기 위한 기본 구성은 소스 스트림의 메타데이터(스트림 타임스탬프, 시퀀스 번호, 새로 고침 타임스탬프 등과 같은 속성)와 스트림 자체의 원시 이진 데이터를 제공합니다. JSON 형식으로 인코딩된 원시 바이너리 데이터가 포함된 스트림의 경우 Amazon Redshift는 데이터 구문 분석 및 관리를 위한 다양한 도구를 제공합니다. 각 스트림 형식의 메타데이터에 대한 자세한 내용은 다음을 참조하세요. Amazon Kinesis Data Streams에서 스트리밍 수집 시작하기 및 Amazon Managed Streaming for Apache Kafka에서 스트리밍 수집 시작하기.

가장 기본적인 수준에서 Amazon Redshift를 사용하면 원시 데이터를 개별 열로 구문 분석할 수 있습니다. 그만큼 JSON_EXTRACT_PATH_TEXT 및 JSON_EXTRACT_ARRAY_ELEMENT_TEXT 함수를 사용하면 JSON 개체 및 배열에서 특정 세부 정보를 추출하여 분석을 위해 별도의 열로 변환할 수 있습니다. JSON 문서의 구조와 특정 보고 요구 사항이 정의되면 이러한 방법을 사용하면 분석을 위한 향상된 압축 및 정렬을 통해 보고에 필요한 정확한 구조로 구체화된 뷰를 사전 계산할 수 있습니다.

이 접근 방식 외에도 Amazon Redshift JSON 함수를 사용하면 적응형 SUPER 데이터 유형을 사용하여 원래 상태로 JSON 데이터를 저장하고 분석할 수 있습니다. 함수 JSON_PARSE 스트림에서 이진 데이터를 추출하여 SUPER 데이터 유형으로 변환할 수 있습니다. SUPER 데이터 유형과 PartiQL 언어를 통해 Amazon Redshift는 반구조화된 데이터 분석 기능을 확장합니다. JSON 데이터 저장소에 SUPER 데이터 유형을 사용하여 열 내에서 스키마 유연성을 제공합니다. SUPER 데이터 유형 사용에 대한 자세한 내용은 다음을 참조하세요. Amazon Redshift에서 반구조화된 데이터 수집 및 쿼리. 이 동적 기능은 반구조화된 데이터의 데이터 수집, 저장, 변환 및 분석을 단순화하여 Redshift 환경 내의 다양한 소스로부터 풍부한 통찰력을 제공합니다.

스트리밍 데이터 형식

대체 직렬화 형식을 사용하는 조직은 다양한 역직렬화 방법을 모색해야 합니다. 다음 섹션에서는 역직렬화를 위한 최적의 접근 방식을 살펴보겠습니다. 이 섹션에서는 조직이 데이터를 효과적으로 관리하기 위해 사용하는 다양한 형식과 전략을 자세히 살펴봅니다. 이러한 이해는 Amazon Redshift의 데이터 구문 분석 접근 방식을 결정하는 데 핵심입니다.

많은 조직에서는 스트리밍 사용 사례에 JSON 이외의 형식을 사용합니다. JSON은 데이터의 스키마가 실제 데이터 자체와 함께 저장되는 자체 설명형 직렬화 형식입니다. 이는 JSON을 애플리케이션에 유연하게 만들어 주지만, 이 접근 방식은 JSON 키와 구문에 포함된 추가 데이터로 인해 애플리케이션 간의 데이터 전송이 증가할 수 있습니다. 직렬화 및 역직렬화 성능과 애플리케이션 간 네트워크 통신을 최적화하려는 조직은 다음과 같은 형식을 사용하도록 선택할 수 있습니다. 아 브로, 프로토부프또는 최적화된 방식으로 애플리케이션 데이터를 바이너리 형식으로 직렬화하는 사용자 정의 독점 형식도 있습니다. 이는 메시지 값만 이진 메시지로 압축되는 효율적인 직렬화의 이점을 제공합니다. 그러나 이를 위해서는 데이터 소비자가 메시지를 역직렬화하기 위해 데이터를 직렬화하는 데 사용된 스키마와 프로토콜을 알아야 합니다. 다음 그림에 설명된 것처럼 조직에서 이 문제를 해결할 수 있는 여러 가지 방법이 있습니다.

다양한 바이너리 메시지 직렬화 접근 방식의 시각화

임베디드 스키마

임베디드 스키마 접근 방식에서는 데이터 형식 자체에 실제 데이터와 함께 스키마 정보가 포함됩니다. 즉, 메시지가 직렬화되면 스키마 정의와 데이터 값이 모두 포함됩니다. 이를 통해 메시지를 받는 사람은 누구나 스키마 정보에 대한 외부 소스를 참조할 필요 없이 메시지의 구조를 직접 해석하고 이해할 수 있습니다. JSON, MessagePack, YAML과 같은 형식은 포함된 스키마 형식의 예입니다. 이 형식의 메시지를 받으면 추가 단계 없이 즉시 메시지를 구문 분석하고 데이터에 액세스할 수 있습니다.

가정된 스키마

가정된 스키마 접근 방식에서 메시지 직렬화에는 데이터 값만 포함되며 스키마 정보는 포함되지 않습니다. 데이터를 올바르게 해석하려면 수신 애플리케이션이 메시지를 직렬화하는 데 사용된 스키마에 대한 사전 지식이 있어야 합니다. 이는 일반적으로 스키마를 스트림 이름과 같은 일부 식별자 또는 컨텍스트와 연결하여 수행됩니다. 수신 애플리케이션은 메시지를 읽을 때 이 컨텍스트를 사용하여 해당 스키마를 검색한 다음 그에 따라 이진 데이터를 디코딩합니다. 이 접근 방식에는 컨텍스트를 기반으로 한 추가 스키마 검색 및 디코딩 단계가 필요합니다. 이를 위해서는 일반적으로 소비자가 스트림 메타데이터(예: AWS Glue 스키마 레지스트리).

이 접근 방식의 한 가지 단점은 스키마 버전을 추적하는 것입니다. 소비자는 스트림 이름에서 관련 스키마를 식별할 수 있지만 사용된 스키마의 특정 버전은 식별할 수 없습니다. 생산자는 다른 스키마 버전을 사용할 때 소비자가 중단되지 않도록 스키마를 이전 버전과 호환되도록 변경해야 합니다.

내장된 스키마 ID

이 경우 생산자는 가정된 스키마 접근 방식과 유사하게 데이터를 이진 형식(예: Avro 또는 Protobuf)으로 계속 직렬화합니다. 그러나 추가 단계가 포함됩니다. 즉, 생산자가 메시지 헤더 시작 부분에 스키마 ID를 추가합니다. 소비자가 메시지를 처리할 때 헤더에서 스키마 ID를 추출하는 것부터 시작됩니다. 이 스키마 ID를 사용하여 소비자는 레지스트리에서 해당 스키마를 가져옵니다. 검색된 스키마를 사용하여 소비자는 메시지의 나머지 부분을 효과적으로 구문 분석할 수 있습니다. 예를 들어, AWS Glue 스키마 레지스트리는 다음을 제공합니다. Java SDK SerDe 라이브러리, 내장된 스키마 ID를 사용하여 스트림의 메시지를 기본적으로 직렬화 및 역직렬화할 수 있습니다. 인용하다 스키마 레지스트리 작동 방식 레지스트리 사용에 대한 자세한 내용은

외부 스키마 레지스트리의 사용은 소비자와 개발자에게 많은 이점을 제공하므로 스트리밍 애플리케이션에서 일반적입니다. 이 레지스트리에는 애플리케이션에 대한 모든 메시지 스키마가 포함되어 있으며 이를 고유 식별자와 연결하여 스키마 검색을 용이하게 합니다. 또한 레지스트리는 애플리케이션 개발을 용이하게 하기 위해 스키마 버전 변경 처리 및 문서화와 같은 다른 기능을 제공할 수도 있습니다.

메시지 페이로드에 포함된 스키마 ID에는 버전 정보가 포함될 수 있으므로 게시자와 소비자가 항상 동일한 스키마 버전을 사용하여 데이터를 관리할 수 있습니다. 스키마 버전 정보를 사용할 수 없는 경우 스키마 레지스트리는 소비자에게 문제가 발생하지 않도록 생산자가 이전 버전과 호환되는 변경을 수행하도록 하는 데 도움이 될 수 있습니다. 이는 생산자와 소비자를 분리하는 데 도움이 되고 게시자와 소비자 단계 모두에서 스키마 유효성 검사를 제공하며 다양한 애플리케이션 요구 사항을 허용하기 위해 스트림 사용에 더 많은 유연성을 허용합니다. 메시지는 스트림당 하나의 스키마로 게시되거나 단일 스트림 내의 여러 스키마로 게시될 수 있으므로 소비자는 메시지가 도착할 때 동적으로 해석할 수 있습니다.

스키마 레지스트리의 이점에 대해 자세히 알아보려면 다음을 참조하세요. 교차 계정 AWS Glue Schema Registry의 스키마를 사용하여 Amazon MSK를 통한 스트리밍 데이터 검증.

파일의 스키마

일괄 처리 사용 사례의 경우 애플리케이션은 데이터 소비를 용이하게 하기 위해 데이터를 데이터 파일 자체에 직렬화하는 데 사용되는 스키마를 포함할 수 있습니다. 이는 포함된 스키마 접근 방식의 확장이지만 일반적으로 데이터 파일이 더 크기 때문에 비용이 적게 듭니다. 따라서 스키마는 전체 데이터에서 비례적으로 더 적은 양을 차지합니다. 이 경우 별도의 로직 없이 소비자가 직접 데이터를 처리할 수 있다. Amazon Redshift는 COPY 명령을 사용하여 이러한 방식으로 직렬화된 Avro 데이터 로드를 지원합니다.

JSON이 아닌 데이터를 JSON으로 변환

JSON이 아닌 직렬화 형식을 사용하려는 조직은 Amazon Redshift 외부에서 메시지를 구문 분석하기 위한 외부 방법을 개발해야 합니다. 우리는 AWS 람다- 기반 외부 사용자 정의 함수(UDF) 이 과정을 위해. 외부 Lambda UDF를 사용하면 조직은 임의의 역직렬화 논리를 정의하여 내장된 스키마, 가정된 스키마, 내장된 스키마 ID 접근 방식을 포함한 모든 메시지 형식을 지원할 수 있습니다. Amazon Redshift는 일부 사용 사례에 대해 실행 가능한 대안이 될 수 있는 Python UDF 정의를 기본적으로 지원하지만, 이 게시물에서는 더 복잡한 시나리오를 다루기 위해 Lambda UDF 접근 방식을 보여줍니다. Amazon Redshift UDF의 예는 다음을 참조하십시오. GitHub의 AWS 샘플.

이 솔루션의 기본 아키텍처는 다음과 같습니다.

다음 코드를 참조하십시오.

-- Step 1
CREATE OR REPLACE EXTERNAL FUNCTION fn_lambda_decode_avro_binary(varchar)
RETURNS varchar IMMUTABLE LAMBDA 'redshift-avro-udf'; -- Step 2
CREATE EXTERNAL SCHEMA kds FROM KINESIS -- Step 3
CREATE MATERIALIZED VIEW {name} AUTO REFRESH YES AS
SELECT -- Step 4 t.kinesis_data AS binary_avro, to_hex(binary_avro) AS hex_avro, -- Step 5 fn_lambda_decode_avro_binary('{stream-name}', hex_avro) AS json_string, -- Step 6 JSON_PARSE(json_string) AS super_data, t.sequence_number, t.refresh_time, t.approximate_arrival_timestamp, t.shard_id
FROM kds.{stream_name} AS t

각 단계를 더 자세히 살펴보겠습니다.

Lambda UDF 생성

전반적인 목표는 원시 데이터를 입력으로 받아들이고 JSON으로 인코딩된 데이터를 출력으로 생성할 수 있는 방법을 개발하는 것입니다. 이는 JSON을 기본적으로 SUPER 데이터 유형으로 처리하는 Amazon Redshift 기능과 일치합니다. 함수의 세부 사항은 직렬화 및 스트리밍 접근 방식에 따라 다릅니다. 예를 들어 Avro 형식의 가정된 스키마 접근 방식을 사용하면 Lambda 함수가 다음 단계를 완료할 수 있습니다.

  1. 스트림 이름과 XNUMX진수로 인코딩된 데이터를 입력으로 사용합니다.
  2. 지정된 스트림 이름에 대한 스키마를 식별하기 위해 스트림 이름을 사용하여 조회를 수행합니다.
  3. XNUMX진수 데이터를 XNUMX진수 형식으로 디코딩합니다.
  4. 스키마를 사용하여 이진 데이터를 읽을 수 있는 형식으로 역직렬화합니다.
  5. 데이터를 JSON 형식으로 다시 직렬화합니다.

f_glue_schema_registry_avro_to_json AWS 샘플 예에서는 스트림 이름별로 Avro 스키마를 검색하고 사용하기 위해 Lambda UDF의 AWS Glue 스키마 레지스트리를 사용하는 가정된 스키마 접근 방식을 사용하여 Avro를 디코딩하는 프로세스를 보여줍니다. 다른 접근 방식(예: 내장된 스키마 ID)의 경우 직렬화 프로세스 및 스키마 레지스트리 구현에 정의된 대로 역직렬화를 처리하도록 Lambda 함수를 작성해야 합니다. 애플리케이션이 메시지 스키마를 처리하기 위해 외부 스키마 레지스트리 또는 테이블 조회에 의존하는 경우 외부 시스템의 로드를 줄이고 평균 Lambda 함수 호출 기간을 줄이는 데 도움이 되도록 스키마 조회에 대한 캐싱을 구현하는 것이 좋습니다.

Lambda 함수를 생성할 때 Amazon Redshift 입력 이벤트 형식을 수용하고 예상되는 Amazon Redshift 이벤트 출력 형식을 준수하는지 확인하십시오. 자세한 내용은 다음을 참조하세요. 스칼라 Lambda UDF 생성.

Lambda 함수를 생성하고 테스트한 후 Amazon Redshift에서 UDF로 정의할 수 있습니다. Amazon Redshift 내에서 효과적인 통합을 위해 이 Lambda 함수 UDF를 IMMUTABLE로 지정합니다. 이 분류는 증분 구체화된 뷰 업데이트를 지원합니다. 이는 Lambda 함수를 멱등성으로 처리하고 솔루션에 대한 Lambda 함수 비용을 최소화합니다. 메시지가 이전에 처리된 경우에는 처리할 필요가 없기 때문입니다.

기준 Kinesis 데이터 스트림 구성

메시징 형식이나 접근 방식(내장 스키마, 가정된 스키마, 내장 스키마 ID)에 관계없이 메시징 소스에서 Amazon Redshift로 스트리밍 수집을 위한 외부 스키마 설정부터 시작합니다. 자세한 내용은 다음을 참조하세요. 스트리밍 수집.

CREATE EXTERNAL SCHEMA kds FROM KINESIS IAM_ROLE 'arn:aws:iam::0123456789:role/redshift-streaming-role';

원시 구체화된 뷰 생성

다음으로 원시 구체화된 뷰를 정의합니다. 이 보기에는 Amazon Redshift VARBYTE 형식의 스트리밍 소스에서 가져온 원시 메시지 데이터가 포함되어 있습니다.

VARBYTE 데이터를 VARCHAR 형식으로 변환

외부 Lambda 함수 UDF는 VARBYTE를 입력 데이터 유형으로 지원하지 않습니다. 따라서 스트림의 원시 VARBYTE 데이터를 VARCHAR 형식으로 변환하여 Lambda 함수에 전달해야 합니다. Amazon Redshift에서 이를 수행하는 가장 좋은 방법은 TO_HEX 내장 방법. 그러면 이진 데이터가 XNUMX진수로 인코딩된 문자 데이터로 변환되어 Lambda UDF로 전송될 수 있습니다.

Lambda 함수를 호출하여 JSON 데이터 검색

UDF가 정의된 후 UDF를 호출하여 XNUMX진수로 인코딩된 데이터를 JSON으로 인코딩된 VARCHAR 데이터로 변환할 수 있습니다.

JSON_PARSE 메서드를 사용하여 JSON 데이터를 SUPER 데이터 유형으로 변환합니다.

마지막으로 다음과 같은 Amazon Redshift 기본 JSON 구문 분석 방법을 사용할 수 있습니다. JSON_PARSE, JSON_EXTRACT_PATH_TEXT, 그리고 JSON 데이터를 분석에 사용할 수 있는 형식으로 구문 분석하는 등의 작업을 수행합니다.

고려

이 전략을 사용할 때는 다음 사항을 고려하세요.

  • 비용 – Amazon Redshift는 확장성을 향상하고 전체 Lambda 호출 수를 줄이기 위해 Lambda 함수를 일괄 호출합니다. 이 솔루션의 비용은 스트림의 메시지 수, 새로 고침 빈도, Amazon Redshift에서 일괄 메시지를 처리하는 데 필요한 호출 시간에 따라 달라집니다. Amazon Redshift에서 IMMUTABLE UDF 유형을 사용하면 구체화된 보기에 대한 증분 새로 고침 전략을 활용하여 비용을 최소화하는 데 도움이 될 수도 있습니다.
  • 권한 및 네트워크 액세스 - AWS 자격 증명 및 액세스 관리 Amazon Redshift UDF에 사용되는 (IAM) 역할에는 Lambda 함수를 호출할 수 있는 권한이 있어야 하며 외부 종속성을 호출할 수 있는 액세스 권한이 있도록 Lambda 함수를 배포해야 합니다. 스키마 레지스트리와 같은 개인 리소스에 액세스)
  • 모니터링 – Lambda 함수 로깅 및 지표를 사용하여 역직렬화, 스키마 레지스트리 연결 및 데이터 처리 오류를 식별합니다. UDF Lambda 함수 모니터링에 대한 자세한 내용은 다음을 참조하세요. 로그에 측정항목 포함 및 Lambda 함수 모니터링 및 문제 해결.

결론

이 게시물에서는 스트리밍 사용 사례에 대한 다양한 데이터 형식과 수집 방법을 살펴보았습니다. JSON이 아닌 데이터 형식을 처리하기 위한 전략을 탐색함으로써 구체화된 뷰를 사용하여 거의 실시간으로 이러한 형식을 원활하게 수집, 처리 및 분석하는 Amazon Redshift 스트리밍의 사용을 조사했습니다.

또한 스트림별 스키마, 포함된 스키마, 가정된 스키마 및 포함된 스키마 ID 접근 방식을 탐색하여 이들의 장점과 고려 사항을 강조했습니다. JSON이 아닌 형식과 Amazon Redshift 간의 격차를 해소하기 위해 데이터 구문 분석 및 변환을 위한 Lambda UDF 생성을 살펴보았습니다. 이 접근 방식은 후속 분석을 위해 다양한 데이터 스트림을 Amazon Redshift에 통합하는 포괄적인 수단을 제공합니다.

끊임없이 진화하는 데이터 형식 및 분석 환경을 탐색할 때 이 탐색이 데이터 스트림에서 의미 있는 통찰력을 도출하는 데 귀중한 지침이 되기를 바랍니다. 의견 섹션에 어떤 생각이나 질문이라도 환영합니다.

저자에 관하여

M 메르텐스 소프트웨어 엔지니어, 설계자 및 데이터 엔지니어로 일하면서 경력 전반에 걸쳐 분산 시스템 엔지니어링 분야에서 일해 왔습니다. 과거에 M은 짧은 대기 시간으로 테라바이트 규모의 스트리밍 데이터를 처리하고, 엔터프라이즈 기계 학습 파이프라인을 실행하고, 다양한 데이터 도구 세트 및 소프트웨어 스택을 사용하여 팀 간에 데이터를 원활하게 공유하는 시스템을 구축하는 시스템을 지원 및 구축했습니다. AWS에서 그들은 미국 연방 금융 고객을 지원하는 수석 솔루션 설계자입니다.

신두 아추탄 AWS Federal Financials의 수석 솔루션 아키텍트입니다. 그녀는 고객과 협력하여 AWS Glue, Amazon EMR, Amazon Kinesis 및 기타 서비스를 사용하는 분석 솔루션에 대한 아키텍처 지침을 제공합니다. 직장 밖에서 그녀는 DIY, 장거리 트레일 여행, 요가를 좋아합니다.

spot_img

최신 인텔리전스

spot_img

저작권 @ 2023 Plato Technologies Inc.