책 <견고한 데이터 엔지니어링(조 라이스, 맷 하우슬리 지음)>의 2장을 요약정리한 내용입니다.
이 책은 데이터 엔지니어링을 특정 데이터 기술 집합으로 보는 관점이 아닌 데이터 엔지니어가 데이터 수명 주기 관리 원칙의 관점에서 사고하는 것을 장려합니다. 이번 2장에서는 중심소재인 데이터 엔지니어링 수명 주기를 설명합니다.
데이터 엔지니어링 수명 주기란?
원시 데이터 요소(raw data)를 데이터 분석가, 과학자. ML 엔지니어 등이 사용할 수 있는 유용한 최종제품으로 전환하는 단계로 구성됩니다. 데이터 엔지니어링 수명 주기는 다음 5가지 단계를 거칩니다.
데이터 엔지니어링 수명 주기는 원천 시스템에서 데이터를 가져와 저장하는 것부터 시작됩니다. 이후 데이터를 변환하고, 이를 내부 사용자에게 제공하는 것을 목표로 진행됩니다.
데이터 저장은 수명 주기 전체에 걸쳐 일어나며, 다른 모든 단계를 뒷받침하는 기반이 됩니다. 수명 주기는 여러 단계가 반복되거나 순서가 바뀌거나, 겹치는 등 예상치 못한 방식으로 이루어질 수 있습니다. 이는 흐름이 깔끔하지 않거나 중간 단계가 섞여도 큰 문제가 되지 않음을 의미합니다.
데이터 엔지니어링 수명 주기의 기반은 여러 단계에 걸쳐 작용하는 숨겨진 요소입니다. 이러한 요소들이 없으면 수명 주기의 어떤 단계도 제대로 작동할 수 없습니다.
데이터 수명 주기와 데이터 엔지니어링 수명 주기의 차이
데이터 엔지니어링 수명 주기는 전체 데이터 수명주기의 하위 집합으로, 전체 데이터 수명주기는 데이터 전체 수명을 포괄하는 반면 데이터 엔지니어링 수명주기는 데이터 엔지니어라 제어하는 단계에 초점을 맞춘다는 미묘한 차이가 있습니다.
데이터 생성
원천 시스템은 데이터 엔지니어링 수명 주기에서 사용되는 데이터의 출처입니다. 예를 들어, IoT 장치, 애플리케이션 메시지 대기열*, 또는 트랜잭션 데이터베이스* 등이 원천 시스템의 예시입니다. 데이터 엔지니어는 원천 시스템의 데이터를 처리하기 위해 그 시스템의 작동 방식, 데이터 생성 방식, 데이터의 빈도와 속도, 그리고 생성되는 데이터의 다양성을 깊이 이해해야 합니다. 또한 엔지니어는 원천시스템 소유자와 데이터 파이프라인 분석을 중단할 가능성이 있는 변경사항에 대해 개방적인 소통라인을 유지해야 합니다.
데이터 엔지니어링의 큰 과제 중 하나는 데이터 엔지니어가 작업하고 이해해야 할 다양한 원천 시스템의 광범위한 배열입니다. 예를 들어, 일반적인 원천 시스템 두 가지를 살펴보겠습니다.
원천시스템 예시
첫 번째는 전통적인 애플리케이션 데이터베이스입니다. 이 패턴은 애플리케이션 서버와 데이터베이스가 결합된 형태로, 1980년대 RDBMS의 성공과 함께 널리 보급되었으며 오늘날에도 여전히 널리 사용됩니다. 이 패턴은 단일 모놀리스 시스템*이 아닌, 마이크로서비스*로 구성된 여러 소규모 서비스와 데이터베이스 쌍으로 구성될 수 있습니다.
*1 메시지 대기열: 서버리스 및 마이크로서비스 아키텍처에서 사용되는 비동기식 서비스 간 통신 방식으로, 작업 일괄 처리 및 애플리케이션 분리를 위한 비동기 메시징을 지원합니다.
*2 트랜잭션 데이터베이스: 데이터를 행 단위로 저장하는 방식입니다. 행 저장은 특정 데이터를 빠르게 조회할 수 있어, 예를 들어 사용자 테이블에서 특정 고객 정보를 검색할 때 효과적입니다.
*3 모놀리스: 시스템의 모든 기능이 하나의 프로세스로 함께 배포되는 형태를 말합니다. 모놀리식 아키텍처에서는 전체 시스템이 한 번에 배포되며, 모든 코드가 단일 프로세스로 패키징 됩니다.
*4 마이크로서비스: 비즈니스 도메인에 따라 독립적으로 릴리스 가능한 소규모 서비스로, 각 서비스는 기능을 캡슐화하고 네트워크를 통해 다른 서비스와 통신할 수 있습니다.
두 번째로 IOT 스웜입니다. IOT 장치들이 데이터 메시지를 중앙 수집 시스템에 송신하는 형태입니다. 이러한 IOT 원천 시스템은 IOT 장치가 늘어나면서 점점 더 보편화되고 있습니다.
데이터 생성 - 원천 시스템 평가: 주요 엔지니어링 고려 사항
원천 시스템을 평가할 때는 시스템의 수집, 상태 및 데이터 생성을 처리하는 방법 등 여러 가지 사항을 고려해야 합니다. 원천시스템 평가 질문 스타터킷을 기반으로 데이터 생성 시 주요 엔지니어링 고려사항을 파악해 보겠습니다.
- 데이터 원천의 특성
데이터는 어디에서 발생하는지, 예를 들어 애플리케이션, IoT 장치 등 다양한 원천을 구분할 수 있습니다. 원천 시스템에서 데이터는 어떻게 유지되고 보존되는지, 그리고 데이터가 얼마나 자주 삭제되는지에 대한 이해가 필요합니다. - 데이터 생성 속도와 양
데이터가 어느 정도의 속도로 생성되는지, 특히 이벤트 발생 시 갑작스러운 데이터 증가에 대비할 필요가 있습니다. 이를 통해 시스템이 감당할 수 있는 용량을 확인하고, 문제를 예방할 수 있습니다. - 데이터 품질 관리
원천 시스템에서 데이터 품질에 문제가 발생할 경우 어떻게 대응할지 사전에 계획해야 합니다. 데이터 무결성 검사나 오류 처리 방법에 대한 명확한 절차가 필요합니다. - 이벤트 처리
데이터가 얼마나 자주 변경되며, 이러한 변경 사항이 실시간으로 처리되는지 파악해야 합니다. 또한 이벤트 기반의 데이터 전송(예: 변경 데이터 캡처, CDC)이 필요한지 여부를 평가하는 것도 중요합니다. - 다운스트림 시스템과의 연계
원천 시스템에서 데이터를 다운스트림 시스템으로 어떻게 전달하고, 이를 활용하는 주체는 누구인지 명확히 해야 합니다. 이때 데이터 전송 속도와 성능, 연관된 서비스 간의 상호작용을 고려해야 합니다. - 성능 및 지연
원천 시스템이 데이터 조회 성능에 미치는 영향을 평가하고, 지연을 최소화할 방법을 모색해야 합니다. 시스템이 실시간 처리를 요구하는지, 아니면 약간의 지연을 허용할 수 있는지에 따라 접근 방식이 달라질 수 있습니다.
원천은 사람이 생성한 다운스트림 시스템(스프레드시트, 앱, 웹앱, IOT 센서 등) 환경에서 사용되는 데이터를 생성합니다. 각 원천에는 고유한 데이터 양과 데이터 생성주기가 있습니다. 그렇기에 데이터 엔지니어는 원천으로부터 데이터를 생성하는 방법을 알고, 상호작용하는 원천시스템의 한계를 이해해야 합니다. 예를 들어 원천 애플리케이션 데이터 베이스에 대한 분석 쿼리는 자원 경합 및 성능 문제를 일으킬 수 있을까? 와 같은 내용을 고민해보아야 합니다.
원천 데이터의 까다로운 차이점 - 스키마
스키마는 데이터의 계층 구성을 정의하는데, 원천 시스템이 제공하는 데이터의 스키마는 다양한 방식으로 처리될 수 있습니다. 여기에서 널리 사용되는 두 가지 스키마 방식을 살펴보겠습니다.
- 스키마리스 방식: 스키마가 아예 없는 것은 아니며, 애플리케이션이 메시지 대기열, 플랫 파일, 몽고 DB와 같은 도큐먼트 데이터베이스*에 데이터를 기록할 때 사용됩니다. 이 방식은 유연성이 크지만, 체계적인 관리가 필요합니다.
- 고정 스키마 방식: RDBMS와 같은 전통적인 스토리지를 기반으로 구축된 모델에서는 고정된 스키마를 사용합니다. 애플리케이션에서 데이터를 기록할 때, 반드시 미리 정의된 스키마 구조를 준수해야 합니다.
엔지니어는 원천 시스템의 스키마 변화를 이해하고 이에 맞춰 대응할 방안을 마련해야 합니다. 특히 시간이 지남에 따라 소프트웨어와 데이터베이스 스키마가 어떻게 변화하는지, 그리고 이를 통해 원천 시스템의 데이터를 어떻게 효율적으로 유지할 것인지가 중요한 과제입니다. 이러한 요소들을 고려하여 스키마와 데이터 모델링을 지속적으로 관리해야 안정적이고 성능이 뛰어난 데이터베이스 운영이 가능합니다.
*1 도큐먼트 데이터베이스는 JSON과 유사한 형식의 문서로 데이터를 저장하고 쿼리하는 데 사용할 수 있는 NoSQL 데이터베이스 유형입니다.
데이터 저장
데이터를 저장할 공간인 스토리지 솔루션을 선택하는 것은 나머지 데이터 수명 주기에서 성공을 거두기 위한 열쇠이자, 아래와 같은 이유로 수명주기에서 가장 복잡한 단계이기도 합니다.
- 클라우드 데이터 아키텍처는 종종 여러 스토리지 솔루션을 활용한다.
- 복잡한 변환 쿼리를 지원하는 데이터 스토리지 솔루션은 순수하게 스토리지로서 작동하는 경우가 거의 없으며 많은 솔루션이 복잡한 변환 쿼리를 지원한다. (심지어 객체 스토리지 솔루션인 AWS S3도 쿼리 기능을 지원할 정도이다)
- 저장은 데이터 엔지니어링 수명 주기의 한 단계이지만 수집, 변환 및 서비스 제공과 같은 다른 단계에도 자주 관여한다.
저장이 전체 데이터 엔지니어링 수명 주기에 걸쳐 실행되고, 데이터 저장 방식이 데이터 엔지니어링 수명 주기의 모든 단계에서 데이터 사용 방식에 여러 가지로 영향을 미치기에 스토리지 솔루션을 선택하는 것이 어려운 단계입니다.
데이터 저장 - 스토리지 시스템 평가: 주요 엔지니어링 고려 사항
데이터 웨어하우스, 데이터 레이크하우스, 데이터베이스 또는 객체 스토리지 등을 위한 스토리지 시스템을 선택할 때 확인할 핵심 엔지니어링 질문을 통해 고려해야 할 주요 사항을 파악해 보겠습니다.
- 스토리지 성능: 아키텍처에서 요구하는 쓰기 및 읽기 속도를 충분히 지원할 수 있는지 평가해야 합니다. 특히 다운스트림 프로세스에서 병목 현상이 발생하지 않도록 유의해야 합니다.
- 기술 최적화: 스토리지 시스템이 최적의 방식으로 사용되고 있는지 확인해야 합니다. 예를 들어, 전체 스토리지에 비효율적인 부분이 존재하는지, 랜덤 액세스 패턴이 필요한지 등을 검토할 필요가 있습니다.
- 확장성: 스토리지 시스템이 미래에도 확장 가능성을 지니고 있는지 고려해야 합니다. 용량과 성능의 제약 없이 시스템을 확장할 수 있는지를 평가하는 것이 중요합니다.
- SLA 준수: 다운스트림 사용자가 필요로 하는 서비스 수준 협약(SLA)을 만족시킬 수 있는지도 점검해야 합니다. 이는 데이터 전송과 처리를 원활하게 하기 위해 중요한 요소입니다.
- 스키마 관리: 스키마의 변화가 데이터베이스에 어떤 영향을 미치는지, 그리고 메타데이터 관리가 적절히 이루어지는지 확인해야 합니다. 스키마의 변화는 소프트웨어의 성능과 효율성에 큰 영향을 미칠 수 있습니다.
- 복잡한 쿼리 지원 여부: 스토리지 시스템이 복잡한 쿼리를 지원할 수 있는지 평가해야 합니다. 특히 객체 스토리지를 사용하는 경우에도 복잡한 쿼리가 가능해야 데이터 활용도를 높일 수 있습니다.
엔지니어는 이러한 사항을 고려하여 스토리지 시스템을 선택하고, 각 스토리지 방식이 데이터 엔지니어링 수명 주기 전반에 걸쳐 어떻게 영향을 미칠지 평가해야 합니다.
데이터 접근 빈도 이해
스토리지 솔루션을 선택할 때는 데이터 접근 빈도를 이해하는 것이 중요합니다. 모든 데이터가 동일한 방식으로 액세스되는 것은 아니며, 검색 패턴에 따라 저장 및 쿼리되는 데이터의 특성이 크게 달라집니다. 이를 기준으로 데이터 온도라는 개념이 나타났습니다. 데이터 접근 빈도에 따라 데이터 온도는 세 가지로 분류됩니다.
- 핫 데이터: 가장 자주 액세스되는 데이터입니다. 일반적으로 하루에 여러 번 검색되며, 이러한 데이터는 빠른 검색을 지원하는 저장소에 저장되어야 합니다. 여기서 '빠름'의 기준은 사용 사례에 따라 다를 수 있습니다.
- 미온적 데이터: 가끔 액세스되는 데이터로, 예를 들면 주기적으로 매주 또는 매월 검색되는 데이터를 의미합니다.
- 콜드 데이터: 거의 쿼리되지 않는 데이터로, 아카이브 시스템에 저장하는 것이 적합합니다. 콜드 데이터는 주로 규정 준수 목적으로 보관되거나, 다른 시스템에 심각한 장애가 발생했을 때 대비책으로 보관됩니다.
스토리지 시스템 선택
어떤 유형의 스토리지 솔루션을 선택할지는 수집되는 데이터의 사용 사례, 데이터 볼륨, 수집 빈도, 형식, 그리고 크기에 따라 달라집니다. 스토리지 선택에 있어 모든 상황에 적용할 수 있는 범용적인 권장사항은 없습니다. 각 스토리지 기술에는 트레이드오프(장단점)가 존재하며, 이를 충분히 고려하여 선택해야 합니다. 수많은 스토리지 기술이 존재하기 때문에 데이터 아키텍처 옵션을 결정할 때 압도당하기 쉽지만, 이를 잘 이해하고 판단하는 것이 중요합니다.
퀴즈 1
스키마리스 방식의 특징으로 알맞은 것은?
- 데이터 저장 과정에서 고려해야한다.
- 유연성이 크고, 체계적인 관리가 필요하다.
- 스키마가 아예 없다.
- RDBMS에서 기록될 때 사용된다.
정답: 2. 유연성이 크고, 체계적인 관리가 필요하다.
퀴즈 2
데이터 접근 빈도에 따라 분류되는 데이터 온도 중, 가장 자주 액세스되며 하루에 여러 번 검색되는 데이터는 무엇인가요?
- 미온적 데이터
- 핫 데이터
- 콜드 데이터
- 온디맨드 데이터
정답: 2. 핫 데이터
'Data > 엔지니어링' 카테고리의 다른 글
데이터 엔지니어링 수명주기 전체에 걸친 기술 선택 (0) | 2024.10.14 |
---|