背景
今天第一次看到DIMMQ的概念，聊聊我的幾點看法。
從數據重用到query重用
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一樣，理解的可能是一個概念，在不同系統裏實現出來的形態可能是不一樣的，但大家的目的都是相同的。老外對這種東西的理解及抽象能力，值得學習！
