한빛미디어

​

이 책은 데이터 공학, 즉 데이터 엔지니어링으로 나아가는 여정을 담고 있다. 이 책의 목표는 현재 데이터 엔지니어링 관련 내용과 자료의 공백의 메우는 것이다. 데이터 수명 주기의 시작 단계부터 최종 단계에 이르기까지 모든 단계를 살펴본다. 이 책의 주요 내용은 데이터 생성, 저장, 수집, 변환, 서빙 등을 다루는 데이터 엔지니어링 수명 주기다.

 

이 책의 구성

• 1부 : 데이터 엔지니어링 기반 구축하기

• 2부 : 데이터 엔지니어링 수명 주기 심층 분석

• 3부 : 보안, 개인정보보호 및 데이터 엔지니어링의 미래

• 부록 : 직렬화, 압축 및 클라우드 네트워킹

---

Part 1. 데이터 엔지니어링 기반 구축하기

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

데이터 엔지니어링을 어떻게 정의하냐는 여러 의견이 있겠지만, 이 책에서 정의한 내용은 아래와 같습니다. 데이터 엔지니어링은 원시 데이터를 가져와 분석 및 머신러닝과 같은 다운스트림 사용 사례를 지원하는, 고품질의 일관된 정보를 생성하는 시스템과 프로세스의 개발, 구현 및 유지관리이다. 데이터 엔지니어링은 보안, 데이터 관리, 데이터 운영, 데이터 아키텍처, 오케스트레이션, 소프트웨어 엔지니어링의 교차점이다. 데이터 엔지니어는 원천 시스템에서 데이터를 가져오는 것부터 시작해 분석 또는 머신러닝과 같은 사용 사례에 데이터를 제공하는 것으로 끝나는 데이터 엔지니어링 수명 주기를 관리한다.

 

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

• 데이터 생성

• 데이터 저장

• 데이터 수집

• 데이터 변환

• 데이터 서빙

 

데이터 엔지니어링 수명 주기는 전체 수명 주기에 걸쳐 중요한 아이디어인 드러나지 않는 요소라는 개념을 포함한다. 여기에는 보안, 데이터 관리, 데이터옵스, 데이터 아키텍처, 오케스트레이션, 소프트웨어 엔지니어링이 포함된다. 데이터 엔지니어링이 데이터 과학 및 분석과는 별개라고 가정한다. 이들은 서로 보완하지만, 분명히 다른 개념이다. 데이터 엔지니어링은 데이터 과학의 업스트림에 위치한다. 데이터 엔지니어는 데이터 과학자가 사용할 입력값을 제공하며, 데이터 과학자는 이렇게 입력된 값들을 유용한 결과로 변환한다는 의미다.

 

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

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

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

 

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

• 데이터 원천의 본질적 특징은? 데이터 원천은 애플리케이션인가?

• 원천 시스템에서 데이터는 어떻게 유지되는가? 데이터는 장기간 보존되는가?

• 데이터는 어느 정도 속도로 생성되는가? 초당 몇 개의 이벤트가 발생하는가?

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

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

 

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

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

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

• 이 스토리지 기술이 작동하는 방식을 인지하고 있는가?

• 이 스토리지 시스템은 향후 예상되는 확장을 처리할 수 있는가? …

 

수집단계 : 주요 엔지니어링 고려 사항

• 수집 중인 데이터의 사용 사례는 무엇인가? 여러 버전을 생성하는 대신 재사용이 가능한가?

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

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

• 데이터의 형식은 무엇인가? …

 

배치와 스트림 수집의 주요 고려 사항

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

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

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

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

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

 

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

• 변환에 드는 비용과 투자수익율(ROI)는 얼마인가? 관련된 비지니스 가치는 무엇인가?

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

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

 

데이터 엔지니어링의 드러나지 않는 주요 요소

• 보안 : 접근제어(데이터, 시스템)

• 데이터 관리 : 데이터 거버넌스, 데이터 모델링, 데이터 무결성

• 데이터옵스 : 데이터 거버넌스, 관찰 가능성과 모니터링, 데이터 무결성

• 데이터 아키텍처 : 데이터 분석 트래이드오프, 디자인과 민첩성, 비지니스에 가치 더하기

• 오케스트레이션 : 워크플로우 조정, 작업 스케줄링, 작업 관리

• 소프트웨어 엔지니어링 : 프로그래밍과 코딩 기술, 소프트웨어 디자인 패턴, 테스트와 디버깅

 

데이터 품질의 3가지 주요 특징

1. 정확도 : 수집된 데이터가 실제로 정확한가? 중복된 값이 있는가? 수치가 정확한가?

2. 완전성 : 기록은 완전한가? 모든 필수 필드에 유횻값이 포함되는가?

3. 적시성 : 기록을 시기 적절하게 이용할 수 있는가?

 

데이터옵스

데이터옵스(DataOps)는 애자일 방법론, 데브옵스, 통계적 공정관리의 모범 사례를 데이터에 매핑한다. 데브옵스의 목표는 소프트웨어의 릴리스와 품질을 개선하는 것이지만, 데이터옵스는 데이터 제품에 대해서도 같은 작업을 수행한다. 데이터옵스에는 자동화, 모니터링 및 관찰 가능성, 사고 대응 이라는 세 가지 핵심 기술 요소가 있다.

 

오케스트레이션

오케스트레이션은 많은 작업이 예약된 순서대로 최대한 빠르고 효율적으로 실행되도록 조정하는 프로세스다. 예를 들어 에어플로와 같은 오케스트레이션 도구를 스케줄러라고 부르는 경우가 많지만, 오케스트레이션 엔진은 일반적으로 유향 비순환 그래프(DAG)의 형태로 작업 종속성에 따라 메타데이터를 구축한다. DAG는 한번만 실행되거나 매일, 매주, 매시간, 5분 등 일정한 간격응로 실행되도록 스케줄링할 수 있다. 오케스트레이션 툴로는 에어플로, 프리펙트, 대그스터, 매타플로 등이 있다.

 

CHAPTER 3. 우수한 데이터 아키텍처 설계

우수한 데이터 아키텍처 원칙

1. 공통 컴포넌트를 현명하게 선택하라

2. 장애에 대비하라

3. 확장성을 위한 아키텍처를 설계하라

4. 아키텍처는 리더십이다

5. 항상 아키텍처에 충실하라

6. 느슨하게 결합된 시스템을 구축하라

7. 되돌릴 수 있는 의사결정을 하라

8. 보안 우선순위를 지정하라

9. 핀옵스를 수용하라

 

주요 아키텍처 개념

1. 도메인과 서비스 : 도메인은 실제 설계를 하는 주제 영역이다. 서비스는 작업 달성이 목적인 기능 집합이다.

2. 분산 시스템, 확장성, 장애에 대비한 설계

• 확장성 : 시스템 용량을 늘려 성능을 개선하고 수요를 처리할 수 있다. 예를 들어 시스템을 확장해 높은 속도의 쿼리를 처리하거나 대량의 데이터셋을 처리할 수 있다.

• 탄력성 : 확장성이 뛰어나 시스템을 동적으로 확장할 수 있다. 탄력성이 뛰어난 시스템은 현재 워크로드에 따라 자동으로 스케일 업과 스케일 다운이 수행할 수 있다.

• 가용성 : IT 서비스 또는 컴포넌트가 작동 가능한 상태에 있는 시간의 비율

• 신뢰성 : 시스템이 지정된 동안 의도한 기능을 수행할 때 정의된 표준을 충족할 가능성(확률)이다.

3. 강한 결합 VS 느슨한 결합, 모놀리스, 마이크로서비스

• 도메인과 서비스의 모든 부분은 다른 모든 도메인과 서비스에 필수적으로 의존한다. 이처럼 긴밀한 결합 패턴을 강한 결합이라고 한다. 이와 반대를 느슨한 결합이라고 한다.

• 모놀리스 내에서의 강한 결합은 기술 결합과 도메인 결합의 두가지 방식으로 살펴볼 수 있다. 기술 결합은 아키텍처 계층이, 도메인 결합은 도메인이 서로 결합하는 방식을 말한다.

• 마이크로서비스 아키텍처는 개별적이고 분산되어 있으며 느슨하게 결합된 서비스로 구성된다. 각 서비스는 특정 기능이 있으며 도메인 내에서 운영되는 다른 서비스와 분리된다. 한 서비스가 일시적 중단되더라도 다른 서비스의 기능에 영향을 주지 않는다.

4. 사용자 접근 : 싱글 VS 멀티테넌트

• 데이터 엔지니어는 여러 팀과 조직 및 고객에 시스템을 공유하는 것에 대한 결정을 내려야 한다. 어떤 의미에서는 모든 클라우드 서비스가 멀티테넌트지만, 이러한 멀티테넌트는 다양한 방식으로 발생한다. 멀티테넌시에는 성능과 보안이라는 두 가지 요소를 고려해야 한다.

5. 이벤트 기반 아키텍처

• 이벤트 기반 워크플로우는 이벤트 생성, 라우팅, 소비의 세 가지 주요 영역으로 요약된다. 이벤트 기반 아키텍처는 이벤트 중심 워크플로를 수용하고 이를 사용해 다양한 서비스 간에 통신한다. 이벤트 기반 아키텍처의 장점은 이벤트의 상태를 여러 서비스에 분산시킨다는 점이다. 이는 서비스가 오프라인 상태가 되거나, 분산 시스템에서 노드에 장애가 발생하거나, 여러 소비자 또는 서비스가 동일한 이벤트에 접근하도록 할 때 유용하다.

6. 브라운 필드 VS 그란필드 프로젝트

• 데이터 아키텍처 프로젝트를 설계하기 전에 백지상태에서 처음부터 시작하는지, 아니면 기존 아키텍처를 재설계하는지를 알아야 한다. 주로 브라운필드(기존 재설계)와 그린필드(신규) 두 유형이 있다.

 

데이터 아키텍처의 사례 및 유형

• 데이터 웨어하우스

• 데이터 레이크

• 융합, 차세대 데이터 레이크, 데이터 플랫폼

• 모던 데이터 스택

• 람다 아키텍처

• 카파 아키텍처

• 데이터 흐름 모델, 통합 배치, 스트리밍

• IoT용 아키텍처

• 데이터 메시

 

람다 아키텍처

• 람다 아키텍처에서는 배치, 스트리밍 및 서빙 등의 시스템이 서로 독립적으로 작동한다. 원천 시스템은 이상적으로 변경할 수 없고 추가만 가능하며, 데이터를 처리할 때는 스트림과 배치라는 두 목적지로 전송한다.

 

카파 아키텍처

• 람다 아키텍처의 단점에 대응책으로 카파 아키텍처라는 대안을 제시했고, 스트림 처리 플랫폼을 데이터 처리, 저장 및 서빙 등 모든 데이터 처리의 백본으로 사용하면 어떨까? 이를 통해 진정한 이벤트 기반 아키텍처를 실현할 수 있다. 실시간 이벤트 스트림을 직접 읽고 대량 데이터 청크를 재생해 일괄 처리함으로써 동일한 데이터에 실시간 및 배치 처리를 매끄럽게 적용할 수 있다.

 

데이터 메시

• 데이터 메시는 거대한 모놀리식 데이터 플랫폼과 운영 데이터와 분석 데이터 사이에 환경이 구분되는 ‘데이터 격차’에 대한 최근의 대응책이다. 데이터 메시는 도메인 기반 설계 개념을 채택해 데이터 아키텍처에 적용함으로써 중앙 집중식 데이터 아키텍처의 문제를 뒤집으려 한다. 데이터 메시의 핵심은 탈 중앙화다.

 

데이터 메시의 핵심 구성 요소

• 도메인 지향 분산형 데이터 소유권 및 아키텍처

• 제품으로서의 데이터

• 플랫폼으로서의 셀프서비스 데이터 인프라

• 통합 컴퓨팅 거버넌스

 

CHAPTER 4. 데이터 엔지니어링 수명 주기 전체에 걸친 기술 선택

• 팀의 규모와 능력

• 시장 출시 속도

• 상호 운용성

• 비용 최적화 및 비즈니스 가치

• 현재 vs 미래 : 불변의 기술과 일시적 기술 비교

• 장소 : 온프레미스, 클라우드, 하이브리드 클라우드, 멀티 클라우드

• 구축과 구매 비교

• 모놀리식과 모듈식 비교

• 서버리스와 서버 비교

• 최적화, 성능, 벤치마크 전쟁

• 데이터 엔지니어링 수명 주기의 드러나지 않는 요소

---

Part II. 데이터 엔지니어링 수명 주기 심층 분석

CHAPTER 5. 1단계 : 원천 시스템에서의 데이터 생성

데이터 엔지니어링 수명주기의 첫 번째 단계는 ‘원천 시스템에서 데이터 생성’이다. 데이터를 생성하는 시스템의 다양한 기본 운영 패턴을 학습할 때는 데이터가 어떻게 생성되는지를 이해해야 한다. 데이터는 사실과 수치의 비조직적이고 맥락 없는 집합이다. 데이터는 아날로그와 디지털 등 다양한 방법으로 생성될 수 있다. 원천 시스템은 다양한 방법으로 데이터를 생성한다.

 

원천시스템 : 주요 아이디어

1. 파일과 비정형 데이터 : 파일은 바이트의 시퀀스로, 일반적으로 디스크에 저장된다. 애플리케이션은 종종 파일에 데이터를 쓴다. 파일은 로컬 매개변수, 이벤트, 로그, 이미지 및 오디오를 저장할 수 있다. 파일은 정형, 반정형, 비정형 등이 있다.

2. API : 애플리케이션 프로그래밍 인터페이스(API)는 시스템 간에 데이터를 교환하는 표준 방식이다.

3. 애플리케이션 DB : 애플리케이션의 상태를 저장한다. 은행 계좌의 잔액을 저장하는 데이터베이스 등이 일반적인 예다. 고객 거래 및 결제가 발생하면 애플리케이션은 은행 계좌 잔액을 갱신한다. 일반적으로 애플리케이션 데이터베이스는 개별 데이터 레코드를 높은 속도로 읽고 쓰는 온라인 트랜잭션 처리(OLTP) 시스템이다. ACID는 데이터베이스의 중요한 특성 중 하나로 원자성, 일관성, 독립성, 내구성을 나타낸다. 원자적 트랜잭션은 단위로 커밋되는 여러 변경 사항의 집합이다.

4. 온라인 분석 처리(OLAP) 시스템 : OLTP와 달리 온라인 분석 처리 시스템은 대규모 분석 쿼리를 실행하도록 구축되어 있으며 일반적으로 개별 레코드의 조회 처리에는 비효율적이다.

5. 변경 데이터 캡쳐(CDC) : 데이터베이스에서 발생하는 각 변경 이벤트(입력, 갱신, 삭제)를 추출하는 방법이다. CDC는 데이터베이스 간에 거의 실시간으로 복제하거나 다운스트림 처리를 위한 이벤트 스트림을 생성하는데 자주 사용된다.

6. 로그 : 시스템에서 발생하는 이벤트에 대한 정보를 수집한다. 예를 들어 로그는 웹 서버의 트래픽과 사용 패턴을 수집할 수 있다. 모든 로그는 이벤트와 이벤트 메타데이터를 추적한다. 로그는 최소한 누가, 무엇을, 언제 수행했는지를 수집해야 한다.

7. 데이터베이스 로그 : 데이터베이스 서버는 데이터베이스 테이블에 대한 쓰기 및 갱신 요청을 수신하고, 각 작업을 로그에 저장한 후에 요청을 확인응답 한다. 데이터베이스 로그는 데이터 엔지니어링에 유용한데, 특히 CDC가 데이터베이스 변경에서 이벤트 스트림을 생성하는 데 매우 유용하다.

8. CRUD : 생성, 조회, 갱신, 삭제를 의미하는 CRUD는 프로그래밍에서 일반적으로 사용되는 트랜잭션 패턴으로, 영구 스토리지의 네 가지 기본적인 연산 작업을 나타탠다. CRUD는 애플리케이션의 상태를 데이터베이스에 저장하는 가장 일반적인 패턴이다.

9. 입력전용 : 데이터를 포함하는 테이블에서 이력을 직접 유지한다. 레코드를 갱신하는 대신, 새로운 레코드가 생성된 시점을 나타내는 타임스팸프와 함께 입력된다. CRUD 패턴을 사용할 때는 고객이 주소를 변경하면 레코드를 갱신하기만 하면 된다.

10. 메시지와 스트림 : 이벤트 기반 아키텍처와 관련해 메시지 큐와 스트리밍 플랫폼이라는 용어가 서로 혼용되는 경우를 볼 수 있는데, 두 용어 사이에는 미묘하지만 본질적인 차이점이 있다. 메시지는 둘 이상의 시스템 간에 전달되는 원시 데이터이다. 스트림은 이벤트 레코드의 추가 전용 로그다.

11. 시간 유형 : 이벤트 시간은 원본 이벤트 자체의 타임스탬프를 포함해 원천 시스템에서 이벤트가 생성된 시점을 나타낸다. 수집 시간은 원천 시스템에서 메시지 대기열, 캐시, 메모리, 객체 스토리지, 데이터베이스 또는 데이터가 저장된 다른 위치로 이벤트가 언제 수집되었는지를 나나탠다. 처리시간은 수집 시간 이후에 데이터가 처리될 때 발생한다.

 

원천 시스템의 실질적인 세부 사항

1. 데이터베이스 : 관계형 데이터베이스(RDBMS), 비관계형 데이터베이스(NoSQL) : key-value, document, graph, search, time series

2. API : REST, GraphQL, WebHook, RPC & gRPC

3. 데이터 공유

4. 서드파티 데이터 원천

5. 메시지 큐와 이벤트 스트리밍 플랫폼

 

드러나지 않는 요소가 원천 시스템에 미치는 영향

1. 보안

2. 데이터 관리 : 데이터 거버넌스, 데이터 품질, 스키마, 마스터 데이터 관리, 개인정보보호와 윤리, 규정

3. 데이터옵스 : 자동화, 관찰가능성, 사고 대응

4. 데이터 아키텍처 : 신뢰성, 내구성, 가용성, 사람

5. 오케스트레이션 : 주기와 빈도, 공통 프레임워크

6. 소프트웨어 엔지니어링 : 네트워크, 인증과 권한, 접근 패턴, 오케스트레이션, 병렬화, 배포

 

CHAPTER 6. 2단계 : 데이터 저장

데이터 저장은 데이터 엔지니어링 수명 주기의 토대로서 주요 단계인 수집, 변환 및 서빙의 기초가 된다. 데이터는 수명 주기를 거치는 동안 여러 번 저장된다.

 

데이터 스토리지의 기본 구성요소

1. 자기 디스크 드라이브 : HDD

2. SSD(Solid State Drive)

3. 임의 접근 메모리(RAM)

4. 네트워킹과 CPU

5. 직렬화

6. 압축

7. 캐싱

 

데이터 스토리지 시스템

1. 단일 머신 VS 분산 스토리지

2. 최종 일관성 VS 강력한 일관성

3. 파일 스토리지

4. 블록 스토리지

5. 객체 스토리지

6. 캐시 및 메모리 기반 스토리지 시스템

7. 하둡 분산 파일 시스템

8. 스트리밍 스토리지

9. 인덱스, 파티셔닝 및 클러스터링

 

데이터 엔지니어링 스토리지 개요

1. 데이터 웨어하우스

2. 데이터 레이크

3. 데이터 레이크하우스

4. 데이터 플랫폼

5. Stream-to-Batch 스토리지 아키텍처

 

스토리지의 주요 아이디어와 동향

1. 데이터 카탈로그

2. 데이터 공유

3. 스키마

4. 컴퓨팅과 스토리지의 분리

5. 데이터 스토리지 수명 주기 및 데이터 보존

6. 싱글테넌트 스토리지와 멀티테넌트 스토리지 비교

 

드러나지 않는 요소

1. 보안

2. 데이터 관리

3. 데이터 옵스

4. 데이터 아키텍처

5. 오케스트레이션

6. 소프트웨어 엔지니어링

 

CHAPTER 7. 3단계 : 데이터 수집

데이터 수집은 데이터를 한 장소에서 다른 장소로 옮기는 프로세스다. 데이터 엔지니어링 수명 주기에서는 원천 시스템에서 스토리지로 데이터가 이동하는 것으로, 수집은 중간 단계에서 이루어진다.

 

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

1. 유한 데이터 VS 무한 데이터

2. 빈도

3. 동기 수집 VS 비동기 수집

4. 직렬화와 역직렬화

5. 처리량과 확장성

6. 신뢰성과 내구성

7. 페이로드

8. 푸시 VS 풀 VS 풀링 패턴

 

배치 수집 고려사항

1. 스냅숏 또는 차등 추출

2. 파일 기반 익스포트 및 수집

3. ETL과 ELT

4. 입력, 갱신 및 배치 크기

5. 데이터 마이그레이션

 

메시지 및 스트림 수집에 관한 고려사항

1. 스키마의 진화

2. 늦게 도착하는 데이터

3. 주문 및 복수 전달

4. 재생

5. 유효 시간

6. 메시지 크기

7. 에러 처리와 데드레터 규

8. 소비자 풀 앤 푸시

9. 위치

 

데이터 수집 방법

1. 직접 데이터베이스 연결

2. 변경 데이터 캡쳐

3. API

4. 메시지 큐와 이벤트 스트리밍 플랫폼

5. 관리형 데이터 커넥터

6. 객체 스토리지로 데이터 이도

7. EDI

8. 데이터베이스와 파일 익스포트

9. 공통 파일 형식의 실질적 문제

10. 쉘

11. SSH

12. SFTP 및 SCP

13. 웹훅

14. 웹 인터페이스

15. 웹 스크레이핑

16. 데이터 마이그레이션용 전송 어플라이언스

17. 데이터 공유

 

드러나지 않는 요소

1. 보안

2. 데이터 관리

3. 데이터옵스

4. 오케스트레이션

5. 소프트웨어 엔지니어링

 

CHAPTER 8. 4단계 : 쿼리 모델링 및 데이터 변환

데이터 엔지니어링 수명 주기의 단계는 주로 데이터를 한 장소에서 다른 곳으로 전달하거나 저장하는 것이다. 쿼리, 모델링 및 변환을 이해하면 원시 데이터 구성 요소를 다운스트림 이해관게자가 사용할 수 있는 것으로 전환하는 도구를 얻을 수 있다.

 

쿼리

데이터 엔지니어링, 데이터 과학 및 분석의 기본적인 부분이다. 변환을 위한 기본 패턴과 기술을 알아보기 전에 쿼리가 무엇인지, 쿼리가 다양한 데이터에서 어떻게 작동하는지, 쿼리 성능을 개선하는 기술은 무엇인지 등을 이해해야 한다.

• 데이터 정의 언어(DDL) : CREATE, DROP, ALTER

• 데이터 조작 언어(DML) : SELECT, INSERT, UPDATE, DELETE, COPY, MERGE

• 데이터 제어 언어(DCL) : GRANT, DENY, REVOKE

• 트랜잭션 제어 언어(TCL) : COMMIT, ROLLBACK

 

데이터 모델링

데이터 모델링은 데이터의 일관성 있는 구조를 의도적으로 선택하는 작업이며, 데이터를 비지니스에 유용하게 만드는 중요한 단계이다. 데이터 모델은 데이터가 실제 세계와 연관되는 방식을 나타낸다. 데이터 모델은 조직의 프로세스, 정의, 워크플로 및 논리를 가장 잘 반영하기 위해 데이터가 어떻게 구조화되고 표준화되어야 하는지를 반영한다.

 

정규화는 데이터베이스 내 테이블과 열의 관계를 엄격하게 제어하는 데이터베이스 데이터 모델링 관행이다. 정규화의 목표는 데이터베이스에서 데이터 중복을 제거하고 참조 무결성을 보장하는 것이다.

• 비정규화 : 정규화되지 않음. 중첩 및 중복 데이터 허용

• 제1정규화(1NF) : 각 열은 고유하며 단일 값을 가진다. 테이블은 고유한 기본 키가 있다.

• 제2정규화(2NF) : 1NF의 요건과 일부 종속성이 제거된다.

• 제3정규화(3NF) : 2NF의 요건과 더불어 각 테이블에는 기본 키와 관련된 필드만 포함되며 전이 종속성은 없다.

 

드러나지 않는 요소

1. 보안

2. 데이터 관리

3. 데이터옵스

4. 데이터 아키텍처

5. 오케스트레이션

6. 소프트웨어 엔지니어링

 

 

CHAPTER 9. 5단계 : 분석, 머신러닝 및 역 ETL을 위한 데이터 서빙

데이터 엔지니어로서 접하게 될 세 가지 주요 사용 사례의 데이터를 서빙하는 다양한 방법을 설명한다. 첫째, 분석 및 BI용 데이터를 제공한다. 둘째, ML 애플리케이션의 데이터를 제공한다. 셋째, 역 ETL을 통해 데이터를 제공한다.

 

데이터 서빙의 일반적인 고려 사항

• 분석

• 머신러닝

• 데이터 엔지니어가 ML에 관해 알아야 할 사항

• 분석 및 ML을 위한 데이터 서빙 방법

• 역 ETL

 

드러나지 않는 요소

• 보안

• 데이터 관리

• 데이터옵스

• 데이터 아키텍처

• 오케스트레이션

• 소프트웨어 엔지니어링

---

Part III. 보안, 개인정보보호 및 데이터 엔지니어링의 미래

CHAPTER 10. 보안과 개인정보보호

1. 사람

2. 프로세스

3. 기술

 

CHAPTER 11. 데이터 엔지니어링의 미래

1. 사라지지 않는 데이터 엔지니어링 수명 주기

2. 복잡성의 감소와 사용하기 쉬운 데이터 도구의 부상

3. 클라우드 규모의 데이터 OS와 향상된 상호 운용성

4. 엔터프라이즈 데이터 엔지니어링

5. 직책과 책임의 변화

6. 모던 데이터 스택을 넘어 라이브 데이터 스택으로

 

이 책을 정독하면서 느낀 점은 데이터 엔지니어 역할을 위해서 알아야 하는 수많은 정보 중에 꼭 필요한 개념과 단계들을 일관된 스타일로 정리가 되어 있어서 내가 필요하는 시점에 찾아보기가 쉽게 되어 있다는 점이다. 특히 데이터 를 만들기 위해 필요한 생성, 저장, 수집, 변환, 서빙 단계별 주요 요소 및 드러나지 않는 정보까지 다 담겨 있어서 좋았습니다. 마지막 부분에 보안, 개인정보보호까지 최근 데이터 취급시 필히 알아야하는 부분도 담겨 있기 때문에 끝까지 포기하지 않고 읽기를 바랍니다.

 

한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다.

 

 



​