この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
大阪オフィスの玉井です。
（ちょっと時間が空いていますが）日本時間の2021年6月9日～10日に、Snowflake Summit 2021が開催されました。
当記事では、Snowflake Summit 2021のセッションの中から、Accelerating Analytical Workloads with Snowflake Performanceというセッションのレポートをお届けします。
概要
Snowflake's Data Cloud eliminates legacy tuning requirements and has flipped the capacity planning paradigm on its head. In this session, you'll learn about the Snowflake engine and its new approach to accelerating analytics. At the end of the session, HYAS will share some of its success accelerating its own analytics workloads on Snowflake.
私なりの要約
Snowflakeは、パフォーマンスの調整に関して、ほとんどの部分はサービス側で勝手にやってくれるため、ユーザーは複雑な管理作業を行う必要はありません。しかし、ElasticsearchやPrestoのような、検索結果を高速で返してくれるようなサービスは依然強いです。そこで、Snowflakeは、検索最適化サービス等の、パフォーマンスを向上させる機能群を開発しました。
このセッションは、その機能の紹介や、実際にその機能でパフォーマンスを向上させた企業の事例紹介が行われました。
セッションレポート
※レポート本文のみ、一人称は登壇者を指します。
前段
皆さん、こんにちは。私はSnowflakeのプロダクトチームに所属するBharath Sitaramanです。今日は、プリンシパルデータプラットフォームアーキテクトであるDarren Gardnerと、HYAS社のシニアソフトウェアエンジニアであるRandy Foxが参加しています。
今日は、当社のパフォーマンス哲学と、どのようにして、Snowflakeのパフォーマンスを上げるか、ということについて説明します。DarrenはSnowflakeのワークロードを最適化するためのベストプラクティスについて話します。そして最後に、Randyが、高い稼働率を誇るプロジェクトのいくつかと、Snowflakeでのデータ分析ワークロードをどのように高速化したかについてお話しします。
どうやってパフォーマンスを出すか
私たちは、会社の設立当初から、使いやすいクラウドプラットフォームを作るという難しいことに挑戦してきました。シンプルさを追求することは、意外と難しいものです。私たち人間は、複雑にしすぎたり、十分に機能するものに甘んじたりする傾向があります。しかし、直感的に使えるシンプルなものを目指したり、ワークロード間の強力な統合とサポートを実現したりするには、努力が必要です。パフォーマンスについて考えるとき、私たちはすべての複雑さを取り除くことを目指しています。
私たちの哲学は、ユーザーによる手動のメンテナンス作業を無くすことです。ツマミを調整したり、インデックスを追加したり、クエリのヒントを追加したりする必要はありません。分散キーも必要ありません。私たちは、パフォーマンスをできるだけ簡単に、そして見えないようにすることを目指しています。
私たちが開発した、様々なパフォーマンスに関する機能は、以下のような次元で考えることができます。
セルフオーガナイゼーションストレージ。これは、入力されたデータを最適化して保存する当社の自動パーティショニングに始まり、あらゆる種類のデータを高圧縮し、ペタバイト規模でも高速な応答時間を実現します。さらに、特定のデータを整理・検索するための自動クラスタリングや検索最適化などのサービスも提供しています。
第二に、コンピュートは、ストレージとは別に拡張することができます。ワークロードごとに専用のコンピュートリソースとクラスターを持ち、個々のコンピュートクラスターのサイズ調整、ユーザーの同時実行性への対応、マルチクラスターウェアハウス機能、クエリのバーストが必要なときに自動的にコンピュートリソースを追加するなど、ワークロードのニーズに応じてサイズを変更することができます。そして、これらすべてがSnowflakeに組み込まれた瞬間的な非弾力性（instant inelasticity）と結びついています。コンピュートクラスターを瞬時に立ち上げたり、立ち下げたりすることができます。
Snowflakeでは、コンピュートを再利用してパフォーマンスを向上させることもできます。永続的なクエリリザルトを使用し、クエリに何も変更がない場合は、同じ計算は行いません。頻繁にアクセスするデータは、コンピュートクラスターの近くにキャッシュします。また、頻繁に使用する射影や集計を保存することで、クエリを高速化し、計算量を減らすことができます。
これらはすべて、Snowflakeの主な設計方針の一つである「使いやすさ」に基づいており、パフォーマンスは難しいものではありません。私たちが目指しているのは、ユーザーによるメンテナンスをほとんど必要としないこと。ノブやインデックス、クエリヒント、分散キー、ソートキーなどを気にする必要がありません。チューニングのための煩雑な負担から解放され、実際の作業に集中できるようにしたいと考えています。
Snowflakeのパフォーマンスに関する機能
次に、Snowflakeのパフォーマンスと最適化に関する主要な機能について説明します。なお、ここではパフォーマンスと最適化を別の概念として扱っています。パフォーマンスは処理のスピードに関係し、最適化はコストも考慮して、より高い効果を得られるようにするものです。
ストレージ
Snowflakeは、マイクロパーティションと呼ばれる不変のデータブロックにデータを格納します。マイクロパーティションとは、今日の分析システムで一般的に使用されているカラム構造です。
マイクロパーティションは、Snowflakeによって完全に管理されています。各マイクロパーティションは、カラムレベルの統計メタデータと統合しています。これにより、従来のデータベースシステムで使用されていたツリー型インデックス構造では実現できなかった規模で、ワークロードをコンピュートクラスターに分散させることが可能になります。また、Snowflakeは、各クラウドプロバイダーのオブジェクトストレージインターフェースを活用できるように最適化されています。
Elastic Scalable Compute
Snowflakeのコンピュートは、仮想マシンやノードの集合体である仮想ウェアハウスを通じて提供されます。はっきりさせておきたいのは、これらのノードにはデータは一切保存されないということです。すべてのデータは、先ほど説明したマイクロパーティションに保存されます。1つまたは複数のノードがクラスターにグループ化されます。
クラスターのサイズはTシャツサイズで指定され、常に2の累乗になります。XSmallはシングルノード、4XLは128ノードです。
標準的な仮想ウェアハウスには1つのクラスターしかありません。マルチクラスターウェアハウスは、複数のクラスターで構成されており、制御するクラスターの最小数と最大数に加えて、Snowflakeがインバウンドロードやウェアハウスに対する変化に基づいてクラスターを動的にスピンアップまたはダウンさせる速度に影響を与えるスケーリングポリシーで構成されます。
キャッシュ
Snowflakeでは、サービス全体で3つの主要な形態のキャッシングを利用しています。
ウェアハウスクラスタの各ノードのローカルSSD上にデータキャッシュがあります。すべてのデータは最終的にクラウドストレージに保存されるため、クエリ処理のためにクラウドストレージからノードにデータを取り込むには、ネットワークを介した読み取りが必要となります。SSDキャッシュは、よくアクセスされるデータのネットワークI/O量を大幅に削減することができます。
また、クエリの結果をすべて保存するリザルトセットキャッシュもあります。そのため、同じクエリを再発行しても結果が変わらない場合は、クエリ処理を行わずに既存の結果を返します。これはクラウド・サービス・レイヤーによって完全に管理されています。そのため、仮想ウェアハウスとは無関係に利用でき、24時間保持されます。そして、このタイマーは、結果セットにアクセスするたびにリセットされます。
そして最後に、クラウド・サービス・レイヤーにはメタデータキャッシュがあります。Snowflakeは、ハイパフォーマンスなサービスとして、重要なメタデータをキャッシュし、特定の操作を最適化します。例えば、SHOWコマンドのようなものです。このキャッシュは、エンドユーザーであるお客様には見えません。しかし、ここではSnowflakeの一部として、Snowflakeの全体的なパフォーマンスの話をしています。
ANSI SQLと関数
SQLに精通しているユーザーは、Snowflakeの強力なSQLクエリオプティマイザーを利用して、標準的なクエリに対する答えを出すことができ、驚くほどのパフォーマンスを発揮します。また、JSON、XML、parquet、Avro、ORCなどの一般的なフォーマットの半構造化ドキュメントデータをネイティブにファーストクラスでサポートするとともに、半構造化データを効率的に処理するための豊富な構造体や関数を提供しています。LATERALは、FLATTENと共に使用することで、ドキュメントを行にアンピボットすることができ、array_eggおよび object_eggは、行を半構造化ドキュメントにピボットすることができます。
サーバーレスな機能
仮想ウェアハウスに加えて、Snowflakeはサーバーレス機能という形でコンピュートリソースを提供しています。Snowpipeと呼ばれるデータインジェストサービス、自動クラスタリング、検索最適化サービス、マテリアライズドビューメンテナンスサービスなどです。
最近のSummitで発表され、現在プライベートプレビュー中の Query Acceleration Serviceは、仮想ウェアハウスに、動的に追加のコンピュート能力をバーストさせることができるので、期待しています。
クエリプロファイラ
Snowflakeのグラフィカルなクエリプロファイラは、クエリ実行のさまざまな側面を可視化します。実行計画をグラフィカルに表示し、詳細およびサマリーの実行統計情報を提供することで、クエリのチューニングを支援します。
モニタリングのためのテレメトリ
Snowflakeは自動的に収集し、すべてのお客様に豊富なテレメトリを提供します。これにより、Snowflakeのクエリアクティビティやクレジット消費に関するインサイトを得ることができ、リソースを効果的に最大限に活用することができます。当社の最も成功しているお客様は、これらの情報に基づいて強力なダッシュボードや自動化を構築しています。information_schemaビューとテーブルバリュー関数でリアルタイムの情報を、account_usageビューで1年分の履歴情報を得ることができますので、ぜひ熟知しておいてください。
ネイティブコネクタとドライバ
最後に、Snowflakeには、プラットフォーム上でシーケンサーベースのオペレーションをオーケストレーションするために使用できるコネクターやドライバーの豊富なエコシステムがあります。これらのコネクタの多くは、プッシュダウン操作などの特殊な最適化機能を備えており、Snowflakeのスケーラブルな並列実行エンジンのパワーを十分に活用することができます。
その他のパフォーマンス関連機能
ここでは、パフォーマンス関連のサービスについて、もう少し詳しくご紹介したいと思います。
自動クラスタリングサービスでは、1つまたは複数の列を組み合わせてクラスタキーを定義することができます。これにより、マイクロパーティションへの行の割り当て方法に影響を与えます。マイクロパーティションは列指向であるため、より良いプルーニングを行うためには、マイクロパーティション内の行の順序は関係ありません。基本的に、クラスタリングのアイデアは、一般的にフィルタリングされる列の狭い最小-最大範囲を生成することです。これは、最高レベルのプルーニングを達成するためで、結合キーの相対的な範囲に応じて、ある程度の結合も可能です。
検索最適化サービスは、値を、その値を含むマイクロパーティションのリストにハッシュマップする辞書に似ています。そのリストに入っていない他のすべてのマイクロパーティションは、効果的にプルーニングされます。マイクロパーティションのサブセットにしか存在しないユニークIDのように、カーディナリティの高いカラムを検索する場合に有効です。クラスタリングとは異なり、検索最適化では、効果的なプルーニングを実現するために狭い最小-最大範囲を必要としません。サポートされているすべての列に対して、テーブルレベルで有効であり、アドホックなアクセスパターンやフィルタ条件が多岐にわたるテーブルにお勧めです。
マテリアライズビューはデータベースの世界ではかなり一般的なものです。マテビューがパフォーマンスを向上させる状況はいくつかあります。例えば、GROUP BY、WHERE句での行のフィルタリングされたサブセット、CLUSTER BY句のような行の代替ソート、外部テーブルへの行の遅延取り込み、クラウドストレージのファイルからマイクロパーティションへの取り込みなどがあります。Snowflakeのマテビューの利点は、マテビューを直接参照するようなSQLを書く必要がないことです。クエリの自動書き換えができるようになっているからです。マテビューを持つテーブルに対してクエリが発行された場合、オプティマイザは、ベーステーブルの代わりにマテビューからデータを取得する方が効率的である場合に選択することができます。
サーバーレスタスクでは、パイプラインタスクを自動化することができますが、最適化はSnowflakeで行われます。この機能は、定期的なイベントとして実行されるSQL文をスケジューリングすることで動作します。これは現在、一部のお客様でプレビュー中です。
最後に、最近のオンラインサミットで発表されたクエリアクセラレーションサービスは、現在、プライベートプレビュー中です。このサービスは、大規模なクエリの中の特定の処理に対して、大量の演算処理を追加することができます。これにより、かなりの数のマイクロパーティションをスキャンする必要があるにもかかわらず、実際にはその後の処理で、より小さなサブセットの行を処理するだけで済むような場合に、仮想ウェアハウスを、より大きなサイズにオーバープロビジョニングする必要がなくなります。この場合、追加のコンピュートスレッドが自動的に投入されて並列読み取り能力が拡張されますが、残りの作業は仮想ウェアハウスが単独で完了するようになります。この設定は仮想ウェアハウスレベルで行うことができ、ユーザーが要求するコンピュートリソースの倍率として指定されます。
Snowflakeのパフォーマンスにおけるベストプラクティス
Snowflakeは、すぐに使える素晴らしいパフォーマンスを提供します。ここでは、リソース管理、データエンジニアリング、シーケンス最適化の3つのカテゴリーに分けてご紹介します。
まずリソース管理ですが、Snowflakeのユニークなアーキテクチャは、コンピュートとストレージを分離するだけでなく、ワークロードアイソレーションと呼ばれる、コンピュートとコンピュートを分離する別の強力な機能も実現しています。これにより、コンピュートリソースの競合が減るだけでなく、ワークロードを適切なサイズのコンピュートクラスターにマッチさせることができ、ワークロードごとに費用やSLSを最適化することができます。
Snowflakeに搭載されているリソースモニターを利用して、仮想ウェアハウス内のクレジット消費にガードレールを敷くことを強くお勧めします。
今日の世界では、分析的な洞察力が威力を発揮するため、パフォーマンスとクレジット消費の両方の主要な指標を表すダッシュボードを介して利用できる豊富なテレメトリ情報を活用することをお勧めします。ダッシュボードだけでなく、同じテレメトリを使用して、カスタムした閾値を超えたときにプロアクティブに行動するジョブの統合も検討してください。私が担当したあるお客様では、自動クラスタリングのコストを自ら監視し、クラスタキーの定義が不十分で割り当てられたクレジット予算を超えたテーブルに対しては、プログラムで無効化するようにしていました。
また、注目すべき重要な指標のひとつにスピリングがあります。ローカルスピリングは、複雑なクエリによってノードのメモリが一杯になり、ローカルSSDに波及した場合に発生します。リモートスピリングは、SSDが一杯になり、一時的な結果をリモートストレージに流出させる必要がある場合に発生します。中程度のローカルスピリングは一般的で、少量のリモートスピリングはしばしば許容範囲内ですが、リモートスピリングが急増した場合は調査が必要です。
データエンジニアリングでは、データをモデル化する際、データ型は重要です。一般的に、文字列ではなく整数を使用するという選択肢がある場合、数値型の方がはるかに効率的であることが多いです。
データパイプラインの複数のDMLステップを1つのDMLに統合することができます。例えば、複数の挿入、更新、削除は、多くの場合、1つのマージDMLとして書き換えることができます。各DMLは新しいマイクロパーティションを作成することになるため、オーバーヘッドが発生し、テーブルのクラスタリングにも悪影響を及ぼす可能性があります。タイトなループを避け、可能な限りセットベースのSQLに置き換えてください。
エンド・ツー・エンドのパイプラインのレイテンシーが重要な場合は、ELTの採用を検討してください。ETLアプローチよりもELTアプローチを採用することを検討してください。半構造化データを直接バリアントカラムにインジェストすることで、Snowflakeはインジェスト中に半構造化データを自動的に解析し、ほとんどの標準的なシナリオでメタデータの統計情報を取得します。また、半構造化属性の一部をそのカラムに取り込み、残りをVARIANT型に残すというハイブリッドなアプローチも可能です。
ストリームオブジェクトを増分処理に使用する場合、ストレージテーブルへの操作がすべて挿入の場合は、必ずAPPEND_ONLYオプションでストリームを作成してください。高度に最適化されます。
また、データパイプラインで対象となるテーブルのクラスタキーについても考慮してください。パイプラインを構築する際には、場合によっては、クラスタリング状態を維持するためにターゲットテーブルにデータを適用する方法に影響を与えることがあります。
最後に、SQLの最適化についてですが、古くさいと思われるかもしれませんが、事実なのでここで強調しておきます。コーディングスタンダードは多くの場合、SQL最適化の最初のステップです。ですから、自分が確立した基準を守りましょう。なぜなら、ほとんどの場合、コストのかかるフルテーブルスキャンに戻ってしまうからです。
複数のテーブルを結合し、DISTINCTまたはGROUP BYで集約する場合、一連のCTEs（Common Table Expression）内で結合をグループ化し、後続の結合に備えてCTEs内で中間結果を集約することを検討してください。これは「粒度（grain）の設定」と呼ばれ、結合が爆発した後に巨大な集約が行われるという、コストのかかるアンチパターンを避けることができます。さらに、便利なANY_VALUE関数を使用して、GROUP BYを持つSELECT句の非グループキー式のいずれかを返すことで、これをさらに強化することができます。
最後に、照合（collation）を使用するのは、本当に必要なときだけです。照合は間接的なレベルを増やすことになります。そのため、クエリを実行するたびに余分な処理が必要になります。また、一般的に結合キーとして使用される文字列カラムには、絶対に照合を使用しないでください。
ここからは、HYAS社のパートナーであるRandy Fox氏に代わって、パフォーマンス機能をどのように活用し、Snowflake体験をどのように最適化したかを紹介してもらいます。
HYAS社の事例
ありがとう、ダレン。こんにちは、私の名前はランディ・フォックス、HYASのシニア・ソフトウェア・エンジニアです。
会社紹介
HYASは、敵のインフラを独自に理解しているサイバーセキュリティ企業です。HYASは誰も持っていないデータを持っているので、アナリストや顧客はHYASの製品（HYAS INSIGHT）を使って、脅威インテリジェンスやインシデントレスポンスを行うことができます。
例えば、マルウェアを使ったサイバー攻撃を開始する前に、敵対者はマルウェアが指令を出すためのコマンド＆コントロールインフラを構築する必要があります。また、フィッシング攻撃では、悪者がFedExに似せたサイトを用意して、ユーザーの認証情報を取得することがありますが、最高センターはこれらのインフラをスキャンします。また、インフラの知識を利用して、企業から悪意のあるインフラへの通信をDNSリゾルバ経由でブロックするDNSサービスも提供しています。
HYAS社の課題
小さな会社だからこそ、（Snowflakeを導入する前に行っていた）ほとんど管理できていないデータベースとの格闘に時間とお金を費やすのではなく、自社のドメイン問題に集中する必要がありました。
新しいソリューションに対するビジネス要件は、ごく標準的なものでした。並行性制限のないスケーラビリティが必要で、ETLが必要でした。エンドユーザーに影響を与えないためには、パフォーマンスを向上させる必要があり、ハードウェア、ソフトウェア、運用コストを削減する必要がありました。シリーズBの資金を獲得したばかりのスタートアップ企業にとって、コストは特に重要な問題です。目標とするパフォーマンスについては、ビジネスの観点からは難しい制約はありませんが、実行速度は遅くなることはありませんし、できれば速くしたいと考えていました。特に現在のソリューションでは、レポートが一向に終わらないものもあるので、もっと速くできると思っていました。
HYAS INSIGHT
ここで、Snowflakeを採用した、当社のHYAS INSIGHTについて少しご紹介します。当社のお客様は、INSIGHTを使用する際、まさに干し草の中の針を探しているようなものです。INSIGHTを使えば、さまざまなデータセットを利用して、侵害されたインフラの中から悪質な行為者を見つけることができます。
これらのデータセットは、2つのアトリビューション、マルウェアのアトリビューションDNS（IPジオロケーション）、その他いくつかのデータで構成されています。このようなツールを効果的に使うためには、お客様がデータの様々な情報を適切なレスポンスタイムで追跡できなければなりません。当社のIPジオロケーションテーブルが62TB・3620億行ですが、このレベルの規模になると、大変なことです。当社のWHOISデータセットは、2つのディメンションテーブルとファクトテーブルで構成されており、それぞれがファクトごとに複数の行を持っている場合、これを扱うのは困難です。また、当社のコスト分析担当者は、これら3つのテーブルのいずれかにおいて、1つまたは複数のコアカラムを抽出し、相関させることができます。
SnowflakeのPoCを実施
繰り返しになりますが、HYASは小規模な企業であるため、新しいデータベースソリューションへの移行の目的は、迅速であること、大量のデータを移動させること、既存のインフラを最大限に利用してETLパイプラインを移植すること、簡素化、信頼性の向上、パフォーマンスの改善が必要でした。そして、アプリケーションのパートナーになる必要がありました。
移行自体については別のプレゼンテーションで話すことになるかもしれませんが、私たちは移行を簡単かつ迅速に行うことができ、データパイプラインをシンプルにすることができたので、より速く、より信頼性の高いものになりました。
しかし、私たちには検索最適化サービスを使わなければならない大きな要件がありました。それが今回のプレゼンテーションの焦点です。
お客様がマイニングできる各データセットは、一般的なクエリビルダで実行されますが、パフォーマンスの名の下に過度に複雑にしたくありませんでした。主に、特定のクエリに最適化されたデータのコピーを持ちたくなかったのですが、これではコストがかかり、メンテナンスも大変です。PoCでは、Snowflakeが正しいソリューションであることを証明するために、多様なデータセットの中でも最も重要な2つのデータセットを使用することにしました。
このデータセットは、ドメインに関するファクトテーブルと、登録されている情報を含むディメンションテーブルで構成されています。2つ目のディメンションテーブルには、ゲームサーバーの情報が含まれています。カーディナリティは1次元で、このデータセットはプライマリデータベースとパフォーマンスを比較するのに十分な大きさです。
正規化されたスキーマと様々なクラスタリング手法，および非正規化されたスキーマを使用してPoCを行いました。それぞれのアプローチは、あるユースケースでは高速でしたが、他のユースケースでは低速でした。例えば、サロゲートキーでクラスタリングしなかった場合、結合が遅くなりました。日ごとにクラスタリングしないと、新しい行を追加するたびにテーブル全体を再クラスタリングしなければならず、1日中新しいデータが入ってきてしまいます。そのため、日付とサロゲートキーでクラスタリングする必要がありました。検索最適化サービスを使わなければ、パフォーマンスを得ることができたかもしれませんが、私たちは複数のテーブルを異なる列に基づいてクラスタリングしたかったのです。しかし、特定のカラムにクラスタリングすることでジョイントのパフォーマンスが低下したり、非常に複雑になってしまったアプリケーションではうまくいかなかったのではないかと思います。そして、決定論的なテーブルを持たないクエリパラメータもあるでしょう。ユーザーの使用は、テーブル上の複数のカラムでフィルタリングしています。どのテーブルを使うかは、各パラメータの行数によりますが、多くのテーブルを結合しなければなりません。これはあまりにも複雑で、コストがかかりすぎると感じました。
検索最適化サービスにより、正規化されたテーブルとコードをそのまま使って、すべてのユースケースを満足させることができたため、以前よりもパフォーマンスが2～3倍向上しました。
2番目に難しいデータセットは、IPジオロケーションデータです。これはWHOISデータセットと非常によく似ていて、複数のテーブルがあり、ユーザーは複数のカラムをクエリできますが、データサイズが約600倍大きいという例外があります。つまり、データセット全体をPoCのために複製し、複数の構成を試すことはコスト的に難しいということです。
そこで、データのサブセットを使ってテストを行い、スケーラビリティをシミュレートして、より小さなタスクのパフォーマンスを予測してみたところ、検索最適化サービスを活用したWHOISデータのテストと同様の結果が得られました。WHOISデータは、異なるカラムに複数のコピークラスターを行うことができました。 しかし、データの大きさを考えると、（IPジオロケーションは）コスト的に厳しいものがありました。予測されるパフォーマンスには満足しており、Snowflakeに全面的に取り組むことを決断しました。
結果
私たちはレポートを作成し、実際のパフォーマンス指標を得ることができました。ご覧のように、検索最適化サービス∂で得られたパフォーマンスはとても良く、ベータ版での運用を開始することができました。検索最適化サービスを使ったときのパフォーマンスは素晴らしいものでしたが、コードやデータベース構造の変更なしにパフォーマンスが得られたことで、お客様に喜んでいただくことができました。
しかし、Snowflakeでは様々なアイデアを簡単に試すことができるので、もっとパフォーマンスを絞り出せないかと考え、Timebox Optimizationと呼んでいるものを試してみることにしました。
目的は、クラウドサービスレイヤーでスキャンしなければならなかったマイクロパーティションの数を減らして、クラスター化することです。私たちは日付でクラスター化しているので、各クエリの日付時間範囲を最小化して、返されるデータだけを取得されるようにしようと考えました。
私たちのシステムはサーバーサイドでページングを行っています。そのため、ユーザーが時間範囲を選択したとしても、その範囲はページに対して広すぎることがほとんどです。これらは制約やキャストをマイニングしているので、私は、ユーザーがクエリできるカラムのアカウントを追跡するテーブルをすぐに作成することができましたが、データの頻度とページングサイズに最も適していることから、1ヶ月という時間単位で作業することにしました。
これらが動作することがわかってからは、このデータをプリプロセッサとして採用するコードを書きました。サーバーサイドのページングでは、新しいタイマーに合わせてクエリのオフセットを再計算することだけが必要でした。新しい時間の範囲とオフセットを、一般的なクエリコードに追加しました。
ご覧のように、素晴らしいパフォーマンスを得ることができました。37分かかっていたものが、約7秒に短縮されています。私はこの手法を、他の多くのチームでも採用しました。
Snowflakeを採用したもう一つの要因は、HYASのような小さな会社にどれだけ対応してくれるか、という部分でした。
確かに、私たちは大規模なファンでもなければ、めちゃくちゃ大きいデータセットを持っているわけでもありません。しかし、我々には厳しい課題があります。それは、検索最適化サービスのための良いマッチングであり、試練の場でした。私たちは、データを入力するだけの機能で彼らと緊密に協力することができました。彼らは、検索最適化サービスに関する私たちの課題に対応してくれ、レポートやリリースの最中や後に投げかけた課題を受け入れてくれました。この対応力は、検索最適化サービスを超えています。Snowflakeとのやりとりはすべて、パートナーシップのような態度で接しています。私たちは彼らがそばにいてくれることを知っていますし、彼らは私たちの話に耳を傾けてくれます。彼らは、私たちが投げかける厳しい課題を受け入れ続けることができ、難しい問題に絶えず針を動かしています。
まとめ
Randy、Snowflakeの可能性を示す素晴らしいお話をありがとうございました。また、Darrenもパフォーマンス機能の概要を説明してくれてありがとうございました。そしてもちろん、この講演に参加してくださった皆さんにも感謝しています。このプレゼンテーションから何か新しいことを学び、何かを得ていただけたなら幸いです。ご質問やご意見がございましたら、お気軽にお寄せください。ありがとうございました。
おわりに
Snowflakeのパフォーマンスについて意識すべきことがわかるのも良かったですが、Snowflake社のパフォーマンスに対する考えを聞けたのがとても良いです。「Snowflakeに分散キーはありません（必要ない）」というセリフはなかなか…。
印象に残るのはHYAS社の事例です。37分→7秒という劇的な改善結果となっていますが、それが検索最適化サービスの活用によるもの、というのが驚きです。自分でもこの機能は使ってみたものの、ここまで威力のあるものだとは想像していませんでした。Timebox Optimizationという手法についても、チェックしないといけませんね。
「会社規模の大小に関わらず、真摯に対応してくれた」というHYAS社のSnowflake社に対する評価も素晴らしいですね。
14
