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

Scrapeless Web Unlockerは、データチームが検証、保存、そしてガバナンスされたソースデータとしてデータレイクに配置できる公開Webコンテンツを取得します。

TL;DR

データレイクは、限られた前提変換で多様なデータを保存します。 生データ、半構造化データ、構造化データ、およびバイナリオブジェクトは、一つのガバナンスされたストレージ環境を共有できます。
ストレージだけでは湖にはなりません。 カタログ、所有権、アクセスポリシー、品質チェック、およびライフサイクルルールがコンテンツを利用可能にします。
スキーマは、データが読み込まれるときに適用されることがよくあります。 消費者は、探索、機械学習、または下流のキュレーションのために同じソースを形作ることができます。
オープンファイル形式は相互運用性を向上させます。 カラム形式とテーブル形式は、複数のエンジンが共有データ上で作業できるようにし、独自のデータベースの境界を設けません。
湖はキュレーションされたシステムを補完します。 信頼された倉庫テーブルとデータ製品は、すべての分析ストアを置き換えるのではなく、ガバナンスされた湖のゾーンから構築できます。

データレイクの定義

データレイクは、大量のデータをそのソース表現に近い形で保持するためのレポジトリと管理パターンです。一般的には耐久性のあるオブジェクトまたはファイルストレージを使用し、構造化されたテーブル、JSON、ログ、文書、メディア、分析用ファイル形式を受け入れます。すべての下流使用が決定される前に。

湖は、複数のコンピュートエンジンからストレージを分離します。クエリエンジン、ノートブック、変換ジョブ、または機械学習ワークフローは、カタログを通して承認されたオブジェクトを読み、必要なスキーマをそのタスクに適用できます。この柔軟性は、データのアイデンティティとポリシーがインジェスト中に生き残る場合にのみ有用です。ここで使用される主要な用語は Microsoftデータレイクアーキテクチャガイダンス, つまりこの概念に具体的な技術的境界を与え、マーケティングラベルとして扱われることはありません。

有用な定義は、概念が何を行わないかも述べます。データレイクは、無名のバケツでも、すべてのデータベースの置き換えでもなく、すべての収集物を無期限に保持する許可でもありません。また、キュレーション、インデックス作成、テーブルメタデータ、およびワークロード特有のコンピュートなしにデータの低遅延ビジネスレポートを保証するものでもありません。その境界を明確に保つことで、アーキテクチャダイアグラムが別のレイヤーに属するコンポーネントに保証を割り当てることを防ぎます。

データが湖を通って移動する方法

有用な湖の設計は、インジェストをソース証拠から発見可能な資産への制御された移行として扱います。各段階は、元の文脈を消すことなく、メタデータや品質を追加します。

プロデューサーは、起源、収集時間、所有者、分類メタデータを持つ不変のソースオブジェクトを書き込みます。
検証は、形式、期待されるフィールド、アクセス範囲、およびオブジェクトが意図されたソースを表すかどうかを確認します。
カタログは場所、スキーマ観察、パーティション、系譜、品質ステータス、およびデータに責任を持つ人を記録します。
変換ジョブは、ソースオブジェクトへのリンクを維持しながら、標準化されたまたはキュレーションされたデータセットを作成します。
消費者は、探索、報告、モデル、またはエクスポートに適したエンジンと権限を介して承認されたゾーンをクエリします。

オブジェクトストレージはバイトを保持し、ファイル形式はレコードを整理し、テーブルメタデータは論理データセットを追跡し、カタログは資産を発見可能にし、コンピュートエンジンは作業を実行します。それらの役割を分離することで、チームはすべてのソースオブジェクトを書き換えることなくクエリエンジンを変更できます。この動作については、 Apache Parquetドキュメントでより完全に文書化されています。ソースは、緩やかな類推に依存するのではなく、実際の実行またはデータモデルを説明するため有用です。

コアデータレイクレイヤー

レイヤー	主要なジョブ	保持すべき証拠
ソースゾーン	受信データを保持する	起源、時間、チェックサム、収集コンテキスト
検証済みゾーン	不正確または予期しない入力を拒否する	検証結果とスキーマ観察
標準化されたゾーン	名前、型、およびパーティションを正規化する	変換バージョンと系譜
キュレーションされたゾーン	定義されたビジネスやモデルの利用を提供する	所有者、契約、品質目標
アーカイブまたは削除	保持および法的ポリシーの適用	廃棄理由および承認

ゾーン名は異なるが、状態遷移は明示的であるべきである。品質や所有権の変更なしに新しいプレフィックスにファイルをコピーすることは、ガバナンスではなく視覚的な組織を生み出す。各ゾーンは、消費者に安全な仮定を伝えるべきである。

一般的なデータレイクのワークロード

探索的分析

分析者は安定したウェアハウスモデルまたは製品契約にコミットする前に、新しいソースを検査できる。

機械学習の準備

チームは再現可能な変換系を持つ高次元、半構造化、バイナリ入力を保持できる。

長期的なソース保持

不変の証拠は、パーサー、スキーマ、またはビジネスの質問が変わったときに再処理をサポートする。

マルチエンジン分析

SQLエンジン、ノートブック、バッチジョブ、およびストリームプロセッサーは、共有されたガバナンスフォーマットで動作できる。

これらのユースケースは選択ルールを共有する：ワークロードに対して実行および所有モデルが一致するため、名称が高度に聞こえるからではなくデータレイクを選択する。ワークロードが小さく、非常にトランザクションが多い、またはすでにキュレーションされた分析データベースに適合する予測可能なダッシュボードに支配される場合、湖は魅力が減少する。アーキテクチャの柔軟性には運用コストがある。

ゾーン、カタログ、およびガバナンス

ガバナンスは取り込みの時点で始まる。プロデューサーは、最初の大きなバッチが到着する前に、ソース、目的、所有者、感度、保持、期待されるスキーマ、および品質チェックを特定するべきである。

不変のソースオブジェクトを好む。 新しいバージョンは証拠を保持し、歴史を静かに変えずに変換を再現可能にする。
オープンで型付けされたフォーマットを使用。 ポータブル列指向ファイルはスキャン作業を削減し、分析エンジン間の相互運用性を向上させる。
すべてのガバナンスされた資産をカタログ化。 発見、系譜、所有権、およびアクセスポリシーは部族知識やパス名に依存するべきではない。
ゾーンごとに許可を分ける。 生の敏感な入力とキュレーションされた消費者テーブルは、同じオーディエンスを必要とすることはめったにない。
小さなファイルの管理のための予算を考える。 コンパクションとパーティションポリシーは、メタデータのオーバーヘッドがクエリ作業を支配するのを防ぐ。

テーブルフォーマットは、スナップショット、スキーマの進化、パーティションメタデータ、およびオブジェクトストレージに対するトランザクショナルコーディネーションを追加することができる。それはソース契約やアクセスガバナンスの必要性を排除するわけではなく、いくつかのストレージレベルの変更をより安全に、より簡単にクエリできるようにする。関連する主な参照は、 Apache Icebergドキュメント, それはその選択の背後にあるストレージ、実行、または相互運用性の仮定を明確にする。

データレイクがデータスワンプになる理由

データスワンプは、ストレージが理解よりも早く成長する時に形成される。警告サインは、所有権の欠如、重複したソース、不明確なスキーマ、広範な権限、無制限の保持、および消費者が同じクリーンアップロジックを再構築していることである。

パスのみの組織。 フォルダは意味、系譜、所有権を記録するカタログに取って代わることはできない。
スキーマフリーの思考。 すべての消費者は仮定を適用する; 文書化されていない仮定は、スキーマ作業を下流に移すだけである。
アイデンティティなしのコピー。 ソースキーやバージョンルールなしの重複ファイルは、一貫性のない分析結果を生み出す。
一つの許可境界。 すべての消費者に生のゾーンとキュレーションされたゾーンへのアクセスを許可すると、リスクが拡大し、目的の制限が弱まる。
デフォルトで保持する。 ライフサイクルルールのないデータは、コスト、法的リスク、および発見の負担を増加させる。

失敗は最小の責任のある層を追跡するべきである。クエリが間違っている場合、消費者の計算を変更する前に、キュレーションされた資産をその変換、カタログエントリ、検証結果、および不変のソースオブジェクトに追跡する。この実践は、より多くのキャパシティを追加するという曖昧な指示の代わりに、有用な是正措置を生み出す。

湖に公的ウェブデータを着陸させる

公的ウェブデータは、HTML、テキスト、JSON、スクリーンショット、または抽出されたフィールドとして到着することが多い。レイクは取得した表現を保持し、後に分析のために正規化されたParquetまたはガバナンステーブルを作成できる、パイプラインがソースのアイデンティティと収集コンテキストを保持する限り。

公的ウェブ入力の場合、取得層は、要求されたURL、最終URL、収集時間、応答モード、およびコンテンツチェックを下流処理が始まる前に記録するべきである。要求されたURLおよび最終URL、コンテンツタイプ、チェックサム、収集時間、および検証結果をオブジェクトのそばまたはリンクされたマニフェストの中に保存する。その受け渡しは、分析者に再現可能なソースレコードを提供し、収集行動を解釈から分離する。

Scrapelessは、冒頭の文で説明された管理されたウェブ収集のステップを処理する。アプリケーションは依然としてソースの承認、フィールド定義、ワークロードの範囲、保持、アクセス制御、および検証を所有している。Scrapelessは要求された取得を実行し、データプラットフォームは承認されたソース、オブジェクトの命名、パーティション、カタログ登録、許可、保持、下流契約を決定する。これらの層間で明確な契約があれば、後の変更がテストしやすくなる。

パイプラインは、ユースケースが監査可能性を必要とする際に、生の証拠とキュレーションされた出力の両方を保持するべきである。生の材料は、パーサーまたはスキーマが変更された後の再処理をサポートし、キュレーションされたテーブルは安定した分析に対応する。目的と保持ポリシーが正当である場合にのみ生の証拠を保持し、次に文書化されたフィールドと品質期待を持ったキュレーションされた製品を公開する。二つの表現は異なる運用上の質問に応え、重複とは見なされるべきではない。

データレイクアーキテクチャチェックリスト

設計レビュー中に以下の質問を使用してください。書面による回答は、仮定されたデフォルトよりも価値があります。チームがデータレイクについて意見が分かれている部分を明らかにするからです。

どのソース表現は不変でなければなりませんか？
各オブジェクトを発見可能かつ再現可能にするために必要なメタデータは何ですか？
どの形式とテーブルの標準は複数のエンジンが共有しなければなりませんか？
スキーマドリフトや互換性のない変更はどのように検出されますか？
すべてのキュレーションされたデータセットを所有し、その消費者を承認するのは誰ですか？
生データとキュレーションデータのアクセス権はどのように異なりますか？
ファイルレイアウトを制御する圧縮およびパーティションルールは何ですか？
データはいつアーカイブまたは削除され、どこでその決定が記録されますか？

レイクは、新しい消費者が資産を発見し、その契約を理解し、系譜を検証し、適切なアクセスを要求し、保存された証拠から変換を再現できるときに準備が整います。作業負荷の形状、データの量、サービス制限、または消費者の期待が変化した後に回答を再検討してください。探索的なバッチにとって合理的であったアーキテクチャが、継続的な生産パスには不適切な場合があります。

結論

データレイクは、柔軟なストレージをカタログ化、ガバナンス、および独立したコンピューティングと組み合わせます。その価値は、様々なソースデータを保存しながら、所有権、品質、系譜、権限、およびライフサイクルを明示することから来ています。オープンフォーマットとテーブルメタデータは相互運用性を向上させますが、それ自体で信頼を生むことはありません。レイクは、すべての資産が証拠から消費者向けデータ製品への文書化された経路を通じて移動できるときに有用になります。

ガバナンスされたウェブデータレイクを構築する準備は整いましたか？

承認された公共ウェブの証拠を収集し、出処を保存し、検証されたオブジェクトをレイクの取り込みパイプラインに渡してください。

今日サインアップして、 $5の無料クレジットを手に入れましょう — クレジットカードは不要です.

$5クレジットを請求する →

FAQ

データレイクの主な目的は何ですか？

データレイクは、すべてのソースを取り込み時に1つのデータウェアハウススキーマに強制することなく、将来のいくつかの使用のために多様なデータを保存します。それは、探索、機械学習の準備、長期的な証拠、および複数エンジン分析をサポートします。その柔軟性は、カタログ、所有権、アクセス制御、品質チェック、および保持ポリシーに依存します。

データレイクは常にクラウドに保存されますか？

いいえ。データレイクは、クラウドオブジェクトストレージ、分散ファイルシステム、またはその他の耐久性のあるストレージ環境を使用できます。クラウドオブジェクトストアは、ストレージをコンピューティングから分離し、運用上スケールするため一般的ですが、定義的な特徴は、保持された柔軟なデータにガバナンスと分析のアクセスが加わることであり、特定のデプロイメント場所ではありません。

リード時のスキーマとは何ですか？

リード時のスキーマとは、消費者がデータをクエリしたときに構造を適用または解釈することを意味し、ソースが保存される前に最終的な分析スキーマを要求しません。ソースには依然として物理的な形式と観察されたフィールドがあります。良いレイクプラットフォームは、それらの事実を記録し、スキーマが存在しないふりをするのではなく、それを検証します。

データレイクがデータスワンプになるのはなぜですか？

レイクは、ユーザーがその内容を発見できず、信頼できず、理解できず、安全にアクセスできないときにスワンプになります。所有権の欠如、弱い系譜、重複するソース、文書化されていないスキーマ、広範な権限、および無期限の保持が一般的な原因です。ストレージをもっと追加したり、新しいクエリエンジンを導入しても、それらのガバナンスのギャップは修復されません。

公共ウェブデータはデータレイクに入ることができますか？

はい、組織に承認された目的があり、適用可能なアクセス、プライバシー、著作権、契約、および保持要件に従う場合です。取り込みマニフェストは、ソースURL、コレクションコンテキスト、検証ステータス、および所有権を保持する必要があります。キュレーションされた出力は、ガバナンスされたソースオブジェクトへの系譜を維持する必要があります。