📒 ETL

📌 ETL(Data pipeline)

• ETL : Extract, Transform, Load
• Data Pipeline, ETL, Data Workflow, DAG
  • ETL
  • Called DAG(Directed Acyclic Graph) in Airflow

📕 ETL vs. ELT

• ETL : 데이터를 데이터 웨어하우스 외부에서 내부로 가져오는 프로세스
  • 보통 데이터 엔지니어들이 수행함
• ELT : 데이터 웨어하우스 내부 데이터를 조작해서(보통은 좀 더 추상화되고 요약된) 새로운 데이터를 만드는 프로세스
  • 보통 데이터 분석가들이 많이 수행함
  • 데이터 레이크 이에서 이러한 작업들이 벌어지기도 한다.
  • 이런 프로세스 전용 기술들이 있으며 DBT가 가장 유명하다. : Analytics Engineering
    • DBT : Data Build Tool

📕 Data Lake vs. Data Warehouse

• Data Lake
  • 구조화 데이터 + 비구조화 데이터
  • 보존 기한이 없는 모든 데이터를 원래 형태대로 보존하는 스토리지에 가깝다.
  • 보통은 데이터 웨어하우스보다 몇배는 더 큰 스토리지
• Data Warehouse
  • 보존 기한이 있는 구조화된 데이터를 저장하고 처리하는 스토리지
  • 보통 BI툴들(룩커, 태블로, 수퍼셋...)은 데이터 웨어하우스를 백엔드로 사용한다.

📕 Data Pipeline의 정의

• 데이터를 소스로부터 목적지로 복사하는 작업
  • 이 작업은 보통 코딩(Python or Scalar) 혹은 SQL을 통해 이루어진다.
  • 대부분의 경우 목적지는 Data Warehouse가 된다.
• 데이터 소스의 예
  • Click stream, call data, ads performance data, transactions, sensor data...
  • More concrete examples : production datavases, log files, API, stream data(Kafka topic)
• 데이터 목적지의 예
  • Data Warehouse, cache System, Production Database, NoSQL, S3,...

---

📌 Data Pipline

📕 Raw Data ETL Jobs

1. 외부와 내부 데이터 소스에서 데이터를 읽기(많은 경우 API를 통하게 된다.)
2. 적당한 데이터 포맷 변환(데이터의 크기가 커지면 Spark등이 필요해진다.)
3. Load to Data Warehouse

-> 이 작업은 보통 데이터 엔지니어가 행한다.

📕 Summary/Report Jobs

1. DW(혹은 DL)로부터 데이터를 읽어 다시 DW에 쓰는 ETL
2. Raw Data를 읽어서 일종의 Report 형태나 Summary형태의 테이블을 다시 만드는 용도
3. 특수한 형태로는 AB테스트 결과를 분석하는 데이터 파이프라인도 존재한다.

요약 테이블의 경우 SQL(CTAS를 통해)만으로 만들고 이는 데이터 분석가가 하는것이 맞다.
데이터 엔지니어 관점에서는 어떻게 데이터 분석가들이 편하게 할 수 있는 환경을 만들어 주는냐가 관건이다.
-> Analytics Enginner(DBT)

📕 Production Data Jobs

1. DW로부터 데이터를 읽어 다른 Storage(많은 경우 프로덕션 환경)로 쓰는 ETL

• Summary 정보가 프로덕션 환경에서 성능 이유로 필요한 경우
• 혹은 ML Model에서 필요한 feature들을 미리 계산해두는 경우

2. 이 경우 흔한 타겟 스토리지

• Cassandra/HBase/DynamoDB와 같은 NoSQL
• MySQL과 같은 관계형 DB(OLTP)
• Redis/Memcache와 같은 cache
• ElasticSearch와 같은 검색엔진

---

📌 Data Pipline을 만들 때 고려할 점

📕 Best Practices (1)

• 가능하면 데이터가 작을 경우 매번 모두 복사해서 테이블을 만들기(Full Refresh)
• Incremental update만이 가능하다면, 대상 데이터소스가 갖추어야할 몇가지 조건이 있다.
  • 데이터 소스가 Production DB Table이라면 다음 필드가 필요하다.
    • Created(데이터 업데이트 관점에서 필요하지는 않다.)
    • Modeified
    • Deleted
      -> 데이터 소스가 API라면 특정 날짜를 기준으로 새로 생성되거나 업데이트된 레코드들을 읽어올 수 있어야한다.

📕 Best Practices (2)

• Idempotency(멱등성)을 보장하는 것이 중요하다.
  • 동일한 입력 데이터로 데이터 파이프라인을 다수 실행해도 최종 테이블의 내용이 달라지지 않아야 한다.
    -> 중복 데이터가 생기지 않아야함
  • 중요한 포인트는 Critical Point들이 모두 One Atomic Action으로 실행이 되어야 한다는 것이다.
  • SQL의 Transaction이 꼭 필요한 기술이다.

📕 Best Practices (3)

• 데이터 파이프라인의 입력과 출력을 명확히 하고 문서화 해야함
  • 비즈니스 오너 명시 : 누가 이 데이터를 요청했는지를 기록으로 남겨야 한다.
  • 데이터 카탈로그로 들어가서 데이터 디스커버리에 사용 가능하다.
    -> 데이터 리니지가 중요해진다. 이걸 이해하지 못하면 많은 종류의 사고가 발생한다.

📕 Best Practices (4)

• 주기적으로 불필요한 데이터들을 삭제한다.

📕 Best Practices (5)

• 데이터 파이프라인 사고시 마다 사고 리포트(post-mortem)쓰기
  • 목적은 동일한 혹은 아주 비슷한 사고가 또 발생하는 것을 막기 위함이다.

📕 Best Practices (6)

• 중요 데이터 파이프라인의 입력과 출력을 체크하기
  • 아주 간단하게 입력 레코드의 수와 출력 레코드의 수가 몇개인지 체크하는 것부터 시작
  • Summary Table을 만들어내고 Primary key가 존재한다면 Primary key uniqueness가 보장되는지 체크하는 것이 필요하다.
  • 중복 레코드 체크