最初のSnowflake Elastic Data Warehouseの概要

当社では、ビッグデータのストレージおよび管理の分野で、新しい興味深いテクノロジーを定期的に試し、分析しています。 4月に、Snowflake Computingの担当者から連絡があり、Snowflake Elastic Data Warehouse製品（クラウドデータウェアハウス）の試用を申し出ました。 彼らは、必要に応じて簡単に拡張できる弾力性のあるシステムの作成に取り組んでいます-データ量、負荷、その他のトラブルが増加しています。



通常、DBMSは、使用可能なリソースの量が使用可能な機器によって制限される条件で動作します。 リソースを追加するには、サーバーを追加または交換する必要があります。 クラウドでは、リソースは必要なときに利用でき、不要になった場合は返却できます。 Snowflakeアーキテクチャを使用すると、クラウドを最大限に活用できます。データウェアハウスは、進行中のリクエストを中断することなく、即座に拡大および縮小できます。



クラウドで動作する他のデータウェアハウスがあり、最も有名なのはAmazon Redshiftです。 しかし、それらを拡張するには、仮想サーバーではありますがサーバーを追加する必要があります。 データの再配布を伴うもの、つまり-ある程度のダウンタイム。 このようなストレージの圧縮については話していません。誰もがすべてのデータをあちこち転送したくないでしょう。



Snowflakeは、顧客にサービス（Data Warehouse as a Service）の形で柔軟なデータウェアハウスを提供します。 これは、標準SQLをサポートし、ACID要件を満たした高性能カラムDBMSです。 データには、Snowflake Web UI、Snowflake Clientコマンドラインインターフェイス、およびODBCとJDBCを介してアクセスします。



完全なスノーフレークテストサイクルを実施しました。これには、データロードのパフォーマンスのテスト、SQLクエリのテスト、システムのスケーリング、および基本的な運用シナリオが含まれます。



ただし、テスト結果に移る前に、アーキテクチャについて詳しく説明する価値があります。

建築

Snowflakeは、プラットフォームとしてAmazon Web Servicesを使用しています。 DBMSは、データベースストレージレイヤー、プロセッシングレイヤー、クラウドサービスの3つのコンポーネントで構成されています。







データストレージレイヤーは、安全で信頼性の高い柔軟なデータストレージを担当します。 これらの優れた機能は、Snowflake自体ではなく、S3によって提供されます。 データはS3に保存され、顧客はそれらに直接アクセスできません。 Snowflakeにデータを読み込むために、Snowflake SQLを使用してデータを読み込むことができるファイルを追加する必要がある特別なS3バケット（ステージング領域）が作成されます。 標準のAmazon Webサービスまたは特別なSnowflake SQL機能を使用して、ステージング領域を作成し、そこにファイルをコピーできます。 既存のS3バケットをステージング領域として接続すると、事前にコピーせずにファイルをダウンロードできます。 ロードされると、データは圧縮（gzip）され、列形式に変換されます。 スノーフレークインデックスは提供されません。



データ配布は、データ使用統計に基づいて自動的に行われます。 パーティショニングなし。



データは、データ処理層を介してアクセスされます。これは、S3ファイルにアクセスできる仮想サーバーのセットです。 「仮想クラスター」は、1（X-Small）、2（Small）、4（Medium）、8（Large）、または16（X-Large）仮想サーバー（EC2）で構成できます。 仮想クラスタ内のすべてのサーバーは同じで同等であり、クライアントはそれらに直接アクセスできません。 クライアントの観点から見ると、仮想クラスターは単一のエンティティです。 EC2サーバーには、標準とエンタープライズの2つのタイプがあります。 テストの時点で、16Gb RAM、160Gb SSD、8コアのEC2が標準として使用されました。 エンタープライズ-2倍。 SnowflakeはAmazonと合意しており、5分以内に新しいインスタンスを取得します。 つまり 仮想クラスターの拡張または新しいクラスターの作成には1〜5分かかります。 EC2はデータを保存しないため、その損失はまったく重大ではありません。 障害が発生した場合、EC2は単純に再作成されます。

仮想サーバーSSDは、クラスターキャッシュとして使用されます。 要求を実行すると、S3からのデータはクラスターキャッシュに分類され、以降のすべての要求はこのキャッシュを使用します。 キャッシュにデータがある場合、クエリは最大10倍高速に実行されます。



同じデータに同時にアクセスする複数の仮想クラスターを作成できます。 これにより、負荷をより適切に分散できます。 たとえば、さまざまな仮想クラスタを使用してさまざまなテーブルにアクセスできます。この場合、さまざまなテーブルのデータがさまざまなクラスタによってキャッシュされ、実際にデータベースのキャッシュサイズが増加します。



Snowflake クラウドサービスは、データの管理に使用されます。 Snowflake UIを使用して、クライアントはデータベースとテーブル、ユーザーとロールを作成します。 メタデータはデータ処理レベルで使用され、必要なアクセス権の可用性を判断したり、リクエストをコンパイルしたりします。 メタデータの保存方法と保存場所については、Snowflakeは説明していません。



各仮想クラスターについて、それが機能するデータベースを選択する必要があります。 リクエストを実行する前に、ユーザーは実行する必要のあるクラスターを指定する必要があります。 デフォルトのクラスターを設定できます。

スケジュールに従ってクラスターを起動できます。リクエストが到着すると自動的に、リクエストが一定時間内に到着しなかった場合は自動的に停止できます。 実行中のクラスター内のサーバーの数を増減することもできます。



その結果、クライアントはエラスティックストレージを受け取りますが、サイズに制限はありません。 インストール、構成、およびメンテナンス手順を実行する必要はありません。これらはすべてSnowflakeによって提供されます。 サイトにアクセスし、テーブルを作成し、データをダウンロードし、クエリを実行するだけです。

特徴

Snowflakeにはいくつかの興味深い機能があります。 たとえば、最近削除されたオブジェクト（テーブル、スキーマ、さらにはデータベース）を復元できます。



別の機能を使用すると、最近実行したクエリの結果を表示できます。 再表示の場合、リクエストを完了したユーザーのみが24時間以内にデータを利用できます。 保存された結果を表示するには、仮想クラスターは必要ありません。 Snowflakeはそれらをメタデータとともに保存します。



Snowflakeは、JSONやAvroなどの部分的に構造化されたデータを処理できることを非常に誇りに思っています。 データは、変換も特定のスキームもなしにそのままロードされます。 その後、レコードの特定の「フィールド」を指定して、SQLでそれらにアクセスできます。 テストの一環として、このような呼び出しの速度はチェックしませんでしたが、通常、このような場合、パフォーマンスは利便性のために犠牲になります。 たとえば、Verticaでは、この機能は通常のテーブルのクエリよりもはるかに低速です。

価格

サービスのコストは、S3のデータ量に対する支払いと、使用される仮想サーバーに対する1時間ごとの支払いで構成されます。 つまり クライアントに4つのサーバーの2つの仮想クラスターがあり、それらが9時間3分間働いた場合、2 * 4 * 10 = 80時間のサービス操作に対して支払う必要があります。 仮想サーバーは、稼働時間に対してのみ支払われることが重要です。 これにより、1日を通して負荷が均等にならない場合や、システムがたまにしか使用されない場合に大幅に節約できます。

テスト中

テストデータセットは、1つの大きなテーブル（10億行強）といくつかの小さなテーブル（10〜10万行）で構成されています-単純な星型の図です。 データは、CSV形式のテキストファイルからダウンロードされました。 Snowflakeは、CPUコア上の1つのファイルに小さなデータをダウンロードすることをお勧めします。これにより、リソースが最も効率的に使用されます。 これを行うには、ステージング領域に入る前にファイルを断片に分割する必要があります。 あるテーブルから別のテーブルにデータをさらに高速にコピーします。 データが変更されると、テーブルは排他的にブロックされます（読み取りは可能です。すべてのDML要求はキューに入れられます）。





次に、単純なクエリに移りました。 ここで、Snowflakeは私たちを満足させました。大きなテーブルと小さなテーブルの両方を含む2つまたは3つのテーブルへのクエリは、非常に迅速に実行されました。



データがキャッシュされている場合、テーブルのスキャンは10倍以上高速であることがわかります。 また、Snowflakeのスケーリングが優れていることもわかります。 クラスタ内のサーバーの数を増やすと、パフォーマンスがほぼ直線的に向上します。



結果を分析するには、常に標準が必要です。 この場合、これらは5台のサーバーのVerticaクラスターでの同じテストの結果です。 5つのサーバーはすべて同じです：2xE5-2630、32GB RAM、8x1000GB R10 SATA。



したがって、十分なキャッシュサイズがあれば、4 EC2のSnowflake Mediumクラスターは5サーバーのVerticaクラスターと十分に競合できます。 さらに、SnowflakeはスキャンでVerticaをかなり追い越しますが、リクエストの複雑さから遅れを取り始めています。 残念ながら、キャッシュをどの程度信頼できるかは明確ではありません。 監視は利用できません。使用統計も表示できません。 特定のリクエストを実行するために読み取る必要があるデータの量のみが表示されますが、このデータがキャッシュから、またはS3から読み取られた場所は表示されません。 また、テーブルデータを変更する場合、キャッシュが無効になることを考慮する必要があります。 ただし、実際のパフォーマンスを予測するために合成テストデータを使用しないでください。



次のステップでは、Verticaで使用するデータ読み込み手順の再現を試みました。 まず、ファイルのデータは非常に幅の広いテーブル（約200フィールド）に読み込まれ、さまざまな詳細度で集計されて他のテーブルに転送されます。 そこで問題が発生し始めました。 多数のテーブルまたは列を含むクエリは、数分間コンパイルされる可能性があります。 要求を完了するのに十分なメモリがない場合、メッセージは表示されず、代わりに誤った結果が返されました。 多くの場合、エラーメッセージは情報を提供するものではなく、起動時にフォーマットの不一致を診断することは特に困難でした。 Snowflakeはまだタスクの準備ができていないことが明らかになったため、テストを停止しました。

おわりに

テストは約1か月続きました。 この間、Snowflakeのスペシャリストが私たちをサポートし、アドバイスを助け、さらにいくつかのバグを修正しました。 この技術は興味深いものであり、リソースの量をその場で変更する機能は非常に魅力的です。



プロジェクトが新しく、まだ多くのデータがない場合、クラウドデータストレージは価値のあるオプションになる可能性があります。 特に、プロジェクトの運命が不明で、データを保存および処理するためのインフラストラクチャに投資したくない場合。 しかし、すべてのデータとシステムのクラウドへの転送を計画するにはまだ早すぎます。