Instiq

Microsoft Fabric Analytics Engineer Associate のナレッジマップ

Microsoft Fabric Analytics Engineer Associate の主要概念 211 件と、そのつながり。上のマップでノードをクリックすると関連用語や前提をたどれます。下は全概念の索引で、定義と「前提・関連する概念」への内部リンクを掲載しています。

概念一覧(211)

  • Microsoft Fabric(容量・ワークスペース・エクスペリエンス)

    データ統合・分析・BI を 1 つに統合した SaaS 分析基盤。階層は「容量(キャパシティ)→ ワークスペース → アイテム」。容量=コンピュート+課金の単位(F SKU・Power BI Premium の P SKU、容量ユニット CU を消費、スムージング/バースティングで平準化、一時停止/再開可)。ワークスペース=コラボとアクセス管理の単位。エクスペリエンス=Data Engineering/Data Factory/Data Warehouse/Real-Time Intelligence/Power BI など役割別機能。全エクスペリエンスが OneLake を共有する点が最大の特徴。PaaS の寄せ集めではなく統合 SaaS。

    前提: Azure Data Factoryスムージングとバースティング階層(セマンティックモデル)

    関連: 容量(Fabric キャパシティ)エクスペリエンス(Fabric)Real-Time Intelligence(リアルタイムインテリジェンス)

  • ウェアハウス(Fabric Warehouse)

    フル T-SQL(読み書き・マルチテーブルトランザクション)に対応する Fabric の DW アイテム。データは OneLake の Delta に保存される。

    関連: Direct Lakeレイクハウス(Fabric Lakehouse)OneLake

  • Fabric の取り込みと変換(パイプライン・Dataflow Gen2・Spark・メダリオン)

    取り込み=データパイプライン(Copy/ノートブック等のアクティビティをオーケストレーション・スケジュール・再試行)/Copy アクティビティ(大量データ高速搬送・増分はウォーターマーク)/データフロー Gen2(Power Query でノーコード整形)/ショートカット(参照)/Eventstream(ストリーミング)。変換=Spark ノートブック(PySpark/Spark SQL・大規模/ML)/T-SQL(Warehouse・セットベース)/Dataflow Gen2(ノーコード)。設計はメダリオン=ブロンズ(生)→シルバー(クレンジング/結合)→ゴールド(集計/ビジネス向け)で段階化し各層を Delta で保存。

    前提: Copy アクティビティデータパイプライン(Fabric)Dataflow Gen2(データフロー Gen2)Microsoft Fabric(容量・ワークスペース・エクスペリエンス)

  • Direct Lake

    Power BI が OneLake の Delta テーブルを、インポートも DirectQuery もせずに直接・高速に読むセマンティックモデルのモード。非対応機能では DirectQuery にフォールバックする。

    前提: Delta テーブル(Delta 形式)DirectQuery モード

    関連: ウェアハウス(Fabric Warehouse)レイクハウス(Fabric Lakehouse)OneLake

  • OneLake

    組織で 1 つに統合された Fabric のストレージ(ADLS Gen2 互換・テーブルは Delta 形式)。全エクスペリエンスが共有し、データを 1 か所に集約する。

    前提: Azure Data Lake Storage Gen2

    関連: Direct Lakeウェアハウス(Fabric Warehouse)レイクハウス(Fabric Lakehouse)Delta テーブル(Delta 形式)エクスペリエンス(Fabric)

  • セマンティックモデル

    Power BI の「意味の層」(旧データセット)。テーブル・リレーションシップ・メジャー・階層・書式をまとめ、レポートが参照する。

  • データの探索とパフォーマンス診断(DAX/T-SQL/KQL・Performance Analyzer)

    探索はクエリ言語を用途で使い分け:DAX(セマンティックモデルの集計)/T-SQL(SQL 分析エンドポイント・Warehouse の表分析)/KQL(Real-Time のストリーミング/ログ)。Power BI のビジュアル探索(スライサー/ドリルダウン)も用いる。性能トラブルは Performance Analyzer で各ビジュアルの DAX クエリ時間/表示時間を計測→DAX Studio や Tabular Editor のベストプラクティスアナライザーで深掘り→ストレージエンジン(VertiPaq・速い)vs フォーミュラエンジン(単一スレッド・遅くなりがち)の比率を確認。根本対処はスタースキーマ化・メジャー見直し・Delta の V-Order/OPTIMIZE・Direct Lake のフォールバック回避。「まず計測→原因特定→改善」。

    前提: DAX StudioDirect Lakeウェアハウス(Fabric Warehouse)メジャー

  • セマンティックモデルと DAX(メジャー・CALCULATE・ストレージモード)

    Power BI の「意味の層」(旧データセット)。リレーションシップ(ファクト↔ディメンションは原則 1 対多・単一方向)、メジャー(集計式・遅延評価・非保存)と計算列(行ごとに事前計算・保存=肥大化しがち)、階層/書式で構成。DAX(Data Analysis Expressions)は行コンテキストとフィルターコンテキストで評価され、CALCULATE がフィルターコンテキストを変更する中核(FILTER/ALL/USERELATIONSHIP と併用、TOTALYTD/SAMEPERIODLASTYEAR でタイムインテリジェンス)。ストレージモード=Direct Lake(OneLake の Delta を直接メモリにロード・高速+ほぼ最新・条件未達で DirectQuery にフォールバック)/インポート(最速・更新スケジュール要)/DirectQuery(常に最新・遅め)。列ストアエンジン VertiPaq が圧縮/集計を高速化。

    前提: CALCULATE 関数計算列(DAX)フィルターコンテキストと行コンテキストDAX(Data Analysis Expressions)

  • レポート(Power BI)

    1 つのデータセットに基づく複数ページの対話的な分析。ビジュアルを配置し、フィルターやドリルダウンで深掘りできる。Power BI Desktop で作成する。

  • 次元モデリング / スタースキーマ(ファクト・ディメンション・SCD)

    分析/BI 向けのデータ設計。スタースキーマ=中央のファクトテーブル(数値メジャー+外部キー)の周囲にディメンションテーブル(日付・製品・顧客など分析の切り口)を放射状に配置(非正規化=BI で高速)。ファクトはまず粒度(グレイン=1 行が表す単位)を決める。ディメンションはサロゲートキー(システム生成の整数キー)を主キーにし業務キーと分離して結合/履歴を安定。SCD(Slowly Changing Dimension)=属性変化の扱いで、Type 1(上書き・履歴なし)/Type 2(行追加で履歴保持)/Type 3(前の値を列で保持)。日付ディメンション(連続日付)はタイムインテリジェンスの前提。スノーフレーク(さらに正規化)は結合増で BI 性能が落ちやすい。

    前提: 日付ディメンション非正規化ディメンションテーブルファクトテーブル

  • Fabric の監視と最適化(監視ハブ・容量メトリック・V-Order・OPTIMIZE)

    監視=監視ハブ(パイプライン/ノートブック/Spark の実行履歴・状態・所要時間)/容量メトリックアプリ(容量ユニット CU の消費・スロットリングを可視化し過負荷源を特定)/Data Activator(データ条件で通知/アクションを自動起動)。エラー対応=再試行ポリシー(一時障害)+失敗パス。最適化=V-Order(読み取り最適化された並び)/OPTIMIZE(小さなファイルの圧縮統合・small files 問題の定番対処、Z-Order でデータスキッピング)/VACUUM(古い未参照ファイル削除)/パーティション設計/Spark・容量のチューニング。

    前提: 容量メトリックアプリData Activator(Activator)Microsoft Fabric(容量・ワークスペース・エクスペリエンス)容量(Fabric キャパシティ)

  • メジャー

    集計を行う DAX 式。評価時に計算され(遅延評価)モデルに値を保存しない。フィルターコンテキストに応じて結果が変わる。

    前提: フィルターコンテキストと行コンテキスト

    関連: DAX(Data Analysis Expressions)

  • レイクハウス(Fabric Lakehouse)

    ファイルとテーブルを一体で扱える Fabric のアイテム。Spark/ノートブックで処理し、自動生成される SQL 分析エンドポイント(読み取り専用)で T-SQL クエリもできる。

    関連: Direct Lakeウェアハウス(Fabric Warehouse)OneLakeSQL 分析エンドポイント

  • Microsoft Power BI

    データをレポート(複数ページの対話分析)やダッシュボード(1画面の要約)で可視化・共有する BI ツール。

    関連: ダッシュボード(Power BI)

  • ファクトテーブル

    売上や数量などの数値(メジャー)と、各ディメンションへの外部キーを持つ中心テーブル。1 行が表す単位=粒度をまず決める。

    前提: 外部キー

  • 性能の指標(IOPS/スループット/帯域幅/レイテンシー)

    性能を測る基本語彙。IOPS=1 秒あたりの I/O 回数(小さなランダムアクセスの指標、EBS io2 等)。スループット=単位時間のデータ量(MB/s、大きな連続転送)。帯域幅=回線容量。レイテンシー=1 操作の遅延。ワークロードに合う指標で設計・監視する。

  • Real-Time Intelligence(リアルタイムインテリジェンス)

    ストリーミングデータの取り込み・格納・分析・アクションを担う Fabric のエクスペリエンス。Eventstream・Eventhouse・KQL・Data Activator を含む。

    前提: Eventstream(イベントストリーム)タイムインテリジェンス

    関連: Data Activator(Activator)エクスペリエンス(Fabric)Eventhouse(KQL データベース)Microsoft Fabric(容量・ワークスペース・エクスペリエンス)

  • スタースキーマ

    中央のファクトテーブルの周りに、分析の切り口となるディメンションテーブルを放射状に配置した非正規化の設計。結合が少なく BI で高速。

    前提: 非正規化ディメンションテーブルファクトテーブル正規化

  • Azure ML のジョブと AutoML/スイープ(MLflow・ハイパーパラメーター調整)

    学習はジョブとして実行:コマンドジョブ(単一スクリプト)・スイープジョブ(ハイパーパラメーター探索)・パイプラインジョブ(コンポーネントの DAG)。定義は YAML(CLI v2)/SDK v2。トラッキングは MLflow がネイティブ統合(log_metric/log_param/log_artifact・autolog)で実験を比較。AutoML はタスク指定でアルゴリズム/前処理を自動探索しリーダーボードで選択。スイープは探索空間+サンプリング(グリッド/ランダム/ベイズ)+早期終了(Bandit/中央値停止)でハイパーパラメーターを調整、max_concurrent_trials で並列度とコストを制御。

    前提: Azure Machine Learningコマンドジョブコンポーネント(再利用可能なステップ)早期終了ポリシー(Bandit/中央値停止)

  • SQL 分析エンドポイント

    レイクハウスのテーブルに対して自動生成される、読み取り専用の T-SQL クエリ用エンドポイント(書き込みは不可)。Warehouse のフル T-SQL とは区別する。

    関連: レイクハウス(Fabric Lakehouse)T-SQL(Fabric)

  • T-SQL(Fabric)

    ウェアハウスや SQL 分析エンドポイントで使う SQL 方言。セットベースの変換・集計に向き、Warehouse では読み書きとトランザクションも可能。

    関連: SQL 分析エンドポイント

  • Azure Machine Learning

    MLのワークフロー(準備→学習→評価→デプロイ→予測)を支援。Automated ML(自動最良選択)とDesigner(ノーコード)がある。

  • Azure ML のコンピューティングとデータ(ワークスペース/クラスター/データアセット)

    Azure ML ワークスペースが ML の成果物(データ・モデル・実験・エンドポイント)を一元管理し、関連リソース(ストレージ/Key Vault/Application Insights/Container Registry)が紐づく。コンピューティングは開発用のコンピューティングインスタンス(個人・停止でコスト節約)と学習をスケールさせるコンピューティングクラスター(オートスケール・アイドル時 0 ノード・低優先度/Spot VM 可)。データは Blob/ADLS への接続情報=データストアと、再利用可能・バージョン管理された参照=データアセット(uri_file/uri_folder/mltable)。学習済みモデルはモデルレジストリでバージョン管理。環境(conda/Docker)で依存を固定し再現性を担保。操作は Studio/Python SDK v2/CLI v2。

    前提: Blob ストレージAzure Machine Learningコンピューティングクラスターコンピューティングインスタンス

  • Fabric のセキュリティとガバナンス(ワークスペースロール・機密ラベル・デプロイパイプライン)

    ワークスペースロール=Admin > Member > Contributor > Viewer の階層(最小権限)。データ単位はアイテム権限・行レベルセキュリティ(RLS)・列レベル/オブジェクト権限で細かく制御。ガバナンス=機密ラベル(Microsoft Purview Information Protection でデータ分類・暗号化/透かし)と Purview(監査・系列リネージ・データカタログ)。リリース=デプロイパイプライン(開発→テスト→本番で成果物を昇格・差分比較)と Git 統合(CI/CD)。テナント全体の機能可否は管理ポータルのテナント設定で統制。

    前提: デプロイパイプライン(Fabric)Microsoft Fabric(容量・ワークスペース・エクスペリエンス)Git 統合(Fabric)アイテム権限(Fabric)

  • Azure Synapse Analytics

    大規模なデータウェアハウジングと統合分析(SQL・Spark・パイプライン)を1つにまとめたプラットフォーム。機能は次世代の Microsoft Fabric に統合・継承が進み、新規ワークロードは Fabric が推奨。

    前提: Microsoft Fabric(容量・ワークスペース・エクスペリエンス)

  • データパイプライン(Fabric)

    Copy やノートブックなどのアクティビティをオーケストレーション(順序・スケジュール・再試行・分岐)する取り込み/処理の仕組み。Data Factory エクスペリエンスで作る。

    前提: Azure Data FactoryMicrosoft Fabric(容量・ワークスペース・エクスペリエンス)エクスペリエンス(Fabric)オーケストレーション(Fabric)

  • Delta テーブル(Delta 形式)

    Fabric のテーブルの既定フォーマット。Parquet にトランザクションログを足し、ACID・タイムトラベル・スキーマ管理を可能にする。OneLake のテーブルはこれで保存される。

    前提: ACIDMicrosoft Fabric(容量・ワークスペース・エクスペリエンス)

    関連: OneLake

  • DirectQuery モード

    元のデータソースへ都度クエリを投げる方式。常に最新だが、ソース性能に依存し概してインポートより遅い。

  • Azure ML のデプロイ(オンライン/バッチエンドポイント・トラフィック分割)

    推論はエンドポイントで提供。マネージドオンラインエンドポイント=リアルタイム低遅延(Azure がインフラ管理・オートスケール)/Kubernetes オンライン=既存 AKS/バッチエンドポイント=大量データをコンピューティングクラスター上で非同期スコアリング。1 エンドポイントに複数デプロイを置き、トラフィック分割でブルー/グリーン(段階的ロールアウト・即ロールバック)。デプロイにはスコアリングスクリプト(init/run)と環境、適切なインスタンス種別/数が必要(MLflow モデルは推論コード不要なことも)。アクセスはマネージド ID+キー/トークン認証、必要ならプライベートエンドポイント。

    前提: Azure Machine Learningバッチエンドポイントコンピューティングクラスターマネージドオンラインエンドポイント

  • Eventhouse(KQL データベース)

    Real-Time Intelligence で大量のイベント/時系列データを格納・分析するストア。中に KQL データベースを持ち、KQL で高速クエリする。

    関連: Real-Time Intelligence(リアルタイムインテリジェンス)

  • 容量(Fabric キャパシティ)

    Fabric のコンピュートと課金の単位。F SKU(や Power BI Premium の P SKU)で購入し、容量ユニット(CU)を消費する。一時停止/再開でき、ワークスペースを紐づけて使う。

    前提: Microsoft Power BI

    関連: Microsoft Fabric(容量・ワークスペース・エクスペリエンス)

  • OneLake ショートカット

    内部/外部(ADLS Gen2・Amazon S3・GCS など)のデータを、コピーせず OneLake から参照する仕組み。重複保存を避けデータを仮想的に統合する。

    前提: Azure Data Lake Storage Gen2OneLake

  • OPTIMIZE(テーブル最適化)

    小さなファイルを大きなファイルへ統合し、読み取りを速くする Delta の保守コマンド。small files 問題の定番対処。

    関連: small files 問題

  • V-Order

    Parquet/Delta を読み取りに最適化して並べ替える Fabric の書き込み最適化。Power BI(特に Direct Lake)や SQL の読み取りが速くなる。

    前提: Direct LakeMicrosoft Fabric(容量・ワークスペース・エクスペリエンス)Microsoft Power BI

  • Azure Data Lake Storage Gen2

    Blob ストレージ上に階層型名前空間を追加した、大規模分析向けのデータレイク。ディレクトリ構造と POSIX 風の ACL を持ち、Synapse や Databricks の分析基盤の蓄積層として使われる。

    前提: Blob ストレージAzure DatabricksAzure Synapse Analyticsデータレイク

  • 計算列(DAX)

    行ごとに事前計算してモデルに保存する列。メジャーと違い保存されるためモデルが肥大化しやすい。原則はソース側/メジャーで代替を検討。

    前提: メジャー

  • データウェアハウス

    整形済みの構造化データを分析・集計向けに格納する基盤。スキーマは書き込み時に定義。

    前提: ウェアハウス(Fabric Warehouse)構造化データ

  • Dataflow Gen2(データフロー Gen2)

    Power Query を使い、ノーコードでデータを取得・整形して宛先(レイクハウス/ウェアハウス等)へ書き出す変換ツール。少量〜中量の整形向き。

    前提: ウェアハウス(Fabric Warehouse)レイクハウス(Fabric Lakehouse)

  • フィルターコンテキストと行コンテキスト

    DAX 評価の 2 つの文脈。行コンテキスト=現在の行、フィルターコンテキスト=適用中の絞り込み。CALCULATE はフィルターコンテキストを操作する。

    関連: CALCULATE 関数

  • DAX(Data Analysis Expressions)

    セマンティックモデルでメジャーや計算列を書く式言語。行コンテキストとフィルターコンテキストで評価される。

    前提: 計算列(DAX)フィルターコンテキストと行コンテキストセマンティックモデル

    関連: メジャー

  • ディメンションテーブル

    日付・製品・顧客など分析の切り口(属性)を持つテーブル。ファクトと 1 対多で結び、フィルターやグループ化の軸になる。

    前提: ファクトテーブルグループ化と集計(変換)

  • Eventstream(イベントストリーム)

    イベント(IoT・ログ・キュー等)をノーコードで取り込み、変換して Eventhouse やレイクハウスへ送るストリーミングのパイプライン。

    前提: Eventhouse(KQL データベース)レイクハウス(Fabric Lakehouse)

  • エラーの特定と解決(Fabric)

    パイプライン/Dataflow Gen2/ノートブック/Eventhouse/Eventstream/T-SQL/ショートカットの各エラーを、実行ログ・エラーメッセージから切り分けて修正する運用。

    前提: Dataflow Gen2(データフロー Gen2)Microsoft Fabric(容量・ワークスペース・エクスペリエンス)Eventhouse(KQL データベース)Eventstream(イベントストリーム)

  • エクスペリエンス(Fabric)

    役割別の機能セット(Data Engineering / Data Factory / Data Warehouse / Real-Time Intelligence / Power BI など)。すべて同じ OneLake を共有する。

    前提: Azure Data Factoryデータウェアハウス

    関連: Microsoft Fabric(容量・ワークスペース・エクスペリエンス)OneLakeReal-Time Intelligence(リアルタイムインテリジェンス)

  • メダリオンアーキテクチャ

    データを品質段階で層化する設計。ブロンズ(生)→シルバー(クレンジング/結合)→ゴールド(集計/ビジネス向け)と進め、各層を Delta で保存する。

    関連: ブロンズ層シルバー層ゴールド層

  • ゴールド層

    メダリオンの最終層。集計やビジネスロジックを適用し、レポート/分析がそのまま使えるデータ(多くは次元モデル)にする。

    前提: レポート(Power BI)

    関連: メダリオンアーキテクチャ

  • 正規化

    重複を減らし整合性を保つようにテーブルを分割・設計すること。更新時異常を防ぐ。

  • オーケストレーション(Fabric)

    複数の処理(パイプライン/ノートブック)を順序・依存・条件で組み合わせて自動実行すること。パラメーターと動的式で再利用性を高める。

    前提: パイプラインのパラメーターと動的式

  • 行レベルセキュリティ(Fabric)

    利用者ごとに見える「行」を制限するデータ単位のセキュリティ。ウェアハウス/SQL 分析エンドポイント/セマンティックモデルで述語により行を絞る。

    前提: Microsoft Fabric(容量・ワークスペース・エクスペリエンス)ウェアハウス(Fabric Warehouse)セマンティックモデルSQL 分析エンドポイント

  • ストレージモード

    セマンティックモデルがデータをどう保持/取得するかの方式。Import・DirectQuery・Direct Lake があり、速度と鮮度のトレードオフで選ぶ。

    前提: Direct LakeDirectQuery モードセマンティックモデル

  • 構造化データ

    行と列の固定スキーマを持つデータ。型が定まり検索・集計が高速。例:リレーショナルDBのテーブル。

  • Tabular Editor

    セマンティックモデルを効率的に編集する外部ツール。計算グループの作成やベストプラクティスアナライザーでの点検に使う。

    前提: セマンティックモデル

    関連: 計算グループ

  • タイムインテリジェンス

    前年比・年初来累計・移動平均など、日付ディメンションを前提にした時系列の DAX 計算(TOTALYTD・SAMEPERIODLASTYEAR 等)。

    関連: 日付ディメンション

  • ストアドプロシージャ(Warehouse)

    ウェアハウスで一連の T-SQL 処理(複数ステートメント・制御フロー・パラメーター)をまとめて実行する再利用可能なオブジェクト。パイプラインのアクティビティから呼び出してデータ変換ロジックをオーケストレーションするのに使う。

    前提: ウェアハウス(Fabric Warehouse)オーケストレーション(Fabric)T-SQL(Fabric)

    関連: ユーザー定義関数(Warehouse)ビュー(Warehouse)

  • ユーザー定義関数(Warehouse)

    Fabric Warehouse で再利用可能なロジックを T-SQL でカプセル化する関数。インライン テーブル値関数(インライン TVF)に加え、2025 年からスカラー UDF(1つの値を返す関数)もサポートされた(プレビュー、GA ではない)。スカラー UDF を SELECT 文で使うにはインライン化可能である必要があり、WHILE ループや非決定的関数の呼び出しなどを含むと非対応。共通の計算式を一箇所で保守でき、複数ステートメント TVF 等はオンプレ SQL Server/Synapse との機能差に注意。

    前提: Azure Synapse AnalyticsMicrosoft Fabric(容量・ワークスペース・エクスペリエンス)ウェアハウス(Fabric Warehouse)T-SQL(Fabric)

    関連: ストアドプロシージャ(Warehouse)ビュー(Warehouse)

  • ワークスペースロール(Fabric)

    ワークスペースの権限階層 Admin > Member > Contributor > Viewer。最小権限の原則で割り当て、データ単位の権限と組み合わせる。

    前提: Microsoft Fabric(容量・ワークスペース・エクスペリエンス)階層(セマンティックモデル)

  • Blob ストレージ

    画像・動画・バックアップなど非構造化データ(オブジェクト)向けのストレージサービス。

    前提: 構造化データ非構造化データ

  • Azure Data Factory

    データの取り込み・変換・オーケストレーションを行う ETL/ELT パイプラインサービス。

    前提: オーケストレーション(Fabric)

  • CALCULATE 関数

    フィルターコンテキストを変更して集計し直す DAX の中核関数。FILTER/ALL/USERELATIONSHIP などと組み合わせて条件付き集計を作る。

    関連: USERELATIONSHIP(DAX)フィルターコンテキストと行コンテキスト

  • 計算グループ

    同じロジック(前年比・累計など)を複数メジャーへ一括適用する仕組み。メジャーの重複を減らし保守を楽にする。Tabular Editor で作る。

    前提: メジャー

    関連: Tabular Editor

  • データストアの選択(レイクハウス/ウェアハウス/Eventhouse)

    用途で使い分ける。Spark/非構造化はレイクハウス、フル T-SQL/トランザクションはウェアハウス、ストリーミング/時系列は Eventhouse。

    前提: Eventhouse(KQL データベース)ウェアハウス(Fabric Warehouse)レイクハウス(Fabric Lakehouse)T-SQL(Fabric)

  • 非正規化

    正規化したテーブルをあえて結合・冗長化し、読み取り/分析を速くする手法。分析基盤では結合コストを下げるためによく使う。

    前提: 正規化

  • Direct Lake on OneLake

    Direct Lake の実行方式のうち、OneLake 上の Delta テーブルの列データを SQL 分析エンドポイントを介さず参照し、クエリ実行時にオンデマンドで VertiPaq エンジン用にメモリへトランスコードする経路。Direct Lake on SQL と対比される。機能面の制約や既定として使われるかどうかはモデル作成時の状況(フォールバック条件・サポートされる機能範囲)に依存し、一律に「制約が少なく既定で高性能」とは言い切れない。

    前提: Delta テーブル(Delta 形式)Direct LakeOneLakeSQL 分析エンドポイント

  • スイープジョブ(ハイパーパラメーター調整)

    探索空間・サンプリング・主要メトリック・早期終了を指定して多数の試行を走らせ、最良のハイパーパラメーター構成を見つけるジョブ。

    前提: 探索空間(search space)

    関連: プライマリメトリック

  • モダンデータウェアハウスアーキテクチャ

    取り込み→保存(データレイク)→準備・変換→モデル化・提供(DWH)→可視化、という分析の流れ。バッチとストリームを組み合わせ、Synapse/Fabric が各段を担う。

    前提: Azure Synapse AnalyticsデータレイクデータウェアハウスMicrosoft Fabric(容量・ワークスペース・エクスペリエンス)

  • 外部キー

    別テーブルの主キーを参照してテーブル間を関連づける列。参照整合性を保つ。

    前提: 主キー

  • アイテム権限(Fabric)

    個々のアイテム(レイクハウス/レポート等)を、ワークスペースロールとは別に特定ユーザーへ共有・権限付与する仕組み。

    前提: Microsoft Fabric(容量・ワークスペース・エクスペリエンス)レイクハウス(Fabric Lakehouse)レポート(Power BI)ワークスペースロール(Fabric)

  • 階層(セマンティックモデル)

    年→四半期→月や国→都市など、ドリルダウンできる段階構造をモデルに定義したもの。レポートで掘り下げ表示に使う。

    前提: レポート(Power BI)セマンティックモデル

  • 主キー

    テーブルの各行を一意に識別する列。重複・NULL 不可。

  • PySpark

    Python から Apache Spark を操作する API。DataFrame で大規模データを分散変換する。Fabric の主要な変換言語の 1 つ。

    前提: Microsoft Fabric(容量・ワークスペース・エクスペリエンス)

  • small files 問題

    小さなファイルが大量にできると読み取りが遅くなる現象。OPTIMIZE による統合や適切なパーティション設計で対処する。

    関連: パーティション設計OPTIMIZE(テーブル最適化)

  • Spark ノートブック

    PySpark や Spark SQL で大規模データを分散処理するノートブック。複雑な変換・機械学習・反復処理に向く。

    前提: PySparkSpark SQL

  • USERELATIONSHIP(DAX)

    モデル内の非アクティブなリレーションシップを、特定の計算内でのみ一時的に有効化する DAX 関数。CALCULATE の修飾子として使い、テーブル間に複数の関係(例:注文日と出荷日)がある場合にどちらを使うかを式単位で切り替える。

    関連: RELATED(DAX)CALCULATE 関数

  • VertiPaq(列ストアエンジン)

    インポート/Direct Lake モデルを支える列指向のインメモリエンジン。列ごとに高圧縮し、集計を高速化する。

    前提: Direct Lake

  • ACID

    トランザクションの信頼性を表す性質:原子性・一貫性・分離性・永続性。

  • 列レベルセキュリティ(Fabric)

    特定の列を利用者から隠すデータ単位のセキュリティ。ウェアハウスや SQL 分析エンドポイントで GRANT/DENY により列単位のアクセスを絞り、行レベルセキュリティ(RLS)とは制御軸が異なる(行 vs 列)。両者は併用できる。

    前提: Microsoft Fabric(容量・ワークスペース・エクスペリエンス)ウェアハウス(Fabric Warehouse)SQL 分析エンドポイント

    関連: オブジェクトレベルセキュリティ(Fabric)

  • Copy アクティビティ

    大量データを高速に搬送するパイプラインのアクティビティ。増分はウォーターマーク列で前回以降だけを取り込む。

    前提: ウォーターマーク(増分の基準)

  • Azure Cosmos DB

    グローバル分散・低遅延・自動スケールのマネージド NoSQL。複数 API(NoSQL/MongoDB/Cassandra/Gremlin/Table)対応。

    前提: 非リレーショナル(NoSQL)性能の指標(IOPS/スループット/帯域幅/レイテンシー)

  • Data Activator(Activator)

    データが条件(しきい値など)を満たしたら通知やアクションを自動で起動する Fabric の機能。Real-Time Intelligence の一部。

    前提: Microsoft Fabric(容量・ワークスペース・エクスペリエンス)

    関連: Real-Time Intelligence(リアルタイムインテリジェンス)

  • データレイク

    生のまま多様なデータ(構造化〜非構造化)を大量・安価に格納する基盤。スキーマは読み取り時に解釈。

    前提: 非構造化データ

  • 日付ディメンション

    連続した日付と暦の属性(年/四半期/月/曜日など)を持つ専用ディメンション。タイムインテリジェンス(前年比など)の前提になる。

    関連: タイムインテリジェンス

  • DAX パフォーマンスの改善

    遅い DAX を速くする取り組み。変数で再評価を避ける、イテレーターを減らす、フィルターを最適化する、スタースキーマ化するなど。

    前提: OPTIMIZE(テーブル最適化)スタースキーマ

  • DAX Studio

    DAX クエリの実行・計測・トレースを行う外部ツール。サーバータイミングでストレージエンジン/フォーミュラエンジンの内訳を確認できる。

    前提: ストレージエンジン vs フォーミュラエンジン

  • デプロイパイプライン(Fabric)

    開発→テスト→本番のステージ間で成果物を昇格し、差分比較やデプロイ規則を適用するリリース機能。手動配置のミスを防ぐ。

    前提: Microsoft Fabric(容量・ワークスペース・エクスペリエンス)

  • コンポーネント(再利用可能なステップ)

    入力・出力・コード・環境をまとめた再利用可能な処理単位。パイプラインのステップとして組み合わせ、バージョン管理・共有できる。

  • Synapse Spark / サーバーレス Spark

    ノートブックから大規模データを対話的に加工するための Spark コンピューティング。アタッチした Synapse Spark プールや AML のサーバーレス Spark を使う。

    前提: Azure Machine LearningAzure Synapse AnalyticsSpark ノートブックSpark パフォーマンス最適化

  • フィールドパラメーター

    レポート利用者が表示するメジャーや軸を動的に切り替えられるようにする機能。1 つのビジュアルで複数の見方を提供する。

    前提: メジャーレポート(Power BI)

  • 粒度(グレイン)

    ファクトテーブルの 1 行が表す詳細さの単位(例:1 取引・1 日 1 製品)。設計の最初に決め、これが集計の正しさを左右する。

    前提: ファクトテーブル

  • ブロンズ層

    メダリオンの最初の層。ソースから取り込んだ生データを、ほぼそのまま保持する(履歴/再処理の起点)。

    関連: メダリオンアーキテクチャ

  • シルバー層

    メダリオンの中間層。クレンジング・重複排除・結合・型整備を行い、整合の取れた統合データにする。

    関連: メダリオンアーキテクチャ

  • Microsoft Purview

    データガバナンスとコンプライアンスを統合した Microsoft の管理ソリューション群。情報保護・データライフサイクル・リスク管理・eDiscovery・監査に加え、データマップ/カタログによる横断的なデータガバナンスを含む(旧 Azure Purview を統合)。

  • Performance Analyzer

    Power BI Desktop の機能で、各ビジュアルの DAX クエリ時間や表示時間を計測し、遅いビジュアルを特定する。性能改善の出発点。

    前提: Microsoft Power BI

  • ストレージエンジン vs フォーミュラエンジン

    DAX 実行の 2 エンジン。ストレージエンジン(VertiPaq・並列・高速)とフォーミュラエンジン(単一スレッド・遅くなりがち)。後者偏重が遅さの原因になりやすい。

    前提: VertiPaq(列ストアエンジン)

  • 非構造化データ

    決まったスキーマがないデータ。ファイル/オブジェクトとして保存。例:画像・動画・音声・文書。

    前提: 構造化データ

  • ビュー(Warehouse)

    ウェアハウスで保存された SELECT 文を、あたかもテーブルのように再利用できるオブジェクト。複雑な結合や集計をビューとして隠蔽し、下流のレポートやクエリを簡潔にする。ビュー自体はデータを複製せず、参照のたびに元テーブルを再評価する。

    前提: ウェアハウス(Fabric Warehouse)レポート(Power BI)

    関連: ストアドプロシージャ(Warehouse)ユーザー定義関数(Warehouse)

  • 容量メトリックアプリ

    容量ユニット(CU)の消費やスロットリングを可視化し、過負荷の原因アイテムを特定するための管理用アプリ。

    前提: 容量(Fabric キャパシティ)

    関連: スロットリング(容量)

  • コンピューティングクラスター

    学習やバッチ推論をスケールさせるオートスケール計算。アイドル時 0 ノードに縮小でき、低優先度/Spot VM でコストを抑えられる。

  • 探索空間(search space)

    調整するハイパーパラメーターとその候補範囲(離散 choice・連続 uniform/loguniform 等)の定義。

  • Azure ML ワークスペース

    ML の成果物(データ・モデル・実験・エンドポイント)を一元管理する最上位リソース。ストレージ・Key Vault・Application Insights・Container Registry が紐づく。

    前提: Azure Machine LearningAzure Key Vault

  • データ取り込みと処理(パイプライン)

    Azure Data Factory / Synapse パイプラインでデータをコピー・オーケストレーションし、マッピングデータフローでコードなしに変換する。実行は統合ランタイムが担う。

    前提: Azure Data FactoryAzure Synapse Analyticsオーケストレーション(Fabric)

  • Power BI の構成要素(Power Query/モデル/ビジュアル)

    Power BI Desktop で Power Query を使い取り込み・整形(クレンジング)→データモデル(リレーションシップ・メジャー)を作成→ビジュアルでレポートを構築し、Power BI サービスで共有する。

    前提: メジャーレポート(Power BI)Microsoft Power BI

  • クエリツール(Azure Data Studio / SSMS)

    データベースに接続して SQL を実行・管理するツール。Windows 向けの SQL Server Management Studio(SSMS)、SQL 拡張機能を入れた Visual Studio Code、Azure ポータルや Microsoft Fabric の Web ベース SQL クエリエディターなどがある(Azure Data Studio は 2026-02-28 に提供終了)。

    前提: Microsoft Fabric(容量・ワークスペース・エクスペリエンス)

  • Synapse の構成要素(SQL/Spark プール)

    Azure Synapse Analytics は専用 SQL プール(プロビジョンド DWH)、サーバーレス SQL プール(データレイクをクエリ)、Apache Spark プール(ビッグデータ処理)、パイプラインを 1 つのスタジオに統合する。

    前提: Azure Synapse AnalyticsデータレイクSpark パフォーマンス最適化

  • ELT(抽出・格納・変換)

    データ統合パターンの一つ。ソースから抽出した生データをまず格納先(データウェアハウス/レイク)へロードし、格納先のコンピュート能力を使って後から変換する。クラウド型DWHの並列処理性能向上で普及し、生データを残せる柔軟性が利点。

    前提: データウェアハウスウェアハウス(Fabric Warehouse)

    関連: ETL(抽出・変換・格納)

  • フォルダー/ファイルレベルのアクセス制御

    OneLake セキュリティ(データアクセスロール)で、テーブルやフォルダー単位に読み取り/読み書きを付与する RBAC。既定は拒否で、権限は下位フォルダーに継承される。

    前提: ロールベースのアクセス制御(RBAC)OneLakeOneLake セキュリティ

  • グループ化と集計(変換)

    キーごとにまとめて合計・件数・平均などを求める変換。ゴールド層の作成やレポート用データの準備で使う。

    前提: ゴールド層レポート(Power BI)

  • 影響分析(ダウンストリーム依存)

    レイクハウス/ウェアハウス/データフロー/セマンティックモデルの変更が、下流のレポート等にどう波及するかを事前に把握する分析。

    前提: レイクハウス(Fabric Lakehouse)レポート(Power BI)セマンティックモデル

  • JSON

    波括弧とキー・値のペアで構造化データを表す軽量なテキスト形式。API のリクエスト/レスポンスや IAM ポリシー・バケットポリシーのような権限定義など、機械可読性を重視する場面で広く使われる。

    前提: 構造化データ

  • 非リレーショナル(NoSQL)

    固定スキーマに縛られず柔軟に保存するDB。キー値/ドキュメント/列ファミリ/グラフの4種類。

  • オブジェクトレベルセキュリティ(Fabric)

    テーブルやビューなどのオブジェクト単位でアクセス可否を制御するセキュリティ。特定のテーブル自体を見えなくする粗い粒度の制御で、列や行を部分的に見せる列/行レベルセキュリティより手前の関門として働く。ウェアハウスの GRANT/REVOKE で設定する。

    前提: Microsoft Fabric(容量・ワークスペース・エクスペリエンス)ウェアハウス(Fabric Warehouse)

    関連: 列レベルセキュリティ(Fabric)

  • OLAP(分析処理)

    履歴データを対象に大量読み取り・集計を行う分析向けワークロード。データウェアハウスに対し実行。

    前提: データウェアハウスウェアハウス(Fabric Warehouse)

  • ダッシュボード(Power BI)

    複数のレポートから重要指標(KPI)を 1 画面に集約した要約ビュー。Power BI サービス上で作成・共有する(レポートは複数ページ、ダッシュボードは 1 画面)。

    前提: レポート(Power BI)

    関連: Microsoft Power BI

  • クエリ高速化(OneLake ショートカット)

    Real-Time Intelligence で、OneLake ショートカット上のデータをキャッシュ/索引化して KQL クエリを速くする機能。標準ショートカットとの使い分けが問われる。

    前提: OneLakeOneLake ショートカットReal-Time Intelligence(リアルタイムインテリジェンス)

  • SCD(緩やかに変化するディメンション)

    ディメンション属性の変化の扱い。Type 1=上書き(履歴なし)、Type 2=行追加で履歴保持、Type 3=前の値を列で保持。

  • セマンティックモデルの更新(監視)

    Power BI のセマンティックモデルにデータを取り込み直す処理。失敗や所要時間を監視し、Direct Lake では更新の挙動が異なる点に注意する。

    前提: Direct LakeMicrosoft Power BIセマンティックモデル

  • 秘密度ラベル

    データを分類し、暗号化や利用制限などの保護を適用する仕組み。ラベルはファイルに付随し社外でも保護が効く。

  • Spark SQL

    Spark 上で SQL を使ってデータを変換・集計する方法。ノートブックから SQL に慣れた人でも大規模処理を書ける。

  • ストリーミングエンジンの選択

    ノーコードで広く繋ぐなら Eventstream、複雑/大規模処理なら Spark 構造化ストリーミング、低遅延クエリ集計なら KQL、と用途で選ぶ。

    前提: Eventstream(イベントストリーム)性能の指標(IOPS/スループット/帯域幅/レイテンシー)Spark 構造化ストリーミング

  • サロゲートキー

    システムが生成する整数の代理キー。業務キーと分離してディメンションの主キーにし、結合の安定や履歴管理(SCD)を容易にする。

    前提: 主キー

  • スロットリング(容量)

    容量を超過して使い続けたときに、処理が遅延/拒否される抑制。容量メトリックで原因を特定し、最適化やスケールで解消する。

    関連: 容量メトリックアプリ

  • VACUUM

    タイムトラベルで不要になった古い未参照ファイルを削除し、ストレージを回収する Delta の保守コマンド。保持期間に注意。

  • ウォーターマーク(増分の基準)

    増分読み込みで「どこまで取り込んだか」を表す基準値(最終更新日時や連番など)。次回はこの値より新しい行だけを取り込む。

    関連: 完全読み込みと増分読み込み

  • YAML

    インデントで階層を表す、人が読み書きしやすいテキスト形式。CloudFormation や各種 IaC ツール、CI/CD パイプラインの設定ファイルで好まれ、同じデータを JSON とも相互変換できる。

    前提: JSON階層(セマンティックモデル)

  • Azure ストレージアカウント

    Blob・File・Table・Queue の各ストレージサービスをまとめて提供する入れ物。

    前提: Blob ストレージQueue ストレージ

  • コンポジットモデル

    Import と DirectQuery(や Direct Lake)を 1 つのモデルに混在させる構成。テーブルごとにモードを選べ、デュアルモードで両用もできる。

    前提: Direct LakeDirectQuery モード

  • 動的データマスク(Fabric)

    権限のない利用者にだけ、データを伏字(例:メールの一部)で見せる機能。元データは変えず表示時にマスクする。

    前提: Microsoft Fabric(容量・ワークスペース・エクスペリエンス)機密データ保護(PII / マスキング)

  • ディメンショナルモデル向けの準備

    ファクト(数値の事実)とディメンション(属性)に整え、サロゲートキーや緩やかに変化するディメンション(SCD)を扱えるよう読み込む準備。

    前提: ファクトテーブルサロゲートキー

  • Direct Lake のフォールバック

    Direct Lake が未対応の状況(一部の機能や上限超過)で、自動的に DirectQuery に切り替わる挙動。性能低下の原因になるため回避設計が問われる。

    前提: Direct LakeDirectQuery モード

  • バッチエンドポイント

    大量データをコンピューティングクラスター上で非同期にスコアリングするエンドポイント。呼び出すとバッチスコアリングジョブが起動する。

    前提: コンピューティングクラスター

  • 早期終了ポリシー(Bandit/中央値停止)

    見込みの薄い試行を打ち切ってコストを抑えるスイープの設定。Bandit(スラックファクター)・中央値停止・切り捨て選択などがある。

    前提: スイープジョブ(ハイパーパラメーター調整)

  • MLflow トラッキング

    Azure ML にネイティブ統合された実験管理。log_metric/log_param/log_artifact や autolog で学習を記録し、実行を比較する。

    前提: Azure Machine Learning

  • マネージドオンラインエンドポイント

    リアルタイム低遅延の推論を提供し、Azure がインフラとオートスケールを管理するエンドポイント。Kubernetes オンラインは既存 AKS を使う。

    前提: 性能の指標(IOPS/スループット/帯域幅/レイテンシー)

  • パイプラインジョブ

    複数のコンポーネントを DAG として接続し、ステップ間でデータを受け渡して実行する一連の処理。スケジュール実行や監視ができる。

    前提: コンポーネント(再利用可能なステップ)

  • Responsible AI ダッシュボード

    モデルを責任ある AI の観点で評価する Azure ML のツール群。誤差分析・解釈可能性・公平性・反事実分析などを 1 つのダッシュボードで提供する。

    前提: Azure Machine Learningダッシュボード(Power BI)

  • サンプリング方法(グリッド/ランダム/ベイズ)

    スイープで探索空間から構成を選ぶ方式。グリッド(全数)・ランダム(無作為・広く速い)・ベイズ(過去結果から有望領域を学習)。

    前提: 探索空間(search space)スイープジョブ(ハイパーパラメーター調整)

  • Cosmos DB の API

    Cosmos DB はワークロードに合わせて複数の API を選べる。NoSQL(ドキュメント・既定)・MongoDB・Cassandra・Gremlin(グラフ)・Table。既存アプリの移行や用途で選ぶ。

    前提: Azure Cosmos DB非リレーショナル(NoSQL)

  • トランザクション処理と分析処理の使い分け

    OLTP は多数の小さな読み書きを高速・整合性重視で処理する業務システム向け、OLAP は大量データを集計・分析する意思決定向け。データの流れは OLTP →(ETL)→ OLAP。

    前提: OLAP(分析処理)OLTP(トランザクション処理)

  • 動的書式文字列

    メジャーの表示書式(通貨・パーセントなど)を条件に応じて DAX で動的に変える機能。計算グループと併用することが多い。

    前提: 計算グループメジャー

  • ETL(抽出・変換・格納)

    データ統合パターンの一つ。ソースからデータを抽出し、格納先に入れる前に変換(クレンジング・整形・集計)を行う。変換用の別コンピュート(サーバーやマネージドサービス)を要するが、格納先には整った形のデータだけが入る。

    前提: マネージドサービス(管理の境界)

    関連: ELT(抽出・格納・変換)

  • 結果整合性(eventual consistency)

    書き込み直後は古い値が読まれる可能性があるが、時間の経過とともに全レプリカが最終的に収束する整合性モデル。高可用性・低遅延を優先する分散データストアの既定挙動になっていることが多い。強整合性が不要な読み取りに使うことでスループットを稼げる。

    前提: 性能の指標(IOPS/スループット/帯域幅/レイテンシー)

    関連: 強整合性(strong consistency)

  • アラート設定(Fabric)

    更新失敗や条件成立などを検知して通知する設定。Data Activator や監視機能と組み合わせて運用を自動化する。

    前提: Data Activator(Activator)Microsoft Fabric(容量・ワークスペース・エクスペリエンス)

  • 監査ログ(Fabric)

    誰がいつ何をしたか(アクセス・変更・共有等)を記録するログ。Purview/管理ポータルで確認し、コンプライアンスや調査に使う。

    前提: Microsoft Fabric(容量・ワークスペース・エクスペリエンス)Microsoft Purview

  • ドメイン(Fabric)

    関連するワークスペースを業務分野(営業・財務など)でまとめる論理グループ。データメッシュ的に分散管理し、ドメイン単位で既定値や委任管理を設定できる。

    前提: RELATED(DAX)Microsoft Fabric(容量・ワークスペース・エクスペリエンス)

  • スムージングとバースティング

    容量の使用を平準化する仕組み。バースティングで一時的に高い処理能力を使い、スムージングでその消費を一定時間に按分する。過負荷時はスロットリングが起きる。

    前提: スロットリング(容量)

  • ワークスペース(Fabric)

    アイテム(レイクハウス・ノートブック・パイプライン等)をまとめ、共同作業とアクセス管理を行う単位。容量に割り当てて使う。

    前提: Microsoft Fabric(容量・ワークスペース・エクスペリエンス)レイクハウス(Fabric Lakehouse)

  • Git 統合(Fabric)

    ワークスペースを Azure DevOps/GitHub のリポジトリに接続し、アイテムをソース管理する仕組み。バージョン管理と CI/CD の基盤になる。

    前提: Microsoft Fabric(容量・ワークスペース・エクスペリエンス)

  • Azure Key Vault

    鍵・シークレット・証明書を安全に保管・管理するサービス。アプリに直接埋め込まずに済む。

  • マネージドサービス(管理の境界)

    AWS が運用の一部を肩代わりするサービス区分。フルマネージド(パッチ/スケール/可用性まで AWS)ほど運用負荷が下がる一方、制御は減る。アンマネージド(EC2 等)は柔軟だが自己管理。責任共有モデルの「どこまでが自分の責任か」を決める軸。

  • ミラーリング(Mirroring)

    外部データベース(Azure SQL・Snowflake・Cosmos DB など)の変更を、ほぼリアルタイムに OneLake へ複製する機能。CDC を使い、ETL を組まずに分析できる。

    前提: Azure Cosmos DBOneLake

  • 監視ハブ(Monitoring hub)

    パイプライン/ノートブック/Spark などの実行履歴・状態・所要時間を一覧で確認する Fabric の監視画面。

    前提: Microsoft Fabric(容量・ワークスペース・エクスペリエンス)

  • OLTP(トランザクション処理)

    小さな読み書きを多数・高速に処理する業務向けワークロード。ACID で取引の正しさを保証。

    前提: ACID

  • OneLake カタログ

    組織の OneLake 上のデータ(アイテム)を検索・把握し、信頼性(エンドース)や系列を確認できるデータ発見の入口。

    前提: エンドースメント(推奨/認定)OneLake

  • OneLake セキュリティ

    OneLake のデータに対するアクセス制御。OneLake データアクセスロールでフォルダー/テーブル単位の権限を定義し、全エンジンに一貫適用する。

    前提: OneLake

  • パーティション設計

    よく絞り込む列(日付など)でデータを分割し、クエリが必要な区画だけ読むようにする設計。過剰分割は small files を招くため粒度に注意。

    関連: small files 問題

  • Power BI Desktop プロジェクト(.pbip)

    レポートとモデルをテキスト形式のファイル群として保存する形式。Git でソース管理しやすく、差分レビューや CI/CD に向く。

    前提: レポート(Power BI)Microsoft Power BI

  • クエリパフォーマンス最適化

    実行計画・統計・適切な結合/フィルター・パーティションプルーニングなどでクエリを速くすること。ウェアハウス/SQL 分析エンドポイントで重要。

    前提: ウェアハウス(Fabric Warehouse)SQL 分析エンドポイント

  • Queue ストレージ

    コンポーネント間を疎結合にするメッセージキュー。処理の山を平準化できる。

    前提: コンポーネント(再利用可能なステップ)

  • 半構造化データ

    タグやキーで構造を持つが固定スキーマに縛られない柔軟なデータ。例:JSON、XML。

    前提: JSON構造化データ

  • 共有セマンティックモデル

    1 つのモデルを複数のレポートから再利用する運用。定義を一元化し、指標の一貫性を保つ(再作成の重複を防ぐ)。

    前提: レポート(Power BI)セマンティックモデル

  • スノーフレークスキーマ

    ディメンションをさらに正規化して複数テーブルに分けた設計。結合が増え、スタースキーマより BI 性能が落ちやすい。

    前提: 正規化スタースキーマ

  • Spark パフォーマンス最適化

    Spark 処理を速くする工夫。スタータープール/カスタムプール、パーティション数、データのスキュー対策、キャッシュ、ブロードキャスト結合などを調整する。

  • 強整合性(strong consistency)

    書き込み完了後の読み取りは必ず最新の値を返す整合性モデル。結果整合性より遅延やコストが増えがちだが、在庫数や残高のように古い値の読み取りが許されない場面で選ぶ。整合性モデルはこのトレードオフに基づき用途ごとに使い分ける。

    前提: 性能の指標(IOPS/スループット/帯域幅/レイテンシー)

    関連: 結果整合性(eventual consistency)

  • Table ストレージ

    キー値(NoSQL)の単純で安価なテーブル。大量の軽量な構造化データに向く。

    前提: 非リレーショナル(NoSQL)構造化データ

  • テナント設定(管理ポータル)

    Fabric 管理者がテナント全体で機能の可否(エクスポート・共有・特定機能の有効化など)を統制する設定。

    前提: Microsoft Fabric(容量・ワークスペース・エクスペリエンス)

  • ビジュアルクエリエディター

    コードを書かずにドラッグ操作で抽出・絞り込み・集計を組み立てる Fabric のクエリ作成画面。裏で SQL を生成する。

    前提: Microsoft Fabric(容量・ワークスペース・エクスペリエンス)クエリツール(Azure Data Studio / SSMS)

  • XMLA エンドポイント

    セマンティックモデルへ外部ツール(Tabular Editor 等)から接続・デプロイ・管理するための接続点。大規模モデルの運用に使う。

    前提: セマンティックモデルTabular Editor

  • ロールベースのアクセス制御(RBAC)

    誰に・どの役割を・どのスコープで割り当てて権限を与える認可の仕組み。最小権限が原則、割り当ては下位へ継承。

  • Azure Database for MySQL

    OSS の MySQL エンジンをマネージドで提供するリレーショナルサービス。現行は Flexible Server 形態で、同一可用性ゾーン内配置によるレイテンシ最適化や柔軟なコンピュート/ストレージのスケーリングに対応する。パッチ適用・バックアップ・フェイルオーバーは Azure が運用する。

    前提: 性能の指標(IOPS/スループット/帯域幅/レイテンシー)

  • Azure Databricks

    Apache Spark に最適化された大規模データ処理・機械学習の基盤。データサイエンス用途に強い。

  • Azure SQL Database

    フルマネージドなリレーショナル PaaS。パッチ・バックアップ・可用性を Azure が担う。新規クラウドアプリ向け。

    前提: マネージドサービス(管理の境界)

  • バッチ処理

    データをまとめてスケジュールで処理する方式。遅延は許容、大量データを効率よく扱う。例:夜間集計。

    前提: 性能の指標(IOPS/スループット/帯域幅/レイテンシー)

  • 計算テーブル

    DAX 式で生成するテーブル。日付テーブルやパラメーター表など、ソースにない補助テーブルを作るのに使う。

    前提: DAX(Data Analysis Expressions)

  • キャパシティプランニング / 需要予測

    将来の負荷を見積もり、必要な容量・コスト・スケーリング方針を計画すること。クラウドでは Auto Scaling と予測スケーリングで動的に追従できるため、固定的な過剰調達を避けられる。Compute Optimizer や CloudWatch の傾向分析が入力になる。

    前提: 容量(Fabric キャパシティ)

  • データの温度と階層化(ホット/ウォーム/コールド)

    アクセス頻度でデータを分類し、コストを最適化する考え方。ホット=頻繁(高速・高コスト)、ウォーム=時々、コールド=めったに(安価・取り出し遅い、Glacier 系)。S3 ライフサイクルや Intelligent-Tiering で自動的に階層を移す。

    前提: OPTIMIZE(テーブル最適化)

  • データベースプロジェクト

    ウェアハウス等のスキーマをコードとして管理し、ソース管理・差分デプロイできる仕組み(SQL プロジェクト)。

    前提: ウェアハウス(Fabric Warehouse)

  • モデルベンチマーク比較

    精度・コヒーレンス・コスト・スループットなどの指標で言語モデルを比較し、用途に合う候補を選ぶための評価。

    前提: 性能の指標(IOPS/スループット/帯域幅/レイテンシー)

  • コマンドジョブ

    単一のスクリプトを指定の環境・計算・入力で実行する基本のジョブ。パラメーターやデータ入力を渡し、ログで障害を診断する。

  • コンピューティングインスタンス

    個人の開発・ノートブック実行用のマネージド VM。停止してコストを節約でき、ターミナルや Jupyter を備える。

  • データアセット(uri_file/uri_folder/mltable)

    再利用可能でバージョン管理されたデータへの参照。種類は uri_file(単一ファイル)・uri_folder(フォルダー)・mltable(スキーマ付き表形式)。

  • トレースによるフロー評価

    フローの各ステップの入出力・遅延・トークン消費を記録(トレース)し、品質や性能のボトルネックを評価・改善する。

    前提: 性能の指標(IOPS/スループット/帯域幅/レイテンシー)

  • モデルカタログ

    Azure AI Foundry / Azure ML で多数の基盤モデル(OpenAI・Hugging Face・Meta 等)を探索・比較・デプロイできるカタログ。

    前提: Azure Machine Learning

  • モデルレジストリ

    学習済みモデルをバージョン管理し、ステージや系統(リネージ)とともに登録・参照する場所。デプロイ対象の選択に使う。

  • プライマリメトリック

    スイープや AutoML が最適化の良し悪しを判断する指標(例:accuracy・AUC)。最大化/最小化の方向も指定する。

    関連: スイープジョブ(ハイパーパラメーター調整)

  • レジストリ(ワークスペース横断共有)

    モデル・コンポーネント・環境・データを複数のワークスペース間で共有する組織レベルのカタログ。開発から本番へ昇格させる際に使う。

    前提: コンポーネント(再利用可能なステップ)

  • スコアリングスクリプト(init/run)

    デプロイで推論を実装するスクリプト。init() でモデルを読み込み、run() で各リクエストを処理する。MLflow モデルでは不要なことがある。

  • トラフィック分割とブルー/グリーン

    1 つのエンドポイントに複数デプロイを置き、トラフィックを割合配分する。新版へ段階的にロールアウトし、問題時に即ロールバックできる。

  • データ可視化とレポートの種類

    目的に応じてビジュアル(棒・折れ線・円・マトリックス・マップ・KPI)を選ぶ。対話的なレポートと、印刷向けに整形したページネーションレポートがある。

    前提: レポート(Power BI)

  • リレーショナルオブジェクト(ビュー/ストアドプロシージャ)

    テーブルに加え、ビュー(保存したクエリ)、ストアドプロシージャ(手続き)、関数などのデータベースオブジェクトでデータアクセスを構造化する。

    前提: ストアドプロシージャ(Warehouse)

  • 保管時の暗号化(at rest)

    ディスクやオブジェクトストレージ上に保存されているデータを暗号化すること。クラウドの多くのマネージドストレージ(ブロック/ファイル/オブジェクト/DB)はサービス側の鍵管理(KMSなど)と統合した暗号化オプションを持つ。盗難・不正アクセスからデータ本体を守る基本対策。

  • 転送時の暗号化(in transit)

    ネットワーク経路を通過中のデータを暗号化すること。多くの場合TLSで通信を保護する。保管時の暗号化と組み合わせて初めて、データのライフサイクル全体(保存中・移動中)を防御できるため、両方を満たすのがセキュリティの基本要件となる。

    前提: 保管時の暗号化(at rest)

  • エンドースメント(推奨/認定)

    信頼できるアイテムに「推奨済み」「認定済み」の印を付け、利用者が良質なデータを見分けられるようにするガバナンス機能。

  • 完全読み込みと増分読み込み

    完全読み込みは毎回すべてを入れ替える方式、増分読み込みは前回以降の変更分だけを取り込む方式(ウォーターマークや CDC を使う)。大量データでは増分が効率的。

    関連: ウォーターマーク(増分の基準)

  • 水平スケーリング(スケールアウト)

    インスタンスの台数を増やして負荷を分散するスケーリング方式。ステートレス設計とロードバランサ・Auto Scalingが前提になり、1台の故障がシステム全体に影響しにくいため耐障害性も高まる。クラウドネイティブな設計では基本の方向性とされる。

  • 増分更新(セマンティックモデル)

    モデル更新で、変更のあった最近の区画だけを取り込み、過去分は再取得しない仕組み。更新時間とリソースを大幅に削減する。

    前提: セマンティックモデル

  • KQL(Kusto Query Language)

    ログ/時系列データを高速に検索・集計する読み取り専用のクエリ言語。Eventhouse/KQL データベースで使う。

    前提: Eventhouse(KQL データベース)

  • 大規模セマンティックモデル形式

    大きなモデルを扱うためのストレージ形式。サイズ上限を引き上げ、XMLA 書き込みや一部の高度機能を可能にする。

    前提: セマンティックモデル

  • マネージド ID

    シークレットの管理なしにアプリが Azure リソースへ安全にアクセスできる ID。Azure が自動管理するサービスプリンシパル。

  • モデルのリレーションシップ

    テーブル間の結び付き。ファクト↔ディメンションは原則 1 対多・単一方向。双方向クロスフィルターは必要時のみ(曖昧さや性能低下に注意)。

    前提: ファクトテーブル

  • モデルの行レベルセキュリティ(ロール)

    セマンティックモデルにロールを定義し、DAX 述語で各ユーザーが見られる行を制限する。動的 RLS は USERPRINCIPALNAME 等で当人の行に絞る。

    前提: セマンティックモデル

  • 機密データ保護(PII / マスキング)

    PII(個人を特定できる情報)や PHI などの機密データを守る運用。Macie で検出・分類し、暗号化・アクセス制御・最小化で保護。マスキング/トークン化で値を秘匿し、データ分類に応じて扱いを変える。ログへの機密混入も防ぐ。

  • パイプラインのパラメーターと動的式

    実行時に値を渡すパラメーターと、式でその値を組み立てる動的式。同じパイプラインを環境や対象を変えて再利用できる。

  • Real-Time ハブ

    組織内のストリーミング/イベントデータを一覧・発見し、接続できる中央の入口。Real-Time Intelligence の起点。

    前提: Real-Time Intelligence(リアルタイムインテリジェンス)

  • リレーショナルデータベース

    データをテーブルに格納し、キーでテーブル間を関連づけるDB。SQL で操作。

    前提: RELATED(DAX)

  • 再試行ポリシー

    一時的な障害(ネットワーク瞬断など)に対し、アクティビティを自動で再実行する設定。失敗パスと組み合わせて堅牢化する。

  • 再利用アセット(.pbit / .pbids)

    .pbit=Power BI テンプレート(モデル/レイアウトのひな形)、.pbids=データソース接続定義。共有して同じ構成を再利用する。

    前提: Microsoft Power BI

  • Spark 構造化ストリーミング

    Spark でストリーミングデータをバッチに似た記述で連続処理する方式。ノートブックで複雑なストリーム変換を書ける。

  • ストリーム処理

    イベントを到着順にほぼリアルタイムで処理する方式。低遅延が要る場面に。例:センサー警報。

    前提: 性能の指標(IOPS/スループット/帯域幅/レイテンシー)

  • 垂直スケーリング(スケールアップ)

    1台のインスタンスのスペック(CPU・メモリ等)を増強するスケーリング方式。アプリの構成変更が少なく手軽だが、インスタンスタイプの上限があり、単一障害点になりやすく、変更時に停止を伴うことが多い。水平スケーリングと対比される選択肢。

    前提: 水平スケーリング(スケールアウト)

  • 統計(Warehouse)

    列の分布情報。クエリオプティマイザーが効率的な実行計画を選ぶのに使う。古い/欠落した統計は遅いクエリの原因になる。

    前提: ウェアハウス(Fabric Warehouse)

  • Z-Order(データスキッピング)

    よく絞り込む列でデータを近くに並べ、読まなくてよいファイルを飛ばせる(データスキッピング)よう最適化する手法。