最近在看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一样，理解的可能是一个概念，在不同系统里实现出来的形态可能是不一样的，但大家的目的都是相同的。老外对这种东西的理解及抽象能力，值得学习！