[レポート]How NearMap Increased analytics velocity

奈良県でリモートワーク中の玉井です。

Snowflake社の下記のウェビナーを受講したので、レポートします。

ウェビナー情報

公式情報

概要

Legacy data infrastructure was slowing down Nearmap’s data team: time-consuming maintenance, slow analytical queries and full model rebuilds that took up to two days to complete!

Join Jonathan Mak, to learn why Nearmap adopted a modern analytics engineering workflow using dbt, and see how Snowflake has proven to be the best cloud data platform to support that workflow.

登壇者

関連リンク等

補足

Nearmapという企業が、Snowflakeを導入してどういう効果があったのか、そしてdbtというツールとSnowflakeを組み合わせることで、どういう相乗効果があったのかを説明する内容でした。その後、dbtの基本的な機能に関するデモが行われました。

基本的に話すのはNearmapの方とFishtown Analyticsの方で、Snowflake社は主に司会を務める形でした。

レポート

Snowflakeとdbtについて

このウェビナーに参加している人の中には、dbtがどのようにSnowflakeにフィットするのかよく知らない人もいると思うので、まず最初にdbtとは何かを説明したいと思います。

dbtはSQLベースのオープンソースツールで、データ変換やモデルはSELECT文として定義されています。これにより、データアナリストは、よりソフトウェアエンジニアのように仕事をすることができます。つまり、DBAとしては、ロジックを反映したSELECT文を書くことに主眼を置くことになります。テーブルやビューを作成したり、実行順序を定義したりするコードを書く必要はありません。

このように、非常にパワフルなコンセプトなのですが、なぜSnowflakeとdbtなのか…。わかりやすい例えを考えていたのですが、少しくだらないものになってしまいました。先日思ったのですが、もしSnowflakeが焼きたてのバナナブレッドだったら、dbtで乾杯するんじゃないかと…。dbtはあなたのためにトーストしたりバターを塗ったりするものなんじゃないかと…。

Snowflakeがどのように技術的な課題を解決しているかを考えてみると、dbtは最高のクラウドデータプラットフォームと思われるものを構築するために、その上で実行されているすべてのデータ分析のワークフローとコラボレーションの問題を解決しています。多くの場合、私たちは（あらゆるツールを）分離して操作しており、その結果、最適な結果が得られないことが多くあります。ナレッジもサイロ化してしまい、多くの組織がこの問題に悩まされています。しかし、この種の問題を解決するためのプレイブックはソフトウェアエンジニアリングチームにすでに存在しており、dbtは同じ技術をアナリティクスにも適用できるという考えに基づいています。これにより、dbtは前述の問題を解決します。

このパートナーシップはまだ始まったばかりですが、すでに米国では一握りの共同顧客を持ち、ヨーロッパではさらに多くの顧客がこのコラボレーションを絶賛しています。Snowflakeのアーキテクチャを考えてみると、dbtは、Snowflakeのプラットフォームにどのようにフィットしているのでしょうか。Snowflakeのアーキテクチャを考えてみると、dbtはSnowflakeのプラットフォームにどこまでフィットするのでしょうか。Data Opsというのは、私にとって最も理にかなっていると思いました。dbtは、通常、独自のSnowflakeの仮想ウェアハウス上で実行されます。Snowflake特有の弾力性とリソース分離の恩恵を受ける必要がある場合は、複数の仮想ウェアハウス上で実行されます。また、バージョン管理の文書化やテストのフレームワークを使用することができます。

私はdbtを非常に高いレベルで把握しています。それを基に、最新のアナリティクスプラットフォームの3つの重要な特徴を提供します。

1つ目は、より幅広いデータアクセスを可能にすることですが、最終的にはSnowflakeアーキテクチャにより、より多くの人にデータアクセスを拡大し、組織全体で、より多くのワークロードにアクセスできるようになり、共同作業と、より高いレベルの調整につながります。ここでもdbtはソフトウェアエンジニアリングの原則を用いて協調的な取り組みをサポートします。

2つ目は、データがもっと容易に利用可能になり、クエリが作業フォーマットになるように、データをコア資産として扱うことです。プラットフォーム自体と分析結果は、ビジネスの核となる部分になり、ユーザーはサービスレベルの保証を必要とし、決定の根拠となるデータを信頼できるようにします。

3つ目は時間とリソースを解放することです。SnowflakeはDBA側の手動管理の多くを取り払い、労力のかかる回避策やdbtのチューニングを排除し、一方でアナリストが反復的なタスクや支払いを自動化するのに役立ちます。

NearMap社の発表

自組織について

弊社を簡単にご紹介します。私たちはオーストラリアを拠点とした空撮の会社です。アメリカでも強い存在感を放っています。私たちの主な業務は、航空画像の提供です。スライドにあるように、独自のマップブラウザを使って、航空画像を提供しています。当社の顧客は、様々な目的で当社の画像を使用しています。

私が所属しているチームについて少しお話ししたいと思いますが、信じられないほど小さなチームです。大規模なものもあれば小規模なものもありますが、最終的には主にLookerでサービスを提供しています。そこには毎週100人ほどのアクティブなユーザーがいますので、かなりの人数のユーザーにサービスを提供していることになります。私たちは非常に多くの人々にサービスを提供していますが、私たちのチームにはあまり多くの人がいません。

私たちのデータ分析基盤（で使っている技術）の話になりますが、私たちはELTを行っていますが、ETLは行っていません。なぜこの方法にしたかというと、ビジネスロジックを維持することにもっと集中したいからです。あちこちでクエリを調整して、ビジネスと状態に価値を提供することに集中しています。dbtは、私たちが最も時間を費やしているツールで、ビジネスのニーズを理解するのに多くの時間を費やしています。

Snowflakeを導入するまで

このSnowflakeとdbtは非常に相性が良いのです。Snowflakeを採用したことで、以前からあった問題点と、それをどのように解決したかを説明したいと思います。

最初の問題点は、ストレージです。会社が成長するにつれて、顧客のポートフォリオが増え、ツールの使用量も増えてきました。これが意味するのは、データウェアハウスのデータがどんどん増えているということです。問題は、リサイズは非常にリスクが高く、ダウンタイムがかかり、コストもかかりますし、価格設定も柔軟性に欠けることが多く、そのようなことはしたくありませんでした。そこで最終的にやったことは、データウェアハウスからS3にデータをアーカイブすることでした。これの問題は、エンドユーザーにサービスを提供したいと思っていたデータの鮮明さを失い始めたということです。

以前のデータウェアハウスはPostgresをベースに構築されていたのでVACUUMが必要でした。データ量が増えてくると、私たちのVACUUMがどんどん長くなってきて、毎週末に6時間から8時間くらいかけていました。日中も2～3時間はかかりましたが、これはdbtの方法によるものです。dbtはテーブルをドロップして再構築します。dbtはインクリメンタルモデルを構築しています。それが我々にとって意味するのは、我々のクエリをブロックしてくれるということです。また、データを削除してS3にアーカイブするようになってから、この問題はさらに悪化しました。これは非常に多くのことを意味します。1つ目は、私たちがやっていることの価値が低下しているということです。2つ目は、私たちのビジネスユニットに高いSLAを持つことができませんでした。プラットフォームにプッシュされたいくつかのデータは、週末のVACUUMのせいで、私たちが処理を行うことができません。

先程、他のプラットフォームにデータをプッシュしたいと言いましたが、それらのプラットフォームもデータをプッシュしてくれますが、多くの場合、データはJSONで、以前のデータウェアハウスはサポートされていませんでした。そして、パフォーマンスが遅いです。開発者にとって大きな問題は、構文を書くのが大変で、維持するのが大変なことです。しなければならないことがたくさんあります。これはサードパーティのデータソースだけではありません。当社の内部データソースやサービスの一部をご存知でしょうか。これらのデータソースは、JSONデータも持っていますし、非構造化データや（他の）半構造化データも持っています。これらのデータセットを処理し、エンドユーザーに適切に提供することが大きな課題となっていました。

また、「Postgresスタイル」という問題もあります。データウェアハウスでは、ワークロード管理の問題もありました。これはかなり厳密なもので、基本的には何をするかというと、事前に負荷をかけて、利用可能な総計算能力のパーセンテージを、異なるグループのユーザに事前に割り当てるというものです。ビジネス部門が日中にLookerを使用していると、データウェアハウスに問い合わせが集中して、必要な計算量が十分に得られないことがあります。夜間や時間外の時間帯は誰も使っていないので、データウェアハウスのメンテナンスや、データウェアハウス内の大きなテーブルを構築することが多くなりました。dbtはコンピュータを手に入れることができませんでしたが、これはワークフロー管理の合図が硬直化しているためです。

これらの要因をすべて足し合わせると、結果として、満足のいくパフォーマンスが得られませんでした。これが意味するのは、Lookerの中のいくつかのクエリです。通常、大きなテーブルへのクエリは、1分かそれ以上かかることがあります。そして、我々はエンドユーザーからの苦情を受けることがよくあります。なぜ私のクエリが殺されたのかというと、クエリの数が多すぎて、クエリが倒れてしまうことがあるからです。そして、それはまた、データウェアハウスの遅さのためであることを意味します。ビジネスロジックの変更は、ビジネス部門から要求されることが多く、迅速に対応することができますが、非常に大きなテーブルを再構築する必要があるため、週末に時間を設定する必要があります。通常は金曜日の遅い時間に処理を開始して、そのままにしておきます。月曜日に戻ってきて、それがうまくいくかどうかを確認し、もし何かミスがあった場合は、次のサービスウィンドウを待たなければなりません。

そこで、Snowflakeを導入することにしました。6ヶ月前に移行を行いましたが、移行には3ヶ月もかかりませんでした。長く聞こえるかもしれませんが、その間にクリスマスがあり、ケリーが言っていたように私は鎖骨を折っていたので、半分の時間は動けませんでした。

このプロセスでは、私たちのスタックが本当に輝いていました。なぜなら、多くのことを変更する必要がなかったからです。Fivetranはエンドポイントを変更するだけです。

私たちは少しだけ作業をしました。SnowflakeのSQL構文に準拠するために、少しリファクタリングをしなければなりませんでした。しかし、作業はこれだけでいいのです。あとはDBTが処理してくれました。2つのテーブルをゼロからデプロイしてくれました。それには、dbtで既に持っていたビジネスロジックを提供する必要がありました。

また、データテストを定義することもできるので、移行が成功したかどうかについて、非常に高いレベルの信頼性を得ることができます。dbtを使用したことで、移行作業が非常に楽になりました。

Snowflakeを導入したあと

では、Snowflakeを使った後に何が起こったか。以前までの問題についてはどうなったのでしょうか。

まず第一にストレージです。Snowflakeでは、ストレージとコンピュートの間には何の繋がりもありません。つまり、アナリストやエンドユーザーは、すべての過去のデータに完全にアクセスすることができます。SnowflakeはS3とAWSをベースにしているので、以前より多くのデータをベースにできます。そして、スタック全体が、よりモダンになり、エンドユーザーはデータウェアハウスの価値を、より高めることができるようになりました。

さらに重要なことに、これはもうメンテナンスの時間がないということを意味します。これにより、色々な制約を解除して、私たちのビジネス部門にサービスを提供することができました。彼らは通知の中で、マーケティングのためのSLAの高いレベルでそれを行うことができるようになりました。以前はできなかったことですが、今では、これによって全体のサイクルが完結しています。

半構造化データはもちろんですが、Snowflakeは半構造化データ、特にJSONをネイティブでサポートしています。さらに重要なのは、セキュリティ目的でAWS CloudTrailのログを取り込みたいと思ったときに、チームの可能性を大きく広げてくれることです。今はJSONファイルがあるので、それを簡単に読み取ることができます。高レベルのパフォーマンスでは、一定の間隔でログをインポートし、脅威やセキュリティ違反があれば、セキュリティチームに報告することができます。また、社内のデータでも、Snowplowからのデータがあります。イベントデータにはJSONデータが含まれていることが多いのですが、これを処理するのは非常に大変でした。

チームのワークロード管理に大きな可能性をもたらしてくれました。モバイル管理もなく、必要なときに必要な分だけコンピュートをプロビジョニングするだけなので、これ以上のことはありません。ユーザグループをデータウェアハウスに固定された計算能力のプールに入れておく必要はありません。スケールアップ、スケールダウン、スケールアウトが可能になりました。すべての人にすべてを与えるべきだと言っているわけではありませんが、データウェアハウスに柔軟性があることで、私たちの生活はとても楽になりました。

また、これらのSnowflakeの利点は全て足し合わせることになります。前にも言いましたが、当初、クエリの実行時間は1分か2分でした。それが今では10秒かそれ以下にまで短縮されています。以前は2時間かかるような処理もありましたが、これは（対象が）ビッグデータセットのようなもので、先ほどのテーブルのように数十億のレコードが含まれているからです。以前はdbtの実行を毎日のジョブと毎週のジョブに分けていましたが、Snowflakeのおかげで、今では、毎日の処理がたった20分でできるようになりました。これはエンドユーザーがデータの更新頻度を高めることができるということです。以前は、ビジネスロジックを更新したり変更したりしてから再構築するような仕事をしていましたが、今はその必要はありません。以前は週末にどうするか、他のことにどう影響するかを計画しなければならなかったのですが、今では「OK」と言うだけでいいのです。

Snowflakeから得られるもう一つの利点は、チーム内のプラクティスにもメリットがあるということです。スキーマ全体をクローンしたり、データベース全体をクローンしたりすると、物理的なストレージは2倍になるので、以前のデータウェアハウスではできなかったのですが、Snowflakeのゼロコピークローンでは、テスト環境を素早く立ち上げることができました。これは新しくビルドされたテーブルに適用され、変更が有効かどうかを私たちに返してくれます。これで、変更内容をマージする際の信頼性が向上しました。

要約すると、私たちはデータウェアハウスに問題を抱えていました。ストレージの面では、ご存知のように、パフォーマンスの面でも問題がありました。今ではコンピュートの割り当てを調整して対応することができます。そして、ビジネス部門が何を必要としているかを実際に理解し、どのような変更を必要としているかを把握し、どうすればより良いサービスを提供できるかを理解するために、より多くの時間とリソースを確保することができます。

これは、dbtとSnowflakeの相乗効果によるもので、特にSnowflakeにおけるパフォーマンスの凄さはご存知の通りです。また、Snowflakeのパフォーマンスが凄いおかげで、新しいデータプロジェクトを開始することができます。例えば、マーケティングプラットフォームにデータをプッシュしたり、セキュリティログを取り込んだり。Snowflakeのおかげで、これらのプロジェクトを早々に実行することができました。

dbtのデモ

（dbtのデモが実演されました。本レポートでは、デモで行われた内容と、dbtのポイントを簡潔にまとめます。）

dbtのポイント

• 誰もがアクセス可能。パイプラインの構築方法を学ぶための時間をほとんど必要とせず、迅速に行うことができる。
• パイプラインを構築する際には適切にテストされるので、テストなしでデータ変換を記述するだけではなく、テスト自体が簡単で適用しやすい。
• すべてがドキュメント化される。自動的に作成されるので、後々の作業を心配する必要がない
• 本番に向けての作業が簡単。CI/CDを使用で作業が楽。
• これらのジョブは監視されているため、デプロイが簡単なのに加えて、確実に実行されているかどうかを確認するのも簡単。

デモの内容

• データアナリストの立場でデモをする
• 既存の収益データマートにテーブルを追加する
• 追加処理に対していくつかのテストを書く
• その処理を本番にデプロイする
• 一連のジョブが適切に実行されることを確認する

デモ時の画像

おわりに

dbtというツールは、海外のデータ技術界隈（？）では名前をよく見るので気になっていました。dbt自体のブログも書きたいところです。また、さり気なくNearmap社のデータ分析基盤のアーキテクチャが見れましたが、普通にFivetranやLookerが登場しています。海外では特に珍しくないツールになっているのでしょうね。