在此阶段,你将为Azure Databricks工作区和 Unity 目录设计存储基础结构。
若要处理Azure Databricks上的数据,必须配置云存储。 Azure Databricks中有两种类型的存储:
- Azure Databricks托管存储(默认存储):Azure Databricks拥有的云帐户中的存储。 无服务器工作区用于工作区根存储,且可选择用于 Unity Catalog 目录。
- 客户管理的存储:客户云帐户中的存储。 经典工作区用于工作区存储和 Unity 目录存储。
这两种存储类型都使用相同的基础云服务。
设计工作区存储体系结构
工作区存储帐户/存储桶是Azure Databricks工作区的必需部分,用于多种用途:
- 默认 Unity Catalog 目录的存储空间,为此工作区创建。
- 平台上不同服务使用的其他内部生成的数据,例如 MLflow 试验和 MLflow 注册表模型的默认位置、Lakeflow Spark 声明性管道默认位置和 Cloud Fetch。
工作区存储模式
使用客户管理的虚拟网络可以更好地控制工作区系统存储桶。 首先创建根存储桶,然后将其分配给Azure Databricks工作区,同时保留对存储桶策略的完全控制,同时确保工作区仍然可以访问它。
工作区存储的最佳做法
- 使用 Unity 目录外部位置替代默认工作区存储位置。
- 除非绝对必要(从管理页进行配置),否则禁止从 Web 应用上传。
- 不要将工作区根存储桶(DBFS)用于生产客户数据。
- 了解根桶的风险和处理方法。
DBFS 迁移
DBFS (Databricks 文件系统)不应用于新的生产数据。 对于现有部署:
- 结构化数据:将 DBFS 表迁移到 Unity 目录托管表。
- 非结构化数据:将文件从 DBFS 迁移到 Unity 目录卷,以便进行 POSIX 样式的文件访问。
- 工作区文件:继续对笔记本、库和群集日志使用工作区存储(而不是 DBFS)。
设计 Unity 目录存储体系结构
Unity Catalog 目录元存储支持三种类型的对象,这些对象确定数据的存储方式和位置:托管、外部和跨国。
存储对象类型
托管对象
对于托管对象,托管存储位置指定云对象存储中用于存储托管表和托管卷的数据的位置。 可以将托管存储位置与元存储、目录或架构相关联。 层次结构中级别较低的托管存储位置会替代在创建托管表或托管卷时在较高级别定义的存储位置。
重要
不建议依赖默认位置,因为它可能会导致数据意外共址,并且会使访问控制和生命周期的管理变得复杂。 在目录或架构级别显式定义存储位置。
外部对象
外部对象将其数据存储在外部位置。 外部位置将 Unity 目录存储凭据与云对象存储容器(例如,Azure容器)相关联。 外部位置用于:
- 定义目录和架构的托管存储位置。
- 定义外部表和外部卷的位置。
异物
外部目录指定与外部数据系统的连接,用于访问远程表和架构。 可以将外部目录与来自外部源(例如 Hive 元存储、AWS Glue 或 Snowflake Horizon)的元数据相关联。 外部目录提供对远程系统数据库对象的只读访问权限,使你能够通过 Unity 目录查询外部表和架构,而无需复制数据。
云存储体系结构
Azure存储体系结构
在 Microsoft Azure Databricks 上,Unity Catalog metastore 拥有:
- 在元存储级别为托管表指定零或一个 ADLS 存储容器。
- 目录或架构级别用于托管表的零个或多个 ADLS 存储容器。
- 外部表的零个或多个 ADLS 存储容器。
与工作区一样,ADLS 存储容器可以位于不同的Azure订阅中。 Microsoft Azure Databricks 访问连接器(托管标识)为 Unity Catalog 提供身份验证,以访问存储容器。
存储隔离模式
按环境分隔存储
使用不同的存储容器进行开发、过渡和生产环境。 这提供了明确的边界,并防止较低环境意外访问生产数据。
按业务部门分隔存储
当业务部门需要完整的数据隔离以进行治理或计费时,请为每个业务部门使用单独的存储容器和单独的存储凭据。
按数据域分隔存储
在数据网格体系结构中,每个域都应有自己的存储容器,由特定于域的存储凭据管理。
多区域存储设计
如果多个区域使用Azure Databricks,则存储体系结构必须考虑数据区域和跨区域访问模式:
- 在与元存储相同的区域中部署存储容器,以提升性能。
- 使用 Azure Databricks 托管的 Delta Sharing (D2D) 在区域之间共享数据。
- 评估跨区域的数据访问频率和量,以确定是否需要数据复制管道。
- 在跨区域访问数据时,需考虑出口成本。
警告
请勿在多个元存储中将共享表注册为外部表。 风险在于,由于写入元存储 A 而对架构、表属性和注释所做的任何更改都不会向元存储 B 注册。元存储 B 中的表必须重新创建才能具有正确的架构,并且表属性和注释将完全断开连接。 这也可能导致 Delta 提交服务出现一致性问题。 使用 D2D Delta Sharing 在数据存储系统之间共享数据。
设计访问和身份验证策略
Azure Databricks建议使用 Unity 目录来管理对所有数据的访问,特别是建议尽可能使用托管表。 Unity 目录完全管理托管表的存储布局、元数据和治理。
为了管理对保存表和卷的外部云存储的访问,Unity 目录使用外部位置,这些位置定义云存储的路径以及访问该位置所需的凭据。 除了云存储,Unity 目录还管理表、模型和其他资产的权限,并且可以联合到外部目录。
云提供的身份验证方法
Azure身份验证体系结构
在 Azure 中,使用 Microsoft Azure Databricks Access Connectors(托管标识)为 Unity Catalog 访问客户存储:
- 创建 Microsoft Azure Databricks 访问连接器(托管标识资源)
- 使用 Azure RBAC(例如存储 Blob 数据参与者)向访问连接器授予对存储帐户的适当权限
- 在 Unity 目录中将 Access Connector 资源 ID 注册为存储凭据
- 创建使用存储凭证的外部位置
Azure身份验证的最佳做法
- 为不同的存储帐户或数据域使用单独的访问连接器。
- 使用 Azure RBAC 角色应用最低特权权限。
- 使用存储防火墙和专用终结点限制网络访问。
- 启用Azure Monitor以审核对存储帐户的访问。
设计加密策略
客户管理的存储可以使用标准云做法进行加密。 默认情况下,使用云提供商的加密和Azure Databricks管理的密钥对静态数据进行加密。
加密选项
Databricks 管理的密钥(默认值)
默认情况下,使用云提供商的加密和Azure Databricks管理的密钥对静态数据进行加密。 这提供基线加密,无需其他配置。
客户管理的密钥
对于需要客户管理的密钥的组织,每个云都支持它们。 客户管理的密钥通常用于两个目的:
目的 1:控制平面和托管服务加密
使用客户控制下的密钥加密Azure Databricks控制平面、默认存储和支持的无服务器服务(例如矢量搜索、查询结果、代码和机密)中的客户数据。 如果客户删除密钥或删除对密钥的访问权限,则控制平面上与该工作区相关的所有数据将不可访问。
目的 2:计算和数据平面加密
为特定服务在客户计算平面和数据平面上加密客户数据。 定义客户管理的密钥以进行存储加密,以便Azure Databricks使用它来加密连接到群集的根存储桶和存储卷。
加密模式
高度管控的环境
使用客户管理的密钥进行控制平面和计算/数据平面加密,以保持对加密密钥的完全控制并满足合规性要求。
标准企业部署
对大多数工作负荷使用Azure Databricks管理的密钥,为具有敏感数据的生产工作区保留客户管理的密钥。
多租户部署
请考虑为不同的业务部门或环境使用单独的客户管理的密钥来提供加密隔离。
设计存储网络安全
对云存储的网络访问可以限制为额外的安全层。 如果凭据泄露,则网络访问控制会阻止其使用。
网络安全模式
- 使用存储防火墙仅允许从特定虚拟网络或子网进行访问。
存储网络安全的最佳做法
- 限制对特定虚拟网络或子网的存储访问。
- 使用专用终结点进行专用连接。
- 启用存储服务日志记录以审核访问尝试。
- 在授予广泛的存储权限之前配置网络规则。
中心辐条型存储设计
中心辐射型存储设计模式是企业 Unity Catalog 部署中的常见架构。 此模式将共享数据资产集中在枢纽存储中,同时允许在分支存储中存放特定领域的数据。
中心辐射型存储特性
- 中心存储:包含组织范围的共享数据资产(例如客户主数据、引用数据、集中策展数据集)。
- 分支存储:包含业务部门拥有和管理的特定领域的数据(例如销售分析、市场营销活动)。
- 存储分离:中心和域目录使用专用的存储,并且为每个存储配备独立的存储凭据。
- 托管表首选项:在 Lakehouse 中处理结构化数据时,建议使用托管表。
- 原始数据的卷:使用卷访问入湖、原始或非结构化数据(这些数据可以位于 Lakehouse 外部,因为第三方通常需要直接访问这些存储位置)。
- 用于共享的外部表:使用外部表在湖仓之外共享数据(用于无法使用 Delta Sharing 或需要直接访问存储位置的其他系统)。
中心辐射型存储设计的最佳做法
- 在全组织范围内的共享数据中使用枢纽存储,以供多个域使用。
- 对业务部门拥有的域特定数据使用钟形存储。
- 为枢纽和每个分支单独存储凭证和外部位置。
- 使用Azure Databricks托管的Delta Sharing将数据从枢纽共享到辐射节点。
- 记录中心辐射存储的数据所有权和沿袭。
- 注意:元存储存储现在是可选的,不建议使用。
存储体系结构建议
推荐
- 使用 Unity 目录托管表,不提供对存储桶的存储级访问。
- 在目录或架构级别显式定义存储位置,而不是依赖于元存储级别的默认值。
- 使用不同的存储容器按环境(例如开发、暂存、生产)分隔存储。
- 使用存储卷来存储由 Unity Catalog 保护的可移植操作系统接口(POSIX)样式的文件路径。
- 尽可能避免旧数据访问模式,例如装载云存储和实例配置文件。
- 评估是否需要客户管理的加密密钥(针对托管服务和存储),以提高对静态数据的控制。
- 使用由Azure Databricks管理的Delta共享功能在不同云和区域间共享表。
避免
- 不要使用根存储桶(DBFS)存储客户数据。
- 不要在 DBFS(Databricks 文件系统)上存储生产数据。
- 不要跨区域(元存储)注册外部表。
- 不要直接向用户提供存储级访问权限(例如 S3 存储桶访问、ADLS 容器访问)。
- 不要依赖生产数据的默认元存储级别存储位置。
阶段 5 结果
完成阶段 5 后,应具备:
- 专为工作区设计的存储体系结构(客户管理的与Azure Databricks托管的)。
- Unity 目录存储体系结构设计(托管对象与外部对象与外来对象)。
- 定义的存储隔离策略(按环境、业务部门或数据域)。
- 设计的身份验证策略(例如 IAM 角色、访问连接器或服务帐户)。
- 选择了加密策略(Azure Databricks托管密钥与客户管理的密钥)。
- 存储网络安全模式(例如,存储桶策略、存储防火墙、VPC 终端节点)的定义。
- 记录的多区域存储注意事项(如果适用)。
- 评估了中心辐射型存储设计(适用于企业部署)。
- 计划使用 DBFS 迁移策略(针对具有 DBFS 数据的现有部署)。
实施指南:有关实现存储设计的分步说明,请参阅 使用 Unity 目录连接到云对象存储。