AWS Athena 和 Google BigQuery 都是亚马逊和谷歌各自云上的优秀产品, 有着相当高的用户口碑. 它们都属于无服务器交互式查询类型的服务, 能够直接对位于云存储中的数据进行访问和查询, 免去了数据搬运的麻烦. 对于在公有云的原生存储上保存有大量数据的许多客户而言, 此类服务无疑非常适合进行灵活的查询分析, 帮助业务进行数据洞察.
AWS Athena 和 Google BigQuery 当然互相之间也存在一些侧重和差异, 例如 Athena 主要只支持外部表(使用 S3 作为数据源), 而 BigQuery 同时还支持自有的存储, 更接近一个完整的数据仓库. 因本文主要关注分析云存储中数据的场景, 所以两者差异这里不作展开.
对于习惯了 Athena/BigQuery 相关功能的 Azure 新用户, 自然也希望在微软云找到即席查询云存储数据这个常见需求的实现方式. 这个问题比较少有直接而正面的回答, 故本系列文章就此专题进行探讨和实验.
我们先以 AWS Athena 为例来看看所谓面向云存储的交互式查询是如何工作的. 我们准备了一个约含一千行数据的小型 CSV 文件, 放置在 s3 存储中, 然后使用 Athena 建立一个外部表指向此 CSV 文件:
这里使用的测试数据来自一个国外的公开数据集, 是中东某地区的信用卡借贷数据, 是公开且脱敏的. 数据来源相关链接为 https://data.opendatasoft.com/explore/dataset/consumer-and-credit-card-loans@kapsarc/information/?disjunctive.periodicity&disjunctive.quarter&disjunctive.load_type
然后我们建立一个简单的 SQL 查询, 用以统计多年来每个季度的总借贷额并以降序排列:
得到的查询结果为:
嗯, 看上去 AWS Athena 轻松地完成了我们的分析任务. 接下来则轮到 Azure 出场了. 总的来说, Azure 可以有多种服务和方式可达到类似 AWS Athena 的分析效果, 不同的方法各自有优势和取舍.
第一种方法, 是使用 Azure Data Lake Analytics(下简称 ADLA). 因为从产品布局上讲, ADLA 是与 AWS Athena 最为对应的 Azure 服务. 该服务最初于 2015 年公布, 于 2016 年 GA, 笔者两年前系统梳理微软生态的文章中曾提到了它. 该服务可通过与第一代的 Azure Data Lake Storage(下简称 ADLS)配套使用, 实现大规模的数据并行处理与查询. 其主要支持的查询语言是 U-SQL, 一个结合了 SQL 与 C# 特点的独有语言.
百闻不如一见, 我们还是直接动手尝试一下, 使用 ADLA 来实现上面 Athena 的同样任务. 首先, 需要把待分析文件存入配合使用的存储服务 ADLS(ADLA/ADLS 相关服务并未在 Azure 中国区上线, 此处使用的是 Global Azure):
其次, 需要新建一个 ADLA 的服务 "账户" 并指向刚才的 ADLS 存储:
然后就可以开始进行数据查询了. 任务 (Job) 是 ADLA 中的核心概念, 我们可以新建一个任务, 配以一段 U-SQL 脚本来表达和前面 Athena 例子中 SQL 相同的语义:(ADLA 没有交互式查询窗口, 所以我们把结果落地存储到一个 CSV 文件中)
可以看到 U-SQL 写起来很有意思, 的确是结合了 C# 和 SQL 的语法与特点. 与 SQL 类似, 其核心处理对象为 RowSet, 即行的集合. 我们的脚本中没有使用外部表 (U-SQL 中外部表仅支持 SQLServer 系数据库) 但通过 Extractors.CSV 方法达到了同样的目的. 事实上更复杂的 U-SQL 脚本还可以添加上 C# 类库引用和函数调用等功能, 这样结合两种语言的优势来撰写脚本可发挥各自优势, 使得 ADLA 具有十分强大的分析能力.
然后我们执行这个任务, ADLS 的引擎就会开始执行相应脚本, 同时绘制出具体的执行计划和步骤:
最后我们看一下输出文件的内容, 同前面的结果是一致的:
整个流程走下来, 可以看到 ADLA 作为一个完全托管的服务, 与 Athena 的设计理念的确是比较相近的, 也能够轻松使用脚本直接针对对象存储中的数据文件进行数据分析. 从 Azure Portal 上来看, 整套产品也有着颇高的完成度:
然而, 通过实际的操作和体验, 我们也发现了 ADLA 在产品层面也还是存在一些短板, 使得其使用范围较为受限:
ADLA 必须配合 ADLS Gen1 存储使用, 不能适用于最为常见的 Azure Blob Storage, 这在很多时候需要额外的数据搬运, 也不便于应用程序集成;
U-SQL 语言虽然有独到之处, 但毕竟有些 "四不像", 配套的开发环境也尚不够成熟, 导致了学习和迁移成本很高, 调试起来更是非常麻烦(如果不熟悉语法, 即便是上面这小段 U-SQL 也需要折腾好一会儿);
该服务主要为超大规模数据处理查询所设计和优化, 对于日常小规模的简单数据处理显得过于笨重和缓慢, 例如我们上面的脚本居然需要 1 分钟左右来执行.
也许正由于如上所述产品上的种种不足, 它正式发布后叫好不叫座, 市场反应比较冷清. 逐渐地, ADLA 产品似乎进入了维护状态, 新特性的更新较为缓慢; 而坊间更是传闻相应团队已经重组, 与 Azure Storage 及其他大数据产品团队进行了整合 -- 这一结果委实令人唏嘘. 要知道在 ADLA/ADLS 诞生之初, 它们可是背负着将微软内部大数据平台 Cosmos(非现在的 CosmosDB)进行云产品化的重任.
其实我们愿意相信 ADLA 背后的技术是十分过硬的, 如果它在产品层面有更多的思考, 例如更注重与现有 Hadoop 大数据生态和 SQL 体系的融合, 或是进一步加入和充实. NET 生态(如提供 C# LINQ Provider), 也许会有不同的结果. 如今 ADLA 渐行渐远的背影显得有几分落寞, 但将来如果有可能, 我们由衷期待它以另一种形式王者归来.
让我们回到本文的主题: 面向云存储的交互式数据查询. 综上所述, ADLA 不失为一个可行的办法, 但它也存在一些局限和问题, 而且在中国区并未发布. 那么在 Azure 上是否还有其他的选择呢? 答案是肯定的. 作为第二种方法, 我们可以借助源自 SQL Server 体系的一项神奇技术. 欲知详情如何, 且听下回分解.
来源: https://www.cnblogs.com/yunjianshiyi/p/azure-athena-adla.html