案例阅读方法每个案例按 7 个维度理解业务背景。数据规模。技术架构。核心原理。难点和解决方案。研发经理关注点。面试表达模板。案例一电商实时用户行为分析平台业务背景电商平台需要实时观察用户浏览、搜索、加购、下单、支付行为用于运营大屏、活动效果分析、推荐策略、广告投放和异常监控。数据规模假设日活用户 1000 万。每个用户每天平均产生 200 条行为事件。日数据量约 20 亿条。高峰期每秒写入几十万条事件。运营大屏要求 10 秒到 1 分钟内看到结果。技术架构前端埋点 SDK | v Java 网关接收埋点 | v Kafka user-events Topic | v Flink 实时清洗、去重、窗口聚合 | ------------------ | | v v ClickHouse 实时查询 Iceberg 明细入湖 | | v v 运营大屏 / BI Spark 离线画像核心原理Kafka 负责削峰填谷和可回放。Flink 按用户 ID 或会话 ID 分区做实时清洗、去重和窗口聚合。ClickHouse 存储实时指标和明细宽表支撑运营大屏秒级查询。Iceberg 保存原始明细方便后续回放、审计、离线分析和模型训练。难点和解决方案难点一埋点数据质量差。解决接入层做 Schema 校验。非法事件写入脏数据 Topic。重要字段做非空校验。埋点版本纳入治理。难点二同一用户行为乱序。解决Kafka key 使用 userId。Flink 使用 Event Time。设置合理 Watermark。对迟到数据做旁路修正或补偿。难点三大促高峰流量激增。解决Kafka 提前扩容 Partition。Flink 提前扩容并行度。非核心指标降级。ClickHouse 写入批量化。大屏查询使用预聚合表。关注点埋点规范和指标口径必须统一。Kafka Lag、Flink 延迟、ClickHouse 写入延迟都要监控。活动前要做容量压测。需要数据回放能力避免活动期间数据错了无法修复。指标要分核心和非核心核心链路优先保障。面试表达模板这个场景我会采用 Kafka Flink ClickHouse Lakehouse 的架构。 Kafka 承接高峰流量并支持回放Flink 做实时清洗、去重、窗口指标ClickHouse 支撑运营大屏和多维分析Iceberg 保存明细数据用于离线分析和回算。 难点主要在埋点质量、乱序迟到、高峰堆积和指标口径一致性。 研发经理层面我会推动埋点规范、链路监控、容量压测、数据质量和补数机制。案例二金融实时风控系统业务背景支付、信贷或交易系统需要在用户交易发生后几百毫秒到数秒内识别风险例如盗刷、撞库、异常提现、设备异常、频繁失败交易。数据规模假设峰值交易 TPS 5 万。每笔交易需要关联用户历史行为、设备、IP、地理位置、黑名单、规则结果。风控决策延迟要求 100 毫秒到 1 秒级。技术架构交易系统 | v Kafka transaction-events | v Flink 风控特征计算 | ------------------ | | v v Redis 实时特征 Kafka risk-results | | v v Java 风控决策服务 审计入湖 / 离线建模核心原理Flink 按 userId、deviceId、cardId 等维度维护状态。状态中保存最近 5 分钟、1 小时、24 小时的交易次数、金额、失败次数、IP 数、设备数等指标。Checkpoint 保证故障恢复。Redis 提供低延迟查询特征。离线数据进入湖仓用于模型训练和规则复盘。难点和解决方案难点一状态很大。解决使用 RocksDB StateBackend。设置 State TTL。拆分不同时间窗口。清理低价值状态。难点二Exactly Once 与外部系统一致性。解决Kafka Source 可重放。Flink 开启 Checkpoint。Sink 写 Kafka 或支持事务的存储。Redis 写入用业务 key 幂等覆盖。难点三热点用户或攻击流量导致倾斜。解决热点 key 监控。对攻击流量限流。热点维度拆分。使用规则降级保护主链路。关注点风控链路要明确 SLA。规则引擎、模型服务、特征平台要分层。高风险决策必须可解释、可审计。线上规则发布要灰度和回滚。必须有降级策略不能让风控系统拖垮交易主链路。面试表达模板实时风控我会优先考虑 Flink因为它适合有状态、低延迟、事件时间和容错要求高的场景。 核心设计是用 Kafka 接入交易事件用 Flink 按用户、设备、卡号等维度维护实时特征结果写 Redis 或 Kafka再由 Java 决策服务执行规则和模型。 难点是状态规模、端到端一致性、热点攻击流量和规则发布治理。案例三用户画像离线标签平台业务背景运营、推荐、广告和会员体系需要用户画像标签例如消费能力、品类偏好、活跃度、生命周期、价格敏感度、流失风险。数据规模假设用户数 3 亿。订单明细百亿级。行为明细千亿级。标签每天 T1 更新一部分核心标签小时级更新。技术架构业务库 CDC / 行为日志 | v Kafka / 数据同步工具 | v ODS 原始层 | v Spark 清洗建模 | v DWD 明细层 - DWS 汇总层 - ADS 标签层 | ------------------- | | v v 画像服务 API BI / 分析 / 推荐核心原理离线标签平台通常采用数仓分层。ODS 保存原始数据。DWD 做清洗后的明细事实表。DWS 做公共汇总。ADS 面向应用生成标签结果。Spark 负责大规模 Join、聚合、窗口函数和历史回算。难点和解决方案难点一指标口径混乱。解决建立指标字典。标签定义进入元数据系统。标签负责人和审批流程。相同指标只允许一个权威来源。难点二Spark Join 数据倾斜。解决小维表广播。热点 key 拆分。加盐 Join。两阶段聚合。优化分区和文件大小。难点三历史回算成本高。解决增量计算。分区重算。标签依赖分析。低价值标签降频。关注点标签平台要防止重复建设。标签要有生命周期和使用统计。重要标签要有质量校验。计算资源要按优先级调度。标签服务要关注查询延迟和缓存命中率。面试表达模板用户画像本质是离线数仓和标签工程问题。我会用 Spark 做大规模离线加工采用 ODS、DWD、DWS、ADS 分层保证明细、汇总和应用层边界清楚。 技术难点主要是数据倾斜、指标口径、历史回算、标签质量和服务化查询。 研发经理要重点推动指标治理、标签资产管理和资源成本控制。案例四IoT 设备海量时序数据平台业务背景智能设备、车联网、工业传感器会持续上报状态、位置、温度、电量、告警等数据。数据特点是写入频率高、时间序列明显、设备数量大、冷热差异明显。数据规模假设设备数 500 万。每台设备每 10 秒上报一次。每天数据量超过 400 亿条。近期数据需要秒级查询历史数据主要用于离线分析。技术架构设备 MQTT / HTTP 上报 | v 接入网关 | v Kafka device-metrics | ------------------- | | v v Flink 实时告警 Iceberg / 对象存储 | | v v 告警系统 Spark 离线分析 | v 时序库 / OLAP 查询核心原理设备数据按 deviceId 和时间分区。Flink 实时检测异常例如温度过高、离线、连续失败、轨迹异常。近期热数据进入时序库或 OLAP。历史冷数据进入对象存储和湖仓用于批量分析。难点和解决方案难点一写入量巨大。解决Kafka 多分区。接入层批量发送。数据压缩。非核心字段降采样。难点二设备数据乱序和补报。解决使用事件时间。Watermark 允许一定乱序。迟到数据单独修正。难点三冷热数据成本。解决热数据保留 7 到 30 天。温数据放湖仓。冷数据归档。查询层按时间路由。关注点接入协议和设备版本要标准化。高峰写入要压测。要区分实时告警链路和离线分析链路。不能让全部历史数据都占用高性能存储。设备侧数据质量也要纳入治理。面试表达模板IoT 数据的特点是高频写入、强时间属性和冷热差异明显。 我会用 Kafka 承接设备上报用 Flink 做实时告警和状态检测用湖仓保存全量历史用时序库或 OLAP 支撑近期查询。 核心难点是高吞吐接入、乱序补报、冷热分层和设备数据质量。案例五广告实时计费与投放分析系统业务背景广告系统需要实时统计曝光、点击、转化、消耗、ROI并且计费数据必须准确。数据规模假设每天曝光 100 亿。每天点击 1 亿。广告主需要分钟级看到消耗和转化效果。计费链路必须可审计、可对账。技术架构曝光 / 点击 / 转化日志 | v Kafka ad-events | v Flink 实时清洗、去重、归因、聚合 | ------------------- | | v v Doris / ClickHouse Iceberg 审计明细 | | v v 广告主报表 离线对账 / 归因回算核心原理曝光、点击、转化通过 requestId、clickId、userId 等标识关联。Flink 做去重、窗口归因、实时聚合。OLAP 存储支撑广告主报表。湖仓保存审计明细支持离线对账和争议处理。难点和解决方案难点一重复上报。解决使用唯一事件 ID。Flink 状态去重。Sink 幂等写入。难点二转化延迟。解决使用事件时间。设置归因窗口。对迟到转化做补偿更新。难点三计费准确性。解决计费链路和分析链路分级。明细可审计。实时结果可离线对账。金额计算避免浮点误差。关注点计费链路优先级最高。必须能重放和对账。报表延迟可以分等级。广告主查询要隔离资源。数据口径变更要有版本管理。面试表达模板广告系统里实时性和准确性都很关键尤其计费链路要可审计、可对账、可回放。 我会用 Kafka 做日志入口Flink 做实时去重、归因和聚合OLAP 引擎提供广告主查询湖仓保存全量明细用于审计和离线回算。 难点是重复事件、迟到转化、归因口径和计费一致性。案例六日志检索与可观测性平台业务背景公司有大量 Java 服务、网关、数据库、缓存和中间件需要统一采集日志、指标、链路追踪用于故障排查和容量分析。数据规模假设上千个服务实例。每天日志几十 TB。核心错误日志需要秒级检索。普通日志保留 7 到 30 天归档日志保留 180 天。技术架构应用日志 / 指标 / Trace | v Agent 采集 | v Kafka observability-events | ------------------- | | v v Flink 实时告警 ClickHouse / Doris | | v v 告警平台 日志检索 / 看板 | v 对象存储归档核心原理日志数据写多查少但故障时查询压力会突然升高。需要对 service、level、traceId、timestamp 等字段建立合理索引或排序。实时告警依赖流式规则。归档依赖冷热分层。难点和解决方案难点一日志量爆炸。解决日志分级。Debug 日志采样。大字段截断。生命周期管理。难点二故障期间查询高峰。解决热数据放高性能 OLAP。常用查询走物化视图或缓存。按服务和时间分区。查询限流。难点三告警噪音。解决告警分级。聚合相同错误。抑制重复告警。关联发布事件。关注点可观测性平台本身也要监控。日志成本要纳入团队预算。告警要减少噪音否则没人响应。TraceId 要贯穿服务链路。故障复盘要推动埋点和指标补齐。面试表达模板日志平台的关键是高吞吐写入、快速检索和成本控制。 我会用 Agent 采集日志进入 KafkaFlink 做实时告警ClickHouse 或 Doris 支撑热日志检索和看板冷数据进入对象存储归档。 难点是日志量爆炸、故障期间查询高峰、告警噪音和冷热分层。案例七企业湖仓一体数据平台业务背景企业多个业务线都有自己的数据库、报表和指标数据孤岛严重。管理层希望统一数据底座支持经营分析、风控、推荐、财务对账和 AI 数据准备。数据规模假设数百个业务库。上万张表。每天新增 TB 到 PB 级数据。既有 T1 报表也有分钟级实时指标。技术架构业务库 CDC / 日志 / 文件 / API | v Kafka / 批量同步 | v Lakehouse ODS | v Iceberg / Delta / Hudi 表 | ------------------- | | v v Spark 批处理 Flink 实时入湖 | v DWD / DWS / ADS | ------------------- | | v v Trino 联邦查询 Doris / StarRocks 服务查询核心原理湖仓一体通过开放文件格式和表格式把对象存储或 HDFS 上的数据组织成可事务化、可演进、可查询的数据表。Spark 做批处理Flink 做实时入湖Trino 做跨源查询Doris 或 StarRocks 做高并发服务查询。难点和解决方案难点一多源数据标准不统一。解决统一数据接入规范。统一命名规则。统一分层模型。建立元数据中心。难点二表太多治理困难。解决表生命周期。Owner 机制。使用频率统计。无主表清理。难点三实时和离线口径不一致。解决指标定义统一。Lambda 架构下做口径校验。或采用湖仓批流一体减少重复链路。对核心指标建立对账任务。关注点数据平台要有组织治理不只是技术架构。权限和合规必须前置设计。元数据、质量、血缘、成本要作为平台能力。优先做高价值数据域不要一开始追求全量大而全。平台要有服务目录让业务方知道有什么数据可用。面试表达模板企业湖仓平台的核心价值是打通数据孤岛统一存储、计算和治理。 我会用 Iceberg、Delta 或 Hudi 管理湖仓表用 Spark 做离线加工用 Flink 做实时入湖用 Trino 做跨源查询用 Doris 或 StarRocks 支撑高并发服务分析。 真正难点不只是框架搭建而是数据标准、指标口径、权限、血缘、质量和成本治理。案例八端到端综合项目讲法项目背景假设公司要建设一个统一用户行为数据平台为运营、推荐、广告、风控和管理驾驶舱提供数据能力。总体架构Java 业务系统 | v 埋点 SDK / 日志采集 | v Kafka | ----------------------- | | v v Flink 实时指标 Spark 离线数仓 | | v v ClickHouse / Doris Iceberg 湖仓 | | ---------------------- v BI / API / 推荐 / 风控 | v Airflow 调度 / 数据质量 / 监控 / 血缘 / 权限你在面试中可以这样讲如果让我从 0 到 1 负责这个项目我会分四步推进。 第一步先做最小闭环。业务系统埋点进入 KafkaFlink 做基础清洗和实时指标结果写入 ClickHouse 或 Doris先满足运营大屏和基础分析。 第二步补齐离线链路。全量明细进入 Iceberg 湖仓Spark 建 ODS、DWD、DWS、ADS 分层支持用户画像、历史回算和复杂分析。 第三步建设稳定性和治理。补齐 Kafka Lag、Flink Checkpoint、Watermark Lag、OLAP 查询延迟、任务失败率、数据量波动、数据质量规则、血缘和权限。 第四步做平台化和成本优化。沉淀统一接入模板、指标平台、标签平台、补数工具、冷热分层、物化视图、小文件治理和资源队列。 这个项目里我作为研发经理最关注的不是某个任务写完而是数据链路稳定、指标口径可信、异常可追踪、成本可控制、团队能持续交付。所有案例的共性总结海量数据落地项目一般都绕不开下面 10 个问题数据怎么进来。峰值怎么扛住。失败后能不能重放。实时和离线怎么分工。数据存哪里。查询怎么快。结果准不准。延迟能不能监控。成本会不会失控。团队能不能长期维护。面试时只要能围绕这 10 个问题展开就会比单纯背框架显得更像研发经理。