データレイク vs データウェアハウス

スクレイプレスWebアンロッカーは、チームが管理されたレイク証拠として保持できるパブリックWebコンテンツを取得したり、キュレーションされたウェアハウスの事実に変換したりします。

TL;DR

データレイクは柔軟なソース表現を保持します。 それは多様なフォーマット、独立したコンピュート、そして未来のさまざまな変換を好みます。
データウェアハウスは管理された分析構造を公開します。 それは一貫したスキーマ、共有メトリクス、予測可能なアクセス、および報告を好みます。
スキーマのタイミングは違いであり、欠如ではありません。 レイクは消費者スキーマを後で適用することが多いですが、ウェアハウスは広範囲な使用の前にサポートされた契約を施行します。
ガバナンスは両方のシステムに属します。 所有権、系統、アクセス、品質、そして保持は生データかキュレーションされたデータかに関わらず必須です。
多くのプラットフォームは両方を使用します。 レイクはソースの証拠を保持し、一方でウェアハウスはそれから派生した信頼できるビジネスモデルに役立ちます。

データレイクとデータウェアハウスの定義

データレイクは柔軟な未来の使用のために多様なソースデータを格納・管理し、オブジェクトまたはファイルストレージ上で独立したコンピュートを持つことが多いです。データウェアハウスは、繰り返し可能なクエリ、メトリクス、報告のために最適化された管理された分析構造にデータを統合します。システムは消費者に提供される契約の点で最も異なります。

レイク資産は多くの場合、元のまたは軽微に変換された表現を保持し、それをカタログやオープンフォーマットを通じて公開します。ウェアハウス資産は通常、よりキュレーションされています：キー、タイプ、履歴、次元、メジャー、そして新鮮さのルールが広範な分析使用のために定義されています。ここで使用される主要な用語は、データレイクアーキテクチャとメタデータの調査、それは概念に具体的な技術的境界を与え、マーケティングラベルとして扱うのではありません。

便利な比較は、各モデルがどのような作業を整理するか、どのリソースが同時に実行できるか、そして待機、調整、またはスキーマの決定がどこで発生するかを尋ねます。この比較は、生は悪であり、キュレーションは良いとは限らず、安価なストレージ対高価なストレージでもありません。管理されたレイクは高品質なテーブル製品を含む場合があり、ウェアハウスは半構造化データを保持することがあります。製品ラベルは重なり合うため、アーキテクチャは実際の契約を通じて評価されるべきです。その境界を見えるように保つことは、アーキテクチャ図が他のレイヤーに属するコンポーネントに対して保証を割り当てるのを防ぎます。

2つのアーキテクチャがデータを処理する方法

同じソースは両方のシステムを通過することができます。レイクは証拠と代替表現を保持しますが、ウェアハウスは再発分析のための制御されたビューを公開します。

出所データを取得し、その起源、所有権、感度、収集文脈を持つ。
管理されたレイクゾーンに不変またはバージョン管理されたオブジェクトを配置し、カタログに登録します。
タイプ、キー、およびパーティションを標準化する前に、構造、品質、および目的を検証します。
承認されたレコードをウェアハウスの事実、次元、またはセマンティックモデルに変換し、一致テストを行います。
管理されたレイク製品から探索を提供し、サポートされたウェアハウス契約から繰り返し可能な報告を提供します。

いくつかのプラットフォームは、ウェアハウススタイルのエンジンでレイクファイルを直接クエリし、テーブルフォーマットがオブジェクトストレージ上にトランザクションメタデータを追加します。これらの機能は運用ギャップを狭めますが、チームは依然としてどの資産が探索の証拠で、どれがサポートされたビジネス契約を持つのかを決定する必要があります。この動作は、データレイクハウスアーキテクチャに関する研究でより完全に文書化されています。ソースは、あいまいなアナロジーに依存するのではなく、実際の実行またはデータモデルを説明するために役立ちます。

データレイクとデータウェアハウス比較

次元	データレイク	データウェアハウス
主要契約	柔軟な保持データ	キュレーションされた分析データ
一般的なフォーマット	ファイル、オブジェクト、オープンテーブルフォーマット	管理されたテーブル、ビュー、セマンティックモデル
スキーマのタイミング	使用近くでしばしば解釈または進化される	サポートされた消費の前に施行される
典型的なユーザー	データエンジニア、科学者、高度なアナリスト	アナリスト、BIユーザー、ビジネスチーム
キーリスク	発見できないまたは管理されていない資産	硬直したまたは一貫性のないビジネスモデル
最良の証拠	出所および再現可能なソースバージョン	調整とメトリック契約

これは絶対的な製品制限ではなく傾向です。湖はキュレーションされたテーブルを公開でき、倉庫は外部オブジェクトストレージをクエリできます。意思決定はワークロード、ガバナンス、相互運用性、レイテンシ、消費者サポートのニーズに従うべきです。

各システムに適したワークロード

探索とモデル準備

湖は最終的な分析質問がわかる前に新しいまたは高次元の入力を保持します。

エグゼクティブおよび運用レポート

倉庫は安定したメトリック、次元、リフレッシュの期待、アクセスパターンを提供します。

証拠とメトリック

湖は元の観察を保持し、倉庫はそれらから導出された調整された指標を公開します。

マルチエンジンデータ製品

管理された湖のテーブルは複数の計算エンジンにサービスを提供でき、倉庫モデルは標準化されたビジネス消費をサポートします。

これらのユースケースは選択ルールを共有します：実行と所有権モデルがワークロードに合致するため、データレイクとデータウェアハウスを選び、名前がより先進的に聞こえるからではありません。小規模なチームは、企業のダイアグラムを模倣するためだけに2つのプラットフォームを構築することを避けるべきです。1つの管理された分析データベースで十分かもしれませんが、ソースの多様性、再処理、またはマルチエンジンアクセスが実証されたニーズを生み出すまでです。

1つ、両方、またはハイブリッドの選択

決定は消費者と変化から始まります。スキーマがどれだけ頻繁に変わるか、どれだけの生の証拠を保持しなければならないか、どのワークロードが予測可能なパフォーマンスを必要とするか、共有メトリックがサポートされたセマンティックレイヤーを必要とするかを探ります。

消費者契約を選択します。 探索的ユーザーとダッシュボードユーザーは、同じソースを読む場合でも異なる保証が必要です。
キュレーションを通じて出所を保持します。 倉庫の値は湖のオブジェクトまたは他の管理されたソースバッチに遡るべきです。
重複する真実を避ける。 メトリックまたはソースバージョンが2つの制御されていないコピー間で漂流しないように所有権を割り当てます。
価値がある場合はオープンインターフェースを使用します。 ポータブルファイルとテーブルフォーマットはエンジンのロックインを減らしますが、依然として運用の規律が必要です。
モデルライフサイクルコスト。 ストレージ価格だけでなく、カタログ、変換、テスト、圧縮、クエリ容量、サポート、削除を含めます。

ハイブリッドまたはレイクハウスデザインは、テーブル管理と分析実行をオブジェクトストレージに近づけることができます。それは、所有権、契約、またはセマンティックガバナンスを延期する方法としてではなく、具体的な相互運用性とワークロードの理由で選択されるべきです。関連する主要なリファレンスは、 Apache Icebergテーブルフォーマットのドキュメントであり、これによりその選択の背後にあるストレージ、実行、または相互運用性の仮定が明確になります。

偽のトレードオフとアーキテクチャトラップ

アーキテクチャの議論は、チームが責任ではなく製品名を比較する場合に生産的でなくなります。同じプラットフォームが一つのデータセットに対して湖のように振る舞い、別のデータセットに対して倉庫のように振る舞うことがあります。

生のデータをスキーマなしと同等する。 すべてのファイルには物理的構造があり、すべてのクエリは文書化されたものであれ隠されたものであれ仮定が適用されます。
キュレーションを柔軟性がないと同等する。 よく設計された倉庫モデルは、バージョン管理された契約と制御された歴史ルールを通じて進化できます。
所有権なしで両方を構築。 重複するパイプラインは矛盾する鮮度、キー、およびメトリックを作成します。
消費者のスキルとツールを無視する。 柔軟なプラットフォームは、対象のオーディエンスが安全に発見またはクエリできない場合には失敗することがあります。
ストレージ価格のみを比較する。 変換、品質、計算、サポート、およびガバナンスは、しばしばライフサイクルコストを支配します。

失敗は責任の最小の層に追跡されるべきです。消費者間で意見の不一致がある場合は、湖や倉庫のカテゴリを責めるのではなく、正確なソースバージョン、変換、契約、鮮度、メトリックの所有者を特定します。この実践は、あいまいな指示ではなく、有用な是正措置を生み出します。

公的ウェブデータを湖と倉庫にルーティング

公的ウェブデータは、両方のレイヤーがなぜ有用であるかを示しています。レンダリングされたソースコンテンツは、監査およびパーサーの変更のために保存が必要になることがありますが、アナリストは製品、日付、地域、またはキャンペーンに結び付けられた型付き観察が必要です。

パブリックウェブ入力の場合、取得レイヤーは要求されたURL、最終URL、収集時間、応答モード、および下流処理が開始される前のコンテンツチェックを記録する必要があります。レイクマニフェストはソースと収集の証拠を保持でき、ウェアハウスのロードは正規化されたキーと指標を公開する際にそのマニフェストを参照できます。このハンドオフは、アナリストに再現可能なソース記録を提供し、収集の行動を解釈とは別に保ちます。

Scrapelessは、冒頭の文で説明された管理されたウェブ収集ステップを処理します。アプリケーションは、ソース承認、フィールド定義、ワークロードの制約、保持、アクセス制御、検証を引き続き所有します。Scrapelessは承認されたパブリックページの取得を処理し、データプラットフォームはルーティング、カタログ作成、変換、品質、意味論的意味、権限、および保持を所有します。これらのレイヤー間の明確な契約により、後の変更をテストしやすくなります。

パイプラインは、使用ケースが監査可能性を必要とする場合、未加工の証拠とキュレーションされた出力の両方を保持する必要があります。未加工の素材は、パーサーやスキーマの変更後の再処理をサポートし、キュレーションされたテーブルは安定した分析をサポートします。代表表示間で1つの系譜チェーンを保ち、修正されたパーサーが適切に保存されたソースバージョンからウェアハウスの事実を再構築できるようにします。2つの表現は異なる運用上の質問に回答し、重複していると誤解されるべきではありません。

選択チェックリスト

設計レビュー中に以下の質問を使用してください。書面による回答は、データレイクとデータウェアハウスについてチームが異なる点を明らかにするため、推定されるデフォルトよりも価値があります。

消費者は未加工の証拠、キュレーションされた指標、またはその両方が必要ですか？
ソースフォーマットと将来の分析質問はどの程度予測不可能ですか？
どの資産が予測可能な対話型クエリの動作を必要としますか？
系譜、カタログ、および所有権はどこに記録されていますか？
どのプラットフォームが共有メトリックの意味を定義しますか？
オープンフォーマットは真実を重複させることなく、相互運用性を改善できますか？
取り込み、計算、テスト、サポート、および削除にかかるライフサイクルコストは何ですか？
チームは、説明責任を弱めることなく2つのシステムを運用できますか？

選択肢は、各データセットに特定の所有者が1人、1つの系譜パス、明確な消費者契約、およびカテゴリファッションではなくワークロードに基づいた正当な場所がある場合、健全です。ワークロードの形状、データボリューム、サービス制限、または消費者の期待が変わった後に回答を再検討してください。探索的バッチに合ったアーキテクチャが、連続生産経路には適さない場合があります。

結論

データレイクとデータウェアハウスは異なる消費者契約を強調します。レイクは多様な証拠を保持し、柔軟な処理をサポートし、ウェアハウスは管理された分析構造と共有メトリックを公開します。多くの組織が両方を使用していますが、組み合わせは系譜、所有権、および品質が境界を越えている場合にのみ成功します。ワークロードと消費者の約束から始め、それらを信頼性高く満たすことができる最小のアーキテクチャを選択してください。

ウェブデータを適切なプラットフォームにルーティングする準備はできましたか？

承認されたパブリックウェブの証拠を一度収集し、系譜を保持し、各表現をその消費者に必要な契約の下で公開します。

今すぐサインアップして、 $5の無料クレジットを受け取ります — クレジットカードは不要.

あなたの$5のクレジットを取得 →

よくある質問

データレイクはデータウェアハウスよりも安いですか？

未加工のオブジェクトストレージは保存されたバイトあたりのコストが低くなる場合がありますが、総コストには取り込み、カタログ、変換、圧縮、クエリ計算、品質作業、セキュリティ、サポート、および削除が含まれます。ウェアハウスは小規模で予測可能なレポートワークロードの場合、より安価である可能性があります。ストレージ価格だけでなく、実際のワークロードの下でライフサイクルコストを比較してください。

読み取り時のスキーマはデータレイクにスキーマがないことを意味しますか？

いいえ。ファイルには物理構造があり、カタログはスキーマを記録することがあり、すべての消費者がフィールドとタイプを解釈します。読み取り時のスキーマは、消費者が使用に近い論理的形状を適用または進化させることができることを意味します。良好なレイクガバナンスは、これらの仮定を可視化し、テストを行います。

企業はデータレイクとデータウェアハウスの両方を使用できますか？

はい。一般的な設計は、管理されたソースオブジェクトと柔軟な製品をレイクに保持し、調整された事実と次元を報告のためにウェアハウスにロードします。境界は系譜を保持し、同じメトリックや現在のソースバージョンの2つの競合する定義を避ける必要があります。

データレイクハウスとは何ですか？

データレイクハウスは、オブジェクトストレージのオープンさと、スナップショット、スキーマの進化、最適化されたクエリ実行などのウェアハウスに関連するテーブル管理および分析機能を組み合わせたものです。この用語は、いくつかの実装をカバーします。カタログ、所有権、品質契約、意味論的定義、セキュリティ、またはワークロード計画の必要性を排除するものではありません。

パブリックウェブデータはどこに保存すべきですか？

取得した表現を、出所、保持、および再処理が管理できる場所に保存し、分析契約が施行される場所に型付けされた消費者フィールドを公開してください。これは、レイクとウェアハウスの組み合わせ、管理されたレイクテーブル、または1つのウェアハウスのスタンバイパスを意味する場合があります。目的と消費者の約束が決定すべきです。