Azure Data Lake Storage Gen2实战体验（上）

背景

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

数据湖的核心功能，简单地可以分为数据存储与数据查询计算两个部分，在云端可以有多种的实现选择。在之前的文章中，我们曾介绍Azure上Azure Data Lake Storage (ADLS Gen1)和Azure Data Lake Analytics (ADLA)这一对可配合使用的服务。这对黄金搭档正是为数据湖而生，分别对应着大数据存储和查询计算的能力。

在数据湖存储服务方面Azure继续着快速发展的脚步，在重新梳理了产品思路之后，将ADLS与同为存储服务的Azure Storage进行了大力整合。的确，在底层存储基础设施方面，ADLS完全可以复用Azure Storage久经考验的存储机制和成熟实现，并在此基础上支持企业级大数据分析的特性并进行针对性优化。在这一新体系下的成果，则是微软于18年开放预览、于19年2月正式对外发布的Azure Data Lake Storage Gen2 (下称ADLS Gen2)。第二代ADLS的口号是“不妥协的数据湖平台，它结合了丰富的高级数据湖解决方案功能集以及 Azure Blob 存储的经济性、全球规模和企业级安全性”。

那么，全新一代的ADLS Gen2实际体验如何？在架构及特性上是否堪任大型数据湖应用的主存储呢？这正是本文希望探讨的话题。

ADLS Gen2初体验

百闻不如一见，我们首先来尝试创建一个ADLS Gen2的实例。需要注意的是，与第一代ADLS是独立服务不同，ADLS Gen2已经集成于大家熟悉的存储账号(Storage Account)的功能体系之中。在建立存储账号时，请注意勾选"Advanced"选项卡下"Hierarchical namespace"(中文译作“层次结构命名空间”)这个看似不起眼的选项：

当这个选项被勾选时，创建出的存储账号中的原Blob存储部分就自然被耳目一新的ADLS Gen2文件系统所替代了：

从这里的产品措辞可以看出，“层次结构”和“文件系统”是反复被强调的ADLS Gen2的最大特点，也是它有别于传统Blob对象存储的最大不同。传统对象存储虽然从路径上看起来也具有“目录”的虚拟概念，但其实目录通常并不实际存在，可认为仅是Blob对象路径字符串中的一部分，因为对象存储本质上是key-value形式的存储。而ADLS这样的“文件系统”级别的存储能力上，目录则是一等公民，可以设置访问权限等元数据（并且能够被子节点继承），也可以使目录重命名等操作变得十分便捷迅速。这样的特性无疑使ADLS更适合作为企业数据湖这样应用的存储介质。

让我们继续操作。点击"Data Lake Gen2 file systems"来到文件系统的管理界面，可看到支持创建多个File System。我们先新建一个File System，这个步骤非常类似Blob存储中建立Container：

再尝试点击进入刚建立的cloudpickerfs这个文件系统，会发现界面上几乎空空如也，提示我们需要使用客户端工具Azure Storage Explorer才可进行操作：

不必对于这个简单的界面过于失望，ADLS Gen2毕竟还是一个初生的产品，相信之后会得到不断丰富。事实上在国际版Azure上已经有集成在Portal中的Storage Explorer，目前还在预览状态，相信之后也会在中国区发布。

我们打开最新版本的Azure Storage Explorer（该工具成熟度很高，非常推荐），可以看到轻松地识别出了刚才建立的文件系统：

尝试建立目录及上传一些文件，毫无问题：

ADLS Gen2特性测试：权限控制

如果说刚才我们走通了最基本的流程，接下来我们则需要对ADLS Gen2的特性进行深度的测试，尤其是针对其“文件系统”的设计目标和大数据应用的典型场景来进行实操体验。在本文中，我们先聚焦ADLS Gen2的权限控制。

我们知道传统的存储账户主要依靠Access Key和SAS token等方式来进行身份认证，并且在权限控制的粒度上比较粗放，只能设置到整个存储账户或是Blob容器的粒度。而在ADLS Gen2中，一般推荐使用集成度更佳的Azure AD进行访问身份认证(Access Key和SAS token也同样支持)，而权限方面的控制则可以非常精细：不仅支持文件系统粒度的RBAC权限指定，而且引入了类似POSIX的ACL体系，使得用户可以将权限设置下沉到目录乃至文件的级别。这样一来，ADLS这个大数据存储服务相当于提供了类似Linux文件系统的权限管理能力，极大地满足了企业级数据平台在资源管控和权限治理方面的需要。

接下来我们对于权限进行一个基本尝试。我们在cloudpickerfs文件系统中新建zone-a和zone-b两个目录来模拟企业不同业务领域的数据。

然后我们在Azure AD中新建一个用户Karl：

现在我们希望Karl拥有整个文件系统的读权限，但还能够对zone-a进行修改和写入。该需求应该如何实现呢？在ADLS Gen2上可以轻松地结合使用RBAC和目录ACL来达到目的。我们先为Karl添加文件系统粒度的Storage Blob Data Reader角色，这使得Karl可以基于RBAC权限机制读取cloudpickerfs这个文件系统中的所有数据：

然后再在Azure Storage Explorer中定位到zone-a，对该目录赋予Karl读写及执行权限，这样Karl就能够实现对于zone-a这个目录的完全控制。可以看到，这里的操作体验与Linux/Unix中的ACL权限机制非常接近：

（图中Default一栏对应的是目录中子项将继承的权限）

权限设置完成后，我们接下来使用一台Linux VM通过AzCopy这个工具来进行相关权限的实操验证。AzCopy作为微软官方的文件复制工具，已经全面地添加了对于ADLS Gen2的支持。

首先我们使用Karl的身份进行AzCopy的登录，注意需指定tenant-id参数为用户Karl所属AD的id：

./azcopy login --tenant-id xxxxxxxx-yyyy-zzzz-zzzz-xxxxxxxxxxxx To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter the code ******** to authenticate

（这里按照AzCopy要求打开浏览器进行身份认证）

成功后AzCopy现在就拥有Karl这个用户的权限了。我们先验证其全局读的能力，尝试下载一个cloudpickerfs文件系统下根目录的文件：

./azcopy cp https://cloudpickerdlg2.dfs.core.windows.net/cloudpickerfs/credit_card_loans.csv .INFO: Scanning...INFO: Using OAuth token for authentication.
Job e3ed4551-713a-2e40-5e47-72b5ee3e3280 has started0 Done, 0 Failed, 1 Pending, 0 Skipped, 1 Total,
Job e3ed4551-713a-2e40-5e47-72b5ee3e3280 summaryElapsed Time (Minutes): 0.0333Total Number Of Transfers: 1Number of Transfers Completed: 1Number of Transfers Failed: 0Number of Transfers Skipped: 0TotalBytesTransferred: 60991Final Job Status: Completed

可以看到这个读取并下载的任务顺利完成。我们再测试向zone-a写入的权限是否被正确地开启了，把刚才下载的本地文件上传到zone-a文件夹：

./azcopy cp ./credit_card_loans.csv https://cloudpickerdlg2.dfs.core.windows.net/cloudpickerfs/zone-a/INFO: Scanning...INFO: Using OAuth token for authentication.
Job a9dc4d08-c279-974e-707d-cceb3fad3720 has started0 Done, 0 Failed, 1 Pending, 0 Skipped, 1 Total,
Job a9dc4d08-c279-974e-707d-cceb3fad3720 summaryElapsed Time (Minutes): 0.0333Total Number Of Transfers: 1Number of Transfers Completed: 1Number of Transfers Failed: 0Number of Transfers Skipped: 0TotalBytesTransferred: 60991Final Job Status: Completed

再次获得了成功！最后，为了验证Karl仅拥有zone-a的写入权限，我们尝试向另一个目录zone-b写入看看效果：

./azcopy cp ./credit_card_loans.csv https://cloudpickerdlg2.dfs.core.windows.net/cloudpickerfs/zone-b/INFO: Scanning...INFO: Using OAuth token for authentication.
Job 484e24c1-366b-e94b-79b9-8f6351a4d503 has started0 Done, 0 Failed, 1 Pending, 0 Skipped, 1 Total,
Authentication failed, it is either not correct, or expired, or does not have the correct permission -> github.com/Azure/azure-storage-azcopy/azbfs.newStorageError, /home/vsts/work/1/s/azbfs/zc_storage_error.go:41===== RESPONSE ERROR (ServiceCode=AuthorizationPermissionMismatch) =====Description=403 This request is not authorized to perform this operation using this permission., Details: (none)   PUT https://cloudpickerdlg2.dfs.core.windows.net/cloudpickerfs/zone-b/credit_card_loans.csv?resource=file&timeout=901   Authorization: REDACTED   User-Agent: [AzCopy/10.2.1 Azure-Storage/0.1 (go1.12; linux)]   X-Ms-Cache-Control: []   X-Ms-Client-Request-Id: [d8504958-5666-42c1-6041-6db6602713a9]   X-Ms-Content-Disposition: []   X-Ms-Content-Encoding: []   X-Ms-Content-Language: []   X-Ms-Content-Type: [text/csv; charset=utf-8]   X-Ms-Version: [2018-11-09]   --------------------------------------------------------------------------------   RESPONSE Status: 403 This request is not authorized to perform this operation using this permission.   Content-Length: [227]   Content-Type: [application/json;charset=utf-8]   Date: [Sat, 10 Aug 2019 16:33:21 GMT]   Server: [Windows-Azure-HDFS/1.0 Microsoft-HTTPAPI/2.0]   X-Ms-Error-Code: [AuthorizationPermissionMismatch]   X-Ms-Request-Id: [206085ca-601f-0035-2699-4f617e000000]   X-Ms-Version: [2018-11-09]

也如我们所期望的那样，向zone-b这个未授权目录的写入失败了。本次实验充分证明，ADLS Gen2大数据文件系统在ACL方式的加持下，可以轻松实现对目录层级的细粒度权限控制。

总结

Azure Data Lake Storage Gen2是微软Azure全新一代的大数据存储产品，专为企业级数据湖类应用所构建。它被称为“不妥协的存储基础设施”，是因为它继承了Azure Blob Storage易于使用、成本低廉的特点，同时又加入了目录层次结构、细粒度权限控制等企业级特性。值得一提的是，这个新近发布的PaaS服务也已经在Azure中国区正式上线。如果您近期有基于Azure构建数据平台的需求，ADLS Gen2非常值得考虑。

在云间拾遗的本次实践中，我们从无到有地创建了ADLS Gen2实例并进行了上传下载等基本操作；我们还基于一个相对复杂的需求场景深度体验了其权限控制特性。整个的测试体验是相当流畅的。