견고한 데이터엔지니어링 #PART 1

 

 

이 책의 주요 목표 중 하나는 데이터 엔지니어로서 성공하는 데 필요한 지식과 기술의 기초를 제공하는 것이다

 

 

Chapter 1. 데이터 엔지니어링 상세

데이터 엔지니어링이란 무엇인가?

책에는 다양한 분들이 데이터 엔지니어링에 대해서 정의해주고 계셨다. 나는 Chatgpt에게도 물어봤다. GPT는 다음과 같이 답변했다.

 

"데이터 엔지니어링은 데이터 생애 주기의 모든 단계를 아우르는 포괄적인 분야로, 데이터의 수집, 저장, 처리, 관리 및 배포를 담당합니다."

 

나는 친구들이 "데이터 엔지니어가 뭐야?" 라고 하면 "데이터 쿠팡맨" 이라고 답변하곤 했다. 내가 생각하는 데이터 엔지니어는 그랬다. 사용자, 고객이 데이터를 사용할 수 있도록 가공시키는 일련의 과정, 흐름 그 전체라고 생각했다.

 

본 책에서는 이 전체 틀을 "데이터 엔지니어링 수명 주기" 와 이 개념에 포함 된 "드러나지 않는요소(undercurrent)로 나타내고 있었다.

 

---

 

데이터의 뿌리는 데이터 웨어하우징이다

1989년 Bill Inmon이 데이터 웨어하우스라는 용어를 공식적으로 만들었다. 이전에 내가 글을 한 번 작성한 적이 있다. 아래 글에서 데이터 웨어하우스의 두 아버지로 Bill Inmon과 Ralph Kimball이 있다고 했다.

 

Data Mart, Data Warehouse, Data Lake

 

 

1980-2000년:

IBM 엔지니어들을에 의해  RDB와 SQL을  가 개발되었고, Oracle은 이를 대중화 시켰다. 데이터 웨어하우징은 대량의 데이터를 처리하고 대규모 병렬 처리(MPP) DB로 확장성 있는 분석의 첫 시대를 열었다.  그리고, 90년대 중반 인터넷의 발달로 닷컴 열풍과 함께 웹 우선 기업의 탄생으로 웹 어플리케이션과 백엔드 시스템에서 엄첨난 활동을 만들어냈다.

 

2000년대 초:

닷컴 열풍이 90년대 후반에 무너졌다. 살아남은 기업들이 야후, 구글, 아마존같은 대형 기업이었다. 그러나 기존 시스템들은 한계에 달했고, 이 때마침 하드웨어도 저렴해졌고 대규모 컴퓨터 클러스터에서 분산 처리도 가능해졌다. 이와 함께 전통적인 모놀리식 서비스를 분산/분리했고 빅데이터의 시대가 시작되었다.

 

2003년 구글은 구글 파일 시스템 논문을 발표했다. 해당 논문은 대규모 분산 데이터 저장및 처리의 문제해결을 위한 접근 방식을 제시하는 논문이었다. 이 논문은 분산시스템 설계및 빅데이터 처리, 더 나아가 클라우드 스토리지 시스템까지 영향을 끼쳤다고 한다. 아래는 논문 링크이다.

 

The Google File System

 

 

 

2006년경, 야후는 Apache Hadoop을 개발했고, 아마존은 EC2 환경에서 S3,  NoSQL DB등 AWS를 통해 다양한 기술을 선보였다.

 

2000년대 후반, 2010년대 데이터 도구가 증가함에따라 빅데이터 엔지니어가 탄생했다. 하지만 오늘날에 와서는 '단순화'로 인해 빅데이터 엔지어는 그저 데이터 엔지니어다.

 

2020년대, 오케스트레이션 및 일반 데이터 수명 주기 관리와 같은 가치 사슬의 상위 영역에 역할이 더 집중되어갔다. 누가 더 큰데이터를 가지고 있는지보다, 가지고 있는 데이터를 어떻게 관리하고 품질을 향상 시킬지가 주요 관심사가 되었다.

 

많은 기업들이 이전과 달리 탈중앙화와 민첩성에 중점을 두고 다시 과거의 "기업화"로 돌아갔다. 기업화는 데이터 품질과 거버넌스를 포함하는 복잡하고 정교한 관리를 뜻한다.

 

---

 

데이터 엔지니어는 상상할 수 있는 모든 데이터 기술을 보유해야 하는 '유니콘' 으로 묘사되지만, 그렇지 않다.

 

A형 데이터 엔지니어와 B형 데이터 엔지니어

 

1. A(Abstraction:추상화)형 데이터 엔지니어는 아키텍처를 가능한 추상적이고 단순하게 유지해 시간낭비를 피한다. 또한, 기성형, 관리형 서비스와 도구로 데이터 엔지니어링 수명 주기를 관리한다.

 

2. B(Build:구축)형 데이터 엔지니어는 데이터 도구나 시스템을 구축한다. 

 

 

외부 대면 데이터 엔지니어와 내부 대면 데이터 엔지니어

 

1. 외부 대면 데이터 엔지니어는 APP,IOT 등과 같은 외부용 어플리케이션 사용자와 연계한다. 내부 대면 시스템보다 훨씬 큰 동시성 부하를 처리하는 경우가 많으므로, 엄격한 제한을 두는 것이 필요하다. 

 

2. 내부 대면 데이터 엔지니어는 비즈니스 밑 내부 이해관계자의 요구 사항에 중요 활동에 집중한다. 예를 들어 ML 모델용 데이터파이프라인 등

 

---

 

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

 

이 데이터를 신뢰해도 될까요?

 

 

데이터 엔지니어링 수명주기는 데이터 수명주기에 속하는 관계이다. 즉, 데이터 수명주기는 전체 데이터, 데이터 엔지니어가 제어하는 단계에 초점을 맞춘다. 아직까지는 사례 중심이다 보니 그냥 소설책 읽듯이 주르륵 읽게 된다.

 

데이터 접근 빈도에 따라 아래와 같이 구분이 가능하다.

    1. 핫 데이터(Hot Data)

    2. 미온적 데이터(Lukewarm Data)

    3. 콜드 데이터(Cold Data)

 

푸시(push) 와 풀(pull) 모델

    1. 푸시 모델: 원천시스템은 DB, 객체 저장소 또는 파일 시스템과 관계없이 타겟에 데이터를 쓴다.

    2. 풀 모델: 원천 시스템에서 데이터를 검색한다.

 

데이터 랭글링(warngling): 데이터 랭글링(Data Wrangling)이란, 원시(raw) 데이터를 정리하고 변환하여 분석에 적합한 형태로 만드는 과정

 

멀티테넌시(multitenancy): 멀티테넌시는 하나의 소프트웨어 인스턴스가 여러 독립된 사용자 그룹을 동시에 지원하는 방식으로, 비용 절감과 효율성 향상 등의 이점을 제공한다. 그러나 보안 및 성능 문제를 관리하는 데 주의가 필요

 

백필링(backfilling): 데이터베이스, 데이터 웨어하우스, 로그 시스템, 또는 기타 데이터 저장소에서 데이터가 누락되었거나 지연된 경우, 이러한 누락된 데이터를 나중에 채워넣는 과정을 의

 

역 ETL: 서빙까지 끝난 데이터를 다시 원천으로 넘기는 것 "WOW 이런 발상을 하다니"

 

드러나지 않는요소(Undercurrent): 보안, 데이터 관리, 데이터옵스, 데이터 아키텍처, 오케스트레이션, 소프트웨어 엔지니어링

 

메타데이터

    1. 기술 메타데이터: 데이터 엔지니어링 수명 주기 전반ㅇ ㅔ걸쳐 시스템이 생성하고 사용

    2. 파이프라인 메타데이터: 워크플로 일정등

    3. 스키마 메타데이터: DB관련 

    4. 운영 메타데이타: 운영결과를 설명

    5. 참조 메타데이터: 다른 데이터를 분류하는데 필요

 

데이터 품질은 "기대하는 것과 비교해 어떤 결과를 얻을 수 있을까?" 라는 질문을 중심으로 최적화 해야한다. 정확도, 완전성, 적시성 3가지 주요 특징으로 정의된다.

 

DODD( Data Obeservabiliy-Drive Development) :데이터 시스템의 가시성을 중심으로 설계 및 운영하는 접근 방식입니다. 이를 통해 데이터 시스템의 신뢰성, 품질, 효율성을 높이고, 문제 발생 시 신속하게 대응. 데이터 가시성은 모니터링, 알림, 루트 원인 분석, 자동화 등을 포함하여 데이터 시스템의 전반적인 상태를 개선하는 데 중점을 둠

 

오케스트레이션: 많은 작업이 예약된 순서대로 최대한 빠르고 효율적으로 실행되도록 조정하는 프로세스