[AWS 데이터엔지니어링] 5장 데이터 엔지니어링 파이프라인 설계

<Data Engineering with AWS> 5장을 번역 및 요약한 내용입니다.

---

책의 4장까지 해서 섹션 1이 끝났습니다! 지금까지 학습한 데이터 엔지니어링 원칙, 핵심 개념, 사용 가능한 AWS 도구를 사용하여 데이터 파이프라인의 형태로 결합할 수 있습니다. 데이터 파이프라인이란, 여러 소스로부터 데이터를 얻고 변환하는 프로세스입니다. 데이터 엔지니어링 역할의 중요한 기능은 이러한 파이프라인을 설계하는 것입니다.

 

1. 데이터 파이프라인 아키텍처 접근

아키텍처에 들어갈 개별 구성 요소의 세부 정보를 살펴보기 전에 우리가 하려는 작업을 넓은 시각에서 살펴보는 것이 좋습니다.

① 주택 설계 및 파이프라인 설계

새 집을 짓는다면 건축가는 건물이 들어갈 땅과 건물의 설계에 대한 대략적인 계획을 세우는 것부터 시작합니다. 데이터 파이프라인을 위한 아키텍처를 생성하는 데이터 엔지니어의 경우, 이와 유사한 접근 방식을 사용할 수 있습니다.

• 프로젝트 스폰서 및 데이터 소비자로부터 요구 사항에 대한 정보를 수집합니다. 목표가 무엇인지, 데이터를 소비하는 데 사용할 도구 유형, 필요한 데이터 변환 등을 알아보는 것입니다.
• 사용 가능한 데이터 소스에 대한 정보를 수집합니다. 여기에는 원시 데이터를 저장하는 시스템, 데이터 형식, 시스템 및 데이터 소유자 등이 포함될 수 있습니다.
• 사용 가능한 도구 유형과 이러한 요구 사항에 가장 적합한 도구 유형을 결정합니다.

 

② 정보 수집 도구로서의 화이트보드

위에서 말한 여러 정보를 수집하는 좋은 방법은 관련 이해 관계자와 화이트보드 세션을 진행하는 것입니다. 이렇게 하면 데이터 엔지니어가 데이터 파이프라인에 대한 높은 수준의 계획을 개발하고 시작하는 데 필요한 정보를 수집할 수 있습니다.

 

다음 다이어그램은 일반적인 데이터 파이프라인의 기본 구성 요소에 대한 높은 수준의 개요와 높은 수준의 파이프라인 아키텍처를 개발하는 접근 방식을 보여줍니다.

데이터 파이프라인 아키텍처의 상위 수준 개요

파이프라인 설계에 접근할 때 다음 시퀀스를 사용할 수 있습니다.(위 다이어그램의 숫자)

1. 비즈니스 목표, 데이터 소비자 및 요구 사항 이해
2. 데이터 소비자가 데이터에 액세스하는 데 사용할 도구 유형 결정
3. 어떤 잠재적인 데이터 소스를 사용할 수 있는지 이해
4. 데이터 수집에 사용할 도구 세트 유형 결정
5. 원시 데이터를 가져와 데이터 소비자를 위해 준비하기 위해 높은 수준에서 필요한 데이터 변환 이해

보시다시피 파이프라인을 설계할 때는 항상 거꾸로 작업해야 합니다. 즉, 데이터 소비자와 그들의 요구 사항으로 시작한 다음 거기에서 작업하여 파이프라인을 설계해야 합니다.

 

③ 화이트보드 세션 진행

초기 프로젝트가 확인되면 데이터 엔지니어는 관련 이해 관계자들을 모아 워크숍을 개최하여 높은 수준의 접근 방식을 화이트보드로 작성해야 합니다. 이 워크숍에서 단순히 기술 정보를 수집하는 것이 아니라 비즈니스 목표를 이해해야 합니다. 비즈니스 스폰서에게 현재 당면 과제에 대한 개요를 제공하고 프로젝트에 대해 예상되는 비즈니스 결과 또는 목표를 검토하도록 요청하는 것이 좋습니다. 팀이 비즈니스 가치를 잘 이해하면 데이터 엔지니어가 화이트보드를 시작하여 높은 수준의 설계를 통합할 수 있습니다. 

 

2. 데이터 소비자 식별 및 요구 사항 이해

먼저 데이터 소비자가 누구인지 파악하고 그들의 요구사항을 이해하는 것부터 시작하겠습니다. 화이트보드 워크숍 중에 데이터 엔지니어는 식별된 프로젝트의 데이터 소비자가 누구인지 이해하기 위해 질문을 해야 합니다. 각 데이터 소비자가 데이터에 액세스하기 위해 사용하려는 도구 유형을 이해하는 것도 중요합니다.

 

정보가 수집되면 다음 다이어그램과 같이 화이트보드에 추가할 수 있습니다.

화이트보드 데이터 소비자 및 데이터 액세스

이 예에서는 데이터 분석가 팀, 데이터 과학 팀 및 다양한 비즈니스 사용자의 세 가지 데이터 소비자를 확인했습니다.

 

프로젝트에 사용할 데이터 소비자가 누구인지, 데이터 작업에 사용할 도구 유형을 잘 파악하면 화이트보드의 다음 단계로 넘어갈 수 있습니다. 화이트보드는 데이터를 수집하기 위해 사용 가능한 데이터 소스와 수단을 조사하는 것입니다.

 

3. 데이터 소스 식별 및 데이터 수집

프로젝트의 전반적인 비즈니스 목표와 데이터 소비자를 파악하면 사용 가능한 데이터 소스를 탐색할 수 있습니다.

대부분의 데이터 소스는 조직 내부에 있지만, 일부 프로젝트에서는 다른 타사 데이터 소스를 사용하여 조직 소유 데이터를 강화해야 할 수도 있습니다. 최근 다양한 데이터 세트를 무료로 구독하거나 액세스할 수 있는 데이터 마켓이 많기 때문에, 데이터 소스를 논의할 때는 내부 및 외부 데이터 세트를 모두 고려해야 합니다.

이러한 데이터 소스에 대해 데이터 엔지니어가 수집해야 하는 정보에는 아래와 같은 것들이 있습니다.

• 데이터가 포함된 소스 시스템에 대한 세부 정보(데이터베이스의 데이터, 서버의 파일, Amazon S3의 기존 파일, 스트리밍 소스에서 오는 데이터 등)
• 이 데이터가 내부 데이터라면 비즈니스 내 소스 시스템의 소유자이고, 데이터의 소유자는 누구인지
• 데이터를 수집해야 하는 빈도(지속적인 스트리밍/복제, 몇 시간마다 데이터 로드, 하루에 한 번 데이터 로드)
• 선택적으로 데이터 수집에 사용할 수 있는 몇 가지 잠재적인 도구들
• 데이터의 원시/수집 형식(CSV, JSON, 기본 데이터베이스 형식 등)
• 데이터 원본에 PII 또는 거버넌스 제어가 적용되는 다른 유형의 데이터가 포함되어 있는지, 그렇다면 데이터를 보호하기 위해 어떤 통제가 필요한지

정보가 수집되면 다음 다이어그램과 같이 화이트보드에 캡처할 수 있습니다.

화이트보드 데이터 소스 및 데이터 수집

이 예에서는 MySQL 데이터베이스의 고객 데이터, Salesforce의 기회 정보, 조직의 모바일 애플리케이션에서 얻은 거의 실시간 판매 지표 등 세 가지 데이터 소스를 확인했습니다.

 

이 화이트보드 세션 동안 우리는 거꾸로 작업하면서 먼저 데이터 소비자를 식별한 다음 사용할 데이터 소스를 식별했습니다. 이 시점에서 우리는 분석을 위한 데이터를 최적화하기 위해 일부 데이터 변환을 검토하는 단계로 넘어가겠습니다.

 

4. 데이터 변환 및 최적화 식별

일반적인 데이터 분석 프로젝트에서는 여러 데이터 소스에서 데이터를 수집한 다음 해당 데이터 세트에 대한 변환을 수행하여 필요한 분석에 맞게 최적화합니다.

① 파일 형식 최적화

CSV, XML, JSON 및 기타 유형의 일반 텍스트 파일은 일반적으로 구조화된 데이터와 반구조화된 데이터를 저장하는 데 사용됩니다. 하지만 훨씬 더 최적화된 이진 기반 파일 형식이 있는데, 바로 Apache Parquet 형식입니다. 일반적인 변환은 일반 텍스트 파일을 Apache Parquet와 같은 최적화된 형식으로 변환하는 것입니다.

② 데이터 표준화

각 데이터 소스는 동일한 항목을 참조하기 위한 서로 다른 명명 규칙을 가질 수 있습니다. 예를 들어, 누군가의 생년월일을 포함하는 필드는 DOB, dateOfBirth, birth_date 등이라고 할 수 있습니다. 생년월일의 형식은 mm/dd/yyy, dd/mm/yyyy 또는 여러 다른 형식으로 저장할 수도 있습니다.
분석을 위해 데이터를 최적화할 때 수행해야 할 작업 중 하나는 이러한 열 이름, 유형 및 형식을 표준화하는 것입니다.

③ 데이터 품질 확인

데이터 변환의 또 다른 측면은 데이터 품질을 검증하고 예상 품질 표준을 충족하지 못하는 수집된 데이터를 강조하는 프로세스일 수 있습니다.

④ 데이터 파티셔닝(분할)

분석을 위한 일반적인 최적화 전략은 데이터를 분할하여 물리적 스토리지 계층의 데이터를 쿼리에 자주 사용되는 필드별로 그룹화하는 것입니다. 예를 들어, 데이터를 날짜 범위로 쿼리하는 경우 데이터를 날짜 필드로 분할할 수 있습니다. 판매 데이터를 저장하는 경우 특정 달의 모든 판매 트랜잭션은 동일한 Amazon S3 접두사(디렉토리와 매우 유사함)에 저장됩니다. 특정 날짜(ex. 23년 2월 8일)의 모든 데이터를 선택하는 쿼리를 실행할 때 분석 엔진은 해당 월(ex. 23년 2월)의 데이터를 저장하는 디렉토리의 데이터만 읽으면 됩니다.

⑤ 데이터 비정규화

데이터 레이크의 경우, 여러 테이블의 데이터를 단일 테이블로 결합하면 종종 쿼리 성능이 향상될 수 있습니다. 데이터 비정규화는 두 개(또는 그 이상)의 테이블을 사용하여 두 테이블의 데이터로 새 테이블을 만듭니다.

⑥ 데이터 카탈로그

데이터 세트를 카탈로그화하는 프로세스는, 이 프로세스를 수행하는 동안 데이터 레이크의 모든 데이터셋이 데이터 카탈로그에서 참조되고 비즈니스 메타데이터를 추가할 수 있습니다.

⑦ 화이트보드 데이터 변환

화이트보드 세션의 경우 필요한 변환의 모든 세부 사항을 결정할 필요는 없지만, 높은 수준의 파이프라인 설계를 위한 주요 변환에 동의하는 것이 유용합니다. 데이터 엔지니어는 화이트보드 세션 동안 예상되는 데이터 변환에 대한 정보를 수집해야 합니다.

정보가 수집되면 다음 다이어그램과 같이 화이트보드에 캡처할 수 있습니다.

화이트보드 데이터 변환

이 예에서는 랜딩 존, 클린 존, 큐레이티드 존의 세 가지 영역으로 데이터 레이크를 생성합니다.

 

데이터 변환을 결정했으면, 이제 데이터 마트가 필요한지 여부를 결정하는 화이트보드 프로세스의 마지막 단계로 이동합니다.

 

5. 데이터 마트에 데이터 로드

3장 <AWS 엔지니어를 위한 도구 키트>에서 다루었듯이 많은 툴이 데이터 레이크의 데이터를 직접 처리할 수 있습니다. 이 도구들은 Amazon S3에서 직접 데이터를 읽지만, 사용 사례에서 훨씬 더 낮은 지연 시간과 더 높은 성능의 데이터 읽기 또는 고도로 구조화된 스키마의 사용이 필요한 경우가 있을 수 있습니다. 이럴 때는 데이터 레이크에서 데이터 마트로 데이터를 로드하는 것이 합리적입니다.

 

분석 환경에서 데이터 마트는 대부분 데이터 웨어하우스 시스템(예: Amazon Redshift)이지만, 사용 사례의 요구 사항에 따라 관계형 데이터베이스 시스템(예: Amazon RDS MySQL)일 수도 있습니다. 두 경우 모두 시스템은 로컬 스토리지(종종 고속 플래시 드라이브)와 로컬 컴퓨팅 성능을 갖추고 있어 대규모 데이터셋, 특히 쿼리가 여러 테이블에 걸쳐 결합되어야 하는 경우 최고의 성능을 제공합니다.

화이트보드 세션의 일환으로 데이터 마트가 데이터의 하위 집합을 로드하는 데 가장 적합한지에 대해 논의하는 데 시간을 할애해야 합니다. 예를 들어, 많은 수의 사용자가 BI 도구(데이터 시각화를 위해)를 사용할 것으로 예상되는 경우 이러한 팀에서 가장 많이 사용할 데이터를 논의하는 데 시간이 걸릴 수 있습니다.

 

6. 화이트보드 세션 마무리

화이트보드 세션을 완료한 후에는 구축하려는 파이프라인의 주요 구성 요소를 보여주는 개요 아키텍처가 있어야 합니다. 현 시점에서 여전히 답이 없는 질문들이 많을 것이고 구체적인 내용도 많지 않을 것입니다. 하지만 높은 수준의 아키텍처는 프로젝트에 대해 제안된 계획에 대해 이해관계자들로부터 광범위한 동의를 얻기에 충분해야 합니다.

 

세션이 끝나면 최종 고급 아키텍처 다이어그램을 작성하고 회의에서 얻은 메모를 포함해야 합니다. 이 메모는 모든 참가자에게 배포하여 초안 아키텍처를 기반으로 프로젝트를 진행하는 것에 대한 승인을 요청해야 합니다.

높은 수준의 접근 방식에 대한 합의가 이루어지면, 추가 세부 사항을 파악하고 요구 사항을 완전히 검토하기 위해 다른 팀과 추가 세션이 필요합니다.

이 장에서 살펴본 시나리오에 기초한 최종 고급 아키텍처 다이어그램은 아래와 같습니다.

높은 수준의 아키텍처 화이트보드

 

---

이 장에서는 제한된 범위의 프로젝트를 식별한 다음 높은 수준의 아키텍처 다이어그램을 화이트보드로 작성하여 데이터 엔지니어링 파이프라인을 개발하는 접근 방식을 검토했습니다. 또, 요구 사항을 논의하고 초기 아키텍처를 계획하기 위해 조직의 관련 이해 관계자와 함께 워크숍을 가질 수 있는 방법을 살펴보았습니다.

 

다음 장에서는 데이터 엔지니어링 파이프라인의 일부로 배치 및 스트리밍 데이터를 수집하기 위한 AWS 서비스에 대해 자세히 살펴보겠습니다.