実践的なデータレイクハウスの事例とユースケース

データレイクハウスの事例を探しているエンジニア、アーキテクト、データサイエンティストは、しばしば同じ課題に直面します。それは、理論的な定義はたくさんあっても、自社の環境にマッピングできる具体的なパターンがほとんどないということです。この記事では、ストリーミング分析、IoTパイプライン、機械学習ワークフロー、エンタープライズレポートにわたる実世界のシナリオを紹介し、それぞれを実務でデータレイクハウスを機能させるアーキテクチャ上の意思決定に結び付けることで、そのギャップを埋めます。

これらのパターンは、組織が実際にこれらのシステムをどのようにデプロイしているかに基づいた出発点を提供します。

モダンデータアーキテクチャとレイクハウスの概要

データレイクハウスは、データレイクの低コストなオブジェクトストレージとスキーマの柔軟性に、データウェアハウスのデータ品質保証、ACIDトランザクション、クエリパフォーマンスを組み合わせた、オープンで統合されたデータストレージシステムです。個別のシステム間でデータを移動させる必要はありません。

データエンジニアは、ウェアハウスとレイクに同時にデータを供給する並行パイプラインを維持する必要がなくなります。データサイエンティストはオープンフォーマットの生データや処理済みデータに直接アクセスでき、アナリストは機械学習モデルを動かすのと同じテーブルに対してSQLクエリを実行できます。

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

データレイクハウスの事例を理解するには、それが何を置き換えるのか、そしてなぜ従来のデータウェアハウスや単なるデータレイクだけでは課題を完全に解決できないのかを理解する必要があります。

データウェアハウス

従来のデータウェアハウスは、書き込み時にスキーマを適用し、構造化データを列指向フォーマットで保存し、BI向けに高速なSQLクエリパフォーマンスを提供します。しかし、データ量が増加したり、ドキュメント、画像、ログファイルなどの非構造化データを分析する必要が生じたりすると、限界が見えてきます。独自のフォーマットはベンダーロックインを引き起こし、統合されたプラットフォームがないため、組織はしばしば個別のシステム間で冗長なデータのコピーを維持することになります。

データレイク

データレイクは、クラウドオブジェクトストレージにあらゆるデータフォーマットを安価に保存しますが、ガバナンスが常に課題となります。スキーマの適用がないため、データ品質が低下します。ACIDトランザクションがないと、同時書き込みによってファイルが破損し、不整合が生じます。パイプラインジョブが失敗すると、部分的な書き込みが残り、最初からやり直すためのコストのかかる再処理が必要になります。

「データスワンプ（データの沼）」という言葉は、下流の分析で利用しやすく信頼できる状態を維持するために必要なメタデータレイヤーやリネージ追跡がないまま、レイクが肥大化した場合に起こる状況を表しています。また、独自の取り込みツールによってオープンフォーマットの柔軟性が失われ、特定のクラウドエコシステムに縛られることで、組織はベンダーロックインのリスクにも直面します。

データレイクハウス

データレイクハウスは、多様なデータタイプのサポートと、スキーマ適用、ACIDトランザクション保証、データバージョン管理、リネージ追跡といったウェアハウスレベルのデータ管理を組み合わせたものです。Delta LakeやApache Icebergなどのオープンテーブルフォーマットがクラウドオブジェクトストレージの上のメタデータレイヤーとして機能し、生のデータレイクにはないトランザクション保証を提供します。これにより、データチームは重複させることなく、同じストレージからSQL分析と機械学習ワークフローの両方に対応できます。

ユースケース：生データ、多様なデータタイプ、高度な分析

データレイクハウスを導入する最大の理由は、統合アーキテクチャによって、本来であれば複数の個別システムを必要とする複雑さを排除できる特定のユースケースにあります。

ストリーミング分析

Eコマースプラットフォームでは、購入から数秒以内に不正な取引を検出する必要があります。

パイプラインはイベントストリームをレイクハウステーブルに取り込み、同じアーキテクチャ内に保存されている顧客プロフィールデータを使用してリアルタイムでエンリッチメントを適用し、低レイテンシのサービングレイヤーに不正スコアをマテリアライズ（実体化）します。

レイクハウスは同じオープンフォーマットでバッチ処理とストリーミングの両方の取り込みをサポートしているため、不正検出モデルはデータを重複させたり個別のシステムを管理したりすることなく、履歴データでトレーニングを行い、ライブイベントをスコアリングできます。

バッチ履歴分析

ある小売チェーンは、レガシーウェアハウスからの5年分の売上データ、買収したブランドからのフラットファイル、および在庫システムのデータを、メダリオンアーキテクチャパターンに従ってレイクハウスに統合します。

Bronzeテーブルは取り込まれたままの生データを保存し、Silverテーブルはクレンジングとスキーマの標準化を適用し、Goldテーブルは売上データを大規模に分析するために必要なメトリクスに集計します。各レイヤーは個別にクエリ可能であるため、データチームは個別のデータストアを作成したり、異なるワークロードのためにシステム間でデータを移動したりすることなく、柔軟に対応できます。

IoTとセンサーデータのパイプライン

ある製造企業は、ハードウェアの世代によって異なる半構造化フォーマットで、温度、振動、圧力などの高頻度のセンサー測定値を収集しています。レイクハウスは生データをオブジェクトストレージに取り込み、ストリーミングパイプラインジョブを通じて正規化し、下流の異常検出モデルに供給します。

構造化データと非構造化データが同じアーキテクチャ内に共存するため、エンジニアはデータを移動させることなく、センサーのテレメトリをメンテナンスログや品質レポートと結合できます。これにより、断片化された個別のシステムでは実用的ではない規模での予兆保全が可能になります。

カスタマー360と統合プロフィール

ある金融サービス企業は、事業部門ごとのデータストアを、すべてのチームが同じ基盤となるレイクハウステーブルから読み取る統合アーキテクチャに置き換えています。データガバナンスポリシーによって役割ごとに機密フィールドがマスクされ、リネージ追跡によって各顧客属性がどのように導出されたかが正確に示されます。その結果、手動での照合を必要とせず、常に最新であり、社内および規制当局の監査に対応する単一の監査証跡を備えた、規制基準を満たすカスタマー360プロフィールが実現します。

レイクとデータ管理のためのデータアーキテクチャパターン

具体的なデータレイクハウスの事例には、チームがコンセプトから実装へと移行するのに役立つ、一連の共通するアーキテクチャパターンが存在します。

ストレージと生データレイヤー

すべてのレイクハウスの基盤はクラウドオブジェクトストレージです。生データは、変換が行われる前に元のフォーマットのまま最初にここに格納されます。これにより、監査、モデルの再トレーニング、データ品質問題のデバッグのための完全な再現性が維持されます。日付、地域、製品カテゴリなど、頻繁にフィルタリングされるフィールドでパーティショニングを行うことで、大規模なデータセットのスキャンに必要なコンピューティングリソースを大幅に削減できます。パーティショニングが不適切であったり存在しなかったりすると、フルテーブルスキャンが強制され、低コストなオブジェクトストレージのコストメリットが損なわれます。

データ管理のためのメタデータとカタログ

中央集権的なメタデータカタログは、ガバナンスの効いたレイクハウスとデータスワンプを区別するものです。すべてのテーブル、列、データセットは、説明、所有権、分類タグ、アクセスポリシーとともに登録される必要があります。これにより、大規模なデータ管理が可能になります。データアナリストは信頼できるデータセットを自律的に発見でき、データサイエンティストはモデルのトレーニングで使用する特徴量のリネージを理解できます。規制の厳しい業界において、リネージ追跡はオプション機能ではなく、コンプライアンス上の必須要件です。

コンピューティング、クエリエンジン、高度な分析

ストレージとコンピューティングを分離することで、レイクハウスにスケーラビリティがもたらされます。ストレージはより多くのデータを収容するために独立してスケールします。コンピューティングは、アイドル状態の容量にコストを支払うことなく、大規模な分析ワークロードを実行するために独立してスケールします。成熟したレイクハウスは、同じオープンデータフォーマットに対して複数のクエリエンジンをサポートしているため、SQL分析チームと機械学習のトレーニングジョブが競合することなく同時に実行できます。データサイエンティストはテーブルに直接クエリを実行し、基盤となるデータの冗長なコピーを作成することなく、仮説の検証を繰り返すことができます。

データサイエンティスト向けのデータ探索とセルフサービス

ロールベースのアクセス制御を備えたレイクハウスにより、安全なセルフサービス型の探索が可能になります。データサイエンティストは、データエンジニアがカスタム抽出データを用意するのを待つことなく、生データや処理済みデータにアクセスできます。サンドボックス環境を使用すれば、本番データセットから分岐して、稼働中のパイプラインに影響を与えることなく仮説をテストできます。タイムトラベル機能（過去の特定の時点に存在していた状態のテーブルにクエリを実行する機能）により、過去の実験を正確に再現することが可能になり、データライフサイクル全体にわたってデータの整合性が保証されます。

機械学習とデータサイエンティストのワークフロー

レイクハウステーブル上でのML特徴量ストアの構築

特徴量エンジニアリングは、機械学習ワークフローにおいて最も時間のかかるステップの1つです。レイクハウスは、設計された特徴量を分析チームがレポート作成に使用するのと同じオープンフォーマットのテーブルに保存することで、このプロセスを簡素化し、データサイエンティストがモデル間で特徴量を登録、共有、再利用できるようにします。

これにより、冗長な計算が排除され、トレーニング環境とサービング環境の間で一貫性が確保されるため、データ探索から本番モデルのデプロイまでの時間が短縮されます。

タイムトラベルによる再現可能な実験

実験の間に基盤となるトレーニングデータが変更されてしまうと、結果を比較することはできません。レイクハウスのタイムトラベル機能は、各トレーニングジョブを特定のデータスナップショットに固定するため、すべての実験がトレーニング時の正確なバージョンのデータを参照します。これにより、MLOpsワークフロー全体が監査可能かつ再現可能になり、チームは反復間でモデルのパフォーマンスが変化した理由を正確に特定できます。これは、デバッグや規制上の監査証跡にとって極めて重要です。

レイクハウスデータからのモデルサービング

レイクハウスのテーブルでトレーニングされたモデルは、バッチサービングにおいて同じテーブルに対してスコアリングを行い、オンラインサービングレイヤーは同じ基盤データから派生したマテリアライズドビューから読み取ります。これにより、従来のアーキテクチャでコストを増大させ、データの鮮度の不整合を引き起こしていた、トレーニング用とサービング用でインフラが分かれる「デュアルスタック問題」が解消されます。その結果、データの重複を必要とせず、モデル開発から本番環境への移行パスがよりシンプルになり、メンテナンス性も向上します。

モダンなデータレイクハウスのデプロイにおけるベストプラクティス

スキーマ強制とスキーマ進化のサポートの採用

スキーマ強制は、インジェスト（取り込み）時に不正なデータがレイクハウスに入り込むのを防ぎます。スキーマ進化により、ダウンストリームのコンシューマー（後続の処理）を壊すことなく、時間の経過とともにテーブル定義を変更できます。これら両方の機能は、初日から設定しておく必要があります。ガバナンスのないレイクに後から強制機能を組み込むのは、最初に実装するよりもはるかにコストがかかり、完全に修復するのが困難なデータ品質の問題を引き起こします。

カタログでのロールベースのアクセス制御の強制

アクセス制御は、インフラレベルではなく、カタログレベルで定義する必要があります。テーブルや列に紐付けられたロールベースのポリシーは、ストレージバケットレベルで管理されるアクセス制御リストよりも、監査や変更が容易で、設定の乖離（ドリフト）が発生しにくくなります。Unity Catalogは、レイクハウス上のデータとAI資産全体にわたって統合されたガバナンスを提供し、コンプライアンス対応を簡素化しながら、すべてのチームに適切なアクセスを可能にします。

インジェスト時の品質チェックの自動化

データ品質チェック（Null率のしきい値、参照整合性テスト、値の範囲の検証など）は、すべてのインジェストパイプラインの一部として自動的に実行される必要があります。入り口の時点で品質の問題をキャッチすることは、ダウンストリームのモデルやダッシュボードに波及した後に発見するよりも劇的にコストを抑えられます。エラーが発生した場合は、不正なデータを黙って通すのではなく、所有チームにアラートを送信し、パイプラインを停止させるべきです。

効率的なスキャンのためのファイルサイズの最適化

高頻度のストリーミングインジェストによって作成される何百万もの小さなファイルは、メタデータのオーバーヘッドを生み出し、クエリのパフォーマンスを低下させます。ほとんどの導入環境では、小さなファイルを最適なサイズ（通常は128 MBから1 GB）のパーティションに結合する定期的なコンパクション（圧密）ジョブを実行することで、スキャン効率と、過度に大きな個別ファイルを管理するオーバーヘッドとのバランスを取ることができます。

課題、トレードオフ、およびリスク管理

トランザクションテーブルフォーマットの複雑さ

オープンテーブルフォーマットは、生のデータレイクにはないメタデータ管理の複雑さをもたらします。トランザクションログ、スナップショットの履歴、コンパクションのスケジュールなどはすべて、運用上の注意を必要とします。シンプルなデータレイクから移行するチームは、この学習曲線のための時間を予算に組み込み、手動で管理するのではなく、日常的なメンテナンスを自動化するツールに投資すべきです。

大規模レイクのパフォーマンスチューニング

ペタバイト規模のレイクハウスには、計画的なチューニングが必要です。クエリのパフォーマンスは、パーティションプルーニング、ファイルレイアウト、インデックス作成戦略、およびキャッシュに依存します。データエンジニアは、データ量が増加しクエリパターンが進化するにつれて、継続的な最適化作業が発生することを想定しておく必要があります。エンタープライズ規模において、パフォーマンスチューニングが一度限りの作業で終わることはありません。

強力なカタログ機能がないことによるガバナンスのギャップ

中央集権的なカタログのないレイクハウスは、本質的にはACIDトランザクションを備えたデータレイクにすぎず、データガバナンスの問題は未解決のままです。適切なガバナンスフレームワークなしでストレージレイヤーとコンピューティングレイヤーをデプロイする組織は、大規模な環境でのデータの検出、リネージ、およびアクセス制御に引き続き苦労することになります。ガバナンスインフラこそが、生産性の高いデータレイクハウスと、単に高度化したデータスワンプを分ける境界線です。

移行と導入のロードマップ

まず既存のレイクとウェアハウスを監査する

何かを移行する前に、組織内のすべてのデータウェアハウス、データレイク、およびポイントツーポイントの統合など、現在の状態を文書化します。

どのテーブルが頻繁にクエリされているか、どのパイプラインが重要か、どのデータセットに既知のデータ品質の問題があるかを特定します。この監査により、レイクハウスによって即座に改善できる「品質の低い高価値データセット」というクイックウィン（早期の成果）と、移行を開始する前に慎重な計画が必要となる依存関係が明らかになります。

移行にあたって高価値なドメインを優先する

すべてのデータセットを一度に移行する必要はありません。

まず、データの断片化が最も大きな課題となっているドメインから始めましょう。たとえば、ビジネスユニット間で分散している顧客データ、高度な分析をサポートできないレガシーなウェアハウスに取り残されている売上データ、あるいはビジネスインテリジェンスと機械学習のワークフローの両方に同時に供給される運用データなどです。高価値なドメインで早期に成果を上げることで、より広範な展開を前に、組織内での信頼を築くことができます。

ハイブリッド共存戦略による段階的な移行

既存のウェアハウスと新しいレイクハウスが並行して動作する、ハイブリッド共存期間を計画します。新しいワークフローの信頼できる情報源（ソースオブトゥルース）としてレイクハウスを使用しつつ、履歴データを段階的に移行します。両方のシステムに二重書き込みを行うことで、セーフティネットが確保され、予期しない問題が発生した場合でもロールバックが可能になります。

メトリクス、モニタリング、およびコスト管理

データの鮮度とクエリレイテンシのSLAを定義する

すべての本番データセットには、データの鮮度とクエリレイテンシに関して合意されたSLAを設定する必要があります。これらのSLAは、パイプラインのスケジューリングやコンピューティングのプロビジョニングに関するエンジニアリング要件を定義し、モニタリングとアラートの明確な基準を提供します。

SLAが定義されていなければ、レイクハウスがさまざまなチームやワークロードにわたるダウンストリームのデータコンシューマーに対する義務を果たしているかどうかを判断することは不可能です。

パイプラインの健全性とデータ品質の計測

パイプラインの健全性モニタリングでは、ジョブの成功率、処理レイテンシ、行数、およびデータ品質メトリクスの経時的な傾向を追跡する必要があります。上流でのスキーマ変更に関連する行数の減少は、両方のシグナルが同じオブザーバビリティダッシュボードで計測されていれば、診断が容易になります。パイプラインの計測を早期に行うチームは、ビジネス向けのレポートや本番モデルに問題が表面化する前に、問題をキャッチすることができます。

ストレージティアとライフサイクルコストの監視

履歴データが蓄積されるにつれて、ストレージコストは継続的に増加します。アクセス頻度の低いデータをより安価なストレージティアに自動的に移行するライフサイクルポリシーを実装します。ストレージコストとコンピューティングコストの比率を経時的に監視します。不均衡がある場合は、コンピューティングの過剰プロビジョニングや、ビジネスが実際に定期的にクエリする以上のデータを保持している保存ポリシーを示していることがよくあります。

FAQ：データレイクハウスの例

データレイクハウスとは何ですか？また、データレイクとどのように違いますか？

データレイクハウスは、データレイクの柔軟で低コストなストレージの上に、ACIDトランザクション、スキーマ強制、およびデータ品質管理を追加したものです。通常のデータレイクは生データを安価に保存しますが、信頼性の高い分析に必要なトランザクション保証やガバナンス機能を欠いています。レイクハウスは、別のウェアハウスにデータを移動させることなくそのギャップを解消するため、エンタープライズ規模で柔軟性とデータの信頼性の両方を必要とするチームにとって最適な基盤となります。

最も一般的なデータレイクハウスのユースケースは何ですか？

最も一般的なデータレイクハウスの例としては、リアルタイムのストリーミング分析、機械学習のフィーチャーエンジニアリング、カスタマー360プロファイル、単一の信頼できる情報源（シングルソースオブトゥルース）を持つエンタープライズビジネスインテリジェンス、およびIoTセンサーデータのパイプラインが挙げられます。いずれのケースでも、レイクハウスは複数の独立したシステム（データレイク、ウェアハウス、MLプラットフォーム）を、すべてのデータチームが共有する単一の統合データアーキテクチャに置き換え、コストを削減し、不要なデータの移動を排除します。

ACIDトランザクションはデータレイクハウスにどのようなメリットをもたらしますか？

ACIDトランザクションは、レイクハウスのテーブルに対する読み取りと書き込みが、原子性、一貫性、独立性、および耐久性を持つことを保証します。並行するパイプラインジョブが互いのデータを破損することはなく、失敗したジョブがダウンストリームの結果を汚染する不完全な書き込みを残すこともありません。また、書き込み側がデータを更新している間も、読み取り側は常に一貫したスナップショットを参照できます。これらの保証により、同じ基盤データストアを共有するデータサイエンティストやビジネスインテリジェンスの利用者の間で、本番環境の分析においてレイクハウスを信頼できるものにします。

データレイクハウスにおけるデータガバナンスはどのように機能しますか？

レイクハウスにおけるデータガバナンスは、すべてのテーブルと資産にわたるアクセス制御、リネージの追跡、データの分類、および検出を管理する統合カタログを通じて一元化されます。どのクエリエンジンやツールがデータにアクセスするかにかかわらず、ロールベースのアクセスポリシーが一貫して適用されます。ストリーミング分析と機械学習のワークロードは、この同じガバナンスモデルを共有するため、データ品質とアクセスポリシーが、生のインジェストからモデルサービングに至るまで、ギャップやシステムごとの個別の設定なしで拡張されます。

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事