[4] Power BI Deep Dive [2026-05]

PBI Deep Dive 2026-05 の資料です。

Transcript

1. Power BI Deep Dive 2026–05 Direct Lake を選ぶ「基準」
2. 円滑な進行のため、ご質問時を除きマイクはオフしてください。 • 資料は後日、Connpass の本イベントページにアップロードします。 • 本セッションは 録画していますが、アーカイブ公開は行いません（運営の記録用です）。 内容に関する注意 • 本シリーズ「Power BI Deep Dive Power Series」では、Fabric × Power BI を中心に取り上げます。 • 一部、プレビュー版／提供前の機能を取り上げる場合があります。 • 内容については 正確性・有用性に配慮していますが、すべてを保証するものではありません。 • 本勉強会での説明や見解は、私個人のものであり、所属する組織・団体を代表するものではありません。 導入時のお願い • 自社環境へ導入する際は、テスト環境での事前検証を行い、最新の公式ドキュメントの確認に加えて、 Microsoft の営業・サポート窓口や担当ベンダーと相談しながら進めてください。 • 本内容を参考にしたことによって問題が生じた場合でも、責任は負いかねますのでご了承ください。 本勉強会ご参加にあたってのご案内 © 2026 Masatoshi Ohata
3. 本日のアジェンダ 時間 内容 19:00 - 19:05 イントロ 19:05 - 19:45 本題 19:45 - 20:00 質問コーナー、アフタートーク © 2026 Masatoshi Ohata
4. プロフィール 大畑 正利 (おおはた まさとし) エンドツーエンドのデータアーキテクトとして、 Microsoft Fabric を中心にデータ基盤構築 から分析・可視化、AI 活用までを一貫して担当。 © 2026 Masatoshi Ohata Power BI Deep Dive 担当
5. 今日のゴール © 2026 Masatoshi Ohata • Direct Lake を使うべき状況を判断できる • Direct Lake を避けるべき状況も理解できる • Import / DirectQuery / Direct Lake の 位置づけを整理できる
6. 本日のアジェンダ 時間 内容 19:00 - 19:05 イントロ 19:05 - 19:45 本題 19:45 - 20:00 質問コーナー、アフタートーク © 2026 Masatoshi Ohata
7. • Import / DirectQuery / Direct Lake の使い分けのラインが分かりにくい • “どれを選ぶべきか”が現場で迷いやすい • データ量・鮮度・性能・運用コストがトレードオフになる • Fabric 時代は Lakehouse 中心の設計が増え、判断がさらに複雑化 • → Direct Lake を選ぶ基準を体系化する必要がある なぜ Direct Lake の“使いどころ”が難しいのか？ © 2026 Masatoshi Ohata
8. • 不必要な Import リフレッシュが消え、運用コストが下がる • DirectQuery の性能問題から解放される • Lakehouse のデータを“そのまま”高速に活用できる • モデル設計がシンプルになり、保守性が上がる • アーキテクチャ全体が Fabric ネイティブで統一される • → データ基盤と BI の一体化が進む Direct Lake を正しく選べると何が変わる？ © 2026 Masatoshi Ohata
9. Direct Lake が必要になるのは、 「鮮度・性能・運用コスト」を同時に満たしたい時。 • Import ではサイズや更新が限界 • DirectQuery では性能や機能制約が厳しい • → そのギャップを埋めるのが Direct Lake 今日の結論 © 2026 Masatoshi Ohata
10. • 大量データを高速に扱いたい • 更新処理やデータ移動を極力なくしたい • DirectQuery の制限を避けつつ最新データを使いたい • Fabric ネイティブの Lakehouse 中心で設計したい • → 三つ巴の最適化が必要な時に Direct Lake が効く Direct Lake が必要になる典型状況 © 2026 Masatoshi Ohata
11. 3つのストレージモード Import • Power BI にデータを保存 • すべての変換が可能 • データの更新が必要 DirectQuery • ソースに都度問い合わせ • 変換は限定的 • 常に最新だが性能はソース依存 Direct Lake • Onelake Delta を直接参照 • 変換は限定的（フォールバックあり） • 更新不要・高速 コンポジットはストレージモードを組み合わせます
12. • OneLake 上の Delta テーブルを直接読む • データ移動なし・更新なし • Import と DirectQuery の “いいとこ取り” • ただし フォールバック がある点は重要 Direct Lake の本質 © 2026 Masatoshi Ohata
13. 大量データ × 高速応答 • Import：サイズ・更新が厳しい • DirectQuery：性能が出ない • → Direct Lake が最適 Direct Lake が必要になるシナリオ① © 2026 Masatoshi Ohata
14. 更新処理を極力なくしたい • 毎日・毎時のリフレッシュが負担 • 運用コストを下げたい • → Direct Lake は更新不要 Direct Lake が必要になるシナリオ② © 2026 Masatoshi Ohata
15. Fabric ネイティブで統一したい • Lakehouse 中心のアーキテクチャ • Delta テーブルをそのまま BI に使いたい • → Direct Lake が最も自然 Direct Lake が必要になるシナリオ③ © 2026 Masatoshi Ohata
16. 複数の Lakehouse / Warehouse を 1 モデルで 扱いたい • エンタープライズ規模の統合 • Import のようなコピーを避けたい • → Direct Lake の柔軟性が活きる Direct Lake が必要になるシナリオ⑤ © 2026 Masatoshi Ohata
17. • Delta で管理されていないデータ • SQL Endpoint 経由でフォールバックが頻発 • モデル側で高度な変換をしたい（Import が向く） • 外部データソース中心（DirectQueryが自然） Direct Lake を使うべきでないケース © 2026 Masatoshi Ohata
18. • Desktop（プレビュー）はフォールバックしにく • いSQL Endpoint はフォールバックしやすい • 未サポート機能を使うと DirectQuery に切り替わ る • → どのテーブルがどのソースを参照しているか把握 が重要 フォールバックの注意点 © 2026 Masatoshi Ohata
19. • データ量 • 鮮度要求 • 性能要求 • 運用コスト • アーキテクチャ整合性 • フォールバック許容度 → この 6 軸で “Direct Lake を使うべきか” を判断で きる まとめ：Direct Lake を選ぶ判断軸（6 つ） © 2026 Masatoshi Ohata
20. Semantic models｜ストレージ形式の判断軸 判断軸 要件・条件 適したストレージ形式 ① データ規模 小〜中規模 Import 大規模・今後も増加前提 Direct Lake / Composite ② 鮮度要件 バッチ更新で問題なし Import ほぼリアルタイムが必要 Direct Lake / DirectQuery ③ パフォーマンスと制御 高速・安定性を最優先 Import / Direct Lake ソース側制御・既存DB運用を優先 DirectQuery ④ エンタープライズ運用 再利用・標準化を重視 Direct Lake 段階移行・方式混在が必要 Composite
21. Direct Lake の2つの接続先 • Direct Lake on OneLake • OneLake 上の Delta テーブルを直接参照 • データ移動やリフレッシュ不要 • シンプルで高速な構成 • Fabric ネイティブな Lakehouse 中心の設計に適 する • Direct Lake on SQL Endpoint • SQL Endpoint 経由で Delta テーブルを参照 • SQL ベースの既存運用やツールと親和性が高い • 一部機能や操作でフォールバックが発生しやすい • SQL 主体の分析・移行シナリオに適する 設計上の注意点  接続先によって DirectQuery への フォールバック挙動が変わる  パフォーマンスと機能制限の理解が必 須 on OneLake / on SQL Endpoint
22. Direct Lake のベストプラクティス • 変換は上流で行い、Delta テーブルを 最終形に 近い状態で具体化 • SQL Endpoint や未サポート機能の利用を避け、 DirectQuery へのフォールバックを防止 • 必要な行・列のみ を含め、高カーディナリティ列 や不要な列を排除 • 整数キー・列指向・適切なパーティションなど、最 適なデータ型と構造 を採用 • Auto Optimize やファイルサイズ調整など、 Delta テーブルの最適化を徹底 Direct Lake
23. • Lakehouse に Delta テーブルを準備 • Tables から新しいセマンティックモデルを作 • 成フォールバックを避ける設計にする （計算列・外部ソース・SQL Endpoint を避ける） Direct Lake の作成方法（3 ステップ）
24. • 計算列は使用不可（フォールバックの原因） • 複雑な DAX（X 系 / FILTER など）は注意 • 外部ソースとの結合は不可 • SQL Endpoint 経由の参照はフォールバック Direct Lake を維持するための注意点 © 2026 Masatoshi Ohata
25. 本日のアジェンダ 時間 内容 19:00 - 19:05 イントロ 19:05 - 19:45 本題 19:45 - 20:00 質問コーナー、アフタートーク © 2026 Masatoshi Ohata
26. 2026-06-14（日） 19:00～20:00 次回の日程(予定)
27. 日付 テーマ May 7 Microsoft Fabric を使用したいですか? May 12 認定取得: Fabric Data Engineer (DP-700 Accelerated) May 19 認定取得: Fabric Analytics Engineer (DP-600 Accelerated) https://aka.ms/fabric/japanese 認定取得: Microsoft Fabric