Fabricへデータ資産をアップグレード Q&A②

前回のQ&Aからやや時間が経過しましたが、残りの部分となります。

ignite.microsoft.com

• Amir Netz
  Technical Fellowという肩書でFabricにおけるCTO（Microsoft歴27年）。Vertipaqエンジンの開発者であり、今のPower BIがあるのは彼のおかげといっても過言ではない（参考記事）。めちゃくちゃパワフルな方で個人的に大ファンです
• Justyna Lucznik
  元々はPower BIのAI（Q&A等）を担当されていたが、FabricではData EngineeringやData Scienceの製品リーダー
• Priya Sathy
  現Data Warehouseの製品リーダー
• Wee Hyong Tok
  データ統合機能（Data Integration）であるData Factory (Data pipelineやDataflow Gen2)の製品リーダー
• Josh Coplan
  元々はSSAS*1やPower BIチームでPremium容量を担当されていたが、現在はOneLakeの製品リーダーを務める

Q7: 容量のサイジングについて

質問: トライアル容量では基盤インフラが明確にならず、また、どの顧客とどの程度共有されるのかもわかりません。

回答: Synapseのように、Fabricでは専用（Dedicated）という概念はなく、正確な表現はサーバーレス環境です。ハードウェアを特定の企業が占有するのではなく、同じコンピュートパワーが複数のサービスで共有され、使用する場合はONにし、使用しない場合はOFFにする運用が行われます。

Q8: Storage as a Serviceについて

質問: "Storage as a Service"という言葉を聞いたことがありますが、メダリオンベースでセマンティックモデルを作成した場合、通常はストレージアカウントを作成します。しかし、Fabricに移行した場合、そのようなストレージをどのように管理し、またAzureに存在するLogic Appsなどの関数を利用できるのでしょうか？

回答: OneLakeはBlob Storageの考え方ではなく、むしろOneDriveと同様に捉えると分かりやすいです。OneLakeは全体のデータレイクとして位置づけられます。もしOneLake以外で既にデータをプロビジョニングした場合、そのデータをそこに残したままでも構いません。代わりにShortcutを使用すれば良いので、ADLS Gen2側でコントロールすることができます。

新しいデータを格納する場合は、直接OneLakeに入れる方が望ましいです。すでに50万のストレージアカウントが用意されており、お客様は単なるストレージを管理するのではなく、OneLakeを管理する立場になります。実質的には、1つの仮想ストレージアカウントを管理する感覚に近いです。

Q9: セキュリティの考え方

質問: OneSeurityが登場するまで、どのようにセキュリティ管理を行えば良いか？

回答: セキュリティ機能は既に存在しており、ワークスペースレベルやアイテム単位のRLS（Row-Level Security）などが備わっています。OneSecurityは、さらに1つ先のレベルの考え方であり、OneLakeに直接アクセスコントロールを行うことができる機能です。これはユニバーサルなセキュリティであり、全ての分析エンジンに適用される機能です。

Q10: サブドメインの考え方

質問: サブドメイン（例: 事業ドメイン等）が多数存在する場合、OneLakeをどのように構成すれば良いでしょうか？

回答: Office環境ではこれまでに同様の作業を行ってきました。SharePointやOneDriveの構成と同じ手法を適用することができます。さらに、Fabricにはドメインという機能が導入されており、それを利用することで適切に対応できるでしょう。各ワークスペースはそれぞれのドメインに紐づいています。

Q11: 参照リソースについて

質問: Fabricのプレビュー期間中に、製品チームによって製品に関する重要なフィードバックとして報告された問題は何ですか？また、これらの問題に関する公式ドキュメントはありますか？

回答: まず、問題の発見に対するご協力、ありがとうございます。プレビューの間に発生した問題が全て解決されたかというと、そうではありません。製品が存在し続ける限り、私たちは問題解決に取り組み続けなければなりません。チームは団結し、問題を特定し、その解決に取り組んでいます。システムの信頼性を常に評価しており、週ごとのFabricの更新は、まさにこれを実現するためです。問題を公表するだけでなく、"Microsoftの製品チームにこのような機能を搭載してほしい”というフィードバックを受け取り、それを実現するためにあらゆるレベルでレビューを行います。そのために製品チームは、投票されたアイデアのトップリストを見直し、投資すべき分野かどうか、それが今期または次期に実現できるかを判断しています。投票数の多いアイデアは実現可能性が高くなりますので、ぜひ新しい機能に関するアイデアを投稿してください。
https://ideas.fabric.microsoft.com/

なお、ストレステスト*2に関する結果はあまり公開することはありませんが、これらのストレステストは毎日実施しています。最も重要な目的は、Fabricチームが継続的にシステムの信頼性や品質を評価し、それらが常に改善されていることを確認することです。

Q12: 新機能のサポートについて

質問: OneLakeにおけるDelta Parquet形式のデータについて、Upsert*3やバージョン管理、タイムトラベル*4、バキューム*5などのオープンソース機能をWarehouseサイドでサポートする予定はありますか？

回答: これらの機能は段階的に全てサポートされる予定です。T-SQLでDeltaとSparkで可能になっている機能に近い機能をサポートする予定です。Upsertについては2024年3月に向けて最初のステップとなる予定です。

Q13: 製品選択のアドバイスについて

質問: DatabricksとFabricのどちらを選択すべきか迷っていますが、何かガイダンスのようなものはありますか？Fabricの方がよりユーザーフレンドリーな気がしますが、いかがでしょう？

回答: まず、我々は製品チームがFabricにバイアスを持っているのはいうまでもないことですので、理解して頂けると思います（笑）。Fabricが目指す野望は非常に広大で、完全なエンドツーエンドのデータ分析基盤となります。

OneLakeのアプローチはFabricにとって非常に特異であり、かつそれはFabricの核心であり、どこにデータがあろうともそれに接続できます。現時点では、他のベンダーにはこのようなSaaS*6型のデータレイクがなく、ユーザーフレンドリーであるというコメントがあったように、FabricはPaaS*7製品とは異なり、SaaS製品として設計されています。従って、お客様が各種のパーツを選択して組み合わせてサービスを機能させる代わりに、Fabricではこれらのパーツが既に統合され、お互いに機能する状態にあることが強調すべき点です。

SaaSの世界では、生産性、out-of-the-box（最初から備わっている）の統合機能、自動チューニング、自動最適化、インフラストラクチャーの抽象化が重要視されます。Fabricは抽象化を次の次元に引き上げることを目指しており、AWSやGCP、Azureのようなサービスとではなく、Office 365と同じアプローチを持っていると考える方が良いでしょう。

Q14: コスト管理について

質問: 顧客からの質問を代表させていただきますが、Fabricにおいて他の各種サービス（Databricks、Data Factory、専用SQLプールなど）で発生するコストをどのように管理できるのでしょうか？コストをFabricに適用する方法について教えていただけますか？

回答: まず、コストをどのように見積もるかという質問に答えることは非常に難しいものです。一方、既に各種サービスを使用して支払っているコストをFabricにマッチする方法についての質問はそれほど難しくありません。なぜなら、内部で各種サービスで発生するコストに対するコストパフォーマンスのベンチマークを持っているため、市場の他のサービスの料金と比較できるからです。重要なのは、製品チームでは常にそれらの指標でFabricが競争優位を持つことを意識し、確認していることです。たとえば、他のテクノロジーで使用されるワークロードを使う場合、Fabricでは同じサービスでのコストがより安価になるように努めています。PaaSとSaaSの違いにより、具体的にどれだけ安くなるかはお伝えできませんが、安価になることは確かです。

Spark

Sparkに関してはAzure Synapseで使用された場合の料金よりも大幅にディスカウントされ、より安くなるようにデザインされています。

Data Factory

Data Factoryでは3つのBilling Meter（課金メーター）*8があります。1) Data movement、2) オーケストレーション、そして3) Dataflow Gen2における標準のコンピュートがそれに当たります（Azure Synapseではさらに多くのBilling Typeが存在します）。また、Azure Data Factory(ADF)で発生する料金とFabricで発生する料金は、CU（Compute Unit）という形で計測されますが、Fabricの方がADFよりも大幅に安価であることを確認しています。

Warehouse

SQLプールに関しては以下が重要です。まず、専用SQLプールとFabricの比較ベンチマークを行っています。結果から言えることは、同じ料金を支払う場合、ベンチマークの結果によりFabricではより高いパフォーマンスが得られることです。また、Fabricではより良いコンカーレンシー（同時接続）の結果を得られるため、TOC（Total Cost of Ownership）ベースで見た場合、専用SQLプールよりも優れていると言えます。

OneLake

OneLakeに関しては、ADLS Gen2の価格（GB当たりの単価）と合わせて考慮されています。トランザクションについては異なるアプローチを取っており、1単位当たりのトランザクションコストは同じですが、Fabricではトランザクションごとの個別の課金は行いません。つまり、ADLS Gen2ではサーバーレスモデルであり、トランザクションごとに異なるMeterが提供され、それに応じて課金されるのに対して、Fabricでは既にコンピュートと容量が存在するため、その容量のプールから情報を取得し、その容量に対して支払いを行うことになります（一部未定情報あり）。強調したいのは、効率性です。OneLakeの存在により、One Copy（重複なしのデータを使う）の概念が生まれ、異なるエンジン全てから利用可能となり、効率性が大幅に向上し、トータルコストに影響を与えることでしょう。Fabricを使用することでデータの移動や重複を回避でき、Power BIへのデータインポート（Direct Lakeモード）に必要な手間が不要になるため、多くの時間を節約できるだけでなく、通常の重複によるコストを削減できる場面もあります。

Q15: Power BIとFabricの容量について

質問: Fabricを導入した場合、Power BI Premiumを使用している場合にはどのような影響があるのでしょうか？異なるTierは存在しますか？

回答: Power BI PremiumはFabricの容量そのものであり、Power BI PremiumのP1はFabricのF64と同等です。Power BI Premium容量を使用している顧客は、そのままFabricのワークロードを利用できます。ただし、FabricのF64を購入した場合でも、P1よりも優れた機能が提供されるわけではありません。Tierに関しては、F2からF2048までの幅広い範囲の提供があります。

Q16: Fabricの更新アプローチについて

質問: Power BIは毎月新しいアップデートがあり、プレビュー機能をオン／オフにすることができますが、Fabricでも同様のアプローチが取られていますか（ワークスペースレベルで）？

回答: SaaSのアプローチを取っているため、基本的にPower BIと同様の考え方を採用しています。リリースの頻度は週次となっており、Power BIよりも早いサイクルでのリリースを行っていますが、変更内容については月次のブログでまとめて公開しています。

Q17: データエクスポートのコストについて

質問: OneLakeというシナリオは非常に優れたものだと考えますが、データをエクスポートする際にもコストが発生するのでしょうか？

回答: ADLS Gen2と同様のアプローチを取るため、データをエクスポートする際には Egress Charge（出口料金）が発生する見込みです。

Q18: 異なるエンジンについて

質問: ADX*9についてあまり聞かないですが、Fabricとのマッチングについて、ADXとServerless SQL*10、SQL Warehouse*11の違いを例として教えていただけますか？

回答: ADXはAzure Data Explorerの略称で、テレメトリーデータやストリーミングデータ、半構造化データ（JSON）などを処理します。実際、MicrosoftのすべてのクラウドサービスはそのテレメトリーデータをADXサービスに保管しており、KQL（Kusto Query Language）*12という言語を使用して、Kustoデータベースに保存されています。これまではMicrosoft内での秘密兵器とされていましたが、Fabricを見ると、同じテクノロジーのKQLデータベースが存在していることに気付くでしょう。KQL Databaseは診断やテレメトリー関連のイベント分析、時系列分析など、DevOps*13に従事する人々にとって非常に有用なサービスです。

一方、FabricのWarehouseは財務データベースなどのトランザクション処理に利用できますが、より伝統的なリレーショナル・データベースであり、ストアドプロシージャ*14などを使用します。そのため、利用するデータベースは使用ケースに応じて変えていくことが重要です。

Q19: Synapseの将来とFabricの世界観について

質問: SynapseとFabricについて、どのような考えていけば良いか悩んでいます。Synapseは全てからPower BIを除外したものと理解しており、FabricのエコシステムをPower BIのエコシステムを理解している人間がどのように推進していけるかを考えています。また、Synapseの将来のロードマップについても心配しています。

回答: Synapseの機能を廃止する予定は今のところありません。もしSynapseの体験が良いと思うのであれば、Synapseを引き続き利用しても問題ありません。ただし、Microsoftの現在のデータ戦略はSaaS型データ基盤を重視しており、それを実現するのがFabricです。このため、さまざまなサービスが改良されており、例えばPower BIではDirect Lakeモードが導入されたり、Data WarehouseではParquet形式でのデータストアが行われたり、SparkやData Integration（データパイプライン）がSaaS化されたりしています。さらにV-order最適化や認証管理、テナントレベルの管理が行われています。これらの機能はAzureの世界からFabricの世界に移植されたものですが、SaaS化されたことでより利用しやすくなり、より深く統合されたものになっています。これらの試みはAIの時代に適したものであると考えられています。

Q20: マッピングデータフローについて

質問: Azure Data Factory (ADF)のマッピングデータフローは現在Fabricには存在していません。この機能をFabricに統合するための投資について、検討されていますでしょうか？

回答: ADFのマッピングデータフローをお客様が何年にもわたって利用してきたことをうれしく思います。Data Factoryチームが行った決断の一つとして、データ変換の能力を強化するためにDataflow Gen2への投資を行うことを選択しました。そのためには、マッピングデータフローを活用しているお客様に変更の理由や展望について責任を持って説明することが重要です。

まず、ADFのマッピングデータフローを使用している場合、マッピングデータフローでOneLakeやWarehouseへの書き込みが可能となる会話が行われました。次に、マッピングデータフローをSparkコードに変換して再利用することを可能にしています。つまり、オープンソースとしてGithubにあるマッピングデータフローをSparkコードに変換し、それをFabric内のnotebookで活用するということです（現在80%完了しています）。現在、ISV*15や顧客と協力しながら、ユーザーエクスペリエンスを向上させるための改善を継続的に行っています。最後に、マッピングデータフローをDataflow Gen2の体験と融合して提供していく予定ですが、互換性の問題などから、これには時間がかかる見込みです。

なお、現時点では、Azure Data FactoryをFabricにマウント*16することで、マッピングデータフローをそのまま活用できます。マッピングデータフローをアップグレードするまで、この機能を引き続き使用できますが、アップグレードには時間がかかる見込みです。

Q21: OneLakeへの書き込みについて

質問: OneLakeへの書き込みは素晴らしいコンセプトですが、現在はSparkとSQLのみがサポートされているようです。他のエクスペリエンスでもこの機能が提供される予定はありますか？

回答: もちろんです。最近、Power BIのインポートモードでのセマンティックモデルをDelta Parquet形式に書き込む機能を発表しました。また、APIを追加することで、ISVやサードパーティがDeltaテーブルに書き込むことも可能です。ADLS Gen2と互換性のあるアプリケーション（OneLake Explorer）を使用すれば、書き込みが行えます。

*1:SQL Servier Analysis Services

*2:システムやソフトウェアが許容できる負荷やストレスの限界を評価するためのテスト手法です。通常、システムが予期しない状況に耐え、どの程度の負荷やトラフィックを処理できるかを確認するために行われます。これにより、システムのパフォーマンス、信頼性、安定性が評価され、問題を特定することができます。ストレステストは、ユーザー数の急増、大量のデータ処理、トラフィックのピーク時など、システムが最大負荷に耐えられるかどうかを確認する際に有用です

*3:データベースのテーブルにレコードが存在しない場合はそのレコードを新規挿入（INSERT）し、レコードが既に存在する場合は既存のレコードを更新（UPDATE）する処理

*4:Delta Lakeのタイムトラベル機能は、データの履歴を管理するための機能です。これにより、過去のデータの状態を特定の時点に戻したり、以前のデータバージョンを照会したりできます

*5:Delta Lakeのトランザクションログに記録された過去の変更を元に、データの物理的な削除とデータファイルの最適化を行います

*6:Software as a Service：「サース」または「サーズ」と呼びます。ソフトウェアを利用者（クライアント）側に導入するのではなく、提供者（サーバー）側で稼働しているソフトウェアを、インターネット等のネットワーク経由で、利用者がサービスとして利用する状況を指します

*7:Platform as a Serviceの略語で「パース」と読みます。 PaaSは仮想化されたアプリケーションサーバやデータベースなど、アプリケーション実行用のプラットフォーム機能をインターネット上のサービスとして提供を行うもの

*8:クラウドサービスやプラットフォームで発生する利用料金を計測し、請求するための指標や計算単位

*9:高速な大規模データ解析向けに設計され、リアルタイムのデータ分析とクエリ処理に特化

*10:データレイク上のデータに対して、SQL構文を使ってクエリを実行できるサーバーレスなSQLサービスです。構造化されたデータを処理する際に利用されます

*11:大規模なデータウェアハウスや分析向けに設計されており、異なるデータソースからのデータを統合して処理・分析するのに最適

*12:Microsoftが開発したデータ分析用のクエリ言語です。主に大量のデータを高速かつ効率的にクエリして分析するために使用されます。KQLはAzure Data Explorer（ADX）などのプラットフォームで広く使用されており、テーブルやタイムスタンプデータなどの複雑なデータ構造をサポートしています。データのフィルタリング、集約、結合などの操作を行うための強力なクエリ機能を提供しています。

*13:開発（Development）と運用（Operations）を組み合わせた造語。 開発担当と運用担当が緊密に連携して、柔軟かつスピーディーにシステム開発を行う手法

*14:ストアードプロシージャ（Stored Procedure）は、データベース内に保存された事前にコンパイルされたSQLクエリや手続きの塊です。これらは一連のSQL文を1つのプログラムとしてまとめ、データベース内で実行できるようにします。Power Queryで言うところのカスタム関数に相当します

*15:Independent Software Vendorの略。システム開発業界などにおけるソフトウェアの開発・販売会社の分類の一つで、コンピュータメーカーなどのプラットフォーム事業者以外の、また、それらの傘下にない独立系企業のこと。特に、受託開発事業者ではなくパッケージソフトの開発・販売元のことを指すことが多い

*16:Fabric のユーザーインターフェースにおいて、ADFの中身を操作できるようになること