DP600に4日で挑む
つぶやき
余裕のある準備なんてできるたちじゃないので、4日でDP600を果たして合格まで持っていけるか
内容が更新される前に受けたかった。内容が更新されてからは難しくなっているらしい、最悪。
参考資料も見つかるのは更新前のものばかり、Udemyも怪しい問題集しかない、詰みか?
ノートを書いていて思った。日本語の論文ってこんな感じ?きついな
使った資料
1、有志のDP600ノート(更新前)
↑これ読むだけで合格率50%まで持っていけた2、有志のDP600ノート(更新後)(英語)
ノート
1. セキュリティとガバナンス
ワークスペースレベルアクセス
EntraID又はM365でワークスペースを共有することができる。
この場合ユーザーはワークスペース内のすべてにアクセス権がある
共有するときロールを振り分けられる
- Admin
- Member(ワークスペースの更新、削除、人の追加、削除ができない)
- Contributor(+ウェアハウス、データベースミラーリングが作れない)
- Viewer(読み取りしかできない)
ワークスペースを作った人はAdmin、複数のロールがある場合、管理権限が高いほうが優先される
アイテムレベルアクセス
アイテムとはワークスペース内のウェアハウスとか、データフローとかのやつ
ワークスペースすべてを共有したくない場合、アイテムレベルでアクセス制限ができる(例外:データパイプライン、データフロー)
アイテムごとに共有の仕方と共有のレベルが異なってくる
アイテムのアクセスをもらったユーザー(グループ)はOneLakeデータHubを通してアクセスする
例:ウェアハウスの共有
- 読み取り:規定。ウェアハウスへのアクセスはできるが、ウェアハウス内のテーブルにはアクセスできない。この読み取り制限をした後、見せたいテーブルだけを許可する(オブジェクトレベルセキュリティ)など、細かいアクセス制御ができる
- データ読み取り:TSQLエンドポイントを通して、ユーザーはウェアハウス内のすべてのテーブルを見ることができる
- All読み取り:ウェアハウスの下にあるOnelakeのファイルなども見れるようになる。ほかエンジンからの読み取りも可能になるということ(Sparkからとか)
- ビルド:ユーザーはこのウェアハウスをもとに、既定のセマンティックモデルからレポートを作成することができる
RLS, OLS, CLS, ファイルレベルアクセスコントロール
T-SQL分析エンドポイント又はウェアハウスを通じて、テーブルに、行レベルセキュリティ(RLS)、オブジェクトレベルセキュリティ(OLS)、列レベルセキュリティ(CLS)を課すことができる
(余談)セマンティックモデルでも上記の三つの細かいアクセス制限ができる。(テストには出ないっぽい)
※注意
-
たとえウェアハウスでアクセス制限をかけても、セマンティックモデルに反映されるわけではない。セマンティックモデルもう一度アクセスをかける必要がある。しなくてもよくなるようにMicrosoftが頑張っているらしい
-
RLSアクセス制御がオンになっているウェアハウスにDirect LakeモードでPowerBIからクエリを繋げる場合、Direct Queryモードにフォールバックする。(RLSを遵守するため)よくわからん
- Copilot:Direct Lakeモードでは、データレイク上のデータに対して直接クエリを実行することができます
ファイルレベルアクセスコントロールはLakehouse上にしか存在しない。(なぜならファイルはレイクハウスにのみ存在するからである!)
例:RLSをウェアハウスにかける方法
- スキーマを作る(外枠)
CREATE SCHEMA Security;
- RLS用のファンクションを作る
CREATE FUNCTION Security.f_FilterRowsForLoggedInUser(@SalesRep AS varchar(100))
RETURNS TABLE
WITH SCHEMABINDING
AS
RETURN SELECT 1 AS f_FilterResult
WHERE @SalesRep = USER_NAME() OR IS_ROLEMEMBER('manager') = 1;
GO;
- セキュリティポリシーを作る
CREATE SECURITY POLICY SalesRowFilterPolicy
ADD FILTER PREDICATE Security.f_FilterRowsForLoggedInUser(SalesRep)
ON Sales.Orders
WITH (STATE = ON);
例:CLS&OLSをウェアハウスにかける方法
アクセスをかけられる側のユーザーの権限は読み取りのみの必要がある。
(ワークスペースレベルの権限を持っていない、ウェアハウスからは追加権限を渡していない、など)
OLS
- GRANTステートメントを使う(以下例はSELECTの使用を許可している)
GRANT SELECT ON Sales.Orders TO [SalesReps];
CLS
- 同じくGRANTステートメント。今度はSELECTの使用を特定のテーブルや列(Column)にのみ与えている
GRANT SELECT ON Sales.CustomerDetails
(CustomerId, AccountCreationDate)
TO [SalesReps];
例:ファイルベースアクセス(レイクハウス用)(プレビュー)
admins, members, contributorsがファイルベースのアクセスができる
- ロール作り
どのテーブルとファイルを共有したいか選択する(ディスコードのロール作りみたいな感じ) - メンバー又はグループをロールに追加する
秘密度ラベル
データガバナンスの一環で、Microsoft Purviewの機能の一つ
ファブリック内では、アイテムごとに、例えばセマンティックモデルに「社外秘」のようなラベルを張ることで情報漏洩対策ができる
コンプラ順守のため、秘密度ラベルを取り入れる企業は増えてるよー
アイテムの承認
承認度をアイテムに振り分けることができるっぽい(?)
プロモート(Promoted)、認定(Certified)、マスターデータ(Master data)の3つの承認バッジがある
- Promoted:このバッジがある場合は、このアイテムが共有、又は再利用の準備ができているということ。書き込み許可があるユーザーはアイテムにこのバッジを付与することができる
- Certified:このバッジがある場合は、組織から、組織の品質レベルに達していると認定してもらえた状態。つまり、このアイテムは信頼でき、承認されていて、組織内で使うことができる状態を指す。
どのユーザーもアイテムの認定リクエストをすることができるが、管理者からアサインされた特定のユーザーのみアイテムを認定することができるそう。 - Master Data:このバッジがある場合はつまり、このアイテムが組織のコアデータ(マスターデータ)であることを指す。プロダクトのソースコードとか、人事データとか、顧客リストとか、、、
このバッジはデータがあるアイテム、レイクハウスとかセマンティックモデルなどにのみ与えることができる。そして管理者からアサインされた特定のユーザーにのみ、アイテムにこのバッジの付与ができる
まとめると、
全てのFabricアイテムとPowerBIアイテム(Dashboradを除く)はPromotedとCertifiedのバッジをつけることができる。
データが入っているアイテム(レイクハウスやセマンティックモデル)にのみMasterDataバッジをつけることができる
そして、CertifiedとMasterDataバッジは管理者からアサインされたユーザーにのみ、許可ができる。
分析的開発のライフサイクル
バージョン管理の設定
Gitでのバージョン管理は
- Fabricアイテムの変更を追跡できる
- 昔のバージョンにアイテムを戻せる
- 複数のユーザーが同じFabricのアイテムで共同作業できる
- チェックとか承認プロセスをアイテムに追加することができる
- Azure DevOps又はGitHubでできるよ
Power BIプロジェクト(.pbip)
.pbip はPowerBIのセマンティックモデルとレポートを保存するときの拡張子(BI Desktopは.pbixだった 多分)
.pbipのいいところ:テキストベースらしい。だからバージョン管理にも組み込めるのだとか
.pbipはセマンティックモデル(TMSL:Tabular Model Scripting LanguageまたはTMDL:Tabular Model Definition Language形式)とレポート(.pbir) の両方を保存できる
Fabricでセマンティックモデルやレポートを作った場合、.pbipに規定で保存される。セマンティックモデルは既定でTMSL形式
.pbixはPower BI Desktopで.pbipに変換できる
管理パイプライン(Fabricの機能の一つ)
管理パイプラインのゴールは新しい管理レイヤーを足してあげることにより、新しい開発フェーズを足しても元の分析結果を壊すようなことにならないためである。
よく聞く Dev, Test/staging, Prodである。
開発フェーズは管理パイプラインを使用することで、アイテムをワークスペースを横切ってコピーすることができる
開発のルールもステージごとの変化に合わせて作ることができる
管理パイプラインを使う以外にも同じようなことができるという
- Branchingを使用する
- Azure DevOpsパイプラインを使用する
- (セマンティックモデル用)XMLAエンドポイントを使用する
影響分析(Fabricの機能の一つ)
Lineage View(系統ビュー)はすべてのワークスペースから見ることができる。アイテムを視覚的にみることができて、それぞれの依存関係をも見ることができる。
影響分析を使うと、ワークスペースの各アイテムの依存関係を確認することができて、例えばアイテムXに変化を及ぼした場合、他のどんなアイテムが影響を受ける可能性があるか、なども見ることができる
変更があった際、通知を送る機能もあるよ
セマンティックモデルのデプロイ(XMLAエンドポイント)
XMLAエンドポイントとは、Fabricのワークスペースを第三者のツールとつなげるときの接続方法なんだそう。エンドポイントの詳細はワークスペースの設定から確認することができる。
XMLAエンドポイントを使用して、第三者のツールからFabricワークスペースにセマンティックモデルをデプロイすることもできる
容量に関係なく、どのワークスペースにもXMLAエンドポイントは存在する。
PowerBIアセットの作り方
.pbit
PowerBIのテンプレートファイル形式。再利用可能なアセットになる
.pbix(PowerBIレポート)から簡単に.pbit(テンプレート)を作ることができる。.pbitから新しいレポートを作るときにデータ元を聞かれるようになる。
.pbids
PowerBIデータソースファイル
PowerBIデスクトップのデータソース設定から、データ接続の設定地などをすべてエクスポートできる。ほかのプロジェクトで再利用したりできる。
セマンティックモデルの共有
セマンティックモデルの共有をすると、違うユースケースの時にセマンティックモデルの再利用ができるようになる。例えばモデルの管理は一か所でやるとして、そのモデルは他のレポートやダッシュボードでも使えるようになるということ。
データ取得
データ接続
データ接続は内部や外部からの接続を中央にまとめることができる(OneLake)
データ接続は以下の場面で使われる
- データフロー、データパイプラインを使用したデータ取得をする場合
- セマンティックモデルからFabric内のデータ(Or外部)と接続する場合
接続は、クラウドでも、オンプレミスでも、仮想ネットワーク間でもできる
データゲートウェイを使うことで、保護されたアクセスをオンプレミス又はAzure上の仮想ネットワークやファイヤーウォールで保護されたデータにアクセスすることができる
ただし、オンプレミス上(サーバーまたはデータベース)にあるデータを取得する場合、オンプレミス側にデータゲートウェイをインストールする必要がある
- データゲートウェイをオンプレミス側のサーバーにインストールする
- Fabric側で、オンプレミスデータゲートウェイ接続を作る必要がある
- ゲートウェイを使って、データフローもしくはデータパイプラインからデータを取得する
Azure上に保管されたデータから接続するには、仮想ネットワークデータゲートウェイが必要
- Azure上でネットワーク設定をします。
- Power Platformリソースプロバイダーを登録
- Azureのオブジェクトにプライベートエンドポイントを作成
- サブネットを作成
- Fabricで新たな仮想ネットワークデータゲートウェイ接続を作成
- ゲートウェイを使って、データフローもしくはデータパイプラインからデータを取得する
OneLakeカタログ、リアルタイムハブについて
OneLakeカタログ(前はOnalake data hubだった)
Onelakeカタログの役目:データの発見、管理、使用を組織内で
組織内でのデータをドメインごとに、ワークスペースごと、秘密度ラベルごとに調べることができる
もっとも重要なのは、アイテムアクセスレベルの権限を渡されたユーザーはこのOneLake カタログからしかデータのアクセスができない(ワークスペースへの権限がないため)
リアルタイムハブ
同様に、リアルタイムハブは上記と同じような機能を備えているけど、配信データに焦点を当てられている。KQLテーブルや、配信などのアクションが許可されたものをリストに挙げてくれる。Microsoftの商品や、Fabric Eventなどからの配信データの取り込みが簡単にできるそう。
Discussion