企业官网建设流程全解析

做大数据架构设计这些年，我听过最多的一个问题不是“用哪个组件”，而是“先从哪儿下手”。很多人把架构设计理解成选型对比：存数据用HDFS还是对象存储，算数据用Spark还是Flink，查数据用Presto还是ClickHouse……选完组件发现系统跑起来还是各种问题：口径对不上、任务天天报警、数据越存越乱。实际上，决定一个大数据平台能不能立住的，不是某几个组件的新鲜度，而是藏在组件背后的设计模式与设计原则。这篇文章就围绕大数据领域数据架构设计中最常用的几种模式、四条底层原则，以及我在网约车项目里验证过的一套落地打法展开。不管你是刚接触数据架构的开发，还是在准备大数据面试，都可以从里面拿走直接能用的东西。

先给个铺垫：大数据架构和传统单体软件架构最大的区别在于，前者永远在处理“数据生命周期”的问题，从采集、传输、存储、计算到服务，每个环节都有独立的复杂度。如果一开始没有想清楚模式与原则，后面加需求就是加补丁，时间久了整个系统会变成一张所有人都改不动的蜘蛛网。这篇文章会先拆解业界常说的大数据架构四层，再聊聊批处理、流处理、Lambda/Kappa三类大方向，然后落到经典设计模式在数据工程里的映射，以及我实践过的可复现案例和排坑经验。

1. 大数据架构的底层逻辑：先看懂四层，再看其他

1.1 为什么分层是必然选择？

传统企业里做报表，经常是业务系统直接推一张表出来，BI工具连上去就画图。数据量小的时候这套链路没有任何问题，但数据量一旦上来，你会立刻遇到三个麻烦：源系统数据库扛不住查询压力，业务表结构一改报表就崩，多个部门对同一字段的口径能吵一年。于是大家开始把数据从业务库抽出来，单独建一套体系，这也就是数据架构分层的原始动机。

分层本质上是在控制复杂度。数据从产生到消费，中间要经历采集、清洗、转换、汇总、服务，每一步的处理目的和性能要求都不同。如果不分层，所有的逻辑都挤在一个大作业里，出问题时定位不了，改需求时牵一发动全身。分层之后，每一层只跟相邻层打交道，上层不关心底层怎么存储，底层不关心上层怎么展现，团队可以各管一段，任务调度和权限控制也都清晰了。

实际项目里，绝大多数大数据平台都能按四个层次来拆：采集层、存储层、计算层和服务层。有人会加一个“数据治理层”穿在中间，有人会把存储和计算合并说成“数据湖”，四层是基础骨架，治理是骨架上的肌肉。只要这些职责边界清楚，后来不管是接实时数据还是上数据服务，都能在不推翻大结构的前提下扩展。

1.2 四层架构拆解：采集、存储、计算、服务

我把这四层拆成一张实战表，每个层的核心职责、常用组件和设计要点都列清楚，方便你对照着自己的项目做体检。

这四层的顺序不是随便定的，它对应数据从“发生”到“被使用”的方向。比如你做网约车项目，司机端上报的定位日志先进Kafka，这是采集层；Flink或Spark消费后落到HDFS或Hudi，这是存储层；然后跑里程统计、订单聚合，这是计算层；最后把统计结果同步到MySQL或Doris，给大屏和App调用，这是服务层。每一层的职责单一，出了问题也能快速圈定范围。

有个容易被忽略的点：采集层不只是把数据搬进来，还要负责记录“我搬到了哪”。Kafka的offset、Flink的checkpoint、DataX的job标记，这些都是采集层的元数据。如果采集层不做断点续传，后面所有层都只能做全量重跑，成本会非常高。所以在设计四层架构时，我建议先画清楚数据流向图，标出每一层之间的“接口契约”，比如明天要从MySQL同步一张10亿行的订单表，采集层的并发和限流策略是什么，存到存储层用什么分区格式，计算层要等多少分钟才能读到。

2. 三种主流架构模式：批处理、流处理与混合架构

2.1 离线批处理模式：稳定压倒一切

早期的数据架构基本都是离线批处理：每天凌晨用Sqoop或DataX把数据抽到数仓，再用Hive或Spark跑T+1报表。这个模式最大的优点是简单和可重算。数据不会突然没了，任务失败了清掉重跑就行，计算逻辑可以一遍遍调试，结果对账也容易。很多金融、传统企业的核心报表现在还坚持这个模式，不是他们不需要实时，而是稳定性优先于时效性。

离线批处理的架构设计重点在于“批”的划分与依赖管理。一个订单表从ODS到ADS要经过清洗、明细、汇总多道工序，必须按DAG调度起来，后一个任务依赖前一个任务成功。通常会用工作流调度系统编排任务，比如DolphinScheduler、Airflow，或者干脆用Shell脚本加crontab。分层虽然让逻辑清晰了，但也带来了任务链路变长、出错点变多的新问题，所以离线架构里调度血缘和失败重跑策略一定不能省。

大数据集群部署策略在这时候很关键。离线批处理对资源的需求呈现明显的“凌晨洪峰”特征，几十个任务集中在一个小时跑完。如果所有节点都配成一样的规格，高峰期扛不住，平峰期又浪费。常见的部署策略是把集群分成主力计算池和弹性计算池，主力池承担核心数仓任务，弹性池专门跑临时分析、数据开发调试，避免临时任务把核心任务挤死。

2.2 实时流处理模式：低延迟的代价

业务一旦需要分钟级甚至秒级指标，离线批处理就满足不了了。比如网约车平台要看当前时刻在线司机数、热区接单时效，这些指标如果用T+1算出来，运营同学根本没法用。实时流处理模式因此进入主流视野，核心组件一般是Kafka加Flink，用流式计算引擎对数据做持续处理。

流处理架构的好处是低延迟，但代价是状态管理和精确一次语义变得异常复杂。Flink虽然有checkpoint和exactly-once机制，但你真的要在生产环境做到端到端不重不漏，还需要在数据源、外部存储、下游Sink上做配合。比如Kafka offset的提交时机、MySQL写入的幂等键、Redis缓存的双写一致性，一个环节没沟通好，实时指标的准确率就崩给你看。

很多团队一上来就想做“全实时”，结果发现成本和运维难度翻了不止一倍。我的建议是，先盘点指标时效性需求，把核心指标和边缘指标分开。核心指标走秒级流处理，边缘指标走小时级微批，能用5分钟批处理解决的别硬上毫秒流。这个取舍不是技术能力问题，而是系统复杂度和收益曲线的匹配问题。

2.3 Lambda与Kappa架构：鱼与熊掌怎么选

Lambda架构是过去十年最流行的大数据架构模式之一，核心思路是“用两条路做同一套指标”：一条离线批处理路径产出准确结果，一条实时流处理路径产出低延迟结果，最终在服务层合并。这样既保住了离线计算的准确性和容错性，又满足了实时查看的需要。但代价是两套代码、两套存储、两套口径，维护成本很高。

Kappa架构则尝试用一套流处理搞定所有需求：所有数据都当成流，统一进Kafka，用Flink做实时计算，如果某些指标需要批量重算，就重放Kafka历史数据慢慢流式补数据。Kappa的优点是只维护一套流处理代码，逻辑统一，但缺点也很明显：对Kafka的存储周期有要求，数据量大了成本不低，而且重算历史数据的耗时未必比离线批处理短。

个人经验：中小规模团队没有强实时需求时，尽量先采用“离线数仓+实时数仓并存，但共用ODS层”的分层式混合架构，本质上是Lambda的变体，但不再做两套独立代码，而是让实时计算和离线计算读取同一份底层数据、共用同一套维度表，只在DWD/DWS层各走各的链路。这样核心口径能对齐，维护成本也还能接受。

3. 设计原则：架构稳定的几条“锚”

3.1 CAP定理与BASE原则：分布式系统绕不开的那道选择题

任何分布式系统都逃不过CAP定理：分区容错性(P)在大规模集群里是必然存在的，网络分区一发生，你只能在一致性(C)和可用性(A)之间选一个。大数据架构到处都是CAP的影子。HDFS为了保证强一致性，在NameNode上做单点元数据管理，换来的是分区容错时需要切换；Kafka为了高吞吐和高可用，允许分区副本在不同broker上异步同步，默认情况下某些极端场景会有一致性缝隙。

BASE原则是大多数大数据系统的现实选择：基本可用、软状态、最终一致。数据仓库里某张汇总表晚5分钟更新，用户不会觉得天塌了，这就是基本可用；某个实时指标因为上游延迟暂时偏低，过会儿数据补齐了再修正，这就是软状态和最终一致。设计大数据架构时，先想清楚每一层能容忍的口径偏差是多少。比如订单量统计，离线T+1一定是准的，实时指标允许有5%的偏差，那么你就不需要为了那5%去强上复杂的精准一次机制。

很多面试题会拿CAP和BASE来考，但实际落地的关键不是背概念，而是给每条数据链路标注一致性等级。我现在做架构评审时，都会要求每个负责人写清楚：这条链路是强一致还是最终一致，数据最多滞后多长时间，重跑后怎么修复影响。把这个问明白，比会背一百个定理都管用。

3.2 数据分层设计原则：ODS/DWD/DWS/ADS怎么划

经典数仓分层是ODS、DWD、DWS、ADS，四个层次各司其职。ODS是贴源层，原样存放从业务库抽取的数据，不做太多加工；DWD是明细层，做清洗转换、维度退化、统一编码，让数据变干净；DWS是汇总层，按主题做宽表和指标预聚合；ADS是应用层，面向报表、大屏、接口输出结果数据。

这套分层原则帮助团队把混乱的数据变成有条理的产品。比如网约车平台原始订单表在ODS里可能还带着一堆杂七杂八的字段，到了DWD层就会拆成事实表和维度表，订单事实表里只留订单id、司机id、乘客id、出发时间、里程、金额，司机维表、城市维表单独维护。到了DWS层，按照城市、小时聚合出订单量、完成率、平均应答时长等指标。ADS层再按业务需要从DWS里圈选字段生成报表。

分层不是越细越好，要不要四层全上，取决于团队规模和业务复杂度。五个人不到的小组硬要做四层，最后一定会变成四层空转，数据没人维护。我见过很多项目把ODS和DWD合并，或者把DWS和ADS合并，效果反而更好。原则是每一层都要有明确的生产者和消费者，如果某层建出来后没人用，果断砍掉。

3.3 数据治理与元数据管理：数据平台能跑多久，就看这一层

大数据平台刚上线时跑得飞快，半年后开始乱：表名看不懂、字段注释缺失、同一个指标在两张表里口径不一样、ETL任务的上游挂了半天没人发现。这不是技术问题，是没做数据治理。企业数据架构里经常引用的一套方法论包括四个域：数据资产目录、数据标准、数据模型、数据分布，核心目的就是让数据从源头到消费都有谱可查。

我自己的落地套路是三步走。第一步建元数据仓库，把表名、字段名、责任人、更新时间、血缘关系都收集起来。第二步定命名规范和数据标准，比如日期字段必须统一成yyyyMMdd，金额字段统一用分为单位还是元为单位，状态字段必须有枚举说明。第三步把质量规则挂在元数据上，比如非空率、唯一性、枚举值合法性，每天自动扫描并推送告警。

数据治理最难的从来不是工具，而是执行。一个人在文档里写规范没用，必须在开发流程里拦截。我见过比较有效的做法是搞“数据表准入评审”，新表上线前必须提交数据字典和质量检测报告，没有通过就不给审批。虽然麻烦，但真的能让后面的数据开发省下大量对口径的时间。

3.4 集群部署策略与命名规范：细节里藏着稳定性

大数据集群部署不是把所有节点丢到一个池子里就行。生产环境我一般分成五类节点：主节点组跑NameNode和ResourceManager，计算节点组跑DataNode和NodeManager，核心任务队列和执行任务队列做资源隔离，再单独放一批实时计算节点跑Flink TaskManager，避免实时任务和离线任务抢资源。

容错设计上，ZooKeeper至少三个节点，NameNode用双机热备，Kafka副本因子至少要2。很多新手会为了省机器把副本因子设为1，结果一台物理机故障直接丢数据。这不是省钱，是埋雷。集群部署策略的原则是“按角色隔离、按重要性分级、按数据量弹性伸缩”，宁可初始少建几个队列，也要把核心任务的资源预留出来。

命名规范也是设计原则的一部分。表名统一用小写下划线分隔，区分层次前缀，比如ods_、dwd_、dws_、ads_，任务名用“业务域_表名_处理周期”的格式。命名规范不用多复杂，但一定要可读、可搜索、可归类。我见过最痛苦的项目，数据开发离职后新来的人看着几十张名不符实的表完全无法接手，最后只能推倒重来，这个成本比多做几次规范检查高太多了。

4. 经典设计模式在大数据工程里的落地玩法

4.1 模板方法模式：让ETL代码长成一个模子

设计模式不只是Java面试题，数据工程师日常每天都在用，只是可能没意识到。拿数据清洗举例，ETL任务虽然业务不同，但骨架高度一致：读数据、过滤无效字段、统一格式、维表补全、写目标表。这时用模板方法模式非常合适：把公共流程定义在基类里，把每个项目的差异化逻辑留给子类实现。

我在一个网约车数据清洗项目里就这么干的。基类负责创建SparkSession、读取源表、保存结果表、记录日志，子类只需要实现extract、transform、validate三个方法。结果十几张表的清洗任务代码量减少了一半，新人上手也能很快按照模板写新任务。更重要的是，当需要统一加一个全局字段如数据来源标签时，只改基类一次，所有任务立刻生效。

模板方法模式的关键是把握“稳定”和“变化”的边界。公共流程一旦抽出来就不要频繁变，否则所有子任务都要跟着回归测试。我会把“读库和写库”这类动作全部收敛到基类，把“过滤和转换”尽量下推到子类，这样基础组件升级时对业务逻辑的影响最小。

4.2 策略模式：用一个接口兼容Spark、Flink与SQL

很多公司不会只用一个计算引擎，同一个指标可能在Spark上批量计算，在Flink上实时计算，在Presto上临时查询。如果代码里到处是SparkSession和FlinkTableEnvironment，后续切换引擎就等于重写一套业务逻辑。这时策略模式是好工具：定义一个计算器接口，比如execute(DataFlowContext)，然后分别实现SparkCalculator、FlinkCalculator、SqlCalculator。

我维护过一个指标计算服务，核心逻辑先编写成通用的表达式或配置，然后把配置交给不同的策略执行器。离线调度走Spark策略，实时场景走Flink策略，数据开发调试走SQL策略。这样新增一种引擎的时候，不需要动已有的业务配置，只要新增一个策略类并在工厂里注册就行。

策略模式的前提是“业务规则的高度抽象”。如果你每个计算逻辑都跟具体引擎的API强绑定，策略模式也救不了。所以我一般会在业务层先定义一套中间结果集的数据结构，比如统一字段名和类型，然后在策略内部做引擎API的转换。这块需要一定的架构洁癖，做完之后收益非常明显：引擎升级、迁移、对比验证都变得可控。

4.3 观察者模式：元数据变更如何驱动下游任务

数据平台里经常遇到这种情况：上游业务表增加了一个字段，下游数仓模型没感知；上游枚举值变了，下游统计口径还停留在旧值上。人工通知永远慢半拍，更好的做法是用观察者模式做元数据变更广播。元数据服务作为被观察对象，各个调度系统、质量监控、指标平台都注册为观察者，一有变更就触发响应。

我用过比较轻量的实现方式是：元数据服务把变更事件写入Kafka主题，下游系统各自消费变化消息。比如源表新增字段后，采集任务自动感知并把字段同步到数仓模型；质量监控重新加载校验规则；数据字典同步更新字段注释。这个模式尤其适合上百张表、多个团队协作的场景，能极大减少“不知道谁改了什么”的沟通成本。

观察者模式在大数据平台落地时，最怕事件风暴式消费引起下游任务连锁重跑。所以要在消息里带上变更类型和影响范围，下游收到后先判断自己相关的表有没有被影响，再决定要不要重跑。给每个事件都设计一个全局唯一的变更版本号，重跑和回滚时都基于版本号操作，避免同一份数据被多个任务重复处理。

4.4 责任链模式：数据质量校验与血缘追踪的串联思想

数据质量检查在大型数据平台里不是单点动作，而是一条链。一份数据从ODS到DWS，中间要经过格式检查、空值检查、唯一性检查、值域检查、一致性检查。如果每个检查逻辑写成独立if，代码会越来越难维护。责任链模式可以把质检规则组织成一条流水线，每个节点处理一项检查，失败就中断，成功就进入下一个节点。

我在做数据质量检查框架的时候就用了这个思路。先建一个抽象校验节点，定义handle方法；然后实现非空校验、枚举校验、波动率校验等具体节点。每次任务执行完，把校验结果和告警消息推给上级系统。这样新增一项校验规则，不需要改主流程，只要在链路上加一个节点。血缘分层的逻辑也可以按责任链串联：从Hive表血缘一直追踪到源库表字段，一层层查下去，直到定位到问题源头，这在排查“某张错误表影响过多少下游”时特别有用。

责任链模式要注意“链路顺序”和“失败策略”。有的检查不做拦截只做告警，有的检查强制阻断任务，顺序设计错了会导致无意义的告警风暴。我一般把轻量级规则放前面先过滤，把耗时长的规则放后面，能明显减少无效计算和重复告警。

5. 实战复现：网约车数据从离线到实时的架构设计

5.1 场景与选型：为什么决定采用混合架构

用一个网约车数据项目作为样例来还原完整设计过程。业务目标是三件事：第一，每日运营报表，包括营收、订单量、完单率；第二，实时大屏，展示当前订单、热区需求、司机在线数；第三，按城市/时段的指标自助分析。第一和第三天然适合离线批处理，第二需要实时流处理，所以最终选择了离线数仓与实时数仓共存的混合架构。

选型上没有盲目跟风。存储层用HDFS保存原始订单日志，Kafka承接实时日志，Hudi作为实时仓的存储底座。计算层离线用Spark SQL，实时用Flink SQL，服务层查询用Doris和MySQL。整套架构不花哨，但每层都解决一个具体问题。关于要不要引入Hudi或Iceberg，我的判断依据是“是否需要对主键做更新”，网约车订单存在状态流转，比如订单从呼叫变成完成，用Hudi做MOR更适合。

5.2 数据流向与主题表设计

数据流向分两条链路。离线链路：司机端和乘客端的日志由Flume或DataX写入Kafka，再定期落ODS；DWD层做数据清洗，把订单、司机、城市关联成明细宽表；DWS层按城市、小时做订单聚合；ADS层输出报表结果。实时链路：同样的Kafka消息由Flink流式消费，先清洗，再按窗口聚合成实时指标，最后写Doris供大屏查询。

表设计可以复用一个简单模型。订单事实表字段包括订单id、司机id、乘客id、城市id、出发时间、完成时间、订单金额、订单状态。城市维度表、司机维度表单独建立，用维度id关联事实表。DWS层宽表则冗余出城市名、司机类型等常用维度属性，减少即时join。这里有个实操经验：事实表中的金额字段一定要统一单位，最好用分存储，避免浮点误差。

实时链路和离线链路共用同一套维度表，但数据刷新频率不同。离线维度表每天更新一次，实时维度表用Flink维表join的方式从MySQL或者Redis读取。实时大屏上的城市名和离线报表里的城市名来自同一份编码表，这样才能保证口径一致。我在设计时还把Kafka消息里的traceid一直保留到DWD层，后期排查数据缺失时能直接按traceid做链路追踪。

5.3 集群部署与资源评估经验

环境规模我按“最小可用”来规划：3台物理节点做基础集群，其中1台部署NameNode和ResourceManager，3台同时作为DataNode和NodeManager，Kafka单独放在另一批机器上，Flink的TaskManager和Spark Executor错峰使用。资源队列分为离线队列、实时队列、开发队列，离线任务跑凌晨窗口期，实时任务固定占一部分资源不分时。

资源评估给一个参考经验：10G/s的日志流入量，Kafka至少需要3个broker，每个broker磁盘吞吐按200MB/s预估；Spark任务每100个并发executor大约需要200GB内存，要按真实数据量做压测。不要只看磁盘容量不看内存，大数据任务最容易先打爆的是堆内存和GC，而不是磁盘。

集群部署里还有一个容易踩的坑：NameNode的元数据磁盘必须用SSD且要高可用，Kafka的日志目录不跟系统盘放一起，HDFS的DataNode数据盘要按数据增长预留30%余量。上线前把监控配齐，NameNode的CPU、DataNode的磁盘IO、Kafka的消费延迟，这四类指标直接关系到架构能不能持续跑下去。

5.4 上线后最容易翻车的几个点

复盘这个项目的上线过程，有四个问题印象最深。第一是Kafka日志保留时间设得太短，导致Kappa式重算历史数据时发现消息已被清理，后来统一把日志保留时间按峰值流量估算到7天。第二是Flink的表名和Hive表名不一致，实时指标和离线指标对齐时花了大量人力，后来把Flink SQL里的表名、字段名全部对齐Hive。

第三是Spark写Hudi时产生了大量小文件，导致查询越来越慢，后来在写Hudi时设置了小文件自动合并的索引策略，并定期跑compaction。第四是数据倾斜集中在晚高峰订单数据上，一个热门城市的订单量占全平台40%，reduce阶段稳定卡住20分钟，最终靠自定义分区器把热点key打散到多个分区解决。这四个问题如果你不去提前设计，绝对会在上线第一周轮番发生。

6. 问题排查实录：大数据架构里的高频坑与解法

6.1 数据倾斜：任务99%卡在最后几个Stage

数据倾斜是离线和实时任务里最经典的问题。表现是Spark的某个stage里绝大多task已经跑完，但有一两个task还卡住不动，或者Flink的某个keyed state异常膨胀。本质原因是数据分布不均匀，比如网约车订单按城市分组，一线城市的key比其他城市大几个数量级，map端还可以，reduce端就炸了。

排查步骤通常是先看Spark UI，找到执行异常的stage，再按key统计前几个热点分组。如果热点是实数，用加盐或自定义partition器打散；如果热点是空值或某种业务默认值，考虑把默认值的key单独过滤或者随机加后缀。实时场景则要给Flink keyBy后的状态设计合理的TTL和过期策略，避免状态无限增长。

数据倾斜问题需要在架构设计时预留解法空间。比如ODS层保留最全的原始粒度，DWD层做必要的聚合，不要在DWD层过早合并小key，否则后面想重新分配数据都难。真正上线后遇到倾斜，优先用“两次聚合”或“过滤加补”的方式处理，不要上来就改写全部业务逻辑。

6.2 小文件过多：NameNode为什么会先崩

HDFS的NameNode把元数据存在内存中，每个文件、目录、块都会占一块内存。几百万个小文件会让NameNode内存暴涨，同时Spark、Hive在拉数据时也需要频繁跟NameNode交互，性能急剧下降。小文件主要来自不合理的动态分区写入、Spark任务并行度设置过大、流任务高频写文件等原因。

解决方式分治和合两类。治是尽量在写入时控制文件大小，比如Spark写Hive时通过参数控制分区大小，或者写Hudi/Iceberg时用自带的文件合并机制。合是定期对小文件做一次compact，比如用Spark读小文件目录然后重新coalesce写入临时目录再替换。生产环境我建议在ODS和DWD层都加一个自动巡检，每天统计文件数，超过阈值自动触发合并任务。

小文件问题在架构设计时就该防：分区粒度不要细到按小时以下，除非有强实时需求；写入时设置合理的文件目标大小，通常128MB到256MB；如果是流处理落到HDFS，尽量用Flink的bulk写入加滚动间隔，不要频繁关闭文件。否则等你发现NameNode告警时，日常请求已经出问题了。

6.3 离线与实时口径不一致：对账脚本怎么设计

口径不一致是最让数据团队头疼的问题。离线跑的是当天最终数据，实时是分钟级快照，两边数字对不上其实是正常的，但用户不认这个理由。为了降低“扯皮”成本，一定要建一套对账机制：每天凌晨离线任务跑完后，自动把离线指标和昨天实时指标存下来的快照做对比。

对账脚本的设计我用同一套基础明细。离线侧从DWD层统计订单数、金额、按城市分组；实时侧从Doris里取昨天实时指标每小时累加值。两边列一张差异表，超过1%的指标自动告警。这类脚本跑几天之后，你会发现大部分差异来自时间窗口边界，比如23:59:59进入实时统计但离线任务的T+1窗口从00:00开始。统一窗口切分规则比争论谁对谁错更有效。

更进步的做法是让实时指标每5分钟自动打点，存下来的快照在天亮后和离线结果做拟合。如果实时指标的波动趋势和离线结果一致，只是有一个稳定的时间差，那就说明逻辑没问题，用户也更容易接受这个口径。对账的目的不是追究责任，而是让数据缺陷能被发现，然后基于问题去修改调度窗口或者处理逻辑。

6.4 面试高频题速记：架构师到底在考什么

大数据架构相关的面试热度一直很高，换汤不换药的问题集中在这几类：谈谈Lambda和Kappa的区别、CAP在分布式系统里怎么抉择、数据仓库分层的原则、如何处理数据倾斜、Spark和Flink的容错机制、如何保证数据质量、怎么设计一张指标一致的表。这些问题的背后都在考察“你有没有真正做过权衡”。

面试时不要只背概念，最好带上具体案例。比如问Spark和Flink的区别，不只是说一个批一个流，可以说“我做过一个网约车实时大屏，离线用Spark跑T+1好，实时用Flink做分钟级聚合，两者共用Kafka和Hudi，最终在Doris层对齐口径”。这样既体现了架构模式的理解，又展示了设计原则的落地能力。

还有一类容易被忽略的问题是关于数据治理和原数据管理，比如“数仓表越来越多，如何管理血缘？”直接答责任链和元数据订阅就行。面试官真正想听的是你认为“没有人能永远靠脑子记住全链路”，系统机制才可靠。这些经验都是踩坑踩出来的，比被知识体系更能体现深度。

架构设计没有银弹，所有的模式和原则最终都要根据数据规模、团队能力、业务时效来权衡。我用过的最笨但最有效的办法，是先画出数据流全景图，再在每条边上标注一致性、时效性、资源消耗和负责人。图画完，架构里的问题通常自己就冒出来了。这套思路我一直在沿用，也推荐你试试。