ETLとコネクタ

従来のETLでは、データを抽出し、外部サーバーで変換してから、クリーンな結果をロードします。最新のデータウェアハウスでは最後の2段階が逆になります。ELTでは、まず生データを抽出してロードし、その後SQLを使ってデータウェアハウス内で変換します。

ELTが優れているのは、データウェアハウスのコンピュートが安価で、柔軟に拡張できるためです。生データを永久に保持でき、ビジネスロジックが変わったときに再変換でき、早すぎるクリーンアップによって詳細を失うこともありません。

コネクタはELを担うエンジンです。データソースのAPIに対して認証を行い、スケジュールに従ってレコードを取得し、ソースのスキーマに対応するデータウェアハウステーブルへ書き込みます。ページネーション、レート制限、リトライ、スキーマ変更にも対応するため、壊れやすいスクリプトを自分で書く必要がありません。

マネージドコネクタを使えば、1週間かかるAPI連携の実装を、OAuthの数回のクリックと同期頻度の設定だけで済ませられます。

マーケティング向けの構築済みコネクタに特化したプラットフォームがいくつかあります。FivetranとAirbyteは、数百のデータソースに対応する汎用的なELツールです。Funnel、Supermetrics、Adverityは、特にマーケティングデータや広告データに重点を置いています。

トレードオフは、マネージドツールには費用がかかる（多くの場合、行数またはアクティブなデータソース数に応じて課金される）一方で、エンジニアリングの時間を節約でき、APIが変更されても自動復旧できることです。変化の激しい広告APIでは、この信頼性に大きな価値があります。

ほとんどのマーケティングデータソースはOAuth 2.0で認証します。パスワードを共有せずに、コネクタへ範囲を限定した、取り消し可能なアクセス権を付与できます。コネクタはリフレッシュトークンを保存し、アクセス権を自動的に更新します。

トークンの有効期限と権限スコープを確認してください。よくある障害は、接続を設定したマーケターが退職し、OAuthの許可を取り消した結果、下流にあるすべての同期が気付かないうちに停止することです。

フルロードでは、同期のたびにすべてのレコードを再取得します。単純ですが、大規模になると高コストで時間もかかります。増分ロードでは、前回の同期以降に変更されたレコードだけを、updated_atのタイムスタンプのようなカーソルを使って取得します。

本番環境のパイプラインの多くは、データ量に対応するため増分同期を使い、削除や修正を検出するために定期的なフルリフレッシュを行います。カーソルを正しく選ぶことが、新鮮なデータと気付かない欠落を分けるポイントです。

ソースAPIは予告なく変更されます。プラットフォームがフィールド名を変更したり、列を追加したり、データ型を変更したりすることがあります。これがスキーマドリフトで、下流のモデルやダッシュボードを気付かないうちに壊します。

優れたコネクタは、新しい列を自動検出して追加し、型の変更を記録し、互換性を壊す変更を通知します。それでも、変換レイヤーにはテストを用意し、ドリフトがCEOのダッシュボードに誤った数値として現れるのではなく、テストの失敗として表面化するようにしてください。

マーケティングデータはどの程度新鮮である必要があるでしょうか。支出レポートなら日次で十分ですが、実施中のキャンペーンの進捗管理には日中の更新が重要です。同期頻度を上げるほど、コネクタとデータウェアハウスのコストは増加します。

意思決定に合わせて頻度を決めてください。予算進捗ダッシュボードは1時間ごとに同期する一方、毎月更新するLTVコホートモデルなら夜間ロードだけで十分かもしれません。誰も活用しない鮮度に費用をかけないでください。

コネクタは専用の生データ用スキーマに書き込む必要があります。そこは変更せず、追加のみ可能にしてください。アナリストやBIツールが生データテーブルを直接クエリできるようにしてはならず、データをその場で変換してもいけません。

生データゾーンは保険です。変換にバグがあったり、ビジネスロジックが変わったりしても、APIから再取得せずに生データから再処理できます。変更不可能なシステムオブレコードとして扱ってください。

パイプラインは逆方向にも動かせます。リバースETLでは、データウェアハウスのモデリング済みデータを運用ツールへ戻します。たとえば、計算したLTVセグメントをMetaに送って類似オーディエンスを作成したり、解約スコアをSalesforceに送ったりします。

これでループが完成します。データウェアハウスはレポートの行き止まりではなくなり、より効果的なターゲティングやパーソナライゼーションをチャネルへ戻す頭脳になります。

各APIに対して独自のPython抽出処理を作れば、完全な制御が可能で、行数に応じた料金もかかりません。しかしその場合、認証の更新、レート制限、ページネーション、スキーマドリフト、そして午前2時にAPIが変更されたときのオンコール対応まで自分たちで担うことになります。

多くのチームは標準的なデータソースにはマネージドコネクタを購入し、特殊なシステムや独自システムに限ってカスタム実装を行います。通常、エンジニアリングの時間はコネクタのサブスクリプション予算よりも希少です。

静かなパイプライン障害は、明らかな障害よりも深刻です。人々が古いダッシュボードを信頼し続けてしまうからです。本番環境のELには、同期成功のアラート、鮮度チェック、行数の異常検知による監視が必要です。

鮮度のSLAを設定し（たとえば、広告費データは24時間以上古くなってはならない）、違反したらアラートを出してください。データへの信頼は、データが古くなった瞬間を把握することで築かれます。会議で初めて発見するものではありません。

データウェアハウスのコンピュートは安価で柔軟に拡張でき、ビジネスロジックが変わったときに再モデリングできるよう、ソースの詳細を完全に保持したいとします。どのロード方式が適しており、変換はどこで行うべきでしょうか。

コネクタは、データソースへの認証、増分同期やスキーマドリフトへの対応、生データの変更不可能なゾーンへの格納を担うELエンジンです。Fivetran、Airbyte、Supermetricsなどのマネージドツールは、サブスクリプション費用と引き換えに信頼性を提供します。

モダンデータスタックでは、データウェアハウス内で変換するELTが主流です。リバースETLによってインサイトをチャネルへ戻し、パイプラインの監視と鮮度SLAを、任意ではなく必須の仕組みとして扱います。