どんな場面で検討するか
AzureのデータレイクをSQLで分析し、データ統合のパイプラインやSpark処理と合わせて運用したい場合。serverless SQLで保存済みファイルを参照する案と、dedicated SQL poolの確保型を比較する。
組織で使う条件
Parquet/分割等で走査量を抑え、入力の件数/到着・パイプライン失敗・SQLエラーを監視する。workspaceやレイク、DBの権限を分け、再実行時の重複を防ぐ。
採用前に試すこと
- 売上1000件と正解集計を用意し、検証レイクへCSV/Parquetの形で保存する。
- serverless SQLで期間指定と全量を比較し、結果・処理量と予算上限の動作を確認する。
- 必要な加工pipelineを再実行し、重複のない出力と失敗の再処理を確認してエンジン別費用を記録する。
合格と判断する条件
- 期待する件数/合計が一致し、再実行で二重集計されない。
- 処理量上限の動作を説明でき、SQL/Spark/pipeline/保存を別枠で見積もれる。
見落としたくない点
- 少量のSQL参照だけならserverless等の小さい構成を比較し、複数エンジンを同時に導入する理由を確認する。新規分析基盤ではMicrosoft Fabric等との運用/既存資産適合も比較する。
- 少量のSQL参照だけならserverless等の小さい構成を比較し、複数エンジンを同時に導入する理由を確認する。新規分析基盤ではMicrosoft Fabric等との運用/既存資産適合も比較する。
根拠となる資料
Azure Synapse Analytics — 既存カタログの公式製品入口