用户超过10人就玩完：Gartner称，数据湖搞不定SQL并发机制！

Spark的支持者Databricks宣称，我们正在努力解决这个问题。

据Gartner声称，数据湖在试图执行SQL查询时，很难支持10个以上的用户，而SQL查询曾经被视为完全适合数据仓库技术。

处理数据湖时，Apache Spark是使用最广泛的处理引擎，原因在于它是一种单一的框架，既可以处理机器学习和图形处理，还可以执行批处理（能够支持实时处理）。这家知名调研公司表示，然而，Spark不适合同时试图使用SQL查询数据的许多企业用户。

Gartner的分析师兼高级总监Sumit Pal表示：“使用来自数据湖的数据面临的一些挑战在于并发机制方面。并发活动密集、甚至并发用户数量达到两位数，常常会降低数据湖的速度，这表现在延迟时间变长。”

数据湖技术一直在努力通过支持SQL，使企业用户更容易访问所存储的续流数据。比如说，去年11月，数据管理和机器学习框架厂商Databricks预览了就为了这个用途的SQL Analytics。Databricks的这个开放格式数据引擎基于Delta Lake，旨在为现有的数据湖确保规范和高性能。

与此同时，AWS的数据湖：Elastic Map Reduce可以通过SQL Workbench或Presto SQL来处理SQL查询。Azure在其数据湖（HD Insight或Azure Databricks）中支持SQL查询，而谷歌云平台（GCP）使用了Bigtable、Dataflow和Bigquery的组合。

但是巨头们实现的这些系统无法处理“传统”数据仓库支持的SQL查询数量，其中一些可能扩展到成千上万个并发用户。

延迟和并发是大问题

Pal告诉参加Gartner数据暨分析峰会的与会人士：“如今数据湖实际上并没有用于商业智能（BI）工作负载，尤其是并没有用于需要高并发性和低延迟的大型组织。过去在数据湖上开发出来的SQL引擎其实从未真正满足过并发性和延迟这两方面的要求。”

Databricks CEO Ali Ghodsi表示，这家公司已经意识到了并发问题，正在努力改进。“并发是Spark之类的技术未能做好的方面。这一直是我们关注的重点。”

他说：“我们已经在超大数据仓库方面处于世界一流水平：我们可以处理数量众多的数据，而且可以比其他任何公司更快速、更出色地处理，但是当数据仓库很小，同一个仓库上又有许多不同的并发用户（比如32个用户），这未必是我们最擅长处理的。”

Ghodsi表示，最初于去年7月构建的SQL Analytics起初无力支持32个并发用户，但是2月份的版本表明，它能够为一个SQL端点每小时处理来自32个用户的19000个查询。他表示，为了支持更多的用户，客户可能需要在云端启动更多的端点。