第1章 岗位能力画像与简历优化模板
本章帮助你精准匹配大厂实时数仓平台工程师的岗位要求，并掌握简历优化的核心技巧。从能力拆解到关键词植入，再到成果量化，三步完成简历升维。
一、岗位能力画像
| 能力维度 | 关键要求 | 面试常见考察点 |
|---|---|---|
| 数据建模与分层 | ODS/DWD/DWS/ADS设计，实时维表 | Lambda/Kappa架构，数据一致性 |
| 实时计算引擎 | Flink/Spark Streaming，Checkpoint，状态管理 | 水位线、背压、Exactly-Once语义 |
| 数据存储选型 | HBase、ClickHouse、Kafka、Redis | 写入吞吐、查询延迟、数据倾斜 |
| 数据治理与运维 | 监控告警、数据质量、权限控制 | 任务调优、故障恢复、SLA保障 |
| 业务理解与沟通 | 指标定义、需求转化、跨团队协作 | 案例复盘、异常归因、方案说服力 |
二、简历结构建议
- 个人信息：姓名、手机、邮箱、GitHub/博客（若有高质量输出）。
- 技术栈清单：分「精通」「熟练」「了解」三级，列出 Flink、Hadoop、Kafka、ClickHouse 等。
- 工作经历：按STAR原则写，每个项目突出规模指标（数据量、延迟、QPS）和个人角色。
- 项目亮点：列出2-3个核心项目，使用成果量化句式。
- 教育背景与证书：本科及以上，可附阿里云/腾讯云认证。
三、关键词清单
| 类别 | 关键词（建议植入简历） |
|---|---|
| 计算引擎 | Flink（DataStream/Table API）、Spark Structured Streaming、Watermark、Checkpoint |
| 数据存储 | Kafka（Topic分区/Rebalance）、HBase（Rowkey设计）、ClickHouse（MergeTree） |
| 数据治理 | 数据血缘、质量校验（Exactly-Once）、任务监控、容器化（K8s） |
| 架构模式 | Lambda、Kappa、流批一体、实时OLAP |
| 性能优化 | 并行度调优、状态后端（RocksDB）、数据倾斜解决 |
四、成果量化句式模板
| 应用场景 | 量化句式示例 |
|---|---|
| 延迟优化 | 将核心实时链路延迟从5分钟降至30秒，提升查询时效性90% |
| 吞吐提升 | 通过并行度及资源配置优化，集群吞吐量提升3倍（10万条/秒→30万条/秒） |
| 成本降低 | 引入HBase预分区+缓存机制，存储成本下降40%，查询RT<500ms |
| 故障恢复 | 设计Flink Checkpoint自动恢复方案，MTTR从15分钟降至2分钟 |
| 数据准确率 | 搭建数据质量监控体系，指标准确率从95%提升至99.9% |
五、面试问答卡片
面试问题：请阐述实时数仓与传统离线数仓的核心区别，并举例说明你在项目中如何选型。
面试官考察点：是否理解两者本质差异（时效性、计算模型、存储选型、数据一致性），能否结合真实业务场景变通。
回答框架：对比维度法——时效性（秒级 vs T+1）、计算引擎（流式 vs 批处理）、存储介质（OLAP vs Hive）、数据一致性（最终一致 vs 强一致），最后给出自己的选型决策逻辑。
示例回答：“实时数仓以秒级延迟为目标，采用Flink流计算+Kafka+ClickHouse，适用于交易监控。离线数仓基于Hive/Spark批处理，日级产出，用于经营分析。我在风控场景选择了Lambda架构，离线层做全量回溯，实时层做秒级预警。”
可能追问：Lambda架构中实时与离线数据如何合并？如何保证一致性？
面试问题：你的简历提到“优化了实时任务延迟”，能否具体说明优化前和优化后的指标，以及改进措施？
面试官考察点：成果量化能力、技术深度、问题定位与解决思路的真实性。
回答框架：STAR法则（Situation：某业务分钟级数据需求；Task：降低延迟至秒级；Action：调整Flink并行度、改用RocksDB状态后端、优化KeyBy分区；Result：延迟从5分钟降至30秒，资源消耗降低20%）。
示例回答：“某实时大屏原延迟5分钟。我通过分析背压定位到状态后端瓶颈，将FsState改为RocksDB，并将并行度从16增至32，同时优化上游Kafka消费组。最终延迟降至30秒，CPU使用率稳定在70%。”
可能追问：为什么选择RocksDB而不是HashMapStateBackend？具体参数如何配置？
面试问题：在实时数仓中，你是如何进行数据分层设计的？各层通常使用什么存储引擎？
面试官考察点：对实时分层体系的理解、存储选型依据、以及是否考虑实时场景的特殊性（如Kafka消息保留策略）。
回答框架：分层定义（ODS->DWD->DWS->ADS）+ 每层存储选型理由（ODS用Kafka保留近期数据；DWD用Kafka或HBase做明细大宽表；DWS用ClickHouse做聚合；ADS对外接口用Redis/MySQL）。
示例回答：“实时数仓沿用四层：ODS层Kafka保留3天原始数据，DWD层Flink清洗去重后写入HBase（Rowkey设计为事件ID），DWS层用Flink TUMBLE窗口聚合写入ClickHouse，ADS层供前端查询的预计算结果存入Redis。各层TTL分级管理，平衡存储与时效。”
可能追问：DWD层如果数据量极大，HBase如何应对高并发写入？如何做数据回刷？