Heatwave on Tarragonhttps://tarrragon.github.io/blog/tags/heatwave/Recent content in Heatwave on TarragonHugo -- gohugo.iozh-TWTarragon (CC BY 4.0)Fri, 22 May 2026 00:00:00 +0000MySQL HeatWave OLAP Add-onhttps://tarrragon.github.io/blog/backend/01-database/vendors/mysql/heatwave-olap-addon/Fri, 22 May 2026 00:00:00 +0000https://tarrragon.github.io/blog/backend/01-database/vendors/mysql/heatwave-olap-addon/<p>MySQL HeatWave OLAP add-on 的核心責任是判斷 OLTP database 內建 analytics 加速何時比拆出 OLAP 系統更划算。HeatWave 這類 add-on 的價值是降低資料搬運與平台數量，但它也把 analytics workload、成本、freshness 與 query governance 帶回 MySQL 生態。</p> <p>本文的判讀錨點是：OLAP add-on 做的是把分析查詢從 OLTP 路徑<a href="https://tarrragon.github.io/blog/backend/knowledge-cards/olap-offload/" data-link-title="OLAP Offload" data-link-desc="說明如何把分析型查詢從 OLTP 主庫卸載，以保護線上交易效能">卸載</a>到專用引擎，解決特定 analytics workload 的 proximity 問題，而非 data warehouse 的完整替代。選型要看資料量、query pattern、freshness、concurrency、成本與團隊能力。</p> <p>官方文件路由的核心責任是固定 HeatWave claim。實作前先查 <a href="https://dev.mysql.com/doc/heatwave/en/index.html">MySQL HeatWave User Guide</a>；本文最後檢查日是 2026-05-22。</p> <h2 id="workload-fit">Workload Fit</h2> <p>Workload fit 的核心責任是找出 HeatWave 類 OLAP add-on 的合理位置。</p> <table> <thead> <tr> <th>情境</th> <th>適合原因</th> </tr> </thead> <tbody> <tr> <td>MySQL 資料為主要分析來源</td> <td>減少 ETL / CDC 複雜度</td> </tr> <tr> <td>Dashboard 需要較新資料</td> <td>freshness 比 warehouse batch 更重要</td> </tr> <tr> <td>分析 query 可被明確界定</td> <td>可控 workload 便於成本與容量管理</td> </tr> <tr> <td>Team 想降低平台數</td> <td>MySQL 生態內完成 transactional + analytics</td> </tr> </tbody> </table> <p>適合的 workload 通常是「MySQL 內資料、分析需求清楚、資料量可控」。若需要跨多資料源、複雜 semantic layer、長期資料湖與 ML feature store，warehouse / lakehouse 仍然更合適。</p> <h2 id="boundary-with-oltp">Boundary with OLTP</h2> <p>Boundary with OLTP 的核心責任是避免 analytics 壓力影響交易服務。OLTP query 要穩定、低延遲、可預測；OLAP query 常是大掃描、大聚合、長時間。</p> <table> <thead> <tr> <th>審查面</th> <th>問題</th> </tr> </thead> <tbody> <tr> <td>Resource</td> <td>OLAP 是否隔離 CPU / memory / storage</td> </tr> <tr> <td>Freshness</td> <td>analytic data 和 source 差多久</td> </tr> <tr> <td>Query control</td> <td>誰能跑 heavy query、如何限流</td> </tr> <tr> <td>Cost</td> <td>add-on node、storage、egress</td> </tr> <tr> <td>Incident</td> <td>OLAP 故障是否影響 OLTP</td> </tr> </tbody> </table> <p>OLAP add-on 要有 query admission policy。任何人都能跑任意分析 SQL，會把成本與穩定性風險放大。</p> <h2 id="freshness-and-evidence">Freshness and Evidence</h2> <p>Freshness and evidence 的核心責任是定義分析結果多新。Dashboard、營運報表、風控、推薦特徵對 freshness 的要求不同。</p> <table> <thead> <tr> <th>Freshness 等級</th> <th>適合情境</th> </tr> </thead> <tbody> <tr> <td>秒到分鐘</td> <td>operational dashboard、風控</td> </tr> <tr> <td>小時</td> <td>商業報表、營運分析</td> </tr> <tr> <td>天</td> <td>財務結算、長期趨勢</td> </tr> </tbody> </table> <p>Freshness 要被量測。Runbook 要記錄 last load / sync time、query latency、failed refresh、data gap 與 fallback dashboard。</p> <h2 id="cost-model">Cost Model</h2> <p>Cost model 的核心責任是比較 add-on 和獨立 OLAP 系統。</p> <table> <thead> <tr> <th>成本項</th> <th>HeatWave 類 add-on</th> <th>獨立 warehouse</th> </tr> </thead> <tbody> <tr> <td>Data movement</td> <td>較少 ETL</td> <td>需要 CDC / batch pipeline</td> </tr> <tr> <td>Compute</td> <td>add-on capacity</td> <td>warehouse compute / auto scaling</td> </tr> <tr> <td>Storage</td> <td>MySQL ecosystem 內</td> <td>separate storage</td> </tr> <tr> <td>Governance</td> <td>MySQL 權限延伸</td> <td>data platform governance</td> </tr> <tr> <td>Lock-in</td> <td>provider-specific</td> <td>warehouse-specific</td> </tr> </tbody> </table> <p>成本比較要包含人力。少一條 ETL pipeline 可能節省大量維運；但 provider-specific query 與管理模型也會增加 exit cost。</p>MySQL HeatWave OLAP add-on 的核心責任是判斷 OLTP database 內建 analytics 加速何時比拆出 OLAP 系統更划算。HeatWave 這類 add-on 的價值是降低資料搬運與平台數量，但它也把 analytics workload、成本、freshness 與 query governance 帶回 MySQL 生態。

本文的判讀錨點是：OLAP add-on 做的是把分析查詢從 OLTP 路徑卸載到專用引擎，解決特定 analytics workload 的 proximity 問題，而非 data warehouse 的完整替代。選型要看資料量、query pattern、freshness、concurrency、成本與團隊能力。

官方文件路由的核心責任是固定 HeatWave claim。實作前先查 MySQL HeatWave User Guide；本文最後檢查日是 2026-05-22。

Workload Fit

Workload fit 的核心責任是找出 HeatWave 類 OLAP add-on 的合理位置。

情境 適合原因
MySQL 資料為主要分析來源 減少 ETL / CDC 複雜度
Dashboard 需要較新資料 freshness 比 warehouse batch 更重要
分析 query 可被明確界定 可控 workload 便於成本與容量管理
Team 想降低平台數 MySQL 生態內完成 transactional + analytics

適合的 workload 通常是「MySQL 內資料、分析需求清楚、資料量可控」。若需要跨多資料源、複雜 semantic layer、長期資料湖與 ML feature store，warehouse / lakehouse 仍然更合適。

Boundary with OLTP

Boundary with OLTP 的核心責任是避免 analytics 壓力影響交易服務。OLTP query 要穩定、低延遲、可預測；OLAP query 常是大掃描、大聚合、長時間。

審查面 問題
Resource OLAP 是否隔離 CPU / memory / storage
Freshness analytic data 和 source 差多久
Query control 誰能跑 heavy query、如何限流
Cost add-on node、storage、egress
Incident OLAP 故障是否影響 OLTP

OLAP add-on 要有 query admission policy。任何人都能跑任意分析 SQL，會把成本與穩定性風險放大。

Freshness and Evidence

Freshness and evidence 的核心責任是定義分析結果多新。Dashboard、營運報表、風控、推薦特徵對 freshness 的要求不同。

Freshness 等級 適合情境
秒到分鐘 operational dashboard、風控
小時 商業報表、營運分析
天 財務結算、長期趨勢

Freshness 要被量測。Runbook 要記錄 last load / sync time、query latency、failed refresh、data gap 與 fallback dashboard。

Cost Model

Cost model 的核心責任是比較 add-on 和獨立 OLAP 系統。

成本項 HeatWave 類 add-on 獨立 warehouse
Data movement 較少 ETL 需要 CDC / batch pipeline
Compute add-on capacity warehouse compute / auto scaling
Storage MySQL ecosystem 內 separate storage
Governance MySQL 權限延伸 data platform governance
Lock-in provider-specific warehouse-specific

成本比較要包含人力。少一條 ETL pipeline 可能節省大量維運；但 provider-specific query 與管理模型也會增加 exit cost。

No-Go Conditions

No-go conditions 的核心責任是避免把 OLAP add-on 推到資料平台的位置。

訊號 建議路由
分析跨多來源 warehouse / lakehouse
查詢需要 semantic layer / BI governance dedicated analytics platform
長期歷史資料遠大於 OLTP warehouse / object storage
ML feature / offline training feature store / lakehouse
成本需要獨立 chargeback separate OLAP environment

HeatWave 類能力適合 MySQL-centered analytics。當分析需求超出單一 OLTP source，資料平台會比 add-on 更清楚。

下一步路由

HeatWave OLAP add-on 完成後，MySQL query 基礎讀 Query Optimization；資料平台邊界讀 backend analytics / warehouse 章節；若要保留 MySQL OLTP 並外接 CDC，讀 Binlog CDC。

]]>