FivetranでELT処理を楽々実装しよう！

はじめに

こんにちは。レバレジーズ、データエンジニアの森下です。 レバレジーズではBigQueryを中心にデータ活用基盤を構築しています。ELT処理は今までEmbulkを使用していましたが、データ更新頻度の向上による社内ユーザーの利便性向上とデータエンジニアの運用負荷軽減を考えて、今年度中に全てFivetranへ移管する予定です。すでにいくつかのRDBやSaaSの更新はFivetranにまかせており、日々その便利さを噛み締めています。

今回は、Fivetranを使った便利なポイントや困ったポイント、注意するべきポイントを紹介いたします。

Fivetranとは？

ELT専用のSaaSです。（https://www.fivetran.com/）

基本的にはBigQueryやSnowflakeといったDWH製品に対して、外部データを連携するためのSaaSになります。ボタンをぽちぽちするだけでデータ連携されていくのでとても簡単にELT処理を実装することができます。

また、RDBに関してはTeleport Syncというデータ連携方法もあり、データソース側の負荷が少ない形で高速な差分更新を実現しています。プランにもよりますが最大で1分に1回の更新が可能なので、ほぼリアルタイムに近い間隔でデータ更新を行うことができます。加えて、CDC（Change Data Capture）によるデータ更新も可能なので、用途や要件に応じて使い分けることができます。レバレジーズの場合、バッチ処理であればTeleport Sync、リアルタイム更新または更新履歴を保持したい場合はCDCといった形で使い分けることが多いです。

SaaSからのデータ連携もボタンぽちぽちで連携できるのが非常に楽なポイントです。さらに、SaaSによってはFivetran側でER図を展開していたりするので、それを見ながら内部構造について理解を深めつつ、クエリを書いて分析を進めていくことができます。

レバレジーズの使い方

現状、以下のデータソースからのデータ連携で使用しています。

• MySQL
• Postgres
• Mailchimp
• Hubspot
• Appsflyer
• Salesforce

FivetranによるELT処理では、Fivetranが付与したメタデータカラムが付与されるかつ日時が全てTIMESTMAP型で入ってきます。データを使用して業務に活かすユーザーの利便性を考えて、データ分析には不要なメタデータを除外し、日時カラムの型変換を行っています。具体的には、参照用のViewを作成し、View定義の段階でメタデータカラムの除外とTIMESTAMP型のキャストを行っています。

便利ポイント！

ボタンぽちぽちでデータが入る

データソース側については、基本的にFivetranの画面指示に従って必要項目を入力していけば認証が完了します。

SaaSはその場でログイン画面が開くので、データ連携に使用するアカウントでログインすれば認証完了です。

DWH側も同じような要領で認証を通すことができるため、10分もあればFivetranを使用して外部からデータを取得しDWHへデータを流し込む設定を行うことができます。

SaaSだとER図を見ることができる

Salesforceのようなカスタムオブジェクトを作成できるものは別ですが、MailchimpやHubspotのようなSaaSの場合は内部構造がほぼ決まっています。そういった場合は、Fivetran側でER図を提供しています。ER図と実際のデータをにらめっこしながら構造を把握する必要がありますが、データしかない場合と比較して、かなり理解の助けになっています。

差分更新なので負荷が低い

RDBの場合、Fivetran独自のバッチかつ差分更新方法のTeleport Syncが用意されています。このTeleport Syncが非常に便利で、レコードの追加更新はもちろんのこと、スキーマ更新にも対応してくれます。差分更新を行うため、最初に全レコードを取得する必要がありますが、そこさえ乗り切ってくれたらDBへの負荷は非常に低く済みます。そのため、日常的な使用に関してはTeleport Syncで十分だと思います。

更新レコード分だけの課金

Fivetranの課金は、月間で更新が入ったレコード（MAR：Monthly Active Record）に応じて決まります。

更新が発生したレコードでの課金なので、仮に全くレコードに変化がなければ課金が発生しません。

基本的には差分更新なので、差分更新対象のレコードだけに課金が入るのは良心的です。また、MARが増えれば増えるほどMARあたりの課金額も下がっていき、接続先やデータ量がどんどん増えていくレバレジーズでは非常にコストメリットがあります。

CDC（Change Data Capture）によるデータ更新

RDBではCDC（Change Data Capture）によるリアルタイム更新も可能です。CDCの場合、リアルタイム更新を行うテーブルを個別に選定できるため、ビジネスにとって重要なテーブルのみを選定することが可能です。そうすることで、DWH側の更新頻度を下げることもでき、後述しますがDWH側の不要な更新コストを削減することができます。

また、CDCは主にリアルタイム更新を実現するために実装すると思いますが、ざっくりとした仕組みとしては、更新履歴をbinlogから取得しそのままDWH側に反映するという方法でリアルタイム更新を実現しています。FivetranによるCDCでは、DWHを更新する際に更新履歴を全てDWHに保持してくれます。そのため、リアルタイム更新は不要だが更新履歴は欲しい、といった場合、CDCを活用する選択肢が生まれます。レバレジーズでは更新履歴が欲しい場合、DWH側で日次スナップショットを取得していましたが、今後はスナップショットを取得するのではなくCDCを活用して更新履歴を全て保持する方向で実装するかもしれません。

ドキュメントのわかりやすさ&サポートの親切さ

地味に感動したのがドキュメントのわかりやすさです。画面ぽちぽちでデータ連携を実現できると記載しましたが、ぽちぽちする際にドキュメントを読んでわからないことがほぼないです。また、GUI上で入力画面の真横に設定ドキュメントが見れるのが地味に便利で、1つのタブ上に入力画面と設定方法が記載されたドキュメントを表示させることができ、視認性が非常に良いです。

サポートについては返信が早く、ログを見た上で回答をいただけたり、ドキュメントには公開されていない内部ロジックについても共有いただける場合があります。感覚としてはAWSやGoogleCloudのサポートと同じ感覚で使用できるため、困ったことがあったらとりあえず質問→解決、の流れを何回も体験することができました。

困りポイント

Salesforceのformula fieldが連携されない

formula fieldはスプレッドシートの関数のようなもので、オブジェクト内に追加することができます。たとえば、企業オブジェクト内に商談オブジェクトを集計した結果を累計商談数として持たせる、といったことが可能です。ただし、Fivetranが差分更新に使用しているSystemModStampカラムは、formula fieldの変更が反映させないため、Fivetranとしてはformula fieldの定義が変わったことを検知する術がありません。そのため、Fivetranはformula fieldを連携しないようになっています。

ただし、実際の利用シーンでは、例に出したように他オブジェクトのデータを使用してformula fieldを定義しているパターンも多く、formula fieldなしで連携したところで、本当に使用できるデータにはなっていませんでした。

Marketoのスキーマを最初は見れない

Marketoの場合、他のSaaSと異なりデータ連携しないとスキーマを見れない仕様になっています。SaaSだとよくあることだと思いますが、APIによるデータ利用の容量制限があり、全カラムを連携するとすぐに容量オーバーになってしまいます。スキーマを見るためにオブジェクト内の全データを一度連携する必要がありますが、1つのオブジェクト連携の度に利用容量オーバーで1日使用できなくなるのは、既存モニタリングのことを考えてしまうと、作業が捗りません。本当であれば必要なカラムだけを選択してデータ連携したいのですが、今の仕様だと難しそうです。

コンソール画面上からログを見れない

これはプランによるものだと思いますが、Standardプランの場合、コンソールからログを確認することができません。レバレジーズの場合、コネクターを利用してBigQueryへログデータを出力することができたので、そちらで確認していますが、少しだけ面倒です。また、BigQueryへのログ出力はバッチ処理になるため、試行錯誤中のログを見るためには、毎回手動でBigQueryへの出力を行う必要があり、やや面倒です。

注意ポイント

DWH更新にかかる課金

Fivetranが取得した差分データの更新は、BigQuery内ではMerge文を実行して実現しています。差分更新の回数が多いとその分だけMerge分の実行回数が増えるので、Fivetran側の更新回数が増えれば増えるほどBQ側の更新回数も増えてしまいます。

仕方のない部分ではあるのですが、Fivetranの課金額だけを見ていると、MAR自体は大したことないのにDWH側の更新にかかるコストが増加しており、トータルで見ると大変な金額になってた、ということにもなりかねません。

特定のテーブルだけの更新ができない

正確には特定のテーブルだけをデータ更新するように設定を変更→手動更新で実現可能なのですが、設定変更の必要があること、戻し忘れによる不具合発生の可能性を考えると、特定のテーブルだけを特別な操作なく更新できると日々の運用が非常に楽になると感じています。

SaaSのレコード更新数が想像以上に多いことがある

現代ではETLよりELTだと思いますので、ひとまず全オブジェクトのデータを連携し、そこからビジネスに活かすためにどのデータを加工し始めるかを選定することが多いと思います。SaaSの場合、おそらくシステム関連オブジェクトが内部的に大量に作られるため、ひとまず全部連携しようとすると、データ活用施策にとっては不要なテーブルも大量に連携されることがあります。どのデータ連携設定でも最初は無料で行けるのですが、一定期間が経過すると課金が発生し始めるため、有料期間が始まる前にデータの選定を完了させないと、無駄かつ大量レコードが転送されることとなり、意図しない重課金が発生する可能性もあります。

最後に

レバレジーズではまだまだFivetranを使い始めたばかりですが、すでに多くの恩恵を感じています。データ更新処理を安定化させ、また楽に早く実装できることは人数もデータ活用シーンもどんどん増えていくレバレジーズにとっては、必要不可欠なことです。既にELT処理に関わる実装および運用工数を大幅に下げることができ、計り知れないメリットを享受しています。

データを更新することはFivetranに任せ、データエンジニアはより高度なエンジニアリングやデータとビジネスの接続といったことに時間を使い、より一層データドリブンな組織を目指していきます。

今回の記事が、Fivetran導入を検討する際の参考になれば幸いです。