手册

连续、高容量数据需要在到达后几分钟内进行分析。

→使用 Pub/Sub 进行摄取 -> Dataflow (流式传输) 进行转换 -> BigQuery 与流式插入或 Storage Write API 进行分析。

原因: 这是典型的无服务器、自动扩缩流处理模式。批处理（例如 Dataproc）无法满足低延迟要求。

数据管道必须在保持低延迟的同时处理不可预测的流量峰值（例如，季节性流量增长10倍）。

→使用全托管、自动扩缩服务：Pub/Sub 用于摄取，启用自动扩缩的 Dataflow，以及 BigQuery 用于存储。

原因: 托管服务会自动扩缩资源以匹配负载，避免过度配置成本，并确保在高峰流量下的性能。

将大型本地 Hadoop/Hive 数据仓库迁移到 Google Cloud。

→将数据迁移到 Cloud Storage，然后加载到 BigQuery。用 BigQuery 替换 Hive/Spark SQL 进行无服务器分析。对于不易转换为 SQL 的 Spark 作业，使用 Dataproc。

原因: BigQuery 为 Hadoop 数据仓库提供了无服务器、高性能的替代方案，减少了运营开销。

流式管道需要对每个实体（例如，每个股票代码）的消息进行一次且按顺序处理。

→使用排序键将消息发布到 Pub/Sub。使用 Dataflow 流式管道进行处理，该管道保证对给定键的按顺序处理。

原因: Pub/Sub 排序键与 Dataflow 结合，提供了托管、可扩展、有序且一次性处理的能力，无需手动状态管理。

参考↗

构建一个灵活、可扩展的数据湖，支持批处理和流式工作负载，并具备数据治理能力。

→使用 Cloud Storage 作为存储层。使用 Dataflow 进行批处理和流式处理。使用 Dataplex 与 Data Catalog 进行元数据管理、发现和治理。

原因: 此架构将存储和计算解耦，允许在具有统一治理的中央数据存储上使用多个处理引擎（Dataflow, Dataproc）。

处理敏感数据（例如 PHI, PII）的管道必须符合 HIPAA 或 GDPR 等法规。

→为所有数据访问启用 Cloud Audit Logs。实施 VPC Service Controls 以创建安全边界，防止数据外泄。

原因: 审计日志对于跟踪数据访问以符合法规至关重要。VPC Service Controls 为防止数据外泄提供了强大的防御，这是敏感数据的一个关键要求。

具有独立批处理层和速度层的 Lambda 架构需要呈现数据的统一视图。

→使用 BigQuery 作为服务层。使用 `MERGE` 语句将批处理数据更新/插入到主表中，覆盖同一时期的流式数据。公开一个视图，将历史批处理数据与当前时期的实时流式数据进行 `UNION` 联合。

原因: 这种模式既提供了低延迟的实时视图，又提供了经过批处理校正的历史准确性，而无需客户端侧的协调逻辑。

实施去中心化的数据网格架构，其中各个领域拥有自己的数据产品。

→使用 Dataplex 对领域特定的“数据湖”和“区域”进行联邦治理。每个领域使用 BigQuery 数据集。使用 Analytics Hub 在领域之间共享数据产品。

原因: Dataplex 提供了中央治理平面，同时允许领域自治，这是数据网格的核心原则。

结合数据湖和数据仓库，允许对原始数据执行 Spark 作业，并对精选数据执行快速 SQL 查询。

→在 Cloud Storage 上以开放格式（Iceberg, Delta Lake）存储数据。使用 BigLake 提供统一的治理和访问层。从 Dataproc (Spark) 和 BigQuery 查询数据。

原因: BigLake 允许在 Cloud Storage 上直接查询数据，同时提供 BigQuery 的性能和细粒度安全性，从而统一了数据湖和数据仓库。

为关键的 BigQuery 数据仓库设计一个具有低 RPO（例如 1 小时）的灾难恢复策略。

→为关键数据集配置 BigQuery 跨区域数据集复制。使用 Terraform 或 Dataform 管理 schema 和视图定义。通过 Cloud Monitoring 警报触发 Cloud Functions 来协调故障转移。

原因: 跨区域复制在灾难恢复区域提供了一个持续更新、可查询的副本，满足关键数据对低 RPO/RTO 的要求。

以低延迟将 OLTP 数据库（例如 Oracle, PostgreSQL, MySQL）中的更改连续复制到 BigQuery。

→使用 Datastream 执行变更数据捕获 (CDC)。将其配置为将更改直接流式传输到 BigQuery，BigQuery 使用其 `MERGE` 功能应用这些更改。

原因: Datastream 是一种托管的无服务器 CDC 服务，它简化了实时数据库复制，无需自定义管道或对源数据库造成显著负载。

参考↗

Dataflow 流式管道必须产生准确的事件时间窗口化结果，即使某些事件延迟数小时到达。

→配置事件时间窗口，并将 `allowedLateness` 设置为适应延迟。使用带提前触发器的触发器获取初步结果，并使用累积触发窗格以包含后期数据。

原因: Dataflow 的水印、触发器和允许延迟模型提供了一个强大的框架，用于在处理乱序数据时平衡完整性和延迟。

写入 BigQuery 的 Dataflow 管道在重启或临时故障后出现重复数据。

→使用 BigQuery Storage Write API 接收器 (`STORAGE_WRITE_API`)，并将方法设置为 `at-least-once`（默认，以前是 `STREAMING_INSERTS`）或 `exactly-once` (`COMMITTED` 模式)。

原因: `COMMITTED` 模式下的 Storage Write API 为流式传输提供了内置的一次且仅一次语义，消除了对自定义去重逻辑的需求。

使用 Dataflow 从分页、速率受限的 REST API 摄取数据。

→使用 `SplittableDoFn` 并行处理分页源。在 DoFn 中实现速率限制逻辑（例如，使用 Guava RateLimiter）和指数退避重试机制。

原因: `SplittableDoFn` 允许动态工作负载再平衡。将其与速率限制和重试逻辑结合，为处理外部 API 创建了一种弹性高效的模式。

单个数据流需要写入多个目的地（例如 BigQuery, Bigtable, Cloud Storage）。

→在单个 Dataflow 管道中，初始处理后，将多个 `PTransform` 写入器应用于相同的最终 `PCollection`。

原因: 扇出模式效率很高，因为数据只处理一次。它避免了运行多个独立管道从同一源读取数据的成本和复杂性。

高容量流必须通过与定期更新的缓慢变化维度表（例如用户配置文件）连接来丰富。

→在 Dataflow 中使用侧输入模式。将维度表加载为 `PCollectionView`。配置周期性触发器，按计划刷新侧输入，防止管道重启。

原因: 侧输入将维度数据广播到所有工作器，用于快速内存查找，避免了每个元素的 API/DB 调用。周期性刷新有效地处理更新。

Dataproc 集群工作负载变化很大，导致资源过度配置或性能不足。

→创建具有自动扩缩策略的 Dataproc 集群。定义主工作器和次工作器的最小/最大数量。策略将根据 YARN 指标扩缩集群。

原因: 自动扩缩通过将集群资源与作业需求匹配来优化成本，在重负载时扩缩，在空闲期间缩减。

Dataflow 管道需要自定义二进制文件、专有库或标准工作器镜像中没有的特定版本，并且必须在没有互联网的 VPC 中运行。

→构建一个预安装所有依赖项的自定义容器镜像。将镜像推送到 Artifact Registry。使用引用自定义容器的 Flex Template 部署管道。

原因: 带有自定义容器的 Flex Templates 提供了对运行时环境和依赖项的完全控制，这对于离线或专用环境至关重要。

执行 `GroupByKey` 的 Dataflow 或 Spark 作业很慢，因为某些键具有不成比例的许多值（“热键”）。

→实施两阶段聚合（键加盐）。首先，向键附加一个随机后缀，将热键分散到多个工作器。进行部分聚合。其次，删除后缀并聚合部分结果。

原因: 这种扇出技术手动拆分热键的工作，使其能够并行处理并克服瓶颈。

流式管道不得因格式错误记录而失败。必须隔离无效记录以进行分析，而不能停止处理。

→在 `DoFn` 中，使用 try-catch 块进行解析。使用带有 `TupleTag` 的多输出 DoFn，将有效记录路由到主输出，将无效记录（带有错误上下文）路由到单独的错误输出。将错误 PCollection 写入死信目标，例如 Pub/Sub 主题或 BigQuery 表。

原因: 此模式通过隔离不良数据、防止管道失败，并确保捕获失败记录以进行调试和重新处理来提供弹性。

BigQuery 查询速度慢且成本高，通常在日期/时间列和其他高基数列（例如 `customer_id`）上进行筛选。

→按日期/时间列（例如每日分区）对表进行分区。按最多四个频繁筛选的列（例如 `customer_id`, `product_category`）对表进行聚簇。

原因: 分区将扫描的数据修剪到只包含相关时间段。聚簇进一步对分区内的数据进行排序，最大程度地减少了对聚簇列进行筛选时扫描的数据量。这是主要的 BQ 性能调优模式。

参考↗

应用程序需要对海量数据集（数十亿行）进行低延迟（低于 10 毫秒）的读写操作，例如用于实时个性化或 IoT 功能存储。

→使用 Bigtable。设计一个支持主要访问模式的行键。对于时间序列，使用 `entity_id#reverse_timestamp`。

原因: Bigtable 是一个 NoSQL 宽列存储，针对大规模高吞吐量、低延迟工作负载进行了优化。BigQuery 用于分析，点查询延迟较高。

事务性应用程序需要全局分发、横向可扩展性以及具有 SQL 接口的强一致性。

→使用具有多区域配置的 Cloud Spanner。

原因: Spanner 是唯一提供所有这些功能的服​​务：全局分发、ACID 事务和关系型 schema。Cloud SQL 是区域性的；Bigtable 不是关系型的，并且集群之间最终一致。

BigQuery 数据仓库拥有大量不常查询但必须保留的历史数据，导致高存储成本。

→对于连续 90 天未修改的分区/表，无需采取任何操作。BigQuery 会自动应用长期存储定价，可节省约 50% 的成本。

原因: 这是一种自动的内置优化。手动将数据移动到 GCS（除非用于 Archive 层）通常是不必要的，并且增加了复杂性。

Cloud Storage 存储桶中的数据具有可预测的访问模式：频繁访问 30 天，偶尔访问 90 天，然后很少访问。

→配置存储桶生命周期策略以转换对象：Standard -> Nearline (30 天后) -> Coldline (90 天后)。

原因: 生命周期策略通过将数据移动到成本更低的存储类别来自动化成本优化，因为数据访问频率降低。

BigQuery 表必须强制执行唯一键约束。

→在加载管道中强制执行唯一性。使用 `MERGE` 语句，其逻辑仅在键不存在时插入。或者，在 Dataflow 中使用有状态的 DoFn 进行去重。

原因: BigQuery 不强制执行 `PRIMARY KEY` 或 `UNIQUE` 约束。唯一性必须由数据加载过程管理。

BigQuery 中的维度表需要维护完整的变更历史记录以进行时间点分析（SCD Type 2）。

→添加 `valid_from` 和 `valid_to` 时间戳列。当发生更改时，使用 `MERGE` 语句更新旧记录上的 `valid_to` 并插入新记录。

原因: 这是在数据仓库中实现 SCD Type 2 的标准模式。`MERGE` 提供了一种高效、原子化的方式来执行所需的更新和插入操作。

应用程序需要一个托管的、可扩展的数据库，用于灵活 schema 的 JSON 文档，并支持事务和复杂的查询需求。

→在 Native 模式下使用 Firestore。利用集合、文档和子集合来建模数据。为复杂查询创建复合索引。

原因: Firestore 是一个无服务器的 NoSQL 文档数据库，针对具有丰富查询功能的事务性工作负载进行了优化，与 Bigtable（键值）或 BigQuery（分析型）不同。

需要通过 BigQuery 查询 Cloud Storage 中（Parquet, Avro 等）的数据，同时强制执行细粒度（行/列）安全性。

→在 Cloud Storage 数据上创建 BigLake 表。将 BigQuery 行级和列级安全策略应用于 BigLake 表。

原因: BigLake 将 BigQuery 治理扩展到 Cloud Storage 中的开放格式数据，从而实现了安全、统一的数据湖仓架构。

数据科学团队需要在大型 BigQuery 数据集上训练机器学习模型，而无需移动或导出数据。

→使用 BigQuery ML。在 SQL 中编写 `CREATE MODEL` 语句，直接在 BigQuery 中进行训练、评估和预测。

原因: BQML 消除了数据移动，简化了机器学习工作流，并利用了 BigQuery 的处理能力，从而加速了迭代。

参考↗

机器学习模型需要特征用于批处理训练和低延迟在线推理，并且两者之间保持一致以避免偏差。

→使用 Vertex AI Feature Store。通过批处理或流式传输摄取特征。它提供了一个离线存储（BigQuery）用于训练，以及一个在线存储（Bigtable）用于低延迟服务。

原因: 这是一种专门构建的托管服务，解决了特征一致性、时间点正确性和双重服务需求的复杂问题。

业务用户需要自助式 BI，但在直接查询数据仓库时会创建不一致的指标和报告。

→使用 LookML 实施 Looker 语义层。一次性定义维度、度量和连接。用户探索受治理的模型而不是原始表。

原因: LookML 为业务逻辑提供了“单一事实来源”，确保了报告的一致性和准确性，同时仍然允许自助式探索。

需要对 BigQuery 和 Cloud Storage 中的数据实施自动化数据质量检查（空值、唯一性、值范围）和监控。

→使用 Dataplex Data Quality。在 YAML 中定义规则，或使用剖析自动生成的规则。安排扫描以随时间监控质量。

原因: Dataplex 提供了一种托管的、集成的DQ解决方案，比自定义 SQL 检查或脚本更具可扩展性和可维护性。

在没有预定义标签的情况下，发现客户数据集中的自然分组或细分。

→使用 BigQuery ML 直接在客户数据上训练 `KMEANS` 聚类模型。

原因: K-means 是一种无监督学习算法，非常适合细分。BQML 使其可以通过 SQL 访问，无需数据导出。

对存储在 BigQuery 中的文本数据启用语义搜索（基于含义而非关键词）。

→使用 `ML.GENERATE_EMBEDDING` 函数与 Vertex AI 基础模型创建向量嵌入。存储它们并使用 `VECTOR_SEARCH` 函数进行相似性搜索。

原因: 此模式将强大的语义搜索功能直接引入 BigQuery，避免了对 Elasticsearch 等外部搜索索引的需求。

将大型语言模型 (LLM) 功能（如文本摘要或分类）直接集成到 BigQuery 分析工作流中。

→创建一个指向 Vertex AI LLM 端点的 BigQuery ML 远程模型。在 SQL 查询中使用 `ML.GENERATE_TEXT` 函数处理文本数据。

原因: 这紧密地将生成式 AI 集成到 SQL 中，允许分析师在不离开 BigQuery 环境或编写复杂应用程序代码的情况下，利用其数据上的 LLM。

多步数据管道涉及复杂依赖关系、重试以及跨不同 GCP 服务（例如 Dataflow, BigQuery, Dataproc）的任务。

→使用 Cloud Composer（托管式 Apache Airflow）。使用 Python 将工作流定义为有向无环图 (DAG)。

原因: Composer 是 GCP 专门用于复杂工作流编排的工具，提供强大的依赖管理、调度、重试逻辑和监控功能，这是 Cloud Scheduler 等简单工具所缺乏的。

调用外部 API 的 Airflow DAG 任务因临时网络问题而频繁失败。

→在 DAG 中配置任务级重试，设置 `retry_exponential_backoff=True`。这会增加重试之间的延迟，让外部系统有时间恢复。

原因: 指数退避是重试临时故障的最佳实践，因为它避免了用快速、重复的请求使下游系统不堪重负。

在 BigQuery 中管理、版本化、测试和调度一系列复杂的相互依赖的 SQL 转换。

→使用 Dataform。在 SQLX 文件中定义表和依赖项，使用 Git 进行版本控制，编写数据质量断言，并调度执行工作流。

原因: Dataform 是 Google Cloud 的原生 ELT 解决方案，为 BigQuery 转换提供依赖管理、测试和版本控制，推广 DataOps 最佳实践。

需要理解和可视化数据如何在 BigQuery 和 Dataflow 等多个服务中从源流向最终报告。

→使用 Dataplex，它在 Data Catalog UI 中自动捕获和显示来自受支持的 Google Cloud 服务的血缘关系。

原因: 自动化血缘跟踪对于影响分析、调试和治理至关重要。Dataplex 为集成服务提供了开箱即用的此功能。

正在运行的 Dataflow 流式作业需要用新逻辑进行更新，而不会丢失数据或状态。

→使用 `--update` 命令行选项并指定正在运行的管道的作业 ID 来启动新的管道版本。使用 `drain` 模式允许旧作业完成处理正在传输中的数据。

原因: Dataflow 的原地更新机制提供了一种零停机时间的方式来部署流式管道的更改，同时保留状态并保证一次且仅一次处理。

为了合规性，必须记录和审计对 BigQuery 和 Cloud Storage 中敏感数据的所有读写访问。

→为相关服务启用 Cloud Audit Logs，特别是数据访问日志。创建一个日志接收器，将这些日志导出到 BigQuery 以进行长期保留和分析。

原因: Cloud Audit Logs 提供了防篡改、全面的数据访问记录。将日志写入 BigQuery 允许进行强大的基于 SQL 的审计和报告。

BigQuery 数据集、表和访问控制需要作为代码进行管理，以实现可重复性和版本控制（基础设施即代码）。

→在 Terraform 配置文件（`.tf`）中定义所有 BigQuery 资源（数据集、表、IAM 策略）。通过 CI/CD 管道管理部署。

原因: Terraform 是 GCP 上 IaC 的标准，实现了对数据基础设施的审计、版本控制和一致管理，防止了手动配置漂移。

生产环境中的机器学习模型性能随时间推移而下降。

→实施 Vertex AI 模型监控。配置一个监控作业，通过将生产流量与基线进行比较来检测训练-服务偏差和预测漂移。设置警报以触发调查或自动化重新训练。

原因: 模型性能因数据漂移而下降。主动监控对于检测此问题并保持模型准确性至关重要，从而为重新训练提供了依据。