OneLake の実体について

はじめに

11月に実施した、icrosoft Data Analytics Day(Online) 勉強会 の登壇資料、
Microsoft Fabric OneLake の実体について　の解説です。

OneLake 概要と特徴

OneLake は、Microsoft Fabric の中心として提供されるデータレイクストレージサービスです。

• 組織に1つのデータレイク: OneLake は、組織全体で一つのデータレイクとして機能します。これにより、これまでのようにプロジェクトごとにデータレイクサービスをセットアップし、複数のデータレイクを個別に管理する必要がなくなります。
• Microsoft 365 との統合: Microsoft 365 テナントを利用している組織には、OneLake が既に備え付けられており、Fabric にサインアップした時点ですぐに利用可能です。
• ワークスペースによる管理: 組織内のプロジェクトチームや部署ごとにワークスペースを作成し、その中でデータを管理することができます。これにより、データの整理とアクセスが容易になります。ワークスペースは数クリックで作成可能です。
• 共同作業の強化: OneLake は、OneDrive のように使いやすく、データ分析や活用のための共同作業をサポートします。これにより、チーム全体でのデータ活用が促進されます。

特徴 1: OneCopy

OneCopy は、OneLake の重要な特徴の一つです。

従来の課題

従来のデータベースやストレージでは、以下のような課題がありました：

• データはサービスや用途ごとに別々にコピーされ、ストレージが分散。
• 各サービスに合わせた再コピーが必要で、手間やコストが増大。
• 重複データの管理が煩雑化し、非効率。

OneCopy の利点

OneCopy の考え方は、「データのコピーは一度きり」というものです。通常、データベースにデータを書き込む場合、そのデータは特定のサービス（データベースの場合にはデータベースサービス）に依存しており、他のサービスで再利用するためにはそのサービスへ再度コピーが必要でした。しかし、OneCopy ではこのプロセスが簡素化されます。

1. 一度のコピーで複数用途に対応:

   • データがオンプレミスやクラウドに存在していても、一度 OneLake にデータをコピーすれば、異なるエンジン（Power BI、SQL、Pythonなど）から同じデータに直接アクセスできます。
   • 再コピーが不要なため、データの利用効率が大幅に向上します。

2. 効率的なストレージ活用:

   • 重複データを削減することで、ストレージの無駄遣いを防ぎます。
   • シンプルな管理で、ストレージ容量や運用コストを最適化します。

3. Fabric 内外でのデータ仮想化:

   • ショートカット（シンボリックリンク）機能を活用し、データをコピーすることなく他のユーザーやチームと共有可能。
   • AWS S3、Google Cloud Storage、Azure Data Lake Storage Gen2 などの外部ストレージも OneLake に統合し、仮想的に利用できます。

例えば、カスタマー360のデータを格納する際に Data Factory などで一度コピーを行えば、その後のデータ分析や可視化のために再度コピーする必要はありません。Power BI での可視化や SQL エンジンでの変換、Python によるデータ解析も、同じデータに対して直接処理できます。

補足知識: コンピューティングとストレージの分離

昨今の分析ソリューションの重要な考え方の一つに「コンピューティングとストレージの分離」があります。

従来のデータベースの課題

従来のオンプレミスの SQL Server などでは、ストレージとコンピューティングが一体化していました。データベースエンジンを通してデータにアクセスするため、エンジンの性能が処理性能の限界となり、他のユースケースでデータを利用する際には再度コピーが必要でした。

レイクセントリックなアーキテクチャ

データレイクの登場により、ストレージとコンピューティングが分離されました。

これにより、以下の利点が生まれます。

• 拡張性: ストレージとコンピューティングが分離されているため、必要に応じてコンピューティングリソースをスケールアウトしやすい点はもちろん、ユーザーがそれぞれのコンピューティングリソースを使用してデータを再利用することができます。
• 柔軟なアクセス: データレイクは単なるストレージであり、様々なエンジンからアクセス可能です。これにより、異なる種類のエンジンでデータを処理し、多数のユースケースを実現することができます。

データベースサービスの背後でストレージを分離したアーキテクチャにより、特に拡張性の利点を起点にしてこのキーワードをもっとも流行らせたのが Snowflake だと思います。

Fabric は OneLake によるレイク中心なアーキテクチャで、最新のデータ分析ソリューションが備えるべき利点を実現しています。

特徴 2: オープンアクセス

OneLake の重要な特徴その 2 は、データのオープンアクセスです。

従来の課題

従来のデータ管理では、以下のような制約がありました：

• 新しいツールやサービスを導入する際、専用APIや独自の操作方法が必要になる。
• プラットフォーム間でのデータ共有が複雑で、作業負担が増える。
• 特定のベンダーやツールに依存する「ロックイン」が発生し、移行の柔軟性が制限される。

オープンアクセスの利点

1. 広範な互換性: OneLake は、新しい専用ツールを使わなければならないわけではありません。既存のツールやサービスをそのまま利用できます。Azure Data Lake Storage Gen2 (ADLS Gen2) の API をそのまま利用できるため、Azure Storage Explorer や PowerShell の Azure Storage SDK など、ADLS Gen2 に対応しているツールやサービスは、OneLake にも対応しています。
2. 異なるプラットフォームとの統合: OneLake は、Microsoft 製品だけでなく、Snowflake などの他社製品からもデータの読み書きが可能です。これにより、異なるデータ分析エンジンやサービス間でのスムーズなデータ共有を実現します。

以上のようにOneLake は ADLS Gen 2 のAPIに互換性があるため、Azure Databricks や、 Azure AI Foundry(旧 Azure AI Studio ) 、 Azure Data Factory などの従来の Azure Analytics / AI サービスはもちろん、Snowflake などの 3rd Party 製品からも利用が可能です。

また、OneLake File Explorer という専用クライアントツールも提供されており、これを利用することでさらに便利にデータ管理ができます。

OneLake File Explorer

特徴 3: オープンフォーマット

OneLake は、オープンソースの Delta Lake フォーマットを採用し、データフォーマットの標準化と効率的な管理を実現しています。この特徴により、データ分析における柔軟性と互換性が大幅に向上します。

従来の課題

従来のデータレイク管理では以下の課題がありました：

1. 多様なデータフォーマットの混在:

   • データレイク内では、CSV、Parquet、Avro など異なるフォーマットが混在し、管理や活用が複雑化。
   • フォーマットの不統一が原因で、クエリ性能が低下したり、分析時に追加の変換処理が必要になることも。

2. 新たなデータサイロの発生:

   • 複数フォーマットを活用する際に、フォーマットごとに個別のストレージやプロセスが必要となり、結果として新たなデータサイロが発生。

3. ベンダーロックインのリスク:

   • 特定のベンダー独自フォーマットを採用すると、ツールやプラットフォームが制限され、柔軟性が失われる。

オープンフォーマットの利点

OneLake は、オープンソースフォーマットである Delta Lake を採用することで、これらの課題を解決しています。以下にその利点を説明します：

1. フォーマットの標準化:

   • Delta Lake は、データレイクとデータウェアハウスの利点を併せ持った、レイクハウスソリューションのための業界標準フォーマットで、OSS (オープンソースソフトウェア) として広く採用されています。
   • 一貫したデータフォーマットにより、分析プロセスの効率が向上し、異なるツール間での互換性が確保されます。

2. 構造化データの最適化 (Delta Parquet):

   • OneLake の Tables 領域では、Delta Parquet フォーマットを採用。
   • V-Order と呼ばれる独自のエンコーディング技術を使用しており、クエリ性能を最適化。
   • 大規模データセットにおいても高速かつ効率的な分析が可能です。

3. 非構造化データの柔軟な対応:

   • Files 領域では、画像、動画、文書などの非構造化データを保存可能。
   • フォーマットの制約がないため、あらゆるデータを柔軟に取り扱えます。

4. ベンダーロックインの回避:

   • Delta Lake はオープンソースのため、特定のベンダーやツールに依存することなく、幅広いエコシステムで活用可能です。

補足: Apache X Table による相互運用性の向上

OneLake は、従来の Delta Lake フォーマットの標準化に加え、Apache X Table 技術を統合予定であり、異なるOSSフォーマット間での相互運用性をさらに高めます。これにより、複数のデータプラットフォーム間でのシームレスなデータ利用が可能になります。

Apache X Table

レイクハウスアーキテクチャを実現するストレージフォーマットは Delta Lake（Databricksが開発、採用）や Iceberg（Snowflake、BigQuery、Redshift などで採用）、Hudi(Uber が開発) といった3つのデファクトスタンダードが存在しており、フォーマット間の互換性が課題でした。

Apache X Table は、Delta Parquet を Iceberg として読み取り、Iceberg を Delta Lake として読み取るといったフォーマット間の相互運用性を高めるプロジェクトで、これにより、 Databricks（Delta Lake）と Snowflake（Iceberg）という二大分析プラットフォームをシームレスに結びつけることが期待されています。

※
Store and access your Iceberg data in OneLake using Snowflake and shortcuts　
にて続報が発表されました

Fabric 機能との関係性について

OneLake の基本構造と機能を理解するには、Fabric におけるワークスペースや、レイクハウスなどのアイテムとデータ保存の仕組みを押さえることが重要です。

https://learn.microsoft.com/ja-jp/fabric/onelake/security/get-started-security

OneLake は、「組織に1つのデータレイク」という考えのもと、Fabric ワークスペース と密接に結びついています。

ワークスペースはフォルダーとして表現され、その中に「Tables (構造化データ領域)」と「Files(非構造化データ領域)」が含まれています。

3つの ”ハウス” のデータ構造

Fabric にはデータ保存領域の主要な環境として、3つのハウスが存在します。

それぞれのアイテムを作成すると、データは以下のように管理されます。

• Lakehouse
  • Tables（スキーマやテーブルが格納）
  • Files（フォルダーが格納）
• Warehouse
  • スキーマとテーブルでデータを管理
• Eventhouse
  • データベースインスタンスの下にテーブルが配置

Lakehouse では構造化データ（テーブル形式）と非構造化データ（ファイル形式）の両方を効率的に管理でき、Warehouse や Eventhouse ではさらに特化した用途でデータを保存できます。

OneLake のフォルダー構造の表現

OneLake 内部のデータ構造は、OneLake File Explorer を使用して直接確認できます。Windows のエクスプローラーと似た操作性を持ち、OneDrive や SharePoint を操作する感覚でデータを管理できます。このツールを使用して視覚的にOneLake の構造を確認します。

OneLake ワークスペースがフォルダーとして OneLake に実体化されていることがわかります。

レイクハウスの構造

レイクハウスの構造を見ていきます。

Tables には publicholidays というテーブルがありますが、これをフォルダで確認すると、テーブル名のファルダ配下にDelta Lake フォーマットの一連のファイル（.parquet や _delta_log）が格納されています。

一方 Files はそのままのフォルダ構造、ファイル内容がエクスプローラーから確認できます。

補足）DeltaLake の基本構造

Delta Lake の基本構造を理解することで、Delta Lake がどのようにデータのトランザクション処理やバージョン管理を実現しているかが見えてきます。

Delta Lake の構成要素

Delta Lake は主に以下の2種類のデータで構成されています：

1. _delta_log:

   • トランザクションログファイルを格納するフォルダー。
   • このログには、以下の情報が記録されています：
     • 各操作内容（例: テーブルの作成、データの更新、削除）。
     • 操作によって生成されたテーブルのバージョン。
   • 各バージョンに対応する Parquet ファイルの場所や、使用すべきファイルリストが記録されています。

2. Parquet ファイル:

   • 実際のデータが格納されたファイル。
   • バージョンごとに Parquet ファイルが生成され、更新や変更に応じて新しいファイルが追加されます。

ちなみにこの構造は OneLake FileExplorer からではなく、 Fabric の UI上からも確認が可能です。

ウェアハウスの構造

Delta Lake のParquet がフォルダ管理されている点がやや異なるものの、ほとんど同じ構造です。

イベントハウスの構造

レイクハウスとほぼ同じ構造です

イベントハウスの OneLake への反映について

イベントハウスはストリーミングの書き込みと、そのクエリに最適化されているため、OneLakeへの反映方法はやや特殊です。

ストリームデータは、短い間隔で小さなデータが継続的に生成される特性を持っています（例: 毎秒、毎分単位のデータ）。
そのため、そのまま OneLake にDeltaLake 形式で出力すると、一回の処理で生まれる Delta Lake 上の Parquet ファイルは非常に小さくばらけてしまい、パフォーマンス低下につながります。

イベントハウスは、時系列インデックスが付与された独自のデータ形式で保管しながら、最適なサイズごとに段階的にDelta Lake に反映することで再利用性と、即時分析の対応を両立しています。
https://learn.microsoft.com/ja-jp/fabric/real-time-intelligence/event-house-onelake-availability

また、イベントハウス内は以下の2種類のストレージ層で構成されており、保持ポリシーを構成することで、コスト効率を柔軟にします。

1. キャッシュ層（OneLake Cache Storage）:

   • 高速クエリの実行を目的としたプレミアム層。
   • リアルタイム性を求められるデータの一時保存に利用されます。

2. 保持層（OneLake Standard Storage）:

   • データを長期間保存するための標準層。
   • クエリ速度は標準的ですが、コスト効率に優れています。

データのURLから ADLSとの互換性を確認

OneLake のプロパティを見てみると、ADLS Gen2 によく似た URLが存在していることがわかります。

1. ADLS の URL:

   https://アカウント名.dfs.core.windows.net/コンテナ名/...
   

   これは従来の Azure Data Lake Storage Gen2 の URL 形式で、Microsoft の多くのツールやサービスが対応しています。

2. OneLake の URL:

   https://onelake.dfs.fabric.microsoft.com/ワークスペースコンテナ名(GUID)/...
   

   OneLake も「dfs」エンドポイントを使用していますが、ドメイン部分が fabric.microsoft.com に変更されています。

dfsエンドポイントは共通であるものの、このドメインの差異により、既存ツールでブロックされる可能性がある点には注意です。

AzCopy での対処例：https://qiita.com/ryoma-nagata/items/b04c11beab457342d649

Power BI エンジンと OneLake の関係

次は Power BI と OneLake の関係を見ていきます。

Power BI のモードから見たエンジン、データの関係性

Power BI におけるOneLake との関係を理解するには、主に以下の3つのモードについて知る必要があります：

• Import モード
• Direct Query モード
• Direct Lake モード（Fabric で新たに導入）

これらのモードは、データの保存場所やアクセス方式によって異なる特性を持っています。

https://learn.microsoft.com/ja-jp/fabric/get-started/direct-lake-overview

• Import
  • 仕組み：Power Query を使用してデータベースエンジンを介してデータを取得し、VertiPaq と呼ばれる Power BI 専用のデータフォーマットに変換して保存 します。
  • 特徴：
    • 高速なクエリが可能（データがメモリ内に格納されるため）
    • インポート処理に時間がかかる。また、インポート処理を実行した時点のデータで固定されるため、リアルタイムなデータ可視化はできません。
• Direct Query
  • 仕組み：Power BI 上にデータを保持せず、 データベースエンジンに直接クエリ します。レポートを操作するたびに、セマンティックモデル上で発生したクエリがデータベースエンジンのクエリ言語に変換されています。
  • 特徴：
    • データがリアルタイムで更新される。
    • クエリの処理速度はソースとなるデータベースエンジンの性能に左右される。
• Direct Lake
  • 仕組み：Power BI エンジンが、OneLake 上の Delta Parquetファイルに直接アクセス します。
  • 特徴：
    • 必要なデータをオンデマンドでメモリに展開することで高速なクエリ応答が可能です。
    • インポートの処理が不要なので、OneLake 上のリアルタイムデータを可視化可能です。

以上のように、Fabric 上にデータがある場合には非常に有力な選択肢となりますが、データボリュームが大きすぎる場合にはDirect Query にフォールバックされることや、計算列や計算テーブルが現時点では利用できないなどの制約事項には注意が必要です。

これらの特性を把握しておくと、Fabric 上のソースであっても、モードの特性の違いに変わりがないこともわかります。

もっともよく誤解される点として、Fabric Warehouse などがソースでああっても、View を対象にした場合には Direct Query にフォールバックされてしまう点に注意してください。
View のデータは View を提供するウェアハウスエンジンにしか存在しないため、（クエリするまでデータは存在しない）Direct Lake の根本的な仕組みである 「OneLake 上の Delta Parquet へのアクセス」と合致しなくなるためです。

以上です。OneLake の実体を抑えることで Fabric を効率的に使う参考になれば幸いです。