ETL 대 최신 ELT: dbt, Airbyte 및 Fivetran
데이터 파이프라인은 모든 데이터 기반 아키텍처의 순환 시스템입니다. 흐름 없이 소스부터 창고, 기계 학습 모델까지 신뢰할 수 있고 문서화되었으며 테스트된 데이터 잘못된 예측을 생성하고 비즈니스 보고서에 일관되지 않은 숫자와 결정이 표시됩니다. 전략은 불안정한 기반을 기반으로 합니다. 하지만 대부분의 이탈리아 기업에서는 데이터 파이프라인은 여전히 cron, 업데이트된 Excel 시트로 예약된 SQL 스크립트의 엉킴입니다. 누구도 감히 건드릴 수 없는 수십 년 전에 구축된 ETL 프로세스를 손으로 직접 제작합니다.
지난 5년 동안 풍경은 급격하게 변했습니다. 클라우드 컴퓨팅의 등장은 데이터 이동의 기본 패러다임이 뒤집혔습니다. 데이터를 변환하는 것은 더 이상 의미가 없습니다. 전에 기존 ETL에서와 마찬가지로 창고에 로드합니다. 클라우드 컴퓨팅 성능은 무시할 수 있는 비용으로 제공되며 현대적인 창고는 이러한 성능을 발휘할 수 있습니다. 몇 초 만에 복잡한 변환이 가능합니다. 그리하여 패러다임이 탄생했다 ELT(추출, 로드, 변신), 변환을 이동하여 작업 순서를 반대로 바꿉니다. ~에 창고 그 자체.
데이터 파이프라인 시장은 이러한 변화를 반영합니다. ELT 부문은 다음과 같이 성장합니다. 연간 26%, 전체 데이터 파이프라인 도구 시장은 다음과 같이 추정됩니다. 2024년에는 120억 달러, 2030년에는 480억 달러에 이를 것으로 예상됩니다. ELT가 관리하는 행위자는 전년 대비 50% 성장으로 ARR에서 3억 달러를 달성했습니다. 이것은 틈새 시장이 아닙니다. 새로운 표준입니다.
이 기사에서는 두 가지 패러다임을 심층적으로 탐색하고 지배적인 도구를 분석합니다. 시장(dbt, Airbyte, Fivetran)을 대상으로 완전한 참조 아키텍처를 구축하고 우리는 귀하의 크기와 크기에 따라 올바른 스택을 선택하기 위한 실용적인 권장 사항을 제공할 것입니다. 팀 기술.
이 기사에서 배울 내용
- 장단점 및 사용 사례를 포함한 기존 ETL과 최신 ELT의 근본적인 차이점
- dbt(Data Build Tool) 작동 방식: SQL 모델, 테스트, 문서화, 계보
- dbt Core와 dbt Cloud: 어느 것을 선택하고 어떤 비용을 지불해야 할까요?
- Airbyte: 셀프 호스팅을 위한 오픈 소스 커넥터, 아키텍처 및 배포
- Fivetran: 관리형 SaaS 모델 및 새로운 MAR 가격 책정(2025)
- 다양한 비즈니스 시나리오에 대한 세 가지 도구 간의 자세한 비교
- 참조 최신 ELT 아키텍처: Airbyte/Fivetran + Warehouse + dbt + BI
- 테스트, 문서화 및 파이프라인 조정을 위한 모범 사례
기존 ETL: 작동 방식 및 더 이상 충분하지 않은 이유
거의 30년 동안,ETL(추출, 변환, 로드) 그게 패러다임이었어 기업 데이터 이동에 있어 가장 중요한 요소입니다. 프로세스는 세 가지 순차적 단계로 나뉩니다.
- 발췌: 데이터는 일반적으로 소스 시스템에서 추출됩니다. OLTP 데이터베이스(ERP, CRM, 전자상거래), 플랫 파일(CSV, XML) 또는 외부 API. 이 단계는 다음과 같습니다 데이터를 수정하지 않고.
- 변환: 추출된 데이터는 다음과 같이 변환됩니다. 중간 시스템, 준비 영역 또는 ETL 엔진이라고 하며 두 영역과 별개입니다. 소스와 대상. 변환에는 정리, 정규화, 농축, 집계 및 창고 표준 준수.
- 짐: 변환된 데이터는 데이터 웨어하우스에 로드됩니다. 목적지의. 데이터 구조는 이미 분석 쿼리에 최적화된 최종 구조입니다.
기존 ETL 도구
| 기구 | 공급업체 | 표시 비용 | 목표 |
|---|---|---|---|
| SSIS | 마이크로소프트 | SQL Server에 포함됨 | Microsoft 생태계를 갖춘 SME |
| 인포매티카 파워센터 | 정보학 | $50,000-$500,000/년 | 기업 금융/보험 |
| 오라클 데이터 통합자 | 신탁 | Oracle DB와 번들로 제공 | 오라클 생태계 |
| 탈렌드 오픈 스튜디오 | Qlik | 무료(코어) / $1,170+/월 | 중소기업, 오픈소스 |
| 펜타호 데이터 통합 | 히타치 반타라 | 무료(CE) / 맞춤형(EE) | 중소기업, 오픈소스 |
이 도구는 작동합니다. 그들은 시스템의 중추였으며 많은 경우 여전히 그렇습니다. 매일 수십억 유로의 거래를 처리하는 중요한 요소입니다. 하지만 한계가 있어요 구조적으로는 클라우드 패러다임이 점점 더 분명해지고 있습니다.
기존 ETL의 구조적 한계
전통적인 ETL이 현대적 맥락에서 어려움을 겪는 이유
- 고가의 외부 컴퓨팅: 변환은 별도의 서버에서 발생합니다. (ETL 서버), 이는 최대 로드에 맞게 크기를 조정해야 합니다. 밤 배치의 경우 1억 개의 행을 처리하려면 서버가 이를 처리할 만큼 강력해야 합니다. 하루 22시간 동안 거의 사용하지 않는 경우에도 마찬가지입니다.
- 강성과 변경 비용: 변환에 필드 추가 SSIS에서는 시각적 흐름을 수정하고, 준비 단계에서 테스트하고, 릴리스를 조정해야 합니다. 목적지 창고를 관리하는 사람과 함께. 구조화된 팀에서는 이 작업에 몇 주가 걸립니다.
- 기본 버전 관리 없음: ETL 흐름은 테스트 가능한 코드가 아니며 응용 프로그램 소프트웨어처럼 버전이 가능합니다. 거버넌스가 어려워진다: 누가 변했는가 이 변신? 언제? 왜?
- 복잡한 디버깅: 변형이 예상치 못한 결과를 낳을 때, 시각적 ETL 흐름을 통해 문제를 추적하는 데 몇 시간이 걸릴 수 있습니다. 거기에는 각 열의 출처를 보여주는 표준 "데이터 계보"입니다.
- 창고 전력 낭비: Snowflake 또는 BigQuery에 투자합니다. 컴퓨팅 성능을 위해 연간 수만 유로를 지출하지만 결국에는 완료됩니다. 별도의 서버에서 데이터를 처리합니다. ELT 패러다임은 창고 자체를 인식합니다. 가장 효율적인 변환 엔진입니다.
최신 ELT: 클라우드가 모든 것을 변화시킨 이유
L'ELT(추출, 로드, 변환) 마지막 두 단계의 순서를 반대로 바꿉니다: 데이터 먼저 소스에서 추출되어 원시 형태로 창고에 로드됩니다. 이후 창고 자체의 컴퓨팅 성능을 사용하여 변환되었습니다.
이러한 패러다임 전환은 세 가지 수렴 요소에 의해 가능해졌습니다.
- 경제적인 클라우드 스토리지: Amazon S3, Azure Blob Storage 및 Google Cloud Storage 비용은 TB당 월 20~23달러입니다. 스토리지를 절약하는 것은 더 이상 의미가 없습니다. 모든 것을 로드하고 다음에 무엇을 변환할지 결정하세요.
- 탄력적인 컴퓨팅: Snowflake, BigQuery, Databricks는 자동으로 확장됩니다. 컴퓨터. 복잡한 변환 쿼리는 다음을 활용하여 몇 초 안에 실행됩니다. 수백 개의 노드로 구성된 클러스터로, 실제 실행 시간에 대해서만 비용을 지불합니다.
- 범용 언어로서의 SQL: 데이터 분석가는 SQL을 훨씬 더 잘 알고 있습니다. 독점 ETL 도구 중 하나입니다. ELT를 사용하면 변환은 다음과 같은 간단한 SQL 쿼리입니다. 팀 구성원 누구나 읽고, 편집하고, 검토할 수 있습니다.
ETL과 ELT 비교: 결정표
ETL과 ELT: 완전한 비교
| 크기 | 기존 ETL | 현대 ELT |
|---|---|---|
| 변형이 일어나는 곳 | 전용 ETL 서버(웨어하우스 외부) | 데이터 웨어하우스 내부(네이티브 SQL) |
| 변신할 때 | 로드하기 전 | 원시 레이어에 로드한 후 |
| 지원되는 데이터 볼륨 | ETL 서버의 용량에 따라 제한됨 | 창고에 따라 확장(잠재적으로 무제한) |
| 구조화되지 않은 데이터 | 어렵거나 불가능함 | 지원됨(네이티브 JSON, 반구조적) |
| 언어 | 독점 GUI/Java/Python | 표준 SQL(+dbt의 Jinja) |
| 버전 관리 | 어렵고 자주 결석함 | 기본 Git(템플릿은 .sql 파일임) |
| 테스트 | 수동 또는 제한 | 통합 테스트 프레임워크(dbt 테스트) |
| 날짜 계보 | 종종 부재하거나 수동으로 | 자동(dbt의 시각적 DAG) |
| 보안/규정 준수 | 민감한 데이터는 절대로 웨어하우스에 공개되지 않습니다. | 웨어하우스의 원시 데이터: 마스킹 및 거버넌스가 필요합니다. |
| 변환 대기 시간 | ETL 서버에 따라 다릅니다. | 창고에 따라 다름(배치 또는 주문형) |
| 학습 곡선 | 높음(독점 GUI) | SQL을 아는 사람에게는 낮음 |
| 다음에 이상적입니다. | 민감한 데이터, 레거시 시스템, 엄격한 규정 준수 | 클라우드 우선, SQL 팀, 높은 데이터 볼륨 |
ETL과 ELT를 선택해야 하는 경우
- 다음과 같은 경우 ETL을 선택하십시오. 업로드를 금지하는 규정 준수 요구사항이 있는 경우 클라우드의 원시 데이터(예: 익명화되지 않은 PII), 온프레미스 레거시 시스템과 작업 창고가 소스에서 너무 멀리 떨어져 있거나 계산 변환이 있는 경우 SQL 웨어하우스의 이점을 누리지 못하는 집중적입니다.
- 다음과 같은 경우 ELT를 선택하세요. 창고 및 클라우드(Snowflake, BigQuery, Databricks, Redshift) 팀은 탄탄한 SQL 기술을 보유하고 있으며 Git을 사용하여 버전 변환을 원합니다. 점점 늘어나는 데이터 볼륨으로 작업하고 클라우드의 탄력성을 활용하고 싶습니다.
- 하이브리드 접근 방식: 많은 기업이 혼합된 접근 방식을 취하고 있습니다. 로드 전 민감한 데이터의 익명화, 모든 변환에 대한 ELT 후속 분석.
dbt: 최신 스택 변환 계층
dbt(데이터 구축 도구) 현대 ELT 패러다임을 정의한 도구입니다. 2016년에 dbt Labs에서 만든 dbt는 데이터 분석가가 변환을 작성하는 방식을 변화시켰습니다. 희박하고 구조가 없는 SQL 프로시저 대신 dbt는 영감을 받은 개발 프레임워크를 도입합니다. 버전이 지정된 모델, 자동 테스트 및 생성된 문서를 통해 소프트웨어 엔지니어링에 자동으로.
기본적이고 간단한 개념: 모든 dbt 템플릿 및 .sql 파일 다음을 포함하는 선택. dbt는 웨어하우스에 테이블이나 뷰를 생성하고 종속성을 관리합니다. 모델 간 변환의 DAG(방향성 비순환 그래프)를 구축합니다.
Dbt 아키텍처: 작동 방식
dbt에는 자체 컴퓨팅 런타임이 없습니다. 대상 웨어하우스의 컴퓨팅을 사용합니다. 그것은 다음과 같이 작동합니다 SQL 컴파일러 + 오케스트레이터: .sql 파일을 사용합니다. Jinja 매크로는 이를 순수 SQL로 컴파일하고 이를 기반으로 올바른 순서로 웨어하우스에서 실행합니다. 선언된 종속성에 대해. 그 결과 창고에 일련의 테이블과 뷰가 생성되었습니다. 재현 가능합니다.
-- models/staging/stg_orders.sql
-- Modello di staging: pulizia e standardizzazione degli ordini
-- dbt crea una view (o tabella) chiamata 'stg_orders' nel warehouse
WITH source AS (
-- Riferimento alla tabella sorgente raw (caricata da Airbyte/Fivetran)
SELECT * FROM {{ source('erp', 'raw_orders') }}
),
cleaned AS (
SELECT
order_id::BIGINT AS order_id,
customer_id::INT AS customer_id,
product_id::INT AS product_id,
quantity::INT AS quantity,
unit_price::DECIMAL(10, 2) AS unit_price,
COALESCE(discount, 0.0)::DECIMAL(5, 2) AS discount,
CAST(order_date AS TIMESTAMP) AS order_date,
LOWER(TRIM(status)) AS status,
-- Importo netto calcolato
quantity * unit_price * (1 - COALESCE(discount, 0))
AS net_amount,
-- Metadati di audit
_loaded_at AS ingested_at
FROM source
WHERE order_id IS NOT NULL
AND customer_id IS NOT NULL
AND quantity > 0
AND unit_price > 0
)
SELECT * FROM cleaned-- models/marts/finance/fct_orders_monthly.sql
-- Modello fatto: aggregazione mensile per il team finance
-- Dipende da stg_orders e dim_customers (risoluzione automatica dipendenze)
{{ config(
materialized='table',
schema='finance',
tags=['finance', 'monthly']
) }}
WITH orders AS (
SELECT * FROM {{ ref('stg_orders') }}
),
customers AS (
SELECT * FROM {{ ref('dim_customers') }}
),
monthly_metrics AS (
SELECT
DATE_TRUNC('month', o.order_date) AS month,
c.region,
c.segment,
COUNT(DISTINCT o.order_id) AS total_orders,
COUNT(DISTINCT o.customer_id) AS unique_customers,
SUM(o.net_amount) AS gross_revenue,
AVG(o.net_amount) AS avg_order_value,
SUM(o.quantity) AS units_sold
FROM orders o
LEFT JOIN customers c ON o.customer_id = c.customer_id
GROUP BY 1, 2, 3
)
SELECT
*,
gross_revenue / NULLIF(unique_customers, 0) AS revenue_per_customer
FROM monthly_metrics
ORDER BY month DESC, gross_revenue DESCdbt 테스트: 데이터 품질 보장
dbt의 가장 중요한 강점 중 하나는 기본 테스트 시스템입니다. dbt의 테스트
선언적입니다. YAML 파일에 정의되어 있으며 각 작업 후에 자동으로 실행됩니다.
명령으로 실행 dbt test.
# models/staging/schema.yml
# Definizione dei test per il modello stg_orders
version: 2
models:
- name: stg_orders
description: >
Ordini puliti e standardizzati dal sistema ERP sorgente.
Caricati ogni ora da Airbyte, trasformati da questo modello.
columns:
- name: order_id
description: "Identificativo univoco dell'ordine (PK)"
tests:
- unique # Nessun duplicato ammesso
- not_null # Ogni riga deve avere un order_id
- name: customer_id
description: "Riferimento alla dimensione clienti"
tests:
- not_null
- relationships: # Referential integrity check
to: ref('dim_customers')
field: customer_id
- name: status
description: "Stato dell'ordine"
tests:
- accepted_values:
values: ['pending', 'confirmed', 'shipped', 'delivered', 'cancelled']
- name: net_amount
description: "Importo netto dell'ordine (quantità * prezzo * (1 - sconto))"
tests:
- not_null
- dbt_utils.expression_is_true:
expression: "net_amount >= 0"
- name: order_date
description: "Data e ora dell'ordine"
tests:
- not_null
- dbt_utils.expression_is_true:
expression: "order_date <= CURRENT_TIMESTAMP"
- name: fct_orders_monthly
description: "Aggregazioni mensili per il reporting finance"
columns:
- name: month
tests:
- not_null
- name: gross_revenue
tests:
- not_null
- dbt_utils.expression_is_true:
expression: "gross_revenue >= 0"
sources:
- name: erp
description: "Dati grezzi caricati dall'ERP tramite Airbyte"
schema: raw_erp
tables:
- name: raw_orders
loaded_at_field: _loaded_at
freshness:
warn_after: {count: 12, period: hour}
error_after: {count: 24, period: hour}DBT 코어와 DBT 클라우드
dbt는 두 가지 변형으로 존재합니다. DBT 코어 (오픈소스, 무료) DBT 클라우드 (SaaS 관리형, 유료). 선택은 귀하의 필요에 따라 달라집니다 인프라 및 고급 기능 측면에서 팀의.
dbt Core와 dbt Cloud: 완전한 비교
| 기능성 | DBT 코어(오픈 소스) | DBT클라우드팀 | DBT 클라우드 엔터프라이즈 |
|---|---|---|---|
| 비용 | 무료 | $100/시트/월 + 15,000개 이상의 모델에 대해 $0.01 | 맞춤형(영업팀에 문의) |
| 작업 실행 | 수동/외부 오케스트레이터(Airflow, Dagster) | 네이티브 스케줄러, 통합 CI/CD | 고급 스케줄러 + SLA 모니터링 |
| 웹 IDE | 아니요(로컬 편집자만 해당) | dbt Cloud IDE(브라우저 기반) | DBT 클라우드 IDE |
| 선적 서류 비치 | 로컬에서 생성됨(dbt 문서 생성) | 자동으로 호스팅됨 | 호스팅 + 고급 데이터 카탈로그 |
| 시각적 계보 | 현지의 | 클라우드 호스팅, 공유 가능 | 클라우드 호스팅 + 프로젝트 간 계보 |
| 팀 협업 | Git을 통해(수동) | 다중 사용자, PR 기반 워크플로우 | RBAC, SSO, 감사 로그 |
| 의미 계층 | No | 포함됨(5,000개 지표/월) | 포함됨(20,000개 지표/월) |
| DBT 메쉬 | No | 제한된 | 완료(프로젝트 간 참조) |
| SOC 2 규정 준수 | 해당 없음(자체 관리) | 포함됨 | 포함됨 + PrivateLink |
| 다음에 이상적입니다. | 기술팀, 제한된 예산, 이미 Airflow 보유 | ETL 인프라가 없는 팀 2~20명 | 기업, 다중 팀, 엄격한 규정 준수 |
실질적인 권장 사항: 1~3명의 데이터 엔지니어로 구성된 팀이 있는 이탈리아 SME는 시작해야 합니다. 와 dbt Core + Airflow 또는 Dagster, 이는 무료로 완전한 유연성을 제공합니다. 팀이 성장하거나 오케스트레이션 인프라 관리를 피하고 싶다면, DBT 클라우드 개발자 좌석이 2~3명 있으면 이미 편리해졌습니다.
Airbyte: 오픈 소스 수집 계층
dbt가 다음을 처리하는 경우 T (변환) ELT에서, 에어바이트 관리하다 는 E (추출) 및 L (로드 중). 2020년에 설립되었으며 오늘날 그 이상과 함께 1억 8천만 달러의 자금 지원, Airbyte 및 가장 널리 채택된 오픈 소스 데이터 통합 플랫폼 시장의, 600개 이상의 사전 구축된 커넥터 그리고 빌드할 Python SDK 맞춤형 커넥터.
경쟁사에 비해 Airbyte의 주요 강점은 오픈 소스 (벤더 종속 없음, 수정 가능한 코드) 아키텍처 포함 실시간 데이터베이스 복제를 위해 CDC(Change Data Capture)를 지원하는 클라우드 네이티브입니다.
에어바이트 아키텍처
Airbyte는 동시에 작동하는 여러 구성 요소로 구성됩니다. 모든 동기화가 이루어집니다. 에 의해 수행됨 노동자 두 개의 개별 Docker 컨테이너를 인스턴스화합니다. 소스 커넥터 (소스에서 읽음) 및 목적지 커넥터 (대상에 씁니다). 데이터는 둘 사이를 통해 흐릅니다. 나는 에어바이트 프로토콜, 표준 JSON 형식입니다.
# Esempio: Configurazione connettore Airbyte via API (YAML/JSON)
# Creazione di una connessione PostgreSQL -> Snowflake
# 1. Configurazione Source (PostgreSQL)
POST /api/v1/sources/create
{
"sourceDefinitionId": "decd338e-5647-4c0b-adf4-da0e75f5a750",
"connectionConfiguration": {
"host": "db.produzione.miazienda.it",
"port": 5432,
"database": "erp_production",
"username": "airbyte_reader",
"password": "{{ secrets.POSTGRES_PASSWORD }}",
"schemas": ["public", "orders"],
"replication_method": {
"method": "CDC",
"replication_slot": "airbyte_slot",
"publication": "airbyte_publication"
}
},
"name": "ERP Production PostgreSQL",
"workspaceId": "workspace-uuid"
}
# 2. Configurazione Destination (Snowflake)
POST /api/v1/destinations/create
{
"destinationDefinitionId": "424892c4-daac-4491-b35d-c6688ba547ba",
"connectionConfiguration": {
"host": "abc12345.eu-west-1.snowflakecomputing.com",
"role": "AIRBYTE_ROLE",
"warehouse": "AIRBYTE_WH",
"database": "RAW_DATA",
"schema": "erp",
"username": "airbyte_user",
"credentials": {
"auth_type": "key_pair",
"private_key": "{{ secrets.SNOWFLAKE_PRIVATE_KEY }}"
}
},
"name": "Snowflake Production",
"workspaceId": "workspace-uuid"
}
# 3. Creazione della connessione
POST /api/v1/connections/create
{
"sourceId": "source-uuid",
"destinationId": "destination-uuid",
"syncCatalog": {
"streams": [
{
"stream": {"name": "orders", "namespace": "public"},
"config": {
"syncMode": "incremental",
"destinationSyncMode": "append_dedup",
"cursorField": ["updated_at"],
"primaryKey": [["order_id"]]
}
},
{
"stream": {"name": "customers", "namespace": "public"},
"config": {
"syncMode": "full_refresh",
"destinationSyncMode": "overwrite"
}
}
]
},
"scheduleType": "cron",
"scheduleData": {"cron": {"cronExpression": "0 */1 * * *", "cronTimeZone": "Europe/Rome"}},
"namespaceDefinition": "customformat",
"namespaceFormat": "raw_{{SOURCE_NAMESPACE}}"
}Airbyte: 배포 옵션
Airbyte는 세 가지 배포 모드를 제공하며 각 모드는 측면에서 서로 다른 특징을 가지고 있습니다. 비용, 제어 및 유지 관리:
Airbyte: 오픈 소스 vs. 클라우드 vs. 엔터프라이즈
| 나는 기다린다 | 오픈 소스(자체 호스팅) | 에어바이트 클라우드 | 에어바이트 엔터프라이즈 |
|---|---|---|---|
| 비용 | 무료(인프라 비용은 본인 부담) | 종량제(크레딧당 $2.50-$10) | 맞춤형(영업팀에 문의) |
| 유지 | 팀에서 지불 | 에어바이트 제공 | 에어바이트 제공 |
| 커넥터 | 600+ | 600+ | 600++ 프리미엄 인증 커넥터 |
| 질병통제예방센터 | 지원됨 | 지원됨 | 지원됨 + 고급 CDC |
| RBAC | 기초적인 | 포함됨 | 고급(SSO, 감사 로그) |
| 루게릭병 | 해당 없음 | 99.9% 가동 시간 | 99.99% 가동 시간 |
| 다음에 이상적입니다. | 기술팀, 제한된 예산, 민감한 데이터 | 운영 없이 속도를 원하는 SME | 엄격한 규정 준수 기업 |
# Deploy Airbyte Open Source con Docker Compose
# Prerequisiti: Docker, Docker Compose, 8GB RAM, 20GB disk
# 1. Clona il repository
git clone --depth=1 https://github.com/airbytehq/airbyte.git
cd airbyte
# 2. Avvia Airbyte (prima esecuzione: ~15 minuti per download immagini)
./run-ab-platform.sh
# Airbyte e accessibile su http://localhost:8000
# Username: airbyte / Password: password (da cambiare in produzione!)
# 3. Per deployment in produzione su Kubernetes con Helm
helm repo add airbyte https://airbytehq.github.io/helm-charts
helm install airbyte airbyte/airbyte \
--namespace airbyte \
--create-namespace \
--set global.state.storage.type=MINIO \
--set global.storage.bucket.log=airbyte-logs \
--values custom-values.yaml
# 4. Configurazione variabili di ambiente per produzione (.env)
# DATABASE_URL=postgresql://airbyte:password@postgres:5432/airbyte
# SECRET_PERSISTENCE=GOOGLE_SECRET_MANAGER
# LOG_LEVEL=INFO
# TRACKING_STRATEGY=segmentFivetran: 관리형 SaaS의 단순성
Airbyte는 오픈 소스 유연성과 제어에 중점을 두고 있지만, 파이브트란 반대 경로 선택: 최대 단순성, 유지 관리 불필요, 엔터프라이즈급 커넥터 전적으로 공급업체에서 관리합니다. 2012년에 설립된 Fivetran은 오늘날 이 부문의 선두주자입니다. ELT는 3억 달러의 ARR, 6,300명 이상의 고객, 56억 달러의 가치 평가를 관리했습니다.
Fivetran의 가치 제안은 분명합니다. Salesforce, Shopify에 대한 Fivetran 커넥터입니다. 또는 기타 SaaS 시스템은 Fivetran 엔지니어로 구성된 전담 팀에 의해 유지 관리됩니다. 소스 API의 모든 변경 사항, 모든 주요 변경 사항, 모든 업데이트를 관리합니다. 계획. 고객은 아무 것도 할 필요가 없습니다.
새로운 Fivetran 가격 모델 2025
2025년 3월 Fivetran은 가격 모델을 대폭 업데이트했습니다. 스타터 및 프라이빗 배포 계획이 제거되고 4개 계층으로 대체되었습니다. 무료, 표준, 엔터프라이즈 및 비즈니스 크리티컬. 청구 지표 남아있다 MAR(월별 활성 행), 그러나 계산이 변경되었습니다. 이제 매 연결 비용은 별도로 청구되며 더 이상 계정별로 집계되지 않습니다.
Fivetran: 계획 및 가격 2025
| 바닥 | 화요일 포함 | 추가 비용 | 주요 특징 |
|---|---|---|---|
| 무료 | 500,000MAR/월 | 해당 없음 | 모든 표준 기능, 최대 5,000개의 모델 실행 |
| 기준 | 무제한(종량제) | $5 기본/연결 + MAR 가격 | 600개 이상의 커넥터, CDC, dbt 통합, 예약 |
| 기업 | 협상 가능 | 맞춤형(대량할인) | SSO/SAML, RBAC, VPN, 우선 지원, SLA |
| 비즈니스 크리티컬 | 협상 가능 | 관습 | PrivateLink, HIPAA 규정 준수, 전담 지원, 99.99% SLA |
Fivetran에서 MAR 계산이 작동하는 방식
MAR(월별 활성 행)은 행 수를 계산합니다. 별개의 한 달 안에 동기화됨 기본 키를 통해 추적되는 달력. 한 달에 30번 편집된 한 줄 30이 아닌 1 MAR로 계산됩니다. 이점: 빈도에 따라 비용이 폭발적으로 증가하지 않습니다. 동기화되지만 고유 레코드 수가 변경됩니다.
실제 예: 월 50,000건의 활성 주문을 보유한 회사이며, 카탈로그에 있는 500,000개의 제품(거의 업데이트되지 않음)이 50,000개에 대한 대부분의 비용을 지불합니다. 전체 제품 카탈로그가 아닌 매달 상태가 변경되는 주문입니다.
dbt vs Airbyte vs Fivetran: 어느 것을 선택해야 할까요?
dbt, Airbyte 및 Fivetran은 대체 도구가 아니라는 점을 이해하는 것이 중요합니다. 상호 배타적: 동일한 스택 내에서 서로 다른 문제를 해결합니다. 그렇죠 변환을 다루고 Airbyte와 Fivetran이 섭취를 담당합니다. 질문 정확하고: 섭취를 위한 Airbyte vs Fivetran?
Airbyte vs Fivetran: 시나리오별 비교
| 크기 | 에어바이트 오픈소스 | 에어바이트 클라우드 | Fivetran 표준 |
|---|---|---|---|
| 기본비용 | $0(인프라 제외) | 사용량에 따라 지불 | $5/연결/월 + 화요일 |
| 커넥터 | 600+ (커뮤니티 유지) | 600+ | 650+(엔터프라이즈급) |
| 커넥터 유지 관리 | 커뮤니티/내부팀 | 에어바이트 팀 | Fivetran 팀(SLA 보장) |
| 질병통제예방센터 | 지원됨 (Debezium) | 지원됨 | 지원됨(로그 기반) |
| 맞춤형 커넥터 | Python SDK(무료) | 파이썬 SDK | 맞춤형 커넥터 SDK(유료) |
| 거주 날짜 | 완료(자체 호스팅) | 지역별 | 지역별 |
| 설치 시간 | 1~4시간(인프라) | 30분 | 15분 |
| DBT 통합 | 수동/공기 흐름 | 토종의 | 네이티브(dbt 클라우드) |
| 다음에 이상적입니다. | 기술팀, 맞춤형 소스, 현지 GDPR | 기술에 능숙한 중소기업, 가변적인 예산 | 표준 SaaS 소스를 갖춘 SME/기업 |
선택을 위한 실제 규칙
- Fivetran을 사용하세요 소스가 표준 SaaS(Salesforce, HubSpot, Shopify, Stripe, Google Analytics, Facebook Ads) 팀은 거래를 원하지 않습니다. 커넥터 유지 관리. 얻은 생산성은 비용만큼 가치가 있습니다.
- 에어바이트 클라우드 사용 표준 소스와 사용자 정의 소스가 혼합되어 있는 경우 또는 시작 단계이고 종량제 결제로 비용을 관리하고 싶습니다.
- Airbyte 오픈 소스 사용 GDPR/데이터 상주 요구 사항이 있는 경우 타사 인프라를 통한 데이터 전송을 방지하거나 내부적으로 작성된 커넥터가 필요한 고도로 사용자 정의된 소스.
최신 ELT 참조 아키텍처
모든 구성 요소를 결합한 이것이 선도 기업이 채택하는 현대적인 ELT 아키텍처입니다. 오늘. 스택의 각 레이어에는 특정 목적과 참조 도구가 있습니다.
최신 ELT 스택: 레이어별
| 레이어 | 기능 | 주요 도구 |
|---|---|---|
| 1. 섭취 | 원시 데이터를 추출하여 웨어하우스에 로드 | Fivetran, Airbyte, Stitch, 사용자 정의 스크립트 |
| 2. 스토리지(원시) | 수정되지 않은 원시 데이터(브론즈 레이어) | 스노우플레이크, BigQuery, Databricks, Redshift |
| 3. 변신 | SQL 모델, 테스트, 문서화, 계보 | DBT 코어, DBT 클라우드 |
| 4.서빙(골드) | 분석 및 ML에 최적화된 테이블 | Snowflake, BigQuery, Databricks(웨어하우스) |
| 5. 오케스트레이션 | 스케줄링, 종속성, 모니터링 파이프라인 | Airflow, Dagster, Prefect, dbt 클라우드 |
| 6. BI 및 보고 | 대시보드, 임시 쿼리, 셀프 서비스 분석 | Looker, 메타베이스, Power BI, Tableau |
| 7. 데이터 품질 | 모니터링, 경고, 이상 탐지 | DBT 테스트, Great Expectations, 몬테카를로 |
# Esempio: Pipeline ELT completa orchestrata con Dagster
# Dagster definisce i job come grafo di asset
from dagster import asset, AssetIn, define_asset_job, ScheduleDefinition
# Asset 1: Raw data (caricato da Fivetran/Airbyte - esterno a Dagster)
# Dagster può "osservare" le tabelle caricate da Fivetran come asset esterni
@asset(
group_name="raw",
description="Ordini grezzi caricati da Fivetran (ERP)"
)
def raw_orders():
# Fivetran scrive qui automaticamente ogni ora
# Questo asset "dichiara" la tabella per il lineage visuale
pass
# Asset 2: dbt staging (trasformazione con dbt)
@asset(
group_name="staging",
deps=["raw_orders"],
description="Ordini puliti e standardizzati (modello dbt stg_orders)"
)
def stg_orders(context):
# Esegue il modello dbt stg_orders
context.log.info("Running dbt model: stg_orders")
# In pratica: dbt_cloud_run_op o subprocess dbt run --select stg_orders
return {"rows_processed": 15000}
# Asset 3: dbt marts (modello gold pronto per il business)
@asset(
group_name="marts",
ins={"staging": AssetIn("stg_orders")},
description="Fatturato mensile per il reporting finance"
)
def fct_orders_monthly(context, staging):
context.log.info(f"Building monthly metrics from {staging['rows_processed']} rows")
# dbt run --select fct_orders_monthly
return {"mart_rows": 360} # 30 giorni * 12 segmenti regionali
# Scheduling: esegue ogni ora, aggiorna tutti gli asset
elt_pipeline_job = define_asset_job(
name="elt_pipeline",
selection=["stg_orders", "fct_orders_monthly"]
)
elt_schedule = ScheduleDefinition(
job=elt_pipeline_job,
cron_schedule="0 * * * *", # Ogni ora
execution_timezone="Europe/Rome"
)신뢰할 수 있는 데이터 파이프라인을 위한 모범 사례
데모에서 간단하게 작동하는 ELT 파이프라인을 구축합니다. 다음과 같은 파이프라인을 구축하세요. 시간이 지남에 따라 팀이 확장하고, 모니터링하고, 유지 관리하려면 규율과 확립된 엔지니어링 관행을 적용합니다.
1. 계층화 및 명명 규칙
아키텍처를 반영하는 명확하고 일관된 dbt 디렉터리 구조를 채택합니다. 계층형(메달리온 또는 동급):
# Struttura di progetto dbt raccomandata
dbt_project/
├── models/
│ ├── staging/ # Layer Silver: pulizia sorgenti
│ │ ├── erp/
│ │ │ ├── stg_orders.sql
│ │ │ ├── stg_customers.sql
│ │ │ └── schema.yml # Test + documentazione
│ │ ├── crm/
│ │ │ ├── stg_contacts.sql
│ │ │ └── schema.yml
│ │ └── ecommerce/
│ │ ├── stg_sessions.sql
│ │ └── schema.yml
│ ├── intermediate/ # Modelli intermedi (join complesse)
│ │ ├── int_customer_orders.sql
│ │ └── schema.yml
│ └── marts/ # Layer Gold: pronti per il business
│ ├── finance/
│ │ ├── fct_orders_monthly.sql
│ │ ├── fct_revenue_by_product.sql
│ │ └── schema.yml
│ ├── marketing/
│ │ ├── fct_campaign_performance.sql
│ │ └── schema.yml
│ └── operations/
│ ├── fct_fulfillment_kpis.sql
│ └── schema.yml
├── seeds/ # Dati statici (tabelle di lookup, mapping)
│ ├── country_codes.csv
│ └── product_categories.csv
├── snapshots/ # SCD Type 2 (Slowly Changing Dimensions)
│ └── snap_customers.sql
├── tests/ # Test custom SQL
│ └── assert_revenue_positive.sql
├── macros/ # Macro Jinja riutilizzabili
│ ├── generate_schema_name.sql
│ └── audit_columns.sql
└── dbt_project.yml # Configurazione globale2. 품질 계약으로서의 테스트
DBT 테스트는 선택 사항이 아닙니다. 이는 변환을 보장하는 계약입니다. 신뢰할 수 있는 데이터를 생산합니다. 모든 모델에는 최소한 다음 테스트가 있어야 합니다.
- 기본 키의 고유 + not_null: 각 모델의 무결성을 보장합니다.
- 관계: 모델 간의 참조 무결성을 확인합니다.
- 허용_값: 범주형 필드에 유효한 값만 포함되어 있는지 확인하세요.
- 소스의 신선도: 데이터가 일정대로 업데이트되지 않으면 경고합니다.
- dbt_utils.expression_is_true: 비즈니스별 제약 조건(예: 수익 >= 0)
3. 데이터 파이프라인의 버전 관리 및 CI/CD
# .github/workflows/dbt-ci.yml
# CI/CD per validare i modelli dbt a ogni PR
name: dbt CI Pipeline
on:
pull_request:
branches: [main]
paths:
- 'dbt_project/**'
jobs:
dbt-lint-and-test:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v4
- name: Setup Python
uses: actions/setup-python@v4
with:
python-version: '3.11'
- name: Install dbt
run: |
pip install dbt-snowflake==1.8.0
pip install sqlfluff==3.0.0
- name: dbt debug (connection test)
run: dbt debug
env:
DBT_SNOWFLAKE_ACCOUNT: {{ secrets.SNOWFLAKE_ACCOUNT }}
DBT_SNOWFLAKE_USER: {{ secrets.SNOWFLAKE_USER }}
DBT_SNOWFLAKE_PASSWORD: {{ secrets.SNOWFLAKE_PASSWORD }}
DBT_SNOWFLAKE_DATABASE: DBT_CI_DB
DBT_SNOWFLAKE_SCHEMA: CI_{{ github.event.pull_request.number }}
- name: sqlfluff lint (SQL style check)
run: sqlfluff lint models/ --dialect snowflake
- name: dbt compile (syntax check)
run: dbt compile
- name: dbt run (solo modelli modificati)
run: dbt run --select state:modified+
env:
DBT_DEFER_TO_PROD: true
- name: dbt test (test sui modelli modificati)
run: dbt test --select state:modified+
- name: dbt docs generate
run: dbt docs generate
- name: Cleanup CI schema
if: always()
run: dbt run-operation drop_schema --args '{"schema": "CI_{{ github.event.pull_request.number }}"}'4. 데이터 신선도 모니터링
아무도 망가졌다는 것을 모르는 망가진 ELT 파이프라인은 파이프라인이 없는 것보다 더 나쁩니다. 데이터 최신성에 대한 사전 예방적 모니터링은 스택의 필수적인 부분이어야 합니다.
ELT 파이프라인에서 피해야 할 안티패턴
- 테스트하지 않은 모델: 하나 이상의 고유 + not_null 테스트가 없는 dbt 모델 그리고 시한폭탄. 조만간 보고서가 무효화되는 중복 또는 null 데이터가 생성될 것입니다.
- Schema.yml이 없습니다: 문서화 없이 모델은 6개월이 지난 저자를 포함하여 그것을 쓰지 않은 사람은 이해할 수 없습니다.
- 항상 전체 새로 고침: 대신 항상 전체 테이블을 다시 로드하세요. 증분 추가/업서트를 수행하는 것은 대규모 데이터 세트의 경우 비용이 많이 들고 취약합니다.
- 스테이징 레이어의 비즈니스 로직: 스테이징은 깨끗하고 표준화하다. 집계 및 비즈니스 논리는 마트로 이동합니다. 레이어를 섞으세요 관리하기 어려운 종속성을 만듭니다.
- 날짜 계보 무시: 보고서에 잘못된 숫자가 표시되면 문서화된 계보 추적이 없으면 문제를 해결하는 데 몇 시간이 걸립니다. dbt 문서를 사용하면 원하는 결과를 얻을 수 있습니다. 단 몇 번의 클릭만으로 소스로 이동할 수 있습니다.
- 신선도에 대한 알림 없음: Fivetran이 동기화를 중지하는 경우 밤에 아무도 모니터링하지 않으면 아침 보고서에는 어제의 데이터가 표시됩니다. 비즈니스 사용자에게는 경고가 표시되지 않습니다.
이탈리아 중소기업을 위한 권장 사항
이탈리아 SME에게는 데이터 파이프라인 환경이 부담스러워 보일 수 있습니다. 제한된 리소스와 소규모 팀. 좋은 소식은 전체 스택을 채택할 필요가 없다는 것입니다. 즉시. 다음은 세 단계로 구성된 점진적인 경로입니다.
중소기업을 위한 채택 경로(3단계)
| 단계 | 타임라인 | 권장 스택 | 월별 비용 |
|---|---|---|---|
| 1단계: 기초 | 1~3개월 | Fivetran 무료 + BigQuery 샌드박스 + dbt 코어 | €0 - €200 |
| 2단계: 생산 | 4~9개월 | Fivetran Standard + Snowflake/BigQuery + dbt Core + Airflow 관리형 | €800 - €3,000 |
| 3단계: 계단 | 10개월 이상 | Fivetran Enterprise + Snowflake + dbt 클라우드 + Dagster 클라우드 | €3,000 - €15,000 |
1단계 - 기초: Fivetran의 무료 요금제 시작하기(500,000MAR/월) 2~3개의 핵심 소스(ERP, CRM, 전자상거래)를 연결합니다. 해당 버전에서 BigQuery 사용 샌드박스(월별 최대 10GB 스토리지 + 1TB 쿼리 무료). 로컬로 dbt Core 설치 처음 10~15개의 패턴을 작성하세요. 목표는 패턴을 배우고 가치를 입증하는 것입니다. 초기 투자 없이 사업을 진행합니다.
2단계 - 생산: PoC가 가치를 입증하면 다음으로 확장하세요. 여러 커넥터를 관리하고 SLA를 통해 클라우드 웨어하우스로 이동하는 Fivetran Standard (Snowflake 또는 BigQuery 프로덕션) 및 Airflow 관리로 조정 추가 (GCP의 Cloud Composer 또는 AWS의 MWAA). 월 비용이 저렴하고 효과가 좋습니다. 비즈니스에 대해 측정할 수 있습니다.
3단계 - 계단: 데이터 팀이 3~5명으로 성장하면 성과가 좋습니다. 협업 IDE 및 자동 CI/CD를 위해 dbt Cloud를 추가하고 다음을 위해 Dagster Cloud를 추가합니다. 관찰 가능성을 갖춘 더욱 정교한 오케스트레이션. 이 시점에서 파이프라인은 다음과 같습니다. 전문 엔지니어링 표준에 따라 관리되는 전략적 기업 자산입니다.
결론 및 다음 단계
ETL에서 ELT로의 진화는 단순히 문자 순서의 변화가 아닙니다. 파이프라인을 설계, 개발 및 유지 관리하는 방식의 근본적인 변화 회사 데이터. 클라우드는 컴퓨팅을 탄력적이고 편리하게 만들어 쓸모없게 만들었습니다. 전용 서버의 사전 로딩 변환 모델.
최신 dbt + Airbyte/Fivetran + 클라우드 웨어하우스 스택은 최첨단 기술을 나타냅니다. 2025년에 출시되었으며 스타트업부터 Fortune 500대 기업까지 수천 개의 기업에서 채택되었습니다. 구체적인 이점은 측정 가능합니다. 코드 버전 지정이 가능한 파이프라인, 자동 테스트 자동으로 생성된 데이터, 문서 및 계보의 품질을 보장합니다. 선행 투자가 필요하지 않고 비즈니스와 함께 성장하는 확장 가능한 비용.
기억해야 할 핵심 사항
- ETL은 죽지 않았습니다. 그럴 필요가 없는 민감한 데이터에는 여전히 의미가 있습니다. 낮은 대기 시간이 요구되는 클라우드 또는 온프레미스 레거시 소스로 암호화되지 않은 상태로 전송됩니다.
- ELT와 새로운 표준 클라우드 우선 아키텍처의 경우: 모든 것을 원시 로드하고, 당신이 가장 강력한 힘을 가지고 있는 곳(창고)을 변화시키세요.
- DBT 변환 계층: 소프트웨어 엔지니어링 모범 사례 제공 (버전 관리, 테스트, 문서화)을 SQL 세계로 확장합니다.
- 에어바이트 맞춤형 소스를 갖춘 기술팀을 위한 오픈 소스 선택 또는 GDPR 데이터 상주 요구 사항.
- 파이브트란 장치에 대한 유지 관리가 필요 없는 사람들을 위한 관리형 선택 표준 SaaS 소스(Salesforce, HubSpot, Shopify 등)에 대한 커넥터입니다.
- 이탈리아 중소기업의 경우: Fivetran Free + BigQuery + dbt Core로 시작하세요 전체 인프라에 투자하기 전에 가치를 검증합니다.
시리즈의 다음 기사에서는 다음 내용을 다룹니다.파이프라인 조정: Airflow, Dagster 및 Prefect를 비교했습니다. dbt가 변환 엔진이고 Airbyte/Fivetran인 경우 그들은 섭취 시스템이자 조정자이며 모든 것을 조정하는 두뇌입니다. 누가 무엇을 하는지, 언제, 어떤 순서로, 문제가 발생하면 어떻게 해야 하는지. 그럴만한 가치가 있는 중요한 구성 요소 헌신적인 토론.
실제 연습: 30분 만에 DBT 코어 설정
다음 글로 넘어가기 전에 웨어하우스에 dbt Core를 설치해 보세요. 기존(무료 BigQuery 샌드박스도 있음):
# 1. Installa dbt con il profilo per il tuo warehouse
pip install dbt-bigquery # per BigQuery
# oppure: pip install dbt-snowflake, dbt-redshift, dbt-duckdb
# 2. Crea un nuovo progetto dbt
dbt init mio_progetto_dbt
# 3. Configura il profilo (~/.dbt/profiles.yml per BigQuery)
# mio_progetto_dbt:
# target: dev
# outputs:
# dev:
# type: bigquery
# method: oauth
# project: mio-progetto-gcp
# dataset: dbt_dev
# threads: 4
# timeout_seconds: 300
# 4. Testa la connessione
cd mio_progetto_dbt
dbt debug
# 5. Crea il tuo primo modello
cat > models/staging/stg_example.sql << 'EOF'
SELECT
id,
name,
created_at,
UPPER(TRIM(email)) AS email_normalized
FROM {{ source('raw', 'users') }}
WHERE id IS NOT NULL
EOF
# 6. Esegui e testa
dbt run
dbt test
dbt docs generate
dbt docs serve # Apre il lineage visuale su http://localhost:8080