データレイクの定義・アーキテクチャ・ユースケース・プラットフォームガイド

あらゆる組織では、既存システムが保持できる以上のデータが日々生成されており、その多くは従来のデータベースでは受け付けられない形式で届きます。データレイクはこの課題を解決します。まずすべてのデータを受け入れ、分析は後で行う——このアプローチにより、アナリストやデータサイエンティストは単一の信頼できるデータソースを基盤として活用することができます。

この記事では、以下の疑問に答えます。

• データレイクとは？
• データレイクの仕組みとは？
• データレイクの主なユースケースとは？
• データレイクが必要な理由とは？
• データレイクの活用例
• データレイク、データウェアハウス、データレイクハウスの違いとは？
• データレイクのアーキテクチャとは？
• クラウドデータレイクの導入方法とは？
• データレイクのメリットと課題とは？
• 最適なデータレイクプラットフォームの選び方とは？

データレイクとは、構造化データ・半構造化データ・非構造化データを元のままの形式で、規模を問わず一元管理できる集中型リポジトリです。リレーショナルデータベースではデータは取り込み時に変換または拒否されますが、データレイクでは前処理なしにクリックストリームイベントログ、IoTセンサーデータ、ソーシャルメディアフィード、PDFドキュメント、CRMエクスポートといった多様なデータを一つのレイクに共存させることができます。

データレイクには主に3つの役割が関わります。データエンジニアはレイクへデータを送り込むインジェストパイプラインを構築します。データサイエンティストは、事前に集計・フィルタリングされていない生データに対して探索的モデルを実行します。アナリティクスエンジニアは、レイクからキュレーションされたデータセットを作成し、ビジネスインテリジェンス(BI)ツールやダッシュボードに提供します。それぞれの役割でデータレイクを活用する目的は異なりますが、同じソースデータが散在するコピーではなく、単一の共有リポジトリを基盤とすることができる点はすべての役割に共通するメリットです。

データレイクという用語は、データマートという概念との対比から生まれました。データマートとは、地域別売上レポートのような特定の目的に最適化された、小規模でフィルタリングされたデータの集合です。一方、データレイクは後から定義するあらゆる用途に対応できる、データ全体の集積です。この違いは設計上の判断に大きく影響します。データマートでは保存前にどの問いに答えるかを決めますが、データレイクではまずデータを蓄積し、ビジネス上のニーズが生じた時点で問いに答えることができます。

データレイクが現代のデータプラットフォームの根幹を担っているのは、ストレージとコンピュートを分離する仕組みにあります。データを一度保存しておけば、ファイルを移動させることなく、SQL、機械学習 (ML)、ストリーミングといった異なる処理エンジンを同じファイルに対して適用することができます。例えば、小売業者がデータレイクに2年分のPOS生イベントデータを格納し、同一のデータセットに対して需要予測モデルと週次売上レポートを、ファイルを複製することなく、それぞれ異なるコンピュートエンジンで実行することができます。

データは取り込みレイヤーを通じてデータレイクに流れ込みます。このレイヤーはデータベース、API、イベントストリーム、フラットファイルといったソースシステムからデータを収集し、内容を変更することなく生ストレージゾーンに格納します。ソースシステムのスキーマエラーもそのまま保存されるため、上流での障害発生時のデータ損失を防ぐことができます。例えば、CRMベンダーが一晩でフィールド名を変更した場合でも、データレイクはレコードを確実に取り込みます。エンジニアはデータを失うことなく、クレンジングのステップで変更内容を整合させることができます。

データが格納されると、一連の処理ゾーンを経て段階的に処理が進みます。rawゾーンにはソースから取り込んだ未加工データが、クレンジングゾーンには検証・重複排除済みのレコードが、キュレーションゾーンにはビジネスですぐに活用できるデータセットが保存されます。この3ゾーン構成により、アナリストが誤って未クリーンなデータをクエリするリスクを防ぎながら、再処理のために元データを保持することができます。よくある失敗の原因は、ゾーン分離を省略してしまうことです。その結果、アナリストがクレンジング前のデータでダッシュボードを構築し、レポートが経営幹部に共有された後にエラーが発覚するという事態につながりかねません。

コンピュートレイヤーはストレージレイヤーから独立しています。SQLエンジン、MLフレームワーク、ストリーム処理ツールはいずれも同じファイルから読み込みます。例えば、同一のお客様イベントログを使って、データをコピーすることなく、不正検知モデルとマーケティングアトリビューションレポートの両方を同時に実行することができます。この分離構造により、負荷の高い処理タスクに対してコンピュートリソースを拡張する際も、ストレージを追加する必要はなく、逆もまた同様です。

メタデータカタログはストレージレイヤーの上位に位置し、どのデータが存在するか、どこに保存されているか、誰がアクセスできるか、そのデータがどれだけ最新かを一元的に把握します。カタログがなければ、ファイルが際限なく蓄積するだけで、検索も管理もガバナンスも効かない「データの沼」へと変わりかねません。カタログの導入を先送りにした組織では、6か月以内に、データエンジニアがデータセットを分析する時間よりも検索に費やす時間の方が長くなるのが一般的です。

データ出力はデータレイクと後続システムを接続します。BIダッシュボード、AIおよびMLパイプライン、カスタマーエクスペリエンスプラットフォーム、運用データベースはいずれも、それぞれで個別のコピーを管理するのではなく、キュレーションゾーンからデータを取得します。この単一出力パターンにより、サイロ化されたデータストアを抱える組織が直面する売上合計の数値が3種類存在する という問題の解消に役立ちます。

データレイクは、分析・運用を問わず幅広いワークロードに対応します。主なユースケースとしては、顧客分析、ML、セキュリティ監視、IoT、コンプライアンスレポート、リアルタイムの意思決定などが挙げられます。

• Customer 360プロファイリング。 組織は、webクリック、アプリイベント、購入履歴などの行動データをCRMレコードやサポートチケットと合わせて単一のデータレイクに取り込み、統合顧客プロファイルを構築します。例えば、あるリテールバンクでは、支店訪問データ、モバイルアプリのセッションデータ、コールセンターのトランスクリプトを単一のデータレイクに集約し、下流の顧客データプラットフォーム (CDP) が各お客様の統合ビューを組み立てられるようにしています。これは、大規模なパーソナライゼーションを実現するすべての企業にとって基盤となるユースケースです。Adobe Experience Platformはこのパターンを体現しており、ガバナンスされたデータレイクが生データと処理済みのお客様イベントを記録システムとして格納し、別個のリアルタイム顧客プロファイル機能がそのデータを統合ビューにまとめてチャネル全体でのアクティベーションに活用できます。
• MLおよびAIモデルのトレーニング。 データサイエンティストが精度の高いモデルをトレーニングするには、大量のフィルタリングされていない履歴データへのアクセスが不可欠です。データレイクは、レコメンデーションエンジン、解約予測モデル、需要予測システムのメインのトレーニングデータリポジトリとして機能します。これらのユースケースでは、データの多様性と量がモデルのパフォーマンスに直結します。データウェアハウスの集計・要約済みデータセットでは、堅牢なMLモデルのトレーニングには不十分なことが多いです。
• ログ分析とセキュリティ監視。 アプリケーションログ、サーバーイベント、ネットワークトラフィックは大量のデータとスキーマの多様性を生み出し、従来型のデータベースでは効率的な処理が困難です。このデータをデータレイクに格納してSQLやストリーミングクエリを実行することで、リアルタイムの異常検知とインシデント後のフォレンジック分析が可能になります。例えば、あるSaaS企業のセキュリティオペレーションチームでは、1日に数十億件の認証イベントを取り込み、数分以内にブルートフォース攻撃のパターンを検出するためのクエリを実行できます。
• IoTおよびセンサーデータの処理製造業、物流、公益事業の企業は、デバイスのテレメトリデータをデータレイクに直接取り込んでいます。データは途切れることなく継続的に届くうえ、独自のバイナリ形式をとるためです。アナリストはその後、バッチ処理またはストリーム処理でデータを分析し、設備の故障を未然に検知することができます。例えば、風力発電事業者はタービンの振動データをデータレイクに蓄積し、毎週予知保全モデルを実行することができます。
• 規制対応のアーカイブと監査金融サービスや医療機関は、データレイクをコスト効率に優れた変更不可のアーカイブ層として活用しています。生のトランザクションデータや患者記録データをオブジェクトストレージに保存するコストは、データベースへの保存と比べて大幅に安く、それでいてコンプライアンス監査に対応できるようデータを照会可能な状態に保つことができます。
• リアルタイム分析とデータストリーミング現代のデータレイクはストリーミングデータの取り込みをサポートしており、webサイトやモバイルアプリのイベントデータをイベント発生から数秒以内に照会することができます。これにより、リアルタイムのオファーの決定やA/Bテストのライブ測定など、夜間バッチ処理を待っていたのではインサイトが鮮度を失ってしまうユースケースにも対応することができます。

従来のデータベースは、事前に定義されたスキーマに一致しないデータを受け付けません。しかしデータレイクなら、新しいモバイルアプリ、サードパーティパートナーのフィード、センサーネットワークなど、新たなデータソースが加わっても、スキーマ設計と並行して即座にデータを取り込むことができます。これにより、インサイトを得るまでの時間を数週間から数時間へと短縮することができます。例えば、新しいモバイルアプリをリリースするマーケティングチームは、データエンジニアリングチームのスキーマ設計を待たずに、初日から生のイベントデータを収集することができます。

データレイクを一元化することで、各チームが個別にデータコピーを乱立させる問題を解消することができます。一元化されていない場合、各チームは独自にデータを抽出してローカルサーバーにコピーし、それぞれ異なる方法で変換してしまいます。その結果、総収益の数値が3つのバージョンに分かれ、どれも一致しないという事態が生まれます。共有カタログを備えたデータレイクは、全チームが照会できる唯一の信頼できるデータソースを実現します。

コスト効率もデータレイク採用の重要な理由のひとつです。Amazon S3、Azure Data Lake Storage、Google Cloud Storageなどのクラウドデータレイクのオブジェクトストレージに生データを保存するコストは、リレーショナルデータベースに同等のデータを格納する場合と比べ、テラバイトあたりの費用が大幅に低くなります。大量の過去データをデータウェアハウスからデータレイクに移行した組織では、コールドデータ層のストレージコストが80%以上削減されることを多くの場合実感することができます。

データレイクは、分析スタックの将来性も確保します。Parquet、Optimized Row Columnar (ORC)、Delta Lakeなどのオープンなファイル形式でデータを保存することで、特定ベンダーの処理エンジンへの依存を避けることができます。データを再取り込みすることなく、SQLエンジンをいつでも自由に切り替えることができます。

また、大規模なAIおよびMLの実現には、データレイクが欠かせません。AIモデルには、要約・集計されたスナップショットではなく、データセットの完全な生の履歴へのアクセスが必要です。エンタープライズ規模で予測AIや生成AI機能を構築する組織にとって、データレイクは構造的に不可欠な基盤です。

• データ量がデータベースの処理能力を超えたとき。トランザクションデータベースを分析クエリにも使用すると、両方のワークロードでパフォーマンスが低下します。データレイクは分析クエリをオフロードし、クエリの競合から運用システムを保護します。本番注文データベースに対してレポートクエリを実行している中規模のeコマース企業は、まさにその典型例です。
• データの多様性がスキーマの限界を超えたとき。構造化レコード (注文、アカウントなど) と非構造化コンテンツ (メール、PDF、画像など)、または半構造化フィード (JSONイベント、XMLファイルなど) を組み合わせる必要が生じた瞬間、スキーマを強制するデータベースはボトルネックになります。データレイクはこれら3種すべてをネイティブに処理することができます。
• チームが探索的なアクセスを必要とするとき。データサイエンティストがデータベース管理者 (DBA) チームに毎週生データのエクスポートを依頼している場合、ガバナンスの効いたセルフサービスアクセスを備えたデータレイクにより、そのボトルネックを完全に解消することができます。アナリストは適切なアクセス制御のもとでデータレイクに直接クエリを実行でき、DBAチームは運用データベースの管理に専念することができます。
• バッチ分析のレイテンシが高すぎるとき。夜間バッチ処理を待つのではなく、数分以内にデータへ対応する必要がある場合、データレイクにストリーミングインジェストレイヤー、データパイプライン、ストリーム処理エンジンを組み合わせることで、バッチレイヤーを置き換えることなくレイテンシをほぼリアルタイムまで短縮することができます。
• 法規制上の要件として低コストのアーカイブが必要なとき。金融サービス、医療、法務など、複数年にわたるデータ保持義務がある業界では、データレイクを階層型アーカイブとして活用するケースが多くあります。ホットデータは高速クエリのためにウェアハウスに保持しつつ、コールドデータははるかに低コストでデータレイクに格納することができます。

データウェアハウスは、BIクエリの高速処理に最適化された、事前にモデル化された構造化データを格納します。スキーマオンライト方式を採用しており、データはロード前にクリーニングと変換が必要です。一方、データレイクはスキーマオンリード方式に従い、生データをそのまま保存し、クエリ実行時にのみ構造化することができます。

実用的なトレードオフとして、ウェアハウスは既知の定期的なクエリ(月次の地域別売上など)に対して高速ですが、非構造化データの保存や生イベントのアドホックな分析には不向きです。一方、データレイクは構造化クエリでは速度が劣る場合がありますが、あらゆるデータ型に対応し、従来のデータウェアハウスでは処理できないMLワークロードもサポートすることができます。

データレイクハウスは、データレイクのオープンなストレージ機能と、データウェアハウスのACIDトランザクションサポートおよびパフォーマンス最適化を統合した新しいハイブリッドアーキテクチャです。Delta LakeやApache Icebergなどのテクノロジーは、オブジェクトストレージ上にテーブルレベルのメタデータ、バージョン管理、タイムトラベル機能を追加し、データレイクのスケールでウェアハウス並みの信頼性とガバナンスを実現します。

主な違い：データレイク vs. データウェアハウス vs. データレイクハウス

どの技術を選ぶかは、主要なワークロードの性質によって決まります。クエリの80%が標準的なBIレポートであれば、通常はデータウェアハウスが最適な選択肢です。MLパイプラインを実行する必要がある場合や、生のイベントストリームを保存する必要がある場合は、データレイクまたはレイクハウスが適しています。現在、ほとんどのエンタープライズデータプラットフォームは、この3つの技術を階層型アーキテクチャで組み合わせて活用しています。

データレイクアーキテクチャとは、データがレイクに入り、処理され、出力される流れを管理するコンポーネントの階層構造を指します。5つのコアレイヤーは、インジェスト、ストレージゾーン、処理、カタログ化とガバナンス、データ活用で構成されます。各レイヤーには固有の役割があり、例えばインジェスト時にデータを変換するなど、レイヤーを混同することは、解消に多大なコストを要する技術的負債を招く可能性があります。

• インジェスト。コネクタとデータパイプラインは、スケジュールに基づいて、またはデータストリーミングを通じてリアルタイムにソースシステムからデータを取得します。バッチコネクタはデータベースのエクスポートやファイル転送を処理し、ストリーミングコネクタはイベントキュー (KafkaやKinesisなど) やIoTテレメトリを扱います。バッチとストリーミングのデータインジェストのどちらを選ぶかは、ダウンストリームのデータ利用者がデータをどれほど迅速に必要とするかによって決まります。夜間のプロダクトカタログ同期はバッチ処理に適していますが、クレジットカードの取引によってトリガーされる不正検知アラートにはストリーミングが必要です。
• ストレージゾーン。生データゾーンには変更不可のソースデータが格納されます。保持ポリシーで定められている場合を除き、データの上書きや削除は行うべきではありません。クレンジングゾーンには検証済みで重複排除されたレコードが格納され、キュレーションゾーンには多くの場合集計済みのビジネス対応データセットが保持されます。この分離により、クレンジングロジックにバグが発見された場合でも、情報を損失することなく生データゾーンからデータを再処理することができます。
• 処理とコンピューティング。分散処理エンジン (Apache Spark、Presto、Trino、Flinkなど) はストレージゾーンからデータを読み込み、結果をダウンストリームゾーンや外部システムに書き込みます。処理はバッチ処理 (夜間のスケジュールジョブ)、マイクロバッチ (数分ごと)、またはストリーミング (継続的) として実行できます。リアルタイムのパーソナライゼーションや不正検知などのユースケースでは、ストリーム処理の活用が増加しています。コンピューティングとストレージを分離することで、処理能力をストレージコストとは独立してスケールすることができます。
• カタログ化とガバナンス。 データカタログは、スキーマ、データ系譜、所有者、分類、アクセスポリシーを含むすべてのデータセットを登録します。このレイヤーがなければ、データエンジニアはデータを分析するよりも検索に多くの時間を費やすことになり、コンプライアンス監査は手作業でエラーの起きやすいプロセスに陥ります。データ品質ルールとデータ系譜の追跡は、ストレージレイヤーではなくこのレイヤーで適用されます。
• 利用。 BIツール、AIおよびMLプラットフォーム、API、運用データベースがキュレーション済みゾーンに接続します。適切に設計された利用レイヤーは、セマンティックレイヤーまたはデータAPIを通じてクリーンでバージョン管理されたデータセットを公開し、基盤となるストレージ構造の変更から下流の利用者を保護します。

クラウドデータレイクは、ストレージとコンピューティングを切り離すオブジェクトストレージサービスを基盤に構築されています。主要クラウドプロバイダー3社はそれぞれ、データレイクの基盤となるマネージドオブジェクトストアを提供しています。Amazon S3 (AWS)、Azure Data Lake Storage Gen2 (Microsoft Azure)、Google Cloud Storage (Google Cloud)の3つです。いずれもオープンなファイル形式、きめ細かなアクセス制御、段階的なストレージ料金をサポートしています。

• リフト&シフト。 既存のオンプレミスHadoop Distributed File System (HDFS)クラスターをクラウドオブジェクトストレージに移行する方法です。既存の処理ロジックを保持できますが、クラウドネイティブの弾力的なコンピューティングを十分に活用することはできません。Hadoopへの大規模な投資を行っており、インフラのオーバーヘッドを迅速に削減する必要がある組織に適しています。
• クラウドネイティブ構築。 マネージドクラウドサービスを活用して、データレイクをゼロから設計する方法です。データインジェストサービス (AWS Glue、Azure Data Factory、Google Cloud Dataflowなど)、ストレージ (オブジェクトストア)、処理 (マネージドSparkまたはPresto)、カタログ化 (AWS Glue Data Catalog、Microsoft Purview、Google Dataplex) の各機能に対応したサービスを組み合わせます。運用上のオーバーヘッドを削減できますが、既存のパイプラインの再設計が必要になることが多いです。
• クラウド上のレイクハウス。 クラウドオブジェクトストレージ上にテーブル形式 (Delta Lake、Apache Iceberg、Apache Hudiなど) を重ねることで、ACIDトランザクション、スキーマ進化、タイムトラベルクエリを実現します。Databricksなどのプラットフォームで採用されているこのアプローチは、新規エンタープライズデータレイク構築のデファクトスタンダードになりつつあります。このパターンを採用する組織は、同一ストレージレイヤー上でリアルタイムとバッチの両ワークロードをサポートするため、ストリーミングデータプラットフォームと組み合わせることが多いです。

ガバナンスに関する重要な意思決定は、デプロイ時に行う必要があります。後からの対処では余計なコストがかかります。データが蓄積される前に保持ポリシーを定義してください。遡及的なクリーンアップには多大なコストが伴います。ストレージレイヤーで個人識別情報(PII)の列レベル暗号化を適用し、タグベースのアクセス制御を実装することで、新しいデータセットが適切なポリシーを自動的に継承できるようにします。

クラウドデータレイクのコスト管理には、積極的なモニタリングが欠かせません。ストレージコストは低く抑えられていますが、データ量に比例して増加します。コールドデータをアーカイブ層に移動するライフサイクルポリシーを設けなければ、データの価値を上回るペースでコストが膨らむ可能性があります。より大きなリスクはコンピューティングコストです。大規模なレイク上で最適化されていないクエリを実行すると、1回の実行だけで多大な処理コストが発生することがあります。

データレイクのコアなメリットは、広く認識されています。

• スキーマの柔軟性。データレイクは事前のモデリング不要で、ほぼあらゆるデータ形式を受け入れることができます。新しいデータソースを、数週間ではなく数時間で追加することができます。
• コスト効率の高いストレージ。オブジェクトストレージは、従来のデータベースストレージと比べてテラバイトあたりのコストが大幅に低く、複数年にわたるデータ保持を経済的に実現することができます。
• AIとMLのサポート。データサイエンティストは、DBAチームへのデータ抽出依頼なしに、完全な生の履歴データに直接アクセスすることができます。
• 唯一の信頼できる情報源。一元管理されたリポジトリにより、データの重複コピーとその管理に伴う照合作業を解消することができます。
• 独立したスケーラビリティ。ストレージとコンピューティングリソースを独立してスケールできるため、データ取り込み量が急増してもコンピューティングのアップグレードは不要です。

課題も同様に重大です。最も多く指摘される懸念が、「データスワンプ」化のリスクです。メタデータの管理、リネージの追跡、アクセスガバナンスが徹底されていなければ、データレイクは管理不能なファイルの蓄積へと変貌する恐れがあります。デプロイ時にカタログレイヤーを省略した組織では、データエンジニアがデータを活用するよりも探し出すことに多くの時間を費やすという問題が繰り返し生じています。

データ品質は、自動的に確保されるものではありません。データレイクは、破損したレコード、重複イベント、ソースシステムからのスキーマドリフトを含む、あらゆる受信データを受け入れます。データ品質は、明示的なバリデーションルールによってクレンジングゾーン内で確保する必要があります。ストレージだけで品質が担保されることはありません。

データレイクの導入は、セキュリティとコンプライアンスの複雑さも増大させます。PII、財務記録、医療データを業務データと同一のレイクに保存すると、攻撃対象領域が大幅に拡大します。そのため、列レベルの暗号化、属性ベースのアクセス制御、監査ログは、後から追加する対策としてではなく、アーキテクチャ設計の根幹として最初から組み込む必要があります。

組織的な観点からは、データレイクは部門横断的な管理体制を必要とします。ストレージ、データ取り込み、ガバナンス、データ活用をそれぞれ異なるチームが担当するケースが多く見られます。専任のデータプラットフォームチームや共通のデータコントラクト標準がなければ、レイクはチーム固有のゾーンに分断され、解消しようとしていたサイロ化を再び引き起こすことになります。

パフォーマンス面でのトレードオフも存在します。データレイク内の大規模な未パーティション化データセットに対するアドホッククエリは、データウェアハウスで実行する同等のクエリよりも処理速度が低下します。柔軟なデータ探索と高速なBIレスポンスの両方が求められる組織では、データレイクハウスアーキテクチャを採用するか、データレイクのキュレーションゾーンからデータを供給する独立したデータウェアハウスを維持するのが一般的です。

最適なデータレイクプラットフォームは、組織の現在のインフラ、主要なワークロード、ガバナンス要件によって異なります。一般的な組織の状況は4つのパターンに分類でき、それぞれに適したプラットフォームの種類も異なります：

1. Hadoopのレガシーインフラを持たず、マネージドサービスを重視するクラウドネイティブ環境の場合。マネージドDatabricks、外部テーブルを使用したSnowflake、またはGoogle BigLakeなど、クラウドネイティブのデータレイクハウスプラットフォームを選ぶことができます。
2. AWS、Azure、またはGoogle Cloudへの既存投資が大きい場合。サードパーティープラットフォームの評価に入る前に、既存クラウドプロバイダーのネイティブデータレイクサービスを拡張することを検討してください。新しいベンダーを追加する際の統合コストは、機能面での限定的なメリットを上回ることが多くあります。
3. 分析よりもお客様データのアクティベーションとリアルタイムのパーソナライゼーションに主眼を置いたワークロードが中心の場合。データレイクと専用の顧客プロファイルストアを組み合わせたCDPの導入を検討してください。例えば、Adobe Experience Platformは、取り込んだデータの記録システムとしてガバナンスが整備されたデータレイクを活用し、独立したリアルタイム顧客プロファイルにデータを供給します。このプロファイルはお客様データを統合し、リアルタイムのセグメンテーションとジャーニーアクティベーションを実現します。データは一度取り込まれると、別のマーケティングスタックにコピーされることなく、分析とアクティベーションのユースケース全体で共有することができます。
4. マルチクラウドまたはハイブリッド要件を持つエンタープライズ環境。Delta LakeやIcebergなどのオープンテーブルフォーマットをサポートするプラットフォームを評価し、ストレージ層でのベンダーロックインリスクを軽減してください。

購入者は一貫した評価基準を適用する必要があります：

• オープンフォーマットのサポート。ベンダーを切り替えた場合、別の処理エンジンを使用してデータにアクセスできますか？
• ガバナンスの成熟度。カタログ、データリネージ追跡、列レベルのセキュリティがプラットフォームに標準搭載されているか、それともアドオンとしてのみ利用可能ですか？
• ストリーミングとバッチ処理の同等性。同一インフラ上で、リアルタイムデータのストリーミングと夜間バッチ処理の両方を処理できますか？
• 総所有コスト (TCO)。ストレージのテラバイト単価だけでなく、データ転送料金、アイドルクラスターのコンピューティングコスト、パイプライン維持に必要なエンジニアリング工数も考慮してください。
• エコシステムの統合。既存のソースシステムやダウンストリームツールのうち、ネイティブに接続できるものはいくつあり、カスタムコネクタが必要なものはいくつありますか？

エンタープライズ規模のデータレイク展開では、プラットフォームの選択はデータガバナンスモデルと切り離せません。強固なガバナンス基盤 (属性ベースのアクセス制御、監査ログ、データ契約など) を備えたプラットフォームを選択した組織は、コンプライアンス要件が変更された際の修正コストが一貫して低いことが報告されています。エンタープライズデータレイクソリューションの評価では、データのインジェスト速度だけでなく、実際のデータ量とチームのアクセスパターンでガバナンスをテストする概念実証も実施してください。

データレイクプラットフォームを決定する前に、3つの要素を評価してください：最初の90日以内に接続するデータソースの数、データサイエンスチームが生データへのノートブックアクセスを必要とするか、それともキュレーション済みデータセットのみを扱うか、そして取り込むデータのコンプライアンス分類です。これら3つの要素を通じて、汎用データレイク、レイクハウス、またはCDPのようなドメイン固有プラットフォームのいずれが適切かを判断できます。

アドビがビジネスを支援する方法

お客様データの統合によるリアルタイムのパーソナライゼーションとアクティベーションを優先事項とするなら、Adobe Experience Platformをご検討ください。ストレージと分析のためのガバナンス済みデータレイクと、エンタープライズ規模のセグメンテーションおよびジャーニーオーケストレーションに対応したリアルタイム顧客プロファイルを組み合わせ、お客様データの統合を実現します。

Adobe Experience Platform でできることをもっと詳しく見る。