[レポート] Database Replication Best Practices #mdscon

大阪オフィスの玉井です。

2021年9月22日〜23日 午前9時～午後3時30分（米国太平洋標準時）、The Modern Data Stack Conference 2021というデータ分析に関するオンラインカンファレンスが開催されました。主催はFivetran社です。

この記事では、このイベントの「Database Replication Best Practices」というセッションのレポートをお届けします。

セッション情報

登壇者

• Jason Nochlin, Staff Software Engineer @ Fivetran
• Sara Ridder, Senior Solution Architect @ Fivetran
• Brandon Chen, Manager of Technical Product Marketing @ Fivetran

概要

As more and more companies migrate their analytics efforts into the cloud, efficient and accurate database replication for a variety of source systems, target destinations, and use cases grows in importance. If you're currently tackling database migration and replication –– or soon to be –– join this session to understand what common technical blockers and solutions are, as well as understand which solutions might work best for your business.

多くの企業がデータ分析をクラウドに移行する中で、様々なソース、データウェアハウス、ユースケースに対応する効率的で正確なデータベースレプリケーションの重要性が高まっています。

このセッションでは、データベースの移行やレプリケーションに取り組んでいる方、あるいはこれから取り組もうとしている方を対象に、一般的な技術的障害とその解決策を理解し、どのようなソリューションが自社のビジネスに最適かを理解していただきます。

セッションレポート

※レポート本文のみ一人称は登壇者を指します。

前段（アジェンダなど）

皆さん、こんにちは。FivetranのマーケティングチームのOlivia Hardyです。

今回は、データレプリケーションとベストプラクティスについて、詳しくお話したいと思います。Brandonさん、どうぞよろしくお願いします。

Oliviaさんありがとう。

このデータベースレプリケーションのセッションを、ちょっとしたジョークで始めたいと思います。3つのリレーショナルデータベースがNOSQLのDBに入ってしまい、テーブルが見つからくなってしまったために5分で帰ってしまったという話です。このジョークが面白かったかどうかは、遠慮なくコメントに書いてください。もし楽しんでいただけたなら、このセッションの最後に別のジョークをご紹介します。

では、今日のアジェンダを確認し、このデータベース・レプリケーション・セッションで何を議論するかを決めます。

まず、データベースのレプリケーションに関する一般的な課題について、人々はどのように取り組んでいるのでしょうか。どのような修正や解決策があり、それらの解決策にはどのような問題があるのでしょうか。

その後、5月に発表したばかりの、データベースコネクタのレプリケーション手法の新しい形を実現する新技術の取得について、もう少し詳しく説明します。

次に、データベース分析のユースケースに加え、Fivetranのユーザーの方々の体験談をご紹介します。私が紹介するものの中には、一般的にデータベース分析に興味がある人にとって特に興味深いものがあります。その内容は、一般的なアナリティクス・プロジェクトの失敗についての話から、失敗の理由を検討してそれをどのように修復するか、それぞれの道筋をたどってお客様の解決策を探ること、アナリティクス・クラウドの組織改革をどのように進めるか、特にデータがますます重要になり、アナリティクス・エンジニア、データ・エンジニア、データ・サイエンティストを養成するためのアナリティクス・チームを求める企業が増えている中で、ビジネスにプラスの影響を与えるだけでなく、アナリティクスの改革を進めるためにデータをどのように利用するか、など多岐にわたります。

また、Mixpanel社やBrooklyn Data社からは、データ分析とモダンデータスタックについて、また、データ分析などの分野で変化をもたらすために構築されたツールなど、データスタックの次の展開についてお話しいただきます。

それではまず、講演者の方々をご紹介しましょう。私の説明が終わったら、皆さんにはミュートを解除して自己紹介をしていただきたいと思っています。

私の名前はBrandon Chenです。私はFivetranに入社して約3年になります。その間、セールスエンジニアとしてFivetranに関わってきました。私は、オンプレミス型のデータウェアハウスからクラウドへの移行などのモダナイゼーションにおいて、モダンデータスタックの構築やスタンドアップなど、Fivetranの導入に関わる何百人ものお客様と仕事をする機会がありました。

私はJason Nochlinです。スライドに書いてあるとおり、私はTeleport Syncの生みの親です。Fivetranのソフトウェアエンジニアになって4ヶ月が経ちました。

こんにちは、私はSarah Ridderです。私はFivetranでシニアソリューションアーキテクトをしています。私は、ほとんどの企業ベースのお客様と仕事をしてきました。Fivetranに入社して1年ちょっとになります。

データベースレプリケーションの一般的な考え方

今回は、先ほどお話した、データベースレプリケーションの一般的なアプローチから始めたいと思います。

このような種類の問題で典型的に直面するのはどのような種類の課題でしょうか。データベースレプリケーションについて話しているとき、基本的なレベルで、私たちが理解しているのは、伝統的なトランザクションデータベースを、分析を目的とした集中型データウェアハウスや集中型データレイクハウスに統合するということです。通常のデータ分析の場合もあれば、機械学習モデルへの投入のような運用が目的の場合もあります。これらは、ユーザーが商品に表示するプロモーションのように、プログラムで調整できます。

このようなデータベース・アプリケーションの話をするとき、通常は、特定のテーブルをインポートするために、1つのオブジェクトを導入するだけ…つまり、このようなことを1回だけ行うのではなく、むしろ、データ分析や機械学習のために、データベース・トランザクションを継続的に複製する、スケーラブルで信頼性の高いプロセスを設定することを意味します。むしろ、スケーラブルで信頼性の高いプロセスを設定して、データベースのトランザクションを、先ほど話したデータ分析や機械学習のための集中管理先に継続的にレプリケーションすることを指します。

多くの企業が実施する、最も一般的なアプローチは、従来のフルテーブルスキャンから始めて、テーブルAとBとCと…という感じで複製したいものからスター型の選択を行うことです。そして、そのようにして抽出した完全なデータを、すでにウェアハウス内にあるデータセットと比較して、どのような変更をマージすべきか、あるいはどのような新しい更新や挿入をマージすべきかを判断します。あるいは、全体的なドロップを行い、ウェアハウス内のテーブルを置き換えることもあります。

これは、レガシーなデータスタックで見られるアプローチの1つです。なぜなら、構築が容易なためです。どのようにしてテーブルを完全に抽出するのか、どのようなストレージバケットに送るのか、といったことを簡単に考えることができます。そして、そのままCOPYコマンドを実行して、すでに構造を設定してあるテーブルにロードすることができます。しかし、ご存知の通り、このプロセスの問題点は時間がかかることです。ソースデータベースにあるデータ量や、データセットをウェアハウスにマージするために使用している方法にもよりますが、時間と負荷がかかります。

もちろん、クエリの実行に時間がかからないようにするという手法もありますが、通常は、クエリの実行に時間がかかるため、夜間に一時停止を行う必要があります。また、このような負荷のかかる時間のかかるプロセスを実行しているので 進行中のトランザクションに支障をきたす可能性があります。例えば、最悪のケースとして、SQL Serverからデータを抽出するプロセスで、テーブルを誤ってテーブルをロックしてしまうかもしれません。これは、データ分析に重要な役割を果たしているトランザクションを追跡する上で非常に重要です。

2つ目のアプローチは、従来のフルテーブルスキャンでは時間がかかることに気付いた企業が、次々と導入しようとするものです。これは、タイムスタンプや自然に増加するキーを使って、どのデータが変更されたのかを把握しようという方向性のものです。例えば1、2、3、4と増加していきます。そして、最後の状態の記録を取り、それを更新し続けます。

ここで問題となるのは、タイムスタンプの粒度を確保することです。タイムスタンプの粒度については、多くの企業が、例えば第2レベルごとに記録する状態を設定することから始めるかもしれません。あるいは、トランザクションの量やデータベースへのアクセスを考慮して、ミリ秒単位での記録が必要な場合もあるでしょう。その場合、状態データを秒単位で記録していると、前回の同期の間に発生した交差点のトランザクションを見逃してしまうことになります。

そして、現在多くの企業が活用している最も一般的なアプローチが、ログベースのレプリケーションです。これは、ネイティブなトランザクションログを使用するものです。例えば、Change Data Captureのように、SQL Serverのバイナリログを使って変更を読み取り、すべてのトランザクションが行われたことを理解し、それをどのようにデータウェアハウスに変換して実際の権限を与えるかを理解することができます。そうすれば、ウェアハウスのデータが更新され、適切な判断を下すことができます。

この方法には様々な問題がありますよね。その一部は、ログの変換に関連しています。トランザクショナルログから読み取ったさまざまな行を、どのように解釈すればよいのでしょうか？様々なメッセージをどのように解析すればよいのか？スキーマドリフトのような問題にどう対処するか？

組織的な問題もあります。インフラやパーミッションの問題もあるでしょうし、かなり大きな会社で働いている場合、ログを読むための適切なパーミッションを持つ新しいデータベースユーザーを作成するための管理者アクセスを得るには、何週間、いや何ヶ月もかかるのです。

また、サードパーティ製のホストを利用する場合も同様です。あなたが自分のデータベースを所有していないとしましょう。誰かがあなたのために魔法のデータベースを作ってくれました。そして、あなたが持っているのは読み取り専用のユーザーだけです。つまり、そのユーザーにログのパーミッションを設定することはできません。あるいは、サードパーティのホストであれば もしかしたら、そもそもトランザクションのログを取る設定ができないかもしれません。

さらに、データベースのレプリケーションには追加の課題があります。

データ分析においてデータベースが重要な役割を果たすことを考えると、一般的にチームは、集中型データウェアハウスに統合される最初のデータソースの中で、トランザクションデータベースが最初にセットアップされるコネクタの一つであることに気付きます。

また、データベースは柔軟性があり、幅広く利用されているため、データベースのレプリケーションを設定する際には、通常、追加で考慮しなければならないことがあります。

例えば、基本的な接続のセキュリティレベルや、レプリケーションの実行中にデータをどのように暗号化するかなどです。また、データの漏洩がないようにするにはどうすればいいのでしょうか？特に、個人情報を含む場合はどうでしょうか？何かが削除された場合はどうするのか？削除されたデータは、データウェアハウス内で論理的に削除されたものとして記録し続けるのか？それとも、完全に物理的にデータウェアハウスに残し、そのデータウェアハウスをデータベースの常に最新の状態を表すものとして使用するのでしょうか？

スキーマドリフトが発生した場合、新しい製品担当者がトランザクションデータベースから追加のメトリクスを追跡し始め、それをすぐにルックアップダッシュボードのように表現したいときに、新しいテーブルが追加されたらどうなりますか？ソースデータベースで使用されているデータタイプが、データウェアハウスやデータレイクハウス内の適切なデータタイプに正確にマッピングされていることを確認するにはどうすればよいでしょうか。アナリストがデータタイプの変換をしなくても、期待通りのクエリを実行できるようにするにはどうすればよいでしょうか。

データタイプからフローへの変化についても考えます。あなたの会社では、時間の経過とともにソースデータベースに様々な種類のトランザクションを集め続けています。そして、それらの変化を記録しておくことは、例えば監査可能性のため、あるいはデータベース内でホストされているデータの種類に応じて、例えば注文の進行を追跡するために重要です。

データベースのチューニングも重要です。多くのデータベースはトランザクション用に構築されています。必ずしもレプリケーション用に構築されているわけではありませんし、レプリケーション用に設定されているわけでもありません。そのため、データベースが標準的なパフォーマンスを維持し、これまで扱ってきたすべてのトランザクションを追跡しながら、データセットをソースデータベースからデータデスティネーションに複製するという新たな負荷を処理する方法を考えなければなりません。それがデータウェアハウスのようなレイクハウスであっても、別のエンタープライズデータであっても、別のデータベースを新しいエンタープライズデータウェアハウスとして使用する場合でも同様です。

Teleport Syncについて

ここからは、私、Jason Nochlinがお話します。私はFivetran社のソフトウェアエンジニアです。

私は、Teleport Dataの元創業者です。Teleport Dataは2020年3月に設立した会社で、パンデミックの最大不確実性の頃に新会社を設立するには素晴らしい時期でした。しかし同時に、家の中では難しい問題を考える時間も十分にありました。そこで私は、あらゆることができる新しいタイプのExtract・Load・フレームワークを作るために、Fivetranに対抗できるツールを作りたいと思い始めました。そして、数ヶ月間その作業を続けました。また、市場の動向を把握するために、いくつかのソーシャルメディアやSlackに参加しました。データ関連のソーシャルメディアやスラックのコミュニティに参加しました。そこで目にしたのは、ハードデリートという問題を抱えたまま眠り続けている担当者たちでした。

データベースレプリケーションの世界では、ある種のシンク・レプリケーション・メカニズムを持っている顧客がたくさんいました。例えば、Postgresのように、INSERTとUPDATEは同期されますが、DELETEは同期されません。そのため、レプリケーション先には本来存在しないはずの行が残ってしまいます。これには多くのお客様が不満を感じていました。

私はパンデミックの間、Teleport Dataを開発している隙間で、この問題に多くの時間を費やしていました。そして最終的には、ソース側で削除されたデータを見つけ出し、それをデスティネーション側に複製するという解決策にたどり着きました。この解決策は、DELETEミスを見つけるだけでなくUPDATEミス等も見つけることができるという、もう少し一般化できるものであることも明らかになりました。UPDATEミスや、正しく同期されていない不一致の行も見つけることができました。これはちょっとしたブレークスルーでしたね。

私はその時、（企業の）コアデータを扱う仕事をしているだけで、データの世界では誰も相手にしてくれませんでした。そこで、どうやって自分を売り込もうかと考えました。オープンソースのプロジェクトをやるか？そこで考えたのが、これを中心としたコンテンツを作ること、あるいはオープンソースとしてリリースすることでした。

しかし幸いなことに、MBAを持つ妻と一緒に取り組むことにしました。つまり、私はヒッピーでオープンソースのプリンシパルエンジニアのような関係です。一方、彼女はビジネススクール出身で、価値を生み出す役割を担っていました。そこで、彼女は即座にこう言いました。「これは巨大な市場機会のように思える。何をするにしても、それについては何も発表せず、実際のプロダクトとして作り上げるべきだ。」。

それ以来、私は他のプロジェクトを脇に置いて、このデータプロダクトに焦点を当てました。このような幅広いデータ品質とデータレプリケーションの分野で、ポジション的には、自分たちはどこに当てはまるのかを模索していました。そして、競合他社についてもっと知りたいと思ったのは、この会話から約1ヶ月後のことでした。その会話とは、GeorgeがSlackで投稿しているのを見たものの事ですが、彼は基本的に、この種のソースとデスティネーションのマッチングはFivetranにとって年単位レベルのパズルだったと述べています。彼らはいくつかのアイデアを持っていましたし、それに取り組んではいたようですが、一般的な解決策はなく、新しいアイデアを探していました。これが市場での評価のすべてでした。

この時点で私に必要だったのは、世界有数のデータ会社のCEOが、「これ（Teleport Data）は大きなニーズだ」と言ってくれることでした。その時点で、私はこのアイデアに真剣に取り組み、暫定特許を取得しました。そしてGeorgeに連絡を取ったのですが、彼のカレンダーではまた数ヶ月かかってしまいました。彼はユニコーン企業の創業者であり、多忙な人ですからね。

しかし、2020年の12月にようやく会うことができました。私は彼にデモを見せて、こう言いました。「今、ビジネスを始めようとしているんだ。FivetranでTeleport Dataを再販することはできないだろうか？」すると彼は、「これは我々の製品に深く統合されていなければならないし、我々が所有しなければならない」と言いました。

私は、他の会社を経営したいのか？自分の会社を持ちたいのか？エンジニアになりたいのか？自分のキャリアの次の段階として、個人的な貢献をしたいのか？…といったことを考えました。GeorgeやFivetranの他の役員に会って、彼らがいかにオープンマインドで透明性が高いかを実感しました。Georgeはデータパイプライン企業を進化させてきた人物で、フォーラムにいつも現れては、コミュニティのメンバーと激しい議論を交わし、学ぼうとしている唯一の人物です。Fivetranや彼が過去に見落としていたかもしれないものを見つけようとする姿は、この会社をよく表しています。結局、私は決断し、2021年5月にFivetranに入社しました。私の技術も一緒に入社し、今では製品の統合を始めています。

Teleportは、ソースデータ（特定のデータベース）とデータウェアハウスを比較するための一般的なソリューションです。つまり、ソースとデスティネーションを比較するのです。

当初、私はこれをデータ統合ツールと考えていました。つまり、メインの同期プロセスが見落としていた行を検証し、ピックアップすることができるのです。しかし、Georgeがこのツールを使って本当に楽しみにしていたのは、実際にこのツールで新しいタイプの同期メカニズムを構築することでした。というのも、一度比較したデータは、何が同期されていないかを示す単なるレポートとして受け取ることもできるし、そのデータを使って実際に同期を実行することもできるからです。その仕組みは、データベースのテーブルの状態を圧縮するプログラムをSQLにコンパイルするというものです。そのため、巨大なテーブルを非常に小さなバケットに収めることができるのです。文字通り、100ガロンの水を入れることができる5ガロンのバケツをテレポートして、それを使って2つのデータベース間の差分を求めるのです。

先程、Brandon氏が他の6つのメカニズムについて説明しましたが、Teleportが本当に素晴らしいのは完全にSQLベースだということです。つまり、動作させるためには、データベースにアクセスするための読み取り専用のSQLユーザーが必要なだけであり、複雑な設定をする必要はありません。

これは、Fivetranのお客様や見込み客となるお客様にとって、どのようなメリットがあるのでしょうか。

これは、新しい増分同期レプリケーションのオプションです。タイムスタンプベースの同期とは異なり、設定が不要です。トランザクションログを確認するために、データベースの内部に接続する必要もありません。多くの場合、トランザクションログは、データベース内のすべてのデータの完全なフィードでしかありません。企業によっては、セキュリティ上の理由から、サードパーティのベンダーにすべてのデータを見られたくない、制限したいと考えるところもあります。

Teleportは純粋なSQLベースなので、どのテーブルやカラムを見ることができるかという標準的なSQLパーミッションを与えることができます。また、スナップショットベースのフルレプリケーション同期を行っている場合は、ほとんどの場合、Teleportの方がより効率的な方法となります。つまり、スナップショットアプローチを行うことができ、フルロードを行うよりも効率的であることがわかり、より頻繁に実行することができます。そうすれば、データウェアハウスへの負荷を減らすことができます。

同期のユースケース以外にも、Teleportはデータベースの新しいインクリメンタル・シグマ・システムとして、初期のロードマップを作成しています。今後は、様々なバージョンのデータベースに1つずつ展開していく予定です。その先には、さらに先のFivetranプラットフォームにデータ統合機能を追加することも検討しています。この点については、あまり多くを語ることはできません。

そして、もうひとつの素晴らしい点は、これらの他のメカニズムのバックアップにもなるということです。多くの場合、トランザクションログに障害が発生した場合、データの整合性を失わずに修正するには、データベース全体を完全に再同期する必要があります。しかし、Teleportでは、よりターゲットを絞った再同期を行うことができます。トランザクションログの停止中に見落とされた行だけを完全に同期するよりもはるかに速くなります。このように、現在はレプリケーションできないデータベースでも、テレポートを使えば新たな機会を得ることができますし、他の同期メカニズムを強化することもできます。

現在、TeleportはFivetranの既存のお客様向けのプライベートプレビューとなっていますが、もっと詳しく知りたい方はぜひご連絡ください。

しかし、Teleportについてもっと知りたいと思っているユースケースをお持ちの皆様からの情報をお待ちしています。既存のお客様、またはこれからのお客様は、ぜひFivetran.comのBeta版にご連絡ください。Beta版はまだ新しい製品なので、お客様がどのような用途で使いたいのか、どのように使いたいのかを知りたいと思っています。ですから、この製品を使って何か役に立ちそうな、ちょっと変わった使用例があれば、ぜひご連絡ください。

顧客事例

ここからは、私、Saraが、データベース分析のユースケースと、Fivetranのお客様がデータベースのレプリケーションで行っていることについて少しお話します。

通常、私たちがお客様と一緒に仕事をするとき、お客様は主に2つの動機を持っています。それは、社内関係と社外関係です。

一般的には、社内の理由では、売上高などのさまざまな追跡システムを見て、社内の多くの関係者のために分析を行いたいと考えています。また、あらゆるタイプのERPシステムも対象となります。これらのERPシステムの多くはすでにAPIを備えていますが、基本的な情報を得るためにはデータベースにアクセスする必要があります。

社外の理由としては、外部アプリケーションの検索と追跡、さまざまな使用状況の確認、マーケティングチャネル情報の把握などがあります。

いま説明したのが、主な、データベース・アナリティクスのユースケースです。

私たちはFivetranの顧客アンケートを行いました。これは、私たちの顧客の多くがどこにいるのかについてのアイデアを提供するものです。分析についてどのように考えているのか、また、データベース・コネクターを強化するためにどのようなサポートをしているのか。

結果は、製品分析が38％、マーケティング分析が26％、ERP分析が12％となっています。

データ分析を良いものにするためには、洞察力を高める必要があります。Fivetranのユーザーは、これらの洞察（インサイト）から何を推進するかを見てみましょう。

ユーザーに関するもの、月間アクティブユーザーのロックイン回数、顧客の注目度などです。先に述べたように、マーケティング・チャンネルの一部では、成功したファネル・プログレッションを見ると、収益が非常によく見られます。それから、やはりERP計画システムですね。

最初の顧客事例は、教育関係の企業です。

以前は、Fivetranの前にGolden GateとExadataを利用しており、SQLやSASのソースがあちこちに散在していました。また、以前はOracle（オンプレ）を使用していました。そして、すべてをクラウドベースに移行したいと考えていました。それがここでの目標でした。

Fivetranを導入してからは、1つのサービスですべてのデータパイプラインを管理できるようになりました。すべてのデータは、5つのSASソース、すべてのOracleデータベース、およそ50のデータベースを経由しています。これらのデータはすべてFivetranを経由しています。これにより、使いやすさ、レプリケーションスケジュールの厳密な管理、そして彼らにとって重要な信頼性を得ることができました。

Fivetranでは、これらのデータベースの多くが、明らかに社内のほとんどのニーズに対応しています。つまり、製品データがどのように処理されているかを見るのです。そして、そこからいくつかの指標を得て、それが我々の販売データとどのように一致するかを知ることができました。

しかし、それ以上に重要なのは、顧客向けのアプリケーションを強化するために利用していたことです。例えば、このデータが非常に重要であることを私に語ってくれました。なぜなら、1行でも間違っていたり、データが最新でなかったりすると、生徒が学校に通うためのノートパソコンを手に入れることができないからです。ですから、このデータは彼らにとって非常に重要なものなのです。だからこそ、Fivetranによる信頼性の高い、安定した、シンプルで使いやすいレプリケーションメカニズムは、彼らにとって非常に重要なのです。

2番目の顧客事例は、オンライン・デリバリー・サービスを専門とするかなり大きなB2Cサービス会社です。

このお客様は、Fivetranの長年の顧客です。Fivetranで使用しているPostgresデータベースは2000個以上あります。このデータベースは9カ国にまたがっています。そして、約1,300万のユーザーイベントを抱えています。そのため、部門を超えてデータを移植し、分析用ダッシュボードを強化しようとしている彼らにとって、Fivetranは極めて重要な存在です。このお客様が成長を続け、急速に成長していくためには、高スループットで本質的に安定したコネクターを持つことが非常に重要なのです。

Fivetranにより、お客様の分析ニーズに応えることができ、多くの社内分析を推進することができます。つまり、財務、製品販売、マーケティングなどです。また、外部分析も可能です。すべてのパートナー、さまざまなベンダー、すべての顧客にとって、このデータは非常に重要なものです。これらのデータは、基本的に何千ものダッシュボードを動かしています。このように、Fivetranがレプリケーションに大きく貢献しています。

最後の顧客事例は、ホスピタリティ部門の企業です。

彼らは以前、データベースのレプリケーションにAloomaを使用していました。Aloomaを利用していたときに感じたことは、ソースごとのレプリケーションスケジュールのコントロールができないなど、いくつかの点が欠けているということでした。そのため、データの更新速度に応じてソースをカスタマイズすることができませんでした。そのため、すべてのソースを一度に処理することができませんでした。

次に、すべてのソースで単一のパイプラインを共有しなければならないという制約がありました。そのため、いくつかの問題が発生していました。基本的に、何か変更があった場合、それは彼らにとって非常にストレスの多い時間でした。なぜなら、1つのソースがダウンするだけでなく、すべてのソースがダウンする可能性があったからです。そのため、彼らは移行を強く希望していました。

Fivetranが彼らのデータ分析にとって非常に重要であった理由の一つは、アナリティクスのニーズに対して非常に安定したパイプラインを持つことができることでした。また、先に述べたコントロールの欠如についてですが、Fivetranでは、レプリケーションのスケジュールをよりカスタマイズできます。つまり、異なるソースごとにということです。例えば、SQLデータベースの場合、1日1回ではなく、データが更新されるたびに15分ごとにレプリケーションを行うことができました。これにより、分析結果は1日1回よりもはるかに速く、正確になりました。

また、Fivetranのパイプラインはすべて独立しています。つまり、すべてのソースが入ってくる巨大なパイプラインにはなりません。もし何かが起こって、何かがダウンしたり、変革や変更があったとしても、影響を受けるのは1つのソースだけです。このようにして、アナリティクスのユースケースに、より高い信頼性と安定性を提供することができました。

このお客様は、Fivetranを1年以上使用していますが、大きな問題は発生していないとのことです。このことは、そのチームにとって大きな価値があることを証明しています。彼らが使用している多くのプロダクションベースの分析結果を提供することができるのです。そして、これまで彼らが抱えていた大きな問題を解決することができました。

ここに挙げたお客様の例をご覧になれば、お分かりになると思います。さまざまな分野、さまざまなニーズのある分野に広がっています。しかし、基本的には、今回紹介した顧客の事例は、DBをレプリケーションしてくれるベンダーとしてFivetranを選んでいます。

質疑応答（面白かったものだけピックアップ）

好きなDBと嫌いなDBを教えて下さい

Brandon氏

私のお気に入りはいつもRedisです。

少なくともデータソースの観点からすると、一般的なものではありません。普通は、永続的なデータストレージとしては使用されません。

しかし、非常にユニークなデザインを持ち、他のデータベースにはないクールなデータ構造機能を持っています。オープンソースですし、C言語で書かれたコードは非常によくできているので、読んでいてとても楽しいです。でも、これはオタク的な側面から見た感想です。そして、本当に一番好きなものなのかどうかはわかりません。F1カーが大規模なチームによって超高度に最適化されていることに似ていると感じています。

この1年半の私の人生で、さまざまなデータベースに非常に深いレベルで潜り込んできたような気がします。そして、そこにはいつも何か美しいものがあります。だから、一番嫌いなものは何かと言われても、その中で何か評価できるものがあるかどうかはわかりません。

ただ、多くの企業がMySQLやPostgresを使うようになってきていることは知っています。ちょっとした話ですが、私が最初に触ったデータベースはOracleでした。この種のものをセットアップするのに何時間もかかりました。だから、MySQLやPostgresの利点はよく理解できますし、それに加えて、これらのデータベースをさまざまなクラウド上で迅速かつ簡単に立ち上げることができます。驚くべきことです。最初の仕事でデータベースをセットアップしていたときには、何時間も節約できていたでしょうね。

Sara氏

私は、Oracleとは愛憎の関係にあると思います。私が初めて本格的に扱ったデータベースはOracle RACでした。それは私にとって少し厄介なものでした。でも今、Fivetranの仕事をしていると、Oracleに対する敬意が深まり、Oracleがどのように機能しているのか理解できるようになりました。しかし、Brandonさんの言うように、MySQLやPostgresが増えているのはもちろんですが、DynamoDBのようなものに移行するものも多く見られるようになりました。

うーん、そうですね、好きとか嫌いとかはありませんね。おそらく、（この私の話は）Oracleとの愛憎関係を例示しているのだと思います。

おわりに

比率としては、Fivetranと、Fivetranの新機能（Teleport Sync）の宣伝っぽい内容の方が多めでしたが、序盤の「データベース→データウェアハウス」というデータ移行の一般的な課題については非常に勉強になるかと思います。

印象的だったのは、質疑応答の「好きなDB嫌いなDB」です。非常に言葉を選んで回答されてましたが、やはりOracleには複雑な感情を抱いている様子…。Oracleに対するイメージは世界共通ということが伺えました。