FlyDataの紹介

弊社(integrate.io)のデータ転送サービスは、実は２つに構成されております。
ここで主に取り扱っているのはETLであるXPlentyですが、ご覧のようにELTサービスであるFlyDataもあります。

本題へ入る前にここでFlyDataを簡単に紹介しましょう。
FlyDataは、主に MySQLなどのデータベースからAmazon Redshiftのようなデータウェアハウスへリアルタイムにデータを同期することに特化したクラウドベースのデータ統合サービスです。
CDC（Change Data Capture）技術を活用し、データベースの変更をほぼリアルタイムでDWHに反映できることが特徴でした。

主な特徴

リアルタイムCDCレプリケーション：データベースの場合データ変更を即座にキャプチャ
簡単なセットアップ：比較的少ない設定でレプリケーションを開始可能
データウェアハウスに特化：データウェアハウスへの同期に最適化された設計

長所	短所
リアルタイムに近いデータ同期が可能	対応先が限定的：主なデータウェアハウス、一部のデータベース、ファイルに対応
データウェアハウスに特化しているため、対象ユースケースでは高い効率	ELTのため、変換機能はなし：データの変換機能がなく、異常値の感知のみ可能
軽量なエージェントベースのアーキテクチャ	-

これでFlyDataについてざっとみてみました。

概要

現代のデータ環境では、単にデータを収集するだけでなく、収集したデータを分析・加工し、再び運用システムへ反映する循環型（Circular）データフローが重要になっています。

本記事では、以下の2つのツールを組み合わせてこの循環構造を実現する方法をご紹介します。

方向	ツール	役割
収集（Inbound）	Flydata(ELT)	各DB → DWH（Snowflake）へのデータ収集
配布（Outbound）	Xplenty(ETL)	DWH → 各DBへの加工データの逆送信

この2つを組み合わせることで、データ収集 → 中央集中分析 → 結果の逆配布という完結したデータ循環パイプラインを構築できます。

アーキテクチャの説明

下記の図は、循環型データ統合アーキテクチャの構成であり、その流れをこれから説明します。

ここで各々のコンポーネントの役割は下記の表の通りです。

コンポーネント名	役割	ツール名
ソース（レガシーサービス）	日々の業務データの蓄積	MySQL、PostgreSQL、Oracle等のデータベース、SaaSのRest API、社内用のRest API
ELTツール	変更が起きたデータを素早くDWHへ取り込み	FlyData
データウェアハウス	データ統合・保存、およびSQLベースの調整・計算処理	Snowflake、BigQuery、RedShift等
ETLツール	加工データの変換、各対象DBへのルーティング、調整データの逆配布	Xplenty
デスティネーション（レガシーサービス）	調整データの更新、分析データの蓄積	MySQL、PostgreSQL、Oracle等のデータベース、SaaSのRest API、社内用のRest API

各ステップの役割

では、循環型データ統合アーキテクチャの各々のステップをみてみましょう。

ステップ 1：ELT — Flydata によるデータ収集
- CDC（Change Data Capture）方式で各運用DBの変更内容をリアルタイムまたは準リアルタイムでSnowflakeへ連携
- データ変換なしでRawデータをまずDWHへ保存（ELTの核心）
- 複数の異種データベースを単一のDWHへ統合
ステップ 2：分析・計算 — Snowflake 内での処理
- 収集したRawデータをもとに、SQL View・Stored Procedure・dbtなどで 調整データ（Reconciled Data） を生成
- 例：在庫調整値、精算金額、集計済みユーザースコアなど
ステップ 3：ETL — Xplenty によるデータ逆配布
- XplentyのビジュアルパイプラインでSnowflakeの加工データを読み込み
- 必要な変換（フィールドマッピング、型変換、フィルタリング）を適用後
- 各運用DBへ Merge（Upsert）・Append・Truncate & Insert などの方式で逆送信

事例：ECプラットフォームの在庫・精算データ同期

事例の背景

複数のリージョン（日本・米国・韓国）に個別の運用DBを持つECサービス
各リージョンの決済データを中央で集計し、グローバル決済調整値を計算
計算した調整値を各リージョンのDBへ反映する要件がある

Step 1：Flydata で各リージョン DB → Snowflake へ収集

[JP MySQL] → (CDC) → Snowflake: raw.jp_payments
[US PostgreSQL] → (CDC) → Snowflake: raw.us_payments
[KR MySQL] → (CDC) → Snowflake: raw.kr_payments
[Snowflake]
データパイプラインの設定(FlyData上で)

Step 2：Snowflake でグローバル在庫調整値を計算

-- 例：全体在庫を基準に、リージョン別の調整数量を計算
CREATE OR REPLACE VIEW analytics.adjusted_payments AS
SELECT
payment_id,
'JP' AS region,
jp.amount - (global_avg.avg_amount * 0.3) AS adjusted_amount
...
...;
-- US、KR も同様のロジックを適用

Step 3：Xplenty で調整データ → 各リージョン DB へ逆配布

Xplenty パイプライン構成例：[Snowflake Source]
analytics.adjusted_payments
↓
[Filter コンポーネント]
region = 'JP' でフィルタリング
↓
[Select コンポーネント]
payment_id、adjusted_qty のフィールドマッピング・型変換
↓
[Database Destination: JP MySQL]
テーブル: payment_adjustment
モード: Merge（Upsert）by payment_id

JP MySQL・US PostgreSQL・KR MySQL それぞれに個別のXplentyパイプラインを構成、または単一パイプライン内で分岐処理
Xplentyのスケジューラで、Snowflakeの計算完了後に自動実行されるよう設定（依存関係チェーニング）

メリットとデメリット

メリット	説明
関心事の明確な分離	データ収集（Flydata）とデータ配布（Xplenty）の役割が明確に分かれており、各ツールの強みを最大限に活かせる
単一の信頼できる情報源（Single Source of Truth）の確保	Snowflakeを中央DWHとして活用することで、すべてのリージョン・サービスのデータが一か所で管理され、一貫した基準で計算dされる
コード不要のパイプライン管理	Xplentyのドラッグ＆ドロップ式ビジュアルパイプラインにより、複雑なETLロジックも非エンジニアが理解・修正できる
拡張性	新しいリージョンDBやサービスDBが追加された場合でも、Flydataの接続とXplentyパイプラインをそれぞれ追加するだけで容易に拡張できる
リアルタイム性の確保（ELT 区間）	FlydataのCDC方式はバッチ方式と比較してレイテンシを最小限に抑え、Snowflakeのデータを最新の状態に保つ
運用 DB への負荷を最小化	分析・計算処理がすべてSnowflake上で行われるため、運用DBに重い集計クエリが直接実行されない

デメリット	説明
逆配布（Write-back）の遅延発生	パイプライン全体のレイテンシが蓄積される・リアルタイム性が求められるため、決済・在庫引き当てなどのトランザクション処理には適していない
データループ（Loop）のリスク	逆配布されたデータが再びFlydataのCDCによって収集され、Snowflakeへ再流入する可能性があり、これを防ぐフィルタリングメカニズムを別途実装する必要がある
ツール間の運用複雑性の増加	Flydata・Snowflake・Xplentyの3システムを同時に運用するため、モニタリング・障害対応・コスト管理が複雑になる
2プラットフォーム分のコスト負担	ELTツール（Flydata）とETLツール（Xplenty）それぞれのライセンス・利用コストが発生し、Snowflakeのコンピューティングコストも加わる
スキーマ不一致のリスク	送信元DB → Snowflake → 送信先DB の間でカラム名・データ型・NULL処理方式が異なる場合、マッピングエラーが発生する可能性がある

注意点

データループの防止（最重要）
- 逆配布データには出所を識別できるメタカラム（source_system、is_adjusted、updated_by など）を追加してください。
- FlydataのCDCフィルター設定またはSnowflakeのViewロジックにおいて、逆配布データを再収集対象から除外する処理を必ず実装してください。
冪等性（Idempotency）の保証
- Xplentyの逆配布パイプラインが重複実行されてもデータが二重挿入されないよう、必ずMerge（Upsert）モードと明確な*主キー（PK）*を設定してください。
実行順序・依存関係の管理
- Snowflakeの計算（Viewの更新、dbt runなど）が完了した後にのみXplentyパイプラインが実行されるよう、スケジュールまたは依存関係トリガーを設定してください。
- Xplentyの Dependent Execution または Webhook Trigger 機能を活用することができます。
エラー発生時の部分ロールバック戦略
- 逆配布の途中で一部のDBにのみデータが書き込まれ、残りで失敗した場合、データの不整合が発生します。
- Xplentyの*単一トランザクションモード（Single Transaction Mode）*または Pre/Post-action SQL を活用してロールバック戦略を策定してください。
モニタリングとアラート設定
- FlydataとXplenty双方に*障害通知（Hook）*を設定し、パイプラインのどの区間でエラーが発生しても即座に検知できるようにしてください。
- Xplentyの Slack・PagerDuty・Email Hook を活用すると効果的です。
機密データの取り扱い
- 個人情報（PII）・金融情報などが含まれるデータを逆配布する場合、Xplentyの Select または Filter コンポーネントを使用して不要な機密フィールドを除外またはマスキング処理してください。

まとめ

Flydata（ELT）とXplenty（ETL）を組み合わせた循環型データパイプラインは、中央集中型のデータ管理と運用システムへのデータ最新化を同時に実現できる強力なアーキテクチャです。

このアーキテクチャは、ECプラットフォーム・金融システム・マルチリージョンSaaSサービスなど、複数の運用データソースを持ちながら中央で統合・計算した結果を各システムへ還元したいケースに特に有効です。

ただし、リアルタイムトランザクション処理や厳密なデータ一貫性が求められる用途には適していないため、要件に応じた適切なアーキテクチャ設計が重要です。