我们的团队将镶木地板文件放在blob上,其主要用途之一是允许分析师(其舒适区为SQL语法)以表格形式查询它们。他们将在Azure Databricks中执行此操作。
我们已经映射了Blob存储,并且可以从笔记本中访问镶木地板文件。当前,它们已通过以下方式加载和“准备”用于SQL查询:
单元格1:
%python
# Load the data for the specified job
dbutils.widgets.text("JobId", "", "Job Id")
results_path = f"/mnt/{getArgument("JobId")}/results_data.parquet"
df_results = spark.read.load(results_path)
df_results.createOrReplaceTempView("RESULTS")
现在,紧随其后的单元格可以开始执行SQL查询。例如:
SELECT * FROM RESULTS LIMIT 5
起床会花费一些时间,但时间不会太多。我担心两件事:
我是以最有效的方式加载此文件,还是有一种跳过df_results
数据框的创建的方法,该数据框仅用于创建RESULTS
临时表。
我是否以最有效地使用SQL的方式加载SQL表?例如,如果用户计划执行几十个查询,那么我不想每次都需要从磁盘重新读取,但是没有必要在此笔记本之外坚持下去。是createOrReplaceTempView
正确的方法吗?
对于第一个问题:
是的,你可以使用Databricks上的Hive Metastore并查询其中的任何表,而无需先创建DataFrames。有关数据库和表的文档是一个不错的起点。
作为一个简单的例子,你可以使用SQL或Python创建一个表:
# SQL
CREATE TABLE <example-table>(id STRING, value STRING)
# Python
dataframe.write.saveAsTable("<example-table>")
通过这种方式创建或保存表后,无需创建DataFrame或临时视图,就可以直接在SQL中对其进行访问。
# SQL
SELECT * FROM <example-table>
# Python
spark.sql("SELECT * FROM <example-table>")
对于第二个问题:
性能取决于多个因素,但总的来说,这里有一些技巧。
OPTIMIZE
和ZORDER
。 OPTIMIZE
帮助为Spark调整大小合适的文件,并ZORDER
改善数据跳过。我知道你说过没有必要在笔记本之外进行持久化,但是你可以通过创建持久化表并利用数据跳过,缓存等来提高性能。