데이터 엔지니어링 수명 주기

데이터 엔지니어링 수명 주기는 원천 시스템에서 데이터를 가져와 저장하는 것에서 시작한다. 데이터를 변환한 뒤 분석가, 데이터 과학자, ML 엔지니어 등에게 데이터를 제공한다는 주요 목표를 향해 나아간다. 실제로 데이터 저장은 데이터가 처음부터 끝까지 흐르면서 수명 주기 전체에 걸쳐 발생한다. 

데이터 생성

원천 시스템 : 데이터 엔지니어링 수명 주기에서 사용되는 데이터의 원본이다. IoT 장치와 애플리케이션 메시지 대기열 또는 트랜잭션 데이터베이스를 예로 들 수 있다. 데이터 엔지니어는 원천 시스템의 데이터를 소비하나, 일반적으로 원천 시스템 자체를 소유하거나 제어하지 않는다. 데이터 엔지니어는 원천 시스템의 작동 방식, 데이터 생성 방식, 데이터 빈도 및 속도, 생성되는 데이터의 다양성을 실무적으로 이해해야 한다. 엔지니어는 데이터 파이프라인과 분석을 중단할 수 있는 변경 사항에 대해 원천 시스템 소유자와 개방적인 소통 라인을 유지해야 한다. 애플리케이션 코드가 필드의 데이터 구조를 변경하거나, 애플리케이션 팀이 백엔드를 완전히 새로운 데이터베이스 기술로 마이그레이션하는 경우도 있다. 데이터 엔지니어링의 가장 큰 과제는 엔지니어가 작업하고 이해해야 하는 데이터 원천 시스템의 방대한 배열이다. 

[원천 시스템의 평가요소]

- 데이터 원천의 본질적인 특징은 무엇인가?

- 원천 시스템에서 데이터는 어떻게 유지되는가? 장기간 보존되는가? 아니면 일시적이고 빠르게 삭제되는가?

- 데이터는 어느 정도의 속도로 생성되는가? 초당 몇 개의 이벤트가 발생할까? 시간당 몇 기가바이트인가?

- 데이터 엔지니어는 출력 데이터에서 어느 정도의 일관성을 기대할 수 있는가? 출력 데이터에 대해 데이터 품질 검사를 실행할 때, 예상치 못한 출력값이나 잘못된 데이터 포맷과 같은 데이터 불일치 사례는 얼마나 자주 발생할까?

- 에러는 얼마나 자주 발생하는가?

- 데이터에 중복이 포함되지는 않는가?

- 일부 데이터값이 동시에 생성되는 다른 메시지보다 훨씬 늦게 도착할 수 있는가?

- 수집된 데이터의 스키마는 무엇인가?  데이터를 완전히 파악하려면 여러 테이블 또는 여러 시스템에 걸쳐 조인을 수행해야 하는가?

- 스키마가 변경되면 어떻게 대처하고 다운스트림 이해관계자에게 전달할 수 있는가?

- 원천 시스템에서 데이터를 얼마나 자주 가져와야 하는가?

- 상태가 있는 시스템의 경우, 데이터는 정기적인 스냅숏으로 제공되는가? 아니면 변경 데이터 캡처로부터의 갱신 이벤트로 ㅈㅔ공되는가? 변경은 어떻게 수행되며, 원천 데이터베이스에서 이러한 변경을 어떻게 추적하는가?

- 다운스트림 사용을 위한 데이터를 전송하는 데이터 제공업체는 누구인가?

- 데이터 원천에서의 데이터 조회가 성능에 영향을 미치는가?

- 원천 시스템에 업스트림 데이터 의존 관계가 있는가? 이러한 업스트림 시스템의 특징은 무엇인가?

- 늦거나 누락된 데이터 확인용으로 데이터 품질 검사가 실시되고 있는가?

 

데이터 저장

데이터를 저장할 공간이 필요하다. 스토리지 솔루션을 선택하는 것은 나머지 데이터 수명 주기에서 성공을 거두기 위한 열쇠이면서, 다음과 같은 다양한 이유로 데이터 수명 주기에서 가장 복잡한 단계의 하나이기더 하다.

1. 클라우드의 데이터 아키텍처는 종종 여러 스토리지 솔루션을 활용한다.

2. 복잡한 쿼리를 지원하는 데이터 스토리지 솔루션은 순수하게 스토리지로서만 작동하는 경우가 거의 없으며 많은 솔루션이 복잡한 변환 쿼리를 지원한다. 심지어 객체 스토리지 솔루션도 Amazon S3 Select와 같은 강력한 쿼리 기능을 지원할 수 있다.

3. 저장은 데이터 엔지니어링 수명 주기의 한 단계이지만 수집, 변환 및 서비스 제공과 같은 다른 단계에서도 자주 관여한다.

저장은 데이터 파이프라인의 여러 위치에서 발생하며 원천 시스템, 수집, 변환 및 서빙과 교차하는 스토리지 시스템을 통해 전체 데이터 엔지니어링 수명 주기에 걸쳐 실행된다. 데이터 저장 방식은 데이터 엔지니어링 수명 주기의 모든 단계에서 데이터 사용 방식에 여러 가지로 영향을 미친다. 클라우드 데이터 웨어하우스는 데이터를 저장하고 파이프라인에 데이터를 처리해 분석가에게 제공할 수 있다. 아파치 카프카와 펄사같은 스트리밍 프레임워크는 데이터 전송을 위한 표준 계층인 객체 저장과 함께 메시지의 수집, 저장 쿼리 시스템으로서 동시에 작동할 수 있다.

[스토리지 시스템 평가]

- 이 스토리지 솔루션은 아키텍처에서 요구하는 쓰기 및 읽기 속도와 잘 맞는가?

- 스토리지가 다운스트림 프로세스의 병목 현상을 초래하지는 않는가?

- 이 스토리지 기술이 작동하는 방식을 인지하고 있는가? 스토리지 시스템을 최적으로 활용하는가? 아니면 부자연스러운 행동을 하는가? 예를 들어 객체 스토리지 시스템에 높은 비율의 임의 접근 갱신을 적용하고 있지는 않은가?

- 이 스토리지 시스템은 향후 예상되는 확장을 처리할 수 있는가? 사용 가능한 총 스토리지, 읽기 작업 속도, 쓰기 볼륨 등 스토리지 시스템의 모든 용량 제한을 고려해야 한다.

- 다운스트림 사용자와 프로세스가 필요한 서비스 수준 협약에 따라 데이터를 취득할 수 있는가?

- 스키마 진화, 데이터 흐름, 데이터 계보 등에 대한 메타데이터를 캡처하고 있는가? 순수 스토리지 솔루션인가? 아니면 복잡한 쿼리 패턴을 지원하는가?

- 스토리지 시스템이 스키마에 구애받지는 않는가? 유연한 스키마인가? 강제 적용된 스키마인가?

- 데이터 거버넌스를 위해 마스터 데이터, 골든 레코드 데이터 품질 및 데이터 계보를 어떻게 추적하고 있는가?

- 법령 준수 및 데이터 주권에 어떻게 대처하고 있는가? 예를 들어 특정 지리적 위치에는 데이터를 저장하고 다른 위치에는 저장하지 않을 수 있는가?

*핫 데이터 : 일반적으로 하루에 여러번 검색되는 데이터로, 빠른 검색용으로 저장되어야 한다.

*콜드 데이터 : 거의 쿼리되지 않으며 아카이브 시스템에 저장하는 데 적합하다. 콜드 데이터는 규정 준수의 목적으로 보관되거나, 다른 시스템에 심각한 장애가 발생했을 때 보관되는 경우가 많다.

데이터 수집

데이터 원천과, 사용 중인 원천 시스템의 특징 및 데이터 저장 방법을 이해한 뒤에 데이터를 수집해야 한다. 데이터 엔지니어링 수명 주기의 다음 단계는 원천 시스템에서 데이터를 수집하는 것이다. 원천 시스템과 데이터 수집은 데이터 엔지니어링 수명 주기에서 가장 큰 병목 현상을 나타낸다. 원천 시스템은 보통 직접 관리할 수 없으며, 임의로 응답하지 않거나 품질이 낮은 데이터를 제공할 수 있다. 또는 여러 가지 이유로 데이터 수집 서비스가 작동하지 않을 수도 있다. 그 결과 데이터 흐름이 멈추거나 저장, 처리 및 서비스에 필요한 불충분한 데이터가 제공된다. 신뢰할 수 없는 원천 및 수집 시스템은 데이터 엔지니어링 수명 주기 전반에 걸쳐 파급 효과를 가져올 수 있다.

[데이터 수집 고려사항]

- 수집 중인 데이터의 사용 사례는 무엇인가? 같은 데이터셋의 여러 버전을 생성하는 대신 이 데이터를 재사용할 수 있는가?

- 시스템이 이 데이터를 안정적으로 생성하고 수집하고 있는가? 필요할 때 해당 데이터를 사용할 수 있는가? 

- 수집 후 데이터 목적지는 어디인가?

- 데이터에 얼마나 자주 접근해야 하는가?

- 데이터는 보통 어느 정도의 용량으로 도착하는가?

- 데이터 형식은 무엇인가? 다운스트림 스토리지 및 변환 시스템에서 이 형식을 처리할 수 있는가?

- 원천 데이터는 다운스트림에서 즉시 사용할 수 있는 양호한 상태인가? 그렇다면 얼마나 오래 사용할 수 있으며, 사용할 수 없게 되는 요인은 무엇인가?

- 데이터가 스트리밍 소스에서 전송된 경우, 목적지에 도달하기 전에 데이터를 변환해야 하는가? 데이터가 스트림 자체 내에서 변환되는 형태의 변환이 적절할까?

 

배치 vs 스트리밍

우리가 다루는 대부분의 데이터는 본질적으로 스트리밍이다. 데이터는 거의 항상 원천에서 지속해 생성되고 갱신된다. 배치 수집은 스트림을 큰 청크로 처리하는 전문적이고 편리한 방법이다. 예로 하루 분량의 데이터를 단일 배치 방식으로 처리한다. 스트리밍 수집을 사용하면 다른 애플리케이션이나 데이터베이스 또는 분석 시스템 등의 다운스트림 시스템에 데이터를 실시간으로 연속해 제공할 수 있다.

*실시간 : 데이터가 생성된 지 얼마 지나지 않은 짧은 시간에 다운스트림 시스템에서 데이터를 사용할 수 있음을 의미(Ex.1초 미만)하며, 실시간 인증에 필요한 지연 시간은 도메인 및 요건 사항에 따라 다르다.

배치 데이터는 미리 설정된 시간 간격에 따라 또는 데이터가 미리 설정된 크기 임곗값에 도달하면 수집된다. 배치 수집은 한 방향으로만 이루어지며, 데이터가 배치로 분할되면 다운스트림 소비자의 지연 시간이 본질적으로 제한된다. 레거시 시스템의 제약 때문에 오랫동안 배치가 기본적인 데이터 수집 방식이었다. 배치 처리는 특히 분석 및 머신러닝에서 다운스트림을 사용할 때 데이터를 수집하는 매우 인기있는 방법이다.

[배치와 스트림 수집의 고려사항]

- 데이터를 실시간으로 수집하면 다운스트림 스토리지 시스템이 데이터 흐름 속도를 처리할 수 있는가?

- 밀리초 단위의 실시간 데이터 수집이 필요할까? 아니면 매 분마다 데이터를 축적하고 수집하는 마이크로 배치 접근 방식이 효과가 있을까?

- 스트리밍 수집의 사용 사례로는 무엇이 있을까? 스트리밍을 구현하면 구체적으로 어떤 이점을 얻을 수 있을까? 데이터를 실시간으로 가져올 수 있다면, 배치 방식에 비해 개선될 수 있는 데이터에 대해 어떤 조치를 취할 수 있을까?

- 스트리밍 우선 접근 방식은 단순 배치 방식보다 시간, 비용, 유지 보수, 다운타임 및 기회비용 측면에서 더 많은 비용을 소비할까?

- 인프라에 장애가 발생했을 때 스트리밍 파이프라인과 시스템이 안정적이고 다중화되어 있는가?

- 사용 사례에 가장 적합한 도구는 무엇인가? 관리형 서비스(Amazon Kinesis, 구글 클라우드 Pub/Sub, Google Cloud Dataflow)를 사용해야 하는가? 아니면 카프카, 플링크, 스파크, 펄사 등의 인스턴스를 구축해야 할까? 후자를 선택한다면 누가 관리의 역할을 맡을 것인가? 비용과 트레이드오프는 무엇일까?

- ML 모델을 배포했을 때 온라인 예측 및 지속적인 훈련으로 얻을 수 있는 이점은 무엇일까?

- 실제 운영 인스턴스에서 데이터를 가져오는가? 그렇다면 이 원천 시스템에 대한 수집 프로세스의 영향도는 얼마나 될까?

 

푸시 vs 풀

푸시 모델에서의 원천 시스템은 데이터베이스, 객체 저장소 또는 파일 시스템과 관계없이 타깃에 데이터를 쓴다. 한편 풀 모델에서는 원천 시스템에서 데이터를 검색한다.

예를 들어 배치 지향 수집 워크플로에서 일반적으로 사용되는 추출-변환-적재 프로세스를 생각해보자. ETL의 추출 부분은 풀 수집 모델을 다루고 있음을 명확히 보여준다. ETL의 추출 부분은 풀 수집 모델을 다루고 있음을 명확히 보여준다. 수집 시스템이 정해진 일정에 따라 현재 소스 테이블의 스냅숏을 쿼리한다.

또다른 예로, 몇 가지 방법으로 달성되는 연속적인 CDC를 생각해보자. 일반적인 방법의 하나는 원천 데이터베이스에서 행이 변경될 때마다 메시지를 트리거하는 것이다. 이 메시지는 큐에 푸시되며, 수집 시스템이 해당 메시지를 가져간다. 또 다른 일반적인 CDC 방식은 데이터베이스에 대한 모든 커밋을 기록하는 바이너리 로그를 사용하는 것인데, 데이터베이스가 로그를 푸시한다. 수집 시스템은 로그를 읽지만, 그 외에는 데이터베이스와 직접 상호 작용하지 않는다. 배치 CDC의 일부 버전에서는 풀 패턴을 사용한다. 예를 들어 타임스탬프 기반 CDC에서는 수집 시스템이 원천 데이터베이스를 쿼리하고 이전 갱신 이후에 변경된 행을 가져온다.

데이터는 스트리밍 수집을 통해 백엔드 데이터베이스를 우회하여 이벤트 스트리밍 플랫폼의 데이터 버퍼 부분으로 들어간다. 이 패턴은 센서 데이터를 만들어내는 일련의 IoT 센서에 유용하다. 현재 상태를 유지하고자 데이터베이스에 의존하기보다는 기록된 각 판독치를 하나의 이벤트로 판단한다. 또한 이 패턴은 실시간 처리를 단순화하고, 앱 개발자가 다운스트림 분석에 맞게 메시지를 조정할 수 있으며, 데이터 엔지니어의 업무를 크게 간소화해 소프트웨어 애플리케이션에서도 인기가 높아지고 있다.

데이터 변환

 원래 형태에서 다운스트림 사용 사례에 유용한 형태로 변경하는 경우를 말한다. 적절한 변환을 거치지 않으면 데이터는 비활성 상태로 유지되며 보고서, 분석 또는 ML에 유용하지 않은 형식으로 남는다. 일반적으로 변환 단계는 데이터가 다운스트림 사용자의 데이터 소비를 위한 가치를 창출하기 시작하는 단계이다.

수집 직후에는 기본 변환을 통해 데이터를 올바른 유형으로 매핑하고, 레코드를 표준 형식으로 지정하고, 잘못된 유형을 제거한다. 변환 이후 단계에서는 데이터 스키마를 변환하고 정규화를 적용할 수 있다. 

[변환 단계에서의 주요 고려 사항]

- 변환에 드는 비용과 투자수익률은 얼마인가? 관련된 비즈니스 가치는 무엇인가?

- 변환은 가능한 한 단순하고 독립적인가?

- 변환이 지원하는 비즈니스 규칙은 무엇인가?

일반적으로 데이터는 원천 시스템에서 변환되거나 수집 중에 변환된다. 예를 들어 원천 시스템은 수집 프로세스에 전송하기 전에 이벤트 타임스탬프를 레코드에 추가할 수 있으며, 또는 스트리밍 파이프라인 내의 레코드가 데이터 웨어하우스로 전송되기 전에 추가 필드 및 계산을 통해 보강될 수 있다. 변환은 수명 주기의 여러 부분에서 흔히 볼 수 있는데, 데이터 준비, 데이터 랭글링, 데이터 정제와 같은 변환 작업은 데이터의 최종 소비자에게 가치를 더해준다.

논리적으로는 변환이 데이터 엔지니어링 수명 주기의 독립형 영역으로 취급될 수 있으나 수명 주기의 현실은 훨씬 복잡하다. 비즈니스 로직은 종종 데이터 모델링에서 데이터 변환의 주요 원인이다. 데이터는 비즈니스 로직을 재사용 가능한 요소로 변환한다. 예로, '판매'는 '누군가가 나에게서 12개의 사진 프레임을 개당 30달러, 총 360달러에 구입했다'는 의미이다.  데이터 모델링은 비즈니스 프로세스를 명확하고 최신화된 상태로 파악할 때 매우 중요하다. CFO가 재무 건전성을 명확하게 파악할 수 있도록 회계 규칙의 논리를 추가하지 않으면 원시 소매 거래에 대한 단순한 뷰는 유용하지 않을 수도 있다. 

또 다른 예로 ML의 데이터 특성화는 또 다른 데이터 변환 프로세스로 볼 수 있다. 특성화는 ML 모델 훈련에 유용한 데이터 특성을 추출하고 강화하려는 것이다. 특성화는 도메인 전문 지식과 데이터 과학의 광범위한 경험을 결합한 주술일 수 있다. 

* 일단 데이터 과학자가 데이터를 특징짓는 방법을 결정하면, 데이터 파이프라인의 변환 단계에서 데이터 엔지니어가 특성화 프로세스를 자동화할 수 있다는 것이다.

데이터 서빙

데이터를 수집하고 저장한 뒤에 일관성 있고 유용한 구조로 변환하여 데이터로부터 가치를 창출한다. 

- 분석 : 대부분의 데이터 작업 핵심으로, 데이터가 저장되고 변환되면 보고서 또는 대시보드를 생성하고 데이터에 대한 임시 분석을 수행할 수 있다. 

1. 비즈니스 인텔리전스

: 기업 경영의 과거와 현재 상태를 설명하기 위해 데이터를 수집한다. 데이터는 깔끔하지만 상당히 원시적인 형태로 저장되며, 후처리 비즈니스 로직은 최소화된다. BI 시스템은 비즈니스 로직과 정의에 대한 리포지터리를 유지 관리한다.

2. 운영 분석

: 운영의 상세 사항에 중점을 두고 보고서 사용자가 즉시 수행할 수 있는 작업을 촉진한다. 재고 물품에 대한 실시간 뷰 또는 웹사이트나 애플리케이션 상태에 대한 실시간 대시보드가 해당되며, 이 경우 데이터는 원천 시스템에서 직접 소비되거나 스트리밍 데이터 파이프라인에서 실시간으로 소비된다.

3. 임베디드 분석(고객 대면 분석)

: 보고서 요청 비율과 그에 따른 분석 시스템의 부담이 매우 커지며, 접근 제어 역시 훨씬 더 복잡해지고 중요해진다. 기업은 수천 명 이상의 고객에게 별도의 분석 및 데이터를 제공할 수 있고, 각 고객은 자신의 데이터만 확인할 수 있어야 한다. 기업 내부의 데이터 접근 오류는 절차적 검토로 이어질 수 있다. 또한 고객 간 데이터 유출은 중대한 신뢰 위반으로 고객 감소로 이어질 수 있다. 그렇기에 데이터 유출 및 보안 취약성과 관련한 피해 범위를 최소화해야 하며, 스토리지를 비롯 데이터 유출 가능성이 있는 모든 장소에서 테넌트 또는 데이터 수준의 보안을 적용한다.

* 멀티테넌시  : 많은 스토리지 및 분석 시스템은 다양한 방법으로 멀티테넌시를 지원한다. 데이터 엔지니어는 내부 분석 및 ML을 위한 통합된 뷰를 제공하기 위해 공통 테이블에 많은 고객 데이터를 저장할 수 있다. 적절하게 정의된 제어 및 필터가 있는 논리 뷰를 통해 개별 고객에게 외부적으로 제공된다. 데이터 엔지니어는 완벽한 데이터 보안과 분리를 보장하기 위해 배포하는 시스템에서 멀티테넌시의 세부 사항을 이해해야 한다.