ACID
데이터베이스 트랜잭션이 안전하게 처리됨을 보장하는 4가지 속성(원자성·일관성·격리성·지속성)의 약자. 계좌 이체 시 출금과 입금이 반드시 함께 성공하거나 함께 실패하도록 보장하며, 트랜잭션 데이터베이스처럼 절대적 정확성이 필요할 때 중요하다.
Resources
Glossary
Data Engineering Glossary: 100+ Terms in Plain English (2026)
— docs/Data Engineering Glossary_ 100+ Terms in Plain English (2026).pdf
데이터 엔지니어링 실무에서 자주 쓰이는 143개 용어를 A부터 Z까지 정리한 용어집. ACID, CDC, ETL/ELT 같은 기본 개념부터 메달리온 아키텍처, 데이터 레이크하우스, 테이블 포맷(Iceberg/Delta), 스트림 처리, SCD 같은 아키텍처·모델링 패턴까지 실무 맥락과 함께 짧게 설명한다.
데이터베이스 트랜잭션이 안전하게 처리됨을 보장하는 4가지 속성(원자성·일관성·격리성·지속성)의 약자. 계좌 이체 시 출금과 입금이 반드시 함께 성공하거나 함께 실패하도록 보장하며, 트랜잭션 데이터베이스처럼 절대적 정확성이 필요할 때 중요하다.
정기 파이프라인의 일부가 아니라 특정 질문에 답하기 위해 즉석에서 작성하는 일회성 쿼리. 대부분의 데이터 웨어하우스는 정기 워크로드와 함께 이런 쿼리도 빠르게 처리하도록 설계된다.
여러 행을 SUM, COUNT, AVG, MIN, MAX 같은 요약값으로 합치는 연산. 대시보드의 '지역별 총매출' 같은 지표 뒤에는 항상 집계 로직이 있으며, 파이프라인 버그가 가장 많이 숨어있는 곳이기도 하다.
파이프라인을 코드(Python DAG)로 정의·스케줄링·모니터링하는 오픈소스 워크플로우 오케스트레이션 도구. 실행 시점 관리, 실패 시 재시도, 장애 알림을 담당하며 데이터 엔지니어링에서 가장 널리 쓰이는 도구 중 하나다.
실시간 데이터를 처리하는 분산 스트림 처리 프레임워크. 배치 엔진으로 출발해 스트리밍을 추가한 Spark와 달리 처음부터 스트리밍 전용으로 설계되었으며, 이상거래 탐지·실시간 추천·IoT 데이터 처리에 쓰인다.
Hadoop 위에서 HiveQL이라는 SQL 유사 언어로 대용량 데이터를 조회할 수 있게 해주는 데이터 웨어하우스 시스템. MapReduce를 직접 작성하지 않아도 되게 해줬지만, 지금은 일부 레거시 시스템에서만 주로 쓰인다.
대규모 분석 데이터셋을 위한 오픈 테이블 포맷. Parquet 같은 파일과 쿼리 엔진 사이에 위치해 스키마 진화, 타임 트래블, 파티션 진화 같은 기능을 더해주며 Delta Lake, Apache Hudi와 경쟁한다.
분산 이벤트 스트리밍 플랫폼으로, 프로듀서가 이벤트를 쓰고 컨슈머가 읽는 고처리량 메시지 버스 역할을 한다. 클릭스트림, 트랜잭션 로그, 센서 데이터처럼 초당 수백만 건의 이벤트를 시스템 간에 옮겨야 할 때 주로 쓰인다.
배치 처리, 스트림 처리, 머신러닝, SQL 쿼리를 모두 다루는 대규모 데이터 처리용 통합 분석 엔진. 데이터를 메모리에서 처리해 기존 Hadoop MapReduce보다 훨씬 빠르며, 오늘날 가장 수요가 많은 데이터 엔지니어링 기술 중 하나다.
Application Programming Interface의 약자. 데이터 엔지니어링에서는 Stripe 거래 내역, Salesforce 레코드, 날씨 데이터처럼 외부 시스템에서 데이터를 가져오는 통로로, 요청을 보내면 보통 JSON 형태의 구조화된 데이터를 응답으로 받는다.
모든 메시지가 한 번 이상 전달되지만 중복이 발생할 수 있는 메시징 보장 방식. exactly-once보다 구현이 단순해 대부분의 스트리밍 시스템이 기본값으로 채택하며, 이 방식을 쓰는 파이프라인은 중복 처리를 감당할 수 있어야 한다(멱등성과 연결된다).
수요에 따라 컴퓨팅 자원을 자동으로 늘리거나 줄이는 시스템 능력. 월말에 Spark 작업량이 10배로 늘면 실행기(executor)를 자동으로 늘리고, 작업이 끝나면 다시 줄여 유휴 자원에 대한 비용을 아낀다.
Kafka와 Hadoop에서 흔히 쓰이는 행(row) 기반 데이터 직렬화 포맷. 스키마를 데이터와 함께 저장해 시간에 따라 변하는 데이터에 적합하며, 압축적이고 직렬화가 빠르고 기존 컨슈머를 깨뜨리지 않고 필드를 추가할 수 있는 스키마 진화를 지원한다.
새로 만들었거나 최근에 고친 파이프라인에 과거 데이터를 다시 흘려보내는 작업. 월요일에 새 변환 로직을 배포했지만 1월분 데이터까지 소급 적용해야 한다면 그것이 백필이며, 소스 데이터 변경 가능성과 결과 중복 방지 때문에 생각보다 까다롭다.
다운스트림 시스템이 유입 데이터 속도를 따라가지 못할 때 발생하는 현상. 소방 호스를 정원용 호스에 연결한 것과 비슷하며, 스트리밍 시스템은 백프레셔 메커니즘으로 프로듀서 속도를 늦추거나 데이터를 버퍼링해 장애나 데이터 유실을 막는다.
한 건씩이 아니라 정해진 일정에 따라 큰 덩어리로 데이터를 처리하는 방식. 매시간·매일 밤·매주처럼 데이터를 모아 처리하며, 데이터 엔지니어링에서 가장 오래된 패턴이자 여전히 대부분의 워크로드에 적합한 선택이다.
Google Cloud의 완전관리형 서버리스 데이터 웨어하우스. 클러스터나 스토리지를 직접 관리할 필요 없이 SQL만 작성하면 되고 스캔한 양만큼 과금되며, 대규모 분석 쿼리에서의 단순함과 속도로 인기 있고 Snowflake, Redshift와 자주 비교된다.
파일, 이미지, 동영상, 로그, Parquet 파일 등 대용량 비정형 바이너리 객체를 위한 저장 서비스. Amazon S3, Azure Blob Storage, Google Cloud Storage가 대표적이며, 데이터 엔지니어링에서 데이터 레이크가 보통 자리잡는 곳이다.
메달리온 아키텍처의 첫 번째 레이어로 가공되지 않은 원본 데이터가 그대로 들어오는 곳. 정제·필터링·변환이 전혀 없는 소스 시스템의 충실한 복사본이며, 다운스트림에 문제가 생겨도 언제든 브론즈로 돌아가 재처리할 수 있는 안전망 역할을 한다.
데이터를 대시보드, 리포트, 인사이트로 바꾸는 실무. Tableau, Power BI, Looker, Metabase 같은 도구가 이 영역에 속하며, 데이터 엔지니어는 이런 BI 도구에 데이터를 공급하는 파이프라인과 모델을 구축한다.
마지막 추출 이후 변경된 데이터만 식별해 캡처하는 기법. 매번 테이블 전체를 가져오는 대신 삽입·수정·삭제만 감지해 하류로 보내므로 효율적이고 소스 시스템 부하를 줄이며 준실시간 파이프라인에 필수적이다. Debezium, AWS DMS, Fivetran이 대표적인 CDC 도구다.
특정 시점의 시스템 상태를 저장한 스냅샷. 스트림 처리에서 체크포인트는 장애 발생 시 처음부터 다시 시작하는 대신 마지막 저장 상태부터 데이터를 재생해 복구할 수 있게 해주며, Spark Structured Streaming과 Flink 모두 체크포인트에 크게 의존한다.
지속적 통합과 지속적 배포. 데이터 엔지니어링에서는 변경 사항이 푸시될 때마다 파이프라인 코드를 자동으로 테스트·배포하는 것을 의미하며, dbt 모델·Airflow DAG·Spark 작업도 애플리케이션 코드처럼 자동화된 검증을 거친 뒤 운영에 반영된다.
클라우드에서 호스팅·관리되는 데이터 웨어하우스. Snowflake, BigQuery, Redshift가 대표적이며 스토리지와 컴퓨트를 분리해 필요에 따라 확장하고 하드웨어 관리 없이 페타바이트급 데이터를 다룰 수 있다. 오늘날 대부분의 분석 쿼리가 이곳에서 실행된다.
함께 작동해 데이터를 처리하는 여러 대의 연결된 머신(노드) 그룹. Spark, Kafka, Hadoop은 모두 클러스터 위에서 동작하며, 단일 머신이 감당 못 하는 데이터량을 여러 대에 분산시켜 처리한다.
행이 아니라 컬럼 단위로 값을 묶어 저장하는 방식. Parquet 파일과 클라우드 웨어하우스에서 분석 쿼리가 빠른 이유가 바로 이것으로, 50개 컬럼 중 3개만 필요하면 엔진이 나머지 47개는 아예 건너뛴다.
많은 수의 작은 파일을 더 적고 큰 파일로 병합하는 과정. 작은 파일은 쿼리 계획·실행에 오버헤드를 더해 데이터 레이크 성능을 저해하는데, Delta Lake·Iceberg·Hudi 모두 자동 컴팩션을 지원해 이를 해결한다.
두 시스템 간 데이터 이동을 위한 사전 구축된 통합 모듈. Kafka Connect는 데이터베이스, 클라우드 서비스, 파일 시스템용 커넥터를 제공하며 Fivetran과 Airbyte는 사실상 커넥터 플랫폼이다. 커스텀 추출 코드를 짜는 대신 커넥터를 설정해 배관 작업을 맡길 수 있다.
코드와 그 의존성을 함께 묶어 어디서든 동일하게 실행되게 하는 경량 이식형 패키지. Docker가 표준이며, 데이터 엔지니어는 컨테이너로 Spark 작업, Airflow 워커, 커스텀 변환 스크립트를 환경 차이 걱정 없이 배포한다.
유닉스 계열 시스템의 시간 기반 작업 스케줄러. `0 2 * * *` 같은 CRON 표현식은 '매일 새벽 2시에 실행'을 의미하며, Airflow 등 복잡한 워크플로우용 오케스트레이터로 대체되고 있지만 스케줄링 설정 곳곳에서 여전히 흔히 쓰인다.
모든 흐름이 한 방향이고 순환이 없는 그래프. 데이터 엔지니어링에서는 파이프라인 워크플로우를 나타내며 작업 A 다음 B, B 다음 C가 실행되고 C가 다시 A로 돌아가지 않는다. Apache Airflow는 DAG을 파이프라인 정의의 핵심 추상화로 사용한다.
조직 내 모든 데이터 자산을 검색 가능하게 정리한 목록. 어떤 데이터가 있고, 어디에 있으며, 누가 소유하고, 무엇을 의미하는지 알려주는 일종의 도서관 카탈로그다. AWS Glue Data Catalog, Apache Atlas, DataHub가 이 역할을 한다.
데이터를 주고받는 생산자와 소비자 사이에 구조·포맷·품질에 대해 맺는 공식 합의. 데이터 파이프라인용 API 명세와 비슷하며, 업스트림 팀이 예고 없이 컬럼 타입을 바꾸면 계약 위반이 발생하고 이상적으로는 자동화된 검증이 문제가 커지기 전에 이를 잡아낸다.
시간이 지나며 유입 데이터의 통계적 속성이나 스키마가 예상과 다르게 바뀌는 현상. 소스 시스템이 갑자기 널 값을 보내기 시작하거나 필드의 분포가 바뀔 수 있으며, 아무도 감시하지 않으면 모델과 리포트를 조용히 망가뜨릴 수 있다.
조직 전반에서 데이터가 제대로 관리되도록 보장하는 정책·표준·프로세스의 집합. 누가 어떤 데이터에 접근할 수 있는지, 품질을 어떻게 유지하는지, 민감 데이터를 어떻게 다루는지, 데이터가 시스템 사이를 어떻게 이동하는지를 다루며 관료적으로 들리지만 없으면 금방 무너진다.
구조화·반구조화·비구조화 데이터를 원본 그대로 담는 중앙집중식 저장 시스템. 데이터 웨어하우스와 달리 적재 전에 스키마를 정의할 필요가 없어 저렴하고 유연하며 대용량을 저장할 수 있지만, 제대로 관리하지 않으면 '데이터 스웜프'가 된다.
데이터 레이크의 유연함과 데이터 웨어하우스의 성능·신뢰성을 결합한 아키텍처. Parquet 같은 오픈 파일 포맷을 저렴한 오브젝트 스토리지에 저장하되 Delta Lake나 Apache Iceberg 같은 테이블 포맷으로 ACID 트랜잭션, 스키마 강제, 타임 트래블 기능을 얹으며, 업계 표준으로 자리잡은 '두 세계의 장점' 접근이다.
데이터가 어디서 왔고 어떻게 변환되었으며 어디로 갔는지 추적하는 능력. 대시보드의 숫자가 이상해 보이면 리니지를 통해 모든 변환을 거슬러 올라가 원본 소스까지 추적할 수 있으며, 디버깅·컴플라이언스·데이터 신뢰 구축에 필수적이다.
특정 팀이나 업무를 위해 설계된 데이터 웨어하우스의 더 작고 초점이 맞춰진 부분집합. 마케팅팀은 캠페인·전환 데이터를 담은 데이터 마트를, 재무팀은 매출·비용 데이터를 담은 마트를 가질 수 있으며 각 팀에 필요한 것만 제공해 접근을 단순화한다.
데이터 소유권을 분산시키는 조직적 접근 방식. 하나의 중앙 데이터팀이 모든 것을 소유하는 대신 영업·마케팅·제품 같은 각 도메인 팀이 자신의 데이터 제품을 소유하고 발행하며, 강력한 데이터 계약과 셀프서비스 인프라가 뒷받침되어야 한다. 기술보다 사람과 프로세스에 관한 것에 가깝다.
운영 중인 데이터 파이프라인의 상태와 품질을 모니터링하는 것. 단순히 작업 성공 여부를 확인하는 데 그치지 않고 데이터 신선도, 볼륨, 스키마 변경, 분포 이상을 추적하며 데이터 버전의 애플리케이션 모니터링이라 할 수 있다. Monte Carlo, Bigeye, Great Expectations가 이 영역의 도구다.
데이터를 한 곳에서 다른 곳으로 옮기는 일련의 단계로, 보통 추출·변환·적재를 포함한다. CSV 파일을 데이터베이스로 복사하는 단순한 스크립트일 수도, Airflow가 오케스트레이션하는 수십 개 작업으로 이루어진 복잡한 시스템일 수도 있다. 자동화된 데이터 흐름은 대체로 파이프라인이라 부른다.
데이터가 얼마나 정확하고 완전하며 일관되고 시의적절한지를 뜻한다. 데이터 품질이 나쁘면 잘못된 리포트, 고장난 대시보드, 신뢰 붕괴로 이어지며 데이터 엔지니어는 널 체크, 유일성 제약, 신선도 모니터, 값 범위 검증 같은 품질 체크를 파이프라인에 내장한다.
서로 다른 팀이나 부서가 데이터를 서로 소통하지 않는 격리된 시스템에 저장하는 현상. 영업 데이터는 Salesforce에, 마케팅 데이터는 HubSpot에, 제품 데이터는 Postgres에 있어 아무도 통합된 시야를 갖지 못하며, 사일로를 허무는 것이 데이터 엔지니어링 팀이 존재하는 주된 이유 중 하나다.
잘 관리되지 못한 데이터 레이크가 변한 모습. 문서화나 명명 규칙, 품질 관리 없이 데이터가 그냥 쌓이면 아무도 무엇이 있는지 모르고 아무도 찾은 것을 신뢰하지 못하는, 방치된 데이터셋의 무덤이 된다. 해결책은 거버넌스, 카탈로그, 명확한 소유권이다.
분석 쿼리에 최적화된 중앙집중식 구조화 저장 시스템. 개별 레코드의 빠른 읽기·쓰기를 위해 설계된 운영 데이터베이스와 달리 웨어하우스는 수백만 행에 걸친 무거운 집계 연산을 위해 설계되며, Snowflake·BigQuery·Redshift가 오늘날 주요 클라우드 데이터 웨어하우스다.
데이터 팀이 SQL로 변환 로직을 작성하고 버전 관리·테스트·문서화 등 소프트웨어처럼 관리할 수 있게 해주는 오픈소스 도구. 웨어하우스 내부에서 동작하며, SELECT문을 작성하면 dbt가 테이블·뷰 생성을 처리해주고 테스트되고 문서화된 변환 레이어를 얻게 된다. ELT의 'T'를 담당하는 사실상 표준이다.
정상 처리되지 못한 메시지나 레코드를 위한 보관 영역. 데이터를 잃어버리거나 파이프라인을 막는 대신 실패한 레코드를 DLQ로 보내 나중에 점검·재처리할 수 있게 하며, Kafka, SQS 등 메시징 시스템에서 흔히 쓰인다.
데이터셋에서 중복 레코드를 제거하는 작업. 간단해 보이지만 타임스탬프가 조금씩 다른 세 개의 사본 중 어느 것이 '맞는' 레코드인지 정하는 문제가 얽혀 있어 까다로우며, 비즈니스 규칙에 크게 의존하고 멱등성과도 밀접하게 연결된다.
Databricks의 오픈소스 스토리지 레이어로, 데이터 레이크에 ACID 트랜잭션, 스키마 강제, 타임 트래블을 더해준다. Parquet 파일 위에 자리잡고 모든 변경을 추적하는 트랜잭션 로그를 추가하며, Databricks를 쓴다면 기본 테이블 포맷이다.
테이블을 합치거나 데이터를 중복시켜 읽기 쿼리 속도를 높이는, 의도적으로 중복성을 더하는 기법. 정규화된 데이터베이스에서는 결과를 얻기 위해 5개 테이블을 조인해야 하지만 비정규화된 곳에서는 필요한 데이터가 이미 한 곳에 있다. 분석 데이터베이스와 웨어하우스는 성능을 위해 거의 항상 비정규화되어 있다.
스타 스키마에서 고객명, 제품 카테고리, 지역, 날짜 같은 서술적 속성을 저장하는 테이블. 팩트 테이블의 숫자에 맥락을 부여하며, '지역·분기별 매출' 리포트에서 지역과 분기는 디멘션 테이블에서 온다.
여러 대의 머신이 서로 협력하며 처리를 분담하는 시스템. Spark, Kafka, Hadoop 등 대부분의 현대 데이터 도구가 분산 시스템이며, 장점은 규모(단일 머신이 못 다루는 데이터량 처리)지만 머신 장애, 네트워크 분단, 조정의 어려움이라는 복잡성이 따른다.
컨테이너를 만들고 실행하는 플랫폼. 데이터 엔지니어링에서는 파이프라인 코드, 라이브러리, 설정을 이식 가능한 이미지로 묶어 노트북, CI 서버, Kubernetes 클러스터에서 동일하게 실행되게 해주며, '내 컴퓨터에서는 되는데' 문제를 해결해준다.
원본 데이터를 먼저 웨어하우스에 적재한 뒤 SQL로 변환하는 데이터 통합 패턴. ETL과의 핵심 차이는 변환이 적재 전이 아니라 웨어하우스 내부에서 일어난다는 점이며, 클라우드 웨어하우스로 스토리지가 저렴해지고 컴퓨트가 확장 가능해지면서 실용적이 되었다. dbt가 ELT 변환 레이어의 대표주자다.
고전적인 데이터 통합 패턴. 소스에서 데이터를 뽑아 정제·재구성한 뒤 웨어하우스에 적재하며, 스토리지가 비쌌던 시절 웨어하우스에는 정제된 데이터만 넣고 싶었기에 수십 년간 지배적이었다. 적재 전에 데이터를 정제하거나 마스킹해야 할 때 여전히 옳은 패턴이다.
시스템들이 직접 API 호출 대신 이벤트를 발행·구독하며 소통하는 설계 패턴. 사용자가 주문을 하면 'order_placed' 이벤트가 발행되고, 재고·결제·알림 같은 다운스트림 시스템이 각자 독립적으로 이 이벤트를 소비한다. Kafka가 이벤트 기반 데이터 아키텍처의 가장 흔한 백본이다.
메시징 보장 방식 중 최고봉으로, 모든 메시지가 정확히 한 번만 처리되어 중복도 유실도 없다. 분산 시스템에서 달성하기 극히 어려우며, Kafka는 자체 생태계 내에서 exactly-once 시맨틱을 지원하지만 여러 시스템을 아우르는 종단 간 exactly-once는 보통 신중한 멱등적 설계가 필요하다.
데이터 파이프라인의 첫 단계로, 소스 시스템에서 데이터를 꺼내오는 것. 소스는 데이터베이스, API, 파일, 메시지 큐, 심지어 웹 스크래핑일 수도 있으며, 목표는 소스 시스템을 망가뜨리거나 도중에 레코드를 잃지 않고 안정적으로 데이터를 뽑아내는 것이다.
스타 스키마의 중심 테이블로 매출액, 클릭 수, 주문량, 거래액 같은 정량적·측정 가능한 데이터를 저장한다. 보통 수백만~수십억 행에 이르며 외래키를 통해 디멘션 테이블과 연결된다. '팩트 테이블을 만든다'는 것은 비즈니스가 관심 있는 숫자를 담을 테이블을 만든다는 뜻이다.
노드가 죽거나 네트워크가 끊기거나 디스크가 가득 차는 등 문제가 생겨도 시스템이 계속 동작할 수 있는 능력. 좋은 데이터 시스템은 복제, 체크포인트, 자동 재시도를 통해 장애를 우아하게 처리하도록 설계되며, 머신 하나가 흔들릴 때마다 파이프라인이 깨진다면 장애 허용성이 없는 것이다.
파일에 데이터를 저장하는 구조. 데이터 엔지니어링에서 주로 쓰이는 것은 분석에 좋은 컬럼형 Parquet, 스트리밍에 좋은 행 기반 Avro, Hive 생태계에서 흔한 컬럼형 ORC, 사람이 읽기 쉽지만 느린 CSV, 유연하지만 장황한 JSON이며, 포맷 선택은 쿼리 성능과 저장 비용에 직결된다.
다른 테이블의 기본키를 참조하는 한 테이블의 컬럼. 스타 스키마에서 팩트 테이블은 외래키로 디멘션 테이블과 연결되며, 매출 팩트 테이블의 'order_id'가 주문 디멘션 테이블의 'id' 컬럼을 가리키는 식으로 관계형 데이터의 연결을 유지한다.
변경 여부와 상관없이 매번 소스 테이블 전체를 추출·적재하는 방식. 단순하고 안정적이지만 실제로 바뀐 행의 비율이 낮은 대용량 테이블에는 낭비가 크며, 작은 참조 테이블이나 CDC를 쓸 수 없는 경우에 흔히 쓰인다.
메달리온 아키텍처의 최종 비즈니스 준비 레이어. 데이터가 정제·집계·모델링되어 대시보드, 리포트, 머신러닝에 바로 쓸 수 있는 상태이며, 비즈니스 로직을 반영해 최종 사용자가 실제로 소비하는 '서빙' 레이어라 할 수 있다.
행과 열 대신 노드(개체)와 엣지(관계)로 데이터를 저장하는 데이터베이스. 소셜 네트워크, 사기 조직, 추천 엔진처럼 개체 자체보다 개체 간 관계가 더 중요한 데이터를 모델링하는 데 유용하며, Neo4j가 가장 잘 알려진 그래프 데이터베이스다.
데이터 검증, 문서화, 프로파일링을 위한 오픈소스 Python 라이브러리. '이 컬럼은 널이면 안 된다', '이 값은 항상 양수여야 한다', '이 테이블은 1,000~10,000행이어야 한다' 같은 '기대치(expectations)'를 정의하면 파이프라인의 일부로 자동 검증해준다.
대용량 데이터셋의 분산 저장과 처리를 위한 오픈소스 프레임워크로, 저장용 HDFS와 연산용 MapReduce를 도입했다. 2010년대에 혁신적이었지만 지금은 Spark, Snowflake, 오브젝트 스토리지 같은 클라우드 네이티브 도구로 대체되었고 레거시 환경에서 주로 볼 수 있다.
파일을 블록으로 나눠 클러스터의 여러 머신에 복제·분산 저장하는 Hadoop의 저장 레이어. 초기 빅데이터 시대의 기반이었으나 오늘날 신규 프로젝트에서는 클라우드 오브젝트 스토리지(S3, GCS, ADLS)가 대부분 그 자리를 대체했다.
Hadoop 기반 생태계의 테이블에 대한 테이블 정의, 컬럼 타입, 파티션 정보, 저장 위치 같은 메타데이터를 저장하는 중앙 저장소. Hive 자체는 덜 쓰이지만 Hive Metastore는 Spark, Trino 등 여러 쿼리 엔진의 기본 메타데이터 카탈로그로 여전히 쓰이며, 데이터가 어디에 무슨 모습으로 있는지 알려주는 '전화번호부' 역할을 한다.
단일 머신을 업그레이드하는 대신 더 많은 머신을 추가해 늘어난 부하를 감당하는 방식. Spark 클러스터가 감당을 못 하면 워커 노드를 추가하며, 단일 머신 성능에는 한계가 있기 때문에 현대 데이터 도구 대부분이 수평 확장을 염두에 두고 설계된다. 기존 머신의 CPU·RAM을 늘리는 수직 확장과 대비된다.
데이터 접근 빈도에 따른 분류. 핫 스토리지는 SSD나 인메모리 데이터베이스처럼 빠르지만 비싸고, 콜드 스토리지는 S3 Glacier나 테이프 백업처럼 느리지만 저렴하다. 데이터 엔지니어는 최근·자주 조회되는 데이터는 핫하게, 오래되고 드물게 조회되는 데이터는 콜드로 옮겨 비용을 아끼는 저장 계층을 설계한다.
같은 연산을 여러 번 실행해도 한 번 실행한 것과 동일한 결과를 내는 성질. 데이터 엔지니어링에서 매우 중요한데, 파이프라인이 중간에 죽었다 재실행되었을 때 멱등적 파이프라인은 중복 없이 올바른 결과를 내지만, 그렇지 않은 파이프라인은 레코드를 이중으로 셀 수 있다. 재실행이 항상 안전하도록 '삭제 후 재적재'나 업서트 로직을 쓰는 것이 흔한 접근이다.
디스크가 아니라 RAM에 있는 데이터로 연산을 수행하는 방식. RAM 접근이 디스크 I/O보다 몇 자릿수 빠르기 때문에 극적으로 빠르며, Apache Spark의 속도 우위는 상당 부분 인메모리 처리에서 나온다. 대가는 비용으로, RAM은 디스크보다 비싸다.
전체를 다시 적재하는 대신 마지막 실행 이후 새로 생기거나 변경된 데이터만 적재하는 방식. 더 빠르고 저렴하며 소스 시스템 부하도 적지만, 무엇이 바뀌었는지 안정적으로 감지하는 것이 과제이며 타임스탬프, 시퀀스 번호, CDC가 흔히 쓰이는 방법이다. 대부분의 운영 파이프라인이 증분 적재를 쓴다.
외부 소스로부터 데이터를 데이터 플랫폼으로 들여오는 과정으로, ETL·ELT의 'E'에 해당한다. 배치(정기적으로 가져오기)일 수도, 실시간(연속 스트리밍)일 수도 있으며 Fivetran, Airbyte, Kafka Connect, AWS DMS가 데이터 수집을 전문으로 한다.
Java 기반 애플리케이션에서 관계형 데이터베이스에 접속하기 위한 표준 인터페이스. Spark가 PostgreSQL이나 MySQL 데이터베이스를 읽을 때 보통 JDBC 커넥터를 쓰며, 연결 URL과 인증 정보, 쿼리를 제공하면 JDBC가 통신을 처리한다.
키-값 쌍과 중첩 구조를 사용하는 가볍고 사람이 읽기 쉬운 데이터 포맷. API는 거의 예외 없이 JSON을 반환하며 데이터 엔지니어는 API 응답 파싱, 로그 파일 처리, 데이터 레이크의 반구조화 데이터 처리 등에서 JSON을 끊임없이 다룬다. 요즘은 대부분의 웨어하우스가 네이티브로 JSON 쿼리를 지원한다.
Kafka와 외부 시스템 간 데이터를 스트리밍하기 위해 Kafka 생태계에 내장된 프레임워크. 커스텀 프로듀서·컨슈머를 직접 짜는 대신 사전 구축된 커넥터(데이터베이스, 클라우드 스토리지, 검색 엔진 등 수백 종)를 배포하면 되며, 확장, 장애 허용, 오프셋 관리를 대신 처리해준다.
람다 아키텍처에 있던 별도의 배치 처리 레이어를 없애고 모든 것을 스트림으로 처리하는 데이터 아키텍처. 배치와 스트리밍 두 코드 경로를 유지하는 대신 스트림용 로직을 한 번만 작성하면 되어 유지보수가 더 쉽지만 견고한 스트리밍 인프라가 필요하며, 람다 아키텍처의 대안으로 명명되었다.
오픈소스 컨테이너 오케스트레이션 플랫폼. 데이터 엔지니어링에서는 컨테이너화된 Spark 작업, Airflow 워커, Kafka 브로커, 커스텀 파이프라인 서비스를 실행하며 확장, 로드 밸런싱, 자동 재시작을 처리한다. 데이터 플랫폼이 컨테이너 위에서 돈다면 대개 Kubernetes가 그것을 관리하고 있다.
배치 처리와 실시간(스트림) 처리를 병렬로 실행하는 데이터 처리 아키텍처. 배치는 정확성을, 스트리밍은 속도를 담당하고 서빙 레이어가 결과를 병합하는데, 포괄적이지만 일관된 결과를 내야 하는 두 개의 별도 처리 파이프라인을 유지해야 해 복잡하다. 많은 팀이 이 복잡성을 피하려 카파 아키텍처나 통합 배치/스트리밍 도구로 옮겨가고 있다.
이미 닫힌 처리 윈도우에 속하는데도 그 이후에 도착하는 데이터. 모바일 앱이 화요일 이벤트를 보내지만 사용자가 오프라인이었던 탓에 목요일에야 파이프라인에 도착하는 경우가 그렇다. 지연 도착 데이터 처리는 스트림 처리에서 가장 까다로운 문제 중 하나로 워터마크, 허용 지연 설정, 재처리 전략이 필요하다.
데이터가 생성된 시점과 사용 가능해진 시점 사이의 시간. 매일 밤 도는 배치 파이프라인은 24시간의 지연이 있고 스트리밍 파이프라인은 몇 초일 수 있다. 낮은 지연이 항상 좋은 것은 아니며 더 큰 복잡성과 비용이 따르기에, 적절한 지연 수준은 실제 비즈니스 요구에 달려 있다.
데이터베이스가 자체 복구를 위해 유지하는 트랜잭션 로그(binlog, WAL, redo log 등)를 읽어 변경을 캡처하는 CDC 기법. 데이터베이스에 직접 쿼리하는 대신 이미 존재하는 로그 파일을 읽으므로 비침습적이고 모든 변경을 순서대로 포착한다. Debezium이 이 방식을 쓴다.
쿼리 결과를 테이블처럼 물리적으로 저장하되 원본 쿼리로부터 다시 갱신할 수 있는 데이터베이스 객체. 매번 쿼리를 재실행하는 일반 뷰와 달리 결과를 미리 계산해두며, 실시간일 필요 없는 비용이 큰 집계에 유용하다. Snowflake, BigQuery, Redshift, PostgreSQL 모두 지원한다.
데이터 레이크를 브론즈(원본)-실버(정제·정합)-골드(비즈니스 준비 집계) 세 레이어로 구조화하는 데이터 조직 패턴. 데이터는 브론즈에서 실버, 골드로 흐르며 각 레이어를 거칠수록 점점 정제된다. 설명하기 쉽고 구현이 쉬우며 데이터가 어디에 속하는지 명확한 멘탈 모델을 준다는 점에서 인기 있다. Databricks가 이 용어를 대중화했지만 개념 자체는 어떤 데이터 플랫폼에도 적용된다.
프로듀서와 컨슈머 사이에 메시지를 보관해 비동기 통신을 가능하게 하는 시스템. Kafka, RabbitMQ, Amazon SQS, Google Pub/Sub이 모두 메시지 큐다(다만 Kafka는 기술적으로는 분산 로그에 가깝다). 컨슈머가 다운되어도 메시지가 유실되지 않고 큐에서 기다리도록 시스템을 분리해준다.
데이터에 관한 데이터. 테이블의 스키마, 마지막 갱신 시점, 소유자, 행 수, 적용된 변환 등이 모두 메타데이터이며, 좋은 메타데이터 관리가 쓸 만한 데이터 플랫폼과 데이터 스웜프를 가른다. 데이터 카탈로그는 근본적으로 메타데이터를 정리하고 노출하기 위해 존재한다.
완전한 레코드 단위 스트리밍 대신 몇 초 간격처럼 매우 작은 배치를 고빈도로 처리하는 방식. Spark Structured Streaming이 내부적으로 마이크로배칭을 사용하며, 더 단순한 배치 처리 모델을 유지하면서 준실시간에 가까운 지연을 제공한다. 많은 사용 사례에서 마이크로배칭은 '충분히 실시간'이다.
Amazon S3와 API 호환되는 오픈소스 고성능 오브젝트 스토리지 시스템. 데이터 엔지니어는 온프레미스나 개발 환경에서 S3 같은 스토리지가 필요할 때 MinIO를 쓰며, 운영 환경에서 S3를 쓴다면 MinIO로 동일한 코드를 로컬에서 실행할 수 있다.
중복을 줄이고 무결성을 높이기 위해 관계형 데이터베이스에서 데이터를 조직하는 방식. 정규화된 데이터베이스에서는 고객 정보가 한 테이블에, 주문이 다른 테이블에 있고 키로 연결되는데, 이는 트랜잭션 시스템에는 좋지만 분석 쿼리에는 나쁘기 때문에 데이터 웨어하우스는 보통 스타 스키마 같은 비정규화 모델을 쓴다.
전통적인 관계형 테이블을 쓰지 않는 데이터베이스 범주. 문서 저장소(MongoDB), 키-값 저장소(Redis, DynamoDB), 컬럼 패밀리 저장소(Cassandra, HBase), 그래프 데이터베이스(Neo4j)를 포함한다. 데이터 엔지니어는 분석 파이프라인에 유입되는 소스 시스템으로 NoSQL을 접하며, 각 유형은 데이터 모델에 따라 강점이 다르다.
시스템이 누락되거나 정의되지 않은 값을 다루는 방식. 실제 데이터에는 널이 어디에나 있고 잘못 다루면 집계가 틀어지고 조인이 깨지고 리포트가 오도된다. SUM이 널을 무시하는지, JOIN이 널 키를 가진 행을 버리는지 등 도구와 쿼리를 통해 널이 어떻게 전파되는지 모든 데이터 엔지니어가 이해해야 한다.
대규모 데이터셋에 대해 집계, 그룹화, 윈도우 함수 같은 복잡한 분석 쿼리를 실행하도록 설계된 시스템 범주. 데이터 웨어하우스가 OLAP 시스템이며, 비즈니스 질문에 답하기 위해 대량의 데이터를 스캔하는 읽기 중심 워크로드에 최적화되어 있다.
빠르고 작고 빈번한 읽기·쓰기 연산을 위해 설계된 시스템. 회원가입, 주문, 결제를 처리하는 애플리케이션 데이터베이스가 OLTP 시스템이며 PostgreSQL, MySQL, SQL Server가 일반적인 용도로는 OLTP 데이터베이스다. 데이터 엔지니어는 OLTP 시스템에서 데이터를 추출해 분석용 OLAP 시스템에 적재한다.
Hadoop 워크로드에 최적화된 컬럼형 파일 포맷. 좋은 압축률, 빠른 읽기, 내장 인덱싱을 제공하며 Hive 생태계에서 기본 포맷이었다. 요즘은 더 폭넓은 도구 지원 덕에 Parquet이 더 인기 있지만 ORC는 기존 Hadoop 기반 플랫폼에서 여전히 많이 쓰인다.
스케줄링, 의존성 관리, 재시도, 모니터링을 포함해 데이터 파이프라인 내 여러 작업의 실행을 조율하는 것. Apache Airflow, Dagster, Prefect, Mage가 오케스트레이션 도구이며, 오케스트레이션이 없다면 스크립트를 수동으로 돌리며 순서대로 끝나기를 바라는 것에 불과하다.
데이터 레이크의 분석 데이터를 위한 사실상 표준이 된 컬럼형 파일 포맷. 컬럼 단위로 데이터를 저장하고 효율적인 압축을 지원하며 쿼리 엔진이 필요한 컬럼만 읽을 수 있게 한다. 데이터 레이크를 구축한다면 거의 확실히 Parquet 포맷으로 데이터를 저장하고 있을 것이다.
날짜, 지역, 카디널리티가 높은 다른 컬럼 값을 기준으로 큰 데이터셋을 더 작고 독립적인 조각으로 나누는 것. 테이블 전체를 스캔해 1월 데이터를 찾는 대신 쿼리 엔진은 1월 파티션만 읽는다. 좋은 파티셔닝 전략은 데이터 엔지니어링에서 가장 큰 성능 지렛대 중 하나다.
이름, 이메일, 전화번호, 주민등록번호, IP 주소처럼 특정 개인을 식별할 수 있는 데이터. GDPR, CCPA, HIPAA 같은 규제 때문에 데이터 엔지니어는 PII를 신중히 다뤄야 하며, 이는 파이프라인과 웨어하우스에서 PII를 마스킹·암호화·접근 제한하는 것을 뜻한다.
관련 없는 데이터가 메모리로 아예 읽히지 않도록 필터 조건을 스토리지 레이어까지 내려보내는 쿼리 최적화 기법. 전체 테이블을 로드한 뒤 필터링하는 대신, 프레디케이트 푸시다운은 스토리지 엔진에게 필터에 맞는 행만 반환하라고 지시해 I/O를 크게 줄이고 쿼리를 빠르게 한다. Parquet 등 컬럼형 포맷이 이와 특히 잘 맞는다.
테이블의 각 행을 고유하게 식별하는 컬럼(또는 컬럼 집합). 두 행이 같은 기본키를 가질 수 없고 널일 수도 없다. 데이터 엔지니어링에서는 중복 제거, SCD 추적, 조인 성능을 위해 올바른 기본키 선택이 중요하다.
발행자가 토픽에 메시지를 보내고 구독자가 관심 있는 토픽에서 메시지를 받는 메시징 패턴. 발행자는 누가 구독하는지 모르고 구독자도 누가 발행했는지 모른다. Google Cloud Pub/Sub과 Amazon SNS가 이 패턴을 쓰며, Kafka도 pub/sub을 지원하되 메시지를 영속적으로 저장한다는 점이 다르다.
데이터에 대한 쿼리를 읽고 파싱하고 최적화하고 실행하는 소프트웨어. Spark SQL, Trino(구 Presto), Athena, Hive가 모두 쿼리 엔진이며, 좋은 쿼리 엔진은 같은 데이터에서 쿼리가 3초에 끝나느냐 30분이 걸리느냐를 가른다.
쿼리를 더 빠르게 실행하고 자원을 덜 쓰게 만드는 과정. 옵티마이저가 SQL을 효율적으로 재작성하고, 적절한 파티셔닝·클러스터링으로 테이블을 설계하고, 푸시다운을 지원하는 파일 포맷을 선택하는 등 여러 층위에서 일어난다. 데이터 엔지니어링에서 성능 개선은 대부분 하드웨어 업그레이드가 아니라 쿼리 최적화에서 나온다.
Amazon의 클라우드 데이터 웨어하우스 서비스. 최초의 클라우드 웨어하우스 중 하나로(2012년 출시) 확장 가능하고 종량제인 분석 스토리지라는 개념을 대중화했다. 컬럼형 스토리지를 쓰고 표준 SQL을 지원하며 AWS 생태계와 긴밀하게 통합되어 Snowflake, BigQuery와 자주 비교된다.
한 시스템의 데이터를 다른 시스템으로 복사해 동기 상태를 유지하는 것. 데이터베이스 복제는 리포팅용 읽기 복제본을 최신 상태로 유지하고, 리전 간 복제는 지역 장애로부터 보호한다. 데이터 엔지니어링에서 복제는 배치 복사, CDC, 지속적 스트리밍을 통해 소스 시스템 데이터가 데이터 레이크나 웨어하우스로 흘러들어가는 방식이다.
데이터를 보관하고 있다가 아카이브하거나 삭제하기까지의 기간을 정하는 규칙. 원본 로그에 대한 90일 보존 정책은 그보다 오래된 것은 콜드 스토리지로 옮기거나 삭제한다는 뜻이다. 보존 정책은 저장 비용과 재처리·감사·컴플라이언스를 위해 이력 데이터를 유지할 필요성 사이의 균형을 잡는다.
쿼리 시 사용자가 볼 수 있는 행을 제한하는 기능. 지역 영업 관리자는 테이블에 모든 지역 데이터가 있어도 자기 지역 행만 볼 수 있다. Snowflake, BigQuery, Redshift 모두 행 수준 보안을 지원하며 멀티테넌트 데이터 플랫폼에 필수적이다.
시간에 따라 디멘션 데이터가 어떻게 변하는지 추적하는 일련의 기법. 고객이 주소를 바꾸면 웨어하우스에서 무슨 일이 일어나는가? Type 1은 그냥 이전 값을 덮어쓰고, Type 2는 이전 행을 유지한 채 유효기간이 달린 새 행을 추가해 이력을 보존하며, Type 3은 이전 값을 담는 컬럼을 추가한다. 특정 시점의 데이터 모습을 알고 싶어하는 경우가 대부분이라 실무에서는 Type 2가 가장 흔하다.
테이블 이름, 컬럼 이름, 데이터 타입, 제약조건, 관계 등 데이터가 어떻게 조직되는지 정의하는 구조. 관계형 데이터베이스에서는 스키마가 엄격하게 강제되지만 데이터 레이크에서는 느슨할 수 있고(스키마 온 리드) 테이블 포맷으로 강제될 수도 있다(스키마 온 라이트). 스키마를 제대로 설계하는 것은 데이터 모델링에서 가장 영향력 큰 결정 중 하나다.
기존 컨슈머를 깨뜨리지 않고 컬럼 추가, 필드 이름 변경, 타입 변경 등 시간에 따라 데이터셋의 스키마를 바꿀 수 있는 능력. Avro, Parquet(Iceberg·Delta 같은 테이블 포맷을 통해), 그리고 현대 웨어하우스 대부분이 스키마 진화를 지원하며, 이것이 없으면 스키마 변경마다 고통스러운 조율 작업이 필요하다.
고정된 스키마 없이 데이터를 저장하고 데이터를 읽거나 쿼리할 때 구조를 적용하는 접근 방식. 데이터 레이크는 전통적으로 스키마 온 리드를 쓴다. 무엇이든 저장할 수 있어 유연하지만 데이터를 이해하는 부담을 소비자에게 떠넘긴다.
저장되기 전에 데이터가 미리 정의된 스키마를 따라야 하는 접근 방식. 전통적인 데이터베이스와 웨어하우스가 스키마 온 라이트를 쓰며, 유연성은 떨어지지만 시스템 내 데이터가 항상 구조화되고 유효함을 보장한다.
원본 데이터와 비즈니스 사용자 사이에 위치해 비즈니스 지표, 디멘션, 관계를 일관되게 정의하는 추상화 레이어. 모든 분석가가 각자 '매출' 계산 로직을 짜는 대신 시맨틱 레이어가 한 번만 정의해준다. Looker의 LookML, dbt Metrics, Cube.js가 시맨틱 레이어를 제공한다.
객체나 레코드 같은 데이터 구조를 저장하거나 전송할 수 있는 형태로 변환하는 것. 예를 들어 Python 딕셔너리를 JSON 문자열이나 Avro 바이트 시퀀스로 바꾸는 것이다. 역직렬화는 그 반대 과정이며, 직렬화 포맷(JSON, Avro, Protobuf, Parquet) 선택은 성능, 저장 크기, 스키마 처리 방식에 영향을 준다.
메달리온 아키텍처의 중간 레이어로 데이터가 정제·검증·정합된 상태. 중복이 제거되고 데이터 타입이 표준화되며 기본적인 품질 체크가 적용된다. 실버 데이터는 아직 특정 비즈니스 용도로 집계되지는 않았지만 신뢰할 만큼 정제되어 있으면서도 여러 다운스트림 용도에 두루 쓰일 만큼 범용적이다.
처리된 데이터가 최종적으로 기록되는 목적지. Kafka 파이프라인에서 싱크는 데이터베이스, 데이터 레이크, 또는 다른 Kafka 토픽일 수 있다. ETL 파이프라인에서는 보통 데이터 웨어하우스가 싱크다. '소스'는 데이터가 오는 곳, '싱크'는 데이터가 가는 곳이다.
특정 시점에 캡처한 데이터셋 전체의 복사본. 소스 테이블의 일일 스냅샷은 매일 데이터가 어떤 모습이었는지 이력 기록을 남기며, 감사·디버깅·SCD Type 2 디멘션 구축에 유용하다.
디멘션 테이블을 서브 디멘션으로 정규화한, 스타 스키마의 변형. 하나의 큰 '제품' 디멘션 대신 제품 카테고리, 제품 서브카테고리, 브랜드를 위한 별도 테이블을 둘 수 있다. 저장 공간은 아끼지만 추가 조인 때문에 쿼리가 더 복잡해진다.
데이터가 파이프라인에 들어오기 전에 유래하는 시스템. 데이터베이스, API, 메시지 큐, 플랫 파일, SaaS 애플리케이션이 모두 소스이며, 소스 시스템의 데이터 모델, 갱신 패턴, 한계를 이해하는 것이 어떤 데이터 파이프라인을 만들든 첫걸음이다.
추출과 최종 적재 사이에 데이터가 머무는 임시 보관 구역. 원본 데이터가 스테이징에 들어와 검증·정제된 뒤 최종 목적지로 이동한다. 스테이징 영역은 파이프라인 실행 중 부분적으로 처리된 데이터가 운영 테이블에 나타나는 것을 막아준다.
데이터 웨어하우스에서 가장 흔한 데이터 모델링 패턴. 측정값을 담은 하나의 중앙 팩트 테이블을 서술적 속성을 담은 디멘션 테이블들이 별 모양으로 둘러싸는 구조다. 이해·쿼리·최적화가 쉬워 대부분의 BI 도구가 스타 스키마에 가장 잘 맞도록 설계되어 있다.
데이터가 도착하는 대로, 레코드 또는 마이크로배치 단위로 연속해서 처리하는 방식. 데이터를 모을 때까지 기다리는 배치 처리와 달리 스트리밍은 움직이는 데이터를 그때그때 다룬다. Kafka Streams, Apache Flink, Spark Structured Streaming이 주요 스트림 처리 도구이며 이상거래 탐지, 실시간 대시보드, IoT 모니터링처럼 지연이 중요한 곳에 쓰인다.
디멘션 테이블의 각 행에 부여되는, 보통 자동 증가 정수나 UUID인 인위적인 키. 이메일이나 제품 코드 같은 자연키와 달리 서로게이트 키는 절대 바뀌지 않고 비즈니스적 의미가 없어 SCD Type 2 추적을 단순하게 하고 조인을 더 빠르게 해준다.
Parquet 같은 파일 포맷 위에서 ACID 트랜잭션, 스키마 진화, 타임 트래블, 파티션 관리 같은 데이터베이스 같은 기능을 제공하는 메타데이터·규약 레이어. Delta Lake, Apache Iceberg, Apache Hudi가 3대 테이블 포맷이며 데이터 레이크하우스를 가능하게 하는 핵심 요소다.
일정 시간 동안 시스템이 처리할 수 있는 데이터의 양. 처리량이 높은 파이프라인은 분당 수백만 건의 레코드를 처리한다. 처리량과 지연은 관련이 있지만 다른 개념으로, 높은 처리량에 높은 지연(배치 처리)을 가질 수도, 낮은 지연에 낮은 처리량(레코드 단위 스트리밍)을 가질 수도 있다. 데이터 엔지니어링 최적화 대부분은 이 둘 사이의 균형을 맞추는 일이다.
이전 시점에 존재했던 데이터를 그대로 조회할 수 있는 능력. Delta Lake, Apache Iceberg, Snowflake 모두 타임 트래블을 지원한다. 실수로 테이블을 덮어썼다면 어제 버전을 조회하면 되고, 지난달 데이터가 어땠는지 감사해야 한다면 수동 스냅샷 없이도 타임 트래블로 가능하다.
데이터의 형태, 내용, 구조를 바꾸는 모든 연산. 행 필터링, 테이블 조인, 새 컬럼 계산, 값 집계, 타입 캐스팅이 모두 변환이며 ETL·ELT의 'T'에 해당한다. 데이터 엔지니어링에서 비즈니스 로직이 사는 곳이 바로 여기다.
파이프라인 실행을 시작시키는 메커니즘. 시간 기반(CRON 스케줄), 이벤트 기반(S3에 새 파일 도착), 데이터 기반(업스트림 테이블 갱신)일 수 있다. Airflow에서는 보통 스케줄 기반 트리거를 쓰고, 이벤트 기반 아키텍처에서는 보통 메시지나 파일 알림이 트리거가 된다.
'update'와 'insert'의 결합. 키를 기준으로 레코드가 이미 존재하면 갱신하고 없으면 삽입한다. 업서트는 멱등적 파이프라인을 만들고 증분 적재를 구현하는 데 근본적이며, 대부분의 데이터 웨어하우스는 MERGE문을 통해 업서트를 지원한다.
오래되거나 삭제되었거나 더 이상 쓰이지 않는 데이터 파일을 정리하는 유지보수 작업. Delta Lake에서 vacuum은 트랜잭션 로그가 더 이상 참조하지 않는 파일을 제거하고, PostgreSQL에서 vacuum은 죽은 행이 차지하던 저장 공간을 회수한다. 정기적으로 vacuum하지 않으면 데이터를 삭제한 뒤에도 저장 비용이 늘고 쿼리 성능이 떨어진다.
CPU, RAM, 스토리지를 추가해 단일 머신을 더 강력하게 만드는 방식. 수평 확장보다 단순하지만 한 대의 박스에 넣을 수 있는 하드웨어에는 한계가 있어 확실한 천장이 있다. 단일 머신 용량을 넘어서는 데이터 엔지니어링 워크로드에는 수평 확장이 나아갈 방향이다.
SQL 쿼리로 정의되는 가상 테이블. 뷰는 데이터를 저장하지 않고 접근될 때마다 정의된 쿼리를 실행한다. 복잡한 로직을 추상화하거나 특정 컬럼에 대한 접근을 제한하거나 단순화된 인터페이스를 제공하는 데 유용하다. 구체화 뷰와 달리 일반 뷰는 저장 비용은 없지만 쿼리마다 컴퓨트 비용이 추가된다.
스트림 처리에서 시스템이 이벤트 타임라인상 어디까지 진행했는지 추적하는 지표. '이 타임스탬프까지의 이벤트는 모두 받았다고 믿는다'는 것을 시스템에게 알려준다. 워터마크는 일부 이벤트가 늦게 도착하더라도 스트리밍 엔진이 시간 윈도우를 언제 닫고 결과를 내보내도 안전한지 판단하는 기준이 된다.
현재 행과 관련된 행 집합에 걸쳐 계산을 수행하되 그 행들을 하나의 출력으로 합치지 않는 SQL 함수. ROW_NUMBER(), RANK(), LAG(), LEAD(), 누적 합계 같은 것들이다. 윈도우 함수는 분석 SQL에서 가장 강력한 기능 중 하나로 데이터 엔지니어링 변환에서 끊임없이 쓰인다.
데이터 처리 목표를 달성하기 위한 일련의 정의된 작업. 워크플로우는 작업 자체, 의존 관계, 스케줄링 규칙, 실패 처리를 포함한다. Airflow의 DAG이 곧 워크플로우이며 '워크플로우', '파이프라인', 'DAG'는 미묘한 뉘앙스 차이는 있지만 흔히 서로 바꿔 쓰인다.
실제 데이터 파일에 적용되기 전에 데이터베이스 변경 사항이 먼저 기록되는 로그 파일. 시스템이 쓰기 도중 죽더라도 WAL을 재생해 복구할 수 있게 해준다. Debezium 같은 CDC 도구는 WAL을 읽어 변경을 캡처하며, PostgreSQL, MySQL(binlog) 등 대부분의 데이터베이스가 어떤 형태로든 WAL을 쓴다.
Airflow에서 DAG 내 작업들이 서로 작은 데이터 조각을 주고받게 해주는 기능. 한 작업이 파일 경로나 행 수를 XCom에 push하면 다운스트림 작업이 그 값을 pull해 다음에 무엇을 할지 결정한다. XCom은 작은 메타데이터용이며 데이터프레임 전체를 통과시키려 하면 안 된다.
데이터 엔지니어링 도구 전반에서 널리 쓰이는 사람이 읽기 쉬운 설정 포맷. Docker Compose 파일, Kubernetes 매니페스트, dbt 프로젝트 설정, CI/CD 파이프라인 정의가 모두 YAML로 작성된다. 괄호 대신 들여쓰기로 구조를 나타내 깔끔하게 읽히지만 공백 오류에 민감하다.
데이터가 이미 있는 곳에서 직접 접근할 수 있게 해 전통적인 추출-변환-적재 파이프라인을 없애는 접근 방식. 데이터를 있는 자리에서 바로 쿼리하거나, 지속적으로 복제하거나, 최소한의 처리로 스트리밍한다. 꿈처럼 들리지만 변환 작업이 사라지는 게 아니라 소비자 쪽으로 더 가까이 옮겨갈 뿐이다. 운영 리포팅이나 단순 분석에는 잘 맞지만 비즈니스 로직이 복잡할 때는 어려움을 겪을 수 있다.
분산 시스템에서 설정, 네이밍, 동기화를 유지하는 중앙집중식 서비스. Kafka는 역사적으로 클러스터 메타데이터 관리와 리더 선출을 위해 Zookeeper에 의존했다. 최신 Kafka 버전(KRaft 모드)은 이 의존성을 없앴지만 Zookeeper는 여전히 많은 기존 배포와 HBase 같은 다른 분산 시스템에서 쓰인다.