바로 전에 apbot을 스케줄러에 올리는 작업을 통해 airflow에 입문을 했으니 이번에는 보다 여러 테스크가 들어간 DAG를 생성해보려고 한다.
apbot은 원래 airflow를 염두에 두고 만든 것은 아니었기 때문에 글 발행 스케줄 작업이 순조롭지만은 않았고, DAG도 단일테스크였다. 하지만 앱을 airflow를 통해 관리하게 될 때 어떤 문제가 생기고 어떤 식으로 관리하는 게 효율적인지 생각해볼 수 있고, DAG와 Airflow 설정을 들여다볼 수 있었다. 또한 곁들여서 GCP와 같은 SaaS와 오케스트레이션 툴인 쿠버네티스도 입문할 수 있었다. 쿠버네티스의 기술은 차차 공부해가야 하겠지만 사용법은 도커와 흡사해서 그나마 다행인 듯 하다.
GCP는 한번 사용하다보니 클라우드에서 제공하는 다양한 서비스들을 안 사용할 수 없게 잘 엮어놓은 듯 하다. 앗 이게 필요한데..하면 그럴줄 알았다는 듯이 나오는 기능들..;; 올인원 느낌? 모든 편의시설이 다 있는 리조트같은 느낌? 한번 사용하면 헤어나올 수 없는 트랩... 빠져있다 보면 과금이 뺨을 때리며 정신차리라고 말해주는 현실.;
어쨋든, 다시 파이프라인 작업으로 돌아와서. 이 작업은 일반 데이터를 가지고 만들 수도 있고, 내 프로젝트와 관련된 파이프라인을 만들 수도 있을 것 같다.
파이프라인 작업
1. ML 파이프라인: 학습용 이미지 데이터 수집 → 학습
개인이 모으는 데이터로는 큰 데이터를 못 모으고 복잡한 테스크는 꼬아서(?) 생각하지 않는 이상 만들 필요도 없는 것 같다고 생각된다. 현재 모아야 하는 개인 데이터는 이미지 데이터이다. 이 데이터를 모아서 object detection 모델 학습에 사용할 예정이다.
이 작업을 해보자 생각하게 된 이유는 기업들이 어떤식으로 airflow를 사용하는지 찾다가 유튜브에서 twitter 팀이 자신들은 airflow를 ML 파이프라인으로 사용하고 있다는 발표를 보았기 때문이다. (2020년도 영상이었던 것 같다.)
기능을 테스크로 잘 분리해서 만들어야 할 것 같다.
2. 구글의 빅데이터를 활용한 파이프라인
당장 큰 데이터를 구하는 건 구글에서 제공하는 퍼블릭?데이터를 사용하자.
여러 테이블에서 필요한 데이터를 추출 → 가공(클리닝 작업) + join → 분석시스템으로 보내기
내가 분석가라면 어떤 데이터를 요구하게 될까? 를 생각하면서 파이프라인을 작성해볼 수 있을 것 같다. 또한 정형데이터 추출에 익숙해질 수 있을 것이라 생각된다. 이런 저런 글들을 찾아보면 기업에서 빅쿼리를 많이 이용하는 것을 볼 수 있는데 빅쿼리도 SQL을 사용하니... NoSQL을 주로 사용하다보니 SQL 연습을 더 해야한다.
기업에서는 주로 시계열 데이터를 다루고 집계를 많이 할거라 생각이 돼서 집계와 테이블 조인을 통한 데이터 합치는 작업을 넣어보자.
구체적인 데이터에 대한 airflow 파이프라인 예시를 좀 더 찾아서 참고해보자.
밑은 데이터 파이프라인에 대해 찾으면서 용어와 개념을 정리했다.
SaaS (Software as a Service)
소프트웨어 클라우드 애플리케이션과 기본 IT 인프라 및 플랫폼을 사용자에게 제공하는 구독형 서비스
ETL과 ELT
참조:
ETL(extract, transform, load)
- 오랫동안 표준 데이터 통합 방법으로 사용되었다.
- 여러 소스들로부터 데이터를 추출하고 하나의 타겟 데이터베이스에 모으는 것
- Extract: SaaS, 온라인, on-premise(기업의 서버를 클라우드 같은 원격 환경에서 운영하는 방식이 아닌, 자체적으로 보유한 전산실 서버에 직접 설치해 운영하는 방식을 의미), 다른 데이터베이스 쿼리 등으로부터 데이터가 추출된다. 데이터는 스테이징 area로 옮겨진다.
- Transformation: 데이터는 클리닝 등의 전처리 등을 거쳐 일반적인 포맷으로 바뀐 후 지정된 data warehouse나 DB, Data lake 등등에 저장되어 BI 플랫폼을 이용한 분석에 사용된다.
- Loading: 포맷을 따르는 데이터는 타겟시스템에 로딩된다. 이 프로세스는 형식이 정해진 파일에 기록되고, DB에 스키마를 생성하거나 앱에서 새로운 오브젝트 타입을 만드는 작업을 수반한다.
ETL의 장점
- 자원 보존: ETL은 웨어하우스에 저당된 데이터의 볼륨을 줄여 기업이 비용에 예민하다면 저장소, 밴드위드, 컴퓨팅 자원을 아낄 수 있게 해준다.
- 법률준수: IP난 이메일 등의 민감한 데이터를 마스킹하거나 삭제해서 데이터 웨어하우스에 보낼 수 있다. 마스킹, 삭제, 특정 정보의 암호화를 통해 기업이 데이터 프라이버시 보호 규정(CCPA, HIPAA, GDPR) 등을 준수하게 도와준다.
- 잘 개발된 툴: ETL은 몇 십년간 존재했던 기술이어서 이를 위한 많은 플랫폼들이 있다. 따라서 환경세팅과 유지가 쉽다.
ETL의 단점
(트랜스포메이션을 정해놓고 한다는 것이 가장 큰 문제로 보인다.)
- 레거시 ETL은 느림: 전통적인 ETL 툴은 디스크기반 스테이징과 트랜스포메이션을 따른다.
- 지속적인 유지보수: ETL데이터 파이프라인은 추출과 변경 둘다를 핸들링한다. 만약 분석가가 다른 데이터 타입을 요구하거나 소스 시스템이 예상을 벗어나는 포맷과 스키마를 가지게 되면 계속 변경해야 한다.
- 높은 초기비용: 비즈니스 로직과 트랜스포메이션을 정의하는 것은 데이터 통합 프로젝트 범위를 넓게 만듦.
ETL 파이프라인의 현대화?
ETL 프로세싱은 스트리밍 데이터를 다루게 되면서 디스크기반 방식이 아닌 인메모리 방식과 멀티노드로 수평스케일업을 해서 훨씬 빠르고 더 큰 데이버볼륨을 다룰 수 있게 되었다. (카프카, 스파크 등을 사용)
ELT
(데이터를 타겟 시스템(가공 작업이 빠르고 편한?) 으로 보낼테니 입맛대로 가공해 써라의 느낌)
- 비즈니스 로직에 의한 데이터 변형작업없이 소스 시스템의 데이터를 타켓시스템으로 보내는 것을 말한다.
- Extract: 앱, Saas, DB 등의 다양한 소스에서 raw 데이터가 추출된다.
- Loading: 데이터는 일반적으로 프로세스에서 생성된(?) 데이터 타입 마이그레이션과 스키마와 함께 타겟시스템으로 바로 전달된다.
- Transformation: 타겟 플랫폼은 리포팅 목적에 따라 가공될 수 있다.
ELT의 부상?
클라우드 저장소와 분석 리소스가 좋아지면서 기업들은 정형화되지 않은 데이터를 쌓아둘 수 있게 되었다. ETL은 정형화된 데이터에 적합한 transformation 작업 때문에 이런 정형화되지 않는 다양한 데이터들을 다루기에 적합치 않다.
분석가들은 점점 더 snowflake 같은 데이터 가공과 조인에 특화된 모던 데이터 플랫폼을 사용하는 것을 고려하고 있다.
ELT 의 장점
- 빠른 추출과 로딩: 데이터는 최소의 가공만 거친 채로 타겟 시스템으로 보내진다
- 낮은 초기 개발 비용: ELT 툴은 일반적으로 최소의 수작업으로 타겟시스템에 데이터를 연결한다.
- 유연성: 분석가들은 어떤 인사이트와 데이터 타입을 가져와야 할지 미리 정하지 않아도 되고 필요에 따라 dw에서 불러다가 사용할 수 있다.
ELT의 단점
- 과일반화: 몇몇 ELT 툴들은 일반화된 데이터 운영 방식을 가지고 있다. 예를 들어 새로운 컬럼 이벤트에서 모든 테이블들을 재스캐닝, 오랫동안 유지되는 트랜잭션의 경우에 새로운 트랜잭션을 막는 것 등.
- 보안 문제: 모든 데이터를 보관하고 접근가능하게 하는 건 보안 리스크를 유발할 수 있다. 기업은 데이터를 마스킹하고 암호화해서 타겟 시스템의 보안을 보장해야 한다
- 규정위반 위험: raw 데이터를 다룰 때 개인정보 방침을 어기지 않게 주의를 기울여야 함
- 비즈니스 로직에 의한 트랜스포메이션의 가능성이 높으면 ELT는 오히려 작업을 느리게 만들 수 있다.
참조:
