手册

将 Cloud Storage 中的大型批处理文件（CSV、Parquet、Avro）加载到 BigQuery 中。

→使用 BigQuery 加载作业。指定通配符 URI（例如，`gs://bucket/path/*`）以在单个作业中加载多个文件。

原因: 这是批处理摄取最快、最具成本效益的方法。加载作业是免费的。它避免了流式传输的每行成本。

参考↗

摄取高吞吐量、实时数据（IoT、点击流），并可能进行转换。

→Pub/Sub -> Dataflow -> BigQuery。

原因: 规范的可扩展流式传输模式。Pub/Sub 提供持久、可扩展的缓冲区。Dataflow 支持复杂的转换、窗口化和精确一次处理。

以低延迟将操作型数据库（MySQL、PostgreSQL、Oracle）复制到 BigQuery，捕获所有更改（插入、更新、删除）。

→使用 Datastream 进行变更数据捕获 (CDC)。

原因: 专为低影响、实时 CDC 而构建。它处理初始回填并将持续更改直接流式传输到 BigQuery。

参考↗

在加载到 BigQuery 之前，执行复杂的数据验证、丰富或转换（例如，展平嵌套的 JSON/XML）。

→使用带有自定义 Apache Beam 转换（例如，ParDo）的 Dataflow 管道。

原因: Dataflow 为自定义代码（Python/Java）、复杂逻辑以及将无效记录路由到死信队列提供了最大的灵活性。

将数 TB 或数 PB 的数据从其他云（例如，S3）或本地数据中心传输到 Cloud Storage。

→对于云到云传输，使用 Storage Transfer Service。对于网络带宽有限的本地环境，使用 Transfer Appliance。

原因: STS 是一种托管的、高性能的在线传输服务。当网络成为瓶颈时，Transfer Appliance 用于离线（物理运输）传输。

直接从 BigQuery 查询驻留在 Cloud Storage 或 Amazon S3 中的数据，而无需加载。

→创建 BigQuery 外部表。为了与 Spark 进行统一治理，使用 BigLake 表。

原因: 避免 BigQuery 中的数据重复和存储成本。BigLake 为对象存储数据增加了细粒度安全（行/列级别）和治理。

参考↗

当源文件（JSON、Avro）中添加新列时，摄取管道必须自动适应。

→将 BigQuery 加载作业配置为 `schemaUpdateOptions` 设置为 `ALLOW_FIELD_ADDITION`。

原因: 自动化模式演变。BigQuery 将新列添加到表模式中，而不会导致加载作业失败。

以比传统流式 API 更低的成本，将高吞吐量数据以精确一次语义流式传输到 BigQuery。

→使用 BigQuery Storage Write API。

原因: 与旧的 `insertAll` API 相比，提供更高的吞吐量和更低的成本，并具有强大的保证，例如流内的精确一次交付。

参考↗

按计划编排包含多个依赖任务（例如，Dataflow、BigQuery、Cloud Functions）的复杂工作流。

→使用 Cloud Composer（托管式 Apache Airflow）。

原因: 复杂工作流编排的标准。提供用于定义依赖项、调度、重试、警报和丰富运算符生态系统的 DAG。

Cloud Composer DAG 需要暂停并等待特定文件出现在 Cloud Storage 存储桶中，然后才能继续。

→在 Airflow DAG 中使用 `GCSObjectExistenceSensor`。

原因: 这是用于等待外部条件的 Airflow 惯用“传感器”模式。它比 PythonOperator 中的自定义轮询循环更高效。

流式 Dataflow 管道需要按时间戳正确聚合事件，即使事件乱序或延迟到达。

→使用带有水印的事件时间窗口化并配置 `allowedLateness`。

原因: 这个核心 Dataflow/Beam 功能根据事件发生的时间（而不是处理时间）正确地对数据进行分组。`allowedLateness` 防止延迟数据被丢弃。

运行用于批处理或机器学习的大规模、非交互式 Apache Spark 作业。

→使用 Dataproc 集群。为了最大限度地节省成本，使用带有 Spot VM（以前称为抢占式 VM）的临时集群。

原因: Dataproc 是托管的 Spark/Hadoop 服务。临时集群仅在作业期间存在，Spot VM 为容错工作负载提供大幅折扣。

创建可由不同团队以不同参数（例如，输入/输出路径）执行的标准化 Dataflow 管道。

→将管道打包为 Dataflow Flex 模板。

原因: Flex Templates 是可重用 Dataflow 作业的现代标准。它们基于容器，支持自定义依赖项，并接受运行时参数。

Cloud Composer DAG 中的任务因临时外部问题（例如，API 速率限制、资源争用）而间歇性失败。

→为任务配置 `retries` 和 `retry_delay`，并设置 `retry_exponential_backoff=True`。

原因: 这通过以递增的延迟自动重试失败的任务，使管道具有弹性，通常无需手动干预即可解决瞬态问题。

Dataflow 流式管道落后，表现出高系统延迟或数据新鲜度不足。

→调查 Dataflow 监控指标。检查自动扩缩是否达到 `maxNumWorkers` 限制。增加 `maxNumWorkers` 或切换到更大的机器类型。

原因: 高系统延迟是处理能力不足的主要指标。管道需要更多或更大的工作器来跟上数据流入。

优化大型 BigQuery 表以降低查询成本和提高性能。

→按频繁过滤的时间单位列（例如，交易日期）对表进行分区。按其他高基数、频繁过滤的列（例如，`customer_id`）对表进行聚类。

原因: 通过修剪扫描的数据量，分区是降低成本和延迟最有效的方法。聚类通过在分区内对数据进行排序来进一步提高性能。

参考↗

即使是具有有效凭据的用户，也要阻止敏感 BigQuery 数据集中的数据复制到未经授权的目标（例如，公共 GCS 存储桶）。

→使用 VPC Service Controls 在包含 BigQuery 数据集的项目周围创建服务边界。

原因: VPC Service Controls 作为 GCP 服务的“虚拟防火墙”，防止数据离开边界。这是防止数据泄露的关键深度防御控制措施。

参考↗

将 BigQuery 表中敏感列（例如，PII）的访问权限限制为授权组，同时允许其他人查询剩余列。

→使用 Data Catalog 创建分类和策略标签。将策略标签应用于敏感列，并向授权组授予“细粒度读取者”角色。

原因: 这是 BigQuery 中列级别安全的原生、可扩展方法。它提供集中式治理，无需创建和管理单独的视图。

过滤表，使B用户只能看到与他们相关的行（例如，销售经理只能看到自己区域的数据）。

→在表上创建行级安全策略，根据 `SESSION_USER()` 过滤行。

原因: 在查询时提供动态的、基于谓词的过滤。这比为每个用户或角色创建授权视图更安全、更易于管理。

在指定的保留期后自动从 BigQuery 表中删除数据，以符合法规（例如，删除超过 7 年的数据）。

→对于时间序列数据，在时间分区表上设置分区到期。对于其他表，设置默认表到期。

原因: 这是一个内置的“一劳永逸”功能，无需手动清理脚本或外部编排即可确保合规性。

BigQuery 表被意外修改或删除。

→使用 BigQuery 时间旅行功能，通过 `FOR SYSTEM_TIME AS OF` 查询事件发生前的表状态。

原因: BigQuery 自动维护 7 天的表数据历史记录。这允许在时间旅行窗口内即时恢复，而无需从备份中恢复。

参考↗

发现、管理、保护和监控整个组织的数据资产（BigQuery、GCS）。

→使用 Dataplex。

原因: Dataplex 充当智能数据架构，为跨不同数据孤岛的数据治理、质量、沿袭、发现和生命周期管理提供统一的平台。

理解和可视化数据如何从源系统流经转换作业，最终到达报告表。

→使用 Dataplex 数据沿袭。

原因: 自动从 BigQuery、Data Fusion 和 Composer 日志中捕获沿袭信息，以提供交互式的、基于图表的数据依赖视图，用于影响分析和审计。

确保关键工作负载可预测的查询性能和成本，避免其他用户的“槽位争用”。

→购买 BigQuery 版本（基于容量的定价）。创建预留以将槽位池专用于特定项目或文件夹。

原因: 从共享的按需池切换到专用计算容量，为关键作业保证资源并提供可预测的计费。

扫描 BigQuery 和 Cloud Storage 中的所有数据资产，自动识别和分类 PII 及其他敏感数据。

→配置 Cloud Data Loss Prevention (DLP) 发现扫描作业。

原因: Cloud DLP 使用数百个预定义检测器来大规模查找敏感数据。它可以与 Data Catalog 集成，自动应用策略标签进行治理。

容器化应用程序（在 GKE 或 Cloud Run 上）需要安全地向 BigQuery 进行身份验证，而无需管理服务帐号密钥。

→使用 Workload Identity。

原因: 这是服务到服务身份验证的推荐最佳实践。它将 Kubernetes 服务帐号映射到 GCP IAM 服务帐号，使用短期、自动轮换的令牌。

为了合规性，生成一份报告，列出过去 90 天内查询了敏感 BigQuery 表的所有用户。

→启用并查询 BigQuery 数据访问审计日志，这些日志可以路由到 BigQuery 数据集进行分析。

原因: 数据访问日志提供谁在何时访问了哪些数据的不可变记录。它们对于安全和合规性审计至关重要，但必须明确启用。

识别哪些用户或查询导致了高昂的 BigQuery 成本。

→查询 `INFORMATION_SCHEMA.JOBS` 视图。

原因: 此元数据视图包含每次查询运行的详细信息，包括用户、计费字节和消耗的槽位，从而实现精确的成本归因和分析。

执行复杂的分析计算，例如运行总计、组内排名（例如，每个类别的前 N 名）或将一行与前一行进行比较。

→使用 BigQuery SQL 窗口函数（`SUM() OVER (...)`、`RANK() OVER (...)`、`LAG() OVER (...)`）。

原因: 这是执行跨一组与当前行相关的表行的计算的标准且最有效的 SQL 方法。

为不编写 SQL 的业务用户创建和共享基于 BigQuery 数据的交互式、自动刷新仪表板。

→使用 Looker Studio。

原因: 原生的免费 GCP 可视化工具。它直接连接到 BigQuery，并允许通过简单链接共享，将数据源凭据与用户访问权限分开管理。

参考↗

使业务分析师能够使用熟悉的电子表格工具（数据透视表、图表、公式）来分析 BigQuery 中的数 TB 数据。

→使用 Connected Sheets。

原因: 提供从 Google 表格到 BigQuery 的实时连接。所有处理和计算都在 BigQuery 中进行，绕过了传统电子表格的大小和性能限制。

查询大型复杂聚合的 Looker Studio 仪表板速度缓慢且成本高昂。

→创建 BigQuery 实体化视图以预计算聚合。将 Looker Studio 数据源指向实体化视图。

原因: 实体化视图预计算并缓存昂贵的查询结果。这显著提高了仪表板性能并降低了重复工作负载的查询成本。

使用 BigQuery 中驻留的数据，构建、训练和提供机器学习模型（例如，用于分类、回归或预测）。

→使用 BigQuery ML (BQML)。

原因: 通过允许用户使用标准 SQL `CREATE MODEL` 语法训练模型来普及机器学习。模型在 BigQuery 中存在并运行，简化了部署和预测。

参考↗

根据历史时间序列数据预测未来业务指标（例如，销售额、需求）。

→将 BigQuery ML 与 `ARIMA_PLUS` 模型类型一起使用。

原因: `ARIMA_PLUS` 是一个专门为时间序列预测而构建的 BQML 模型，可自动处理趋势、季节性、节假日和异常检测。

BigQuery 查询将非常大的事实表（数 TB）与小型维度表（<100MB）连接时速度缓慢。

→确保 BigQuery 使用广播连接。虽然通常是自动的，但如有必要，您可以检查查询计划或使用 `JOIN` 提示。

原因: 广播连接将整个小表发送到每个处理槽位，避免了大型表在网络上进行昂贵且缓慢的数据混洗。

BigQuery ML 模型需要定期（例如，每周）在新数据上重新训练，以防止模型漂移。

→使用 BigQuery 计划查询来运行 `CREATE OR REPLACE MODEL` 语句。

原因: 这是自动化 BQML 再训练最简单、最集成的方法。它不需要像 Composer 或 Cloud Functions 这样的外部服务。

构建一个协同过滤推荐系统（例如，“购买了 X 的用户也购买了 Y”）。

→将 BigQuery ML 与 `MATRIX_FACTORIZATION` 模型类型一起使用。

原因: 此模型专为基于用户-项目交互数据的推荐任务而设计。