メインコンテンツまでスキップ
に最終更新

フェーズ6： Delta Lake建築設計

このフェーズでは、レイクハウスのDelta Lakeストレージ アーキテクチャとデータ編成パターンを設計します。

デザイン メダリオンアーキテクチャ​

メダリオンアーキテクチャは、データを階層化することで、パイプラインを通過する際のデータ品質を向上させます。このパターンは、適切に構造化されたレイクハウスを構築するための基本です。

最も単純な形式では、メダリオン アーキテクチャは、ブロンズ レイヤー (生データ)、シルバー レイヤー (洗練されたデータ)、およびゴールド レイヤー (ビジネス対応データ) の 3 つのレイヤーで構成されます。

ブロンズレイヤー (生データ)​

ソースデータをレイクハウスの第1層に取り込み、そこに永続化します。すべてのダウンストリーム データがブロンズ レイヤーから作成されると、必要に応じてこのレイヤーから後続のレイヤーを再構築できます。

ブロンズレイヤーの特徴

  • 真実のソース : ソース システムから届いたそのままの生データ。
  • 最小限の変換 ：データは元の形式で保存される（または監査可能性のためにDeltaに変換される）。
  • 不変 ：データは追記専用であり、更新または削除されることはありません。
  • スキーマ・オン・リード ：多様なソースシステムに対応した柔軟なスキーマ処理。
  • 監査証跡 ：一部のアプリケーション（ GDPRや規制対象データなど）では、このレイヤーをDelta形式に変換することが適切な場合があります。

ブロンズレイヤーのベストプラクティス

  • 完全な監査可能性を確保するため、すべてのソースデータフィールドを保存してください。
  • 生のファイルを格納するには、 Unity Catalogボリュームを使用してください。
  • 全面的な再処理を避けるため、段階的なデータ取り込みを実装してください。
  • 効率的なデータ管理のために、取り込み日ごとにパーティション化します。
  • データソースとデータ取り込みスケジュールを文書化する。

シルバーレイヤー（リファインデータ）​

第2層の目的は、クレンジング、精製、フィルタリング、および集約されたデータを保持することです。

シルバーレイヤーの特徴

  • データ品質 ：重複データの削除、欠損値の処理、スキーマの強制。
  • データ拡充 ：複数のソースからのデータを結合して、統合データセットを作成します。
  • 標準化 ：一貫したデータ型、フォーマット、および命名規則を適用する。
  • ビジネスルール ：検証ルールとビジネスロジックを実装します。
  • アナリティクスに役立ちます : レポート、ダッシュボード、機械学習の基盤。

シルバーレイヤーのベストプラクティス

  • データ品質チェックとモニタリングを実施する。
  • シルバーレイヤーデータにはUnity Catalogマネージドテーブルを使用します。
  • ビジネスディメンション（例：日付、地域、製品）で分割します。
  • 文書変換ロジックとビジネスルール。
  • データの鮮度に関するSLA（サービスレベル契約）を確立する。

ゴールドレイヤー（ビジネスですぐに使えるデータ）​

第3層は、ビジネスやプロジェクトのニーズに基づいて構築されます。これは、他の事業部門やプロジェクトに対してデータ製品として異なる視点を提供し、セキュリティ要件（例えば、匿名化データ）に合わせてデータを準備したり、パフォーマンスを最適化したり（例えば、事前集計されたビュー）します。

ゴールドレイヤーの特徴

  • ビジネス特化型 ：特定のユースケースや顧客に合わせてカスタマイズされています。
  • パフォーマンス最適化済み ：高速クエリのために事前集計および非正規化されています。
  • アクセス制御 ：行レベルのセキュリティと列マスキングを実装します。
  • 消費者向け ：BIツール、アプリケーション、機械学習モデル向けに構造化されています。
  • データ製品 ：組織全体で再利用可能なデータセットとして公開されます。

ゴールドレイヤーのベストプラクティス

  • 異なる事業部門またはユースケースごとに、個別のゴールドテーブルを作成する。
  • 行レベルおよび列レベルのセキュリティには、動的ビューを使用します。
  • 頻繁にクエリされるテーブルには予測的最適化を実装します。
  • ドキュメントデータをブロンズからゴールドにリネージします。
  • 明確な所有権のもと、Unity Catalogを通じてデータ製品を公開します。

着陸地点の検討​

大規模な組織のパイプラインには、クラウド上に追加のランディング ゾーンがあることがよくあります。 ランディング ゾーンは、ブロンズ レイヤーに取り込まれる前に、外部システムから生のファイルを受信します。

着陸地点パターン

  • クラウドオブジェクトストレージ ：ファイルドロップには、S3、ADLS Gen2、またはGCSバケットを使用します。
  • Unity Catalogボリューム ： Unity Catalogガバナンス機能により、POSIXスタイルの安全なファイルアクセスを実現します。
  • 第三者アクセス ：外部システムはランディングゾーンに直接書き込むことができます。
  • 通知トリガー ：イベント通知を使用して、データ取り込みパイプラインをトリガーします。

メダリオン アーキテクチャの包括的なガイダンスについては、 「メダリオン レイクハウス アーキテクチャとは何ですか?」を参照してください。 。

設計データ取り込み戦略​

ブロンズレイヤーへのデータの取り込みは、メダリオンアーキテクチャの最初のステップです。 データソース、データ量、およびレイテンシ要件に基づいて、データ取り込み戦略を設計してください。

摂取方法​

Lakeflowコネクト

LakeFlow Connectは、 Databricksが提供するマネージド データ取り込みサービスで、コードを 1 行も記述することなく、外部ソースからDatabricksにデータを定期的に同期できます。

パートナー向けデータ取り込みツール

Fivetranなどのツールは、 LakeFlow Connectでサポートされていないデータも取り込むことができます。 このような生の非構造化データは、(外部ロケーションではなく) Unity Catalogボリュームに保存する必要があります。

カスタム取り込みパイプライン

複雑な変換要件またはサポートされていないソースの場合は、 LakeFlow Spark宣言型パイプラインまたはノートブックを使用してカスタム取り込みパイプラインを構築します。

摂取パターン​

バッチ取り込み

  • 定期的なデータ読み込みをスケジュール設定します（例：1時間ごと、1日ごと、1週間ごと）。
  • 大量の履歴データに最適です。
  • ストリーミング配信に比べてコストが低い。
  • 分析ワークロードにとって許容可能なレイテンシ。

ストリーミング取り込み

  • 低遅延での継続的なデータ取り込み。
  • ストリーミング ファイルの取り込みには、 Auto LoaderでLakeFlow Spark宣言型パイプラインを使用します。
  • 突然の分析と運用のユースケースに最適です。
  • コンピュートコストは高くなりますが、データは新鮮です。

チェンジデータキャプチャ（CDC）

  • ソースシステムからの段階的な変更をキャプチャして適用する。
  • 更新頻度の高い大規模なテーブルに効率的です。
  • データリネージと監査証跡を保存します。
  • LakeFlow ConnectおよびLakeFlow Spark宣言型パイプラインによってサポートされています。

データ取り込みのベストプラクティス

  • Bronze を取り込む前に生データをランディングするためにUnity Catalogボリュームを使用します。
  • 再試行を安全に処理するために、冪等なデータ取り込みを実装してください。
  • クラウド ストレージから効率的にファイルを取り込むには、 Auto Loader使用します。
  • 着陸ゾーンデータの保持ポリシーを設定します。
  • データ取り込みパイプラインの障害やデータ品質の問題を監視する。

デザインテーブル管理戦略​

テーブルとボリュームは、マネージドボリュームまたは外部ボリュームとして作成できます。トレードオフを理解することで、最適なテーブル戦略を設計することができます。

管理テーブルと外部テーブル​

マネージドテーブルとボリューム

Unity Catalog 、 Databricksからの外部テーブルとボリュームへのアクセスを管理しますが、基になるファイルを制御したり、それらのファイルの保存場所をフルマネージドしたりすることはありません。 一方、マネージドテーブルとボリュームはUnity Catalogによるフルマネージドであり、含まれるスキーマに関連付けられた管理されたストレージの場所に保存されます。

Databricksは、構成、最適化、およびガバナンスを簡素化するため、ほとんどのワークロードに対してマネージドボリュームとマネージドテーブルの使用を推奨しています。予測的最適化やマネージド DR などの新機能はマネージドテーブルでのみ利用可能です。

外部テーブルとボリューム

外部との最大の違いは、マネージドテーブルがschema_name/table_nameの単純なフォルダー構造を提供せず、代わりに内部 GUID スタイルのフォルダーを使用することです。 これらのフォルダには、 Unity Catalog経由でのみアクセスしてください。

外部テーブルを使用するタイミング

  • 規制またはコンプライアンス上の理由から、データは特定のクラウドストレージパスに保持されなければなりません。
  • 外部システムは、データへの直接的なファイルアクセスを必要とする。
  • Delta Sharingを使用できないシステムとのデータ共有。
  • マネージドストレージに移行できない既存データ。

テーブル管理のベストプラクティス

  • すべての新しいレイクハウス データ (ブロンズ、シルバー、ゴールド) にはマネージドテーブルを使用します。
  • ランディングゾーンと未加工の非構造化データには、マネージドボリュームを使用してください。
  • 外部テーブルは、特定のパスに保持する必要のあるデータのみに使用してください。
  • すべてのテーブルに関するドキュメントの所有権とライフサイクルポリシー。
  • 頻繁にクエリされるマネージドテーブルに対して予測的最適化を有効にします。

ハブアンドスポークメダリオンデザイン​

ハブアンドスポーク設計パターンは、エンタープライズ展開においてメダリオンアーキテクチャと組み合わせることができる。このパターンは、共有データ資産を一元化しつつ、ドメイン固有のデータ処理を可能にする。

ハブアンドスポークメダリオンの特徴

  • データハブ ：組織全体の資産（例えば、SAPデータや、天気や財務などの一般的な資産）を取り込み、整理し、管理します。これらは、ソースリンク型データ製品とみなすことができる。
  • データドメイン ：各ドメインは、ハブがキュレーションしたデータ製品の一部を読み込むとともに、ドメイン固有の生データを取り込み、キュレーションします。そして、各ドメインはドメイン固有のデータ製品を生成する。
  • 出版モデル
    • 集中型パブリッシング ：ドメインは、組織全体で利用できるよう、データ製品をハブに公開します。
    • 分散型パブリッシング ：ドメインは、ドメイン固有の用途のために、独自のカタログ内でデータ製品を公開します。

ハブアンドスポーク型メダリオンの例

Data Hub (Central)
├── Bronze: Organization-wide raw data (SAP, financials, weather)
├── Silver: Curated shared datasets
└── Gold: Enterprise-wide data products

Sales Domain
├── Bronze: Sales-specific raw data + shared hub data
├── Silver: Sales analytics datasets
└── Gold: Sales data products (published to hub or domain)

Engineering Domain
├── Bronze: Engineering telemetry + shared hub data
├── Silver: Engineering metrics
└── Gold: Engineering dashboards (published within domain)

ハブアンドスポーク型メダリオンのベストプラクティス

  • 複数のドメインが利用する組織全体の共有データには、ハブを使用してください。
  • 各ドメインが、ドメイン固有のデータを取り込み、管理できるようにする。
  • クリアデータ製品公開ポリシーを確立します (集中型と分散型)。
  • Unity Catalogを使用して、ハブデータとドメインデータを分離します。
  • Databricksが管理するDelta Sharingを使用して、ハブとドメイン間でデータ製品を共有します。

データガバナンス戦略の設計​

データガバナンスは、レイクハウス全体におけるデータの品質、検索性、およびコンプライアンスを保証します。組織の成熟度と要件に適したガバナンス戦略を策定する。

データ品質戦略​

メダリオンアーキテクチャのバリエーションに関わらず、データが各層を通過するにつれて、データ品質は向上しなければならない。その結果、ビジネスの観点から見て、データに対する信頼は必然的に高まるだろう。

データ品質ツール

  • 制約事項 ：テーブルに追加されたデータの品質と整合性が自動的に検証されるようにする。
  • 主キーと外部キー ：テーブル内のフィールド間の関係をエンコードします（情報提供のみを目的としており、強制的なものではありません）。
  • 期待 : データ品質の問題が下流に波及するのを防ぎます (現在はLakeFlow Spark宣言型パイプラインで、間もなくすべてのUnity Catalogテーブルで)。
  • レイクハウスモニタリング : アカウント内のすべてのテーブルのデータの統計的特性と品質を監視します。

データ品質のベストプラクティス

  • ブロンズレベルのデータ取り込み時にデータ品質チェックを実装する（例：スキーマ検証、nullチェック）。
  • データがシルバーやゴールドへと移行するにつれて、より厳格な品質基準を適用する。
  • データ品質メトリクスと長期的な傾向を監視します。
  • 重要なデータセットのデータ品質に関するSLAを定義する。
  • データ品質違反に関するアラートを自動化する。

データサイロを避ける​

データの移動、コピー、複製には時間がかかり、特にデータサイロ化につながる場合は、レイクハウス内のデータの品質を低下させる可能性があります。データコピーとデータサイロの違いを明確にするために、スタンドアロンまたは使い捨てのデータコピー自体は、それ自体では有害ではありません。時には、機敏性、実験性、そして革新性を高めることが必要となる。これらのコピーが、下流のビジネスデータ製品がそれに依存する形で運用されるようになると、それらはデータサイロとなる。これらのサイロはすぐに同期が取れなくなり、最終的には信頼性の低いデータレイクへとつながる。

データサイロを回避するためのベストプラクティス

  • データをコピーする代わりに、 Unity CatalogビューとDelta Sharingを使用してください。
  • データセットごとに単一の真実のソースを確立します。
  • 部門レベルでのデータコピーや重複は避けてください。
  • Unity Catalogリネージを使用してデータ依存関係を追跡します。
  • 不要なデータセットは定期的に削除する。

データカタログとデータ検索​

Unity Catalog使いやすさとデータガバナンスのためにデータ治安とリネージを提供します。

データディスカバリー

あらゆる事業分野のユーザー、特にセルフサービスモデルを採用している企業は、関連データを容易に発見できる必要がある。したがって、レイクハウスにはビジネスに関連するすべてのデータを網羅するデータカタログが必要です。 データカタログの主な目的は以下のとおりです。

  • ユーザーがデータセットを検索・発見できるようにする。
  • データセットのメタデータ、説明、およびドキュメントを提供する。
  • ソースから消費までのデータリネージを表示します。
  • データの品質メトリクスと鮮度情報を表示します。

データリネージ

データリネージを正確に追跡することで、ユーザーがデータが現在の形になった経緯を説明できるようにします。 Unity Catalog 、以下のリネージを自動的にキャプチャします:

  • テーブル間の依存関係。
  • データの読み書きを行うノートブックおよびジョブの実行。
  • 上流のソースシステム。
  • 下流の消費者とデータ製品。

データカタログのベストプラクティス

  • すべてのカタログ、スキーマ、テーブルに説明とタグを追加します。
  • 文書データの所有者および主題専門家。
  • Unity Catalog検索を使用してデータ蓄積を有効にします。
  • メタデータは定期的に確認し、更新してください。
  • 変更を加える前に、リネージを使用してデータ間の依存関係を理解してください。

Delta Lake建築に関する推奨事項​

推奨

  • データレイクの構造化には、メダリオンアーキテクチャ（ブロンズ、シルバー、ゴールド）を使用します。
  • すべてのレイクハウス データ (ブロンズからゴールド) にはUnity Catalogマネージドテーブルを使用します。
  • ランディングゾーンと未加工の非構造化データには、 Unity Catalogボリュームを使用してください。
  • 各階層（ブロンズ、シルバー、ゴールド）でデータ品質チェックを実施する。
  • Unity Catalog使用して、データ蓄積とリネージ追跡を有効にします。
  • 頻繁にクエリされるマネージドテーブルに対して予測的最適化を有効にします。
  • ハブアンドスポーク型アーキテクチャ向けに、明確なデータ製品公開ポリシーを策定する。

避ける

  • 運用データを複数のドメインに重複して保存することで、データサイロを作成しないようにしてください。
  • データが特定のストレージパスに保持される必要がある場合を除き、外部テーブルを使用しないでください。
  • ブロンズレイヤーは省略しないでください（生データは常に真実のソースとして保存してください）。
  • 納期を守るために、データ品質チェックを省略してはいけません。
  • Unity Catalogガバナンスなしに、管理されていないデータの無秩序な拡散を許してはいけません。

第6相の結果​

フェーズ6を完了すると、以下のものが得られます。

  • メダリオンアーキテクチャーデザイン（目的が明確なブロンズ、シルバー、ゴールドレイヤー）。
  • データ取り込み戦略を定義する（要件に基づいて、バッチ処理、ストリーミング処理、またはCDC）。
  • テーブル管理戦略を設計しました（管理対象テーブルと外部テーブル）。
  • ハブアンドスポーク型のメダリオンアーキテクチャを評価（複数ドメイン組織向け）。
  • 各階層で適切なチェックを行うデータ品質戦略を定義する。
  • データガバナンスポリシーを制定（カタログ、リネージ、ディスカバリーなど）。
  • 着陸ゾーンのアーキテクチャ設計（外部システムに必要な場合）。
  • データ製品の公開モデルが定義されています（集中型、分散型、またはハイブリッド型）。

次のフェーズ ：フェーズ7：インフラストラクチャ・アズ・コードのアプローチを計画する

実装ガイド ：Delta Lake 設計を実装するための手順については、 「Databricks における Delta Lake とは？」を参照してください。