3
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Fabricの構成要素~Fabricは階層で理解すると分かりやすい

3
Posted at

2.1 Fabricの構成要素.png

📚 関連書籍

※この記事は書籍の一部をベースに再構成しています。もう少し踏み込んだ内容(設計や具体例)は書籍の中でまとめているので、気になる方はそちらもどうぞ。

『ゼロから触ってわかった!Microsoft Fabric実務入門 データ統合・分析・BI・AI活用の全体像 』

Fabricの構成要素~Fabricは階層で理解すると分かりやすい

Microsoft Fabricを理解するときは、最初に構成要素の関係を押さえておくと分かりやすくなります。

Fabricには、Tenant、Capacity、Workspace、Item、OneLakeといった重要な概念があります。これらは個別に覚えるよりも、階層や役割の違いで整理すると理解しやすくなります。

大まかにいうと、Tenantは組織全体の単位、Capacityは処理能力や課金に関係する単位、Workspaceは作業場所、ItemはWorkspace内に作成される成果物、OneLakeはデータを置く共通の場所です。

つまり、Fabricは「組織全体の環境の中に、処理能力の単位があり、その上に作業領域があり、そこにさまざまな成果物を作成し、データはOneLakeを中心に管理する」と考えると整理しやすくなります。

Tenant:組織全体の単位

Tenantは、Microsoftクラウドにおける組織全体の管理単位です。

Microsoft 365やAzure、Power BIを利用している企業では、ユーザー、グループ、認証、管理設定などがTenant単位で扱われます。FabricもこのMicrosoftのクラウド基盤の上で利用するため、TenantはFabric全体を管理する大きな枠組みになります。

たとえば、どのユーザーがFabricを利用できるのか、どの機能を有効にするのか、組織としてどのような管理ルールを適用するのか、といった設定はTenant全体に関係します。

Fabricをビルにたとえるなら、Tenantは会社が入っている建物全体のようなものです。建物全体の管理ルールがあり、その中に部署や作業部屋が存在するイメージです。

Capacity:処理能力と課金に関係する単位

Capacityは、Fabricで処理を実行するためのリソース単位です。

Fabricでは、データを取り込む、Notebookを実行する、WarehouseでSQLを実行する、Power BIレポートを利用する、といった処理に計算リソースが必要です。この処理能力を提供する単位がCapacityです。

Capacityは、性能や利用量、課金と関係します。どの程度の処理能力を持つCapacityを使うかによって、同時実行できる処理や処理速度、利用コストに影響します。

また、WorkspaceはCapacityに割り当てて利用します。つまり、作業場所であるWorkspaceは、どこかのCapacityのリソースを使って動くと考えると分かりやすいです。

ビルの例でいえば、Capacityは電力や作業設備のようなものです。どれだけ大きな作業ができるか、どれだけ同時に処理できるかを支える基盤です。

Workspace:成果物をまとめる作業領域

Workspaceは、Fabricで作業を行うための領域です。

Workspaceの中には、Lakehouse、Warehouse、Pipeline、Notebook、Semantic model、Reportなど、さまざまなItemを作成します。チームやプロジェクトごとにWorkspaceを分けることで、成果物や権限を整理しやすくなります。

たとえば、営業分析用のWorkspace、経理分析用のWorkspace、検証用のWorkspace、本番用のWorkspaceといった形で分けることができます。

Workspaceは、単なるフォルダではありません。共同作業、権限管理、Capacityへの割り当て、成果物の管理を行う重要な単位です。

ビルの例でいえば、Workspaceは部署ごとの作業部屋です。部屋ごとにメンバーがいて、その中で必要な成果物を作成します。

Item:Workspace内に作成される成果物

Itemは、Workspaceの中に作成される具体的な成果物です。

Fabricでは、Lakehouse、Warehouse、Data Pipeline、Dataflow、Notebook、KQL Database、Semantic model、Power BI ReportなどがItemとして扱われます。

実務でFabricを使うとき、ユーザーが直接作成・編集する対象の多くはItemです。たとえば、データを保存するLakehouseを作る、SQL分析用にWarehouseを作る、データ取り込み用のPipelineを作る、可視化用のReportを作る、というように作業します。

Itemは、Fabricにおける実際の作業成果物です。Workspaceが作業部屋だとすれば、Itemはその部屋の中に置かれた机、資料、道具、成果物のようなものです。

OneLake:Fabric共通のデータ置き場

OneLakeは、Fabricにおける共通のデータレイクです。

Fabricでは、LakehouseやWarehouseなどの各Itemがデータを扱いますが、その土台としてOneLakeがあります。OneLakeは、組織全体で利用する単一の論理データレイクとして位置づけられています。

従来のデータ基盤では、部門ごと、ツールごと、用途ごとにデータの置き場所が分かれがちでした。その結果、同じデータが複数の場所にコピーされ、どれが正しいデータなのか分かりにくくなることがありました。

Fabricでは、OneLakeを中心にデータを管理することで、データの分断を減らし、複数のワークロードから同じデータを利用しやすくすることを目指しています。

5つの構成要素の関係

ここまでをまとめると、Fabricの構成要素は次のように整理できます。

Tenantは、組織全体の管理単位です。

Capacityは、処理能力や課金に関係するリソース単位です。

Workspaceは、チームやプロジェクトで成果物を管理する作業領域です。

Itemは、Workspace内に作成される具体的な成果物です。

OneLakeは、Fabric全体でデータを置く共通の場所です。

この関係を理解しておくと、Fabricの画面や設定を見たときに迷いにくくなります。

たとえば、「このLakehouseはどこにあるのか」と聞かれた場合、それは特定のWorkspace内にあるItemです。「このWorkspaceは何のリソースで動いているのか」と聞かれた場合、それは割り当てられたCapacityを使っています。「データはどこに保存されているのか」と聞かれた場合、その中心にOneLakeがあります。

Fabricの全体アーキテクチャは、これらの構成要素が組み合わさって成り立っています。

📚 関連書籍

※この記事は書籍の一部をベースに再構成しています。もう少し踏み込んだ内容(設計や具体例)は書籍の中でまとめているので、気になる方はそちらもどうぞ。

Databricks/Snowflake/n8n/Salesforce/AI基盤e/POC/要件定義の進め方 を体系的に学べる
「ゼロから触ってわかった!」シリーズをまとめました。

『ゼロから触ってわかった!Microsoft Fabric実務入門 データ統合・分析・BI・AI活用の全体像 』

『ゼロから触ってわかった! Databricks 本番導入完全ガイド(非公式) ― Serverless・Lakeflow・AI時代のデータ基盤実践 ― 』

『Databricks──ゼロから触ってわかった!Databricks非公式ガイド(2026年更新版)』

クラウド時代の分析基盤を “体験的” に学べるベストセラー入門書。
Databricksの操作、SQL/DataFrame、Delta Lakeの基本、ノートブック操作、SDP(宣言型パイプライン)
Serverless、Genieなどを初心者でも迷わず進められる構成で解説しています。
https://amzn.to/4uIqEj4

『ゼロから触ってわかった! Snowflake × Databricks次世代データ基盤PoC実践 非公式ガイド』

本書を読み終えたとき、「POCって何から始めればよいのか」が明確になり、「自分たちにもできる」という確信を持てることを目指しています。
https://amzn.to/43qI0oR

『ゼロから触ってわかった! Snowflake × Databricksでつくる次世代データ基盤 - 比較・共存・連携 非公式ガイド』

SnowflakeとDatabricks――二つのクラウドデータ基盤は、これまで「どちらを選ぶか」で語られることが多くありました。本書は、両プラットフォームをゼロから触り、構築・運用してきた実体験をもとに、比較・共存・連携のリアルを丁寧に解説する“非公式ガイド”です。
https://amzn.to/4efDkIk

Snowflake

ゼロから触ってわかった!Snowflake非公式ガイド ― 基礎から理解するアーキテクチャとCortexによる次世代AI基盤

初めてSnowflakeに触れる方には「最初の一冊」として。
なんとなく使っているけれどモヤモヤしている方には「頭の中を整理する一冊」として。
AI時代のエンジニアを目指すための、確かな燃料となる一冊です。
https://amzn.to/4x1VvZm

「ゼロから触ってわかった!Codex - AIエージェント時代のソフトウェア設計」

本書は、AIエージェントと共に開発する時代において、エンジニアが思考停止せず、主体的に価値を発揮し続けるための指針を提示します。
ツールの使い方ではなく、これからの開発の本質を理解したいすべてのエンジニアへ。
https://amzn.to/4o0repH

「ゼロから触ってわかった! Claude Code × ChatGPT × Gemini AI共生戦略 -“対立”ではなく“共生”する時代へ」

Claude Code × ChatGPT × Geminiという共生モデルを解説します。
https://amzn.to/4a2dJjC

『ゼロから触ってわかった!スペック駆動開発入門 ― SaaS is dead?AI時代のソフトウェア設計論』

前半では思想や背景を丁寧に整理し、後半ではスペック・実装・実行の三層モデルをサンプルコードとともに具体化します。
https://amzn.to/3RFEZya

####『ゼロから触ってわかった!dbt実務入門 非公式ガイド SQLで作るモダンデータ変換・テスト・ドキュメント・セマンティックレイヤー』
本書は、dbtをこれから学びたい方、SQLを使ったデータ変換をより体系的に管理したい方、データ基盤やモダンデータスタックに関心がある方に向けて書いた入門書です。
https://amzn.to/3SmxlJz

Databricks

『ゼロから触ってわかった!Azure × Databricksでつくる次世代データ基盤 非公式ガイド ―』

クラウドでデータ基盤を作ろうとすると、Azure・Storage・ネットワーク・権限・セキュリティ…
そこに Databricks が加わった瞬間、一気に難易度が跳ね上がります。 “最初のつまづき” を丁寧にほどいていくのが本書です。
https://amzn.to/3QaOzbW

『Databricks──ゼロから触ってわかった!AI・機械学習エンジニア基礎 非公式ガイド』

Databricksでの プロンプト設計・RAG構築・モデル管理・ガバナンス を扱うAIエンジニアの入門決定版。
生成AIとデータエンジニアリングの橋渡しに必要な“実務の型”を体系化しています。
資格本ではなく、実務基盤としてAIを運用する力 を育てる内容です。
https://amzn.to/3PYK4ku

『Databricks認定データエンジニアプロフェッショナル 試験レベル ― 1日3分!気になったところから読めるデータブリックス!魂の100本ノック!』

本書は、Databricks認定データエンジニア・プロフェッショナル相当の論点を、
100個のユースケースに分解し、**“2択の検討”→“解説コラム”→“結論”**でテンポよく叩き込む「魂の100本ノック」です。
暗記ではなく、現場で遭遇する判断ポイント(取り込み・変換・品質・共有・監視・性能/コスト・セキュリティ・ガバナンス・デプロイ・モデリング)を、短い読書時間で反復できるように整えました。
https://amzn.to/4vkLm8K
https://amzn.to/4fhNBF5

Databricks Advancedシリーズ(上/中/下)

Databricksを “設計・運用する” ための完全版実践書
「ゼロから触ってわかった!Databricks非公式ガイド」の続編として誕生した Advancedシリーズ は、
Databricksを触って慣れた“その先”――本格運用・チーム開発・資格対策・再現性ある設計 に踏み込む構成です。
📘 [上]開発・デプロイ・品質保証編
https://amzn.to/4dGQoGv
📘 [中]取込・変換・監視・コスト最適化編
https://amzn.to/49zbPHb
📘 [下]セキュリティ・ガバナンス・トラブルシュート・最適化戦略編
https://amzn.to/4efDkIk

「ゼロから触ってわかった!Databricks × Airbyte」

クラウド時代のデータ基盤を“なぜ難しいのか”から丁寧にほどくガイドが完成しました。
Ingestion / LakeFlow / DLT / CDC をやさしく体系化し、
Airbyte × Databricks の真価を引き出す設計思想まで詰め込んだ一冊です。
https://amzn.to/3XOlV0t

『Databricks──ゼロから触ってわかった!DatabricksとConfluent(Kafka)連携!非公式ガイド』

Kafkaによるストリーム処理とDatabricksを統合し、リアルタイム分析基盤を構築するハンズオン形式の一冊。
イベント駆動アーキテクチャ、リアルタイムETL、Delta Live Tables連携など、
モダンなデータ基盤の必須スキルがまとめられています。
https://amzn.to/42HdmqZ

Salesforce

『ゼロから触ってわかった!Salesforce AgentForce + Data360(Data 非公式ガイド』

Salesforceの最新AI基盤 AgentForce と Data360(Data Cloud) を、実際の操作を通じて理解できる解説書。
https://amzn.to/4u4PyZ2

要件定義(上流工程/モダンデータスタック)

『モダンデータスタック時代の シン・要件定義 クラウド構築大全 ― DWHからCDP、そしてMA / AI連携へ』

クラウド時代の「要件定義」って、どうやって考えればいい?
Databricks・Snowflake・Salesforce・n8nなど、主要サービスを横断しながら“構築の全体像”をやさしく解説!
DWHからCDP、そしてMA/AI連携まで──現場で使える知識をこの一冊で。
https://amzn.to/4nZm0ux

データメッシュ

####『ゼロから触ってわかった データメッシュ入門 ― 思想・型・組織構造から考えるデータメッシュ』
「Data Mesh を導入すべきかどうか」を断言する本ではありません。
自分たちにとって、どこまで分散し、何を共有し、どこに責任を置くのか。
その判断をするための思考の土台を整理する一冊です。
https://amzn.to/3REkyBS

データクリーンルーム

ゼロから触ってわかった データクリーンルーム実践入門 ~ Lakehouse時代のクリーンルームを、思想・設計・マネタイズで読み解く ~

データはあるのに、渡せない。それでも一緒に分析したい——そんな現場の悩みから、本書は始まります。
データクリーンルームを「難しい技術」ではなく、現実の業務でどう使い、どう続けるかという視点で整理しました。
非ITのビジネスパーソンにも読める、実践的な一冊です。
https://amzn.to/4fiG6O2

MCP

『ゼロから触ってわかった!MCPビギナーズガイド』 ― AIエージェント時代の次世代プロトコル入門 アーキテクチャ・ガバナンス・実装―

MCPというプロトコルは、単なる技術トレンドではなく
「AIとシステムの関係性」そのものを変える可能性を秘めています。
SaaS、AIエージェント、ガバナンス、アーキテクチャ、その交差点を一度、立ち止まって整理した一冊です。
https://amzn.to/4nZm0ux

n8n

『n8n──ゼロから触ってわかった!AIワークフロー自動化!非公式ガイド』

オープンソースの自動化ツール n8n を “ゼロから手を動かして” 学べる実践ガイド。
プログラミングが苦手な方でも取り組めるよう、画面操作中心のステップ構成で、
業務自動化・AI連携・API統合の基礎がしっかり身につきます。
👉 https://amzn.to/48Blxca

💡 まとめ:このラインナップで“構築者の視点”が身につく

これらの書籍を通じて、
クラウド基盤の理解 → 要件定義 → 分析基盤構築 → 自動化 → AI統合 → 運用最適化
までのモダンデータスタック時代のソリューションアーキテクトとしての全体像を
「体系的」かつ「実践的」に身につけることができます。

  • PoC要件整理
  • データ基盤の要件定義
  • チーム開発/ガバナンス
  • AIワークフロー構築
  • トラブルシュート

など、現場で直面しがちな課題を解決する知識としても活用できます。

3
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
3
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?