[AWS Data Engineering] 6장. 배치 및 스트리밍 데이터 수집
데이터 아키텍처의 다양한 구성 요소에 대해 알아보도록 하겠습니다. 이 장에서는 여러 유형의 데이터 소스를 살펴보고 데이터를 수집하기 위해 AWS 내에서 사용할 수 있는 다양한 도구를 살펴봅니다. 또한 여러 수집 도구 중에서 작업에 적합한 도구를 사용하고 있는지 확인하기 위해 결정하는 방법을 살펴보도록 하겠습니다.
데이터 엔지니어가 직면하는 데이터의 5V 과제는 다음과 같습니다.
Variety : 다양성
Volume : 데이터의 양
Velocity : 데이터의 속도
Validity : 데이터의 진실성
Value : 데이터의 가치
1. 데이터 소스 이해
1) 데이터 다양성 (Variety)
모든 데이터가 단순히 데이터 베이스의 관계형 데이터라면 데이터 분석 솔루션으로 옮기는 것은 비교적 쉬웠을 것입니다. 하지만 오늘날 조직은 다른 많은 유형의 데이터(웹 서버 로그 파일, 사진, 비디오 및 기타 미디어, 지리적 위치 데이터, 센서 및 기타 IoT 데이터 등)를 분석하기 때문에 가치와 경쟁 우위를 가집니다.
데이터 엔지니어는 파이프 라인의 각 데이터 원본에 대해서 수집할 데이터 유형을 결정해야 합니다.
#구조화된 데이터
데이터 모델에 따라 구성된 데이터이며 일련의 행과 열로 표시 됩니다. 각 행은 레코드를 나타내며 열은 각 레코드의 필드를 구성합니다. 구조화된 데이터 파일의 각 열에는 특정 유형의 데이터가 들어 있으며, 모든 행에는 동일한 수의 열과 유형의 열이 있습니다. 각 레코드에 포함되는 열의 정의와 각 열에 대한 데이터 유형을 데이터 스키마라고 합니다.
- 관계형 데이터 베이스 관리 시스템(RDBMS) : MySQL, PostgreSQL, SQL Server, Oracle
- CSV(쉼표로 구분된 값) 파일 또는 TSV(탭으로 구분된 값) 파일과 같은 구분 파일
- xls 형식의 Microsoft excel과 같은 스프레드시트
- 온라인 양식의 데이터
구조화된 데이터는 Amazon S3 기반 데이터 레이크를 포함한 분석 시스템과 Amazon Redshift 데이터 웨어하우스와 같은 데이터 마트에 쉽게 수집될 수 있습니다.
#반구조화된 데이터
구조화된 데이터와 동일한 속성을 많이 공유하지만 구조 또는 스키마를 엄격하게 정의할 필요는 없습니다. 일반 적으로 반구조화된 데이터에는 데이터 요소를 식별하는 내부 태그가 포함되지만 각 레코드에는 서로 다른 요소나 필드가 포함될 수 있습니다.
구조화되지 않는 데이터의 데이터 유형 중 일부는 정수 값과 같은 강력한 유형일 수 있고, 다른 요소는 자유 형식 텍스트와 같은 항목을 포함할 수 있습니다. 일반적인 반구조적 형식에는 JSON 및 XML 파일 형식이 포함됩니다.
csv와 같은 구조화된 데이터 유형에서 동일한 정보를 캡처하는 것은 훨씬 더 복잡합니다. 예를 들어 레코드마다 범주 수가 다르거나 일부 레코드에 추가 속성이 있는 시나리오에는 적합하지 않습니다. JSON은 계층적 형식(데이터를 중첩할 수 있는 형식)으로 구성되어 있기 때문에 상당한 유연성을 제공합니다.
JSON과 같은 반구조화된 형식으로 데이터를 저장하는 것은 웹 및 모바일 애플리케이션뿐만 아니라 IoT 데이터 작업과 같은 다양한 사용 사례에 일반적으로 사용됩니다.
#구조화되지 않은 데이터
비정형 데이터는 데이터가 미리 정의된 구조 또는 스키마를 가지지 않는 다양한 유형의 데이터를 포함합니다. 자유형식 데이터(PDF 또는 워드 프로세싱 파일 또는 이메일)에서 미디어 파일(사진, 비디오, 위성 이미지 또는 오디오 파일)에 이르기까지 다양합니다.
일부 비정형 데이터는 전문화된 도구를 사용하지 않는 한 일반적으로 매우 효율적이지는 않지만 직접 분석할 수 있습니다. 예를 들어 기존 데이터 베이스에서 대량의 자유 형식 텍스트로 검색하는 목적으로 사용할 수 있는 특수도구(Amazon ElasticSearch)가 있습니다.
그러나 일부 유형의 비정형 데이터 예를들어, 이미지 또는 비디오 파일을 데이터 분석 도구로 직접 분석할 수 없습니다. 이는 분석 프로젝트에서 이러한 유형의 파일을 사용할 수 없음을 의미하는 것이 아니라 분석에 유용하게 사용하려면 추가 처리가 필요합니다.
오늘날 생성되는 데이터의 대부분은 비정형 데이터로 간주됩니다. 예를 들어 이미지 인식도구를 사용하여 분석에 사용할 수 있는 이미지 또는 비디오 파일에서 메타데이터를 추출할 수 있습니다. 또는 자연어처리도구를 사용하여 웹사이트의 자유형식 텍스트 리뷰를 분석하여 다양한 제품에 대한고객 감정을 파악할 수 있습니다.
2) 데이터 볼륨 (Volume)
데이터 소스에 대해 이해해야 하는 데이터 속성은 볼륨과 관련이 있습니다. 이를 위해서는 수집해야 하는 기존 데이터의 총 크기와 일/월/년 단위로 증가하는 데이터를 모두 파악해야 합니다.
과거 데이터와 미래 데이터의 양을 파악하면 사용 사례에 맞는 AWS서비스의 초기 크기를 조정하는 데 도움이 되며 관련 비용에 대한 예산을 더 잘 책정할 수 있습니다.
3) 데이터 속도 (Velocity)
데이터 속도는 소스 시스템에서 대상시스템으로 새 데이터를 수집하고 처리할 것으로 예상되는 속도입니다.
수집을 위해 데이터는 하루에 한 번 또는 하루에 몇 번 배치 일정에 로드될 수 있는 한편, 소스에서 대상으로 지속적으로 스트리밍 될 수 있습니다.
소스 데이터가 일정에 따라 또는 실시간 스트리밍 데이터를 통해 얼마나 빨리 생성되는지, 들어오는 데이터를 얼마나 빨리 처리해야 하는지 잘 파악해야 합니다.
데이터 속도는 데이터를 수집하는 방법과 데이터를 처리하는 방법에 모두 영향을 미칩니다.
4) 데이터 진실성 (Validity)
데이터의 진실성은 데이터의 품질, 완정성 및 정확성과 같은 수집 중인 데이터의 다양한 측면을 고려합니다.
우리가 수집하는 데이터는 다양한 출처에서 나올 수 있으며 데이터 생성방법에 따라 데이터가 불완전하거나 일관성이 없을 수 있습니다. 예를 들어 스프레드시트에서 캡처한 데이터에 오류 또는 결측 값이 포함되어 있을 수 있습니다.
데이터를 처리할 때 이러한 항목을 고려할 수 있도록 수집하는 데이터의 진실성을 알고 있어야 합니다. 예를 들어, 일부 도구는 누락된 데이터를 평균으로 다시 채우는 데 도움이 될 수 있을 뿐만 아니라 유효하지 않은 데이터가 포함된 필드를 검색하고 수정하는 데 도움이 되는 도구를 제공할 수 있습니다.
5) 데이터 가치 (Value)
궁극적으로 수집되고 처리되는 모든 데이터는 비즈니스에 새로운 통찰력과 가치를 제공하는 방법을 찾는 단일 목적으로 이루어집니다. 5개의 V 중 가장 중요한 V이며, 데이터 수집 및 처리를 통해 수행하는 작업의 전체적인 상황을 고려할 때 가장 중요하게 생각해야 합니다.
테라바이트 단위의 데이터를 수집하고 여러 가지 방법으로 데이터를 정리하고 처리할 수 있지만 최종 데이터 제품이 비즈니스에 가치를 가져다주지 못하면 시간과 비용을 모두 낭비하게 됩니다
우리는 이 데이터를 수집할 가치가 있는지 확인해야 하며, 이 데이터가 현재 또는 미래에 비즈니스에 어떤 가치를 추가할 수 있는지도 이해해야 합니다.
6) 물어볼 질문
수집하려는 각 데이터 원본의 소유자를 식별한 다음 데이터 원본 소유자와 심층 분석을 수행하고 다음과 같은 질문을 해야 합니다.
- 데이터(관계형 데이터베이스, NoSQL 데이터베이스, JSON 또는 XML과 같은 반구조 데이터, 비정형 데이터 등)의 형식은 무엇입니까?
- 얼마나 많은 과거 데이터를 사용할 수 있습니까?
- 과거 데이터의 전체 크기는 얼마입니까?
- 일/주/월 단위로 얼마나 많은 새 데이터가 생성됩니까?
- 데이터가 현재 어딘가에서 스트리밍 되고 있으며, 그렇다면 데이터 스트림을 활용할 수 있습니까?
- 데이터가 얼마나 자주 업데이트됩니까(지속적으로 업데이트 또는 예약된 기준으로 업데이트)?
- 현재 또는 미래에 비즈니스에 가치를 추가하기 위해 이 데이터 소스를 어떻게 사용할 것인가?
2. 관계형 데이터베이스에서 데이터 수집
분석 프로젝트에서 일반적인 데이터 소스는 관계형 데이터베이스 시스템에서 오는 데이터입니다. 조직에는 종종 사일로화된 데이터베이스를 여러 개 보유하고 있으며 다양한 데이터베이스의 데이터 분석을 위해 중앙위치로 가져오려고 합니다.
이러한 프로젝트에서는 데이터베이스에 이미 존재하는 기록 데이터 수집과 데이터 베이스에서 진행 중인 새 데이터 및 변경된 데이터 동기화가 포함되는 것이 일반적입니다. 데이터베이스 소스에서 수집하는 데 사용할 수 있는 다양한 도구가 있습니다.
데이터 엔지니어는 소스와 대상을 모두 평가하여 어떤 수집 도구가 가장 적합한지 결정해야 합니다.
1) AWS 데이터베이스 마이그레이션 서비스(DMS)
데이터베이스에서 데이터를 수집하는 기본 AWS 서비스는 AWS 데이터베이스 마이그레이션 서비스(DMS)입니다. AWS DMS는 주로 데이터베이스에서 과거 데이터를 일회성으로 수집하거나 관계형 데이터베이스에서 데이터를 지속적으로 복제하기 위한 것입니다.
AWS DMS는 관리형 서비스이지만 서버리스 서비스는 아닙니다. DMS는 하나 이상의 EC2 서버를 복제 인스턴스로 프로비저닝 합니다. 이러한 복제 인스턴스는 원본 데이터베이스에 연결하여 원본에서 데이터를 읽고 대상으로 로드할 데이터를 준비한 다음 대상에 연결하여 데이터를 작성합니다.
2) AWS 글루
AWS 글루는 여러 데이터 소스에 연결할 수 있습니다. 여기에는 JDBC 소스에 대한 연결이 포함되어 글루가 많은 다른 데이터베이스 엔진에 연결할 수 있으며, 이러한 연결을 통해 추가 처리를 위해 데이터를 전송할 수 있습니다.
#하나 이상의 테이블에서 전체 일회성 로드
AWS Glue는 데이터베이스에 JDBC를 연결하고 테이블에서 데이터를 다운로드하도록 구성할 수 있습니다. 글루는 테이블에서 select (*)을 효과적으로 수행하여 테이블 내용을 스파크 서버의 메모리로 읽습니다. 이 시점에서 스파크를 사용하여 Apache Parquet와 같은 최적화된 형식으로 Amazon S3에 데이터를 쓸 수 있습니다.
#테이블에서 초기 전체 로드 및 새 레코드의 후속 로드
AWS 글루는 북마크라는 개념을 가지고 있는데, 이를 통해 글루가 이전에 처리된 데이터를 추적하고 이후 실행 시 새로운 데이터만 처리할 수 있습니다. 글루는 책갈피 키로 사용할 테이블의 열(또는 여러 열)을 식별하도록 하여 이 작업을 수행합니다.
예를 들어, 새 트랜잭션마다 순차적으로 증가하는 트랜잭션 ID 열이 있는 감사 테이블이 있는 경우 북마크 기능을 사용하는 동안 AWS Glue로 데이터를 수집하는 데 적합합니다.
이 프로세스는 테이블에서 업데이트되거나 삭제된 행을 탐지할 수 없으므로 모든 사용 사례에 적합하지는 않습니다. 감사 테이블 또는 이와 유사한 유형의 테이블에서 데이터는 항상 테이블에 추가되지만 기존 행은 업데이트되거나 삭제되지 않습니다.
#AWS Lake Formation으로 AWS Glue 작업 생성
AWS Lake Formation에는 몇 가지 일반적인 섭취 작업을 자동화하는 데 도움이 되는 몇 가지 청사진이 포함되어 있습니다. Lake Formation 콘솔을 몇 번 클릭하면 수집 요구 사항을 구성할 수 있습니다. 구성이 완료되면 Lake Formation은 데이터베이스 원본에서 수집하기 위한 Glue Job, 새로 수집된 데이터를 Glue 데이터 카탈로그에 추가하기 위한 Glue Crawlers 및 여러 구성 요소를 조정하기 위한 Glue Workflow를 생성합니다.
3) 데이터베이스에서 데이터를 수집하는 다른 방법
Amazon EMR은 몇 가지 일반적인 Hadoop 프레임워크 도구를 배포하는 간단한 방법을 제공하며, 이러한 도구 중 일부는 데이터베이스에서 데이터를 수집하는 데 유용합니다
예를 들어 EMR에서 Apache Spark를 실행하고 JDBC 드라이버를 사용하여 관계형 데이터베이스에 연결하여 데이터 레이크에 데이터를 로드할 수 있습니다. 또는 Amazon EMR에서 관계형 데이터베이스 시스템과 Hadoop 간에 데이터를 전송하는 데 널리 사용되는 도구인 Apache Sqoop을 배포할 수 있습니다.
MariaDB, MySQL 또는 Postgre를 실행하는 경우 RDS(Amazon Relational Database Service)의 SQL을 사용하여 데이터베이스 스냅샷을 Amazon S3로 내보낼 수 있습니다. 이는 스냅샷의 모든 테이블을 기록하는 완전관리형 프로세스입니다.
관계형 데이터베이스에서 아마존 S3로 데이터를 이동하는 데 사용할 수 있는 여러 타사 상용 도구도 있습니다. 여기에는 다양한 소스와 타깃 간에 데이터를 이동하기 위한 잘 알려진 툴인 Qlik Replicate(이전의 Attunity)와 같은 툴이 포함됩니다.
데이터베이스 엔진에 데이터를 플랫 형식으로 직접 내보낸 다음 Amazon S3로 전송할 수 있는 도구가 포함되어 있을 수도 있습니다. 또한 일부 데이터베이스 엔진에는 CDC(Change Data Capture) 데이터를 Kafka 스트림으로 생성할 수 있는 솔루션인 오라클 GoldenGate와 같은 고급 도구가 있습니다.
4) 데이터베이스에서 수집하기 위한 최상의 접근 방식 결정
#데이터베이스 크기
전체 로드는 실행하는 데 상당한 시간이 걸릴 수 있으며 실행 중에 소스 시스템에 큰 부하가 걸릴 수 있기 때문에 테이블의 전체 크기가 큰 경우(수십 GB 이상) 야간에 전체 로드를 수행하는 것은 좋지 않습니다. 데이터베이스에서 초기 로드를 수행한 다음 CDC를 사용하여 소스에서 업데이트를 지속적으로 동기화하는 것이 더 좋습니다.
매우 큰 데이터베이스의 경우 AWS DMS를 Amazon Snowball 장치와 함께 사용하여 데이터를 데이터 센터의 Snowball 장치에 로드할 수 있습니다.
실시간에 가까운 변경 사항을 캡처할 필요가 없는 소규모 데이터베이스의 경우 AWS Glue(또는 기본 데이터베이스 도구)를 사용하여 예약된 기준으로 전체 데이터베이스를 Amazon S3에 로드하는 것을 고려할 수 있습니다.
#데이터베이스 로드
항상 일관된 프로덕션 로드가 있는 데이터베이스가 있는 경우 데이터 레이크에 동기화하기 위해 서버에 배치하는 추가 로드를 최소화하는 것이 좋습니다. 이 시나리오에서는 DMS에서 원본으로 지원하는 경우 데이터베이스의 읽기 전용 복제본에서 이상적으로 초기 전체 로드를 수행하는 데 DMS를 사용할 수 있습니다. 진행 중인 복제의 경우 DMS는 데이터베이스 로그 파일을 사용하여 CDC 변경 사항을 식별할 수 있으며 이로 인해 데이터베이스 리소스에 대한 부하가 낮아집니다.
데이터베이스에서 전체 로드를 수행할 때마다 모든 테이블의 전체 읽기가 필요하므로 데이터베이스에 더 많은 로드가 발생합니다. 이 로드를 고려하고 가능한 경우 전체 로드에 데이터베이스 복제본을 사용해야 합니다.
더 작은 데이터베이스가 Amazon RDS에서 실행 중인 경우 소스 데이터베이스에 부하를 주지 않는 RDS의 스냅샷 기능에서 S3로 내보내기를 사용하는 것이 가장 좋은 솔루션입니다.
#데이터베이스 수집 빈도
사용 사례에서 가능한 한 빨리 데이터베이스 소스에서 오는 데이터에 액세스해야 하는 경우 AWS DMS와 같은 서비스를 사용하여 CDC 데이터를 수집하는 것이 가장 좋은 방법입니다. 그러나 가장 최신 상태에 대한 쿼리를 활성화하기 위해 이를 기존 데이터에 적용하는 프로세스가 여전히 필요합니다.
사용 사례에서 야간과 같이 정기적으로 예약된 업데이트를 허용하는 경우 예약된 야간 프로세스를 통해 낮 동안 수집된 CDC 데이터를 적용할 수 있습니다.
#기술 요구 사항 및 호환성
데이터를 수집하기 위한 다양한 접근 방식과 도구를 평가할 때 제안된 솔루션을 기술적으로 평가하기 위해 데이터베이스 소유자와 관리 팀을 사전에 참여시키는 것이 매우 중요합니다.
데이터 엔지니어링 팀은 요구 사항과 소스 시스템과의 호환성에 대한 광범위한 이해를 바탕으로 특정 도구 집합을 미리 결정할 수 있습니다. 그러나 구현 시 소스 데이터베이스 팀이 솔루션의 특정 보안 또는 기술 요구 사항에 반대한다는 사실을 발견할 수 있으며 이로 인해 상당한 프로젝트 지연이 발생할 수 있습니다.
솔루션을 최종 결정하기 전에 데이터베이스 소유자와 관리 팀의 동의를 얻는 것이 중요합니다. 관리 팀을 선두로 이러한 요구 사항을 자세히 검토하는 것은 프로젝트의 성공에 매우 중요합니다.
3. 스트리밍 데이터 수집
점점 보편화되는 분석 프로젝트의 데이터 소스는 지속적으로 생성되고 거의 실시간으로 수집되어야 하는 데이터입니다.
- IoT 장치(예: 스마트 워치, 스마트 가전 등)의 데이터
- 다양한 유형의 차량(자동차, 비행기 등)의 원격 측정 데이터
- =센서 데이터(제조 기계, 기상 관측소 등)
- 모바일 게임의 실시간 게임 플레이 데이터
- 다양한 소셜 미디어 플랫폼에서 회사 브랜드 언급
1) Amazon Kinesis와 Kafka용 Amazon Managed Streaming(MSK) 비교
AWS 내에서 스트리밍 데이터를 수집하기 위한 것은 Amazon Kinesis 및 Amazon MSK입니다.
두 가지 모두 게시-구독 메시지 처리를 제공하는 AWS의 서비스입니다. 즉, 생산자는 스트리밍 서비스(Kinesis 또는 MSK)에 기록되는 메시지를 생성하고 소비자는 서비스에서 메시지를 수신하도록 구독합니다.
#서버리스 서비스 vs 관리형 서비스
Amazon Kinesis는 서버리스 서비스입니다 기본 서버에 대해 결정하거나 관리하거나 알 필요 없이, AWS가 자동으로 필요한 컴퓨팅 인프라를 구성합니다. Amazon Kinesis Data Firehose를 사용하면 메시지 처리량 변경에 따라 Kinesis Data Firehose가 자동으로 확장 및 축소됩니다.
Amazon MSK는 관리형 서비스입니다 기본 컴퓨팅 인프라 및 소프트웨어를 인식하고 결정을 내려야 합니다. 예를 들어 인스턴스 유형을 선택하고 VPC 네트워크 설정을 구성하고 다양한 Kafka구성 설정을 미세 조정해야 합니다. 또한
서비스와 함께 사용하려는 Kafka 버전을 선택해야 합니다.
서버리스 서비스인 Kinesis는 Amazon MSK보다 설정 및 구성이 훨씬 빠르고 쉽습니다. 그러나 Amazon MSK는 기본 소프트웨어를 구성하고 미세 조정하기 위한 훨씬 더 많은 옵션을 제공합니다.
#강력한 AWS 통합을 통한 독점 소프트웨어 vs 오픈 소스 유연성
Amazon Kinesis는 Kinesis 에이전트와 같은 일부 제한된 오픈 소스 요소가 있지만 AWS에서 만든 독점 소프트웨어입니다. Amazon Kinesis를 통해 AWS는 Amazon S3, Amazon Redshift 및 Amazon Elasticsearch와 같은 여러 AWS 서비스와의 강력한 통합을 제공합니다.
Amazon MSK는 널리 사용되는 오픈 소스 솔루션인 Apache Kafka의 관리형 버전입니다. Apache Kafka에는 소프트웨어에 기여하는 대규모 커뮤니티와 다양한 커넥터 및 통합을 제공하는 대규모 에코시스템이 있습니다
두 서비스 중에서 결정할 때 사용 사례에 필요한 통합 유형과 Kinesis 또는 MSK의 기본 기능과 일치하는 방식을 고려해야 합니다.
#최소 1회 메시징 vs 정확히 1회 메시징
Amazon Kinesis는 최소 한 번 메시지 처리 보장을 제공합니다. 이는 생산자가 생성한 모든 메시지가 처리를 위해 소비자에게 전달되도록 효과적으로 보장합니다. 그러나 특정 시나리오에서는 메시지가 소비 애플리케이션에 두 번 이상 전달되어 데이터 복제 가능성이 발생할 수 있습니다. 따라서 애플리케이션에서 개별 레코드가 여러 번 처리되는 방식을 예상하고 적절하게 처리하기 위한 로직을 구축해야 합니다.
Apache Kafka (및 Amazon MSK)에서는 버전 0.11부터 메시지 처리를 정확히 한 번만 처리하도록 스트림을 구성하는 기능이 도입되었습니다.
#단일 처리 엔진 vs 틈새 도구
Amazon Kinesis에는 특수 사용 사례를 위한 몇 가지 고유한 하위 서비스가 포함되어 있습니다. 예를 들어 사용 사례에 스트리밍 오디오 또는 비디오 데이터 수집이 포함된 경우 Amazon Kinesis Video Streams는 이러한 유형의 처리를 단순화하도록 맞춤 설계되었습니다.
#스트리밍 수집 도구 결정
Amazon Kinesis는 선행 구성이 덜 필요하고 진행 중인 유지 관리 작업이 더 적으며 특수 사용 사례를 위한 서비스 하위 집합도 있습니다.
사용 사례에 정확히 한 번 메시지 전달, 스트림 성능 미세 조정 기능 또는 요구 사항과 같은 특정 요구 사항이 있는 경우 Kinesis에서 직접 사용할 수 없는 타사 제품과 통합하려면 Amazon MSK를 고려합니다.
| Amazon Kinesis | Amazon MSK(Apache Kafka) |
| 서버리스 | 관리형 |
| aws 독점 소프트웨어 | 오픈 소스 유연성 |
| 최소 1회 | 정확히 1회 |
| 틈새 도구 | 단일 처리 엔진 |
[Data Engineering with AWS] 도서를 요약 및 번역하여 작성하였습니다.
https://www.amazon.com/Data-Engineering-AWS-Gareth-Eagar/dp/1800560419
Data Engineering with AWS: Learn how to design and build cloud-based data transformation pipelines using AWS: 9781800560413: Com
The missing expert-led manual for the AWS ecosystem ― go from foundations to building data engineering pipelines effortlessly Purchase of the print or Kindle book includes a free eBook in the PDF format. Key Features Learn about common data architectures
www.amazon.com