揭秘指南：如何让Databricks中的数据为最终用户所用-原创手记-慕课网

使用 Databricks 提供和消费数据，你需要知道的一切

使用Databricks进行数据处理和消费

关于在 Databricks 中处理数据的文章和资源有很多，但讨论如何达到最终目标的文章却少得多：使数据可供最终用户或应用程序访问。最终目标是：让数据对最终用户或应用程序可用。

我们有哪些选择？
每个选项的优缺点是什么？
什么时候选这个不选那个比较好？

一方面，有一些内置的解决方案，比如(AI/BI)仪表板，以及最近的Databricks Apps。这些设计旨在使数据使用尽可能简单，同时让用户留在Databricks生态系统中。但如果一家公司已经使用了类似PowerBI的工具，需要更强大的功能，或者有更高的需求呢？

本文将介绍所有选项，帮助您为组织挑选最合适的一项。

Databricks 中的数据生命周期和治理

为了理解所有选项，让我们先来看看数据在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只是较大数据管道的一部分时，将数据写入外部系统非常理想。例如，如果数据管道包含多个系统，Databricks可以将处理后的数据写入管道中的下一个环节。或者，下一个系统可以直接访问甚至修改原始文件（如果我们正在处理外部表）。
另一个常见的场景是当主要的分析环境在Databricks之外主导数据处理时。
对于像超低延迟这样的需求，使用专门的SQL仓库可能会更好，此时外部系统可能更为合适。

平台上：

数据可以在 Databricks 生态系统内保留并使用。当用户主要在 Databricks 中工作时，或者 Databricks 中的工具和仪表板能够满足所有需求时，这种情况特别适用。

由于将数据导入其他系统取决于目标系统的特性和接口，因此如果数据仍然留在平台上，我们将继续关注可用的选项。

Databricks中的数据消费选项

内置的消费工具

Databricks（AI/BI）数据面板

Databricks 提供了内置工具，可以使用 Databricks SQL 创建仪表板和图表。我们可以编写针对数据的 SQL 查询，并以不同图表展示结果。这样可以轻松集成和实时查看数据，因为所有内容都在平台上，因此。

示例零售收入与供应链仪表盘（在Databricks中）

使用这些仪表板，团队可以探索数据，分享发现，而无需离开Databricks。这是一种简单直接的方式，让数据易于获取，尤其是对于熟悉平台的用户和简单的报告需求来说。

Databricks 应用

另一种选择是在Databricks中构建自定义应用。这可能涉及使用像Streamlit或Plotly这样的库来创建交互式数据应用。这种方法提供了高度的定制化和交互性。当需要构建专门的分析应用或数据探索工具而仪表板不够用时，这种方法特别适用。

Databricks 的演示应用

使用仪表板和应用程序的好处在于，它们处理开发应用程序时最让人头疼的部分，即治理、安全和托管这些方面。由于直接集成在 Databricks 生态系统中，我们可以利用现有的系统，而不需要额外的基础架构或治理层。由于应用程序仍然是一个相对较新的功能，我们仍然需要测试它们在价值与成本方面的可行性。

与外部工具整合

如果内置工具不能满足所有需求，或者用户更喜欢其他应用程序，Databricks 提供了多种方法来集成外部工具，同时保持数据在平台内部。这里的选择是，我们是否想使用 Databricks 的计算选项（其隐含的治理体系）来访问数据，或者直接从云提供商那里获取原始数据。

使用 SQL 数据仓库或通用集群环境

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 适合以下场景：

在一个不允许直接数据库连接的环境中工作。
需要一种无需安装数据库驱动的轻量级查询方法。
我们正在与采用HTTP协议的系统进行集成。

用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 直接连接的理想场景是：

我们正在开发一个Python应用程序或脚本，该应用需要与SQL仓库进行交互。
我们更喜欢使用熟悉的Python库来处理数据库连接。
我们希望在执行查询的同时利用Python的数据处理能力。

了解SQL仓库和通用集群之间的网络区别

选择SQL仓库和通用集群时，也需要考虑网络因素。在Databricks架构里，无服务器计算资源如SQL仓库在Databricks账号内运行，而传统的计算资源，比如通用集群，则运行在客户的云账户中。

Azure Databricks 架构概要

对于大型组织而言，保持安全和合规，建立与Databricks之间的私有通道至关重要。然而，根据不同类型的资源，这个设置过程会有所不同。

无服务器资源（SQL 仓库）：由于无服务器资源是在 Databricks 账户中管理的，创建私有连接需要设置 网络连接设置 （NCC）并使用诸如 私有链接 这样的服务来建立 Databricks 和外部应用之间的私有访问路径。这种设置可以实现不通过公共互联网的数据访问，但会增加一些配置复杂度。外部应用程序也必须配置为通过这些私有路径进行连接，这可能会影响您选择的工具，取决于它们是否支持此类网络配置。
通用集群：运行在客户云环境中，这些集群可以实现更加灵活和个性化的网络设置，例如配置 VPC、私有子网和安全组。这使组织能够完全控制入站和出站流量，这通常使集成到云环境中的其他资源变得更加容易，而无需使用额外的服务如 NCC。

这里有一点很重要，无服务器资源依然会在与工作区相同的区域内创建，保证区域一致性：“Azure Databricks 在与您的工作区经典计算平面相同的 Azure 区域中创建无服务器计算资源。”（更多详情，请参阅此链接）

读取原始 Parquet 文件 / Delta 表格,

除了利用 Databricks 的计算资源之外，还可以直接访问原始的 parquet 文件 / delta 表，这些文件存储在云端。这种方法绕过了 Databricks 的治理层，在某些情况下治理要求较低或者必须直接访问时，这种方法可能是合适的。

直接访问原始文件的原因

有时候，直接访问原文件可以带来点好处：

外部工具整合: 在集成外部系统时，直接访问可以简化数据共享过程，而无需使用Databricks计算资源。
成本优化: 如果只需要检索数据而不需要额外计算，这种方法可以降低Databricks集群的成本。

关键考虑

认证与权限: 访问原始文件需要直接在云存储上配置权限，而不是依赖于 Databricks 的基于角色的访问控制。
Delta 格式兼容性: 如果数据以 Delta 格式存储，必须确保外部工具能够处理 Delta Lake 格式和元数据，因为并非所有功能都能在 Databricks 之外使用（例如，DuckDB 最近在与 Databricks 合作后，已经增加了对 Delta Lake 的原生支持 — YouTube 上的演示视频）
数据组织与结构: 没有 Unity Catalog 提供的结构，手动管理和维护目录路径及文件组织就变得至关重要。

合适的用例

直接访问这些原始Parquet文件在以下情况可能有帮助：

数据治理需求较小： 对于不需要集中治理的情况，这种方案提供了一个简单的替代选择。
轻量级数据访问场景： 在进行简单的读取操作而不需使用Databricks计算资源时。

总之，虽然绕过Databricks的治理层框架可能并不总是符合最佳实践，但直接访问原始的Parquet文件在某些数据处理流程中提供了更大的灵活性和成本效益。

访问 Unity Catalog 中的数据外部访问

到目前为止，我们已经讨论了这些内容：

如何使用Databricks计算选项功能和Unity Catalog治理功能来访问数据的方式。
如何使用外部引擎访问存储在云存储中的Databricks内部生成的原始数据/delta表等（不使用Unity Catalog）。

在这一章中，我们将讨论如何通过 Unity Catalog 获取数据，并使用外部处理引擎保持治理并符合合规性。

凭证分发和授予外部引擎访问的概述

对于外部引擎（如 Apache Spark、Trino、Microsoft Fabric 和 Iceberg API 客户端）访问存储在 Unity Catalog 中的数据存储，Azure Databricks 提供了一个称为 凭证分发 的功能。此功能允许 Databricks 实体（用户、组或服务主体）请求一个临时凭证，以启用外部数据访问。该凭证包含一个临时访问令牌和一个云存储 URL，允许外部引擎读取（或写入）由 Unity Catalog 管理的存储位置。

凭证分发确保所有访问都受到严格管理，具有时效限制，并仅限特定授权用户。

如何在 Unity Catalog 中启用外部数据访问

元数据存储设置

Unity Catalog 元数据存储库必须明确开启 外部数据访问功能。该设置默认是关闭的，以防止数据意外泄露。只有元数据存储的管理员才能在目录面板中的元数据存储设置中启用此设置。

元数据仓库配置

人脉：

Databricks 工作区访问权限：外部引擎必须能够访问管理 Unity Catalog 的 Databricks 工作区。这可能涉及到配置 IP 访问列表或 Azure 私有链接。
云存储访问权限：临时访问凭证允许外部引擎访问存储 Unity Catalog 表格的云存储系统。我们需要配置云存储的访问控制（防火墙和访问控制列表）以仅允许授权的外部引擎。

权限需求：

请求的主用户必须在其包含该表的模式（schema）上具有 EXTERNAL USE SCHEMA 权限。
他们还必须具有该表上的 SELECT 权限，以及包含该表的目录（catalog）和模式（schema）上的 USE CATALOG 和 USE SCHEMA 权限。
需要注意的是，模式所有者默认并没有 EXTERNAL USE SCHEMA 权限，必须明确由目录所有者授予，以防止未经授权的数据访问。

表格限制：

在公共预览阶段，只有表可以进行外部访问。视图、物化视图、Delta Live Tables流式表以及其他高级表类型（如Lakehouse联邦表）不支持外部访问。
外部表既支持读取也支持写入，而对外部引擎来说，托管表是只读的。

请求临时访问外部数据的凭证

设置完成后，授权用户可以使用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管理的数据，但必须认识到某些治理功能，如数据血缘追踪或表生命周期管理，仅在数据在Databricks中处理时可用。
临时凭证管理：由于临时凭证有效期较短，外部系统可能需要凭证刷新机制或轮换凭证来支持长期运行的工作负载或自动化数据集成。
成本优化：通过使用外部引擎来处理特定工作负载，组织可以通过减少对Databricks集群的依赖程度来优化成本。

总之，允许外部访问 Unity Catalog 数据提供了多平台集成的灵活性，同时保持管理和控制的完整性。

Delta 分享功能

Delta Sharing 是 Databricks 开发的一种协议，旨在促进安全、可扩展且不受平台限制的数据共享。它设计用于支持各种数据平台，并让组织能够在不同的云环境里以及与外部合作伙伴之间共享数据和 AI 资产。此功能也是 Databricks Marketplace 的基石，在本章中，我们将看看 Delta Sharing 是怎么运作的，它的关键部分以及实际用处。

Delta Sharing: 是怎么运作的

Delta Sharing 是基于一个开放协议构建的，支持跨平台的数据交换，即使接收方不使用 Databricks 时。它利用 Delta Sharing 服务器为接收方提供安全的只读访问权限，支持在 Databricks 内外的数据交换。虽然 Delta Sharing 是一个开源项目，但自行托管 Delta Sharing 服务器可能会比较麻烦。现在，通过用户界面可以轻松配置 Delta Sharing 服务器。

Delta Sharing 数据目录

在 Unity 目录中的 Delta共享分享功能

Delta Sharing提供了三种各自不同的模式。

Databricks 到 Databricks 共享：允许启用 Unity Catalog 的 Databricks 工作区之间的数据共享。此模式提供了集成的数据治理、审计、使用跟踪，以及像 Unity Catalog 卷、笔记本和 AI 模型这样的额外资源。
开放共享协议：允许与任何计算平台上的用户共享数据，即使这些用户不在 Databricks 上。提供商可以使用 Unity Catalog 来管理数据，同时扩展对不同平台用户的访问。
客户管理的开源服务器：对于需要更广泛兼容性的组织来说，Delta Sharing 可以作为开源项目部署，支持从几乎任何平台到任何其他平台的数据共享。

Delta Sharing 中的关键概念包括：分享、提供方和接收方

Delta Sharing主要围绕三个核心概念：

Shares : 份额是指提供者向接收者提供的只读的 Delta 表或分区的集合。在 Databricks 与 Databricks 之间的共享中，份额还可以包括视图、Unity Catalog 卷、模型和笔记本。这些份额在 Unity Catalog 中注册为可安全对象，并且提供者可以随时添加或移除数据资产以及管理接收者的访问权限。
Providers : 提供者是指向接收者提供数据的实体。提供者至少需要一个启用 Unity Catalog 的工作空间来管理份额和接收者。在 Unity Catalog 的上下文中，提供者同时也是代表数据共享组织的可安全对象。
Recipients : 接收者是指访问提供者共享的数据的实体。在 Unity Catalog 中，接收者是与授予访问一个或多个份额权限的凭证关联的可安全对象。提供者必须为每个 Unity Catalog 元数据存储库明确定义接收者，从而能够跨多个份额管理权限。

添加 Delta 分享接收者

开放共享（Open Sharing） vs. Databricks间的共享

选择公开共享还是Databricks间的共享，取决于接收方的环境和要共享的资产。

开放共享：此方法允许提供者与任何用户或平台共享数据，使用基于令牌的凭据来确保数据安全。接收方可以使用诸如 Power BI、Apache Spark 和 Pandas 等流行工具来访问这些数据。
Databricks 到 Databricks 共享：专为启用了 Unity Catalog 的 Databricks 工作区上的接收方设计，此方法不需要令牌认证。相反，访问直接通过 Databricks 管理，提供了更加无缝的共享体验。此方法还支持共享如视图、数据卷、模型和笔记本等额外的 Databricks 资产，这些资产无法通过开放共享获取。

提供者如何配置 Delta 共享

设置 Delta Sharing 包括配置 Unity Catalog 元数据存储来启用数据共享，定义共享以及接收方。

启用 Delta Sharing 在元数据存储中：Databricks 账户管理员在 Unity Catalog 中的元数据存储中启用 Delta Sharing。

启用 Delta Sharing 在元数据存储中

创建和配置共享：提供商可以将 Delta 或 Parquet 表添加到共享中，同时根据使用 Databricks 间共享的情况，可以添加视图、卷、模型和笔记本。
定义接收者：在每个元数据存储中，提供商定义接收者，这些接收者被授予特定共享的访问权限。在开放共享中，会为接收者生成基于令牌的凭据；而 Databricks 间共享的接收者则通过共享标识符来识别。
授予访问权限：提供商可以在任何时候管理访问权限，为每个共享上的接收者分配或撤销权限。
分发访问信息：在开放共享中，提供商通过安全渠道向接收者发送激活链接或访问令牌。对于 Databricks 间共享，接收者会在其 Databricks 工作区中自动获得访问权限。

配置 Delta 共享

收件人权限及使用说明

接收者可以以只读格式访问 Delta Sharing 资产。访问方法根据协议的不同而有所不同，

开放共享：接收者使用基于令牌的凭证进行身份验证，并可以通过诸如Spark、Pandas和Power BI等工具进行连接。
Databricks到Databricks共享：接收者可以直接在其启用Unity Catalog的工作区中访问数据。此方法还允许接收者为其组织中的其他用户授予或拒绝访问权限，从而简化访问管理。

提供商对共享数据资产所做的更改几乎立即同步给接收方，确保数据的一致性。

监控和审计共享数据的访问

Delta Sharing 包含审计功能，让提供方和接收方可以追踪数据共享活动。Azure Databricks 审计日志和系统表提供了关于共享创建、接收方管理和数据访问情况的详细信息。

Databricks到Databricks共享的高级特性

Databricks到Databricks协议支持多种高级共享功能。

共享卷和模型：Unity Catalog 卷和模型可以与表和视图一同共享，使 Databricks 之间的分享非常适合处理复杂的数据和 AI 场景。
笔记本共享：可以将笔记本以只读格式共享，允许接收者克隆并根据需要修改副本。
动态视图共享：可以在视图层级控制行和列的访问权限，根据接收者的属性实现有效的数据治理。
流处理支持：接收者可以利用共享表的历史数据作为流处理的来源，支持低延迟的增量处理。

Delta Sharing 实践案例：应用场景和好处

Delta Sharing的灵活和安全特性，使之非常适合各种数据共享场合。

跨组织数据协作：组织可以安全地与外部合作伙伴、客户或供应商交换数据，无论采用何种计算平台。
多云和混合架构：Delta Sharing 支持各种云和本地数据架构，使组织能够从多个来源集成数据。
成本效益性：通过消除数据复制的需要，Delta Sharing 降低了数据传输成本，为区域数据交换提供了成本效益的解决方案。

关键考虑事项

安全与合规性：Delta Sharing 的令牌安全机制、凭证撤销和活动审核提供了一个强大的安全基础。
出口成本：尽管 Delta Sharing 避免了区域内的出口费用，但跨区域和跨云的数据共享仍可能产生额外费用。提供商应根据需要监控和管理这些费用。
功能限制：一些高级 Delta Lake 功能和对象类型（如物化视图等）在开放共享中不受支持。Databricks 到 Databricks 共享支持这些功能，但开放共享存在一定的限制。

摘要：选择合适的方法

总之，让Databricks的数据对最终用户变得可访问是关于理解所有可用选项，并考虑到用户需求和技术框架。对于已经在Databricks上进行投资的团队，平台内的选项，例如Databricks仪表板和应用，提供了一种将数据洞察直接传递到用户手中的简便方法。然而，如果您的组织依赖于外部工具如Power BI，或者您需要更多地控制数据所在的位置，外部集成选项可以将Databricks的数据与您的现有基础设施无缝对接。

最后，记得注意您组织的安全和管理要求，确保数据访问既安全又符合规定。希望这篇文章能给您带来帮助，期待在下一篇文章中与您相见。

祝你一切顺利嘿，
Eduard

我的名字是埃德乌尔德·波帕，我是一名数据工程师及顾问，帮助组织构建基于Azure和Databricks的云数据平台。

在过去5年多的时间里，我花了超过7000小时之多搭建了数据平台并且应用了各种数据方案，现在想要与你分享我在这一路上学到的东西。

如果你对这种类型的内容感兴趣，可以考虑订阅我的邮件通讯。

[Databricks 专家 | Eduard Popa | Substack

关于使用 Azure 和 Databricks 进行企业级数据工程的通讯。点击阅读更多关于 Databricks 的内容…eduardpopa.substack.com](https://eduardpopa.substack.com/?source=post_page-----00b1b2cb172b--------------------------------)

如果你想和我一起工作，你可以预约一次免费的一对一通话，可以在这里：Calendly 或者联系我：eduard.popa@x-data.ro