Azure Synapse Analytics 超実践 Tips まとめ

## 目次

1. [Tips](#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) 二段階ロード最速パターン

```sql
-- 一時 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:

```sql
-- クエリと待機イベントを横串で
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

```sql
-- 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;
```

---

## ビジュアルで理解する

### アーキテクチャ全体像

```mermaid
flowchart LR
    subgraph ControlNode
        A[Control Node]
    end
    subgraph ComputeNodes
        B1[Compute Node 1\nNVMe Cache]
        B2[Compute Node 2]
        B3[Compute Node 3]
    end
    A -->|MPP Plan| B1
    A --> B2
    A --> B3
    B1 -->|Adaptive Cache| SSD1[(NVMe)]
    B2 --> SSD2[(NVMe)]
    B3 --> SSD3[(NVMe)]
    SSD1 -->|Cold| ADLS[Data Lake]
    SSD2 --> ADLS
    SSD3 --> ADLS
```

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

```mermaid
sequenceDiagram
    participant User
    participant ControlNode as Control Node
    participant Cache as ResultSet Cache
    participant Compute as Compute Node
    User->>ControlNode: Submit SELECT
    alt Cache Hit
        ControlNode-->>Cache: Key Lookup
        Cache-->>ControlNode: Cached Result
        ControlNode-->>User: Return rows
    else Cache Miss
        ControlNode-->>Compute: Send Plan
        Compute-->>ControlNode: Return rows
        ControlNode-->>Cache: Store Result
        ControlNode-->>User: Return rows
    end
```

---

## 重要ポイントまとめ

* **データ配置**: 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 倍効率化する助けになれば幸いです。