Microsoft Fabric 攻略ガイド 2.0 (ドラフト)

Microsoft Fabric 全体像まで

2025/09/08: データ蓄積の章を更新

Transcript

1. Microsoft Fabric 攻略ガイド 2.0版 2025.xx.xx Microsoft MVP for Data Platform 永田 亮磨 (ZEAL CORPORATION) X: @ryomaru0825 Linkedin: ryoma-nagata-0825 Qiita: ryoma-nagata ドラフト
2. 目次 1. はじめに 2. データ活用基盤の全体像 3. Microsoft Fabric について 4. データ管理機能 1. データ蓄積 2. データ処理 5. ユースケース 1. データレイク・DWH 2. BI 3. データサイエンス 4. リアルタイム 5. AI 6. 基盤管理  インフラストラクチャー：Microsoft Fabric について  ガバナンス  コスト・パフォーマンス最適化  CICD 7. 学習リソース  MS Learn  Tech Blog  公式ドキュメント  GitHub サンプル  コミュニティ  製品ロードマップ
3. 1. はじめに
4. 本書の位置づけ  本書は、Microsoft Fabric を対象に、データ分析基盤を構成するための機能に ついて利用指針を記載するものです。  記載内容は筆者の調査に基づいた発行日時点の情報となっています  本書で記載する方法論は、一般的な状況や筆者の理解に基づいて指針を示すものであり、あり方を強制す るものではありません
5. 本書の対象読者 ロール名 概要 特に関連の深い章 データガバナンス責任者 データ資産の把握、推進 5.基盤管理（ガバナンス） プラットフォーム管理者 容量・ワークスペース・ネットワーク管理 5.基盤管理（インフラ） データスチュワード ドメイン管理、ポリシー統制 5.基盤管理（ガバナンス） プロダクト管理者 データ資産運用責任 5.基盤管理（ガバナンス、コスト最適化,CICD） データエンジニア DWH/ETL/パイプライン開発 3.基盤機能、4.ユースケース データサイエンティスト 機械学習モデル開発 3.基盤機能、4.ユースケース（AI/DS） BIモデラー BIモデル設計 3.基盤機能、4.ユースケース（BI） レポート開発者 レポート作成 4.ユースケース（BI） データ利用者 公開データの活用 4.ユースケース  本書はデータ分析基盤に関わる多様な立場の読者を想定しています。 以下は各ロールごとに、特に参考になる章を示したものです。 ご自身の役割に合わせて参照すると効率的に読み進められます。
6. 2. データ活用基盤の全体像
7. データ分析基盤が目指すデータ資産の価値昇華 データ分析基盤はデータを価値ある資産に昇華するプロセスを推進する  データの価値昇華の流れは一般に DIKW モデルで表現される。  データ：事実の収集（センサー、取引、ログなどデータそのもの）  情報（Information）：整理され意味をもったデータ（集計、分類、可視化など計測できる状態）  知識（Knowledge）：知見の獲得（モデル化、予測、相関分析などでデータの背景、関連性がわかった状態）  知恵（Wisdom）：意思決定と実行（ビジネスアクション、改善サイクルを回せる状態） データ 情報 知識 知恵 データ分析基盤
8. データの昇華と役割と課題  データの昇華過程では複数の専門スキルが必要とされ、多様なロールが参画する  それぞれがデータ分析基盤を通じてつながり、共創する  知恵を生むためのビジネスユーザーの依頼に応える、消費者と生産者が分断した構造  少人数で構成されるハイスキルなロールに負担が集中 データ 情報 知識 知恵 アナリスト/データサイエンティスト 分析/解析の専門家 ビジネスユーザー 洞察をビジネスアクションへ データエンジニア データ整備の専門家 関与範囲 ロール 負担が集中する ビジネス知識の重要度
9. セルフサービスの重要性  現代のデータ分析基盤では、ビジネスユーザーがデータ資産を知恵として消費するだけで はなく、 「昇華のプロセスに直接参画し、セルフサービスで試行錯誤」することにより、迅速性と 確実性を向上させることが期待されている  価値ある知恵を生み出すためのプロセスであるほど、「ビジネス現場の知識」が重要なため効果大 データ 情報 知識 知恵 アナリスト/データサイエンティスト 分析/解析の専門家 ビジネスユーザー 洞察をビジネスアクションへ データエンジニア データ整備の専門家 ビジネス知識の重要度 関与範囲 ロール データ分析基盤を活用したセルフサービスにより情報生成に踏み込む
10. データ整備なきセルフサービスの落とし穴 https://docs.microsoft.com/ja-jp/power-bi/guidance/center-of-excellence-microsoft-business- intelligence-transformation  一貫性の欠如  国や、個社、部署ごとに独自の考え 方で売上を計上する 「税別？税込？年間契約は月次 で按分？」  再利用されないデータ  アナリストが分析ではなく整理・収 集に時間を消費 「各アナリストが個別で集約を行い、 ロジックが組織全体で利用されな い」
11. 公式データの整備活動とセルフサービスデータ活用の両輪  「正しい公式データの整備」×「セルフサービスでの活用」 を両輪で回す  公式データの整備により 一貫性・再利用性・信頼性 を担保  セルフサービスの活用により 迅速な試行錯誤・現場での知恵の獲得 が可能  現場で得られた知恵を組織全体で共有し、再利用可能な資産として蓄積  活用と整備が循環することで継続的にデータ資産の価値が強化される 情報を探索し、 知見を生成 知見からアクションへ （知恵） 公式データや 公式の情報の生成 セルフサービスの価値実証 データの特定と取得 現場の知恵を個人レベルで終わらせず、 組織全体で共有・再利用可能なデータ資産に昇華させる データ活用 データ整備 正しいデータでの 改善サイクル
12. データ分析基盤 データ分析基盤の全体像  データ分析基盤は、正しいデータの整備とセルフサービスによる活用を両立させ、 組織全体で価値ある知見を継続的に創出する。その全体像を以下に示す。 データソース 打ち手・施策
13. データ分析基盤 データ分析基盤の全体像  データ分析基盤は、正しいデータの整備とセルフサービスによる活用を両立させ、 組織全体で価値ある知見を継続的に創出する。その全体像を以下に示す。 データソース 打ち手・施策 データ活用 データ整備 DWH・データレイク BI データサイエンス AI リアルタイム プラットフォームサービス（インフラストラクチャー / ガバナンス etc.) データ処理 データ蓄積 ユースケース データ管理基能
14. 3. Microsoft Fabric について
15. データ分析基盤 Microsoft Fabric によるデータ分析基盤の実現  本書ではデータ分析基盤に Microsoft Fabric を採用する  Microsoft Fabric は分析における全ての機能を一貫して提供する総合サービスである データソース 打ち手・施策 データ活用 データ整備 DWH・データレイク BI データサイエンス AI リアルタイム プラットフォームサービス（インフラストラクチャー / ガバナンス etc.) データ処理 データ蓄積 ユースケース データ管理基能
16. Microsoft Fabric AI 時代の統合データプラットフォーム Databases Real-Time Intelligence Power BI Data Factory Analytics OneLake Governance AI Fabric Platform
17. Microsoft Fabric AI 時代の統合データプラットフォーム Databases Real-Time Intelligence Power BI Data Factory Analytics OneLake Governance AI Fabric Platform
18. 全てのデータ活用を支援する Microsoft Fabric ワークロード  「Data Factory」 などの名称を指す  ワークロードには個々のコンセプトがあり、 組織内の様々なロールに合わせてカスタマイズされたソリューション、ツールが提供 される
19. アイテム（項目）  アイテムは Fabric 上での開発成果物そのものとなるリソースである  名前を決めるだけで作成することができ、数クリックで開発作業に取り掛かること ができる 処理内容などの設定 目的に応じたアイテムを作成
20. ワークスペース ワークスペース ワークスペース アイテムを管理し、同僚と共同作業する ための環境となるリソース Fabric の管理における基本単位であり、 開発に関わるロールベースのアクセス制御 が提供される ワークスペースロールによるアクセス制御 管理者 メンバー 共同作成者 ビューワー ワークスペース Microsoft Fabric Workspaces - Microsoft Fabric | Microsoft Learn アイテム一覧
21. パイプライン データフロー Gen2 レイクハウス ウェアハウス Apache Airflow ジョブ ノートブック Graph QL 用 API ミラーリング 環境 SQL DB Microsoft Fabric ワークロードとアイテムの整理 Data Factory Data Engineering Data Warehousing Databases 実験/ MLモデル データエージェント Python/Spark ノートブック 環境 Data Science セマンティックモデル レポート イベントストリーム アクティベーター リアルタイム ダッシュボード ページ分割レポート イベントハウス 組織アプリ Power BI Real-time Intelligence データ統合 様々なロケーションにある データシステムをターゲット にして、データを収集・準 備・変換する データエンジニアリング 多様なデータをレイクハウ スに集約し、Apache Spark で大規模処理を 行う データサイエンス 市民データサイエンティス トを中心に、AI や機械 学習でデータを強化・活 用する データウェアハウス 大規模データを Fabric 上に蓄積またはミラーし、 T-SQL で効率的に分 析する リアルタイムデータ活用 時系列データを蓄積・処 理し、リアルタイムの監視 やビジネスアクション連携 を実現する 運用データベース 運用アプリケーションに最 適化されたリレーショナル ／NoSQL データベースを 構築する ビジネスインテリジェンス 組織全体で分析モデルと ビジュアルを共有し、デー タ探索と意思決定を迅 速化する コピージョブ Microsoft Fabric ドキュメントの Data Engineering - Microsoft Fabric | Microsoft Learn Fabric データ ウェアハウス - Microsoft Fabric | Microsoft Learn Microsoft Fabric のドキュメントのリ アルタイムインテリジェンス - Microsoft Fabric | Microsoft Learn Microsoft Fabric の Data Factory のドキュメント - Microsoft Fabric | Microsoft Learn Power BI ドキュメント - Power BI | Microsoft Learn Microsoft Fabric のデータベース - Microsoft Fabric | Microsoft Learn Microsoft Fabric Data Science のドキュメント - Microsoft Fabric | Microsoft Learn Cosmos DB コンセプト 主なアイテム ワークロード
22. Data Factory 様々なロケーションにあるデータシステムをターゲットにして、 データを収集・準備・変換する 多様な処理をまとめて実行するワークフローを構築 データフロー Gen2 パイプライン Power Query ベースのローコードで、 データの抽出・変換・登録を実行 Dataflow Gen2 とは - Microsoft Fabric | Microsoft Learn Data pipelines - Microsoft Fabric | Microsoft Learn
23. Data Factory 様々なロケーションにあるデータシステムをターゲットにして、 データを収集・準備・変換する 複雑なデータワークフローをプログラムで作成・管理できる Apache Airflow 環境 Apache Airflow ジョブ プレビュー コピージョブ パイプライン不要で、ガイド付きの操作でソースから コピー先へデータを簡単に移動 Apache Airflow ジョブとは - Microsoft Fabric | Microsoft Learn コピー ジョブとは - Microsoft Fabric | Microsoft Learn
24. OneLake へのデータ統合  Data Factoryは170 以上のデータソースに接続可能し、データを物理的に統合 可能 Data Factory OneLake
25. Data Engineering 多様なデータをレイクハウスに集約し、 Apache Spark で大規模処理を行う 構造化／非構造化データを統合的に格納・管理できる レイクハウスアーキテクチャ レイクハウス Apache Spark による並列分散データ処理を ノートブック形式で実行する ※データサイエンスワークロードのノートブックと同一 ノートブック ノートブックの開発、実行、管理 - Microsoft Fabric | Microsoft Learn レイクハウスとは - Microsoft Fabric | Microsoft Learn
26. Data Engineering 多様なデータをレイクハウスに集約し、 Apache Spark で大規模処理を行う ノートブック実行用のランタイムとライブラリセットを管理する 環境 アプリケーションが効率的にデータにアクセスするための GraphQL API エンドポイントを提供 ※データサイエンスワークロードの環境と同一 GraphQL 用 API Fabric で環境を作成、構成、使用する - Microsoft Fabric | Microsoft Learn GraphQL 用の Microsoft Fabric APIとは - Microsoft Fabric | Microsoft Learn
27. Data Warehouse 大規模データを Fabric 上に蓄積またはミラーし、 T-SQL で効率的に分析する 高性能な T-SQL エンジンで構造化データを効率的に分析 ウェアハウス 外部 DB （Cosmos DB / Azure SQL / Snowflake 等）を ETL なしで Fabric にレプリケーションし、分析に活用 ミラーリング ミラーリング - Microsoft Fabric | Microsoft Learn Microsoft Fabric のデータ ウェアハウスとは？ - Microsoft Fabric | Microsoft Learn
28. Microsoft Fabric ミラーリング  様々な外部データシステムのデータに対するニアリアルタイム分析を実現する カスタマー 360 ファイナンス サービス テレメトリー ビジネス KPI Data Factory Synapse Data Engineering Synapse Data Science Synapse Data Warehousing Real-time Intelligence Power BI Data Activator Snowflake Open Mirroring For Partner eco systems Azure Cosmos DB Azure Databricks Unity Catalog Azure SQL Database …and more Fabric ミラーリングにより、既存のデータベースや データウェアハウスをETLなしでFabricに追加 データは Delta 形式で OneLake に複製され、 ほぼリアルタイムで最新の状態に保たれます。 OneLake上に作成されたレプリカは Fabric による 全てのデータ分析に利用でき、ソースデータベースに 分析の負荷を与えることはない
29. Data Science 市民データサイエンティストを中心に、 AI や機械学習でデータを強化・活用する 実験・モデル 機械学習の実験を管理し、モデルを記録・評価・追跡する GUI 付きノートブックでデータ探索や ML モデルの構築・管理を実行し、データを強化 ※データエンジニアリングワークロードのノートブックと同一 ノートブック Machine Learning の実験 - Microsoft Fabric | Microsoft Learn Machine learning model - Microsoft Fabric | Microsoft Learn ノートブックの開発、実行、管理 - Microsoft Fabric | Microsoft Learn
30. Data Science 市民データサイエンティストを中心に、 AI や機械学習でデータを強化・活用する データエージェント Fabric 上の構造化データに対し、 質問から自動でクエリを生成して回答する AI エージェント プレビュー Fabric データ エージェントの作成 (プレビュー) - Learn how to create a Fabric data agent | Microsoft Learn
31. Databases 運用アプリケーションに最適化された リレーショナル／NoSQL データベースを構築する SQL DB Cosmos DB 運用アプリケーション向けのフルマネージドなリレーショナルデータベース グローバル分散型の低レイテンシ NoSQL データベース Cosmos DB データベース プレビュー - Microsoft Fabric | Microsoft Learn SQL データベースの概要 (プレビュー) - Microsoft Fabric | Microsoft Learn プレビュー プレビュー
32. Real-Time Intelligence 時系列データを蓄積・処理し、 リアルタイムの監視やビジネスアクション連携を実現する 数秒以内で時系列データを分析できる リアルタイム分析エンジン イベントストリーム イベントハウス ローコードでストリームデータを処理し、 任意のデータストアへルーティングする
33. Real-Time Intelligence 時系列データを蓄積・処理し、 リアルタイムの監視やビジネスアクション連携を実現する アクティベーター データ検知ルールにより、 アラートやワークフローを即時に実行 リアルタイムダッシュボード イベントハウスで得られたリアルタイムクエリ結果を視覚化
34. Power BI 組織全体で分析モデルとビジュアルを共有し、 データ探索と意思決定を迅速化する メジャーやリレーションシップを定義し、 意味づけされた分析モデルを構築する レポート セマンティックモデル 多彩なビジュアルと AI インサイトによる対話型レポート https://learn.microsoft.com/ja-jp/fabric/real-time- analytics/media/real-time-analytics-overview/product- view.png#lightbox
35. Power BI 組織全体で分析モデルとビジュアルを共有し、 データ探索と意思決定を迅速化する PDF・Excel 出力や印刷に最適化されたページ形式のレポート ページ分割レポート
36. Microsoft Fabric AI 時代の統合データプラットフォーム Databases Real-Time Intelligence Power BI Data Factory Analytics OneLake Governance AI Fabric Platform
37. Microsoft Fabric AI 時代の統合データプラットフォーム Databases Real-Time Intelligence Power BI Data Factory Analytics OneLake Governance AI Fabric Platform
38. OneLake  組織全体で共有される 1 つのデータレイク (OneDrive for Data)  Fabric に標準で備わり、ワークスペース - アイテム - テーブル・・・のようにフォルダ分割  全ワークロードのデータは自動で OneLake に保存 ｘOneLake、データ用の OneDrive - Microsoft Fabric | Microsoft Learn 構造化／非構造化データを保存可能 構造化データは Delta-Parquet 形式で統一保存 ストレージと計算を分離、任意のエンジンで相互処 理
39. OneLake の特徴  OneCopy: データコピーは一度きり。どのエンジンからも再利用可能  冗長コピーをなくし、ストレージコスト削減とデータの一貫性を実現 カスタマー 360 オンプレミス クラウド データソース コピー （一度だけ） T-SQL エンジン 分析・変換 Data Factory エンジン Microsoft Fabric Power BI エンジン 可視化 (No コピー)
40. OneLake の特徴  OneCopy: データコピーは一度きり。どのエンジンからも再利用可能  ショートカットにより既存のデータ資産をリンクを張るように簡単に再利用 カスタマー 360 ワークスペース オンプレミス クラウド データソース コピー （一度だけ） T-SQL エンジン 分析・変換 Data Factory エンジン Microsoft Fabric Power BI エンジン 可視化 (No コピー) Python(Pyspark) エンジン ファイナンス ワークスペース 解析 既存のデータレイク ショートカット (Noコピー) 既存のデータ資産を そのまま参照可能 ショートカット (Noコピー)
41. OneLake の特徴  オープンアクセス：既存の ADLS Gen2 ツール・サービスがそのまま使える  ADLS Gen2（DFS API） に対応した多くのサービスが OneLake にアクセス可能 Azure Databricks データ活用サービス Azure AI Studio Snowflake Azure Data Factory クライアントツール Azure Storage Explorer PowerShell SDK OneLake File Explorer Microsoft 以外もOK
42. OneLake の特徴  オープンフォーマット：標準規格でサイロ化を防止  ベンダーフリーな Delta Lake 形式を採用することで、将来のクラウド移行やマルチクラウド戦略にも対応可能 ファイナンス 非構造化データ 構造化データ （Delta Parquet） Home | Delta Lake  データは2種類のフォルダで管理 - Tables（構造化データ） : Delta Lake 形式専用のフォルダ - Files： 非構造化データを含むあらゆるデータ用フォルダ  独自拡張「Delta Parquet」  独自のエンコーディング技術(V-Order) によりクエリ性能を 向上
43. Delta Lake  Databricks 社が開発したオープンテーブルフォーマット オープンかつシンプル  ベンダーロックインなく、あらゆるツールからアクセ ス可能  SQL/Python 双方での共通データアクセス  統一されたバッチ、ストリーミング DWHとデータレイクのいいとこどり  高速なクエリ  タイムトラベル機能による過去データの遡り  スキーマの自動拡張 or 強制  構造化～非構造化データに対応しつつ高い圧縮率 Home | Delta Lake コンプライアンス対応  監査履歴  UPDATE, DELETEによるデータ操作
44. オープンテーブルフォーマット Iceberg にも対応  OneLake は別の業界標準オープンテーブルフォーマットである、「Iceberg」との互換性 も実現  OneLake に保存された DeltaLake テーブルは Iceberg としても読取可能  New in OneLake: Access your Delta Lake tables as Iceberg automatically (Preview) | Microsoft Fabric ブログ | Microsoft Fabric  OneLake に保存された Iceberg テーブルは Delta Lakeとして読取可能  OneLake で Iceberg テーブルを使用する - Microsoft Fabric | Microsoft Learn  「Databricks は Delta Lake が標準」、「Snowflake は Iceberg を選択可能」である ため、主要なデータ分析プラットフォームとの高度な相互運用性を実現可能 Iceberg OneLake Delta Lake Databricks Microsoft Fabric Snowflake 双方のフォーマットを 自動生成
45. 補足）Delta Lake と Iceberg の概要比較  一般に OTF 市場内では機能の大きな相違はなく、成熟度や牽引するベンダーエコシステムが 現在の比較ポイントとなる Linux Foundation コミュニティ Apache Foundation Spark の開発者 *Spark の開発者によりDatabricks が設立される 開発元 Netflixのエンジニア *Iceberg 創設者による企業 Tabular は Databricks に買 収済 カタログレイヤー：任意 メタデータレイヤー：delta_log データレイヤー：Parquet コンポーネント カタログレイヤー：Polaris Rest Catalog などを要する メタデータレイヤー：manifest file データレイヤー：Parquet, ORC, Avro Spark に特化 エンジン親和性 多エンジン（Spark, Flink, Trino 等） Databricks が牽引（現在 4.0 preview） ベンダーエコシステム 中立（現在1.81） Databricks 、Fabric OneLake など プラットフォームの ネイティブサポート Snowflake, Dremio, AWS Athena, Starburst など
46. すべてのワークロードに組み込まれた Copilot 機能による開発支援 すべてのユーザーが自然言語でデータ活用できる世界へ Data Factory データ統合・準備 Data Warehouse T-SQL クエリ Data Science Python ノートブック開発 Power BI モデル・レポート 開発 Real-Time Intelligence KQL クエリ
47. AI ドリブンな洞察の取得  Power BI レポートとモデルのための Copilot  AI向けに準備されたセマンティックモデルをもとに、自然言語で「レポートを要約して」と指示すれば、主要な傾向や異 常値を自動で抽出可能。  DAXや統計の専門知識がなくても、レポートやデータに関する質問を補助的にサポートし、AIがビジネスインサイトの発 見を支援。 Power BI レポートとセマンティック モデルで Copilot を使用する - Power BI | Microsoft Learn プレビュー
48. AI ドリブンな洞察の取得  スタンドアロン Copilot  ホーム画面から直接アクセスでき、データ探索の最初の入口として利用可能  自然言語でデータに関する質問を投げかけ、関連レポートやセマンティックモデルを横断的に検索・要約  「部門別の売上レポートを探して」「このレポートを要約して」など、探索・要約・質問 を 1 つの入口から実行 Power BI でのスタンドアロン Copilot エクスペリエンス (プレビュー) - Power BI | Microsoft Learn プレビュー
49. 組み込みのガバナンス機能  OneLake カタログ  全データを横断検索：Fabric 上のあらゆるデータを単一ビューで発見  統制と運用を簡潔に：アクセス権やタグ付けなどの設定に素早く移動 OneLake カタログの概要 - Microsoft Fabric | Microsoft Learn
50. 組み込みのガバナンス機能  OneLake カタログ （管理タブ）  データ資産のガバナンス状況を見える化  改善が必要なポイントを分析し、推奨アクションを提示 データ資産の分析情報 データ資産の概要 ガバナンス改善に推奨されるアクション OneLake カタログを使用して Fabric データを管理する - Microsoft Fabric | Microsoft Learn
51. データ活用者にとってのデータ資産価値向上支援  ドメイン - Microsoft Fabric | Microsoft Learn  ワークスペースを論理的に分類し、必要なデータ資産に素早くアクセス  承認（エンドースメント）の概要 – Microsoft Fabric | Microsoft Learn  信頼できるデータを「公式」として認定し、安心して再利用可能に  Fabric のタグ  追加のメタデータで検索性・発見性を向上させ、データ探索を効率化
52. Microsoft Purview と連携したデータガバナンスの強化 Purview の機能を活用することで、安心して使えるデータ活用環境を整備する  How can I decide which protection method to use to protect my sensitive data in Fabric? | Microsoft Fabric Blog | Microsoft Fabric  データ損失防止(DLP)について | Microsoft Learn  機密データが不適切に共有されないように検知・アラート  Microsoft Fabric の保護ポリシー - Microsoft Fabric | Microsoft Learn  秘密度ラベルと連動し、許可されていないユーザーやグループのアクセスを制御  秘密度ラベルはアイテムだけでなく、ドメインの既定として紐づけが可能 DLP（データ損失防止）ポリシーへの違反時にアラート Microsoft Purview 秘密度ラベル × データ損失保護でファイルの外部共有を監 視統制する #DLP - Qiita Microsoft Fabric で秘密度ラベルを適用する②保護ポリシーによりシ ステム管理者からのデータアクセスをブロックする #MicrosoftFabric - Qiita 保護ポリシーで許可されていないユーザーに対して制限
53. データメッシュアーキテクチャにネイティブ対応する  単一のプラットフォームガバナンスで、「全てのデータ活用ワークロード」を実行し、コラボレーションを促進  OneLake による組織全体で共有可能な 「唯一のコピー」 を保持  ドメインごとのポリシーに調整可能な 「委任型ガバナンス」（タグ / 秘密度ラベル / エンドースメント）を実現 Databases Real-Time Intelligence Power BI Data Factory Analytics OneLake Governance AI Domain Domain Domain Domain Domain Domain
54. データ分析基盤 Microsoft Fabric によるデータ分析基盤の実現  Fabric の各サービスは、データ分析基盤の要素に当てはめて整理できる。  以降の章では、この整理を軸に Fabric の活用方法を紹介する。 データソース 打ち手・施策 データ活用 データ整備 DWH・データレイク BI データサイエンス AI リアルタイム プラットフォームサービス（インフラストラクチャー / ガバナンス etc.) データ処理 データ蓄積 ユースケース データ管理基能
55. 4. データ蓄積
56. データ分析基盤 データ蓄積での整理ポイント  データストア：どこになにを格納するか  データモデリング：どのようにデータを表現するか データソース 打ち手・施策 データ活用 データ整備 プラットフォームサービス（インフラストラクチャー / ガバナンス etc.) データ処理 データ蓄積 ユースケース データ管理基能 データストア データモデリング
57. データストア
58. 格納するデータの種類について  データストアについて考えるにあたり本書でのデータの種類について以下のような 前提で用語を使用する  参考：What is Data? | IBM # 種類 説明 例 1 構造化データ 厳密かつ明確なデータ構造（列定義）が存在したうえでテー ブル形式で整理されている。 RDB 上のデータ, parquet,avroなどのファイル 2 半構造化データ タグや、データ内のメタデータによりデータ構造を部分的に識別 でき、可変的なスキーマをもつ JSON,CSV,XML,Excel 3 非構造化データ フォーマットが決まっておらず、解析には個別の特別な処理が 必要 テキスト、画像、動画
59. データストアの種類  データを保存する場所として、データストアの一般的な種類は以下のように整理さ れる  それぞれの代表例に示されるデータストアは複数の種類のデータストアとして使うことが出来る場合がある  参考：データ ストア モデルを理解する - Azure アーキテクチャ センター |Microsoft Learn # 種類 用途・特徴 代表例 1 リレーショナル (OLTP/OLAP) トランザクション処理（OLTP）、分析(OLAP) Microsoft SQL, PostgreSQL, MySQL, Snowflake 2 NoSQL 柔軟なデータモデルとスキーマ （ドキュメント, カラム, グラフ, Key-Value , 時系列） Cosmos DB, Cassandra, MongoDB, Redis 3 時系列 IoT/ログ/センサー、時系列分析 Azure Data Explorer, InfluxDB 4 オブジェクトストレージ 非構造化データ保存 Azure Blob, Amazon S3 （Databricks*） 5 検索 全文検索、ベクトル検索（セマンティック検索、RAG） Elasticsearch, Azure AI Search, Pinecone *Lakehouse アーキテクチャ では、 データストアとしてオブジェクトストレージ が使用される
60. OLTP vs OLAP  OLTP と OLAP はもっとも大きく処理特性の別れるワークロードであるため、それに適したデータストアを 選ぶことが重要となる  特にデータ分析基盤では集計処理時に顕著に性能差が表れる • 業務用データベースが主とする処理特性 • 一般に行指向でデータが保存され、データは1レコードを構成する 複数列が格納される • レコードレベルのルックアップと更新が得意だが、対象レコードのす べてのカラムをリードする必要があるた集計が非効率 • 分析用データベースが主とする処理特性 • 一般に列指向でデータが保存され、データは複数行にまたがって 一つの列が格納される • 対象列のみをスキャンする集計が効率的だが、レコード単位の処 理では複数のデータファイルにアクセスが発生してオーバーヘッドと なる OLTP (Online Transaction Processing) OLAP (Online Analytical Processing) 参考：https://www.slideshare.net/nttdata-tech/bigdata-storage-layer-software-nttdata 集計時に必要な列だけアクセス 集計時には全列にまたがってアクセス
61. OLAPサービス OLAP の基本原則は Disk IO を減らす戦い ①データ配置最適化  最も基本的な最適化戦略は処理時のデータスキャン量である。  2013年ごろ、採用されていた SQL Server Fast Track など、過去の分析基盤でもスキャンを 分散する戦略がとられてきた。  現代では、クラウドのストレージを使用するためディスクを分散を検討することはないが、 最新のDWHでもデータファイルが分散されることで同一の効果が狙われている  Databricks DeltaLake のファイル最適化 / Snowflake のマイクロパーティション 一般的なRDBアーキテクチャ エンジン データ （単一ディスク） ディスクの分散 (SQL Server Fast Trackなど) エンジン データ (複数ディスク) データファイルを複数ディス クに配置してIO向上 (200 * 4 MB/sなど) データ配置の最適化 OLAPサービス データディスクの限界 がボトルネック （200MB/sなど）
62. OLAP の基本原則は Disk IO を減らす戦い ②パーティションプルーニング • 大量データを保持するテーブル/フォルダ行の特定の列の値でレコードを分割することで、アクセスするデータ範囲を 限定する • 最もよくあるパーティション対象列は日付列 • 実務では直近年度だけ参照されることが多いため、効果が出やすい • 小さすぎるデータファイルはかえって性能低下を招くため、使いどころには注意（many tiny files） tableA year=2022 month=1 month=2 tableA 2022/01/01,10 2022/01/02,20 ・・・ 2022/01/31,10 2022/02/01,10 2022/02/02,20 ・・・ 2022/02/28,10 2022/01/01,10 2022/01/02,20 ・・・ 2022/12/31,10 パーティションがある場合 →必要な範囲でアクセスしフィルタ処理不要 パーティションがない場合 →全範囲アクセスしてからフィルタ処理 スキャン対象 スキャン対象 テーブル全量をフルス キャンするため、負荷 が高い 必要なデータファイル のみアクセスされる
63. OLAPサービス OLAPサービス OLAP データストアのスケールアップ  現代の DWH では、処理を複数ノードに分散する MPP アーキテクチャを採用しており、 大量のデータを効率的に処理できる。  処理性能を高めたい場合は、クラスターノード追加により並列処理を強化 （クラスター全体としてのスケールアップ） 単一コンピューティングでの処理 (SMP) エンジン データ (複数ディスク) エンジン （クラスター） データ (分散ストレージ) 制御ノードと複数の処理 ノードが分散処理し、性能 向上 処理の分散 (MPPアーキテクチャ) ・・・ 単一エンジンでの 処理にボトルネック 処理の並列化 負荷に応じて増減
64. OLAP データストアのスケールアウト  MPP で処理性能の向上は可能になったが、処理の要求自体が増加した場合への対策も必要となる。  現代のDWHでは「ストレージとコンピューティングの分離」の原則により、以下を実現している  処理要求数の増加（クラスタースケールアウト）  データ処理を実行するクラスタ自体の数を増やすことで、制御ノードのボトルネックを解消する  同一データに対して異なる用途・スペックでクラスタを使い分ける（ワークロードの分離）  分析クエリ / ETL 実行 / 解析処理 など、異なる特性を持つ処理ではそれに適したクラスタを利用したり、お互いのワークロードが影響しあわないようにする 従来型 （ストレージとコンピューティングが一体化） ストレージとコンピューティングの分離 SQL エンジン SQLサービス ストレージサービス 異なる ワークロード ・・・ SQL エンジン SQLサービス ・・・ ・・・ OLAPサービス エンジン （クラスター） データ (分散ストレージ) ・・・ 負荷に応じて増減 制御ノードは単一で あるため同時に多数 のリクエストをさば けない 負荷に応じて増減 用途に合わせて 別エンジンで処理 ワークロードの分散
65. 特化型データストア：時系列DBと検索DB 時系列 DB 全文検索 ベクター検索 特徴： - 逐次発生するデータのタイムスタンプで自 動的にインデックス付け - 追記型の書込み（Append only）に 最適化されており、更新は苦手 - センサーやログなどの時間集計やトレンド 分析などの用途が一般的 参考：時系列データベース(TSDB)とは 特徴： - テキストを分割（トークン化）し、トークン 単位でのマッチングとランキングを実行。 - キーワードや語形で検索され、一般的な 検索エンジンで広く採用 参考：How full-text search works | Elastic Docs 特徴： - 格納しているデータを意味で検索する - Embedding と呼ばれる手法で、 ドキュメントと質問をそれぞれベクトル形 式にすることで、意味的な類似性を算出 する 参考：ベクトル検索 - Azure AI Search | Microsoft Learn テキスト 分析基盤 / の/ 構築 トークン化 インデックス化  汎用的なRDB/NoSQLでは難しい分析処理を、これら専用ストアが効率的に実現する  それぞれの仕組みと特徴を抑えることで適切な選定が可能となる 「分析基盤の構築」 柴犬 プードル 三毛猫 犬の種類は？ 類似度で検索 埋めこみを 生成 検索DB
66. データレイクハウスについて  2020 年ごろに Databricks が提唱したデータウェアハウスとデータレイクのハイブリッドアーキテクチャ  一つのアーキテクチャですべての種類のデータを管理し、全くエンジンの異なるワークロードを同じデータに 対して実行できる  データウェアハウス（OLAP RDB）  構造化データの保存 / SQL BI ワークロードを実行する SQL エンジン  データレイク（オブジェクトストレージ）  構造化～非構造化データの保存 / ML AI ワークロードを実行する Python エンジン  Databricks は テーブルの仕組みを持ちながらファイルとして自由に持ち運び可能な Delta Lake を開発することで、データレイク上での RDB の仕組みを確立した • What is a Data Lakehouse? – Databricks
67. データストア データストア 分類 リレーショナル(OLAP) +オブジェクトストレージ リレーショナル(OLAP) 時系列 DB リレーショナル(OLTP) NoSQL (ドキュメント) 保存データ 形式 構造化 半構造化 非構造化 構造化 （JSON サポートあり） 構造化 半構造化 構造化 （JSON サポートあり） 半構造化 （JSON） 更新頻度 処理特性 バッチ主体 （ストリーム可） バッチ リアルタイム （追記主体） 高頻度更新 低レイテンシ 高頻度更新 低レイテンシ ユースケース データ統合 SQL/BI分析 機械学習 SQL/BI 分析 センサー等時系列処理 RAGデータストア* 汎用業務アプリ RAG データストア* グローバル分散アプリ 生成AI アプリ* Fabric におけるデータストアの種類 レイクハウス ウェアハウス SQL DB イベントハウス Cosmos DB 参考：Fabric 決定ガイド - データ ストアを選択する - Microsoft Fabric | Microsoft Learn *ベクター検索に対応
68. OneLake でのデータストアの表現  OneLake は 組織に 1 つのデータレイクであり、 ワークスペースや、その中のアイテムはフォルダ構造で表現されている OneLake のセキュリティの概要 - Microsoft Fabric | Microsoft Learn Eventhouse (Mirror) Warehouse Warehouse Lakehouse
69. 3つの ”ハウス” のデータ構造 レイクハウス イベントハウスでのデータ管理単位： コンピューティングを共有したデータベース群 および配下のテーブルなどのオブジェクト ・・・ KQL データベース イベントハウス テーブルなどのオブジェクト ・・・ テーブル フォルダ スキーマ（プレビュー） ・・・ ・・・ ・・・ レイクハウスでのデータ管理単位： 構造化領域としてのスキーマとテーブル、 非構造化領域内のフォルダ、ファイル ウェアハウス スキーマ ・・・ ・・・ ウェアハウスのデータ管理単位： スキーマ群および配下のテーブルなどのオブジェクト テーブルなどのオブジェクト
70.  イベントハウスはストリーム書き込み（小さいデータ断片が細かいタイミングで書き込まれる特性がある）に最適化するため 特殊な構成となっている イベントハウスの OneLake への反映について Delta Lake フォルダへの反映 - プロパティをオンにすると、書き込みで発生した小さくて多数のファイルを 最適なファイルサイズにまとめてDelta Lake 形式出力する - イベントハウス OneLake の可用性 - Microsoft Fabric | Microsoft Learn OneLake Cache Storage (Premium ADLS) OneLake Standard Storage (Standard ADLS) イベントハウス専用ストレージ領域 OneLake データ保持ポリシー - 最速クエリのための”キャッシュ層”と、 標準速度でのクエリ可能な ”保持層” の二つにより、 リアルタイムデータの保持コスト最適化をはかっている - イベントハウスと KQL データベース使用量 - Microsoft Fabric | Microsoft Learn Delta Parquet
71. ウェアハウス と SQL 分析エンドポイント  レイクハウスやミラーリングなどを作成すると「SQL分析エンドポイント」と呼ばれる読み取り専用モードのウェアハウスが自動的に 作成される。  ウェアハウスはMS SQL Server 互換の接続エンドポイントをもつため、対応した BI ツールなどからレイクハウステｰブルに接続が 可能となる  参考：一緒に使えばより便利に - レイクハウスとウェアハウス - Microsoft Fabric | Microsoft Learn ウェアハウス 分析クエリ 分析クエリ モデルトレーニング 変換処理 変換 処理 Tables Power BI レイクハウス Tables Files ノートブック Spark/Python SQL分析 エンドポイント SQL SQL Power BI 自動生成 Data Science 更新は不可
72. Fabric Databases の管理されたミラーリング  Fabric 上で展開した運用データベース（SQL DB / Cosmos DB）は自動的にOneLake にミラーリングされる  OneLake 上のデータに対しては SQL分析エンドポイントが自動設置されるので、 Power BI や外部のSQL ツール を通じて、ニアリアルタイムでの分析が可能となる SQL データベースのミラーリングの概要 (プレビュー) - Microsoft Fabric | Microsoft Learn
73. FAQ：レイクハウスとウェアハウスの選択  ほぼ同じ用途で使用できるウェアハウスとレイクハウスの使い分けの観点を示す  多くの場合組合せて利用することになるので用途別に選択  Microsoft Fabric Decision Guide: Warehouse と Lakehouse の間で選択する - Microsoft Fabric | Microsoft Learn 判断基準 レイクハウスを選択 ウェアハウスを選択 利用したい開発言語 Spark（ SQL / Python ）で開発 T-SQL で開発 保存予定のデータ形式 不定、構造化データに限らない 構造化のみ 列定義の変更頻度 頻繁 稀 同じトランザクションで 複数テーブル更新 不可 ETL内のロジックで対応 BEGIN TRAN に対応 運用の主体 自身でパーティショニングなど柔軟に運用 自動最適化（Microsoft 管理）
74. 補足）書き込み特性の違いによるデータ処理への影響  レイクハウス、イベントハウスはデータとスキーマの置き換え（Replace）コマンドを サポートしている一方で、 ウェアハウスは常に DDL によるテーブル事前定義・変更が必要  具体例：データフロー Gen 2 のあて先としてウェアハウスを選んだ場合、動的スキーマが選択できない。（あらか じめテーブル列の修正が必要） Dataflow Gen2 データの格納先とマネージド設定 - Microsoft Fabric | Microsoft Learn
75. レイクセントリックな OneLake の特性によるデータストアの組合せ実現性  全ての構造化データは OneLake 上で共通のフォーマットで保管され、ショートカットを通じて別のワークロードでもコ ピーなく再利用できる。  ただし、データの更新を行えるのはデータの保存を行ったアイテムからのみであるため、 「どのように使いたいか」よりも「どのように管理したい」か、で選択することがポイント Tables レイクハウス Tables Files ノートブック Spark/Python OneLake ショートカット ウェアハウス SQL データ管理の主体 （提供側） データの消費
76. 参考  レイクハウス  Lakehouse と Delta テーブル - Microsoft Fabric | Microsoft Learn  Microsoft Fabric での Delta テーブルのメンテナンス - Microsoft Fabric | Microsoft Learn  ウェアハウス  Microsoft Fabric ブログ  パフォーマンス ガイドライン - Microsoft Fabric | Microsoft Learn  SQL Analytics エンドポイントのパフォーマンスに関する考慮事項 - Microsoft Fabric | Microsoft Learn  イベントハウス  Microsoft Fabric を使用した RAG アプリケーションの構築  チュートリアル: Eventhouse をベクター データベースとして使用する - Microsoft Fabric | Microsoft Learn  Empowering Real-Time Searches: Vector Similarity Search with Eventhouse | Microsoft Fabric ブログ | Microsoft Fabric  SQL DB  Microsoft Fabric での SQL データベースの発表 (プレビュー) |Microsoft Fabric ブログ |マイクロソフトファブリック  Cosmos DB  Announcing Cosmos DB in Microsoft Fabric (Preview) | Microsoft Fabric Blog | Microsoft Fabric
77. データモデリング
78. データモデリングに関わる役割と本章の対象  データモデリングはオーナーの要件を基に、スチュワードが統制し、技術者が実装する  本章では技術者の観点から、具体的な実装方法（SCD2など）を解説する 公式データの定義・責任を担う “ソースデータオーナー” データ資産の説明責任を もつ ”データスチュワード” ユースケース用の二次データの定義・責任を担う “ビジネスオーナー” 「KPI定義」「集計ロジック」 「ユースケース要件」 ソースデータオーナーの意思を中心に反映 「データ定義」「品質要 件」「利用制約」 データソース データ利活用 ユースケース用データ ユースケース用のデータモデル 要件を実現する “技術者” （データエンジニア / アナリスト / データサイエンティスト) ビジネスオーナーの意思を中心に反映 「標準化・整合」「ルール統制」「品質統制」 整備された汎用データ 全社標準のデータモデル データ統合 データ準備 「モデリング手法」「定義実装」「性能要件」 読者の役割範囲
79. データ分析基盤に関連する 一般的なデータモデリング手法 観点 3NF （第3正規化） ディメンショナルモデリング フラットワイド （大福帳形式） 概要 主キーで分離し重複排除 業務システムで一般に採用 FactとDimensionの2種類のテーブルで構成される。 DWHやデータマートで一般に採用。 マスタ属性を全て付与して非正規化 メリット 更新整合性が高く、ストレージコストも抑制できる。 分析処理の性能に優れ、 DWHの標準 JOIN不要で簡単に利用でき、探索的分析や機械学習 前処理に適する。 注意点 JOINが多く分析に不向き 分析にに応じた非正規化バランスなど、設計難易度が高 い 冗長性が高く、データ量の増加でストレージや性能面に負 担がかかる。 参考 • 関係の正規化 - Wikipedia • Dimensional Modeling Techniques - Kimball Group • スター スキーマと Power BI での重要性を理解する - Power BI | Microsoft Learn
80. （上級者向け）Data Vault 2.0  DWH で履歴の追跡を重視したモデリングとして新興した手法  参考: DataVaultAlliance - Learn, Connect, Excel - DataVaultAlliance  ハブ、サテライト、リンクという形にテーブルを分解し、すべてのデータを履歴保存可能にする  一部のツールでフレームワーク化されているが、まだ難易度は高い データボルト | Databricks
81. ディメンショナルモデリングの位置づけ  分析環境において、正規化（整合性）と非正規化（集計効率）のバランスをとるのがディメンショナルモデリング 売上ヘッダ SalesID CustomerID SalesDate 売上明細 SalesID ProductID Quantity Price 顧客 CustomerID CustomerName RegionID 顧客地域 RegionID RegionName 売上ファクト SalesID CustomerID SalesDate ProductID Quantity Price 顧客ディメンション CustomerID CustomerName Region 売上分析表 SalesID CustomerName Region SalesDate ProductID ProductName ProductCategory Quantity Price 製品 ProductID ProductName Product Category ID 製品カテゴリ Product Category ID CategoryName 製品ディメンション ProductID ProductName ProductCategory ID CategoryName 第三正規形 ディメンショナルモデリング フラットワイド 非正規化 正規化 代表例：スタースキーマ
82. ディメンショナルモデル代表：スタースキーマの概要  2種類のテーブルで構成  Factテーブル  トランザクション情報が一般的  明細などの出来事の発生を表現するレコードを保持  メジャー（測定値）の集計対象として設計する  メジャーの例：受注金額…  データ量は肥大化しやすい  Dimensionテーブル  マスタ情報が一般的。  製品カテゴリなどの出来事の説明を表現するレコードを保持  集計軸として設計する  集計軸の例：製品名、製品カテゴリ  データ量は相対的に小さくなりやすい  後述の履歴管理手法によっては肥大化 スター スキーマと Power BI での重要性を理解する - Power BI | Microsoft Learn
83. ディメンショナルモデルでの集計値算出のイメージ  Dimensionテーブルでフィルタする流れ(下図はスノーフレークスキーマと呼ばれる構成）  1→多の方向に向かって、フィルタが伝播していく  フィルタされたレコードに基づいて、Factが集計結果を返す Power BI Desktop でのモデル リレーションシップ - Power BI | Microsoft Learn
84. スタースキーマ vs フラットワイド（大福帳）  分析用のテーブルのモデリングにおいては、 「すべてに万能なモデルは存在せず、目的に応じて使い分けることが重要」  スタースキーマ：全社共通の分析基盤や BI ツールのソースで必須レベル  DWH / BI のソリューションは一般にスタースキーマに最適化されているため安定  フラットワイド：PoC、探索、機械学習特徴量テーブルに有効  サイズが顕著に肥大化するので実行環境に性能が左右されやすい（SQL分析は高速でもBIツールでは対応しきれない場合も） データ分析基盤での観点 スタースキーマ フラットワイド（大福帳） 適用シナリオ 全社DWH、BIのデータソース PoC、探索、ML特徴量前処理 データサイズ ◎ (程よく正規化) × （同じ属性値が繰り返される） モデリング難易度 △ （粒度調整やテーブルの分割度合が肝） ◎ （列追加で単純拡張） 対応できる問い ◎ （柔軟な切り口で集計） △ （単純集計がメイン）
85. スタースキーマ vs フラットワイド（大福帳）  フラットワイドの注意点の例  イベントの発生しなかった属性に対する分析には 0 埋めなどの工夫が必要になる点に注意 スタースキーマ フラットワイドテーブル Fact Dimension フラットワイドの弱点：ゼロ件が 表現できない 大阪の売上がないことが 可視化される 売上年月 顧客コード 売上数量 2020/10/1 A001 10 2020/10/1 A002 20 2020/11/1 A001 20 顧客コード 顧客地域 A001 東京 A002 東京 B001 大阪 売上年月 顧客コード 売上数量 顧客地域 2020/10/1 A001 10 東京 2020/10/1 A002 20 東京 2020/11/1 A001 20 東京
86. フラットワイドが特に採用されるユースケース  機械学習における特徴量テーブル  モデルの入力となる「特徴量」は大福帳形式となることが一般的  特徴量は機械学習モデルのタスクによって有効となるものが変わる  「回帰」の例：住宅価格を求める →特徴量：住宅の築年数  「分類」の例：顧客の解約可能性を求める →特徴量：顧客利用年数  「時系列予測」の例：7日後の売上を求める →特徴量：過去7日間の売上移動平均  機械学習における特徴エンジニアリング - Azure Architecture Center | Microsoft Learn  リアルタイム分析  センサーやログのリアルタイム分析では、発生するイベントをそのまま1レコードとして蓄積するフラットワイド形式が 一般的  レイテンシ（遅延）を最小化するため、複雑な正規化やJOINを避け、単一テーブルに属性を持たせる設計が 優先される  ユースケース例：設備監視のアラート検知、クリックストリームの即時集計、金融取引の不正検知など  このような用途では「検索効率」「単純なクエリでの即時計算」「スケーラビリティ」が重要視される
87. ディメンショナルモデリングの進め方の例  Kimball 氏の公開情報をベースにした進め方の概要を示す。  参考：Enterprise Data Warehouse Bus Architecture - Kimball Group  アジャイルデータモデリングなどの書籍も有効 ステップ 内容 ゴール（成果物） 1. 業務要件の整理 • 分析対象となる業務プロセスを明確化（売上、在庫、顧客など） • KPI／メジャー値を定義（導出式・利用意図など） • KPI が集計される際の分析軸を確認 • 業務上の使われ方のスケッチや、打ち手とのつながりを整理 分析業務要件の整理資料 • 分析テーマ(Fact)と指標一覧 • 指標の導出式 • 指標の確認方法、確認周期（可視化やアラートなどのアプリケーションに 求める振る舞い） • 指標に対する集計軸(Dimension)に基づいてレコード粒度の定義 2. データ理解と項目整理 • ソースデータの実構造（ER図、キー関係、データ品質）を確認 • 必要な情報項目を洗い出し、Fact／Dimensionの候補を識別 • どの項目をどのソースから取得するかを整理 • サンプルデータを使用した欠損値やコード値確認 データソース整理資料 • 対象データソース一覧 • データソースER図 • Fact、Dimension項目取得元 • データ品質特記情報 3. 結合条件の整理 • FactとDimensionの結合キーを確認 • JOIN条件や履歴管理の方式（SCDなど）を検討 FactとDimensionの結合条件整理資料 • 情報項目を集計軸属性に紐づけるための結合条件一覧（Fact 直接紐 づかず、チェーンする場合に注意） • Fact × Dimension ER図 • テーブル別SCD適用方式 4. モデル全体の構造化 • Fact／Dimensionにおける KPI , 属性の所属テーブル整理 • メジャーと集計軸の関係を整理 • 複数指標間の共通Dimensionを明確化 バスマトリクス • 分析指標と共通ディメンション内の属性の対応関係（実現可否を含 む） • SCDの適用結果
88. バスマトリクス  ディメンショナルモデルではメジャーと集計軸の関係性をメンテナンスするためにバスマトリ クスを作成することが推奨される。  KPIやメジャーがどのモデルで表現されるかを明示することで、再利用性を高め、後続プ ロジェクトや追加レポートへの展開を容易にする。  ディメンション内の属性やSCDの適用状態まで表現すると、設計の完成度がさらに高まる。 Enterprise Data Warehouse Bus Architecture - Kimball Group
89. 顧客代理キー 顧客コード 顧客地域 開始日 終了日 有効フラグ 1 A001 東京 2020/1/1 2020/11/1 0 2 A002 東京 2020/1/1 9999/12/31 1 3 B001 大阪 2020/1/1 9999/12/31 1 4 A001 北海道 2020/11/1 9999/12/31 1 顧客コード 顧客地域 A001 北海道 A002 東京 B001 大阪 履歴化の方式 SCD(Slowly Changing Dimension)  顧客の住所変更や製品の分類変更など、過去の状態を保持して分析に活用するために、SCDと呼ばれる履歴化手法  Dimensional Modeling Techniques - Kimball Group  代表的な SCD パターンは 1 と 2 である（ 0～7までパターン化）  SCD Type 0 ：変更を反映しない  SCD Type 1 ：変更があればレコードを新しい状態に上書き  SCD Type 2 ：変更があれば新しいレコードを追加して古いレコードの終了日を更新する 例： 2020年11月から顧客A001の住所が変わった場合 SCD 1 SCD 2 ～10/31の状態 11/1の状態 ～10/31の状態 11/1の状態 更新 顧客コード 顧客地域 A001 東京 A002 東京 B001 大阪 顧客代理キー 顧客コード 顧客地域 開始日 終了日 有効フラグ 1 A001 東京 2020/1/1 9999/12/31 1 2 A002 東京 2020/1/1 9999/12/31 1 3 B001 大阪 2020/1/1 9999/12/31 1 現在の 状態の レコード 失効
90. 開始日と終了日の取り扱いについて  SCD 2 を採用する場合には終了日を更新する際の日付に一貫したルールが必 要 1. 半開区間方式（開始日と終了日を同日にする）  「開始日=<対象日<終了日」（半開区間）で取得する 2. 前日終了方式（終了日を次の開始日の前日にする）  「開始日 <= 分析日 <= 終了日」で取得する  注意点：日付単位の分析では簡便だが、時間まで記録する場合は境界を 23:59:59 などと表現する必要があり取り扱いに注意 顧客代理キー 顧客コード 顧客地域 開始日 終了日 有効フラグ 1 A001 東京 2020/1/1 2020/11/1 0 2 A002 東京 2020/1/1 9999/12/31 1 3 B001 大阪 2020/1/1 9999/12/31 1 4 A001 北海道 2020/11/1 9999/12/31 1 10/31 時点の情報は WHERE 開始日 <= 10/31 AND 10/31 < 終了日 で取得 顧客代理キー 顧客コード 顧客地域 開始日 終了日 有効フラグ 1 A001 東京 2020/1/1 2025/10/31 0 2 A002 東京 2020/1/1 9999/12/31 1 3 B001 大阪 2020/1/1 9999/12/31 1 4 A001 北海道 2020/11/1 9999/12/31 1 10/31 時点の情報は WHERE 10/31 BETWEEN 開始日 AND 終了日 で取得
91. 補足）各取込のスナップショットが残っていれば SCD 2 は後から生成可能  データを取り込んだ日付とその時のデータを使用してSCD2型のテーブルを一括生成可能。  参考：sql server - SCD Type 2 の SQL クエリ - スタック オーバーフロー (stackoverflow.com) 顧客コード 顧客地域 取込日付 A001 東京 1月1日 A002 東京 1月1日 B001 大阪 1月1日 A001 東京 1月2日 A002 東京 1月2日 B001 大阪 1月2日 A001 北海道 1月3日 A002 東京 1月3日 B001 大阪 1月3日 SELECT [顧客コード], [顧客地域], MIN([取込日付]) AS [取込日付] ～ GROUP BY <取り込み日付以外の項目 > SELECT ROW_NUMBER() AS [顧客代理キー], [顧客コード], [顧客地域], LEAD([開始日]) OVER ( PARTITION BY [顧客コード] ORDER BY [開始日] ) -- 終了日や代理キーの仕様はお好みで ～ 顧客コード 顧客地域 開始日 終了日 A001 東京 1月1日 1月3日 A002 東京 1月1日 1月1日 B001 大阪 1月1日 1月1日 A001 北海道 1月3日 NULL 顧客コード 顧客地域 開始日 A001 東京 1月1日 A002 東京 1月1日 B001 大阪 1月1日 A001 北海道 1月3日
92. 補足）Fact テーブルの再採番を防ぐ日付スナップショット型履歴管理  SCD2のサロゲートキーが降り直しになる際、サロゲートキーをキーに結合する Fact で全件の更新が必要になる。  範囲結合ができない場合やパフォーマンス向上のために Fact 側でサロゲートキーを持つケースがある（基本フロー） ※範囲結合が可能な場合にはあまり問題にならない  日付スナップショット型で履歴管理されたディメンションを使用すると独立した処理が可能  日付スナップショットは SCD2 テーブル×対象日付期間の JOIN で生成可能  通常のSCD 2 に比べてディメンションが肥大化するのでパーティションは必須となる  参考  UPDATEを使わない最新のバッチデータウェアハウスの構築 |by ダニエル・マテウス・ピレス |データサイエンスに向けて (medium.com)  Functional Data Engineering - A Set of Best Practices | Lyft – YouTube WHERE ビジネスキー AND 処理日 でサロゲートキーを取得 顧客代理キー 顧客コード 顧客地域 開始日 終了日 有効フラグ 1 A001 東京 2020/1/1 2020/11/1 0 2 A002 東京 2020/1/1 9999/12/31 1 3 B001 大阪 2020/1/1 9999/12/31 1 4 A001 北海道 2020/11/1 9999/12/31 1 顧客コード 売上日 A001 2025/1/1 A002 2025/2/1 B001 2025/1/1 A001 2025/11/1 Fact ソース Dimension Fact 顧客コード 売上日 顧客代理キー A001 2025/9/1 1 A001 2025/10/1 1 A001 2025/11/1 4 A001 2025/11/1 4 Dimension の情報を使って Fact が生成される 顧客コード 売上日 A001 2025/1/1 A002 2025/2/1 B001 2025/1/1 A001 2025/11/1 Fact ソース HASH値（顧客コード + 売上日 顧客コード 売上日 1111-1111-1111 A001 2025/9/1 ・・・ A001 2025/10/1 4444-4444-4444 A001 2025/11/1 4444-4444-4444 A001 2025/11/1 Fact で完結した処理 代理キーのみで結合可能になる ※Dimensionの代理キーが降りなおされたら再生成 HASH値 顧客コード 顧客地域 スナップショット日 1111-1111-1111 A001 東京 2025/9/1 2222-2222-2222 A001 東京 2025/9/2 ・・・ ・・・ ・・・ ・・・ 4444-4444-4444 A001 北海道 2025/11/1 Dimension 同じ方法で作成された HASH 値を持つディメンションと 結合可能 ※衝突に注意（ SHA2 256 等を利用する） Fact 基本フロー 日付スナップショット
93. データストア よく採用される データモデル DWH： ソースシステム準拠 / ディメンショナルモデル 機械学習： フラットワイド ソースシステム準拠 / ディメンショナルモデル フラットワイド 3NF アプリケーションの アクセスに合わせた バランスの非正規化 説明 ソースシステムからの統合 を目的とする場合は3NF などのソース準拠である 場合も多い レイクハウスと同様にソー スシステム準拠である場 合も多いが、最終的には BI ツール向けにディメン ショナルモデルに向けて整 える 実際には ディメンショナ ルモデルでも扱えるが、イ ベントログ処理ではフラッ トワイドが一般的 業務アプリ向けに 3NF が基本だが、用途によっ て非正規化テーブルを併 用することもある アプリのアクセスパターン に最適化するため、柔 軟に非正規化・多対 多埋め込みを行う Fabric データストアで選択される主なデータモデル レイクハウス ウェアハウス SQL DB イベントハウス Cosmos DB ※すべてのデータストアにおいて「ソース準拠」と「用途準拠」の両モデルがあり得る。 本表は用途に基づく推奨モデルを示す。
94. Power BI を使用する場合の推奨について  用途が Power BI レポートである場合、そのソーステーブルはディメンショナルモデル （スタースキーマ）が推奨される  スター スキーマと Power BI での重要性を理解する - Power BI | Microsoft Learn  スタースキーマを使用せず、フラットワイドテーブルに複数のフィルタ列を使用した場合のリスク例  Understanding DAX Auto-Exist – SQLBI  ただし、一部のユースケースなど、必ずしもスタースキーマが絶対原則ではない点を考慮する  Power BIでスタースキーマが最適とは限らない事例 - テクテク日記
95. データストア内のテーブルの設計指針について  OneLake 上の構造化データは原則 Delta Lake フォーマットであるため、開発元 の Databricks 、 OSS Delta Lake ドキュメントが特に参考になる  Delta Lake のドキュメントへようこそ |デルタ湖  Databricks の Delta Lake とは何ですか? | Databricks on AWS  ※Databricks では OSS 化されていない独自の機能が記述されることがあるため注意
96. Delta テーブル プロパティ・テーブル機能の主要検討項目①復元期間  Time-travel (特定の日時にデータを復元する)：  以下の二つのプロパティの組みあわせにより復元期間を制御する  delta.deletedFileRetentionDuration (既定値 7 日)  現バージョンのテーブルからは不要なデータを含むファイルの保持期間 この期間を越えているデータファイルは VACUUM 時に削除される  テーブル・ユーティリティー・コマンド |デルタ湖  delta.logRetentionDuration (既定値 30 日)  ログファイルの保持期間  ログファイルの削除は自動的に実行される  参考  Delta Lake のログ・過去データの保持期間について理解する #Databricks - Qiita
97. Delta テーブル プロパティ・テーブル機能の主要検討項目②レコード変更履歴  CDF(Change Data Feed)行レベルでの変更の履歴を保持する  delta.enableChangeDataFeed (既定値 false)  変更履歴機能の有効化 / 無効化を行う  変更履歴の保持期間は Time-travel の期間設定にしたがって VACUUM時に削除される点に注意  参考  Delta Lake 変更データ フィード (CDF) |デルタ湖  データフィードの変更 |デルタ湖  Delta Lakeのチェンジデータフィードを用いてどのようにCDCをシンプルにするのか #Databricks - Qiita
98. Delta テーブル プロパティ・テーブル機能の主要検討項目③最適化  特にテーブルの設計時に検討しておくとよい最適化項目  統計情報の収集対象の指定  Delta Lake はファイルのもつ統計情報を使用して不要なファイルのフルスキャンを回避するが、 テキストやバイナリを含む列は統計収集のコストが高いため、対象とならないようにするためのプロパティ  delta.dataSkippingNumIndexedCols (既定値 先頭 32 列)  統計情報の収集対象列（列の並びにより決定）を制御する  更新キーなどの統計情報を収集したい列は並び順の調整が必要になる  OSS Delta Lake では列名での対象指定が未対応  データファイルの自動最適化（テーブルプロパティとしては重要度低）  度重なる更新で小さいファイルに断片化されるデータファイルを自動的に統合する。 書き込み時にセッションで指定可能なため、セッションプロパティを制御できないワークロードが介在するテーブルを対象にするなどで使い 分ける  delta.autoOptimize.autoCompact (既定値 false)  自動ファイル統合を有効化する  spark.databricks.delta.autoCompact.maxFileSize (既定値 128MB)  統合後のファイルサイズ上限を指定する  最適化 |デルタレイク  デルタ テーブル プロパティ リファレンス - Azure Databricks |Microsoft Learn
99. Delta Lake パーティショニングについて  テーブルを作成する際に、パーティション設定を行う代表的な動機 1. クエリに対応したスキャン範囲の最適化  日付など頻繁に利用されるフィルタ項目でパーティションが活用されると高効率 2. 連携データの特性による洗い替え範囲の簡易化  spark.sql.sources.partitionOverwriteMode=dynamic を使用して書き込むと、書き込み先のパーティション設定に基づいて、 反映したいデータがもつ範囲のみ洗い替えされる  月単位などで洗い替えたいが締め日などの関係で、いつ確定データが連携されるかわからない場合に有用  UPSERT 方式だと削除の反映が難しいため  注意点  パーティションはデータの内容に応じてデータが配置されるファイルを分割するため、 パーティション粒度が細かすぎるなど、小さなファイルを含むパーティションフォルダが多数作成されると大幅なパ フォーマンス影響につながる点に注意  リキッドクラスタリングを使用するとパーティションの偏りなどの注意事項を軽減できるが、Fabric ではワークロードの互換性に影響が出るこ とを確認したうえで導入すること  Delta Lake Liquid Clustering | Delta Lake  デルタ テーブルにリキッド クラスタリングを使用する |デルタ湖  Azure Databricks でテーブルをパーティション分割するタイミング - Azure Databricks | Microsoft Learn
100. Delta テーブルの制限事項についての参考  Fabric 上の構造化データ = Delta テーブルには OSS Delta Lake に関連する制限が存在する  スペースや一部の特殊文字をテーブル名や列名に使えないなど  ウェアハウスのテーブル  Lakehouse の Delta Lake テーブルへの読み込み - Microsoft Fabric | Microsoft Learn  OSS Delta Lake は既定では Parquet の命名制約を持つため。  また、大文字と小文字を区別しないのがデフォルトであり、列名 の揺れは検証で弾かれる  Delta Lakeにおけるスキーマの進化と強化 - Databricks  Fabric 内の機能ならびに外部の分析ツールとの 互換性を保つために、小文字のスネークケース (例：sales_detail)を使用するなど一貫した命名 規則を推奨する  必要な場合には、列マッピング （delta.columnMapping.mode=‘name’）を使用することが できるが、互換性への制限を慎重に検討する
101. Fabric における Delta Lake 機能の互換性  Fabric 内では各種のワークロードが同一の データに対して処理を実行するが、 アップグレードが必要なテーブル機能では完 全な互換性が提供されていないことに注意 したうえでテーブル機能を使うこと  Delta Lake テーブル形式の相互運用性 - Microsoft Fabric | Microsoft Learn  Databricks ユーザーが Fabric を使う際にひっかかりがちな Delta Lake テーブル機能の互換性について #Microsoft - Qiita
102. 参考  ディメンショナルモデリング  Amazon | Star Schema: The Complete Reference | Adamson, Christopher | Data Warehousing  Kimball Toolkit Books on Data Warehousing and Business Intelligence  日本語版の書籍が一部あり：データウェアハウス・ツールキット | ラルフ キンボール, Kimball,Ralph, 康秀, 藤本, 和美, 岡田, 学, 下平, 磨瑳也, 伊藤, 喜一, 小畑 |本 | 通販 | Amazon  アジャイルデータモデリング 組織にデータ分析を広めるためのテーブル設計ガイド (KS情報科学専門書) | ローレ ンス・コル, ジム・スタグニット, 株式会社風音屋, 打出 紘基, 佐々木 江亜, 土川 稔生, 濱田 大樹, 妹尾 拡 樹, ゆずたそ, 株式会社風音屋 |本 | 通販 | Amazon  SCD  dbt snapshot から学ぶ Slowly Changing Dimension - Gunosyデータ分析ブログ  Slowly Changing Dimensions Are Not Always as Easy as 1, 2, 3 - Kimball Group  デザインのヒント #152 緩やかに変化するディメンションタイプ 0、4、5、6、7 - Kimball Group
103. 5. データ処理
104. データ分析基盤 データ処理での整理ポイント  データ連携：どのようにデータを基盤に取り込むか / 参照するか  データ変換：目的に応じてどのように整備・加工するか  データ消費：内部・外部でどのように利用・提供されるか  ワークフロー：一連の処理をどのように構成・制御するか データソース 打ち手・施策 データ活用 データ整備 プラットフォームサービス（インフラストラクチャー / ガバナンス etc.) データ処理 データ蓄積 ユースケース データ管理基能 データ連携 データ変換 鋭意作成中 データ消費 ワークフロー