Snowflakeのアーキテクチャと強み――真のクラウドネイティブを実現する
Herskovitz氏によれば、Snowflakeの差別化要素とそれを支える技術は、以下の5つにまとめられる。
- コンピュートとストレージの分離によってワークロード分離を可能にしたこと
- MPPクラスタによるスケーラビリティ確保――スケールアップ（ノード増加）とスケールアウト（クラスタ単位の増加）
- データとメタデータの分離によるACID準拠のトランザクションサポート
- 半構造データに対するネイティブサポート
- As-a-Serviceとしての提供
以下、1つずつ見ていこう。
Snowflakeは、AWSやAzureといったパブリッククラウド上でDatabase-as-a-Serviceを提供する。クエリを実行した際のリソースベースで課金を行い、その課金粒度は1秒単位という細かさである。
Snowflakeは、メインストレージとしてオブジェクトストレージ（AWSならばS3、AzureならばBLOBストレージ）を採用しており、これによって、オブジェクトストレージの実質的に無制限のスケーラビリティの恩恵を受けられる。また、オブジェクトストレージはSSDなどに比べて安価であり、コスト削減にも寄与する。従来、BI/DWH領域のデータベースでは（何しろ大量データを保持するので）そのストレージコストが大きく、初期費用を増大させる一因になっていたが、Snowflakeは大胆な判断によってイニシャルコスト抑制を可能にしている。
一方、S3などには、1）パフォーマンス上の懸念、2）結果整合性しか持たないため、ACID特性を持つトランザクションサポートが難しい、という2つの問題がある（注3）。
Snowflakeは、1）の問題を解決するため、コンピュートインスタンス側でSSDをキャッシュとして利用する。また、複数のコンピュートインスタンスを束ねてMPPクラスタを構成することで（注4）、ワークロードの増大に応じてインスタンスのスケールアップや、スケールアウトによるクラスタの増減を可能にしている。オンデマンドでコンピュートクラスタにインスタンスを追加したり（クラスタのスケールアップ）、クエリの同時実行性を高めるために複数のコンピュートクラスタを立ち上げること（クラスタのスケールアウト）を可能にしている。クラスタのスケールアップ／ダウンはクエリ実行中など、いつでも実行可能で数秒で完了する。クラスタのスケールアウト／スケールインはコンピュートクラスタの負荷に応じて自動的に行われるため、クエリの実行が終了すると自動的にクラスタ数が削減され、リソース課金は秒単位で計測されるのでコスト効率も良い。
さらに、マイクロパーティションとそのメタデータによる実行計画の最適化によってオブジェクトストレージからのデータ読み込み量を最小限にすることで、パフォーマンスを改善する工夫も取り入れている。
また、2）の課題に対しては、データのRead/Writeをメタデータで管理する機構を用意することで、ACID準拠のトランザクション機能をサポートしている。これによって、1つのMPPクラスタがコミットした更新が、他のクラスタからもすぐに参照できるし、ダーティリードが発生することもない。多くのユーザやチームが協働してデータ更新と参照を行うエンタープライズ用途では、トランザクション機能はBI/DWH領域においても必須である。同じくクエリベースのPay-as-you-goモデルを掲げるGoogle BigQueryがシングルステートメントのトランザクションしかサポートしないのに対して、Snowflakeはマルチステートメント（複数のDML文）のトランザクションをサポートするのも、有効な差別化要素だろう。
「Snowflakeの最大の特徴は、コンピュートとストレージの分離によって、ワークロード分離を実現したことです」とHerskovitz氏は言う。
「それによって、ストレージとコンピュートを独立にリサイズ可能になり、本当のPay-As-You-Goモデルを実現できました。ワークロードを分離できるため、ETLによる大量データのロードが肝心の分析クエリのスローダウンを招く、という従来のデータベースで起きていた問題に悩まされることはありません」（Herskovitz氏）
Snowflakeがトランザクション情報をメタデータで管理している理由は、トランザクションのサポート以外にもある。Snowflakeは、ある時点のスナップショットを復元する「タイムトラベル」という機能や、スナップショットのコピーを複数ユーザで共有する「クローン」、チームや場合によっては企業間でデータを共有する「データシェアリング」といった機能も用意している。こうしたデータリカバリやマルチユーザでの開発や試験を効率化する機能も、エンタープライズユーザには魅力的だろう。
そのほか、XMLやJSONといった半構造データもネイティブサポートしており、一般的なクエリと同等のMPPによるパフォーマンス向上の恩恵を受けられる。従来RDBに基礎をおくデータベースを統合的なDWHとして利用する場合、こうした半構造データを扱うには、NoSQL製品を組み合わせるかどうかの検討を行う必要があったが、Snowflakeはこれらのデータもカバーする統合的なDWHプラットフォームとして機能する。
また、As-a-Serviceとして提供されることで、ユーザは運用管理やチューニングといったタスクに煩わされることなく、データ分析に注力できる。「Snowflakeには、ユーザがいじるチューニングパラメータはありません（もちろん内部には持っていますが）。データベースユーザの本来の仕事はクエリチューニングではなく、データからインサイトを得ることであり、データベースの運用管理は本当なら付随的なタスクのはずです」（Herskovitz氏）
注3
Snowflake社の技術チームは、検討の初期段階において、ストレージとしてS3のようなオブジェクトストレージだけでなくHDFSベースのストレージも検討した。その結果、前者にパフォーマンス上の問題はあるものの、高いユーザビリティ、可用性、耐久性を評価し、パフォーマンスはキャッシュ等の手段で補う選択をしたことを下記論文にて述べている。
注4
MPP（Massively Parallel Processing）とは、BI/DWH向けのデータベースで一般的に採用されるアーキテクチャである。複数のノードによる並列分散処理を行うことで、クエリを高速化する。リソースを常に使い切るためのアーキテクチャであるため、多重度に線形でレスポンスタイムが悪化するという欠点もあり、OLTPには向かない。Teradata、Netezza、RedshiftなどBI/DWH向けデータベースが採用している。
