在談到數據分析，就不得不提到OLAP這個概念，Online Analytical Processing，屬於商業智慧的範疇之一，通過OLAP的系統，來進行資料擷取、整合、抽取等等的工作。在以往地端上的做法，便是建立一套屬於自己的資料倉儲，但是這樣的作法往往耗時耗力，同時擴展性上也受到限制，可能跑個購買地端設備的單子就要跑一到兩個月，不符合資料快速擴展的要求。
那遇到這樣的問題，該如何解決呢？
雲原生數據倉庫(AnalyticDB)
沒錯！就是使用雲原生的數據倉庫(AnalyticDB)，透過採用雲原生技術架構，實現了儲存與計算分開，並且能夠隨時動態的擴展與消減。使用者們可以藉由阿里雲 - AnalyticDB來及時應付數據存儲和分析的彈性需求。

另外值得一提的是，自2012年上線至今，阿里的AnalyticDB已經累計發布了近百個版本！此外，阿里巴巴目前在電商、廣告、娛樂等等其他產業的資料分析，幾乎都是使用Analytic DB來做服務。
那麼究竟AnalyticDB的特點到底是什麼呢？AnalyticDB阿里自主研發，並且有經過大規模驗證的 PB 級及時數據倉儲。可以在資料集上執行高併發、低延遲、實時分析查詢的OLAP型資料庫。

以下筆者列出幾項特點：

• 雲原生彈性：採用雲原生技術架構，實現儲存資源與計算資源分開，並搭配動態擴展與縮減，以應對企業上突發性的彈性需求。

• 高可用性：讀寫分離的架構讓AnalyticDB得以自動故障檢測、摘除和重搭副本、秒級災難恢復，同時還支持副本儲存、全量和增量備份。

• 高效性能：維持所有列的索引，用以快速檢索資料；採用RAFT協議來支持大規模的實時數據寫入；使用行列混合儲存來對OLAP分析和行級查詢快速響應。

產品架構圖：
接下來就讓我們看看Analytic DB的架構圖，並且筆者會一一分析這樣的架構。

儲存資源：主要仰賴於二個基於阿里雲Apsara底層主機的外部結構

• 任務管理與排程元件(Fuxi Resource Manager)
• 分散式儲存系統(Pangu Distributed Storage System)

計算資源：對外提供JDBC(Java Database Connectivity)介面來進行資料庫操作，內部則是透過多個控制節點(Coordinator)來管理各自的寫節點和讀節點

• 前端控制節點(Coordinator)：負責接收JDBC介面的SQL讀寫請求並加以解析、管理，接著分發到不同的只讀或讀寫節點。
• 讀節點(Read Node)：除了負責處理查詢請求並將請求的資料送回外，同時具有緩存資料的功能。
• 寫節點(Write Node)：負責處理寫請求並將資料寫入資料庫底層的Pangu中持久化。

大概了解了Analytic DB的架構後，接下來就談談有哪種規格吧！

依照資料庫類型可以分為MySQL、PostgreSQL兩種規格，其中又各自有兩種版本。

首先介紹MySQL版本：

• 彈性模式集群版
• 預留模式集群板

筆者透過圖表的方式整理出兩者的特點：

兩者的計費方式和基本架構都不大一樣，比如：

• 儲存空間的計費模式：預留模式需要在創建時指定儲存空間，而彈性模式則是按照實際使用的儲存空間進行計費。
• 資源分離：彈性模式的CPU和內存資源可以分為計算資源和儲存資源。

聊完MySQL版本，就來看看屬於PostgreSQL的兩個版本吧！

• 儲存彈性模式版：使用儲存計算一體的架構，支持計算節點垂直升降配，橫向擴展儲存。
• Serverless版：無託管，需自行架設儲存計算分離架構，仍支持動態擴展與縮減

了解有什麼版本後，接下來就來看看有哪些場景適合使用：

• 實時數據倉庫：需要在一個平台上提供統一的在線查詢和離線計算能力，並透過彈性伸縮配置更合理的資源。
• 實時數據分析：需要通過實時數據統計來監測用戶的增長、活躍程度、留存等，以提高數據的時效性。
• 智能商業報表：需要可以支持海量實時數據的入庫、計算、毫秒等級的返回結果，以快速建構報表。
• 聯合數據分析：需要解決雲上企業的配置資料問題，以及分庫分表所帶來的複雜性數據分析問題。

使用的情境當然不只以上四個場景，只要是資料分析ETL的流程中，都可以使用到這項服務，減輕使用者的成本與時間耗費。

那下一篇，將會帶各位實際進行AnalyticDB的操作，看看這樣的服務究竟怎麼使用吧！