BigQuery 发布核对清单

简介

此“BigQuery 发布核对清单”列举了建议您在发布使用 BigQuery 的商业应用时完成的活动。此核对清单重点针对特定于 BigQuery 的活动。同时,您还应该使用常规核对清单 Google Cloud Platform 发布核对清单,了解应该完成的适用于所有服务的活动。

此“BigQuery 发布核对清单”专门针对熟悉 BigQuery 的开发者。如果您刚开始使用 BigQuery,这些说明不会教您如何使用 BigQuery。

此核对清单分为以下部分:

  • 架构设计和开发
  • 小范围发布
  • 最终发布

这三个部分的呈现顺序也是我们建议您在准备发布应用时遵循的顺序。例如,您应该从“架构设计和开发核对清单”开始;其包含我们建议您在应用开发生命周期的早期阶段进行的活动。同样,“小范围发布核对清单”包含我们建议您在即将发布应用时进行的活动。但是,核对清单活动的确切时间轴以及这些活动所需的时间取决于您的应用开发期限。

架构设计和开发核对清单

我们建议您在应用开发的早期阶段使用此核对清单。您可以同时进行这些活动组中的核对清单活动;但是,我们建议您尽早开始与软件架构相关的活动,因为它们需要更多时间才能完成。

活动
社区/网上论坛/论坛
❑  
参阅 Stack Overflow 上的 Google BigQuery 社区支持。您可以从中获得大量信息和实用建议。
❑  
订阅 Google BigQuery - 通告网上论坛。
架构设计
❑  
根据查询需求设计架构。BigQuery 支持嵌套和重复 (type:RECORD) 字段,允许反规范化表中含有一对多的逻辑关系。在适当的情况下利用这些字段,同时保持访问这些字段的策略。考虑为重复字段的常见解除嵌套创建逻辑视图。估算查询费用。
❑  
查询第一级或第二级嵌套之外的重复字段可能比较困难,因此请考虑适合您使用的嵌套深度。
❑  
尽管 BigQuery 上可使用联接,但反规范化可以改善某些查询的性能。考虑在数据模型中,可联接性在哪些地方很重要。
❑  
BigQuery 允许通过 DML 追加或更新表。DML 旨在用于批量更新、删除和插入,而不是单行修改。确保更新模式与 OLAP 系统一致。
❑  
与传统的 RDBMS 不同,不存在主要/次要或行 ID 键的概念。如果需要,则可为此在表架构中标识某个列。
估算数据量
❑  
计算初始上传中要上传多少数据才能达到某个基本级别。
❑  
计算按递增方式上传的数据量以及上传速度(每小时一次/每日一次/每周一次)。
❑  
计算到期的数据量(如果有)以及到期频率。
估计查询处理
❑  
确定每天将对 BigQuery 数据集执行的查询类型。Stackdriver Monitoring 可提供有关资源利用率、并发查询和数据集大小的有用诊断信息。
❑  
决定表分区/分片策略。例如,如果某天发出的查询与当天收集的数据相关,则每天创建一个表。要汇总多日的数据,请使用表通配符或 \_PARTITIONTIME 伪列运行查询。
❑  
计算 BigQuery 每天将处理的数据量(查询数量 x 每个查询处理的数据)。请注意,BigQuery 会对处理个别列(非整行)收取费用,因此请在计算中进行说明。另请注意,查询中引用的列会调用完整的列扫描。
配额管理
❑  
了解 BigQuery 的默认配额
❑  
在合适的情况下,完成以下方面的配额分析:
  • 将数据加载到 BigQuery 时每天所需的加载作业数量。
  • 每个表每天加载到 BigQuery 的加载作业数量。
  • 流式插入数量、插入的行大小、每秒最大行数、每个请求的最大行数以及其他特定于流处理 API 的参数(如果使用的是流处理 API)。
  • 您的应用向 BigQuery 发出的查询数量。
  • 用于同时执行查询的并发会话数量。
  • 为从 BigQuery 中提取数据而每天执行的导出作业数量。
  • 甚至用于调用 BigQuery 操作的 API 也设有速率限制和每日限制。如需了解详情,请参阅 API 速率限制
❑  
如果配额不足,请通过 GWSC 提出配额调整申请。
费用分析
❑  
根据估算的数据量和查询处理,使用 BigQuery 价格和/或价格计算器计算 BigQuery 存储和处理的费用。
❑  
请参考以下有关实现费用优化的建议:
  • 只选择查询中的相关列。请注意,无论 where 子句中的过滤条件如何,BigQuery 都会对所选列执行完整的列扫描(并对此收费)。
  • 将表分区/分片为较小的单元以优化处理费用。费用优化和性能之间通常需要进行权衡取舍。如果小表过多,则在加载查询中引用的每个表时会产生固定开销,这可能会影响性能。
  • 对表的小分区而不是单个大表测试查询。
  • 如果使用 API,请使用 dryRun 标志验证查询语法,并获取数据处理统计信息。
  • 删除不再需要查询的旧表,或对表使用 expirationTime。
安全
❑  
仔细查看 BigQuery 的 IAM 政策,确保数据集访问权限和作业运行权限正确无误。注意事项:
  • 审核项目成员的 BigQuery 权限,确保遵循安全政策。bigquery.User 角色让用户可在项目中运行作业,而 dataset.Viewer 角色可控制读取给定数据集中的所有表的能力。只有在用户需要分别修改表或数据集时,才应授予 dataset.Editordataset.Owner 角色。
  • 如果需要与团队成员共享特定数据集,请改用共享数据集或显式 IAM 角色。
  • 如果需要更精细的安全措施,请考虑使用已获授权的视图控制访问权限。
在 BigQuery 之前预处理数据
❑  
请考虑在将数据加载到 BigQuery 之前预处理数据,以节省费用和改善性能。例如,您可以执行以下操作:
  • 预处理不必要的类型转换和计算。
  • 预联接常见联接项。
  • 预先汇总指标和经常运行的分析。
❑  
使用 BigQuery 本身、Cloud DataflowCloud Dataproc 或 ETL 工具预处理(转换、反规范化等)数据。
❑  
考虑针对不同类型的查询,将同一数据集的多种版本进行不同的结构化处理。
❑  
由于每个表的 DML 语句都有每日限制,因此请计划通过分段的修改批次来更新/删除表。
查询调整与测试
❑  
根据以下原则,针对预期的数据量测试查询并对其进行调整:
  • 从 select 子句中省略不必要的列以降低费用并改善性能。
  • 在嵌套查询的上下文中,有效使用 where 子句来过滤掉最内层查询中的数据,以减少外部查询处理的数据。
  • 尽可能向内扁平化,如果可能,请搭配使用 WHERE 子句。
  • 将重量级过滤器(例如正则表达式)移动到最后。
  • 当原始等效数据可用时,避免对字符串进行分组:使用时间戳与字符串。
  • 尝试在最外层的查询中使用 ORDER BYLIMIT。尽可能避免在内部查询中使用 ORDER BY
  • 请注意,在处理偏斜(大型)组时,使用 GROUP BY 可能会增加尾延时。请将其过滤掉以改善查询性能。
  • 考虑使用 IF/CASE 或分析 SQL 函数,而不是自联接,因为它们的处理开销低于自联接。
直观呈现数据
❑  
BigQuery 是用于在大型数据集中查询数据的工具。为了直观呈现数据,它与以下第三方工具之间具有良好的连接性:
  • Google Data Studio
  • 高效办公工具,例如 Google 表格和 Microsoft Excel。
  • 商业工具,例如 Tableau、BIME、Informatica。
  • 开源备选项,例如 redash

小范围发布核对清单

在应用的商业发布之前,我们建议使用“小范围发布核对清单”活动来测试您的发布准备情况。

活动
❑  
如果使用流处理 API 加载数据,请模拟负载测试,确保加载数据时不会出现任何配额违规。
❑  
如果使用批量作业加载数据,请模拟负载测试,确保在合理的时间内将数据加载到 BigQuery 且不会出现配额违规。
❑  
参照实际费用审核费用模型。确保运营费用在预算范围内。修改费用模型。虽然 Google Cloud Platform 价格计算器能够进行比较精确的估算,但须等到负载测试后,才能清楚了解一天中处理的确切数据量。

最终发布核对清单

在即将发布之时和发布期间,请使用最终发布核对清单

活动
❑  
如果到目前为止都已遵照了此清单,则您的应用已准备就绪,可在 Google BigQuery 上成功发布。恭喜!同时我们建议您也查看 Google Cloud Platform 发布核对清单中的“最终发布核对清单”。
此页内容是否有用?请给出您的反馈和评价:

发送以下问题的反馈:

此网页
需要帮助?请访问我们的支持页面