使用Databricks进行数据处理和消费
关于在 Databricks 中处理数据的文章和资源有很多,但讨论如何达到最终目标的文章却少得多:使数据可供最终用户或应用程序访问。最终目标是:让数据对最终用户或应用程序可用。
一方面,有一些内置的解决方案,比如(AI/BI)仪表板,以及最近的Databricks Apps。这些设计旨在使数据使用尽可能简单,同时让用户留在Databricks生态系统中。但如果一家公司已经使用了类似PowerBI的工具,需要更强大的功能,或者有更高的需求呢?
本文将介绍所有选项,帮助您为组织挑选最合适的一项。
为了理解所有选项,让我们先来看看数据在Databricks内部是如何被处理和使用的。数据从各种来源——例如对象存储、数据库或流服务——被摄入,并在Databricks内部进行处理。这里有两个关键考虑因素是 数据治理 和 存储 ,因为这些因素大大影响数据在Databricks中的使用和管理方式。既然Unity Catalog代表了Databricks平台的未来,我们将重点讨论启用Unity Catalog时的选择。
为了理解如何在 Databricks 中访问数据,我们需要了解 Unity Catalog 的治理模型。因为整个设置可能相当复杂,我们将详细解释这些设置的影响。
Unity 目录层次结构 (Unity Catalog Hierarchy)
Unity Catalog的基础是元存储(metastore)。每个Databricks账户在一个区域只能有一个元存储(并且所有属于同一个Databricks账户的工作区都位于同一个云租户中)。在创建元存储时,我们可以指定一个根位置。如果没有指定,我们每次创建新目录时都需要定义一个位置。
这很重要,因为如果我们选择指定某个位置,那么当我们创建目录、模式和表时,如果没有再指定位置,它们就会被存放在这个位置了。
当我们想要创建一个目录或目录时,我们可以指定一个特定的存储位置,但这不仅仅是指向对象存储的路径。它是一个“外部位置”。外部位置结合了一个“存储凭据”(一个标识符)和一个“存储路径”。
之前,使用Hive元数据仓库,我们实际上只有两个选择:
在这个设置中,该路径指向一个对象存储:abfss://container@storageaccount.dfs.core.windows.net/table_name
现在,Unity Catalog 让我们能够为每个对象级别指定 外部 位置 —— 元数据仓库、目录、模式和表。这意味着我们可以在这样的 外部位置 中创建一个 目录 和 模式,并且如果我们不指定位置来创建表,它仍然会被视为一个 托管表。
这种配置给组织提供了数据存储位置的灵活性选择,同时还可以利用 Unity Catalog 的治理能力。然而,这可能会让人感到有些困惑,当我第一次听到“外部位置”这个词时,以为所有的表都是外部表。
总而言之,决定一个表是否受管理或不受管理(外部)的唯一因素是是否为该表指定了存储位置。
但是, “托管表” 或 “外部表” 真正指的是什么?成为 Unity Catalog 治理模型的一部分对表来说又意味着什么?
在第二个例子中,我们创建了一个外部表,它仍然属于 Unity Catalog 的治理范围。只要我们在创建表时指定了完整的路径,例如 <catalog-name>.<schema-name>.<table-name>
,它将作为 Unity Catalog 治理范围的一部分,但仍会存储在我们指定的元存储 / 目录 / 模式级别的位置。
这意味着如果我们删除Databricks中的外部表,底层数据不会被删除。而对于管理表,云提供商应在最多30天内删除数据(详情请参阅此处)。但是,我们仍然可以对表进行治理。
为什么这都这么重要?
这一区别非常重要,因为它影响数据的可访问性和管理。例如,当我们希望通过Unity Catalog来控制数据的访问方式时,就会发现外部表和托管表这类表之间存在不同之处。
了解如何在 Unity Catalog 中控制数据的外部访问权限:在 Unity Catalog 中控制数据外部访问权限
说到底,这也取决于对数据存储位置及管理方式的掌控,以及我们是否愿意依赖Databricks的治理体系并利用其计算资源来进一步处理数据。要知道,我们依然可以保持外部表的存在,这些表仍然属于Unity Catalog的治理框架,而托管表则可以存储在我们希望的地方。
然而,其他功能,如液体聚类,需要被管理的表。这是因为对于这些被管理的表,Databricks 控制表的生命周期和文件结构。在使用管理表时,不建议直接操作底层文件。
在谈到数据生命周期过程时,Databricks 中的数据存储在 Delta 表中,并通过质量和聚合处理阶段,遵循 medallion 架构(即金质、银质和铜质数据模型)。一旦数据达到预期状态,我们有两个主要的选择。
外部系统的集成
平台上:
由于将数据导入其他系统取决于目标系统的特性和接口,因此如果数据仍然留在平台上,我们将继续关注可用的选项。
Databricks(AI/BI)数据面板
Databricks 提供了内置工具,可以使用 Databricks SQL 创建仪表板和图表。我们可以编写针对数据的 SQL 查询,并以不同图表展示结果。这样可以轻松集成和实时查看数据,因为所有内容都在平台上,因此。
示例零售收入与供应链仪表盘(在Databricks中)
使用这些仪表板,团队可以探索数据,分享发现,而无需离开Databricks。这是一种简单直接的方式,让数据易于获取,尤其是对于熟悉平台的用户和简单的报告需求来说。
Databricks 应用
另一种选择是在Databricks中构建自定义应用。这可能涉及使用像Streamlit或Plotly这样的库来创建交互式数据应用。这种方法提供了高度的定制化和交互性。当需要构建专门的分析应用或数据探索工具而仪表板不够用时,这种方法特别适用。
Databricks 的演示应用
使用仪表板和应用程序的好处在于,它们处理开发应用程序时最让人头疼的部分,即治理、安全和托管这些方面。由于直接集成在 Databricks 生态系统中,我们可以利用现有的系统,而不需要额外的基础架构或治理层。由于应用程序仍然是一个相对较新的功能,我们仍然需要测试它们在价值与成本方面的可行性。
如果内置工具不能满足所有需求,或者用户更喜欢其他应用程序,Databricks 提供了多种方法来集成外部工具,同时保持数据在平台内部。这里的选择是,我们是否想使用 Databricks 的计算选项(其隐含的治理体系)来访问数据,或者直接从云提供商那里获取原始数据。
Databricks 提供了 SQL 仓库(以前称为 SQL 终端节点)和 多功能集群,作为用于执行查询的数据计算资源。SQL 仓库针对 SQL 工作负载进行了优化,并默认启用了 Databricks 的高性能查询引擎 Photon。
SQL 数据仓库连接详情
两者都支持JDBC和ODBC连接,这使得它们可以与许多业务智能工具兼容(对于这些工具,我们也可以使用Partner Connect实现更简单的连接过程),比如Power BI和Tableau,甚至是自定义的应用程序。这意味着用户可以继续使用他们喜欢的工具,同时直接从Databricks获取数据。
适用于所有用途的集群连接信息
为了Python应用,Databricks还提供了Python SQL连接器。
这简化了从Python代码连接到SQL仓库的方式,使开发人员在应用程序中执行查询并检索数据。还可以使用Databricks REST API来执行SQL语句并获取结果数据。
通过 REST API 执行的示例 SQL 语句
理解:使用REST API接口和Python连接器之间的区别
当我们进行程序化集成时,我们可能会考虑使用Databricks的REST API,或者直接使用Python的SQL Connector连接到Databricks。选择这两种方法取决于我们与Databricks平台互动的方式,以及每种方法提供的抽象程度。
使用REST API来
使用 REST API 意味着向 Databricks 端点发出 HTTP 请求来执行 SQL 语句。这种方法是跨语言的,可以从任何可以发出 HTTP 请求的编程语言中访问到,使得它可以灵活地与各种系统和应用程序集成。
然而,REST API 往往需要处理异步操作。我们可能需要轮询查询的执行状态,并根据响应采取相应处理。我们还需要手动处理诸如构造 HTTP 请求、解析 JSON 响应、管理身份验证令牌以及错误处理方面等任务。
REST API 适合以下场景:
用Python直接连接
直接使用Python连接时,需要使用[Databricks SQL Connector for Python](https://pypi.org/project/databricks-sql-connector/)(Python的Databricks SQL连接器)。根据官方的pypi文档。
Databricks SQL Connector for Python 允许你开发连接到 Databricks 集群和 SQL 仓库的 Python 应用程序。它是一个基于 Thrift 的客户端,不依赖于 ODBC 或 JDBC。它符合 Python DB API 2.0 规范,并提供了一个 SQLAlchemy 方言,可以与使用 SQLAlchemy 执行 DDL 的工具如
pandas
和alembic
一起使用。使用pip install databricks-sql-connector[sqlalchemy]
命令安装带 SQLAlchemy 依赖项的版本。使用pip install databricks-sql-connector[alembic]
命令安装带 Alembic 依赖项的版本。此连接器使用 Arrow 作为数据交换格式,并且支持直接获取 Arrow 表格的 API。Arrow 表格被封装在
ArrowQueue
类中,以提供按批次获取多行数据的自然接口。
pip install databricks-sql-connector[sqlalchemy]
运行此命令以安装与SQLAlchemy兼容的Databricks SQL连接器。
通过使用Python SQL Connector,我们可以使用包含服务器主机名、HTTP路径和身份验证凭证的连接字符串直接连接到Databricks。这种方法可以让我们使用标准的数据库API接口,提供执行查询、获取结果和处理事务的功能。查询执行一般是同步的,我们在Python应用程序中可以直接接收到Python对象形式的结果,比如列表或字典。
Python 直接连接的理想场景是:
了解SQL仓库和通用集群之间的网络区别
选择SQL仓库和通用集群时,也需要考虑网络因素。在Databricks架构里,无服务器计算资源如SQL仓库在Databricks账号内运行,而传统的计算资源,比如通用集群,则运行在客户的云账户中。
Azure Databricks 架构概要
对于大型组织而言,保持安全和合规,建立与Databricks之间的私有通道至关重要。然而,根据不同类型的资源,这个设置过程会有所不同。
这里有一点很重要,无服务器资源依然会在与工作区相同的区域内创建,保证区域一致性:“Azure Databricks 在与您的工作区经典计算平面相同的 Azure 区域中创建无服务器计算资源。”(更多详情,请参阅此链接)
除了利用 Databricks 的计算资源之外,还可以直接访问原始的 parquet 文件 / delta 表,这些文件存储在云端。这种方法绕过了 Databricks 的治理层,在某些情况下治理要求较低或者必须直接访问时,这种方法可能是合适的。
直接访问原始文件的原因
有时候,直接访问原文件可以带来点好处:
关键考虑
合适的用例
直接访问这些原始Parquet文件在以下情况可能有帮助:
总之,虽然绕过Databricks的治理层框架可能并不总是符合最佳实践,但直接访问原始的Parquet文件在某些数据处理流程中提供了更大的灵活性和成本效益。
到目前为止,我们已经讨论了这些内容:
在这一章中,我们将讨论如何通过 Unity Catalog 获取数据,并使用外部处理引擎保持治理并符合合规性。
对于外部引擎(如 Apache Spark、Trino、Microsoft Fabric 和 Iceberg API 客户端)访问存储在 Unity Catalog 中的数据存储,Azure Databricks 提供了一个称为 凭证分发 的功能。此功能允许 Databricks 实体(用户、组或服务主体)请求一个临时凭证,以启用外部数据访问。该凭证包含一个临时访问令牌和一个云存储 URL,允许外部引擎读取(或写入)由 Unity Catalog 管理的存储位置。
凭证分发确保所有访问都受到严格管理,具有时效限制,并仅限特定授权用户。
元数据存储设置
元数据仓库配置
人脉:
权限需求:
表格限制:
设置完成后,授权用户可以使用Unity Catalog REST API来请求一个临时凭证。此凭证允许用户临时访问指定的表,允许外部引擎根据权限进行读写操作。
这里展示了一个通过REST API调用来获取临时凭证的例子:
curl -X POST -H "Authentication: Bearer $OAUTH_TOKEN" \ https://<workspace-instance>/api/2.1/unity-catalog/temporary-table-credentials \ -d '{"table_id": "<table-identifier>", "operation_name": "<READ|READ_WRITE>"}'
此 API 请求将生成一个临时访问令牌和云存储 URL,这些信息可提供给外部引擎使用。只有具有 HAS_DIRECT_EXTERNAL_ENGINE_READ_SUPPORT 或 HAS_DIRECT_EXTERNAL_ENGINE_WRITE_SUPPORT 的表才有资格参与此凭证发放流程。这些表可以通过ListTables API中的 include_manifest_capabilities
选项来识别。
总之,允许外部访问 Unity Catalog 数据提供了多平台集成的灵活性,同时保持管理和控制的完整性。
Delta Sharing 是 Databricks 开发的一种协议,旨在促进安全、可扩展且不受平台限制的数据共享。它设计用于支持各种数据平台,并让组织能够在不同的云环境里以及与外部合作伙伴之间共享数据和 AI 资产。此功能也是 Databricks Marketplace 的基石,在本章中,我们将看看 Delta Sharing 是怎么运作的,它的关键部分以及实际用处。
Delta Sharing 是基于一个开放协议构建的,支持跨平台的数据交换,即使接收方不使用 Databricks 时。它利用 Delta Sharing 服务器为接收方提供安全的只读访问权限,支持在 Databricks 内外的数据交换。虽然 Delta Sharing 是一个开源项目,但自行托管 Delta Sharing 服务器可能会比较麻烦。现在,通过用户界面可以轻松配置 Delta Sharing 服务器。
Delta Sharing 数据目录
在 Unity 目录中的 Delta共享分享功能
Delta Sharing提供了三种各自不同的模式。
Delta Sharing主要围绕三个核心概念:
添加 Delta 分享接收者
选择公开共享还是Databricks间的共享,取决于接收方的环境和要共享的资产。
设置 Delta Sharing 包括配置 Unity Catalog 元数据存储来启用数据共享,定义共享以及接收方。
启用 Delta Sharing 在元数据存储中
配置 Delta 共享
接收者可以以只读格式访问 Delta Sharing 资产。访问方法根据协议的不同而有所不同,
提供商对共享数据资产所做的更改几乎立即同步给接收方,确保数据的一致性。
Delta Sharing 包含审计功能,让提供方和接收方可以追踪数据共享活动。Azure Databricks 审计日志和系统表提供了关于共享创建、接收方管理和数据访问情况的详细信息。
Databricks到Databricks协议支持多种高级共享功能。
Delta Sharing的灵活和安全特性,使之非常适合各种数据共享场合。
总之,让Databricks的数据对最终用户变得可访问是关于理解所有可用选项,并考虑到用户需求和技术框架。对于已经在Databricks上进行投资的团队,平台内的选项,例如Databricks仪表板和应用,提供了一种将数据洞察直接传递到用户手中的简便方法。然而,如果您的组织依赖于外部工具如Power BI,或者您需要更多地控制数据所在的位置,外部集成选项可以将Databricks的数据与您的现有基础设施无缝对接。
最后,记得注意您组织的安全和管理要求,确保数据访问既安全又符合规定。希望这篇文章能给您带来帮助,期待在下一篇文章中与您相见。
祝你一切顺利嘿,
Eduard
我的名字是埃德乌尔德·波帕,我是一名数据工程师及顾问,帮助组织构建基于Azure和Databricks的云数据平台。
在过去5年多的时间里,我花了超过7000小时之多搭建了数据平台并且应用了各种数据方案,现在想要与你分享我在这一路上学到的东西。
如果你对这种类型的内容感兴趣,可以考虑订阅我的邮件通讯。
关于使用 Azure 和 Databricks 进行企业级数据工程的通讯。点击阅读更多关于 Databricks 的内容…eduardpopa.substack.com](https://eduardpopa.substack.com/?source=post_page-----00b1b2cb172b--------------------------------)
如果你想和我一起工作,你可以预约一次免费的一对一通话,可以在这里:Calendly 或者联系我:eduard.popa@x-data.ro