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」,希望不會又是一週後才寫了。

發表留言

Please log in using one of these methods to post your comment:

WordPress.com 標誌

您的留言將使用 WordPress.com 帳號。 登出 /  變更 )

Google photo

您的留言將使用 Google 帳號。 登出 /  變更 )

Twitter picture

您的留言將使用 Twitter 帳號。 登出 /  變更 )

Facebook照片

您的留言將使用 Facebook 帳號。 登出 /  變更 )

連結到 %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.