■前回の記事
■本記事の目的
今回は、Fabricに複数の種類があるデータストアの目的と
どのように選択する戦略を取れば良いかをまとめていきます。
■概要
Fabricのデータストアと選定方法について理解する。
■前提
後付けの前提にはなりますが、
最も選定が分かれるWarehouseとLakehouseを本記事の中心とします。
本記事の内容は、考察を含むため推奨事項ではありません。
■データストアの種類と目的について
公式資料から引用して、主要な部分をまとめと整理しています。
引用：
https://learn.microsoft.com/ja-jp/fabric/fundamentals/decision-guide-data-store
WarehouseとLakehouse以外については、
目的・用途が、特殊で限定的な部分であるため、ここでの選択は迷う部分では
ないと思われます。
■WarehouseとLakehouseの選定ポイント
ここでよくストア選定に困るのが、WarehouseとLakehouseになります。
上記、主要な選考ポイントとしては以下になります。
・インターフェース：T-SQL or Spark
・データ構造：構造化データのみ or 構造化データ以外もある
・トランザクション制御：複数のテーブルでのデータ整合性や処理におけるトランザクション・ロールバックの一貫性を担保する。
ポイントを挙げましたが、
どちらかを一つ選ばなければならないかと言うと、そうではありません。
データフロー、データパイプラインではデータ処理とデータコピー、ショートカット機能では参照を担保できるので、ユースケースやデータによっては、使い分けと共有することが可能です。
これについては、FabricのSaaSのデータ統合基盤の概念とOnelakeの一つのデータを利用するコンセプトの趣旨になっているところであるため、概ね正しいと思われます。
※ケースによって難しい場合もあります
例えば、構造化データのバッチ処理と、その先のノートブックやBIでの分析利用だけであれば、以下のような構成でも良いです。
・Warehouseで、データの中央集権管理を行う。（データハブとして構成）
・Warehouseは、構造化データファイルから取込、蓄積、集約までのプロセスを
ストアドプロシージャとデータパイプラインとの組み合わせでETLワークフローとして構成する。
・Warehouseにストアしたテーブルをショートカットで、Lakehouseに共有し、
Lakehouseではデータアナリストがそのデータをノートブックで利用する。
・ノートブックにてAIで予測したデータの結果を、Lakehouseテーブルに書き込み
データパイプラインでWarehouseにコピーして中央ハブに戻す。
BI分析のためのセマンティックモデルは、
WarehouseおよびLakehouseから構成して発行できるので、
限定した共有の方法についても柔軟な戦略がとれます。
これはワークスペース設計と管理に関わることですが、
ワークスペースを管理者、中間管理者、一般ユーザーのように
部署や役割によって、データ提供の共有方法を構成することで
データガバナンスにおける自治権を構成することが可能です。
また、上記の例のケースの場合、
ファイルデータの配置について、以下のような参照方法があります。
・Azureストレージアカウントの場合
WarehouseのCOPY INTOによるステージング（URI経由）
Lakehouseでのショートカット参照
・サポートされている外部ストレージ（S3,GCSなど）
Lakehouseでのショートカット参照
※LakehouseのFiles上でもファイルをアップロードして管理することは可能ですが、
現時点ではURI経由か外部ストレージのショートカット参照が
効率的な方法ではないでしょうか。
ダウンロード、アップロードは、外部ストレージの方が利便はいいです。
Onelakeエクスプローラーも方法としてはありますが、
使ってみた所感として、同期までのタイムラグの問題など、課題はまだあるようです。
※補足として、
データベース上で処理できることは、
SQLスクリプト（ストアドプロシージャ）で行った方が早いことは、
Warehouseを含め、過去いずれのデータベースでの検証と同様です。
これはデータ量に比例してそのような結果になります。
単純なコピー処理であれば、データパイプラインのようなツールでも良いのですが、
データ変換処理については、速さを求めるならば、
SQLスクリプトを書くことを優先した方が良いです。
但し、変換の内容によって、Python,Pysparkが必要な変換処理もあります。
参考までに筆者で、仕様を確認し、検討した構成の一案になります。
レイクハウスやセマンティックモデルなどのデータ共有レベルを変えることで、
データの統制と自治権を構成することが可能です。
※構成する際は、管理者による共有の設定と調整は必要です。
今回は、考察と備忘の内容となりましたが、
同じようにアーキテクチャに迷われている方の参考になればと思います。
ここまでのFabricの記事の後書きとなりますが、
他の記事やガイドを参照していても、
要件によってネットワークやワークスペースごとのFabric項目、Fabric容量を最適化して設計する必要があるため、
SaaSと言っても、システム構成を考えなければならないことや継続的なメトリクスを行う点は、PaaSや機能分割されたSaaSの時と大きくは変わりません。
プロビジョニング、コスト管理、コンピューティング、ストレージの部分が抽象化されたところはありますが、PaaSの時とは異なるFabric特有の課題に直面しているような状態です。
Fabricにおける機能の役割分担とコンピューティングについては、これは顕著で、パフォーマンスとユーザビリティの均衡を保つための設計という概念が新たに出てきたような印象です。
次回の記事内容は少し検討いたします。
引用：
https://learn.microsoft.com/ja-jp/fabric/onelake/onelake-shortcuts
https://learn.microsoft.com/ja-jp/fabric/onelake/onelake-file-explorer