S'S ALGORITHM

Google Cloud Consultant 面试经验：技术与架构讨论

这篇记录我准备 Google Cloud Consultant / Data Analytics 技术面试时的思路。它更偏复盘，不是题库。实际面试中，技术问题并不只是考服务名，而是看你能不能基于业务需求、数据特性和运用约束做判断。

技术面试的重点

我准备时把技术面试分成三类：

  1. Cloud data architecture
  2. Code / SQL review
  3. General web, database, system design fundamentals

其中最重要的是第一类和第二类。因为 Cloud Consultant 面试通常不只是问“BigQuery 是什么”，而是问：

我使用的六个 review 维度

不管是架构题还是 code review，我都用同一套框架：

Data Quality
Security
Scalability
Reliability
Maintainability
Cost

这个框架很实用。因为面试里不可能提前准备到所有问题，但可以用它快速组织回答。

Data Quality

关注数据是否正确、完整、一致。

常见点：

数据平台里很多问题表面是 SQL 或 pipeline bug，本质上是数据定义、上游变更、join key、粒度或业务规则没有对齐。

Security

关注谁能访问什么数据，以及敏感数据如何处理。

常见点：

如果是 customer-facing role，security 不能只说“加权限”。要能说明数据使用范围、角色边界和运用流程。

Scalability

关注数据量、并发、延迟要求变化后还能不能处理。

常见点：

我会把 performance 也放在 Scalability 下面考虑。

Reliability

关注失败时系统能不能恢复。

常见点：

数据 pipeline 很少永远不失败，所以面试中能讲清楚恢复方式很重要。

Maintainability

关注团队以后能不能继续维护。

常见点：

很多架构不是因为技术不先进而失败，而是因为团队维护不了。

Cost

关注方案是否过度设计，资源是否浪费。

常见点：

不要默认所有东西都实时化。很多分析场景 daily batch 已经足够。

Batch、Streaming 和 Event-driven 的区别

这是我重点准备的一个话题。

Batch

适合：

常见工具：

Streaming

适合：

常见工具：

Event-driven

适合：

常见工具：

我准备时特别注意一个点：Pub/Sub 传的是 message / event，不是大型文件本体。如果是 GCS 文件，一般是 GCS event 通知下游，让 Cloud Run、Composer、Dataflow 或 BigQuery load job 去处理文件。

BigQuery 相关重点

我重点复习了这些：

一个容易混淆的点：

Partitioning is not vertical partitioning.

BigQuery partitioning 更接近 horizontal partitioning。Vertical partitioning 是按列拆宽表，通常是为了安全、访问模式或管理原因。

Code / SQL review 的回答方式

我准备 code review 时不急着指出 bug，而是按这个顺序：

  1. 先说明代码在做什么：read -> transform -> write
  2. 再从六个维度看风险
  3. 最后提出具体改善建议

例如 Python ETL 可以看：

SQL review 可以看：

这个方式比直接说“这里错了”更像真实 code review，也更适合 consultant 面试。

架构题的回答方式

如果被要求设计一个数据平台，我会先问或先声明需求：

然后再选择服务。不要一开始就说“用 BigQuery + Dataflow + Looker”。服务选择应该从需求推出来。

最重要的心得

技术面试里，知道服务名只是基础。更重要的是能解释：

如果准备时间有限，我会优先练架构解释和 code review，而不是继续背更多零散知识点。