關于DIMMQ: Discardable In-Memory Materialized Query背景從資料重用到query重用

最近在看cbo在不同系統裡的實作方式，比如flink裡在編譯時對plan的cbo優化，以及運作時的cbo：hive、apache calcite(即optiq)的一些内容。

今天第一次看到dimmq的概念，聊聊我的幾點看法。

參考文章：discardable memory and materialized queries: put your memory into its right place in the storage hierarchy for efficient queries

dimmq的全稱是discardable in-memory materialized query，提出這個概念，本質上還是為了解決資料重用。隻是這次資料的重用不是磁盤上的replication，或是記憶體裡的rdd，而是更細粒度的query級别，具體data set是隐藏在dimmq這一層下的。

dimmq相當于是進階語言與底層存儲的一層映射，原文中提到 implementing dimmqs will require changes at the query level (optimization queries in sql and other languages such as pig and cascading) and also at the storage level.  進階語言包括hive，pig，cascading，亦或是任何計算架構的表達層。在我看來，隻要進階語言層能與dimmq進行一層翻譯和映射，那麼計算架構就可以在執行階段，做到較好地重用存儲層的資料。這種使用方式的與衆不同之處，就是面向query，而不是直接面向資料。

以往直接面向資料的重用和locality，有很多。比如最直接的，在磁盤級别，做replication，比如hdfs，比如mongodb的副本集。之後，出現了spark rdd，做到任務内的，大部分可以in-memeory的資料重用。再到tachyon，做到真正記憶體内的，跨任務的資料重用。這種面向資料的直接重用的壞處是，你需要知道這份資料的位置、它的分布情況、它的過期政策等等。這件事情，對應到dimmq裡，認為是可以與上層語言、應用解耦的。原文有這樣一句話 the core concepts — materialized queries, discardable data, and in-memory data — are loosely coupled and can be developed and improved independently of each other.

是以dimmq解決的是什麼問題呢。類比在hadoop體系裡，對hdfs可以做一層discardable distributed memory，利用hcatalog也好，配合query optimizer也好，dimmq的存儲部分的資料存放政策、過期政策、甚至是異構化存儲，都是不暴露的。我認為這也是對存儲層有了更高度的一層使用方式。解耦是肯定具備的。除了解耦之外，還有什麼好處？

文章中還提到關系型資料庫裡的物化視圖。我想，dimmq最直接的靈感一定是來源于物化視圖。資料庫如何導入資料，如何建立索引，在我們使用物化視圖的時候我們都是不關心的。是以類似的，在一個分布式計算架構裡，我使用pig、sql、hive去做計算，我也不關心底層的存儲怎麼load資料的，你底下可以是hdfs，也可以是别的存儲系統，你索引是不是用b tree建的都沒有關系，語言層關心的是具體查詢會怎麼落到計算、存儲節點上，越快越好，能本地化就本地化，能複用資料就複用資料。今天dimmq讓我們不用去知道資料有幾個備份，分别在哪裡，存儲媒體是磁盤、記憶體、還是ssd，用完了是不是要過期，多拷貝幾份還放不放得下。dimmq需要上層語言做的，是rewrite query，dimmq本身不太像執行架構本身的組成部分，而是一種存儲層的額外的meta管理，即與執行架構是不耦合的。

目前dimmq的直接使用場景是cbo。

總之我認為dimmq這個概念還是不錯的，這個東西和rdd一樣，了解的可能是一個概念，在不同系統裡實作出來的形态可能是不一樣的，但大家的目的都是相同的。老外對這種東西的了解及抽象能力，值得學習！