Part 1 - [Chapter 2] . 데이터 엔지니어링 수명 주기 (1)

짹짹

 

 

 

 

이 책의 주요 목표는 데이터 엔지니어링을
특정 데이터 기술의 집합으로 보는 관점에서 벗어나도록 장려하는 것이다 

 

 

기술적인 추상화가 확대됨에 따라 데이터 엔지니어는 점점 데이터 수명 주기 관리 원칙의 관점에서 사고하고 운영하는 

데이터 수명 주기 엔지니어가 될 것이다.

 

 

 

 

2장에서는 이 책의 중심 주제인 데이터 엔지니어링 수명 주기를 설명한다

데이터 엔지니어링수명 주기는 요람에서 무덤까지(즉, 그 생성부터 소멸까지) 데이터 엔지니어링을 설명하는 프레임워크다

 

 

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

데이터 엔지니어링 수명 주기는 원시 데이터 (raw data)의 요소를 분석가, 과학자, ML엔지니어 들이 사용할 수 있는 유용한 최종 제품으로 전환하는 단계로 구성된다. 2장에서는 데이터 엔지니어링 수명 주기의 주요 단계를 소개한다 

 

단계별 핵심 개념에 초점을 맞추어 설명하되, 자세한 내용은 이후에 살펴볼 것이다.

 

데이터 엔지니어링 수명 주기는 다음 5단계로 나눌 수 있다 

• 데이터 생성 
• 데이터 저장 
• 데이터 수집
• 데이터 변환 
• 데이터 서빙

데이터 엔지니어링 수명 주기는 원천 시스템에서 데이터를 가져와 저장하는 것에서 시작한다.

다음으로 데이터를 변환한 뒤 분석가, 데이터 과학자, ML엔지니어 등에게 데이터를 제공한다는 주요 목표를 향해 나아간다.

실제로 데이터 저장은 데이터가 처음부터 끝까지 흐르면서 수명 주기전체에 걸쳐 발생함 따라서 저장 단계가 다른 단계들을 뒷받침 하는 기반이 된다 

 

일반적으로 중간 단계인 저장, 수집, 변환 단계는 다소 뒤섞일 수 있지만 상관없다. 

데이터 엔지니어링 수명 주기의 각 부분을 뚜렷하게 분리하기는 했지만, 항상 깔끔하고 지속적인 흐름을 보이지는 않는다.

수명 주기의 여러 단계는 반복되거나, 순서가 어긋나거나, 겹치거나 흥미롭고 예상치 못한 방식으로 만들어질 수 있다.

 

 

기반이 되는 것은 데이터 엔지니어링 수명 주기의 여러 단계에 걸쳐 존재하는 드러나지 않는 요소 다 

보안, 데이터 관리, 데이터 옵스, 데이터 아키텍처, 오케스트레이션 및 소프트웨어 엔지니어링 등이 그에 해당한다 

 

 

이러한 요소 없이는 데이터 엔지니어링 수명 주기의 어떤 부분도 적잘하게 작동할 수 없다.

 

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

전체 데이터 수명 주기는 데이터의 전체 수명을 포괄하는 반면,

데이터 엔지니어링 수명 주기는 데이터 엔지니어가 제어하는 단계에 초점을 맞춤

 

 

 

 

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

원천 시스템(수집할 대상)은 데이터 엔지니어링 수명 주기에서 사용되는 데이터 원본이다.

예를 들어 원천 시스템은 IoT 장치, 어플리케이션 메시지 대기열 또는 트랜 잭선 데이터베이스일 수있다

 

 

데이터 엔지니어는 원천 시스템의 데이터를 소비하지만, 
일반적으로 원천 시스템 자체를 소유하거나 제어하지 않는다
데이터 엔지니어는 원천 시스템의 작동 방식, 데이터 생성 방식, 데이터 빈도 및 속도, 생성되는 데이터의 다양성을 실무적으로 이해해야 한다.

 

또한 엔지니어는 데이터 파이프라인과 분석을 중단할 수 있는 변경 사항에 대해 원천 시스템 소유자와 개방적인 소통 라인을 유지해야한다 

[이 말 또한 엔지니어는 단독적으로 일을 할 수 없고 협업이 굉장히 중요하다 이거는 1장에서 이미 말한바가 있다]

 

 

어플리케이션 코드가 필드의 데이터 구조를 변경하거나,
어플리케이션 팀이 백엔드를 완전히 새로운 데이터베이스 기술로 마이그레이션하는 경우도 있다

 

 

데이터 엔지니어링의 가장 큰 과제는 엔지니어가 작업하고 이해해야 하는 데이텅 원천 시스템의 방대한 배열이다.

 

 

원천 시스템 평가: 주요 엔지니어링 고려 사항

원천 시스템을 평가할 때는 시스템의 수집, 상태 및 데이터 생성을 처리하는 방법등 여러 가지 사항을 고려해야한다

• 데이터 원천의 본질적인 특정은 무엇인가? 데이터 원천은 어플리케이션인가? IoT 장치의 스웜인가?
  • 이거는 사실상 현 상황에 도메인에 따라 다르지 않을까 생각하게된다 
• 원천 시스템에서 데이터는 어떻게 유지되는가? 장기간 보존? 아니면 일시적이고 빠르게 삭제?
  • 사실상 DW를 유지하거나 과거 데이터를 쌓아서 분석에 용이하도록 하는가 회사마다 다르지 않을까 싶다 하지만 대부분의 회사가 클릭 이벤트를 제외하면 데이터를 쉽게 버리지 않고 괴거의 추이를 분석해 좀 더 나은 방향으로 회사를 움직이게 하는 것이 바람직하다고 생각하는 바 데이터를 쌓아둘 가능성이 매우 농후 하지 않나 생각이 된다 그렇다고 너무 오래된 데이터는 삭제하겠지만 회사 마다의 생명 주기를 테스트할 수 있을꺼같다 주기를 설정하고 
• 원천 시스템에서 데이터를 얼마나 자주 가져와야 하는가?
• 데이터 원천에서의 데이터 조회가 성능에 영향을 미친는가?
• 원천 시스템에 업스트림 데이터 의존 관계가 있는가? 이러한 업스트림 시스템의 특징은 무엇인가?
• 늦거나 누락된 데이터 확인용으로 데이터 품질 검사가 실시되고 있는가?

원천은 사람이 생성한 스프레드시트. IoT 센서, 웹앱, 모바일앱 등 다운스트림 시스템에서 사용되는 데이터를 생성한다

각 원천에는 고유한 데이터양과 데이터 생성 주기가 있다.

 

 

데이터 엔지니어는 원천으로부터 데이터를 생성하는 방법을 알아야한다
한 데이터 엔지니어는 상호 작용하는 원천 시스템의 한계를 이해해야 한다.

 

 

예를 들어 원천 어플리케이션 데이트베이스에 대한 분석 쿼리는 자원 경합 및 성능 문제를일으킬 수 있을까?

원천 데이터의 까다로운 차이점 중 하나는 스키마다 스키마는 데이터의 계층 구성을 정의한다.

 

논리적으로, 우리는 전체 원천 시스템 수준에서 데이터를 개별 테이블로 드릴다운해 각 필드의 구조에 이르기까지 생각할 수 있다.

 

드릴 다운(Drill down)은 
가장 요약된 레벨로부터 가장 상세한 레벨까지 차원의 계층에 따라 분석에 필요한 요약 수준을 바꿀 수 있는 기능

 

 

 

원천 시스템에서 제공하는 데이터의 스키마는다양한 방식으로 처리된다.

그중에서도 널리 쓰이는 두 가지 옵션은 스키마리스 방식과 고정스키마 방식이다 

 

 

스키마리스 방식은 스키마가 없다는 뜻은 아니다. 어플리케이션은 메시지 대기열, 플랫 파일, BLOB 또는 몽고DB와 가은 도큐먼트 데이터베이스에 데이터가 기록될때 스키마를 정의함

 

한편, 관계형 데이터베이스 스토리지를 기반으로 구축된 더 전통적인 모델은 데이터베이스에 적용된 고정 스키마 방식을 시용하는데 이러면 이 형식에 준수해야하는것이 맞는것이다 (Data warehouse 가 대표적일꺼같다 하지만 이것 또한 모놀리틱으로 구성되면 성능이 좋다고 얘기할 수 있을까?)

 

스키마는 시간이 지나면서 변화함, 실제로 스키마의 진화는 소프트웨어 개발에 대한 애자일 접근 방식에서 장려됨

 

데이터 엔지니어가 하는 일의 핵심으 원천 시스템 스키마에서 원시 데이터를 입력받고,
이를 분석에 유용한 출력으로 변환하는 것, 원천 스키마가 진화함에 따라 이러한 작업은 더욱 어려워짐