[견고한] Chapter 2: 데이터 엔지니어링 수명 주기 + 데이터 아키텍쳐

※ 조 라이스와 맷 하우슬리가 공동으로 집필한 '견고한 데이터 엔지니어링'을 공부하면서, 중요한 내용들을 기록해둔 공간입니다. 데이터 엔지니어로써 중요하다고 생각되는 개념들에 대해 자체적으로 공부하며 정리한 글입니다.

 

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

 

기본적으로 "데이터 엔지니어링"이라는 분야 자체가 하는 일은, 데이터분석가 혹은 데이터 사이언티스트 등을 위시한 사내의 다른 소비계층이 활용할만한 데이터를 추출하고, 소비자의 입맛에 맞게 가공하고, 적재하여 서빙(넘겨주는 것)하기까지를 일컫는다.

 

그러니까 데이터 엔지니어링 수명 주기라 함은, 생성 - 추출 - 가공 - 적재 - 서빙의 다섯 단계를 기본적으로 지난다. 각 단계의 위치가 바뀔수도, 생략될 수도 있다. 실무에서는 이게 꼬이고, 반복되고, 겹치거나 혹은 예상 못한 방식으로 진행되는 일이 비일비재하다고 한다.

 

 

1 데이터 생성

 

원천 시스템 source system 은 데이터 엔지니어링 수명 주기에서 사용되는 데이터의 원본이다. 흔히 말하는 raw data를 뽑아오는, 데이터 수명 주기의 시발점이라도 봐도 무방하다. 실무에서는 이를 대개 두가지로 나눈다.

 

(1) 애플리케이션 데이터베이스

애플리케이션과 RDBMS가 결합된 형태의 소프트웨어를 원천으로 하고, 요새도 가장 높은 점유율을 가진 형태. 최근에는 monolithic이 아닌 microservice(MSA) 형태의 소프트웨어가 더 많아졌다.

- 대개 고정 스키마 fixed schema 방식을 활용한다.

 

(2) IoT swarm

수많은 IoT 장치들이 중앙에 위치한 메시지 큐를 향해 데이터 메시지를 송신하는 형태로, 메시지 큐는 각계각층의 장치에서 날아온 데이터를 잘 보관하는 형태로 데이터를 적재한다. 전형적인 DBMS로부터 벗어난, 최근에 보편화되는 형태.

- 대개 스키마리스 schemaless 방식을 활용한다. msg queue, flat file, blob, mongoDB 등과 같은 형태.

 

※ Source System을 평가하는 요소들

- 프로젝트를 앞두고 있으므로 해당 질문들을 눈여겨 보게 됐다. 책에서 선별한 질문들.

 

- 원천 시스템에서 데이터는 어떻게 유지되고, 얼마나 유지되는가?

- 데이터는 어느 정도의 속도로 생성되는가?

- 데이터 엔지니어는 출력 데이터에서 어느정도의 일관성을 기대할 수 있는가?

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

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

- 일부 데이터값이 다른 메시지보다 의미 있는 시간 차이를 가지고 늦게 도착할 수 있는가?

- 수집된 데이터의 스키마는 무엇인가?

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

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

 

 

2 데이터 저장

 

데이터를 저장하는 데에 있어서는, 회사의 관점에서는 이 스토리지 솔루션을 찾는 것이 매우 중요하다. 비단 저장만 하는 것이 아니라, 쿼리 변환 등의 기능도 수행하게 해주기 때문이다.

저장 부분은 특이하게, 나머지 단계들과 유기적으로 자리가 바뀌는 등 데이터 엔지니어링(파이프라인)의 여러 위치에서 발생한다.

따라서 데이터 웨어하우스, 레이크하우스, 데이터베이스, 객체 스토리지(순수 스토리지 솔루션)의 옵션 중 어느것을 선택하는지가 매우 중요한 것이다.

 

※ 스토리지 솔루션을 정할 때 고려할 사항

 

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

- 해당 스토리지 솔루션이 최적으로 작동하는 방식을 인지하고, 이를 구현할 수 있는 환경인가?

- 향후 예상되는 용량의 확장을 처리할 수 있는가?

- 스토리지 시스템이 스키마에 구애받는지 여부

 

데이터 접근 빈도에 따라서, cold, lukewarm, hot data의 세가지로 분류된다. 뒤로 갈수록 빈번히 액세스되는 데이터.

그에 맞게, 예를 들어 콜드는 보관료는 덜 들지만 접근 비용이 높은 저장소에 저장하는 등의 선택이 필요하다.

 

 

3 데이터 수집

 

데이터의 수집과 그 수집의 대상이 되는 원천 시스템은, 데이터 엔지니어링 수명 주기에서 가장 큰 병목현상을 나타낸다.

 

※ 수집 단계에서의 주요 엔지니어링 고려 사항

 

- 시스템이 이 데이터를 안정적으로 생성하고 수집하고 있는가?

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

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

- 원천 데이터는 어떤 형태, 어떤 상태이며, 이를 다운스트림에서 그대로 활용할 수 있는가?

 

이 단계에서 가장 중요한 것은, 배치 vs 스트리밍 과 푸시 vs 풀이라는 두 가지 주요 데이터 수집 개념을 파악하는 것.

 

 

배치 batch vs 스트리밍 streaming

 

기본적으로 우리가 다루는 대부분의 데이터는 스트리밍이다. 원천에서 지속적으로 생성되고 갱신된다. 이를 최대한 가공하지 않고 그 흐름 그대로 가져오는 것을 스트리밍이라고 한다면, 반대로 특정 시간적 기준이나, 용량적 기준에 따라 주기적으로 데이터를 가져오는 것을 배치 수집 batch ingestion이라고 한다.

 

스트리밍이라고 해서 정말 "실시간" 데이터만을 이야기 하는 것은 아니다. 상황이나 툴에 따라 다르겠지만 보통 수 초 정도까지의 간극을 가진 "실시간에 준하는" 데이터들을 스트리밍이라고 말한다.

 

당연히 데이터의 본질 그대로 스트리밍 데이터들을 활용하는 것이 좋다. 그러나 보통 업스트림 혹은 다운스트림의 병목 현상 등의 환경적 요인에 의해 제한받곤 한다. 그래서 스트리밍을 제한하여 배치 형태로 바꾸면서도, 다운스트림의 실수요자들에게 양질의 데이터를 전달할 수 있게끔 배치 수집 스타일링을 하는 것이 중요한 덕목이라고 할 수 있다.

 

그러니까 결국 기본적으로는 배치 스타일을 가되, 만약 스트리밍이 필요한 상황이고 환경 또한 따라준다면 스트리밍 방식을 가는 거라고 보면 되겠다.

 

 

푸시 push vs 풀 pull

 

push는 말 그대로, 데이터 원천이 우리(데이터 엔지니어 시스템)에게 데이터를 밀어주는 것이다. API 서버를 예로 들면, 데이터 제공자가 데이터를 실시간으로 데이터 시스템에 전달하는 방식으로, 데이터가 변경괴는 즉시 업데이트 가능하다는 장점이 있다. 반면, 서버와 클라이언트가 지속적인 연결을 해야 한다는 단점이 있으며, 우리 시스템이 원하지 않는 데이터도 전달될 가능성이 있다.

ex) 주식, 날씨 업데이트 등의 실시간 데이터 스트리밍. 

 

pull은 위와 반대로 생각하면 됨.

ex)  Restful API를 통해 데이터 수집.

 

 

4 데이터 변환

 

변환 transformation. 일반적으로 데이터가 다운스트림 사용자의 데이터 소비를 위한 가치를 창출하기 시작하는 단계.

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

앞서서 설명했듯, 실제 데이터는 스트림에 가깝지만 여러 이유로 배치 수집 형태를 많이 쓰고, 그렇기 때문에 배치형태의 데이터를 변환하는 연습이 주로 필요하다. 그러나 스트림 처리 솔루션의 인기가 높아지고 스트리밍 변환의 인기도 계속 높아지고 있다. 즉, 현재로써는 두 형태의 데이터 모두를 변환할 수 있어야 한다는 말씀!

데이터가 실용적 목적으로 쓰이기 위한 부분을 제외하고, 안 쓰이고 버려지는 부분 등을 우리는 데이터 허영 data vanity라고 부른다. 이 데이터 허영은 제거의 대상이다. 그러나 현재는 다듬어지지 않은 빅데이터 관련 기술적 이슈로 인해 많은 대기업에서 높은 수준의 데이터 허영을 함께 하고 있다.

 

 

데이터 아키텍쳐: 데이터 웨어하우스 vs 데이터 레이크

두 개 모두데이터를 저장하고 관리하는 데에 사용되지만, 사용 목적과 구조가 크게 다름.

 

데이터 웨어하우스

 

정제된 데이터를 구조화하여 저장하는 시스템으로, 주로 분석 및 보고에 사용함.

기업이 의사결정을 위해 데이터를 활용할 수 있도록 최적화된 데이터 저장소.

 

(1) 구조화된 데이터 즉, RDBMS에 저장되는 정형 데이터로, 스키마에 맞춰 정리되어야만 함.

(2) 데이터가 웨어하우스에 들어오기 전에 이미 변환되어 저장하는 ETL을 거침.

(3) 데이터를 빠르게 쿼리하여 BI 및 보고서 생성하는 데에 최적화되어 있음.

 

ex) 매출 분석, 고객 행동 분석, 트렌드 분석, 대시보드 생성, KPI 모니터링 등.

ex) Google BigQuery, snowflake 등

 

=> 이쯤되니, 데이터 웨어하우스는 그냥 엄청 큰 데이터베이스네? 라고 생각했는데, DB는 Online Transaction Processing, OLTP에 초점을 맞추는 반면 데이터 웨어하우스는 Online Analytical Processing OLAP 에 최적화 되어있다고 한다. 근데 어쨌든 난 큰 데이터베이스라고 생각함.

 

데이터 마트는 데이터 웨어하우스의 하위 집합으로, 특정 비즈니스 부서나 도메인을 위해 특화된 데이터 저장소다. 데이터 웨어하우스가 모든 데이터를 갖춘 중앙의 큰 그림이라면, 데이터 마트는 더 세분화된 목적에 맞춘 작은 그림임.

 

 

데이터 레이크

 

원시 데이터를 그대로 저장하는 시스템으로, 다양한 유형의 데이터를 raw 상태로 저장한다는 장점을 가짐.

 

(1) 정형, 반정형, 비정형 등의 데이터를 모두 저장 가능.

(2) 스토리지 비용이 저렴하다는 장점이 있음.

 

ex) 머신러닝, 빅데이터 분석, IoT 데이터 저장, 로그 파일 저장 등

ex) Hadoop, AWS S3 등