Azure Datalake Store Gen2:微软放了大杀器还是做了大傻逼？

2018年6月，微软正式宣布了Azure Datalake Store Gen2,第二代数据湖文件系统。熟悉微软数据湖的知道，这个东西是Raghu搞出来的，用于商业化微软内部数据处理平台Cosmos的系统。有关背景资料我在一湖数据，几度春秋里面有详细的介绍，有兴趣的可以去读一下。

没有时间读的，这里有一个简化版本。微软想在云上卖内部数据分析平台Cosmos赚钱。于是请来了著名的数据库研究学者Raghu负责。这个项目做了好几年，产出是Azure Datalake Store和 Azure Datalake Analytics。前者是一个构建在Blob store上的兼容WebHDFS接口的文件系统。后者是HDInsight--微软的Hadoop云端产品加USQL--微软Cosmos内部分析语言Scope的改版。

产品推出来，卖的一塌糊涂。最后微软重组整个部门。Azure Datalake Store和Azure Blob store组合并。Analytics一度并入到CosmosDB，最近又分出来了。而这个新的Azure Datalake Store Gen2是合并以后的组推出来的产品。

和老产品的具体区别体现在老产品是在Blob Store上包了一层。因为Blob Store是一个简单的object store，里面不存在目录结构的概念。所以Hadoop在云端如果要连一个Object Store，比如亚马逊的S3或者微软的Azure Blob Store，目前工业界有两种主流实现方式：

1. 类似亚马逊，华为等厂商，在client端模拟HDFS。通过在Object Store的文件名上做文章，可以间接的实现对目录的支持。这个做法的坏处是如果要对目录名进行更改，需要更改目录名里面的每个文件对应的Object Store里的文件名。代价颇大。
2. 微软的Azure Datalake Store的作法，client端不要管这些杂事，在server端包了一层，使得看起来有目录结构。如果做得比较聪明，用metadata service的话，可以一定程度上修正第一种做法带来的问题。

但是其实最好的办法就是在文件系统里面直接实现HDFS需要的primitve操作，包括对结构化目录的支持。而微软这次推出的Azure Datalake Store Gen2正是遵循了这样一套思路。一份存储，两种不同的接口去访问。Blob Store补齐了对结构化目录的支持，而HDFS接口则利用下面文件系统提供的能力直接支持HDFS访问。

这个做法的优点很明确，存储少了，两个接口可以同时访问所有的文件，也避免了之前Azure Datalake Store无法直接支持Blob Store的问题。而且这个做法效率也很高，Blob Store的很多新特性都可以直接用上去。无论如何，这其实本来就是最佳解决方案，微软在2018年终于推出来了。

只是我觉得2018年才推出来，而Hadoop已经不是那么重要了，是不是真的能够作为大杀器，产生很大的影响，我觉得够呛，弄不好只是做了一次大傻逼。Hadoop已经不重要了，Spark取而代之的迹象已经越来越明显了。Databricks在Azure上搞的Spark有或者没有这个Datalake Store支持，可能关系都没有那么大了。

所以我觉得是微软做了一件技术上极其正确的事情，但是晚了几年推出来，可能已经对现实没什么意义。那么微软为什么会晚几年才推出来，Amazon为什么一直在client端改。说白了，公司大了，Object Store和做Hadoop Cluster的不是一拨人，那么对你重要的事情对我是不是重要就是两说的了。做政治上正确的事情，而不是技术上正确，对公司最好的事情，无论微软，还是亚马逊，大公司都都无法逃脱。

Azure Datalake Store Gen 2，有总比没有强，但是有多大影响。我觉得微软与其说放了个大杀器，不如说做了几年大傻逼，早一点这样做Datalake Store，又怎么会有今天呢？对于数据湖来说，微软不仅仅有眼前的苟且，还有将来源源不断的苟且。