DDIA閱讀紀錄(9) – 第三章續：從OLTP到OLAP

(進度：loc 2353 – 2540)

又一個星期沒寫了 … 恐怖，專案死線太恐怖了 …

這次讀的段落雖然觸及的主題很多，但重點其實是要從前段以線上即時應用為主的線上交易處理(OLTP，Online Transaction Processing)，過渡到本章後段的主題線上分析處理(OLAP，Online Analytical Processing)。就個人目前粗淺的印象，那個"OL"真的是挺雞肋的，OLTP出生的年代線上與否是件大事，但OLAP就不一樣了，一方面線上或線下並不是重點，另一方面以其探討的架構來看自然是跟大型的資料中心有關，那就一定是線上的。或許只是因為和OLTP對稱，只好硬是冠個OL上去吧？

中間的過渡主題包括fuzzy indexes，full-text search和in-memory database，但都只是蜻蜓點水式帶過，尤其前二者並沒有太多深究，只有指出為何fuzzy indexes和full-text search會需要不同的索引結構。至於in-memory database，很有趣的是因為今日從database engine乃至OS都有自己的caching機制，導致in-memory database真正有效益的地方不在於查詢與讀取，反而是因為在寫入時它不需要轉換成硬碟需要的格式，例如序列化。

過渡之後，本章堂堂進入analytical data的世界。在本章開頭，作者就有指出transaction data和analytical data由於目的和資料量級的差異，存儲策略會完全不同。書中的這個表格總結得不錯：

簡單來說，資料分析的應用大多是一次抽出大量資料出來作統計分析，而當服務規模夠大，直接在production database上做這件事很容易造成整個服務停擺，弄得operation team森七七，系統部門和資料分析部門間烏煙瘴氣。為了兩邊都能做好自己的工作，才衍生出透過ETL程序(extract-transform-load)，把資料定期轉到另外的"data warehouse"，讓資料分析師們可以有個地方愛怎麼搞就怎麼搞，operation team保有內心的祥和，從此和氣生財，大家都過著幸福快樂的生活。

WordPress.com的作法大致上與書中相符。內部有自己維護的ETL程序會把最新的production data輸入到一個Hadoop cluster中，再透過Hue、Looker、以及N種自幹的資料分析工具去找出需要的資料。至於production database上則有作一系列的保護措施，盡量避免OLAP量級的query被某個沒睡飽的工程師跑到，但並沒有很完美就是了。

下個段落開始要提到analytical datastore的存儲策略，標題是「column-oriented storage」，希望不會又是一週後才寫了。