クラウドデータ連携のバッチとリアルタイムって、どこが違う？
本記事はCDataが提供する「CData Software Blog」に掲載された「クラウドデータ連携の「バッチ連携」と「リアルタイム連携」の比較」を再編集したものです。
クラウドデータ連携には「バッチ連携」と「リアルタイム連携」があります。データをSaaS から一度DB やストレージに保存して、使いたいツールから保存されたデータにアクセスする方法がバッチ連携で、ツールから直接データソースであるSaaS を直接クエリする方法がリアルタイム連携です。
本記事は、Qiita CData Advent Calendar 2022 の5日目の記事です。
CData では、CData Sync というデータパイプラインツールとCData Driver / Connectors という製品を提供していますが、CData Sync を使うのはバッチ連携、Drivers / Connectors を使うのはリアルタイム連携です。実はお客様からも「Sync とDriver / Connector のどちらでも実現可能ということですが、どちらを使って連携すればいいのですか？」という質問を頂くことが多いですので、以下は回答をしている内容です。
CData 製品ではなくても、データ連携にはバッチ方式とリアルタイム方式があることを認識していれば、シナリオに合わせた方法を探すことができ、よりよい構成を作ることが可能になります。
本記事では、Salesforce のデータにBI ツールから接続したい、というケースをもとにバッチ連携とリアルタイム連携のメリット・デメリットを比較してみました。
はじめにバッチ連携とリアルタイム連携はどのような実装例を指すのか、Salesforce データをBI から使うというユースケースを元にを見て見ましょう。
1. バッチ連携とは？
バッチ連携・ETL 連携という呼ばれ方があります。以下の図のように間にETL ツールがあり、ETL ツールがSalesforce データを取得し、DB にデータをバッチで保存します。BI ツールからはDB に格納されている同期されたSalesforce のデータを参照しにいきます。
データ保存先のDB はデータレイクとかDWH と呼ばれます。その定義の話はここではしません。
CData Sync でDB にデータを反復複製する方法がこれにあたります。
https://www.cdata.com/jp/kb/tech/salesforce-sync-bigquery.rst
ほかにもAmazon Glue、Google Cloud Data Fusion、Azure Data Factory などのETL サービスを使う方法もあります。
バッチ連携はETL ツールにとどまらず、Python などのスクリプトでCSV を落としたり、手動でCSV を落としてBI ツールにCSV をアップして使う方法も、一度間でCSV という形でデータが保存されれいるのでバッチ連携です。
とにかく間にデータが保存されているものはバッチ連携です。
2. リアルタイム連携とは？
次に、リアルタイム連携についてみていきます。BI ツール側からSalesforce データをリアルタイムで呼び出す方法になります。
2.1ツール内コネクタやドライバーを使うSalesforce 連携
BI ツール側にSalesforce コネクタがある場合が一番考えやすいです。Tableau のデータ取得画面から「Salesforce」を選んでTableau から直接Salesforce データを読み込むことが可能です。この場合、BI ツールとSalesforce の間にはバッチされたDB は入らず、Salesforce のその時点でのリアルタイムデータをTableau から呼んでいます。そのため「リアルタイム連携」と呼んでいます。
ツール側に存在するコネクタを使っている場合はほとんどの場合がリアルタイム連携を行っていると考えてよいです。
ツール側にコネクタが存在しない場合には、ツール側にCData のJDBC / ODBC Driver を組み込むことで、同じようにリアルタイム連携を実現可能です。ドライバーはライブラリですので、ツール側からのクエリをSalesforce にパースしているだけで一度データを保管するようなETL・DB ではありません。
間にData Prep 系のツールを使うことも可能です。こちらもデータ自体の保存は行わず、スキーマ操作だけを行っている場合には、リアルタイム連携になります。
2.2 データアクセス仮想化サービスを使うSalesforce 連携
次に、データアクセス仮想化サービスを使うSalesforce 連携があります。これは、CData Connect Cloud のようにクラウドサービスやオンプレミスに設置するサービスですが、ETL のようにデータを物理的に動かすものではなく、プロトコルをBI ツールからアクセスしやすいものに合わせてくれるサービスです。
たとえば、Tableau からは直接アクセスできないPardot のデータをConnect Cloud 経由でTableau からつなぐことができます：https://www.cdata.com/jp/kb/tech/pardot-cloud-tableau-online.rst
データアクセスの仮想化は、今ホットなトピックですので、こちらの記事も見てみてください：
クラウド時代のデータアクセス仮想化とは？ SaaS API を活用するための古くて新しいアプローチ
2.3 SQL Server のリンクサーバーを使うSalesforce 連携
データアクセスの仮想化といえば、SQL Server のリンクサーバーも仮想化のひとつです。
SQL Server へのクエリをツールから発行し、裏ではSalesforce を呼び出してデータを取得することが可能です。この場合もODBC(SQL Gateway というデーモン）とSQL Server は間に介在しますが、データ自体はSQL Gateway にもSQL Server にも保存されておらず、透過してBI ツールからのクエリがリアルタイムでSalesforce に渡され、リアルタイムでデータが取得可能です。
Salesforce データにSQL Server のリンクサーバーとして接続
このようにいろいろな方法ですが、直接ツール側からデータにアクセスする方法も多いです。こちらにTableau の接続先リストがあります。この中でDB 以外の接続先（SaaS などの接続先）への接続方法はすべてリアルタイム連携です。ということでツールからの外部連携はリアルタイム連携主体と考えてください。
例えばですが、
3. バッチ連携とリアルタイム連携の比較
ここからは、バッチ連携とリアルタイム連携のメリット・デメリットの比較です。誤解がないように申し上げておきますと、これらは「特定の場合のメリット・デメリット、いうなれば向き・不向き」ですので、バッチ連携とリアルタイム連携のどちらが優れているということではないです。
一般的なわかりやすさ
バッチ連携は、①Salesforce からデータを呼び出す→（中略）→④DB にデータを保管→⑤ツール側からデータをクエリする、という流れが頭の中の連携のイメージ通りなので大変わかりやすいです。
リアルタイム連携では、①Salesforce データを取得するクエリはBI などのツール側から直接出されます。リクエストいきなりデータを使う方からはじまって、Salesforce データがツール側に返されるので、すこし最初は意外性に戸惑う方もいらっしゃいます。
リアルタイム性
リアルタイム連携というぐらいですが、リアルタイム連携はリアルタイムです。ただし、常にリアルタイムのデータがBI ツールなどに表示されているということではないです。リアルタイム性は、「BI ツール側からSalesforce データの更新（リフレッシュ）が掛けられるか？」という見方で考えると理解がしやすいと思います。リアルタイム連携の場合は、ツール側から常に最新のデータにリフレッシュが可能です。
バッチ連携の場合は、一度データをDB に保管しているので、BI ツール側からはバッチされた時点のデータしか取ることができません。リアルタイム性は低いと言えます。しかし、これも１カ月に１度のバッチであれば問題になりますが、１日に１度、もしくは数分に1度などのバッチ間隔を設定すると「ニア-リアルタイム」での運用が可能になります。
ホスティング・インフラの負担
バッチ連携では、間にETL やDB が入るため、ホスティングやインフラの負担はより大きいと考えていいです。リアルタイム連携の場合には間に特にサーバーモジュールなどが不要なので、インフラ負担は少ないです。
とはいえ、今どきはETL もサーバーレスでの提供もありますし、DB もフルマネージドなDB も比較的安価に利用ができるので、インフラ負担のばバーは下がってきていると言えます。
リアルタイム連携でもツール側に連携コネクタがない場合には、ドライバーのインストールや他の仮想化サービスの利用などが必要です。ですが、データ自体を保管しないというのはやはり、インフラ設計上のメリットです。
容量の大きいデータ（API リミット）・サーバーへの負担
データをクエリすれば、当然サーバー側に負担がかかります。安定的なデータ活用には絶えずサーバー側の負担や、API 制限などを意識する必要があります。リアルタイム連携では基本的にデータセットはリフレッシュごとに全件クエリして、データセットに削除・新規登録がされます。レコードの全件更新を行うので、数千から数万件というレコードセットぐらいが適切でしょうか。製品のAPI 制限ではそれより厳しいものをあるので注意しましょう。
バッチ連携は差分でのデータ取得が可能です。ツールにCDC（変更データキャプチャ）、差分更新機能があったり、カスタムSQL で更新日付を使ったりすることが可能です。これにより毎回全件取得をする必要がなくなりますので、サーバー側の負担はかなり小さく抑えることが可能です。MA やCRM のデータソースではActivity などのレコードが膨大なので、バッチでの差分更新以外に分析データの用意はむずかしいでしょう。
この辺の差分更新機能の有無はETL ツール選定には大事ですね。CData Sync のCDC や差分更新については是非チェックしてください。
Change Data Capture (CDC) 機能によるDB to DB での差分更新：CData Sync
差分更新未対応のデータソースでもCDataSyncで差分更新させる方法
データ加工や複数データソース統合
データソースから持ってきたデータは、必ずしもすぐに分析ができる状態とは限りません。複数データのマスターデータ統合やリレーションの構築、データ型の調整、指標化などを経て分析利用が可能になるケースが多いです。
データ加工や複数データソースの統合はバッチ連携に分があります。バッチ連携では、ETL 処理時とDB 内のどちらででもデータの加工や処理が可能です。ETL の”T”はそもそもデータ加工のTransfer ですので、得意分野と言えます。またDB 内で分析用のビューを作るという処理も当然想定されているものです。
一方リアルタイム連携では、BI ツール側のデータ加工の機能ともともとのデータの使いやすさに依存することとなります。近頃のBI ツールは、プレパレーション機能が発達していますので、ある程度の対応は可能と思います。
パフォーマンス
パフォーマンスについては、バッチ連携では、データを保管しているDB とBI ツール間のパフォーマンスだけが問題になりますので、リアルタイム連携と比べてハイパフォーマンスが期待できます。データを保管しているDB をBI ツールが直接アクセスできるところに配置していれば、より高いパフォーマンスを得ることができます。
リアルタイム連携ではアプリケーションAPI から比較的大きいデータをインターネット越しにクエリしますので、一定のレイテンシは避けられません。上記の大容量データの話でもありましたが、やはり数万件ぐらいのデータ取得がスムーズに操作ができるバーとなると思います。
管理面・セキュリティ
管理面やセキュリティについては、バッチ連携は集中管理ができるので、全社共有のデータ分析基盤を作る際には向いています。BI ツールからのデータソースへのリアルタイムアクセスを個々の社員に認める形でのリアルタイム連携ではデータセットが個々のユーザーに依存する野良データセットになってしまう場合があります。もちろん、
もうひとつの観点では、誰がどのデータにアクセスできるか？という点ではリアルタイム連携であれば、BI ツールからデータソースに接続する際に利用権限を透過することが可能ですので、より管理が可能ともいえます。バッチ連携では、利用権限を付与する場合には、データソースと同じ利用権限を再度DB 側にて付与する手間がかかってしまいます。
4. まとめ
いかがでしたでしょうか？
バッチ連携とリアルタイム連携についてどんな比較材料があるのかの理解を深めていただけたのではと思います。以下に具体的な利用シナリオでどっちにするかを例として考えてみました：
単一のSaaS で、データが千件程度→リアルタイム連携でOK
MA やCRM の数十～数百万件のデータ→バッチ連携一択
複数のSaaS でデータマート（ビュー）を作って分析→バッチ連携一択
索的に自分の手元でいろんなデータを見たい→リアルタイムでOK
AppSheet などのノーコードアプリツールから→リアルタイム向き
最後までありがとうございました！