Azure Synapse Analytics 超実践 Tips まとめ

目次

1. Tips
2. ポイント
3. テクニック集
4. ビジュアルで理解する
5. 重要ポイントまとめ
6. 次のアクションプラン

---

Tips

#	Tip	Why it matters
1	RESULT_SET_CACHING は DB 単位で ON/OFF、ヒット時は実行プランごとスキップして I/O≒0。最大 10 GB、LFU 方式。	ダッシュボード系クエリが秒→ミリ秒に。
2	Adaptive Cache (NVMe) は 120 秒無アクセスでエビクション。DBCC SHOWADAPCACHE で可視化。	キャッシュ前提の検証は危険。
3	CTAS → SWITCH で統計も丸コピー＝UPDATE STATISTICS 不要。	バッチ後処理を短縮。
4	sys.dm_pdw_exec_requests の total_elapsed_time はキュー待ちを含まない。待機は sys.dm_pdw_wait_stats で確認。	ボトルネック特定が容易。
5	Resource Class は クエリ発行時のユーザー で判定。EXECUTE AS OWNER で降格する場合あり。	ストアド実行が突然遅い原因。
6	COPY INTO が常に最速ではない。ファイル < 50 MB × 多並列は PolyBase が優位。	ETL 基盤設計を再考。
7	REPLICATE 配置は 2 GB まで。それ以上は ROUND_ROBIN が良い場合も。	大型ディメンションが遅い原因解消。
8	IDENTITY 列付き CTAS で NOT NULL 制約が落ちる (2024‑Q4 修正)。	PK NULL 事故を防止。
9	AUTO_CREATE_STATISTICS はあるが 自動更新なし。自前ジョブ必須。	統計古化でプラン劣化を防ぐ。
10	NVARCHAR(MAX) でも Predicate Pushdown (2025‑03 Preview)。	JSON カラム処理が最大 40 % 向上。

---

ポイント

誤解	正しい情報	今後のアクション
Rowstore の方が小クエリ速い	列指向 + Batch Mode が高スループット	Rowstore を棚卸し→移行候補選定
PolyBase は COPY より遅い	条件次第で PolyBase ≒ COPY	データ湖のファイル粒度を測定
HASH 分散キーは一意キー	高カーディナリティ × スキュー小 が条件	分散スキューの再計測
DW6000c 以上は全ノード NVMe	旧 Gen1 は HDD キャッシュ混在	sys.dm_pdw_nodes で世代確認

---

テクニック集

1) 二段階ロード最速パターン

-- 一時 HEAP & ROUND_ROBIN
CREATE TABLE staging_heap WITH (
    DISTRIBUTION = ROUND_ROBIN,
    HEAP
) AS SELECT * FROM external_table;

-- 圧縮&HASH 分散 → 本番へ SWITCH
ALTER TABLE staging_heap
    SWITCH PARTITION 1 TO fact_sales PARTITION 202505;

2) DMV ダッシュボードを作る

Power BI で以下を Live Connect:

-- クエリと待機イベントを横串で
SELECT r.request_id, r.label, w.wait_type, w.total_wait_time
FROM sys.dm_pdw_exec_requests r
JOIN sys.dm_pdw_wait_stats   w ON r.request_id = w.request_id;

3) Serverless ↔ Dedicated ハイブリッド ETL

-- Serverless 側で前段集計
CREATE VIEW vw_filtered AS
SELECT * FROM OPENROWSET(
    BULK 'https://datalake/sales/*.parquet',
    FORMAT='PARQUET')
WHERE sales_date >= '2025-05-01';

-- Dedicated プールへ取り込み
CREATE EXTERNAL TABLE ext_sales WITH (LOCATION='/ext/sales/') AS
SELECT * FROM vw_filtered;

---

ビジュアルで理解する

アーキテクチャ全体像

結果セットキャッシュのフロー

---

重要ポイントまとめ

• データ配置: HASH ≠ 一意キー、REPLICATE は 2 GB 以内。
• インデックス: HEAP → CCI 2 段階でロード高速化。
• 統計運用: 自動生成 + 夜間更新 (サンプル率 20 %)。
• キャッシュ: RESULT_SET_CACHING (10 GB) と Adaptive Cache を使い分け。
• ロード: COPY vs PolyBase はファイルサイズで使い分け。PARQUET 250‑400 MB 推奨。
• モニタリング: 「常に遅い」はプラン、「たまに遅い」は待機イベントを疑う。

---

次のアクションプラン

Priority	Action	Goal
🔴	統計更新ジョブ (sp_update_stats) を夜間 DAG に組込	プラン安定化
🔴	結果セットキャッシュを LAB→STG→PRD で段階適用	レポート高速化
🟡	ファイル分割サイズを再評価 (COPY vs PolyBase)	ETL 時間短縮
🟡	Resource Class ごとにメモリ使用量を計測	OOM 防止
🟢	DMV ダッシュボードを Power BI で可視化	運用モニタ強化

---

⚡ Enjoy fast analytics! この記事があなたの Synapse 運用を 10 倍効率化する助けになれば幸いです。