セマンティックモデルQ&A

今回のMicrosoft Fabric GAにおいて、FabricかつPower BI関連で最もテクニカル、かつ重要なセッションの1つが Semantic Model Q&A Session (by Christian Wade & Zoe Douglas)となります。
ignite.microsoft.com参加者: オンライン約400名

これだけの規模の参加者が集まるQ&Aセッションは類を見ないのですが、海外でFabricに興味を持つ顧客の質問を知るのに非常に良い機会だと思います。かなりテクニカル、かつ、”凝縮された回答”となっていますが、今後Fabricを使う予定のある方は何度もこちらに戻って確認して頂ければと思います。

※注意
「データセット」は別名「セマンティックモデル」に変更となっています。
Datasets renamed to semantic models | Microsoft Power BI Blog | Microsoft Power BI

Q1: セマンティックモデルの意味合い

質問: セマンティックといえば大きな世界での話であり、データセットはセルフサービスという意味合いがあった。"認定されたデータセット（Certified Dataset）"といった名称がある中で、セマンティックモデルに名称変更された背景や意義、この新しい世界について教えてほしい

回答: まず、"認定されたデータセット"ではなく、"認定されたセマンティックモデル"ですね😆 いくつかのアーティファクト（例えばプッシュデータセット等）がまだレガシー名称を保持したままであるが、Power BIやFabricに繋がる場合はDocsやFabricなどのUI*1において全てセマンティックモデルに更新されています。”データセット”という言葉は、セルフサービスBI向けのものであり、何よりも”一般的な言葉”であったため、多くの場合でこの言葉を使うことができていました。しかしながら、セルフサービスBIユーザーでさえ、テーブルやリレーションシップに対してBIモデルという言葉を使っており、セマンティックモデルという名前を導入しても少なくとも”モデル”という言葉を使う部分では違和感はないでしょう（もちろん、モデルだけではFabricではMLモデルなど、他の呼称もあるため一概には難しいですが）。

マーケットリサーチによると、モデルという言葉は完璧ではないが、ユーザーにとって受け入れられるものであったことが判明しています。全てがセルフサービスモデル、あるいは全てがエンタープライズモデル、というわけではなく、多くの場合においてその中間に位置することが多いことから、これら両方を1つにまとめた名称が必要であろうという判断から、セマンティックモデルという名称に統一したほうがベストであると判断しました。また、Power BI Desktop上で既にモデルという言葉（モデルビュー等）が既に浸透している部分も考慮しています。
参考🔗: Is Power BI A Semantic Layer? (Chris Webb)

Q2: データマートについて

質問: データマートの今後について教えて欲しい

回答: データマートは引き続き存続する予定ですが、今後はよりFabricと統合された形に改良されていく予定です。

統合という意味で言えば、大規模なデータセットのストレージ形式（Large semantic model storage format）でインポートしたセマンティックモデルをOneLakeにDelta Parquet形式で書き込む機能が発表されたので、活用事例が増えるのではないかと考えています。
参考🔗: OneLake integration for semantic models (公式)

この機能は以下の点で顧客にとって非常に魅力的な機能となっています。

• Fabricとのインテグレーションを実現できます
• Fabricの分析エンジンを全て活用できます
• SQLクエリを書いたり、Lakehouseショートカットを作ったりする必要がなく、顧客はDirect Lakeを使用できるようになります

Power BIのセマンティックモデルはそれ自体が独自の分析データベースとなっているため、オープンフォーマットという形でOneLakeに統合できることの意義は大きい。インポートされたPower BIセマンティックモデルからWarehouseへ移行する必要がある場合、この機能を使用すればDirect Lakeを使ってDelta Parquet形式のPower BIセマンティックモデルにアクセスできるのは非常に便利なことでしょう。
参考🔗: Driect Lakeの解説（テクテク）

Q3: リアルタイムへのアクセスについて

質問: Fabricという新しい選択肢が増えてきた中で、リアルタイムデータにアクセスするためにはやはりDirectQueryがベストか？

回答: It depends! 使っているシステムやユースケースによって異なります。例えば、オンプレミス*2データベース等を使用している場合、OneLakeにデータ投入が難しいと思われるでしょうから、リアルタイムという意味では相対的にDirectQueryがもしかしたらベストな選択かもしれません。一方で、ミラーリング*3（以下「Mirroring」）等の選択肢が今後可能となることから、WarehouseからDirect Lakeを使うことが最適かもしれません。Direct Lakeはデータ量の影響も受けるため、Direct Lakeとして利用できる集計されたデータを使うケースもあれば、複合モデルを組み合わせてDirectQueryを使用するケースもあるでしょう。更に、IoT等のデータであれば、Real-Time AnalyticsというワークロードがFabricを使うことで可能になるため、ニーズに応じて異なるエンジンを使うことになるでしょう。結局のところ、ビジネス上の意思決定によって最新テクノロジーに投資するかどうかの判断にもなってくるため、様々な要素を考慮する必要があります。

Q4: Mirroringについて

質問: Mirroringについて教えて欲しい

回答: Mirroringについての詳細は別のチームが担当しているため、詳細部分はお伝えできませんが、通常のPower BIとGatewayを使用した際の話とは異なり、クラウドデータウェアハウスやデータベース以外に、オンプレミスデータをOneLakeへミラーリングする機能は今後可能性があるかもしれません。

Q5: TMDLやCI/CD等について教えてほしい

質問: TMDL（Tabular Model Definition Language = 表形式モデル定義言語、YAML*4ベース）の導入により、Power BIでプロ向け開発が可能になったことは非常に興奮を呼んでいますが、異なるワークスペースへのセマンティックモデルのより簡単なデプロイ方法について教えていただけますか？現在のAPIでは、Azure DevOpsを使用したCI/CD*5パイプラインで作業用ファイルを扱うことが不便です。

回答: 元Power BI CATのRui Romanoが開発責任者であり、TMDLに真剣に取り組んでいます。現時点では、まだTMSL（Tabular Model Scripting Language = 表形式モデルスクリプト言語、JSONベース）をベースにしていますが、この形式は今後も維持されます（TMSLはAPIコールやソース管理レポジトリのメタデータの保持に使用されます）。したがって、将来的にはFabric API（現時点ではADLS Gen2 APIのみ）が導入されると、Power BI Desktopの開発者モードでTMDLを保存できるようになるでしょう。FabricのGit統合については、Azure DevOpsを使用していない場合に備え、他のソース管理プロバイダー*6も検討されています。2023年12から6ヶ月以内に大きな発表が予定されています。

また、XMLA Endpointの存在も忘れてはなりません。これはすべての顧客が必ずしも使用するものではありませんが、高度な開発を行う場合には推奨されています。APIの使用は一般的にシンプルなシナリオに適していますが、それだけでは大規模なシナリオに対処できないこともあるため、パフォーマンスの観点から、XMLA EndpointをTOM*7に対して使用すると、通常、増分更新が必要なシナリオで高速に処理できることがわかります。

もう一つ、セマンティックモデルに関する話ではありませんが、レポートレベルの定義言語（RDL: Report Definition Language）が開発されています。これはページ分割されたレポート（Paginated Report）用のRDL*8ではなく、Power BI Desktopで作成するインタラクティブなレポートのためのものです。pbipとして保存すると、ファイルが複数作成され、セマンティックモデル、メタデータ、レポートなどが分離された状態になり、Git統合がより容易になります。CI/CDに関連するシナリオでは、自動デプロイメントや自動テストなど、よりビジネスクリティカルなBI環境に対応できるようになります。Gitに対応したRDLの開発が進行中であり、最終的な目標は、開発者モード（pbipとして保存）のGA（一般提供）を目指しています。
参考🔗：Microsoft OneLake への接続（公式）

Q6: Direct Lakeのテクニカルアーキテクチャについて

質問: Direct LakeモードとImportモードについて、どのようなストレステストが行われてきたか？特にどのようなシナリオでパフォーマンスが低下するのか？複合モデル、その他の選択肢にしたほうが良いシナリオ等も教えてほしい。

回答: グランドルールとして、Direct LakeモードはImportモードとほぼ同じくらいパフォーマンスが良く、スケーラビリティもほぼ同じくらいということです。ImportモードはPower BI Premium P5の場合400GBまでですが、このサイズを超えるまではDirect Lakeモードとして機能するように開発されています。Fabricの最も大きなSKU（下記参考🔗）サイズ（F1024/F2048）は240億行（テーブルごとの行数）であり、DirectQueryにフォールバック*9する十分なデータ量と言えます。行数のカウントに加えて、SKUごとの利用可能なメモリも考慮する必要があります。P5の場合、400GBのデータをページングするため、240億行に達しなくてもこのしきい値を超える場合はDirectQueryにフォールバックします。例外として、Direct Lakeのようなシングルノードのテクノロジーが、例えば非常に良く最適化された数千のノードで構成されているシステムにおいては、DirectQueryモードよりもパフォーマンスが優れているとは言えないかもしれませんが、システムのデザインが重要になります。

最後に、大容量のデータにおいては、ParquetアーキテクチャのRow Groupが適切に設計されているかどうかも重要です。ソース側で少数の行で構成された多くのRow Group（下記参考🔗）が存在する場合、パフォーマンスに影響する可能性が高くなります。
Direct Lakeにおけるガードレール（Guardrails）は、DAXクエリの処理においてDirect LakeモードがDirectQueryモードへフォールバックする必要のあるリソース制限を定義しています。
参考🔗：Direct LakeのFallback条件

Q7: モデリングアーキテクチャについて

質問: Direct Lakeにおいて、DimとFactの数やJoinを行う回数によって影響されますか？

回答: Joinを行うとコストが発生し、クエリのパターンによって異なりますが、通常は「ご自身が今まで活用してきたインポートモードと同じやり方」を推奨しています（=スタースキーマを使用する）。なぜなら、Direct Lakeの処理エンジンはPower BIと同じものであり、Power BIの独自フォーマット（.abf = Analysis Services backup file）ではなく、Delta Parquetをストレージフォーマットとして使用し、Analysis Servicesエンジンで列圧縮フォーマットに対してクエリ処理を行っているからです。

*1:ユーザーインターフェースの略

*2:自社で保有し運用するシステムの利用形態やローカル環境等

*3:独自のフォーマットを採用しているデータベース等に対して、OneLakeへほぼリアルタイムに自動複製（レプリケーション）する機能。最初はAzure Cosmos DB, Azure SQL DB, Snowflake, Mongo DB等を有効にしていき、2024年にはOracleなど更に多くのソースを増やしていく予定

*4:分かりやすいデータ シリアライズ (serialize) 言語。設定ファイルの記述に使用されることが多く、あらゆるプログラミング言語に対応している。YAML はプログラマーにとっての使いやすさが重視されている

*5:日本語では「継続的インティグレーション/継続的デリバリー」と呼ばれている。 CI/CD は、アプリケーション開発の各ステージに自動化を導入し、顧客にアプリケーションを頻繁に提供できるようにする手法。Power BIの世界ではセマンティックモデル、レポートレベルで開発を継続的にチームコラボレーションを活用し、自動化を目指していく作業

*6:ソフトウェア開発において、コードやプロジェクトファイルなどのソースコードを保存、管理、追跡するためのツールやプラットフォームを提供する企業やサービス。Git、Subversion（SVN）、Mercurial、Microsoft Team Foundation Server（TFS）、Azure DevOpsなどがある

*7:Tabular Object Model

*8:Report Definition Language（レポート定義言語）の略称。レポート作成のためのXMLベースのファイル形式で、Microsoft SQL Server Reporting Services（SSRS）で使用される形式

*9:直訳すると”戻ってしまう”という意味。Direct Lakeが様々な制約条件によりDirectQueryのクエリパフォーマンスに戻ってしまうこと