相较传统的重量级OLAP数据仓库，“数据湖”以其数据体量大、综合成本低、支持非结构化数据、查询灵活多变等特点，受到越来越多企业的青睐，逐渐成为了现代数据平台的核心和架构范式。

作为微软Azure上最新一代的数据湖服务，Data Lake Storage Gen2的发布，将云上数据湖的能力和体验提升上了一个新的台阶。在前面的文章中，我们已分别介绍了其基本使用和大数据集群挂载的场景。作为本系列的下篇，让我们继续深度体验之旅。

 ADLS Gen2体验：数据湖共享

在企业中，一个庞大的数据湖往往需要被共享。比如数据湖通常会被划分为多个区域，这些区域最好能够被各自对应的计算集群所访问以进行不同的计算任务。这也充分体现了计算存储分离的理念，是云计算的架构精髓。那么ADLS Gen2能否支持这一重要场景呢？

答案是肯定的。对于各计算集群而言，不妨淡化它自己的“本地”存储，转为考虑集群是否能够读取访问远端的数据湖实例——在这样的思路下，就可以设立一个统一而独立的数据湖实例，被多个计算集群共享，同时按目录进行权限设置和数据隔离。数据湖的生命周期可独立于计算集群的创建和销毁，在需要时作为外部数据被引用和访问就可以了。

接下来我们以前篇文章创建的HDInsight Spark集群为例，继续数据湖共享的实战验证。微软的一段文档告诉了我们如何让HDInsight集群访问“外部”的ADLS Gen2：

To add a secondary Data Lake Storage Gen2 account, at the storage account level, simply assign the managed identity created earlier to the new Data Lake Storage Gen2 storage account that you wish to add.

https://docs.microsoft.com/en-us/azure/hdinsight/hdinsight-hadoop-use-data-lake-storage-gen2

看起来颇为容易，只需要将代表集群的identity赋予相应的ADLS Gen2权限即可。注意这里的权限粒度事实上可以设置得非常细致，精确到目录乃至文件层级，这正是我们需要的。

接下来我们来构建和实验这样一个常见的重要场景：原始数据位于数据湖的区域一中，由集群1的spark程序来进行处理，并将处理后的数据落地到同一数据湖的区域二中；集群2则利用hive来对区域二中的处理后数据进行查询。注意这里由于计算存储进行了分离，数据处理和查询集群都可以是无状态的，无工作负载时可以关闭，也能够随时创建或横向扩展。

我们先来准备共享数据湖，在系列上篇中已经创建的存储账号cloudpickerdlg2中新建一个文件系统datalakefs-shared用于共享数据。随后在其中分别建立zone-rawdata和zone-processed两个文件夹，并在zone-rawdata文件夹中存放入前面使用过的小说《双城记》文本文件ATaleOfTwoCities.txt：

接下来，为使Spark集群顺利访问这个中央数据湖中的数据，我们只需对之前创建的spark-cluster-identity分别对两个文件夹进行授权。这里为zone-rawdata赋予读权限，对于zone-processed赋予读写权限：  

随后，我们就可以复用系列中篇里的Spark集群来访问这个远端的数据湖了。再次祭出Jupyter Notebook进行数据处理，并将Spark的处理结果以parquet形式写入zone-processed：