第20回では「10年戦えるデータ分析入門」と題して、『10年戦えるデータ分析入門』の著者である青木峰郎氏と、Treasure DataのChief Architectを務める古橋貞行氏に、10年先でも戦えるアーキテクチャとはどのようなものなのか、詳しくお話していただきました。
今回の勉強会では、日本マイクロソフト株式会社のお二人にご登壇いただき、Microsoft Azureの概要や特徴についてお話していただきます。また、最近話題の生成AIを活用したMicrosoft Fabricについて、その特徴や活用方法を詳しく解説していただきます。
第20回は「Azureのデータ分析サービスの現在と未来」と題して、Microsoft Azureが現在提供しているサービスの概要・特長や、新たなSaaS型データ分析ソリューション Microsoft Fabricについてお話していただきます。
前半の講演では、日本マイクロソフト株式会社 カスタマーサクセス事業本部 クラウドソリューションアーキテクトの武田雅生氏に、データ分析基盤でよく使われるPaaSサービス群に焦点を当て、それぞれの特長を詳しく解説していただきます。
後半の講演では、同じく日本マイクロソフト株式会社 カスタマーサクセス事業本部 クラウドソリューションアーキテクトの中里 浩之氏に、Power BI のデータ分析機能を SaaS として提供し、さらに Azure OpenAI ベースの AI Copilot を導入した「Microsoft Fabric」の概要と特長についてご紹介していただきます。
講演1「Microsoft Azure の主要な PaaS データ分析サービス」
武田雅生 氏
日本マイクロソフト株式会社 カスタマーサクセス事業本部 クラウドソリューションアーキテクト

武田氏:「本日は、特にData&AI系についての話をしたいと思います。5年前、10年前から現在にかけて、サービスのアップデートもそうですし、大きなデータ界隈のトレンドが変わってきていると思います。
(本日の講演では)サービスを取り上げてトレンドの変化を感じつつ、少しでもインサイトがあり、興味を持っていただければと思っております。」
Azure データサービスの概要
武田氏:「まずはじめに、Azureのデータサービスのラインナップをお見せしたいと思います。
今となっては、Azureはさまざまなデータサービスを展開していますが、Azureが出てきた当初は、PaaSサービスはAzure SQLデータベースと呼ばれるものが一つあるだけでした。そこから、さまざまな機能拡張が行われ、非常に多くのモデルタイプの中からお客様のワークロードに適したものを選択できるようになりました。
Analyticsの点で言いますと、Azure Data FactoryはETLをGUIで使う上では、非常にさまざまなことができるようになっています。そのほかにも、ストリーミング系やマシンラーニング系、そしてOpenAIのAzureサービス等々が展開されています。最近では、特にAzure Databricksでアップデートが多く出てきています。
最近お問い合わせが多いData Catalog(Governance)では、Azure Purviewと呼ばれるサービスやデータシェアリング系のサービスも出てきています。こういったサービスは、それぞれが機能拡張をしているだけではなく、さまざまなデータソースを分析したい時に、サービス間の横連携をする機能や、自動的に内部で分析用のデータストアを作り出してくれる機能も非常に多く出てきている状況です。」
Databricks社の始まり
武田氏:「本日は、アップデートが特に多い、Databricksの話を中心にしていきたいと思います。Azure Databricksはトレンド変換や最新のアップデートを遂げているため、”最初にどういった形で開発されて、今どうなってるのか”にフォーカスをして説明していきます。
Databricksと呼ばれるソリューションを展開する会社が作られたのは2013年です。UC バークレーの研究生7人によって設立された会社です。彼らは数年前からApache Sparkと呼ばれる分散処理のフレームワークを開発しており、Apache Sparkを広めるためにDatabricks社が設立され、現在ではMicrosoftとパートナーシップを結んでいます。」
Spark 誕生のきっかけ
武田氏:「ただ、このSpark自体をゼロから開発されたわけではなく、CEOのAliさんとCTOのMateiさんが、当時GoogleファイルシステムやMapReduceの論文を見たときに、強く感銘を受けました。とくに、データセンター上に多数のマシンを並べてストレージ上の仕組みを作ったり、並列分散のフレームワークを作ったりすることで、高速かつ耐障害性のある点に強く感銘を受けました。
彼らとしては、それをインメモリでイテレイティブに処理をすることが、よりイノベーティブだろうと考え、その発想からSparkが生まれました。」
Databricks 設立当初のビジョン
武田氏:「Databricksの当初のビジョンは、非常に異彩を放っており、変革的なところがありました。たとえば、もちろんSparkを広めたい思いもありましたし、できるだけビッグデータのソリューションを複雑なコンフィグなしにスケーラブルに展開したいおもいもありました。また、データとAIの統合によって、「サイエンティストとデータエンジニアリングの方々とのギャップを埋めたい」思いから、(両者が)コラボレーションするような機会にしてほしいといったビジョンがありました。
ただ、当時とくに異彩を放っていたのは、End-to-Endのデータソリューションである点でした。Databricksは当時、データの収集・格納・加工をして分析を行い、モデル作って展開をする、あるいはBIで情報提供する、ライフサイクル全体をカバーしていました。
当時のDatabricksが提供しているコンポーネントとしては、非常に大規模なバッチ処理のETLの部分的なところが現実的でしたが、それ以外もカバーする点は一つのPaaSサービスとして異彩を放っていました。」
2013年当時のクラウドベンダー各社のサービス
武田氏:「2013年当時のクラウドベータ各社のサービスを見てみると、やはりAWSをはじめとして、役割特化の各PaaSサービスをいかに組み合わせるかが重要でした。マイクロサービス由来のアーキテクチャおよび適材適所の概念が基本デスクだったと思いますし、今でもその流れはベースラインとしてあると思います。
ところが、一つのPaaSサービスでさまざまなことをできるようにしていく考え方は、他のサービスと設計思想が異なるため、扱いづらい印象がありました。また、Databricksはアーキテクチャの中の一つの役割としてアーキテクチャに組み込まれるのがやっぱり当時のリファレンスであり、今でもそういった流れがあるのかなと思っています。」
2023年のAzure Databricks 全体像
武田氏:「現在のAzure Databricksは何ができるのか、機能単位で説明していきます。
Azure Databricksは、よくSnowflakeやBigQuery、Redshiftなどと比較されますが、基本としては、Single Source of Truthで1箇所にデータを集める考え方です。そのため、さまざまなファイルをストレージに配置する時に、そのファイルに対してトランザクションや、タイムトラベル、チェンジデータフィールドができる拡張をしております。
デルタリンクの3.0バージョンを使うと、ユニフォームと呼ばれる機能によって、デルタフォーマットでそのファイルをiceberg等としても使える拡張性を持っています。
そして、マルチクラスターかつオートスケール、およびサーバーレスでそのファイルを扱える機能があります。これによって、
- バッチのETLやストリーミング
- データベースに対するSQLのアドホックなクエリやBI
- マシンラーニングのモデルトレイン
- プレディクト(最近ではllmの開発)
こういったものが、それぞれ混在ワークロードになることなく、クラスターを使って処理できる点において、マルチクラスターが非常に重要です。
バッチETLとストリーミングの機能は、言語としてはマルチ言語で対応したり、上図にアイコンがあるようなサービスとコネクトし、データを受け取ったり処理をしたりできるようになっています。
言語対応としては、SQLからPySparkそしてJava、R、Scala等々に対応しています。最近では、English SDKや、日本語でこのように処理をしてくれと書くとそのようにデータフレームを操作してくれるというもの、そしてワークフロー機能やトリガーの機能もあります。処理のエンジンとして高速化がなされていたり、チューニングをするためのオプションが拡充されたりしている点も重要だと思います。
そして、スナップショット的にデータをクローンする、SHALLOW CLONEと呼ばれる機能や、物理的にデータ自体をクローンするDEEP CLONEと呼ばれる機能、またCI/CDの連携も実現しております。
SQLでアドホックなクエリをデータウェアハウスに対して発行する、あるいはBIからつなぐ点では、キャッシュのバリエーションが非常に多いのがDatabricksの特徴です。そのため、さまざまなケースで高速化を図る、内部的な仕組みが整っている印象があります。
Databricksの中にBIのダッシュボードがあり、そこからアクセスするときに限っては、クラスターが停止していても可視化ができるような機能拡張もあります。もちろんTableauやPowerBIなどのツールからの接続にも対応しています。
Databricksのウェアハウスから、フェデレーションをしてSnowflakeやRedshift、BigQueryにフェデレーテッドクエリを発行することもできます。最近では、teamsやSlackから、たとえば「この売上を集計して」のように打てば、その結果を返してくれるコネクトにも対応しております。
マシンラーニング系や生成AI系のアップデートもあり、特に最近のトレンドの流れを汲んでいます。従来、数値系のautoMLのみだったところが、たとえば生成AIのHugging Face等に対してファインチューンを書くためのオートモデルのGUI機能や、モデルのサービング、モニタリングなどが拡充されています。この中には、まだ一部これから使えるようになってくるものもありますが、一つのDatabricksの中でも、最近のトレンドに追従してきているようなイメージです。
そしてデータブリックスの中には、データカタログとしてUnity Catalogと呼ばれる機能があります。Unity Catalogによって、Databricksにあるさまざまなデータやフェデレーテッド先のデータベース等々もカナログとして管理できます。そのため、データをアクセスポリシーで制御し、社内外への共有や、マーケットプレイスへの展開などができるようになっています。
内部的には、Lakehouse IQと呼ばれる生成AI系の機能が動き、Unity Catalogと連携することによって、よりChat GPTのような問い合わせにも対応できるイメージになります。作ったアプリケーションはLakehouse Appsといい、Databricksの上にアプリとしてサービングをし、それを自社利用やマーケットプレイス展開できるイメージです。
特徴的なところとして、Databricks社と追加の契約をすることなく、Azure上の一つのサービスとして利用できます。エンジニアの方々にとってはメリットは理解しづらいかもしれませんが、契約の窓口であったりサポートの窓口を一本化できる点は、業務寄りの方々や事業部側の方々からすると嬉しいポイントかなと思います。」
Databricksのパフォーマンス
武田氏:「Databricksはもともと、Sparkのフレームワークでインメモリでイテレイティブな処理ができ、高速である点が特徴としてありましたが、Databricksのエンジンを再開発した歴史があります。そうしてできたエンジンがFhoton Engineと呼ばれるものです。
クエリを発行すると、ドライバーノードと複数のワーカーに当たるエグゼキューターノードが処理をされる時に、CPUのレベルでレポートのエンジンがうまく効く仕組みになっています。扱うデータはDelta LakeやDelta format、Parquetとして格納されている、カラム型で圧縮されているデータです。
Photon Engineは、非常にオーバーヘッドが少ない言語で開発されています。それだけではなく、多くのCPUがサポートしているSIMのインストラクションをダイレクトに利用できることから、マイクロなCPUレベルで、1回の処理をする時に複数のデータに対して、一括で処理できる特徴があります。
世にある高速なデータウェアハウスであれば、SIMの命令をダイレクトに利用できるようになっているため、Databricksもこのタイミングで他社のデータウェアハウスと同等のスピード感になってきたと思っています。
最新のアップデートとしては、Predictive IOやLiquid Clusteringと呼ばれる機能が出てきています。
Predoctive IOは、インデックスを付与して高速化する従来のアプローチではなく、内部にMLのモデルを持っており、データの配置や過去に実行されたクエリプランを学習して、最適なアクセスパスを継続的に学習し、Optimizerと連携する仕組みです。
Liquid Clusteringは、クラスタリングキーを指定をし、内部のカーディナリティを考慮して、できるだけばらつきがない形でファイルを配置してくれる、IO最適化の機能です。」
Databricks Workspaceの進化
武田氏:「高速化が進んでいるだけではなく、UIも進化しています。DatabricksでSQLを実行する時には、左上図のようなエディターがあり、左側の対象のスキーマやテーブルの中から対象を選択してクエリを実行する、非常に分かりやすいUIかなと思っております。また、その結果の可視化も可能ですし、ダッシュボードの作成もシームレスに連携できます。
過去に自分が実行したクエリの実行時間や、クエリのプランやSTEP、そこに使われた時間や行数、メモリを非常に分かりやすい形で出してくれるため、チューニングの観点では非常に嬉しいと思っております。」
AI Assistantとは?
武田氏:「最近の生成AIの流れに乗っ取り、DatabricksにはAIアシスタントと呼ばれる機能がついています。SQLエディターで実行する横の画面にアシスタントが出てきて、”こういった集計をしたい”と打ち込むと、その結果が返ってきてSQLをすぐ実行できます。
この生成されるSQLは極めて精度が高く、実行すると成功する可能性が高いです。なぜかというと、Unity Catalogと裏ではLakehouse IQが連携しており、Lakehouse IQがユーザーが実行したクエリやテーブル情報、カラム情報、ノートブック情報、ドキュメントなどを参考にしながら回答を作っているためです。」
Unity Catalogの検索強化
武田氏:「カタログ検索に関してもLakehouse IQの機能は効いており、たとえば検索をする時に、ユーザーが打った質問に対して、同義語も加味した検索結果を表示できます。
データカタログの各テーブルや、カラムのメタデータを自動で生成してくれる機能もあります。自動で生成されたメタデータを管理者が見て、説明として違うと判断した時には、エディットで編集をして保存できます。この機能は、精度を改善していくうえで、非常に重要なポイントの一つだと思っています。」
Notebookでも自然言語でのコーティング・解析が可能
武田氏:「NotebookでPythonの実行は可能ですが、English SDKでの対応も進めています。OpenAI社のCode Interpreterを、社内のデータやスケーラブルな処理をしたい時に使えるのかなと思います。たとえばURLや自社のデータのパスを指定して、Sparkのデータフレーム化を行い、“各プロダクト別にデータをピポット集計して”のように打つと、その結果をトランスフォームしてくれます。
解析をしたいときには、たとえばタクシーの運賃のテーブルデータがあったとして、そのデータをもとに“距離と運賃の相関性を可視化して”のように打ち込むと、プロットをしてくれます。」
SlackやTeamsからDatabricksに直接QnAをする
武田氏:「最近では、SlackやTeamsからDatabricksに直接QnAをできる機能拡張もあります。内部的にはラングチェーンのライブラリーを使ってOpenAIのモデルと連携する形になります。たとえば、“平均の運賃のデータはどうか”と問い合わせをすると、その結果を返してくれるように、新しいUIを提供してくれます。」
Unity Catalogの重要性とは
武田氏:「Databricksのデータカタログとして存在している、Unity Catalogの重要性に触れたいと思います。
生成AI系の機能の中には、比較的Unity Catalogが有効化されていることを前提として使う機能が多く、今後もその方向性はあると思っています。ユーザーがクラウド環境でデプロイしてDatabricks Workspaceがたくさん乱立するよりは、一つのUnity Catalogでメタストアを持っている方がよいと思います。また、アクセスポリシーを制御して各ワークスペースが管理されているのが、管理面の観点からは非常によいと思います。
さらに、ユーザーの方がデータ基盤のアーキテクチャを考える時にも、Unity Catalogがあることで、トレンドとなるアーキテクチャへの対応の新しい選択肢を作ってくれるメリットもあると思います。」
セントラルなデータ分析基盤の課題
武田氏:「本当に全社統合のデータプラットフォームを作り、運用しようとした時に陥りがちな機能不全のリスクについてお話ししたいと思います。領域特化型のプラットフォームであれば、本課題は対称ではないことをあらかじめ触れておきます。
全社のデータを文字通り一箇所に集めてくるプロジェクトは、何気に多くあると思っていますし、普段そういったご相談を数多く受けています。
ただ、営業にしても米国やヨーロッパなどの営業がありますし、マーケ、財務、法務などすべてのデータを一つのデータベースに格納しようとすると、各事業やその国のデータに求められるレギュレーションが異なるため、それら全てに対応していくのはかなり非現実的になります。たとえ作ったとしても、セキュリティが厳重な基盤が出来上がるのです。
各事業部や国、文化によっても、使いたいBIツールが異なるケースがあると思います。そういったもの全てに対応しようとすると、ますます追加の拡張が重なっていき、新しいツールを入れたい時に考慮すべき点が多く出てきて、スピード感が欠如する可能性があります。あるいは、そのツールを使わないと言われた時に、本当は使いたかった社員のモチベーションがダウンするケースもあるかと思います。」
Data Mesh Architectureとは
武田氏:「最近、大きなクラウドサービスの会社でも、データメッシュのアーキテクチャを組むのがトレンドになってきております。
上図を見ると、データメッシュは、セントラルな一つのデータベースがあるわけではなく、各データのドメインの中にレイクハウスやデータプラットフォームがあります。そして中心には、セントラルに管理するためのデータカタログがあり、全体をマネジメントする構造です。
このアーキテクチャのフレームワークの場合は、組織やビジネスの拡張も視野に入れたアプローチになっています。最近は、非常に複雑なデータを組み合わせて分析したいケースや、さまざまな用途に応えたいケースの相談が出てきています。
各データドメインに対してデータを共有するときには、データシェアリングの機能を使ってスナップショット的に共有でき、そういったアクセスポリシーはUnity Catalogや他のデータカタログでも管理していくものになっています。
何が言いたいかというと、Databricksは一つのワークスペースの中でさまざまな機能拡充をしてますが、新たなフロンティアとなるアーキテクチャへの対応も見据えて拡張してきている点は特長だと思っております。」
モダンデータ基盤構想策定ワークショップ
武田氏:「しかし、データメッシュのアーキテクチャは、コツをつかめばそこまで大変ではないのですが、”どういった時にセントラルで、どういった時にデータメッシュのアーキテクチャなのか”の判断基準や考え方のステップが、まだ成熟していない領域なのかなと思っております。
そこに関して弊社では、どういったステップで考えてプランニングすればよいのかをご支援するメニューがあります。実際にそういったプラットフォームを実装していく中で得た知見を体系化しているため、もし興味がある方がいらっしゃいましたら、お問い合わせいただければと思います。」
当初のビジョンが最新トレンドへ
武田氏:「2013年当時は、DatabricksのEnd-to-Endに関しては、変わったビジョンだなと捉えられていましたが、2023年現在まで着実に、一つのPaaSサービスの中でさまざまなことができるようになる、End-to-Endに近い形で実現してきていると思います。
当初は一つのPaaSは一つの機能だけといった固定観念がありましたが、現在では一つのPaaSでもさまざまな機能が使えるようになっており、機能拡張が変わってきているデータ系のサービスも少なくないと思います。そういったところを見ると、当時は変わったビジョンだと捉えられていても、今ではデファクトのトレンドになりつつあるのかなと思います。
製品選定やサービスの何か決めるときに、今時点の機能を比較するのではなく、”現在のトレンドがどうなっていて、対象のサービスがトレンドの先導役になるのか、後追い役になるのか”で判断することが、後のさまざまな機能の成熟を見るうえでも非常に重要なポイントかなと思っております。」
講演2「Microsoft Fabric:AI Copilot 搭載の次世代 SaaS データ分析」
中里 浩之 氏
日本マイクロソフト株式会社 カスタマーサクセス事業本部 クラウドソリューションアーキテクト
Twitterのアカウントはこちら
Linkedlnのアカウントはこちら
中里氏:「前半に武田から話したAzure DatabricksはPaaSですが、Microsoft FabricはSaaSのサービスです。2023年5月にパブリックプレビューが開始されています。Microsoft Buildと呼ばれるMicrosoftのグローバルなイベントが年に1回あり、そこで弊社のCEOであるSatya Nadellaが発表しました。
画面の下の吹き出しにあるように、Satyaは「FabricはMicrosoftのデータ関連製品として、SQL server以来最大の発表になるだろう」とコメントしています。SQL Serverも30年以上の歴史がありますが、それと同等のインパクトを持つのがFabricです。」
本セッションではMicrosoft Fabricについて、5つの観点でご紹介していきます。はじめに、Microsoft Fabric開発の背景についてお話ししていただきました。
今年最も話題になったテクノロジー 生成AI
中里氏:「今年最も話題になったテクノロジーは、間違いなく生成AIかなと思っています。OpenAIやCopilot、LLMなどをはじめとして、生成AIに関連するキーワードをニュースやSNSで見なかった日はほとんどなかったのではないかと思います。」
生成AI登場の反響
中里氏:「生成AIの登場後、極めて大きな反響がありました。海外のみならず日本においても、国家レベルで”生成AIをどのように活用していくか”の議論が活発化しています。パナソニック様やベネッセ様、日清食品様など、非常に多くの国内外の企業が生成AIを自社に導入しています。
さらにスライドの右側にあるような、プロンプトエンジニアリングと呼ばれる、新しいスキルにも脚光が当たっています。」
AIの重要性=データの重要性
中里氏:「AIの重要性が今までになく高まっていると同時に、AIのいわば燃料であるデータの重要性もますます高まっています。」
2023年の機械学習・AI・データのランドスケープ
中里氏:「最近では、データに関するさまざまなイノベーションが起きています。
こちらは、2023年の機械学習・AI・データに関連するサービスのランドスケープです。一つ一つのアイコンが、サービスやソリューション、OSSのテクノロジーなのですが、このように数えきれないほど多くのアイコンが並んでいるのがお分かりになると思います。」
よりシンプルにしたい
中里氏:「もちろん、この中からうまくサービスを選んで組み合わせて、ビジネス上のバリューにうまくつなげてらっしゃる企業も数多くいらっしゃると思います。一方で、普段私たちが接する企業のCDO(最高データ責任者)の方からは、”もっとシンプルにしてほしい。私は最高のデータ責任者であって、サービス同士を統合する最高統合責任者になりたいわけではない。”といったコメントを受けます。」
AI時代のためのSaaSデータ分析ソリューション Microsoft Fabric
中里氏:「この問題を解決するために、私たちはMicrosoft Fabricを発表しました。Fabricは、AI時代のためにゼロから設計したSaaSのソリューションになっています。企業が必要とする全ての分析を担う、統合されたオールインワンの分析ソリューションです。」
Microsoft Fabricの特徴
中里氏:「Fabricは大きく分けて、2つのレイヤーで構成されています。小さなアイコンが7個並んでいる上のレイヤーが、コンピューティングのエンジンです。ここに分析に必要なすべての機能が備わっています。
一番左側にData Factoryがあり、つづいてSynapseといったキーワードも並んでいますし、PowerBIもあります。FabricはPowerBIのUIとUXがコアになっており、Azureで提供しているData FactoryやSynapseのデータ分析機能がSaaSで使えるように、オールインワンでまとめたソリューションです。
下のレイヤーが、いわゆるストレージです。OneLakeと呼ばれる、SaaS型のレイクです。Fabricには7つのエンジンがありますが、これら全ての分析エンジンはOneLakeを一元的なデータの保管先として利用します。」
つづいて、「次世代のBIと先端テクノロジーの融合」についてお話していただきました。
中里氏:「データに関する4つの分野があるのですが、Microsoftはそれら全てで唯一リーダーに居続けられている企業です。左側からデータ統合ツール、クラウド・データベース管理システム、クラウド AI開発者サービス、そしてアナリティクスとBI プラットフォームです。
とくにアナリティクスとBI プラットフォームにおいて、Microsoftは抜きん出たリーダーの評価をいただいています。その評価の源泉になっているのが、Microsoft PowerBIです。」
Power BIを中心としたストラテジー
中里氏:「Fabricは市場で高い評価をいただいている、Power BIを中心とした戦略を描いています。
まずは、使いやすさの観点です。データの可視化・分析のエリアにおいて誰もが認めるリーダーになることを目指しています。これを実現するために、PowerBIとMicrosoft Office製品のさらなる融合を目指しております。最終的に描く姿としては、”文章作成はWord、プレゼンテーションはPowerPoint、そしてデータ分析はExcelとPowerBI”が当たり前の世界を作っていきたいと考えています。
一方で、スライドの右側にはMicrosoft Fabricのさまざまな分析機能が載っているのですが、PowerBIもFabricの分析機能の一部であるため、他のデータ分析系の機能と一緒に使える点が特徴です。
さらに、エンジニアのみならずビジネスユーザーの方にも気軽に使ってもらえるように、Copilotの機能を搭載していくロードマップになっています。これによって、質問に対する回答を自然言語で迅速に得られたり、Fabricに搭載されているパイプラインを作る機能も自然言語で作ったりと、生産性を高められるようになっていきます。」
Azureで実証されたデータ分析テクノロジーとの融合
中里氏:「これまで大規模なデータ活用のシーンにおいては、Power BIはAzureのさまざまなデータと、AIプラットフォームのサービスを組み合わせて利用するケースが一般的でした。Azureには、DatabricksやSynapse、Data Factoryなどのデータ関連のサービスがあります。それらのサービスは、多くのお客様に使っていただき、すでに効果が実証されています。
Microsoft Fabricは、PowerBIのUI・UXをベースとしていると申し上げましたが、FabricをPower BIの拡張と捉えると、スライドの右側にあるような、すでに実証済みの確立されたサービス群と融合して使えると言えます。」
つづいて、「レイク セントリックなアーキテクチャ」についてお話していただきました。
OneLakeの特徴
中里氏:「OneLakeの特徴をご紹介していきたいと思います。
Fabricには分析に関するさまざまなコンピューティングのエンジンが搭載されていますが、全てのエンジンはOneLakeにデータを保存し、一元的なストレージの役割を果たします。
Fabricを利用する際には、Fabricテナントと呼ばれる、組織内での一つの大きな傘のようなものの中で、さまざまなリソースを管理していきます。OneLakeはFabricの利用を開始したタイミングで、テナントの中で自動的にプロビジョニングされるため、すぐに使い始められます。」
One Copyとは
中里氏:「OneLakeはOne Copyと呼ばれるコンセプトの下で設計、開発をされています。これは、Fabricに搭載されている全てのコンピューティングエンジンが、OneLake上にある同じデータにアクセス可能であることを表しています。たとえば、Sparkを使ってOneLakeに出力したデータに、SQLやKQL(Kusto Query Language)を使ってアクセスできます。
これまでは、コンピューティングエンジンでデータをやり取りする時には、データを一度エクスポートしてインポートするステップが必要でした。しかし、Fabricにおいてはそのステップが不要になります。まさしくOne Copyで、ただ一つのコピーで全てのワークロードをカバーできるようになります。
OneLake上のすべての構造化データは、オープンスタンダードなデータ形式である、デルタレイクのフォーマットを採用しています。さらに、Fabric上のすべてのエンジンはネイティブな形式として、デルタレイクのフォーマットで動作するように最適化されているため、One Copyが実現可能となるのです。」
One Securityとは
中里氏:「もちろん、セキュリティも重要な関心事であり、One Securityと呼ばれる機能が今後のロードマップになっています。One Securityは、一つのコンピューティングエンジンで適用したセキュリティモデルが、その他のすべてのコンピューティングエンジンでも適用できる考え方です。
現時点ではまだ利用できませんが、今後提供する予定で開発を進めております。」
OneLake ショートカットとは
中里氏:「OneLakeの中で最も強力な機能が、OneLake ショートカットです。
OneDriveをお使いの方もいらっしゃるかと思いますが、OneDriveにもショートカットの機能があります。組織の中でSharePointのフォルダに見たいファイルがあった際、そのフォルダをOneDriveにショートカットとして登録すると、あたかも自分のファイルと同じようにアクセスができます。ところが、ファイルの場所は移動しておらず、コピーもしていない、シンボリックリンクのような役割を果たします。
OneLakeでも同じことができます。他のワークスペースにあるデータを、自身のワークスペースに簡単にショートカットとして登録ができるのです。データの実態のコピーは不要になります。
さらに、Azureのオブジェクトストレージである、Azure Data Lake Storageや、Amazon S3などのサービスも、OneLakeにショートカットとして登録できます。Google Cloud StorageもComing soonになっています。
これの何が嬉しいかというと、Fabricのコンピューティングエンジンから、OneLakeのインターフェースを通じて、透過的にクラウドオブジェクトストレージにアクセスができる点
です。こちらも、データの実態のコピーや移動はありません。
すでに、各社のクラウドオブジェクトストレージにデータを整理して蓄積しているケースは多いと思いますが、それをOneLakeに一気に持っていくのは難しいと考えています。ただ、このショートカットをお使いいただくと、データのコピーを伴わずに、クラウドを横断する形で、データの統合、データの仮想化を行っていただけます。」
OneLakeデータへのオープンアクセス
中里氏:「Azure Databricksとの連携ももちろん考えられています。多くのユーザーではすでに、Azure Data Lake Storagen Gen2の上に様々なデータを整理して、蓄積しているケースが多いです。
Fabricにおいては、2つのポイントで既存の資産を効率的に活用できます。
まず1つ目は、OneLakeはAzure Data Lake Storage Gen2のAPIとSDKとの互換性がある点です。つまり、Azure DatabricksやAzure HDinsightなどの、データレイクに対応するアプリケーションから、OneLakeに直接アクセスできます。
2つ目は、先ほどご覧いただいたショートカットです。Azure Data Lake Storage Gen2をOneLakeにショートカットとして登録することで、Fabric上の分析エンジンから直接アクセスできます。アプリケーションの観点でも、データの観点でも、既存の資産をFabricでは効率的に活用できます。」
他のサービスと組み合わせたアーキテクチャ
中里氏:「スライドの一番下に、さまざまなデータソース群を載せています。
Fabricには、GUIでデータ統合を行えるパイプラインやDataflow Gen2と呼ばれる機能がありますが、150以上のコネクターを備えています。これらを使うことで、オンプレミスのさまざまなRDBやファイルサーバー、Azureの各種サービスはもちろん、Amazon Redshift、BigQuery、Snowflakeなどのメジャーなサービスとも、簡単に連携できます。
さらに、ショートカットにより、3クラウドのオブジェクトストレージをショートカットとして登録できます。このような形でOneLakeにデータを取り込んだら、一番上にあるようなData EngineeringやData Factoryの分析のインターフェースを通じて、サーバーレスのコンピューティングエンジンであるSparkやSQL、KQLなどを使ってデータを自由に分析できます。
スライドの一番右下には、センサーやSNSのストリーミングデータがありますが、Fabricではリアルタイムのデータ取り込み分析・可視化のシナリオについてもサポートしております。」
OneLakeのデモシナリオ
中里氏:「OneLakeのショートカットのデモをご覧いただきたいと思います。
左上にAzure Data Lake Storage Gen2があり、ここに売上のファクトテーブルがDelta Lakeの形式で格納してあります。Amazon S3には、ファクトテーブルと繋がる各種ディメンションテーブルを格納している状態です。これらをOneLakeの方にショートカットとして登録します。
OneLakeでショートカットした後は、Notebookを使ってSparkで分析、あるいはSQLでクエリをかけて分析、そしてPower BIで可視化します。この一連のEnd-to-Endの分析のシナリオについて見ていただこうと思います。」
Azure Data Lake Storage Gen2の概観
中里氏:「まずは、Azure Data Lake Storage Gen2にどういったデータがあるか、概観していきたいと思います。
今映しているのが、Azure Data Lake Storage Gen2です。こういったストレージアカウントのコンテナーのフォルダを切っていますが、ファクトセールと呼ばれるフォルダーを切って、この中にDelta Lakeの形式でファイル群が並んでいます。また、デルタログのフォルダがあります。」
Amazon S3の概観
中里氏:「同様に、S3も概観したいと思います。
Microsoft Fabric S3ショートカットのバケットを作り、この中にファクトテーブルと繋がるようなディメンションテーブル群のDelta Lakeのテーブルのファイルを置いています。ディメンションペケのフォルダが5つ並んでいます。一番上のディメンションシティを見たいと思います。
この中にDelta Lakeの形式でParquetとデルタログのフォルダがあります。
これらのデータレイクとS3にあるデータを、ショートカットして分析をするところを連続して見ていただきたいと思います。
こちらがFabricの画面です。まずはデータレイクをショートカットとして登録したいと思います。」
中里氏:「”新しいショートカット”を選んで、Azure Data Lake Storage Gen2を選びます。」
中里氏:「接続設定のところでデータレイクのURLを入力し、”次へ”を押します。さらに、”サブパス”には、データレイクのフォルダーを入力し、最後にショートカット名として”ファクトセール”と入れて作成を押します。
これだけでデータレイクにあるデータが、FabricのOneLakeにショートカットとして登録されました。」
中里氏:「”ファクトセール”を押すと、実際にデータのプレビューができています。」

中里氏:「つづいて、同じようにAmazon S3にあるDelta Lakeのデータもショートカットとして登録していきます。S3のバケットのURLを入力します。アイアムのユーザー情報は、すでに入れているため、それを接続の資格情報として使い、次に進みます。」
中里氏:「S3のサブパスとして、ディメンションシティのサブパスを入れ、これをショートカット名として使い、作成を押します。これだけで、FabricのOneLakeに、同じようにショートカットとして登録されました。」
中里氏:「ディメンションシティを押すと、同様にプレビューでデータが見えるようになっています。このような形でショートカットとして登録してしまえば、分析が簡単にできるようになります。
まずはノートブックで分析をしていきたいと思います。」
中里氏:「”ノートブックを開く”を押すと、すぐにノートブックが開きます。」
中里氏:「1番目のセルでは、先ほどショートカットとして登録してきたテーブル文をSparkのデータフレームとして読み込み、”実行”を押します。このようにすると、実は裏側ではサーバーレスのSparkがスタンバイ状態になっているため、5秒〜10秒でセッションを確立したら、処理がすぐに始まります。」
中里氏:「データフレームに読み込んだものを、Sparkを使って2番目のセルで集計をかけます。」

中里氏:「最後のセルでは、集計した結果をOneLakeにDelta Lakeの形式で永続化しています。
ショートカットのデータをノートブックを使って分析し、その結果をOneLakeに永続化することが、非常に簡単にできることをお分かりいただけたと思います。」
中里氏:「もちろん、OneLakeにあるデータをSQLを使って分析することもできます。「SQLエンドポイント」のメニューがあるため、こちらに切り替えるだけです。」

中里氏:「そうすると、T-SQLを使ってこれらのテーブル文を分析できます。テーブルが左側にあって真ん中にスケールがあり、一番下にその結果が並ぶといった、多くの会社さんにあるようなUIです。さらに、この結果を簡単にビジュアライズできます。」

中里氏:「Fabricの面白い点は、Power BIをベースとしています。テーブル間のリレーションをGUIを使って、マッピングできます。たとえば、ドラッグ&ドロップ、GUIの操作で、ファクトテーブルとディメンションテーブルをキーで結びつけられます。
上図のようにモデリングを簡単に行ったら、すぐにPower BIのレポートがこの画面から作れます。」
中里氏:「これがPower BIの画面です。右側にはOneLakeにショートカットとして取り込んだテーブル文が見えています。可視化の例としては、セールスの売り上げの合計金額を出したり、モデリングをしたことで、複数のテーブル間のリレーションを意識した形で、年別の売上も簡単に可視化したりできます。
Fabricでは、データをショートカットとして取り込み、Sparkを使って前処理加工したりスキルで分析したり、Power BIで可視化する、End-to-Endの流れが簡単に行えることがお分かりいただけたらよいと思っています。」
つづいて、「AI Copilot 搭載」についてお話していただきました。
Copilotで生産性を加速させる

中里氏:「Microsoft Fabricでも、Copilotの機能がプライベートプレビューになっています。Fabricにはさまざまな分析のエンジンとOneLakeがありますが、全ての分析のエンジンでCopilotが使えるような形で開発を進めています。
たとえば、Data FactoryではGUIでデータ統合のパイプラインを作りますが、自然言語でパイプラインで作られます。また、Sparkのノートブックも、Azure DatabricksのAI Assistantと似たような形で、やりたいことを自然言語で指示したらノートブックとして出してくれる機能が出てくる予定です。もちろん、Power BIのレポートを自然言語で作るということも可能になっていきます。」
Microsoft Cloud 信頼に基づく実行

中里氏:「Microsoft Cloudは、信頼に基づく実行を最重要視しています。
またお客様のデータはお客様自身のものであり、お客様のデータを私たちのAIモデルのトレーニングに利用することはありません。
そして、お客様のデータは、もっとも包括的な企業向けコンプライアンスとセキュリティ対策で安全に保護されています。」
さいごに、ライセンスとキャパシティの考え方について、ご紹介をしていただきました。
Microsoft Fabricの利用開始方法

中里氏:「Fabricの利用を開始するには、現在3つの方法がございます。
すでにPower BIのプレミアム容量をお持ちのお客様の場合は、Power BIの管理ポータルからパブリックプレビュー設定を有効化いただければ、すぐにFabricの全ての機能がご利用いただけます。
無料使用版のFabric容量といったものを現在ご提供しており、こちらも管理ポータルでトライアル版の設定を有効化いただければ、現在だと無期限で、無料のトライアル版のFabric容量と、最大1TBのOneLakeストレージが無料でご利用いただけます。aka.ms/TryFabricからすぐにトライアルが開始できます。
3つ目は、重量課金制のFabric容量です。Azureポータルから作成できます。作成した容量にFabricのワークスペースを割り当てることで、Fabricの機能がご利用いただけます。」
Microsoft Fabricの価格の構成要素

中里氏:「つづいて、価格の構成要素についてです。大きく2つの要素から構成されます。
左側がコンピューティング、Fabricの容量です。この容量を作成するときには、容量ユニット(CU)を、F2-F2048から選べます。
Fabricの特徴としては、Data FactoryやPower BIなどのさまざまな分析機能を搭載しているのですが、全ての分析エンジンがワークスペースに割り当てた一つのFabric容量を共有します。また、個別の分析エンジンごとに、裏側でコンピューティングリソースを別々に準備いただく必要がない点も大きな特徴です。
容量の一時停止、再開が可能です。停止している間は、コンピューティング部分の課金は発生しません。作成いただいた後もサイズの変更が行え、最低1分からの秒単位課金制になっています。
右側がストレージOneLakeです。こちらは、格納するデータサイズに応じた従量課金制です。」
Microsoft Fabricの具体的な価格
中里氏:「(スライドが示すのは)US West 2以上のパブリックプレビューの参考価格です。
左側がFabricの容量の価格です。F2からF2048までさまざまなサイズの容量ユニットがあります。今後よりコスト効率よく利用できるよう、予約容量の提供も予定しております。
右側がOneLakeストレージの料金で、1GBあたり1月0.023ドルです。より詳細なライセンスについては、aka.ms/fabriclicensingにアクセスしてご確認いただければと思います。」
よくある質問
中里氏:「”Azureのデータ分析関連サービスは今後どうなりますか?”の質問に、お答えしようと思います。
回答としては、MicrosoftではAzure Synapse AnalyticsやData Factory、Data Explorer、Databricksなどの堅牢で企業向けの、データ分析関連のPaaSのソリューションは引き続き提供します。
Fabricは、データ分析関連の機能を一体化し、よりシンプルにSaaSのソリューションとして使っていただけるように提供するものです。PaaSとSaaSで異なるニーズに対応できるため、お客様のニーズに応じて適切なソリューションを選択いただけます。
SynapseやData Factoryからの移行を希望するユーザーの方向けに、移行パスを現在準備しているところです。」
機能の提供情報(2023年8月現在)
中里氏:「今お使いいただけるのは、スライド左側のパブリックプレビューになってるものと、一般提供になっている機能です。
スライド右下にあるような、Copilot系については現在プライベートプレビューです。まだ一般にはご利用いただけませんが、今後の展開をお待ちいただければと思います。
ぜひFabricの無料トライアルを試していただけるとありがたく思います。aka.ms/TryFabricから無料トライアルを開始いただけます。」
中里氏:「Fabricには、現時点で豊富なドキュメントが用意されています。ぜひこれらのドキュメントを手引きとして、無料をトライアルでパブリックの機能をお試しいただければと思います。」
過去のData Engineering Studyのアーカイブ動画
Data Engineering Studyはデータエンジニア・データアナリストを中心としたデータに関わるすべての人に向けた勉強会を実施しております。
当日ライブ配信では、リアルタイムでいただいた質疑応答をしながらワイワイ楽しんでデータについて学んでおります。
過去のアーカイブもYoutube上にございます。興味をお持ちの方はぜひご覧ください。