データレイクとデータウェアハウスは、異なる問題を解決します。データレイクは生データをネイティブ形式で安価に保存し、データウェアハウスはキュレーションされたデータを高速に提供します。これらを個別に、または組み合わせてどのように使用するかは、分析チームができることに影響を与え、最新のデータの規模は、この選択をさらに重要なものにします。2024 年には、毎日 4 億 289 万テラバイトのデータが作成、キャプチャ、コピー、または消費され、年間約 147 ゼタバイトに達しました。
以下では、データレイクとデータウェアハウスを比較し、スキーマ、コスト、パフォーマンス、ガバナンスにおける違いと、ワークロードに適切なアーキテクチャを適合させる方法について説明します。
主なポイント
データレイクはスキーマオンリードを使用して生データを柔軟に保存しますが、データウェアハウスはスキーマオンライトを使用して、ビジネスインテリジェンス (BI) およびレポートに高速で一貫性のあるクエリパフォーマンスを提供します。
成熟したデータチームは通常、階層化されたアーキテクチャで両方のシステムを使用し、生データはデータレイクに保存され、キュレーションされたデータは分析のためにデータウェアハウスに送られます。
独自のパイプラインを構築するという従来の支払いデータのアプローチは、API スキーマの変更によってパイプラインが機能しなくなる可能性があるため、脆弱になる傾向があります。
データレイクとは
データレイクは、データを生のネイティブ形式で保存する一元化されたリポジトリです。これには、構造化データ (テーブル)、JavaScript Object Notation (JSON) ログなどの半構造化データ、非構造化データ (テキスト、画像、動画) が含まれます。
データレイクの背後にある決定的な理想は、スキーマオンリードです。データは生成されたとおりに保存され、後で誰かが解決しようとしている問題を把握したクエリ時に構造が適用されます。この柔軟性により、データレイクは大規模な取り込みと探索的分析に適しています。事前にモデリング方法を決定することなく、事実上あらゆるものを保存できます。
データウェアハウスとは
データウェアハウスは、高速で一貫性のあるクエリを実行するように設計された構造化された分析システムです。
データがウェアハウスに保存される前に、通常は分析に最適化された明確に定義されたスキーマにクリーニング、変換、モデル化されます。このアプローチはスキーマオンライトと呼ばれ、データが保存される前に構造と定義が決定されます。その結果、アナリストは一貫性のないフォーマットや不足しているコンテキストを心配することなく、クエリを実行し、ダッシュボードを構築し、指標を計算できるキュレーションされた環境が構築されます。
データレイクは柔軟性を優先しますが、データウェアハウスは分析の信頼性とパフォーマンスを優先します。
データレイクとデータウェアハウスの主な違いは何ですか？
データレイクとデータウェアハウスの実際の違いは、データの保存場所にとどまりません。構造、使用できるユーザー、クエリにかかるコストも重要な違いです。
構造
データレイクは生データを保存し、クエリが実行されたときにのみ構造を適用します。この柔軟性により、同じデータセットを複数の方法で解釈できます。データウェアハウスはデータの書き込み時に構造を適用するため、注文に対してクエリを実行するすべてのユーザーが同じスキーマと定義を確認できます。
クエリのパフォーマンス
データウェアハウスは、インタラクティブな 分析 用に構築されています。Snowflake や BigQuery などのシステム内の大きなテーブルに対するクエリは、数秒で返されることがあります。レイクストレージ内の生データに対するクエリは、列指向ストレージ、パーティショニング、コンパクションなどの最適化を行わない限り、遅く、コストがかかる可能性があります。
データの種類
データウェアハウスは、レポートやダッシュボードで使用される構造化されたリレーショナルデータに優れています。データレイクはより柔軟であり、生のログ、ネストされた JSON、機械学習データセット、画像、その他の非リレーショナルフォーマットを保存できます。
ガバナンスと信頼性
通常、データウェアハウスのデータは検証および変換パイプラインを通過するため、ビジネスレポートに適しています。データレイク内のデータは生で探索的であることが多いため、本番環境の指標をサポートする前に、通常は追加の処理が必要になります。
コストプロファイル
データレイクは、大量の生データやアクセス頻度の低いデータを保存する場合、はるかに安価です。データウェアハウスは 1 テラバイトあたりのコストは高くなりますが、より高速なクエリのパフォーマンスを提供し、同時実行性の高い 分析 ワークロードをより適切にサポートします。
organizations はデータレイクとデータウェアハウスをどのように併用していますか？
成熟したプラットフォームは両方のシステムを使用する傾向があり、それぞれが最も適したパイプラインの処理を担います。通常、データレイクは生データのランディングゾーンとして機能し、データウェアハウスはキュレーションされた分析可能なデータセットをアナリストやビジネスツールに提供します。
一般的なパターンは メダリオンアーキテクチャ であり、以下が含まれます。
Bronze: 取り込まれた生データ
Silver: クリーニングおよび重複排除されたデータセット
Gold: レポート作成に使用される、集計済みのビジネス対応テーブル
多くの実装では、Bronze と Silver のデータはレイクストレージに配置され、Gold のデータセットはデータウェアハウスから提供されます。
この階層化アーキテクチャの欠点は、その難しさにあります。データはシステム間で複製され、パイプラインによって移動および変換されるため、チームは複数の場所でガバナンスとアクセス制御を管理する必要があります。Organizations は、Delta Lake、Apache Iceberg、Hudi などのテクノロジー上に構築されたレイクハウスアーキテクチャを試験的に導入することで、これを簡素化しています。これらのシステムは、原子性、一貫性、独立性、耐久性 (ACID) トランザクションやスキーマの適用など、従来データウェアハウスに関連付けられていた機能をレイクストレージに直接追加します。
これにより、チームは 2 つではなく 1 つのプラットフォームを使用できるようになります。これがどの程度機能するかは、クエリの複雑さと、それを運用するチームの成熟度によって異なります。
データレイクとデータウェアハウスの選び方
適切な答えは、誰がデータを使用し、何を必要としているかによって異なります。一般的に、組織には要件が異なる複数のチームが存在します。
考慮すべき要素を以下に示します。
ビジネスインテリジェンス (BI) チームおよびレポートチーム
主なユーザーが Looker、Tableau、Metabase などのツールでダッシュボードを構築するアナリストである場合、通常はデータウェアハウスが最適な基盤となります。これらのツールは、一貫したスキーマ、信頼性の高い指標、高速なクエリ応答に依存しています。
データサイエンスチームおよび機械学習チーム
モデルのトレーニングには多くの場合、イベントストリーム、テキスト、行動ログなど、複雑な形式の大量の生データセットが必要になります。データレイクを使用すると、構造化されたテーブルに整形する前に、そのデータを柔軟に保存して探索できます。
大規模なデータを取り込むエンジニアリングチーム
システムが毎日数十億件のイベントを生成する場合、通常はデータレイクが最も実用的な最初の保存先となります。コストが低く、進化するスキーマに適切に対応でき、アップストリームシステムが事前定義されたデータモデルに準拠する必要がありません。
混合ワークロード
組織は両方を組み合わせる傾向があります。データの取り込みと生データの保存にはデータレイクを使用し、キュレーションされたデータセットの提供にはデータウェアハウスを使用し、両者を接続する変換レイヤーを設けます。このタイプのセットアップでは、全体のデータパイプラインの中で各システムがどこに適合するかが問題になります。
決済代行業者はデータレイクまたはデータウェアハウスのアーキテクチャにどのように適合するか
支払いデータへの従来のアプローチは、アプリケーションプログラミングインターフェース (API) を使用してページネーションとレート制限を処理し、結果をストレージに書き込み、実装を無期限に維持する独自のパイプラインを構築することです。
これは機能しますが、脆弱です。API スキーマの変更によってパイプラインが機能しなくなる可能性があり、過去のバックフィルには追加のロジックが必要になり、支払いデータには機密性の高い財務情報が含まれます。つまり、追加のサードパーティの抽出、変換、ロード (ETL) ベンダーを介してルーティングすると、多くの財務チームやコンプライアンスチームが懸念するセキュリティリスクが生じます。
Stripe Data Pipeline は、これらの課題に直接対処します。Stripe が構築および維持するネイティブコネクターであり、既存の Stripe ユーザーが利用でき、Stripe のデータ (取引、顧客、サブスクリプション、入金) をデータウェアハウスまたはクラウドストレージの保存先に直接同期することで機能します。
サードパーティのコネクターと比較して、ネイティブアプローチにはいくつかの利点があります。
データの完全性: Stripe Data Pipeline には、アカウントの過去のデータ、事前構築された財務レポート、およびサードパーティのコネクターが公開しないことや表示するためにカスタムの構成を必要とすることが多い、キュレーションされたデータセットが含まれています。
大規模な信頼性: パイプラインは Stripe 自体によって維持されるため、API の変更を自動的に追跡し、スキーマの進化を処理し、外部コネクターが見逃すことのある Stripe のデータモデルの境界ケースを考慮します。
セキュリティリスクの軽減: 金融取引データは、中間ベンダーのインフラストラクチャーを経由せずに Stripe とストレージの保存先の間を移動するため、データセキュリティの体制が簡素化されます。
Stripe Data Pipeline の機能
Stripe Data Pipeline を使用すると、Stripe のデータを他のビジネスデータと組み合わせることで、データウェアハウスで同じ分析を実行できます。Stripe Data Pipeline と Stripe Sigma はいずれも同じ基盤となる Stripe データを活用していますが、Data Pipeline を使用すると、そのデータを他のデータセットと組み合わせて簡単に表示できます。
Stripe Data Pipeline を使用すると、次のことが可能になります。
ウェアハウスへの直接同期
データはサードパーティのコネクターを経由せずに Amazon Redshift、Snowflake、または Amazon S3 に移動するため、機密性の高い財務データが追加のベンダーのインフラストラクチャーに保存されることはありません。信頼できる唯一の情報源の確立
Stripe のデータを 1 カ所に一元化して、決算処理を高速化し、上位の決済手段を特定し、AI モデルを強化することなどができます。ノーコードでのセットアップ
接続は Stripe ダッシュボードで構成され、ノーコードで完了します。Stripe Data Pipeline を数分でセットアップし、データストレージの保存先で Stripe のデータとレポートを継続的に自動で受信します。
ビジネスデータの活用に Stripe Data Pipeline がどのように役立つかについての詳細を表示します。
この記事の内容は、一般的な情報および教育のみを目的としており、法律上または税務上のアドバイスとして解釈されるべきではありません。Stripe は、記事内の情報の正確性、完全性、妥当性、または最新性を保証または請け合うものではありません。特定の状況については、管轄区域で活動する資格のある有能な弁護士または会計士に助言を求める必要があります。