반응형

사실 dbt는 정식 명칭이 “data build tool”인데, dbt Labs에서는 일부러 소문자 표기(db t)를 고수합니다.

 

이유 

1. 브랜딩 철학

  • dbt Labs는 “데이터팀을 위한 도구가 거창한 이름이 아니라, 가볍고 실용적인 툴”이라는 이미지를 주고 싶었습니다.
  • 그래서 일반적인 약자처럼 “DBT”라고 대문자로 쓰지 않고, 소문자 dbt라는 독특한 스타일을 선택했습니다.

 

2. 개발자 문화와 유사성

 

  • 리눅스 명령어나 Python 패키지 이름처럼, 소문자 CLI(command-line interface) 툴 스타일을 따랐습니다.
  • 실제로 설치 후 실행할 때도 dbt run, dbt test처럼 소문자 명령어를 입력합니다.

3. 공식 가이드라인

 

  • dbt Labs 공식 문서에서도 “항상 dbt라고 소문자로 작성할 것”을 권장합니다. 가이드

  • 대문자 DBT는 다른 의미(예: 심리치료에서 쓰이는 Dialectical Behavior Therapy)와 혼동될 수 있기 때문에 차별화 목적도 있습니다.

 

 

반응형
반응형
  • ETL ( Extract → Transform → Load )
    • 전통적 방식
    • 데이터를 원본에서 추출(Extract)중간 처리 서버에서 변환(Transform) → 최종적으로 데이터 웨어하우스에 적재(Load)
    • 데이터 웨어하우스의 연산 능력이 부족하던 시절에 주로 사용됨
    • [Source] → (Extract) → [ETL 서버에서 Transform] → (Load) → [Data Warehouse]
  • ELT ( Extract → Load → Transform )
    • 현대적 방식 (dbt가 여기에 해당)
    • 데이터를 원본에서 추출(Extract) → 그대로 데이터 웨어하우스에 적재(Load) → 웨어하우스 내부에서 SQL 기반 변환(Transform) 수행
    • Snowflake, BigQuery, Redshift, Databricks 등 강력한 클라우드 DWH가 등장하면서 표준이 됨
    • [Source] → (Extract + Load, Ingestion) → [Data Warehouse] → (Transform, dbt) → [Analytics-ready Data]
  • 요약
구분 ETL ELT (dbt 활용)
Transform 위치 ETL 서버(외부 처리 엔진) 데이터 웨어하우스 내부
데이터 적재 순서 변환 후 Load Load 후 변환
도구 예시 Informatica, Talend, Pentaho dbt, SQL, BigQuery/Snowflake/Redshift 내장 기능
장점 - 웨어하우스 부담 ↓- 보안·정책 제약 환경에서 유리 - 웨어하우스의 강력한 성능 활용- 단순 구조 (원시데이터와 정제데이터 모두 보관)- SQL만으로 개발 가능
단점 - 변환 서버 운영 필요- 확장성 낮음 - 웨어하우스 비용 증가 가능- 웨어하우스 의존도 ↑
사용 사례 과거 온프레미스 DWH 환경 최신 클라우드 DWH + dbt 파이프라인

 

반응형

+ Recent posts