본문 바로가기
Data Science/DBT

ETL vs ELT, 왜 지금은 ELT를 선호하는가.

by 루크 Luke 2024. 8. 5.
반응형

 

개요

강사님이 어느 정도 ETL과 ELT가 익숙한 사람을 대상으로 강의를 해서 그런지, 자세한 설명은 이번에 건너 뛰신 것 같다. 추가적으로 ETL과 ELT를 구글링해보고 그 내용도 함께 실어봤다. (그냥 들어도 이해는 충분히 가는 내용이었지만, 이왕 공부하는거 좀 자세하게 알아보고 가면 좋을 것 같아서.)

 

ETL vs ELT

ETL (Extract, Transform, Load)과 ELT (Extract, Load, Transform)는 데이터 통합의 두 가지 주요 방법이다. 각각의 접근 방식은 데이터의 이동과 변환을 다르게 처리하며, 비즈니스 상황이나 자원에 따라 다르게 쓰인다고 한다.

1. ETL (Extract, Transform, Load)

  • 데이터 추출 → 변환 → 로드
  • 데이터를 별도의 처리 서버에서 변환한 후 데이터 웨어하우스에 최종 로드
  • 장점:
    • 복잡한 변환에 적합
    • 데이터 보안 및 규정 준수에 유리
  • 단점:
    • 느리고 확장성 부족
    • 실시간 데이터 처리에 부적합

2. ELT (Extract, Load, Transform)

  • 데이터 추출 → 로드 → 변환
  • 원시 데이터를 데이터 웨어하우스에 직접 로드한 후, 데이터 웨어하우스 내에서 변환을 수행
  • 장점:
    • 빠르고 확장성 있음
    • 구조화된 데이터와 비구조화된 데이터 모두 처리 가능
  • 단점:
    • 보안 및 규정 준수 측면에서 추가 보호 필요
    • 상대적으로 최신 기술로 문서화 및 경험이 부족

3. ETL과 ELT 비교

  • 변환 위치: ETL은 별도의 처리 서버에서, ELT는 데이터 웨어하우스 내에서 변환을 수행
  • 속도: ELT가 ETL보다 빠르며, 실시간 데이터 처리에 유리함
  • 데이터 보존: ELT는 원시 데이터를 데이터 웨어하우스에 저장하여 무제한 쿼리 가능, ETL은 변환된 데이터만 저장
  • 데이터 호환성: ELT는 데이터 레이크와 호환되며, ETL은 그렇지 않음

4. 선택 기준

  • ETL: 작은 데이터 집합, 복잡한 변환, 데이터 보안이 중요한 경우에 적합
  • ELT: 대량의 데이터, 실시간 처리 필요, 원시 데이터 보존 필요 시 적합

 

ELT가 가능해진 이유

ELT : Extract, Transform, Load

 

이제 데이터 성숙도 모델에 익숙해졌으니, ETL과 ELT 절차를 살펴보고 왜 ETL이 채택되어 널리 퍼지게 되었는지 살펴볼 수 있는 단계다. 1967년에 1MB 하드 드라이브의 가격은 100만 달러였다고 한다. (굉장히 비쌌다.) 그러다 보니, 저장 비용이 비쌀 때는 데이터베이스에 어떤 데이터를 저장할지를 신중하게 고려해야 했다. 당시 데이터 엔지니어들은 오늘날처럼 쉽게 확장하거나 축소할 수 없었기 때문에, 계산 제약이 있는 단일 노드 데이터베이스와 작업해야 했고, 온프레미스 자원은 영구 라이센스 비용 등으로 인해 비쌌다고 한다. 그래서 ETL이 더욱 적합했다고 할 수 있겠다.

 

저장과 계산 자원이 부족했기 때문에, 데이터베이스 외부의 스테이징 영역에서 변환을 수행하는 것이 완벽하게 합리적이었고, ETL이 널리 사용된 전통적인 접근 방식이 된 것이다. 데이터 추출(데이터 수집)을 먼저 하고, 그 다음에 데이터베이스 외부에서 변환을 하고, 마지막으로 해당 데이터베이스로 로드를 하는 방식.

 

하지만 이 접근 방식에는 몇 가지 문제가 있다. 예를 들면, 스키마가 변경되었을 때 모델이 깨지거나, 데이터 속도가 시간이 지남에 따라 변동하는 경우, 확장이 어려울 수 있다. 새로운 데이터 소스를 추가하는 것도 시간이 걸리고, 테스트와 디버깅의 어려움도 있다.

 

But, 요즘 저장 비용은 데이터 1GB당 2센트 정도. 그래서 전통적인 ETL 워크플로를 재구성하는 것이 논리적이다. 오늘날 계산과 저장 자원은 매우 저렴하기 때문에, 원시 데이터를 소스(Source)에서 직접 목적지로 로드하는 데 아무런 문제가 없다. Snowflake, Redshift, BigQuery 같은 데이터 웨어하우스는 매우 확장 가능하고 성능이 뛰어나므로, 외부 처리 계층 대신 데이터베이스 내에서 변환을 수행하는 것이 합리적인 판단이다.

 

전통적인 ETL 접근 방식에서는 로드와 추출 단계 사이에 변환이 이루어졌지만, 요즘은 FiveTran, Stitch와 같은 도구들이 소스 시스템에 연결하고 데이터를 목적지로 로드하는 작업을 몇 번의 클릭으로 할 수 있게 도와준다. 현대의 분석 데이터베이스와 클라우드 컴퓨팅 덕분에 ELT가 표준이 되었고, 작업 또한 훨씬 쉬워졌다고 볼 수 있다.

 

포스팅 자료 출처

본 포스팅은 유데미(Udemy) 사이트의 "The Complete dbt (Data Build Tool) Bootcamp: Zero to Hero" 강의의 내용을 발췌하여 작성했습니다. (광고 X)

반응형

댓글