Part 1. 들어가며

인공지능을 공부하다보면 필연적으로 마주치는 분야인 데이터 엔지니어링입니다.
항상 필요한 기능만 필요할 때 구글링하여 사용하다보니, 어느것보다 중요한 데이터이기에 체계적으로 학습하여 개념을 정립해 놓아야 할 필요성이 있다고 판단하였습니다.

따라서, 스마일게이트멤버십의 지원을 받아 패스트캠퍼스의 강의를 쭉 보며 간략하게 포스팅을 시작합니다.
강의이름은 "실시간 빅데이터 처리를 위한 Spark & Flink 올인원 패키지 Online."입니다.

 

CH01_01. 데이터 엔지니어링이란

데이터 엔지니어링의 목적 - 데이터 기반 의사결정을 위한 인프라 만들기

데이터 엔지니어링 SaaS의 폭발적인 성장으로, 큰 데이터 엔지니어를 푼 회사들이 많이 성장하였고, 투자도 많이 이루어지고 있음

데이터기반 의사결정이 중요한건 누구나 아는 사실입니다.

맥킨지에 의하면, Chief Data Officer를 고용한 기업이 다른 기업보다 이윤이 높다고 알려졌고 60%이상의 1000대 기업이 고용하고 있다고 합니다.

 

데이터 기반 의사결정의 사례)

1) 넷플릭스 컨텐츠 방문 80% 이상이 머신러닝 기반 추천에 의해 이루어지고 있음

2) bp에서 유정 센서 분석을 통해, 생산성을 22% 향상하며, 메탄 발생률을 74% 감소시켰다고함

3) Uber에서는 과거와 실시간 데이터를 이용하여, 수요와 공급을 예측을 통한 가격 조정으로 고객이 기다리는 시간(ETA)를 최소화

 

Garbage In, Garbage Out !!

 

 

CH01_02. 모던 데이터 엔지니어링 아키텍처

1. 과거의 데이터 관리 방식

1. 스키마를 미리 만들어두어, 데이터 웨어하우스를 구축하였음

2. 데이터 변동이 별로 없었음

3. 데이터베이스 모델링 과정이 중요했었음

 

이러한 일련의 파이프라인을 ETL이라고 불렀으며

1. 추출(Extract)

2. 스키마에 맞게 변환(Transform)

3. 데이터베이스에 적재(Load)

 

하지만 데이터로 할 수 있는 일이 다양해지고, 형태를 예측하기 힘들어지면서 스키마를 정의하기 힘들어졌습니다.

컴퓨팅파워도 많이 저렴해졌기 때문에, 많은 양의 데이터를 저장해두고 많은 양의 프로세스를 더할 수 있게 되었습니다.

일반회사에서도 컴퓨팅파워 -> 비즈니스, 속도를 최적화 하는것이 이득이 크게 되었습니다.

 

2. 현재 데이터의 운용 방식 : ETL -> ELT

 

3. 데이터 인프라 트렌드

- 클라우드로 많이 옮겨감 - Snowflake, Google Big Query

- Hadoop에서 Databricks, Presto와 같은 다음 세대로 이동하는 추세임

- 실시간 빅데이터 처리에 대한 수요도 증가하고 있음 (Stream Processing)

- ETL -> ELT

- 데이터 파이프라인이 복잡해지고, 의존성을 관리하기 힘들어지다 보니, 이런 Dataflow를 자동화하는 (Airflow)를 마낳이 사용하고 있음

- 데이터 분석팀을 두기보단, 누구나 분석할 수 있도록 툴들을 진화시키고 있음 (카카오 데이터 엔지니어 Service BI)

- 데이터 플랫폼들이 중앙화 되고 있음, access control이나 스키마들이 진화하고 있다함

 

데이터 생성에서 적용까지

데이터 엔지니어링에 쓰이는 도구들 나열

일반적인 엔지니어링으로 다뤄야하는 분야는 "데이터 수집 및 변환, 처리"에 집중되어 있습니다.

 

이 수업에서 앞으로 배울 분야를 간단하게 살펴보면

1. Spark와 데이터 분산-병렬 처리

2. Airflow와 데이터 오케스트레이션

3. Kafka와 이벤트 스트리밍

4. Flink와 분산 스트림 프로세싱

 

CH01_03. Batch & Stream Processing

배치 프로세싱 (Batch Processing) == 일괄 처리 - 전통적으로 쓰이는 데이터 처리방법

- 많은 양의 데이터를 정해진 시간에 한꺼번에 처리하는 것

 

언제 쓸까?

1. 실시간성을 보장하지 않아도 될 때

2. 데이터를 한꺼번에 처리할 수 있을 때

3. 무거운처리를 할 때 ex) ML학습

주기적인 일에 주로 쓰이는 배치프로세싱

 

스트림 프로세싱 (Stream Processing) == 실시간으로 쏟아지는 데이터를 계속 처리하는것 (이벤트가 생기거나, 데이터가 들어올때마다)

 

언제 쓸까?

1. 실시간성을 보장해야 할 때

2. 데이터가 여러 소스로부터 들어올때

3. 데이터가 가끔 들어오거나 지속적으로 들어올 때

4. 가벼운 처리를 할 때 (Rule-Based)

 

 

배치 vs 스트림

 

마이크로 배치란?

- 데이터를 조금씩 모아서 프로세싱하는 방식으로, 배치 프로세싱을 잘개 쪼개서 스트리밍을 흉내내는 방식 (Spark Streaming 방식) 

 

배치와 스트림을 적절히 섞은 예) 우버의 미켈란젤로 - 우버 내부에서 배달에 걸리는 시간을 예측하는데 사용됨

데이터를 관리할 때

- 온라인 : 실시간 데이터를 스트림 엔진을 통해 DB에 저장 (현재 배달에 걸리는 시간 예측)

- 오프라인 : 과거의 데이터를 한꺼번에 처리하는 배치 파이프라인을 통해 DB에 저장 (매주 수요와 공급을 예측)

- 머신러닝 학습은 무거운 프로세스이기 때문에 오프라인 배치 프로세싱으로 학습

- 학습된 머신러닝 모델은 다른 배치 프로세싱에서도 쓰일 수 있도록 배포

- 실시간 온라인 서비스에도 쓸 수 있도록 배포

- 실시간 모니터링 대시보드 : 실시간의 경우, 같은 시계열에서 사용되는 Feature와 Output을 같이 표시

 

CH01_04. Dataflow Orchestration

Orchestration이란? - 오케스트라처럼 데이터 테스크를 지휘하는 느낌

대표적인 툴 - Apache Airflow (대시보드를 통해 실시간 테스크 상태확인)

 

요즘 트렌드를 보면 필요한 이유를 알 수 있음

1. 서비스가 커지면서 데이터 플랫폼의 복잡도가 커짐

2. 데이터가 사용자와 직접 연관되는 경우가 늘어남 (워크플로우가 망가지면 서비스도 망가짐)

3. 테스크 하나하나가 중요해짐

4. 테스크간 의존성도 생김

 

없을 때, 업무 스케줄이나 우선순위간 혼선이 있거나, 실패 시나리오나 테스크 에러 후 로그 알람이 없으나

있다면, 테스크 에러 후 로그를 남기며 실패 시나리오에 따라 테스크를 성공할 수 있으며, 시간도 절약할 수 있음 

 

 

CH01_05. 데이터 엔지니어링 프로젝트 소개

우버 - 미켈란젤로 (쉽게 머신러닝 알고리즘을 학습하고 배포할 수 있는 플랫폼)

 

앞으로 만들것

- 배치 파이프라인과 스트림 파이프라인을 동시에 사용하는 : ML데이터 학습 + 서빙 파이프라인

 

배치 파이프라인

- 주기적으로 실행이 되는 부분은 Airflow Orchestration으로 관리

스트림 파이프라인

 

배치 + 스트림 프로세싱