Microsoft Fabric導入支援とAzureデータエンジニアリング

Microsoftを使う組織の多くは、データ基盤を一度に選んだわけではありません。あるプロジェクトで作ったAzure Data Factoryのパイプライン、別のプロジェクトのSynapseワークスペース、基幹業務アプリの裏にあるAzure SQLデータベース、そしてその上にPower BIがある、という状態です。Microsoft Fabricはこれらを1つのストレージ層を持つ1つの製品にまとめますが、移行を計画して進めなければシンプルにはなりません。

当社のMicrosoft Fabric導入支援とAzureデータエンジニアリングサービスは、その両面をカバーします。適した領域ではFabric上で新たに構築し、すでにお使いのAzureサービスは運用、チューニング、移行を行います。作業は貴社のテナントとサブスクリプション内で行い、貴社のセキュリティモデルに従い、貴社のチームが運用できるパイプラインとモデルをお引き渡しします。

当社の業務の多くは、製薬・ライフサイエンス企業のチーム向けです。創業者のHarsh KhubchandaniはZSで製薬企業のコマーシャルオペレーション・コンサルティングに携わってきたため、営業部門や患者サービス部門が実際に使うデータとレポートを軸に基盤を設計します。取り組みの中心がPower BIであれば、Power BIコンサルティングのページをご覧ください。

唯一の正解となる移行方法はありません。現在のSynapseワークスペースが何を担っているかによって変わります。

• 専用SQLプールはFabricウェアハウスへ移行します。MicrosoftはFabric内に移行アシスタントを用意しており、DACPACまたは直接接続からスキーマを変換し、手動修正が必要なオブジェクトを示します。その後、Fabric Data Factoryでデータをコピーします。
• SparkワークロードはFabricのレイクハウスとノートブックへ移行します。通常、コードの変更はわずかです。
• SynapseとAzure Data Factoryのパイプラインは、ソースごとにFabric Data Factoryへ再構築または移行します。
• Power BIレポートは接続先を切り替え、効果がある場合はDirect Lakeで再構築します。

移行中は新旧の出力を並行稼働させ、突き合わせが済むまで何も停止しません。当面はAzureサービスのままにしておいた方がよい環境もあり、その場合は率直にお伝えします。

あるスペシャルティ医薬品の提供企業では、ソース間でIDが一致しないまま、患者アクセスレポートを毎サイクル手作業で作り直していました。当社はクリーンなIDとMDM構造を整備し、ケースのパイプラインを自動化し、レポートとダッシュボードを標準化しました。手作業は60〜80パーセント削減され、レポートは安定して運用されています。Microsoft環境であれば、同じ仕組みはData Factoryのパイプラインが管理されたマスターとFabric上のPower BIモデルにデータを供給する形になります。

レポート層についてはPower BIコンサルティング、Azure Databricksをお使いの場合はDatabricksコンサルティング、あらゆるプラットフォームでのパイプライン構築はETLサービス、ブランドチーム向けにその上で構築するものについては製薬コマーシャルアナリティクスをご覧ください。