BigQuery 上多租户工作负载的最佳做法
本文档提供了用于多租户数据平台和企业数据集市的常见模式的技术和最佳做法。
商业企业、软件即服务 (SaaS) 供应商和政府组织必须经常安全地托管跨地理和管理边界的内部和第三方数据。BigQuery 是一款功能强大的工具，可以始终如一地满足跨不同业务部门的 EB 级数据和数十万数据消费者的多租户平台要求。本文档适用于在 BigQuery 上部署多租户平台并且希望了解可用的访问权限控制措施和性能管理功能的组织。
多租户平台构建者通常需要平衡以下方面的注意事项：
- 数据隔离：实施强有力的控制措施，以防止跨租户的数据泄露。
- 一致的性能：配置和分配 BigQuery 预留，以在各个租户之间保持一致的性能。
- 资源管理：计划配额和限制的影响。
- 地理位置分布：查找指定和必需的地理位置中的数据。如需了解合规性相关问题，请参阅 Google Cloud 的合规性服务。
- 审核和安全：保护租户数据免遭不当访问和渗漏。
- 费用管理：确保托管每个租户的 BigQuery 费用保持一致。
- 运维复杂度：尽可能减少托管新租户所需的系统差异。
具有共享租户基础架构的 SaaS 供应商
托管第三方数据的 SaaS 供应商需要确保整个客户群的可靠性和隔离性。这些客户可能有数以万计，并且可以通过共享服务基础架构来访问客户数据。一些 SaaS 供应商还维护一个经过清理的中央数据存储区，以对整个租户群进行分析。
每个租户的数据集设计有助于减轻组织扩容到成千上万的租户时遇到的以下问题：
- 管理复杂度：基于每个客户的新项目和云资源的总数
- 端到端延迟时间：数据存储区在租户和跨客户分析解决方案方面的最新表现
- 效果预期：确保租户效果保持在可接受的限制范围内
为每个租户配置数据集
在专用于存储客户数据的项目中，每位客户的数据都由 BigQuery 数据集分隔。在宿主项目中，您使用第二个项目来根据组合的客户数据部署分析和机器学习。然后，您可以配置数据处理引擎 Dataflow，将传入数据双重写入内部表和租户专属表。Dataflow 配置使用完全写入的表，而不是已获授权的视图。使用完全编写的表可以统一处理地理分布，且有助于避免在租户数量发生变化时达到已获授权的视图限制。
与基于集群的仓库相比，BigQuery 的存储和计算分离使您可以配置更少的项目，以处理诸如服务层和数据隔离之类的问题。当您不需要为租户配置其他专用云资源时，建议您考虑为每个租户配置专用数据集的默认配置。下图显示了基于此推荐设计的示例项目配置：
图 1.随着租户数量的增长，恒定数量的项目可以处理数据和处理需求。
图 1 中的项目配置包含以下项目：
- 数据流水线项目：接收、处理和分发租户数据的核心基础架构组件均打包到单个项目中。
- 合并的租户数据项目：每个客户维护数据集的核心数据项目。租户数据应通过计算层级项目访问。
- 内部开发项目：代表自我管理资源的项目，分析团队使用这些项目来评估租户数据并构建新功能。
- 最终用户应用项目：包含旨在与最终用户互动资源的项目。我们建议您使用租户级服务账号访问租户数据集，并使用强大且安全的构建流水线部署应用。
- 预留计算层级项目：将租户查询活动映射到 BigQuery 预留的项目。
分享预留信息
此方法中的预留依赖于 BigQuery 预留中内置的公平调度算法。每个计算层级预留都会分配给一个项目。租户查询使用分配给每个计算层级项目的公平调度槽，而任何层级中未使用的槽会自动在其他层级中重复使用。如果租户有特定的时间要求，您可以使用专门用于提供确切数量的槽的项目对。
配置 VPC Service Controls 边界
在此配置中，我们建议您使用 VPC Service Controls 边界，以防止 Google Cloud 组织外部的租户数据集出现意外泄露，并防止未经授权的数据加入组织内。
边界
在此配置中，我们建议您创建以下服务边界：
- 数据流水线：数据流水线项目周围的边界应强制执行所有无需接收租户数据的服务。
- 租户数据：租户数据集项目与租户 BigQuery 计算项目周围的边界。实施所有服务以阻止从组织外部访问。
- 内部应用：强制执行所有服务并使用访问权限级别向部门团队授予资源访问权限。
- 外部应用：SaaS 应用的边界。强制执行应用正常运行所必需的所有服务。
边界网桥
在此配置中，我们建议您创建以下边界网桥：
- 数据流水线和租户数据：允许流水线将数据写入租户数据集。
- 数据流水线和内部应用：允许流水线将数据写入跨客户数据集。
- 外部应用和租户数据：允许面向外部的应用查询租户数据。
- 外部应用和内部应用：面向外部的应用将使用内部应用开发和部署的模型来处理数据。
具有专用租户基础架构的 SaaS 供应商
在更复杂的场景中，SaaS 供应商可以为每个租户部署专用的计算基础架构。在此场景中，专用基础架构负责在 BigQuery 内处理租户数据请求。
在部署每个租户以及 BigQuery 时，专用租户基础架构设计可以解决以下常见问题：
- 结算账号责任：跟踪与每个初始租户关联的基础架构费用。
- 端到端延迟时间：数据存储区在租户和跨客户分析解决方案方面的最新表现。
- 效果预期：确保租户效果保持在可接受的限制范围内。
共置数据集与专用资源
部署专用租户基础架构时，我们建议您为特定于租户的项目创建一个父文件夹。然后，将租户的 BigQuery 数据集与项目中代表资源的专用资源共置。为了最大限度降低租户数据的端到端延迟时间，Dataflow 流水线会直接将数据插入租户数据集。
这种设计可处理上游数据处理和分发，类似于之前的共享基础架构设计。但是，访问租户数据的租户数据和应用是特定于租户的项目（可以选择性地整理到特定于租户的文件夹）下，可以简化结算和资源管理。下图显示了基于此推荐设计的示例项目配置：
图 2：数据流水线项目从多个其他项目处理单个租户的数据。
图 2 中的项目配置包含以下项目：
- 数据流水线项目：接收、处理和分发租户数据的核心基础架构组件均打包到单个项目中。
- 专用租户项目：此类项目包含特定于单个租户的所有云资源，包括 BigQuery 数据集。我们建议您使用 Identity and Access Management (IAM) 大幅限制哪些服务账号和服务账号可以访问客户数据集。
- 内部分析项目：代表自我管理资源的项目，分析团队使用这些项目来评估租户数据并构建新功能。
- 外部网络项目：处理租户请求并将其路由到其专用后端的项目。
分享预留信息
此方法中的预留依赖于 BigQuery 预留中内置的公平调度算法。在此配置中，计算层级预留会分配给使用该层级的每个租户项目。如果租户有特定的时间要求，您可以创建专用预留来为租户项目提供精确数量的槽。
使用 IAM 控制措施并停用密钥创建功能
VPC Service Controls 边界可能不适用于此场景。与项目相关的限制可防止组织在与租户项目交互的项目上使用界限边界。相反，我们建议您使用严格的 IAM 控制，并停用密钥创建功能，以防止不需要的外部访问。
具有中央授权方的数据集市
数据集市是一种常见的设计主题，其中核心分析数据会存储在中央代码库中，并且部分业务线会共享。数据集市通常有数十个或数百个租户，视为业务线。
BigQuery 中的数据集市设计可满足以下需求：
- 保护数据协作：利用技术控制措施共享数据，以最大限度地减少各团队的不当访问。
- 集中数据治理：确保关键业务报告使用的核心数据资源经过标准化和验证。
- 业务部门费用归因：按业务部门跟踪和调整计算使用量。
使用集中管理的代码库
在此设计中，核心数据会捕获到集中管理的代码库中。授权视图、授权的用户定义函数 (UDF) 和列政策会经常用于与业务线共享数据，同时防止意外分发敏感数据。
租户项目中的团队可根据其账号权限访问集中受监管的数据集。团队使用分配给自己项目的槽来构建报告和派生数据集。核心数据团队使用授权视图来保持对数据集市资产的访问权限控制的所有权。在此配置中，我们建议您避免在核心数据项目呈现的对象上构建多层视图。下图显示了基于此推荐设计的示例项目配置：
图 3.核心数据项目维护着一个可从整个组织访问的集中式数据集市。
图 3 中的项目配置包含以下项目：
- 核心数据项目：用于管理核心数据和数据集市视图的治理边界。您可以在此项目内的数据集中维护授权视图，并根据组成员身份将授权视图授予分析团队。
- 提取、转换、加载 (ETL) 基础架构：用于将上游数据源处理到核心数据的基础架构。根据管理分离需求，您可以选择将 ETL 基础架构部署为自己的项目或作为核心数据项目的一部分。
- 分析团队项目：数据集市的使用者使用这些项目，并使用其自己的预配基础架构访问权限来处理数据集市内的数据。分析团队项目应该能够构建派生数据集以供本地使用。
使用双层预留设计
使用数据集市时，建议您使用两层设计。在双层设计中，您可为包含槽的预留分配包含少量槽的预留，以满足一般使用需求。如果团队的需求更高，请在项目级层或文件夹级层分配预留。
配置 VPC Service Controls 边界
在此配置中，我们建议您使用 VPC Service Controls 边界，以防止在 Google Cloud 组织外部公开 BigQuery 数据集。
边界
在此配置中，我们建议您创建以下服务边界：
- 核心数据：保护数据仓库和数据集市的边界。
- 数据流水线：ETL 基础架构项目的边界。如果数据流水线需要在 Google Cloud 组织外部发出请求，我们建议您将此边界与核心数据边界分隔开。
- 分析：用于构建和部署组织内部的分析资源的边界。预计此边界比与其桥接的核心数据边界具有更宽松的访问政策。
边界网桥
在此配置中，我们建议您创建以下边界网桥：
- 数据流水线和核心数据：允许数据流水线写入核心数据项目。
- 核心数据和分析：允许分析项目中的用户查询授权视图。
复制多区域配置的数据集
由于 BigQuery 不允许跨区域查询，因此如果数据集必须存在于多个区域，则无法使用细分包含授权视图的数据的策略。您可以改为使用 BigQuery Data Transfer Service 将相关数据集复制到另一个区域。在这种情况下，您需要在数据目录中为数据所在的每个额外区域创建列政策。下图展示了多区域配置：
图 4.多区域配置使用 BigQuery Data Transfer Service 跨区域复制数据集。
图 4 中的项目配置包含以下项目。
- 核心数据项目：用于管理核心数据和数据集市视图的治理边界。数据被复制并保存到可在全球范围内为团队提供服务的区域数据集中。
- ETL 基础架构：用于将上游数据源处理为核心数据的基础架构。根据管理分离需求，您可以选择将 ETL 基础架构部署为自己的项目或作为核心数据项目的一部分。
- 分析团队项目：数据集市的消费者使用这些项目，并使用他们自己的预配基础架构来处理数据集市的区域数据集中的数据。分析团队项目应该能够构建派生数据集以供本地使用。
BigQuery Data Transfer Service 是一个附加的计划组件，但有一些限制。内置服务调度器的最小间隔时间为 15 分钟，并且它必须从源数据集中复制所有表。无法将其他脚本嵌入到 BigQuery Data Transfer Service 调度器中，以创建特定于区域的数据子集。
如果您的组织需要更强的灵活性，则可以使用以下选项：
- Cloud Composer 作业：您可以安排 Cloud Composer 作业发出 ETL 作业，以创建区域子集，然后再通过其客户端 API 触发 BigQuery Data Transfer Service。如果您的组织可以支持额外延迟，则建议使用此选项。
- ETL 基础架构：ETL 基础架构（例如 Dataflow）可以将区域子集双重写入目标区域。如果您的组织要求区域之间的数据延迟最小，则建议使用此选项。
使用分散的机构处理数据集市
如果需要由系统所有者、业务线或地理位置问题分离管理，请使用分散式授权。
与标准数据集市相比，分散式数据集市存在以下不同的问题：
- 保护数据协作：利用技术控制措施共享数据，以最大限度地减少各团队的不当访问。
- 数据可检测性：团队需要能够发现和请求访问数据集。
- 数据来源：在没有中央策展人团队的情况下，团队需要能够信任进入其分析产品的数据的来源。
委派核心数据管理
这种设计与传统数据集市方法不同，因为分散式授权将核心数据管理决策委托给组织的组件子组。使用分散式授权时，您可以使用 Cloud Key Management Service (Cloud KMS)、列政策、VPC Service Controls 和预留。因此，您可以避免自行管理的仓库常见的数据扩张。下图展示了使用分散式授权的架构：
图 5.核心治理项目有助于确保一致的安全性，而各个团队可以维护其数据运营。
图 5 中的项目配置包含以下项目：
- 核心治理项目：负责跨组织管理问题的项目。在此项目中，您需要创建 Cloud KMS 密钥环和数据目录列政策等安全资源。此项目充当 BigQuery 预留管理项目，在组织范围内共享槽。
- 组织单元数据项目：范围更广的组织中自我管理的数据集市的所有者。核心管控项目管理组织部门数据项目的受限范围。
- 分析团队项目：数据集市的消费者使用的项目。这些项目使用它们自己预配的基础架构和插槽来访问和处理数据集市中的数据。
使用双层预留设计
我们建议您对数据集市进行分散化，使用与标准数据集市相同的双层设计。在此配置中，您向组织资源分配了包含少量槽的预留，以支付常规用量。如果团队的需求更高，请在项目级层或文件夹级层分配预留。
使用数据目录
数据目录提供组织范围的发现、元数据标记和列政策配置。Dataplex 的发现功能会自动为组织中的所有新 BigQuery 表创建元数据条目。Dataplex 的功能还有助于数据治理管理员快速识别新的数据资源并应用适当的控制措施。
配置 VPC Service Controls 边界
在此配置中，我们建议您使用 VPC Service Controls 边界，以防止在 Google Cloud 组织外部公开 BigQuery 数据集。
边界
在此配置中，我们建议您创建以下服务边界：
- 核心数据：保护数据仓库和数据集市的边界。此边界应包含所有组织部门项目和数据治理项目。
- 分析：用于构建和部署组织内部的分析资源的边界。预计此边界比与其桥接的核心数据边界具有更宽松的访问政策。
边界网桥
在此配置中，我们建议您创建以下边界网桥：
- 核心数据和分析：允许分析项目中的用户查询授权视图。
多组织数据共享
多组织共享是一种针对数据集市设计的特殊设计注意事项。此数据共享设计适用于希望与具有自己的 Google 组织的另一个实体安全地共享其数据集的组织。
多组织数据共享可以解决数据共享者的以下问题：
- 共享机密性：只有目标方可以访问共享数据。
- 防止不恰当的访问权限：仅可从外部访问要访问的资源。
- 计算分离：外部方针对其发起的查询付费。
保护内部项目免受共享数据项目的影响
多组织数据共享设计的重点是保护组织的内部项目免受共享数据项目中活动的影响。共享数据集项目充当缓冲区，以禁止访问敏感的内部数据处理，同时提供了在外部共享数据的功能。
从外部项目启动的查询会使用调用项目的计算资源。如果所有查询的数据集共享相同的 Google Cloud 区域，则这些查询可以跨组织联接数据。下图显示了如何在多组织项目配置中共享数据集：
图 6. 外部组织从共享项目的多个数据集中查询数据。
图 6 中的项目配置包含以下项目：
- 组织内部项目：包含敏感内部数据的项目。内部项目可以通过将已清理的数据复制到共享数据项目的数据集中来与外部共享数据。内部项目应拥有负责更新共享数据的服务账号。
- 共享数据项目：包含从内部项目复制的已清理信息的项目。使用外部用户群组管理外部各方的访问权限。在这种情况下，您将群组成员资格作为管理功能进行管理，并为外部账号授予查看者权限，以便他们通过这些群组访问数据集。
配置 VPC Service Controls 边界
在此配置中，我们建议 VPC Service Controls 边界在外部共享数据，并防止在内部项目之外意外公开 BigQuery 数据集。
边界
在此配置中，我们建议您创建以下服务边界：
- 内部数据：用于保护核心数据资源的边界。VPC Service Controls 会强制访问 BigQuery。
- 外部共享数据：用于托管可与外部组织共享的数据集的边界。此边界禁止访问 BigQuery。
边界网桥
在此配置中，我们建议您创建以下边界网桥：
- 内部到外部数据：边界网桥允许受保护程度更高的内部数据项目将数据输出到外部数据共享项目中。
多租户系统中的其他注意事项
本部分更深入地介绍了特殊情况，您可以将这些特殊情况与前面的最佳做法一起考虑。
Google Cloud 资源限制和配额
- 服务账号限制为每个项目 100 个服务账号的软配额。您可以通过 Google Cloud Console 为维护租户服务账号的项目申请配额。
- BigQuery 并发在每个发布查询的项目中默认具有 100 个查询的并发（保存数据集的项目没有这样的限制）。如需增加此软配额，请与销售代表联系。
- VPC Service Controls 在组织范围内的服务边界内最多只能包含 10000 个项目。如果每个租户的项目设计均高扩容，我们建议您改用每个租户一个数据集的设计。
- VPC Service Controls 限制每个组织最多 100 个边界，包括边界。
使用授权视图或具体化子集表
如需管理对大型事实表子集的租户访问权限，您可以使用特定于租户的授权视图，或创建特定于租户的子集表。下表对这些方法进行了比较：
| 特征 | 授权视图 | 子集表 |
|---|---|---|
| 支持的租户数量 | 每个数据集有 2500 个授权资源的硬限制。 | 授权资源包括授权视图、授权数据集和授权函数。项目中的数据集或数据集中的表在数量上没有限制。 |
| 分区和聚类 |
授权视图必须共享基表的通用分区和集群架构。 为了改善租户细分的性能，我们建议您在租户 ID 中对父表进行聚簇。 |
您可以对子表划分分区，并将其按照租户的需求进行聚簇。 |
| 地区化 | 授权视图不能跨区域，并且必须位于基表的 Google Cloud 区域中。区域化会影响远程地理位置的租户。 | 子集表可以位于最适合租户的区域。您可能还需要支付其他费用。 |
| 强制执行列政策 | 应用于基表的列政策将应用于所有授权视图，无论这些视图的权限如何。 | 每个子集都必须应用列政策，才能生效。 |
| 数据访问日志记录 | 数据访问日志会反映在基表的日志中。 | 系统会单独记录对每个子集表的访问。 |
| 转型灵活性 | 通过授权视图，您可以即时重新设计租户访问的对象。 | 更改架构需要更改复杂的架构。 |
控制敏感数据
为防止未经授权的数据访问，BigQuery 除了标准 IAM 权限之外，还提供了几项其他功能。
客户端提供的加密
客户端数据加密包括托管组织代表租户存储和处理数据但阻止其访问部分数据内容的情况。例如，托管组织可能会无法访问具有敏感性的个人数据或设备数据。
我们建议数据发送者使用开源 Tink 库中的 AEAD 加密密钥来加密敏感数据。Tink 库 AEAD 加密密钥与 BigQuery AEAD 函数兼容。然后，租户可以通过访问已获授权的 UDF 中的密钥材料，或以查询参数形式传递密钥材料来解密数据。导出到 BigQuery，其中托管组织无法记录密钥。
列访问权限政策
在多租户数据集市中，列政策经常用于防止敏感内容在协作团队之间意外泄露。 在数据集市场景中，授权视图是在团队之间共享数据的首选机制。授权视图无法授予对受保护列的访问权限。
当您设置政策以强制执行访问控制时，可以阻止未授予该政策的细粒度读取者角色的用户访问。即使未实施该政策，该政策也会将所有用户访问记录在已归类的列中。
敏感数据保护
敏感数据保护提供了 API 和扫描实用程序，可帮助您识别和缓解存储在 BigQuery 或 Cloud Storage 数据集中的敏感内容。多租户场景中的组织通常使用 DLP API（敏感数据保护的一部分）在存储之前识别和标记敏感数据（可选）。
槽预留管理
多租户系统中的预留管理有助于随着租户规模扩大而控制成本，并确保为每个租户提供效果保证。
如需管理预留，建议您创建一个预留管理项目。在同一管理项目中购买的插槽承诺可在源自该管理项目的所有预留中共享。使用插槽承诺的项目一次只能分配给一项预留。源自某个项目的所有查询都基于可用资源共享插槽。
为确保满足租户服务等级目标 (SLO)，您可以通过 Cloud Logging 和 BigQuery 信息架构监视预留。那些由于分析师活动或优先工作而处于忙碌状态的组织可以使用弹性插槽分配额外的容量。
预留作为租户计算层
具有数十个至数千个租户的 SaaS 供应商通常将有限数量的 BigQuery 预留配置为共享资源。
如果您是共享租户基础架构的 SaaS 供应商，我们建议您将每个预留都专用于单个项目，并将租户分组以共享该项目以进行 BigQuery 计算。这种设计减少了具有成千上万个其他项目和预留空间的管理开销，同时允许您的组织分配必要的最小插槽容量，以满足预留的预期性能需求。
如果 ELT 数据处理的及时性是当务之急，我们建议您分配一个预留来处理该数据处理。为避免使用多余的槽可用于临时工作负载，请将预留设置为忽略空闲槽。
以下示例说明了如何将预留配置为租户计算层级：
- 数据处理：2000 个槽，忽略空闲。此预留配置为满足数据处理 SLO 要求。
- 内部项目：1000 个插槽，允许空闲插槽。此预留适用于内部分析的项目。如果从数据处理或计算层中遗留了插槽，则这些插槽将被重用。
- 低计算层级：2000 个槽，忽略空闲。如果资源不足，则预留将应用到租户。与高层级不同，此预留会忽略空闲槽。
- 高计算层级：3000 个槽，允许空闲。此预留适用于拥有较高资源的租户。为了加快查询速度，系统会自动应用其他预留中的空闲槽。
如果您的租户在专用基础架构上运行，我们建议您将指定的文件夹或项目分配给适当的共享预留。
每个团队的预留数
在数据集市环境中使用团队时，我们建议您为每个需要额外计算的团队创建一个预留。然后将该预留分配给包含团队项目的父级文件夹。该团队的所有新项目均使用同一资源分配中的公平调度槽。
以下示例说明了如何为每个团队配置预留：
- 组织级层预留：500 个插槽，允许空闲插槽。此预留将分配给顶级组织，并且会为不使用专用预留的项目的任何 BigQuery 用户提供插槽
- 数据处理：1000 个槽，忽略闲置槽。此预留已配置为满足最低数据处理 SLO 要求。
- 核心数据管理：500 个槽，允许空闲。此预留适用于内部分析的项目。如果从数据处理或计算层中遗留了插槽，则这些插槽将被重用。
- 分析处理预留：500 个槽，允许空闲。这是为分析团队分配的专属预留。
多区域托管要求
多区域托管要求通常是由于需要减少数据使用者的延迟或满足监管要求。
Google Cloud 中的项目是全球项目，可以在任何区域中预配资源。BigQuery 将数据集、列政策和槽承诺视为区域资源。槽只能访问本地区域中的数据集，并且列政策只能应用于本地数据集中的表。如需使用基于容量的价格，您必须在包含数据集的每个区域购买槽。
如需获得监管方面的指导，请咨询您的销售代表。
后续步骤
- 了解 IAM 最佳做法。