Snowflake は現在、クラウド データ ウェアハウス プラットフォームの事実上の標準です。パイプライン、ETL、分析、ガバナンスに至るまで、さまざまなデータ タスクをサポートするように設計されています。従来、企業が Snowflake の機能を利用するには、すべてのデータを Snowflake に移動する必要がありました。
しかし、Snowflake は、企業がデータを移動せずに、データがどこにあっても統合したいと考えていることを理解しています。その結果、外部テーブルのサポートの導入により、企業はまさにそれを実現できるようになります。
これは、Snowflake 導入の経済性だけでなく、分析やデータ サイエンスのために Snowflake プラットフォームで利用できるデータの量にも実際の影響を及ぼします。
外部テーブルが利用可能になっても、Snowflake が実行される場所は変更されません。Snowflake は引き続き 3 つの主要なパブリック クラウド (AWS、GCP、Azure) でのみ実行されます。ただし、Snowflake を操作するためにすべてのデータを Snowflake に保存するという要件は削除されます。
おそらく MinIO がこの変更の最大の恩恵を受けています。 MinIO は、高性能のクラウド ネイティブ オブジェクト ストアです。これは、Kubernetes のすべてのフレーバー (アップストリーム、EKS、AKS、GKE など) だけでなく、パブリック クラウド VM、VMWare などの仮想マシンやベアメタル ハードウェアでも動作します。このため、MinIO は、データがどこにあっても、Snowflake 顧客にとってのグローバル データストアになることができます。
適切なデータを適切なユーザーが利用できることを保証するには、これらのマルチクラウド データ レイクに対するきめ細かいアクセス制御が不可欠です。 MinIO はサードパーティの IDP と統合する機能と、その高度なポリシーベースのアクセス制御 (PBAC) 機能により、これが後から考えられるものではありません。
Snowflake は S3 エンドポイント (当然、他のオブジェクト ストアを含む) をサポートしますが、これらのオブジェクト ストアは、企業がデータを保管するすべての場所で実行できるわけではありません。たとえば、アプライアンスはパブリック クラウドや OpenShift、Tanzu では実行されません。一貫したデータどこでも戦略を達成するには、企業は MinIO を採用する必要があります。
さらに、Snowflake は企業にとってミッションクリティカルなものになっています。そのため、現在、これらのシステムには復元力が組み込まれています。この回復力は、クラウド内のリージョンの障害だけを説明するものではなく、クラウド全体の障害を説明します。
以前に書いたように、単一のクラウドへの依存はアーキテクチャとして不十分であることが判明しました。 MinIO は、どこでも利用でき、プライベート クラウド、パブリック クラウド、エッジ クラウド間で複製できる機能を備えており、マルチクラウド データ可用性のための唯一の真のソリューションを提供します。
では、エンドユーザーにとってそれはどれほど簡単なのでしょうか? MinIO に「Bucket1」というバケットがあると想像してください。単なる別のテーブルであるかのように、任意の SnowSQL コマンドを実行できるように設定できます。
例: Bucket1 から * を選択します。
Snowflake のほとんどの機能と同様、MinIO に保存されているデータへの接続も比較的簡単です。
始めるために必要なものは次のとおりです。
Snowflake 環境では、外部テーブルのサポートをオンにする必要があります。 「無効な URL プレフィックスが次の場所で見つかりました: ' s3compat://snowflake/ '」のようなエラーが表示された場合は、おそらく有効になっていないことを意味します。有効にするには、Snowflake 担当者にお問い合わせください。
MinIO セットアップを Snowflake で動作させるための要件は、いくつかだけです。
以下の例では、バケット「snowflake」には 4 つのオブジェクトがあり、フォルダー/サブプレフィックス「sn1」内に別のオブジェクトがあります。 Snowflake はこれらのオブジェクトをすべてフェッチします。
これを Snowflake と統合するには、MinIO サーバーがhttps://play.min.ioにある場合、バケットはhttps://snowflake.play.min.ioでアクセスできる必要があります。
サンプル ファイルは、https://docs.snowflake.com/en/user-guide/getting-started-tutorial-prerequisites.html#sample-data-files-for-loadingから入手できます。
MinIO バケットを Snowflake と統合するには 2 つの方法があります。 1 つ目は「ステージング領域」として、2 つ目は外部テーブルとして使用します。両方見てみましょう
ETL プロセスの一部として、データは通常、データ ソースまたはデータ レイクから選択および準備され、ステージング領域に移動されてから、クエリを実行できるようにウェアハウスにロードされます。
従来、Snowflake のこれらのステージング領域は Snowflake 自体にあったため、次のようなフローになりました。
データレイク (オンプレミス、パブリック クラウドなど) -> Snowflake ステージング -> Snowflake 内部テーブル
企業は、MinIO をステージング領域として設定し、データを内部の Snowflake テーブルに直接移動してクエリを実行できるようになりました。
これにより次のことが行われます
新しいフローは次のようになります: MinIO のデータ (オンプレミス、パブリック クラウドなど) -> Snowflake 内部テーブル
次の例は Snowflake コンソールに表示されていますが、同じものを Snowflake CLI を通じて実行できます。
play.min.ioの場合は、使用します
AWS_KEY_ID='Q3AM3UQ867SPQQA43P2F'
AWS_SECRET_KEY='zuf+tfteSlswRu7BJ86wekitnifILbZam1KYY3TG'
Snowflake CREATE STAGE コマンドのリファレンスは、https: //docs.snowflake.com/en/sql-reference/sql/create-stage.htmlから入手できます。
Snowflake のクエリは内部テーブルで実行する必要がありました。これは、アドホック クエリであっても、すべてのデータを Snowflake に移動する必要があることを意味しました。その結果、コストがかかるだけでなく、タイムリーにクエリを実行できなくなりました。
企業は、Snowflake によって導入された新しい外部テーブル アクセス機能を使用して、MinIO バケット内のデータに直接アクセスできるようになりました。
最初のクエリにかかる時間は、転送されるデータの量によって異なりますが、読み取りはキャッシュされるため、次の更新までは後続のクエリの方が高速になる可能性があります。
外部テーブルのアプローチを使用すると、データをコピーする必要がなく、バケットをクエリ、結合などの外部テーブルとして使用できます。
ただし、その代わりに得られるメリットは非常に大きいです。
以下に例を示します。
Snowflake CREATE EXTERNAL TABLE コマンドのリファレンスは、https: //docs.snowflake.com/en/sql-reference/sql/create-external-table.htmlから入手できます。
Snowflake CLI (SnowSQL) を使用して同じコマンドを実行できます。
SnowSQL をプラットフォームにインストールする方法については、https: //docs.snowflake.com/en/user-guide/snowsql-install-config.htmlで確認できます。
唯一の違いは、コマンドで開始する必要があることです。
$ Snowsql -a <アカウント識別子> -u <ユーザー名>
アカウント識別子の形式は、<組織名>-<アカウント名> です。これは、Snowflake コンソールの [管理者] ページから見つけることができます。
それで終わりです。
Snowflake 機能の追加を検討している MinIO の顧客、または Snowflake の外部に保存されているデータにその機能を拡張したいと考えている Snowflake の顧客は、ぜひ試してみてください。いずれの方法でも、現在の投資からさらに多くの利益を引き出すことができます。
ここでも公開されています。