Power BI Deep Dive [2026-08]

Power BI Deep Dive [2026-08] の資料です。

Transcript

1. SQL KQL Power Query の使い分け Power BI Deep Dive 2026–08
2. 本日のアジェンダ © 2026 Masatoshi Ohata 時間 内容 19:00 - 19:05 オープニング 19:05 - 19:45 本題 19:45 - 20:00 質問コーナー、アフタートーク
3. プロフィール 大畑 正利 (おおはた まさとし) Power BI Deep Dive 担当 エンドツーエンドのデータアーキテクトとして、 Microsoft Fabric を中心にデータ基盤構築から 分析・可視化、AI 活用までを一貫して担当。 © 2026 Masatoshi Ohata
4. 今日のゴール © 2026 Masatoshi Ohata • SQL / KQL / Dataflow Gen2 の役割の違いを理解する • データの性質や処理目的に応じて、適切な手段を選べるようにする • 「取得・整形・確認・探索・分析」のどこで使う機能なのかを整理する • 使える機能を増やすだけでなく、保守しやすい設計につなげる
5. 本日のアジェンダ © 2026 Masatoshi Ohata 時間 内容 19:00 - 19:05 イントロ 19:05 - 19:45 本題 19:45 - 20:00 質問コーナー、アフタートーク
6. データの「取得・整形・探索・分析」を目的別に選ぶ • Fabric では、同じデータに対して複数の処理手段を選択できる • 重要なのは「どの機能が優れているか」ではなく「どの目的に合っているか」 • 本資料では、SQL / KQL / Dataflow Gen2 を、実務で迷いやすい観点か ら整理する • 判断軸は、データの性質、処理目的、利用者、保守性、再利用性
7. ツール選定ではなく、処理の役割分担で考える • データを「どこで整えるか」を決める • 取り込み時 • 保存後 • 分析直前 • データを「誰が扱うか」を決める • 業務担当者 • BI担当者 • データエンジニア • 運用担当者 © 2026 Masatoshi Ohata • データを「何に使うか」を決める • レポート • データ品質確認 • 障害調査リ • アルタイム監視 • 再利用可能なデータ整備
8. 3つの位置づけ 区分 主な役割 SQL 構造化データの照会・集計・検証 KQL ログ・イベント・時系列データの探索 Dataflow Gen2 ローコード ETL・データ準備 © 2026 Masatoshi Ohata 向いている場面 Warehouse / Lakehouse / SQL endpoint のテーブル確認、集計、ビュー化 Eventhouse / KQL Database のリアルタイム 分析、監視、操作ログ分析 外部データの取得、クレンジング、結合、型変 換、宛先への読み込み
9. SQL を使う場面 構造化された業務データを、安定的に確認・集計する • 向いている用途 • 売上、予算、店舗、商品、日付などの構造化データの確認 • 集計、結合、フィルター、ビュー作成 • レポートやセマンティックモデルの前段確認 • データ品質チェック、件数確認、重複確認 • 判断ポイント • テーブル構造が明確か • 集計ロジックを再利用したいか • BI利用者やデータ担当者が読みやすい形で残したいか • 注意点 • Lakehouse の SQL analytics endpoint は読み取り中心の用途として考える • 更新・加工の主処理は、Spark、Dataflow、Pipeline などとの役割分担を考える © 2026 Masatoshi Ohata
10. KQL を使う場面 ログ・イベント・時系列データを、流れで探索する • 向いている用途 • ストリーミングデータ • 操作ログ、監査ログ、イベント履歴 • 時系列の傾向確認 • 障害調査、監視、アラート分析 • 判断ポイント • 時間条件で絞り込むことが多いか • 大量のイベントを高速に探索したいか • 「まず見る、絞る、集計する、並べる」という探索型の分析 か • 注意点 • 業務テーブルの定型集計をすべて KQL に寄せる必要はない • レポート用の整備済みデータとは役割を分ける © 2026 Masatoshi Ohata
11. Dataflow Gen2 を使う場面 業務データをローコードで取得・整形・読み込む • 向いている用途 • Excel、CSV、SharePoint、DB などからのデータ取得 • 型変換、列追加、結合、フィルター、不要列削除 • 業務担当者にも理解しやすいデータ整形 • 変換処理を再利用可能な形で管理 • Pipeline から実行する定期処理 • 判断ポイント • Power Query ベースで表現しやすい処理か • コードよりも画面操作・手順化を優先したいか • 複数のレポートやモデルで再利用したいか • 注意点 • 複雑な差分処理、大量データの高度な処理は Notebook や SQL も検討 • 宛先、更新方式、スキーマ変更の扱いを事前に決める © 2026 Masatoshi Ohata
12. 判断軸 迷ったときは5つの観点で決める 観点 データの性質 主な目的 利用者 SQL 構造化データ 照会・集計・検証 BI担当、データ担当 保守性 クエリとして管理しやすい 再利用性 ビュー・共通SQL化 © 2026 Masatoshi Ohata KQL Dataflow Gen2 ログ・イベント・時系列 外部データ・未整形データ 探索・監視・原因調査 取得・整形・読み込み 運用担当、分析担当 業務担当、BI担当、データ担当 調査クエリとして蓄積しや GUI手順として共有しやすい すい 調査テンプレート化 データ整備処理として再利用
13. 実務での使い分け例｜代表シナリオ別の選択 シナリオ 店舗売上と予算を店舗別・日付別に確 認する レポート更新前に件数や欠損を確認する 外部CSVを取り込み、列名・型・不要列 を整える SharePoint や Excel 由来の業務データ を定期取込する Pipeline 実行ログやイベント履歴を調査 する リアルタイムデータの傾向を確認する © 2026 Masatoshi Ohata 第一候補 理由 SQL 構造化データの結合・集計に向く SQL Dataflow Gen2 Dataflow Gen2 検証クエリとして残しやすい KQL 時間軸での絞り込み・探索に向く KQL Eventhouse / KQL Database と相性がよい Power Query ベースで整形しやすい ローコードで取得・変換・宛先設定がしやすい
14. 使えるから使う、ではなく、保守できる形で選ぶ • 避けたいパターン • Dataflow Gen2 に複雑すぎる業務ロジックを詰め込む • SQL でログ・イベント分析を無理に行う • KQL で通常の業務集計を過度に実装する • 同じ変換処理を Dataflow、SQL、Notebook に重複して持つ • 一時調査クエリと本番処理の境界が曖昧になる • 望ましい考え方 • 取得・整形・保存・検証・分析の責務を分ける • 本番利用する変換は再利用可能な場所に寄せる • 調査用と運用用の処理を分けて管理する © 2026 Masatoshi Ohata
15. まとめ : 使い分けの結論 • SQL • 構造化された業務データの確認・ 集計・検証に使う • KQL • ログ、イベント、時系列、リアルタ イムデータの探索に使 • Dataflow Gen2 • データの取得、整形、読み込みを ローコードで実装する © 2026 Masatoshi Ohata • 判断基準 • データの性質 • 処理の目的 • 利用者のスキル • 保守性 • 再利用性 • 結論 • 「何をしたいか」から逆算して選ぶ • 取得・整形・分析・監視を同じ手段に 寄せすぎない
16. 本日のアジェンダ © 2026 Masatoshi Ohata 時間 内容 19:00 - 19:05 イントロ 19:05 - 19:45 本題 19:45 - 20:00 質問コーナー、アフタートーク