クラウド データ ウェアハウス Snowflake、Panoply、Repods の包括的な比較

【51CTO.com クイック翻訳】はじめに

Snowflake、Panoply、Repods は、管理されたクラウド アーキテクチャでデータの取り込み、処理、保存、アクセスを可能にする 3 つのクラウド サービスです。データの表示と処理のみを提供できる他のクラウド サービスとは異なり、これらのプラットフォームは大量のデータに対応するコンピューティング リソースとストレージ リソースを提供できるため、クラウド データ ウェアハウス プラットフォームと呼ばれることがよくあります。

データ ウェアハウス サービスは、データの保存と処理を中核機能とし、データの全体的な管理と分析のための強固なクラウド プラットフォーム基盤を提供します。これら 3 つのプラットフォームの視聴者はまったく同じではないため、すべての側面を直接比較することはできない可能性があります。特に Panoply と Snowflake については、オンラインで公開されている情報に基づいてのみ分析しました。

建築

Panoply は、Amazon Redshift データ サービス、Elasticsearch データベース、Amazon S3 ストレージ、Spark コンピューティング アーキテクチャを組み合わせて使用​​します。 Amazon Redshift は、Postgres データベース アーキテクチャから派生し、クラスタリング機能を追加したスケーラブルなデータベースです。ただし、Amazon Web Service としてのみ実行できます。

クラスターにノードを追加することで、アーキテクチャをオンラインで拡張できます。異なる Panoply クライアントが同じインフラストラクチャを共有できるため、1 つのクライアントのクエリ負荷が高いと、他のクライアントのクエリ パフォーマンスに影響する可能性があります。 Panoply を使用すると、複数の Amazon Redshift タイプのデータベースを作成できます。つまり、ある意味では、これらのデータベースには別々のストレージ領域がありますが、同じクエリ エンジン (つまり、DBMS システム) を共有しています。

Snowflake は基盤となるアーキテクチャを詳細に公開していませんが、一般的に、オンラインのスケーラブルなプラットフォームを通じてストレージとコンピューティング リソースを明確に分離することができます。 Snowflake を使用すると、同じアカウントで複数のデータ ウェアハウスを作成して管理できます。各ウェアハウスのコンピューティング クラスターのサイズを詳細に構成し、各ウェアハウスの自動オンライン スケーリング ルールを構成することで、サービスを中断することなく垂直拡張 (単一のコンピューターでより多くのリソースを使用する) と水平拡張 (より多くのコンピューティング リソースを導入する) を実現できます。もちろん、各ウェアハウスのパフォーマンスが安定するように、Snowflake のデータ ウェアハウスはコンピューティング リソースを共有せず、外部ツールを使用してデータベースに直接アクセスします。

Repods のインフラストラクチャには、ネイティブ PostgreSQL (バージョン 10 以上) と TimescaleDB が含まれます。データベースは、長期間にわたるパーティション化されたデータ、ストレージ クラスター管理、拡張ストレージ、および多くのデータ ウェアハウス関連サービスに使用できます。現在、Repods は信頼性の高い I/O 速度と PB レベルのオンライン拡張を提供できますが、コンピューティング リソースを拡張するプロセスには依然として数秒のデータ ウェアハウスのダウンタイムが必要であり、容量の弾力性がありません。アカウントごとに複数のデータ ウェアハウスを作成、管理、共有できます。ただし、プラットフォーム内のさまざまなデータ ウェアハウス インスタンスは、主にクラスター内の他のインスタンスと共有されない専用リソースに依存しているため、安定したクエリ パフォーマンスが実現されます。

インポートインターフェース

インポート インターフェイスは次の 4 つの部分に分かれています。

[[276650]]

• ファイル -依然として最も一般的なデータ形式です。
• Web サービス -インターネット上には関連データが多数存在します。
• データベース –通常、さまざまな種類のデータがさまざまな組織の従来のデータベースに保存されており、組織によるこれらのデータベースへのアクセスは通常インターネットに公開されていないため、クラウド データ プラットフォームで直接使用することはできません。その後、オンプレミスのデータベースとクラウド サービスの間に Web サービスを配置して、アクセス制御などのセキュリティ関連の問題を処理できます。もちろん、別の方法としては、安全なジャンプ ホストで ssh トンネリングを使用する方法もあります。
• リアルタイム ストリーム -リアルタイム データ ストリームは、さまざまなメッセージ ルーターによって配信されます。モノのインターネットの台頭により、それらはますます重要になります。

Panoply は、上記の 4 つの領域すべてにおいて幅広いインポート オプションを提供します。ただし、私たちが持っている情報によると、Panoply は自動スケジュールに従ってクラウド ストレージ バケットまたは SFTP からファイルを抽出することも、スケジュールに従って RESTful URL を要求することもできません。

Snowflake は、ファイルの読み込みのみに重点を置いていますが (cat.II など)、Amazon S3 や Microsoft Azure などのクラウド ストレージからファイルを読み込むこともできます。 Snowflake を使用すると、新しいファイルが到着するとそれを監視し、タイムリーに読み込むことができます。

Repods では、ファイルをアップロードしたり、S3 バケットからファイルを読み込んだり、外部の SFTP サーバーからデータを読み込んだりできます。 Repods は、すべての Web サービスに対して個別のインターフェースを提供するわけではありませんが、あらゆるタイプのサービス (Socrata など) の Web リクエストを受け入れるために使用できる共通 API を提供します。ユーザーはデータベース間でデータをインポート/エクスポートすることはできませんが、Repod を通じてメッセージ ルーター (現在は WAMP のみ) 上のさまざまなトピックをサブスクライブして受信し、マイクロバッチでデータを抽出できます。

データ変換 ETL

通常、データ プラットフォームにインポートされたデータは、データ ストリームで分析する前に変換する必要があります。このプロセスは ETL (抽出、変換、ロード) と呼ばれることが多く、生データ用のテーブルの作成、データ型の割り当て、値のフィルタリング、既存のデータの結合、派生列/行の作成、生データへのさまざまなカスタム ロジックの適用などが含まれます。

業界では、ETL を作成および管理するプロセスをデータ エンジニアリングと呼ぶことがよくあります。このプロセスは時間がかかるだけでなく、管理者のエネルギーも消費します。大規模なデータ ウェアハウスには、さまざまなステージ、依存関係、処理順序を持つ数千の ETL プロセスが含まれることがよくあります。

Panoply では、コードを使用してデータ変換を作成します。各データ アクセスに対して、一部の変換によって再計算された仮想結果 (「ビュー」) が提供される場合があります。再計算の作業負荷を軽減できるものもあります。私たちの知る限り、Panoply では、データがすでにマテリアライズされている場合、更新を取得するにはデータを手動で更新する必要があります。たとえば、新しいデータが表示されたら、ユーザーは「更新」をクリックして変換を実行する必要があります。

ソースのサイズと変換の複雑さに応じて、専用の管理結果テーブルへの中間結果の保存を無効にすることができます。一般的な方法は、テーブル内の既存のデータに新しいデータを段階的にロードすることです。もちろん、Panoply は履歴記録に対する特別なサポートは提供していません。

Snowflake は、データ変換の処理において Panoply と同様のアプローチを採用しています。 Snowflake の SQL ステートメントを使用して、フォームベースの SQL クエリでデータ変換を実装し、必要に応じて新しいテーブルで後処理することができます。 Snowflake では、Postgres、MySQL、Oracle、DB2 などの従来のデータベース システムと同様に、データ オブジェクトを低レベルで制御できます。テーブル、インデックス、ビュー、クエリ、パーティションなどを作成できます。

さらに、Snowflake を使用すると、特定の時点 (最大 90 日前) のテーブルの状態を照会できます。ただし、Snowflake は、自動データ履歴を「そのまま」サポートしていません。

Repods では、生データを特定のデータ ウェアハウス テーブル (Evo テーブルなど) に変換する、いわゆる「パイプ」を作成できます。これらのクエリでは、実際の挿入のターゲット テーブルで重複排除、キー生成、履歴ログ、バージョン管理などの統合された後処理が使用されるため、変換ごとにデータ挿入戦略を再考する必要はありません。

モニター

通常、大規模なデータ ウェアハウス システムには、数百のデータ テーブルと、データ フローを管理する数百の自動 ETL プロセスが簡単に格納および格納されます。ただし、操作中にエラーが発生することは避けられず、これらのエラーの一部には人間の介入が必要になります。この複雑さに対処するには、プラットフォームの状態を監視する必要があります。

Panoply では、実行されたさまざまなクエリとジョブの履歴を表示できます。アラート ビューでは、サービスやその他の資産に関する問題とそのソースを可視化できます。さまざまなクエリ ログは、ポーリング サービスに基づいて数秒ごとに更新されます (リアルタイムではありません)。

Snowflake 監視レポートは、特定の期間におけるアクティブなクエリの数とそのリソース消費量に関する集計情報を提供します。 Snowflake では、SQL ステートメントを使用してさまざまな内部メタデータ テーブルにアクセスし、システム内のクエリ アクティビティに関する関連する種類の情報を抽出できます。同時に、Snowflake は Web インターフェイスで実行された履歴クエリ操作も表示できます。

Repods は、リアルタイムで更新され、現在および過去に実行されたパイプラインの詳細を表示するグラフィカルな概要を提供することで機能します。 Repods では、SQL ステートメントを使用してシステムのログを分析し、パイプライン実行に関するさまざまな情報を抽出することもできます。

実用性

ユーザー、データ ウェアハウス、テーブル、変換、レポートなどの作成と管理に関しては、クラウド ツールは通常、対象ユーザーに基づいて制御レベルと使いやすさのバランスを取ります。ここで紹介する 3 つのプラットフォームは基本的にクラウド環境であるため、ユーザーはブラウザベースの Web アプリケーションを使用して直接アクセスし、制御できます。具体的には：

Snowflake は、データベース システムと同様の高度に制御可能な機能をユーザーに提供します。ユーザーは、コード パネルでコードを記述、インポート、集計、表示、インデックス作成、その他の処理を行うことができます。 Web フォームを使用して、データ ウェアハウス全体とそのユーザーの作成や削除などのタスクを処理します。ただし、Web インターフェースはプラットフォーム上のさまざまなアクティビティに自動的に応答しないため、ユーザーは更新を実現するために定期的に (10 秒ごとに) ビューを更新する必要があります。

Panoply では、ユーザーは Web フォームを使用してオブジェクトの作成とデータのインポート設定を処理しますが、それ以上のデータ変換と分析はコード パネルを通じてのみ実行できます。さらに、Panoply はインターフェースの英語版のみを提供できます。

Repods では、ユーザーは Web フォームを通じてオブジェクトの作成を処理し、コード パネルでさまざまなカスタム変換ロジックを処理できます。 Repods データ分析に関しては、ユーザーはワークブック スタイルのアプローチを使用してカスタム分析クエリを作成したり、組み込みの OLAP ツールを使用してクリックするだけでデータ モデルをすばやく理解したりできます。

マルチユーザーワークフロー

ここでの主な比較は、ユーザーインタラクションと、データおよび作業コンテンツの共有のサポートです。一般に、これら 3 つのプラットフォームでは、複数のユーザーが同じデータ環境で共同作業を行うことができます。もちろん、オンラインディスカッションやチャット機能は提供されていません。

Panoply は、すべてのユーザーにインフラストラクチャのような環境を提供し、ユーザーはその上で複数の Amazon Redshift データベースを作成できます。 Panoply では、「管理者」と「編集者」の 2 種類の役割を管理できます。ただし、Panoply プラットフォーム ユーザー間の通信機能はなく、プラットフォーム内のデータ オブジェクトと変換に関するドキュメントも不足しています。

Snowflake では、各アカウントが複数のデータ ウェアハウスにアクセスする方法を細かく制御できます。従来のデータベース システムで使用されるアクセス制御と同様に、これらのデータ ウェアハウス内のすべてのオブジェクトの権限をカスタマイズし、さまざまなロールを作成できます。

Repods では、各ユーザーが複数のデータ リポジトリ (データ ポッド) を管理できるようにし、GitHub プラットフォームと同様のアクセス権限を他のユーザーに付与することができます。プラットフォームの事前設定されたアクセス ロールには、閲覧者、報告者、開発者、管理者、所有者が含まれます。各ユーザーにはさまざまなポッドでロールを割り当てることができ、さまざまなデータ テーブルは「ラベル」によってグループ化されます。もちろん、「タグ」に基づいて各ユーザーを個別に認証することもできます。プラットフォームはリアルタイムなので、ユーザー間のやり取りは他のすべてのユーザーにすぐに表示されます。

データの履歴化

時間の経過とともに、新しく生成されたデータを既存のデータ インベントリに追加する必要があり、データ ウェアハウスではより長い履歴を持つデータを管理できる必要があり、個別のデータ ブロックを均質なデータ履歴にマージできる必要があります。同時に、データ履歴を継続的に管理および適用するために、専用の時間範囲列を使用して、さまざまなテーブルの時間範囲を追跡できます。

Repods はすぐに使用できるデータ履歴化をサポートします。履歴化は通常、データ変換後、データベース テーブルへの挿入前に行われます。このアルゴリズムは、ゆっくり変化するデータに対して最もスペース効率に優れています。履歴レコードを最小限に抑えるこの方法により、テーブルのサイズが大幅に削減され、データ クエリの整合性にプラスの影響を与えることができます。

他の 2 つのプラットフォームのデータ履歴時間範囲は、ユーザーが提供する変換ロジックによって管理されます。 Panoply には「履歴テーブル」と呼ばれる機能があり、これについては後ほど詳しく説明します。

データのバージョン管理

データのバージョン管理を使用すると、一定期間にわたるデータの変更を追跡できるため、必要に応じて古いバージョンに復元したり、既存のデータに非破壊的な変更を加えたりすることができます。クラウド データ ウェアハウスのバージョン管理機能を比較する場合、バージョンの作成がどれだけ簡単か、およびバージョンの復元やクエリがどれだけ簡単かを考慮する必要があります。バージョン管理はさまざまなシステム レベルで処理できます。

• バックアップと同様に、ストレージ サブシステム上のバージョンのスナップショットを作成します。
• 基盤となるデータベース システムはバージョン追跡をサポートできます。
• バージョン管理はデータ ウェアハウス システムによって処理できます。
• バージョン管理は、ユーザー空間でカスタム変換ロジックとして実装できます。

Panoply には継続的なバックアップによるバージョン管理が組み込まれています。バックアップ時間範囲内のスナップショットの任意の時点に復元できますが、この方法を使用してアクティブ システムのバージョンを照会することはできません。 Panoply では、「履歴テーブル」を作成して、元のテーブルにコンパニオン テーブルを挿入することもできます。

元のテーブルで更新が発生すると、システムは変更を示す時間間隔で同じレコードをコンパニオン テーブルに自動的に挿入します。これらの履歴テーブルを使用すると、SQL ステートメントを使用して同じデータの異なるバージョンを照会できます。

Snowflake を使用すると、すべてのデータのスナップショットを簡単に作成し、データベース システムが提供する「タイム トラベル」機能を利用できます。この機能により、SQL ステートメントを使用して特定の時点でデータを柔軟にクエリできます。ただし、この機能は Enterprise Edition でのみ利用可能で、90 日間の履歴のみが含まれます。つまり、ユーザーはより長い期間にわたってバージョン管理ロジックを自ら実装する必要があります。

現在、Repods は、あらゆるデータ ウェアハウスのユース ケース向けに設計された継続的なバックアップおよびバージョン追跡サービスを提供していません。 「フリーズ」タイムスタンプを指定することで、データの回復可能性を確保できます。シンプルな SQL ステートメントを使用して、さまざまな凍結時間 (無制限の日数) のデータを柔軟にクエリできます。

分析/レポート

データ プラットフォームの最も基本的なタスクの 1 つは、大量の生データをさまざまな方法で分析し、そのデータをより長い履歴レコードとして保存することです。

[[276651]]

現在、大規模なデータベースからデータを抽出して集約し、自動分析を実行し、関連レポートを読み取り可能な形式で提示できる商用インテリジェンス ツールが数多くあります。

Panoply と Snowflake はどちらも、データ変換、分析、集計を作成するための SQL コード エディターを提供します。どちらのプラットフォームでも、ユーザー名とパスワードを使用して ODBC (および同様のツール) ツール経由でアクセスできます。したがって、Jupyter ワークブックや PowerBI などの専用の分析ツールを使用して独自のデータを分析できます。ただし、プラットフォーム上のリソースを使用して Python を実行したり、機械学習モデルをトレーニングしたりすることはできません。同時に、これらのワークブックの結果をプラットフォーム内のデータ ワークフローに統合することはできません。

現在、Repods ではユーザーが外部ツールを使用してプラットフォームにアクセスすることはできませんが、さまざまなデータ ストーリーや分析抽出を作成するための独自のワークブック タイプをユーザーに提供しています。ここでのワークブックとは、多数の SQL コード パネルとドキュメント パネル (「Markdown」を使用) で構成されるワークシートを指します。もちろん、ワークブック形式の分析に加えて、Repods には OLAP (オンライン分析処理) インターフェイスも含まれており、ポイント アンド クリック方式を使用してデータ モデルを理解したり、レポート結果を作成したりできます。

データサイエンス

機械学習モデルの作成は、データ プラットフォームが提供する必要のある新しいタイプのサービスです。現在、業界では一般的に、numpy、pandas、scikit learn、tensor flow、pytorch などの独自のライブラリを備えた Python または R 言語を使用して実装しています。

ただし、これらのプラットフォームのいずれも、プラットフォーム上でデータ サイエンス タスクを直接実行する方法を提供していません。したがって、一般的な戦略は、指定されたツールを介してプラットフォームにアクセスし、すべてのデータ サイエンス関連タスクをプラットフォーム外で実行することです。選択できるツールは多数ありますが、要求の厳しい機械学習タスクをサポートするために、管理されたコンピューティング リソースに依存するという課題に直面する可能性があります。

外部アクセスとAPI

3 つのプラットフォームがデータ コンテンツを外部ユーザーにどのように表示するかを次の観点から比較します。

• SQL アクセス。
• API アクセス (REST リクエスト)。
• テキストプッシュまたは電子メールによる通知。
• ファイルのエクスポート。

Panoply を使用すると、ODBC と同様の方法で、ユーザー名とパスワードで保護されたプラットフォームにユーザーが直接アクセスできます。ほぼすべての標準的なビジネス インテリジェンス ツール (Looker や Tableau など) を Panoply に接続して、そのデータを使用できます。 Panoply はシステム上のアラートを追跡しますが、テキスト メッセージや電子メールは送信しません。

Snowflake は、SQL アクセスとそのデータを他のツールに提供できるだけでなく、ファイルをクラウド ストレージ バケット (AWS S3 または MS Azure) にインポートすることもできます。ただし、ユーザーは一般的な Snowflake サービスの可用性に関する電子メール通知のみを設定できます。

Repods では、API アクセス キーを作成し、プラットフォーム データを抽出するためのアクセスを制御できます。これらのアクセス キーを外部の消費者に配布することで、消費者は任意のプログラミング言語で標準化された REST リクエストを使用してプラットフォームのデータ リソースにアクセスできるようになります。これにより、ビジネス インテリジェンス ツール PowerBI を Repods プラットフォームに接続して、さまざまなダッシュボードを作成し、ブラウザーから直接無制限のサイズのファイルをエクスポートおよびダウンロードすることもできます。ただし、このプラットフォームは現在、いかなる種類のプッシュ通知も提供していません。

書類

データ エンジニアリングは、一度だけ、偶然に必要になるものではないことが多いため、すべての主要プラットフォームは、完全な機能紹介と詳細な情報ドキュメントを提供する必要があります。

Snowflake は広範なオンライン ドキュメントを提供します。 SQL ステートメントは広範囲に使用されるため、これらのドキュメントの構造はデータベースやプログラミング言語のドキュメントと非常に似ています。さらに、そのドキュメントのほとんどは SQL 関連の関数に関するものになります。さらに、Snowflake では、ユーザーがプラットフォームに慣れて試してみるのに役立つガイドや YouTube ビデオも多数提供しています。

Panoply もオンラインドキュメントを提供していますが、Snowflake ほど詳細ではありません。もちろん、Panoply は SQL アクセス用に基盤となる Amazon Redshift をユーザーに直接公開しているため、ユーザーは Amazon Redshift の SQL ドキュメントを直接参照できます。 Panoply は、データ ウェアハウスに関する一般的なガイダンスの提供に加えて、YouTube チュートリアルもいくつか提供しています。

Repods は、Web API の使用に関する個別のオンライン ドキュメントのみを提供します。たとえば、RESTful Web リクエストを使用して Python、JavaScript、PHP を使用して Repods のデータにアクセスする方法などです。通常、プラットフォームは、さまざまな使用方法ドキュメントを対応するツールに直接埋め込みます。 Panoply と同様に、ユーザーは SQL サポートについて元の Postgres ドキュメントを直接参照できます。さらに、Medium.com では、Repods が一連の技術記事と YouTube スタイルの詳細なビデオを公開しています。

安全性

一般的に、データ プラットフォームのセキュリティは、主にストレージ (保存データ)、インタラクション (転送中のデータ)、およびアクセス制御に反映されます。現在、3 つのプラットフォームはすべて、保存時および転送中のデータを暗号化できます。アクセス制御に関しては、どちらもパスワードベースのユーザー認証を提供します。

さらに、Snowflake は最も安全な 2 要素認証メカニズムも提供します。 Panoply と Snowflake を使用すると、ODBC のようなインターフェースを介して基盤となるデータベースにアクセスできます。パブリック データベース ポートがインターネットに公開されるのを減らすために、ユーザーは安全な SSH トンネリングと専用のジャンプ ホスト メソッドを使用してアクセスすることができます (また、そうすべきです)。

結論は

完全なデータ ウェアハウス プラットフォームを構築する場合は、Snowflake と Panoply を他のツールと組み合わせてギャップを埋める必要があります。これら 3 つのプラットフォームでは、SQL コードが関係するため、基本的なデータ エンジニアリングの専門知識が必要です。

データ分析用のオンライン データベース アーキテクチャが必要であり、システムとハードウェアの管理に多額の投資をしたくない場合は、Snowflake が適切な選択肢です。これは大規模なデータ環境に適しており、当然ながらプラットフォームを管理するにはデータベース管理者が必要です。前述したように、Snowflake は通常のデータベースと非常によく似ており、データのニーズが特別でない場合は、AWS でホストされているデータベースを選択できます。

Panoply は Snowflake よりもシンプルで、ユーザーがシステム、ハードウェア、データベース管理の専門知識を持っている必要がありません。他の 2 つのプラットフォームと比較すると、Panoply はそれほど複雑でないデータ環境に適しています。

Repods のシンプルさとユーザーに対する技術要件は Panoply と似ています。 Repods のデータ ウェアハウス機能には、自動化、履歴、代理キーのメンテナンスと分析も含まれます。 Repods の管理インターフェースは、大規模な中央データ ウェアハウス アーキテクチャではなく、データ ウェアハウスに対するプロジェクト指向のアプローチに適しています。同時に、Repods はデータのカタログ作成にも使用できます。

原題: クラウド データ ウェアハウスの比較、著者: Melissa Rojas Tänzer

[51CTOによる翻訳。パートナーサイトに転載する場合は、元の翻訳者と出典を51CTO.comとして明記してください。