ETL 対モダン ELT: dbt、Airbyte、Fivetran
データ パイプラインは、データ駆動型アーキテクチャの循環システムです。流れがなければ ソースからウェアハウス、機械学習モデルまで、信頼性が高く、文書化され、テストされたデータ 不正確な予測を出し、事業報告書には一貫性のない数字と決定が示される 戦略は不安定な基盤に基づいています。しかし、イタリア企業の大多数では、 データ パイプラインは依然として cron でスケジュールされた SQL スクリプトの複雑な状態であり、Excel シートが更新されています 手作業で行われ、ETL プロセスは数十年前に構築され、誰も触れることを敢えてしませんでした。
過去 5 年間で風景は根本的に変わりました。クラウドコンピューティングの出現により、 データ移動の基本的なパラダイムは覆されました。データを変換することはもはや意味がありません。 前に 従来の ETL で行われていたように、それらを倉庫にロードするには、 クラウド コンピューティングの能力はごくわずかなコストで利用でき、最新の倉庫はパフォーマンスを向上させることができます。 複雑な変換を数秒で実行します。こうしてパラダイムが生まれた ELT (抽出、ロード、 トランスフォーム)、変換をシフトすることで演算の順序を逆にします。 dentro 倉庫そのもの。
データ パイプライン市場はこの変化を反映しています。ELT セグメントは 年間 26%、データ パイプライン ツール市場全体は次のように推定されます。 2024 年には 120 億ドル、2030 年までに 480 億ドルに達すると予測されています。 ELT が俳優を管理し、ARR は前年比 50% の成長で 3 億ドルに達しました。 これはニッチなものではなく、新しい標準です。
この記事では、2 つのパラダイムを詳しく調査し、主要なツールを分析します。 市場 (dbt、Airbyte、Fivetran) に合わせて、完全なリファレンス アーキテクチャを構築し、 お客様のサイズとサイズに基づいて適切なスタックを選択するための実用的な推奨事項を提供します。 チームスキル。
この記事で学べること
- 従来の ETL と最新の ELT の基本的な違い、長所/短所、およびユースケース
- dbt (データ構築ツール) の仕組み: SQL モデル、テスト、ドキュメント、リネージ
- dbt コアと dbt クラウド: どちらを選択するか、またそのコストはどれくらいか
- Airbyte: セルフホスティングのためのオープンソース コネクタ、アーキテクチャ、および展開
- Fivetran: マネージド SaaS モデルと新しい MAR 価格設定 (2025)
- さまざまなビジネス シナリオにおける 3 つのツール間の詳細な比較
- リファレンス最新 ELT アーキテクチャ: Airbyte/Fivetran + Warehouse + dbt + BI
- テスト、文書化、パイプライン オーケストレーションのベスト プラクティス
従来の ETL: その仕組みと、もう十分ではない理由
ほぼ30年にわたり、ETL (抽出、変換、ロード) それはパラダイムだった 企業データの移動に主流です。このプロセスは、次の 3 つの連続したフェーズに分かれています。
- 抽出する： データはソース システムから抽出されます。通常、 OLTP データベース (ERP、CRM、電子商取引)、フラット ファイル (CSV、XML)、または外部 API。このフェーズでは次のようになります。 データを変更せずにそのまま保存します。
- 変身： 抽出されたデータは次のように変換されます。 中間システム、ステージング領域またはETLエンジンと呼ばれ、両方から分離されています ソースと宛先。変換には、クリーニング、正規化、 強化、集約、および倉庫基準への準拠。
- 負荷： 変換されたデータはデータ ウェアハウスにロードされます 目的地の。データ構造はすでに最終的なもので、分析クエリ用に最適化されています。
従来の ETL ツール
| 楽器 | ベンダー | 参考コスト | ターゲット |
|---|---|---|---|
| SSIS | マイクロソフト | SQL Server に含まれる | Microsoft エコシステムを利用する中小企業 |
| Informatica PowerCenter | 情報学 | 年間 50,000 ～ 500,000 ドル | エンタープライズバンキング/保険 |
| オラクルデータインテグレーター | オラクル | Oracle DBにバンドルされています | オラクルのエコシステム |
| Talend オープンスタジオ | Qlik | 無料 (コア) / 月額 $1,170+ | 中小企業、オープンソース |
| Pentaho データ統合 | 日立ヴァンタラ | フリー（CE）/カスタム（EE） | 中小企業、オープンソース |
これらのツールは機能します。それらはかつては (そして多くの場合は今も) システムのバックボーンでした 毎日数十億ユーロの取引を処理する重要な要素。しかし、それらには限界があります クラウド パラダイムによってその構造がますます明らかになってきています。
古典的なETLの構造的限界
従来の ETL が現代の状況で苦戦する理由
- 高価な外部コンピューティング: 変換は別のサーバーで行われます (ETL サーバー)、ピーク負荷に合わせてサイズを設定する必要があります。夜間バッチの場合 1 億行を処理する場合、サーバーはそれを処理できる十分な能力が必要です たとえ 1 日 22 時間ほとんど非アクティブなままだったとしても。
- 変更の硬直性とコスト: 変換にフィールドを追加する SSIS では、ビジュアル フローの変更、ステージングでのテスト、リリースの調整が必要です。 目的地の倉庫を管理する人と。構造化されたチームの場合、これには数週間かかります。
- ネイティブのバージョン管理なし: ETL フローはテスト可能なコードではなく、 アプリケーションソフトウェアと同様にバージョン管理が可能です。ガバナンスが難しくなる：誰が変わったのか この変身？いつ？なぜ？
- 複雑なデバッグ: 変換によって予期しない結果が生じた場合、 視覚的な ETL フローを通じて問題を追跡するには、数時間かかる場合があります。はありません 各列の由来を示す標準の「データ系統」。
- 倉庫の電力の無駄: Snowflake または BigQuery に投資する 彼らの計算能力には年間数万ユーロがかかりますが、それはそれで終わりです 別のサーバーでデータを処理します。 ELT パラダイムは、倉庫自体が そして最も効率的な変換エンジン。
最新の ELT: クラウドがすべてを変えた理由
L'ELT (抽出、ロード、変換) 最後の 2 つのフェーズ、つまりデータの順序を逆にします。 それらはまず供給源から抽出され、生の状態で倉庫に積み込まれます。 その後、倉庫自体のコンピューティング能力を使用して変換されました。
このパラダイムシフトは、次の 3 つの要素が集まって可能になりました。
- 経済的なクラウドストレージ: Amazon S3、Azure Blob Storage、Google Cloud Storage 料金は 1 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 は、データ アナリストが変換を記述する方法を変革します。 dbt は、まばらで構造のない SQL プロシージャの代わりに、インスピレーションを受けた開発フレームワークを導入しています。 バージョン管理されたモデル、自動テスト、生成されたドキュメントを使用したソフトウェア エンジニアリングまで 自動的に。
基本的かつシンプルなコンセプト: すべて dbt テンプレートと .sql ファイル 含まれている SELECT。 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 の最も重要な強みの 1 つは、ネイティブ テスト システムです。 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 には 2 つのバリエーションが存在します。 DBTコア (オープンソース、無料) dbtクラウド (SaaS 管理、有料)。選択はニーズに応じて異なります インフラストラクチャと高度な機能の面でチームの優れた評価を獲得します。
dbt コアと dbt クラウド: 完全な比較
| 機能性 | dbt コア (オープンソース) | DBTクラウドチーム | DBTクラウドエンタープライズ |
|---|---|---|---|
| 料金 | 無料 | 1 シートあたり月額 100 ドル + 15,000 を超えるモデルの場合は 0.01 ドル | カスタム (営業担当者にお問い合わせください) |
| ジョブの実行 | マニュアル / 外部オーケストレーター (Airflow、Dagster) | ネイティブ スケジューラー、統合された CI/CD | 高度なスケジューラー + SLA モニタリング |
| ウェブIDE | いいえ (ローカルエディターのみ) | dbt クラウド IDE (ブラウザベース) | DBTクラウドIDE |
| ドキュメント | ローカルで生成 (dbt docs generated) | 自動的にホストされる | ホスト型 + 高度なデータ カタログ |
| ビジュアル系譜 | 地元 | クラウドでホストされ、共有可能 | クラウドホスト + クロスプロジェクト系統 |
| チームのコラボレーション | Git 経由 (手動) | マルチユーザーの PR ベースのワークフロー | RBAC、SSO、監査ログ |
| セマンティックレイヤー | No | 含まれています (5,000 メトリクス/月) | 含まれています (20,000 メトリクス/月) |
| dbtメッシュ | No | 限定 | 完了 (プロジェクト間の参照) |
| SOC 2 準拠 | 該当なし (自己管理) | 付属 | 付属 + プライベートリンク |
| に最適 | 技術チームは予算が限られており、すでに Airflow を導入しています | ETL インフラストラクチャを使用しないチーム 2 ～ 20 名 | エンタープライズ、マルチチーム、厳格なコンプライアンス |
実際的な推奨事項: 1 ～ 3 人のデータ エンジニアのチームを持つイタリアの中小企業は、まず始めるべきです。 と dbt コア + エアフローまたはダグスター、無料で完全な柔軟性を提供します。 チームが成長した場合、またはオーケストレーション インフラストラクチャの管理を避けたい場合は、 dbtクラウド 開発者シートが 2 ～ 3 つあると、すでに便利になります。
Airbyte: オープンソースの取り込みレイヤー
dbt が T ELT での (変換)、 エアバイト 管理する の E （抽出）そして L (読み込み中)。 2020 年に設立され、現在もその先へ 1 億 8,000 万ドルの資金調達、Airbyte、そして最も広く採用されているオープンソース データ統合プラットフォーム 市場の、 600 以上の事前構築済みコネクタ およびビルドする Python SDK カスタムコネクタ。
競合他社に対する Airbyte の主な強みは、以下の組み合わせです。 オープンソース (ベンダーロックインゼロ、コード変更可能) アーキテクチャを採用 リアルタイムのデータベース レプリケーションのための Change Data Capture (CDC) をサポートするクラウドネイティブ。
エアバイトのアーキテクチャ
Airbyte は、連携して動作するいくつかのコンポーネントで構成されています。あらゆる同期がやってくる によって実行される 労働者 これにより、2 つの別個の Docker コンテナがインスタンス化されます。 ソースコネクタ (ソースから読み取る) 目的地 コネクタ (宛先に書き込みます)。この 2 つの間でデータが流れるのは、 私は エアバイトプロトコル、標準の 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 は 3 つの展開モードを提供しており、それぞれに異なる特徴があります。 コスト、管理、メンテナンス:
Airbyte: オープンソース vs クラウド vs エンタープライズ
| 待ってます | オープンソース (セルフホスト型) | エアバイトクラウド | エアバイトエンタープライズ |
|---|---|---|---|
| 料金 | 無料（インフラストラクチャはお客様負担） | 従量課金制 (1 クレジットあたり 2.50 ドルから 10 ドル) | カスタム (営業担当者にお問い合わせください) |
| メンテナンス | チームから支払われる | エアバイト提供 | エアバイト提供 |
| コネクタ | 600以上 | 600以上 | 600++ プレミアム認定コネクタ |
| CDC | サポートされています | サポートされています | サポートされている + 高度な CDC |
| RBAC | 基本 | 付属 | 高度な (SSO、監査ログ) |
| ALS | 該当なし | 99.9% の稼働率 | 99.99% の稼働率 |
| に最適 | 技術チーム、限られた予算、機密データ | 運用を行わずにスピードを求める中小企業 | コンプライアンスを徹底した企業 |
# 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 はオープンソースの柔軟性と制御に重点を置いていますが、 ファイブトラン 反対の道を選択しました: 最大限のシンプルさ、メンテナンス不要、エンタープライズグレードのコネクタ ベンダーが完全に管理します。 Fivetran は 2012 年に設立され、現在この分野のリーダーです。 ELT は 3 億ドルの ARR、6,300 人以上の顧客、56 億ドルの評価額で経営を行っています。
Fivetran の価値提案は明確です: Fivetran と Salesforce、Shopify のコネクタ またはその他の SaaS システムは、Fivetran エンジニアの専任チームによって保守されます。 ソース API のすべての変更、すべての重大な変更、すべての更新を管理します。 スキーム。お客様は何もする必要はありません。
新しい Fivetran 価格モデル 2025
2025 年 3 月に、Fivetran は価格モデルを大幅に更新しました。 スターター プランとプライベート デプロイメント プランは廃止され、次の 4 つの階層に置き換えられました。 無料、標準、エンタープライズおよびビジネス クリティカル。請求指標 そのままです MAR (月間アクティブ行)、しかし計算は変わりました：今ではすべて 接続は個別に請求され、アカウントごとに集計されなくなりました。
Fivetran: 2025 年のプランと価格
| Piano | 火曜日を含む | 追加費用 | 主な特長 |
|---|---|---|---|
| 無料 | 500,000MAR/月 | 該当なし | すべての標準機能、最大 5,000 のモデル実行 |
| 標準 | 無制限（従量制） | 5 ドルの基本/接続 + MAR 価格 | 600 以上のコネクタ、CDC、dbt 統合、スケジューリング |
| 企業 | 交渉可能 | カスタム (ボリュームディスカウント) | SSO/SAML、RBAC、VPN、優先サポート、SLA |
| ビジネスクリティカル | 交渉可能 | カスタム | PrivateLink、HIPAA 準拠、専用サポート、99.99% SLA |
Fivetran での MAR 計算の仕組み
MAR (Monthly Active Row) は行をカウントします。 明確な 1か月以内に同期されました カレンダー、主キーを介して追跡されます。 1 か月に 30 回編集された行 30 ではなく 1 MAR としてカウントされます。利点: コストが頻度によって爆発的に増加しない 同期の度合いは変わりますが、一意のレコードの数は変化します。
実際の例: 毎月 50,000 件のアクティブな注文がある会社 カタログ内の 500,000 製品 (めったに更新されない) は、50,000 のほとんどの費用を支払います。 製品カタログ全体ではなく、毎月ステータスが変わる注文。
dbt vs Airbyte vs Fivetran: どれを選ぶべきですか?
dbt、Airbyte、Fivetran は、次のような代替ツールではないことを理解することが重要です。 相互に排他的です。同じスタック内で異なる問題を解決します。はい は変換を扱い、Airbyte と Fivetran は取り込みを扱います。質問 正しく、かつ: 摂取に関してはAirbyte対Fivetran?
Airbyte vs Fivetran: シナリオ別の比較
| サイズ | Airbyte オープンソース | エアバイトクラウド | ファイブトランスタンダード |
|---|---|---|---|
| 基本料金 | $0 (インフラストラクチャを除く) | 使用ごとに支払い | $5/接続/月 + 火曜日 |
| コネクタ | 600+ (コミュニティ維持) | 600以上 | 650+ (エンタープライズグレード) |
| コネクタのメンテナンス | コミュニティ/社内チーム | エアバイトチーム | Fivetran チーム (SLA 保証) |
| CDC | サポートあり (Debezium) | サポートされています | サポートあり (ログベース) |
| カスタムコネクタ | Python SDK（無料） | Python SDK | カスタムコネクタSDK（有料） |
| 滞在日 | 完了 (自己ホスト型) | 地域固有の | 地域固有の |
| セットアップ時間 | 1 ～ 4 時間 (インフラストラクチャ) | 30分 | 15分 |
| DBTの統合 | 手動 / エアフロー | ネイティブ | ネイティブ (dbt クラウド) |
| に最適 | 技術チーム、カスタム ソース、ローカル GDPR | テクノロジーに精通した中小企業、変動予算 | 標準の SaaS ソースを備えた中小企業/大企業 |
選択のための実践的なルール
- ファイブトランを使用する ソースが標準の SaaS (Salesforce、HubSpot、 Shopify、Stripe、Google Analytics、Facebook Ads) とチームは対処したくない コネクタのメンテナンス。得られる生産性にはコストに見合う価値があります。
- Airbyteクラウドを利用する 標準ソースとカスタム ソースが混在している場合、または 始めたばかりで、従量課金制でコストを管理したいと考えています。
- Airbyte オープンソースを使用する GDPR/データ所在地要件がある場合、 サードパーティのインフラストラクチャを介したデータ転送を防止するか、 内部的に作成されたコネクタを必要とする高度なカスタム ソース。
最新の ELT リファレンス アーキテクチャ
すべてのコンポーネントを組み合わせた、これが大手企業が採用する最新の ELT アーキテクチャです 今日。スタックの各層には、特定の目的と参照ツールがあります。
最新の ELT スタック: レイヤーごと
| レイヤー | 関数 | 主なツール |
|---|---|---|
| 1. 摂取 | 生データを抽出してウェアハウスにロードする | Fivetran、Airbyte、Stitch、カスタム スクリプト |
| 2. 保存（生） | 無修正生データ（ブロンズ層） | スノーフレーク、BigQuery、Databricks、Redshift |
| 3. 変身 | SQL モデル、テスト、ドキュメント、系統 | dbt コア、dbt クラウド |
| 4.サービング（ゴールド） | 分析と機械学習用に最適化されたテーブル | Snowflake、BigQuery、Databricks（ウェアハウス） |
| 5. オーケストレーション | スケジュール、依存関係、パイプラインの監視 | エアフロー、ダグスター、プリフェクト、dbt クラウド |
| 6. BI とレポート | ダッシュボード、アドホック クエリ、セルフサービス分析 | Looker、メタベース、Power BI、Tableau |
| 7. データ品質 | 監視、警報、異常検知 | dbt テスト、大いなる期待、モンテカルロ |
# 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 テストはオプションではありません。DBT テストは、変換が行われることを保証する契約です。 信頼できるデータを生成します。すべてのモデルには少なくとも次のテストが必要です。
- 主キーの unique + 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 パイプラインで避けるべきアンチパターン
- テストを行わないモデル: 少なくとも 1 つの一意の + not_null テストを持たない dbt モデル そして時限爆弾。遅かれ早かれ、重複データまたはヌルデータが生成され、レポートが無効になります。
- schema.yml が存在しない: ドキュメントがないと、モデルは次のようになります。 6か月後の著者を含め、それを書いていない人には理解できません。
- 常に完全に更新: 代わりに常にテーブル全体をリロードします 大規模なデータセットの場合、増分追加/更新/挿入はコストがかかり、脆弱です。
- ステージング層のビジネス ロジック: ステージングはクリーンアップするだけで済みます 標準化する。集計とビジネス ロジックはマートに行きます。レイヤーを混ぜる 管理が難しい依存関係が作成されます。
- 日付系統を無視する場合: レポートに間違った数値が表示された場合、 文書化された系統の追跡がなければ、問題の追跡には何時間もかかります。 dbt ドキュメントを使用すると、そこに到達できます 数回クリックするだけでソースにアクセスできます。
- 鮮度に関するアラートはありません: Fivetran が同期を停止した場合 夜に誰も監視していない場合、朝のレポートには昨日のデータが表示されます。 ビジネス ユーザーには警告は表示されません。
イタリアの中小企業への推奨事項
イタリアの中小企業にとって、データ パイプラインの状況は圧倒的に見えるかもしれません。 限られたリソースと小規模なチーム。良いニュースは、スタック全体を採用する必要がないことです。 すぐに。以下は 3 つのフェーズからなる進歩的なパスです。
中小企業向けの導入パス (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 エンタープライズ + Snowflake + dbt クラウド + Dagster クラウド | €3,000 - €15,000 |
フェーズ 1 - 基礎: Fivetran の無料プラン (月額 500,000 MAR) を始めましょう 2 ～ 3 つの重要なソース (ERP、CRM、電子商取引) に接続します。バージョンで BigQuery を使用する サンドボックス (最大 10 GB のストレージ + 1 TB のクエリ/月まで無料)。 dbt コアをローカルにインストールする 最初の 10 ～ 15 パターンを書きます。目標はパターンを学習し、価値を実証することです 初期投資なしでビジネスを始められます。
フェーズ 2 - 生産: PoC が価値を実証したら、次のようにスケールします。 Fivetran Standard で複数のコネクタを管理し、SLA 付きのクラウド ウェアハウスに移行 (Snowflake または BigQuery 本番環境)、Airflow 管理によるオーケストレーションを追加します (GCP 上の Cloud Composer または AWS 上の MWAA)。月々のコストが安く効果も抜群 ビジネス上で測定可能です。
フェーズ 3 - 階段: データチームが 3 ～ 5 人に成長すると、成果が上がります 共同IDEと自動CI/CD用にdbt Cloudを追加し、Dagster Cloudを追加します。 可観測性を備えたより洗練されたオーケストレーション。この時点でパイプラインは次のようになります。 専門的なエンジニアリング基準で管理される戦略的な企業資産。
結論と次のステップ
ETL から ELT への進化は、単に文字の順序が変更されただけではありません。 パイプラインの設計、開発、維持方法における根本的な変革 会社のデータ。クラウドによりコンピューティングは柔軟かつ便利になり、時代遅れになりました 変換モデルを専用サーバーに事前にロードします。
最新の dbt + Airbyte/Fivetran + クラウド ウェアハウス スタックは最先端技術を表しています 2025 年に設立され、新興企業からフォーチュン 500 企業に至るまで、何千もの企業に採用されています。 具体的な利点は、コードとしてバージョン管理可能なパイプライン、自動テストなど、測定可能です。 自動生成されたデータ、ドキュメント、リネージュの品質を保証します。 また、先行投資を必要とせず、ビジネスに応じて増加する拡張可能なコストも備えています。
覚えておくべき重要なポイント
- ETL は死んだわけではありません。 必要のない機密データには依然として意味があります。 暗号化されずにクラウドまたはオンプレミスのレガシー ソースに低遅延で転送します。
- ELT と新しい標準 クラウドファーストアーキテクチャの場合: すべてを生でロードし、 最も力のある場所 (倉庫) を変革します。
- dbt そして変換層: ソフトウェアエンジニアリングのベストプラクティスをもたらします (バージョン管理、テスト、ドキュメント) SQL の世界へ。
- エアバイト カスタム ソースを使用する技術チームにとってはオープンソースの選択 または GDPR のデータ所在地要件。
- ファイブトラン デバイスのメンテナンスをゼロにしたい人向けの管理された選択肢 標準の SaaS ソース (Salesforce、HubSpot、Shopify など) へのコネクタ。
- イタリアの中小企業向け: Fivetran Free + BigQuery + dbt Core から始める 完全なインフラストラクチャに投資する前に価値を検証します。
シリーズの次の記事では、以下について詳しく説明しますパイプラインオーケストレーション: エアフロー、ダグスター、プリフェクトを比較しました。 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