企业官网建设流程全解析

上周公司内部做方案评审，聊到某个实时同步任务的链路时延问题，有人随口说了句“这个Topic的Offset已经落后很多了，要盯一下Consumer Group的堆积情况”，旁边刚入职两周的同事愣了一下，会后偷偷问我：“Topic我大概懂，Offset和Consumer Group到底是什么关系？”我当时忽然意识到，在这个行业里，真正拦住新人的往往不是SQL写法，也不是框架API，而是一堆天天挂在嘴边的英文词汇。

大数据这个领域有个特点，技术文档、源码注释、设计评审、面试沟通基本都以英文词汇为“默认语言”。很多词看起来眼熟，但真要你说清楚它在整个链路里扮演什么角色，又说不利索。所以我花了不少时间整理了一份按工作场景分类的词汇清单，不是字母序词典那种，而是按照“你在做某类事情时最常碰到哪些词”来组织。这篇文章就是这份清单的第一版，后面会持续更新。

1. 为什么每个大数据从业者都需要自己的英文词汇清单

1.1 一次评审会上的“当场卡壳”让我开始整理词表

说白了，这个行业的英文词汇不是用来背的，是用来干活的。在真实工作场景里，这些词会出现在各种你无法回避的地方：设计文档里、代码注释里、周报标题里、同事的即时消息里，甚至面试官的第一句话里。

我自己刚入行那阵子也干过蠢事。有一次在数据同步方案里看到“CDC”，我以为是某种数据库连接配置，查了半天才发现是Change Data Capture，变更数据捕获。还有第一次听到同事说“这个任务Spill了”，我心想Spill不是“洒出来”吗？后来才知道是内存不够、数据溢写到磁盘的意思。类似的词积累多了以后，我发现如果不把它们按“工作场景”串起来，光靠零散记忆特别容易忘——查一次明白，过两周又模糊了。

1.2 我把词汇分成了三个层级：看得懂、用得对、能讲清

这也是我整理这份清单时的一个核心思路，每个词至少要在这三个层级中找到自己的位置。

第一个层级是“看得懂”。看文档、看监控面板、看报错日志的时候，知道这个缩写或术语大概是什么意思。比如看到“OOM”知道是内存溢出，看到“Backpressure”知道是背压，这就能让你在排障时不至于一头雾水。

第二个层级是“用得对”。你在跟同事沟通、写方案、做汇报时，能在正确的语境里使用这个词。比如你跟数据开发同学说“这个表按天分区，查询时要做分区裁剪”，对方立刻明白你的意思。如果是“分桶”却说成“分区”，往往就会产生误解。

第三个层级是“能讲清”。给新人培训、在面试中回答问题、在方案评审时解释技术选型，都需要你能把一个词背后的原理、适用场景、优缺点讲明白。比如“Exactly-once”这个词，很多人挂在嘴边，但要解释清楚它为什么难实现、业界通常用什么手段去趋近它，很多人又说不清楚了。

1.3 为什么按场景而不是按字母顺序整理

市面上的大数据词汇表并不少，但大部分是按字母排序的词典。这类表有个问题，查一次就忘一次，因为它把词汇从使用场景里剥离出来了。就好像你背了一堆做菜的术语，比如“改刀”“焯水”“挂糊”，但如果是按拼音顺序背，你很难在做红烧肉的时候立刻想起它们。

所以我换了个思路：按实际工作内容组织。你现在要搭数仓，就去看数据仓库与数据治理那一批词；你在搞实时计算，就直接从流处理与消息队列那批词进入。这样记起来的英文词汇，天然带着使用场景的锚点，不容易忘。这份清单一共有八个大的场景类别，下面一个一个说。

2. 存储与计算引擎：先把“数据存在哪、用什么算”这两件事说清楚

2.1 Hadoop到底是一个框架，还是一个生态代名词

Hadoop这个名字，现在很多新人已经觉得有点“上古”了。但不管Spark、Flink多流行，Hadoop依然是大数据技术的底座和代名词。严格来说，Hadoop是指Apache Hadoop生态，核心由三部分组成：HDFS负责存储，YARN负责资源调度，MapReduce负责计算。但现在大家说“Hadoop生态”，往往还包括Hive、HBase、Spark等一系列运行在它之上的组件。

有一个容易混淆的点：很多人以为“用Hadoop”就等于“用MapReduce写任务”。其实现在大部分任务都跑在Spark或Flink上，HDFS和YARN还承担着存储和调度的底层职责。你在简历写“熟悉Hadoop生态”，面试官默认你了解HDFS文件切块、副本机制，以及任务怎么被调度，而不是默认你会写MapReduce。

2.2 HDFS：把大文件切成块扔给一群机器的分布存储

HDFS，全称Hadoop Distributed File System，分布式文件系统。它的设计目标很直接，用一堆普通机器存超大文件，并且能容忍机器故障。

HDFS会把一个文件切分成多个Block（数据块），默认128MB一块，然后每个Block存多份副本，默认3份，分布在不同节点上。这样做的好处是，任何一台机器挂了，数据在其他机器上还有副本，不会丢。理解HDFS的关键是记住它“面向大文件、批量读写、不适合低延迟随机访问”的特点。你让它存一个日志文件、一个离线分析结果，它很开心；你要在上面跑一个在线小查询，它的性能会让你怀疑人生。

实际工作中，会看到“NameNode”“DataNode”这两个词。NameNode就是HDFS的“目录管理员”，管理文件系统的命名空间和Block到DataNode的映射关系；DataNode才是真正干活的，存数据块、响应读写请求。面试的时候如果被问到HDFS，这俩概念基本必考。

2.3 MapReduce、Spark、Flink：两代计算模型的差异

MapReduce是大数据计算模型的祖师爷。它把计算拆成两个阶段：Map阶段做映射和过滤，Reduce阶段做聚合和汇总。优点是非常稳定，适合海量数据的离线批处理；缺点是慢，因为中间结果频繁落盘，而且很多场景需要多次读写HDFS。

Spark的核心卖点是基于内存计算。它提出的RDD概念，把数据抽象成一种带血缘关系的分布式集合，中间结果优先放在内存里，减少磁盘IO。后来Spark又推出了DataFrame和Dataset API，让用户可以用类似SQL的方式操作分布式数据，门槛大幅下降。现在做离线数仓，Spark基本是默认选项之一。

Flink则是流处理领域的代表，Spark Streaming默认是微批模式，攒一小批数据再处理，而Flink是真正的事件流处理，来一条数据处理一条。这也带来一个本质差异：在实时性要求高的场景下，Flink的延迟更低。但要注意，现在Spark和Flink都在互相借鉴，Flink也有批模式，Spark也提供了结构化流。选型时更多看团队技术栈和具体时延要求。

这块词汇还有两个常客：Hive和Tez。Hive是把SQL翻译成分布式计算任务的“翻译官”，它本身不存储数据，只把SQL变成执行计划，跑在MapReduce、Tez或Spark上。Tez是DAG计算引擎，比MapReduce聪明的地方在于，它把多个有依赖关系的计算任务组织成一张有向无环图，能减少中间结果的重复写盘，所以很多Hive查询在Tez上会快不少。

2.4 YARN、Presto/Trino：生态里的“配角”其实都是主角

YARN的全称是Yet Another Resource Negotiator，在Hadoop生态里负责资源调度。你可以把它理解成集群的“物业公司”：哪个任务申请多少CPU、多少内存，由它统一分配、调度和管理。现在很多新项目用Kubernetes来跑大数据组件，但传统Hadoop集群里，YARN的调度能力依然很关键，面试常问它和Kubernetes的差异。

Presto/Trino这类MPP查询引擎，则解决的是“我想快速查一下这个数仓表，但不想等Spark任务启动”的需求。它的核心卖点是快，适合即席查询和交互式分析。Presto和Trino同源，后来因为社区路线分歧分成了两个项目。在数据湖和数仓场景中，Presto/Trino经常扮演那个“查询加速器”的角色。

提到底层存储结构，还会遇到LSM（Log-Structured Merge Tree）这个词，它是很多大数据引擎底层存储的基石，比如HBase、LevelDB、RocksDB都用了类似思路。LSM的核心就是把随机写转成顺序写，再通过后台合并来整理数据。理解它，对你理解HBase为什么写快读慢非常有帮助。

3. 集群与调度：分布式系统的组织架构词汇

3.1 Cluster、Node、Master/Slave、Leader/Follower

Cluster（集群）就是一批机器作为一个整体对外提供服务。Node是这个集群里的单台机器，也常叫作Worker节点或实例。谈架构的时候，人们会说“一个三节点的集群”“我们集群里跑了20个节点”——这些都是最基础、出现频率极高的词。

Master/Slave是经典的分布式主从架构表述，Master负责任务调度和管理，Slave负责执行任务。不过这些年越来越多项目改用Leader/Follower或Primary/Secondary来替代，主要原因是一部分旧词汇有历史包袱。你读老文章时还会经常看到Master/Slave，但要明白意思和现在的Leader/Follower是一样的。面试时如果提到这个概念，建议直接用Leader/Follower这种说法，表达更稳妥。

3.2 ZooKeeper，分布式系统的“管家”

ZooKeeper在大数据生态里的角色是分布式协调服务。它做三件典型的事：选主（Leader Election）、配置管理（Configuration Management）、分布式锁（Distributed Lock）。

举一个最直观的例子：在一个高可用的HDFS集群里，通常有两个NameNode，一个是Active状态，一个是Standby状态，正常情况下只有Active节点对外服务。怎么保证同一时刻只有一个Active节点？ZooKeeper就是那个做裁决的“管家”。HBase的RegionServer选主、Kafka的Controller选主，也都依赖ZooKeeper的协调能力。

很多人会问：“ZooKeeper自己挂了怎么办？”答案是ZooKeeper可以集群部署，通常奇数节点，过半存活就能继续工作。这也是面试里常问的ZAB协议、过半机制的场景来源。理解ZooKeeper，建议从“它解决的是分布式系统里谁说了算的问题”这个角度切入，比死记选举流程更有用。

3.3 Rack、Uplink、AZ：物理拓扑和容灾关键词

Rack是机架，机房里的机器通常按机架摆放。大数据系统在做数据副本放置时会有机架感知（Rack Awareness）机制：默认情况下，HDFS的3个副本不会放在同一个机架上，为的是某个机架断电或者交换机故障时，数据不至于全部不可用。

Uplink指的是机架之间的上行链路，带宽一般比机架内带宽低。了解这个词，能帮你解释为什么计算引擎要追求数据本地性——因为跨机架传数据比同一机架内传数据要贵得多。

AZ是Availability Zone的缩写，云场景下的可用区概念。一个AZ通常对应一个或多个机房，跨AZ部署是为了容灾。聊到云上大数据架构时，“跨AZ高可用”是经常挂在嘴边的一句话。

3.4 SLA、Uptime：运维视角的常用词

SLA全称Service Level Agreement，服务等级协议，指的是服务提供方承诺的可用性指标。比如“99.9%的可用性”，听起来差距不大，但折算下来，一年最多允许的不可用时间大约只有8.76小时。所以当你听到“这个集群的SLA是99.95%”时，要意识到这意味着每年宕机时间不能超过4个多小时。

Uptime就是运行时间，常和SLA一起出现。监控系统里如果报“Uptime下降”，意味着节点或服务不健康了。有些面试题会让你计算不同可用性对应的停机时间，本质上考的就是你对SLA数字的敏感度。

4. 数据仓库与数据治理：从ETL到数据血缘之间的常用词

4.1 ETL和ELT，不只是字母顺序的区别

ETL是Extract、Transform、Load的缩写，先抽取数据，再转换清洗，最后加载到目标存储。ELT则是Extract、Load、Transform，先把原始数据原封不动加载到目标存储，再进行转换。

早期数仓建设普遍用ETL，因为数据仓库的存储和计算资源宝贵，尽量把清洗转换放在进入数仓之前，避免脏数据污染数仓。但到了数据湖时代，存储成本大幅下降，计算引擎越来越强，ELT的优势就出来了：先把原始数据全都收进来，等需要分析的时候再去转换，灵活性更高。

实际工作中，你经常能听到“ETL任务挂了”“这个同步任务就是一条ELT链路”。别小看这俩词，方案评审时把顺序说反，是会闹笑话的。

4.2 Data Warehouse与Data Lake：一个像精装超市，一个像早市仓库

Data Warehouse（数据仓库，简称数仓）存的是经过建模、清洗、整合后的数据，结构化程度高，直接服务于BI报表和业务分析。Data Lake（数据湖）强调以原始格式存储海量数据，什么格式都收，结构化、半结构化、非结构化通通进来，等要用的时候再定义结构。

我个人喜欢用一个类比：数仓像精装超市，货架上的商品已经分好类、贴好价签，逛起来方便；数据湖像一个超大早市仓库，什么货都堆在里面，但你可以随时去翻，翻到了就能加工出你想要的东西。

最近的趋势是湖仓一体（Lakehouse），也就是在数据湖的存储底座上实现数仓的建模和管理能力，像Hudi、Iceberg、Delta Lake这些开源技术就是这股潮流的代表。

4.3 Schema、Metadata、Catalog：数据的“使用说明书”

Schema是数据结构定义，也就是一张表有哪些字段、每个字段什么类型、是否允许为空。大数据领域经常提到Schema-on-read和Schema-on-write，前者是读的时候才定义结构，后者是写的时候就必须严格校验。数据湖偏向前者，数仓偏向后者。

Metadata是元数据，描述数据的数据。比如文件创建时间、字段含义、表的负责人、数据量大小，都是元数据。Metadata不存具体业务数据，但它告诉你业务数据长什么样、放在哪、怎么用。

Catalog可以理解成元数据的目录中心。有了Catalog，你查询的时候才能通过库名、表名定位到真实的数据文件。很多计算引擎都内建或对接了Catalog服务，比如Hive Metastore就是一个最典型的Catalog实现。

4.4 数仓分层：DWD、DWS、ADS到底分什么

数仓建模中最常见的一套分层缩写，你几乎在每份数仓设计文档里都会看到。

ODS是操作数据存储层，贴源层，通常把业务库数据原样同步进来，不做太多清洗。DWD是明细数据层，Data Warehouse Detail，这个层级以业务过程为建模驱动，保存最细粒度的事实数据，一行就是一条业务事件。DWS是汇总数据层，Data Warehouse Summary，按主题、维度和周期做汇总，比如“按天统计每个城市的订单量”。ADS是应用数据层，Application Data Store，面向具体报表或应用需求加工的数据。

面试最常问“ODS、DWD、DWS、ADS怎么划分”，如果你只回答缩写含义，其实只答了一半。更重要的是说出每一层的职责边界：DWD回答“发生了什么”，DWS回答“每天每个纬度的汇总是什么”，ADS回答“报表要用的具体数据集市是什么”。

4.5 CDC与SCD：数据同步与历史变化的两组关键词

CDC是Change Data Capture，变更数据捕获。它的核心是捕获数据库中的增量变更，比如MySQL的binlog、PostgreSQL的WAL，然后把这些变更事件同步到消息队列或数仓。现在的实时数仓架构里，CDC几乎是标配，你用Flink读binlog的过程，本质就是一条CDC管道。

SCD是Slowly Changing Dimension，缓慢变化维。这个概念说的是维度数据变化频率低，比如用户邮箱、收货地址，但变化了以后怎么处理历史事实的归属。Type 1直接覆盖旧值，实现简单但丢历史；Type 2保留历史版本，通过生效时间和失效时间来追踪；Type 3只保留最近两次值。面试题“用户换手机号了，订单事实里的用户维度怎么处理”，就是在考察SCD。

Data Governance（数据治理）和Data Lineage（数据血缘）也是近两年的高频词。数据血缘解决的是“这张报表的数据从哪张表来的、中间经过了几层加工”的问题。排查数据异常的时候，血缘关系图能帮你快速定位到底哪一层加工出了问题。

5. 流处理、批处理与消息队列：实时和离线的分界线上站着哪些词

5.1 Batch与Stream：攒批算 vs 来一条算一条

Batch Processing（批处理）和Stream Processing（流处理）是大数据领域最基本的一组对立概念。批处理的典型代表是Spark离线任务：数据攒到一个时间窗口，或者文件就绪后，一次性统一计算，强调吞吐量。流处理的典型代表是Flink实时任务：数据一条一条来，系统攒够微批就处理（Spark Streaming），或者来一条处理一条（Flink），强调低延迟。

理解这俩词要抓住一个关键点：批处理和流处理没有绝对的优劣。你的业务关心的是“昨天所有订单的总收入”，那批处理足够；你的业务关心的是“当前最近5分钟风控异常率有没有上升”，那得靠流处理。现在很多团队做的是“批流一体”，用同一套代码逻辑兼容两种场景，但概念上，Batch和Stream的边界依然清晰。

5.2 Kafka核心五件套：Topic、Partition、Offset、Consumer Group、Broker

Kafka是消息队列领域最出名的开源系统之一，实时数仓里上下游数据流通的“主动脉”。要理解Kafka，先抓住这几个词。

Broker是Kafka集群中的服务节点，负责接收和存储消息。Topic是消息的分类，就像信件的分类标签。Partition是Topic的分区，把Topic的消息拆成多个子队列，每个分区是一个有序的、不可变的消息日志，分区分布在不同的Broker上，这是Kafka能横向扩展并行的基础。Offset是消息在Partition内的偏移量，也就是序号，消费者通过记录Offset来知道自己读到哪了。Consumer Group是消费组，同一个消费组内的多个消费者共同消费一个Topic，分区分给组内不同的消费者，一条消息在同一个组内只会被一个消费者处理；不同消费组之间互不影响，这种设计让Kafka可以同时喂给多条下游管道。

实际排障时，你看到“某个Consumer Group的Offset lag很高”，说明消费端处理速度跟不上生产端，消息在Kafka里堆积了。这时候不是光重启消费者就完了，而是要去看下游处理瓶颈在哪。

5.3 三种投递语义：最多一次、至少一次、精确一次

投递语义是分布式消息系统中绕不开的一组词：At-most-once（最多一次）、At-least-once（至少一次）、Exactly-once（精确一次）。

At-most-once的意思是消息可能丢，但绝对不会重复，适合那些丢了也无所谓的场景。At-least-once是不丢，但可能重复，这是很多系统的默认选择，因为实现相对简单，下游做幂等就能接受。Exactly-once是严格不丢不重，听上去最完美，实现也最难。

关键认知是，很多所谓的“精确一次”其实是“至少一次+消息去重/幂等写入”配合出来的效果。比如Flink的端到端精确一次，依赖检查点和幂等写入两方面的配合。面试时聊到这里，你如果能主动把这道关系讲透，会比单纯背三个名词加分不少。

5.4 Lambda架构与Kappa架构：实时数仓的两条技术路线

Lambda架构是在实时技术和离线技术边界还没有完全弥合时出现的折中方案：用离线批处理保证最终结果准确，用实时流处理保证低延迟，两条链路各算各的，最后在一个服务层合并结果。Kappa架构则更进一步，主张只保留流处理一条链路，把“批”看作“流的特例”，也就是用流处理引擎统一处理所有数据。

当年我在项目里对比过这两种方案。Lambda架构最大的痛点是维护两套代码，离线任务和实时任务的计算逻辑很容易出现不一致；Kappa架构降低了这种双链路不一致问题，但对流处理引擎的能力和运维水平要求更高。现在批流一体技术逐步成熟，Kappa的声音越来越大，但Lambda架构的历史地位仍然值得理解。

背压（Backpressure）也是流处理中特别重要的词。当下游处理速度跟不上上游生产速度时，系统需要一种机制让上游降速或暂时缓存，这个机制就叫背压。Flink等引擎内置了背压处理机制，当你看到监控面板上出现背压告警时，基本上等于在告诉你：下游有瓶颈，数据快把管道堵住了。

6. OLAP与多维查询：分析场景下的高频术语

6.1 OLTP与OLAP：一个管交易，一个管分析

OLTP（联机事务处理）面向的是日常交易类操作，特点是大量短小、频繁的读写，比如订单下单、库存扣减。OLAP（联机分析处理）面向的是分析类查询，特点是复杂的聚合、扫描海量数据、对响应时间的要求因场景而异。这两类系统在设计哲学上差异巨大：OLTP系统强调ACID事务和低延迟单点操作，OLAP系统强调高吞吐扫描和复杂聚合能力。

做大数据的人很少直接碰OLTP系统，但必须知道它的存在，因为数据来源往往就是OLTP系统的binlog或者业务库快照。而数仓和查询引擎本身，本质上都是在优化OLAP场景下的性能和体验。

6.2 Cube、Rollup、Drill-down、Slice/Dice：多维分析的核心词汇

一旦进入OLAP分析，这些词会频繁出现。Cube是多维数据集，本质是“把数据沿着若干个维度预先聚合好”，比如按时间、城市、商品三个维度组合聚合，这样查询任何组合都能直接命中。

Rollup是上卷，把细粒度数据向粗粒度汇总，日报汇总成月报就叫Rollup。Drill-down是下钻，反过来，从月报细看到日报就是下钻。Slice是切片，固定某个维度的取值，只看这个切片上的数据；Dice是切块，在多个维度上做范围筛选。

理解这组词对理解“预聚合”技术特别有帮助。像Kylin、Druid、ClickHouse这些分析引擎，核心思路都和多维预聚合有关。面试时聊数仓建模，提到“多维分析”却不提Rollup和Drill-down，说服力会打折扣。

6.3 Cardinality、Selectivity：两个让你真正看懂执行计划的词

Cardinality是基数，含义是一个字段去重后的不同值个数。性别字段基数很低，常见只有两个值；用户ID字段基数很高，可能有几千万甚至上亿个值。基数直接影响存储和索引的选择，也直接影响查询引擎的优化策略。

Selectivity是选择率，指查询过滤条件能筛掉多少比例的数据。选择率高意味着数据被压缩得多；选择率低意味着要扫描大量数据。很多执行计划中的Join顺序优化，核心就是在估算每一步的选择率。

这两个词经常出现在执行计划解释和SQL优化中。你看执行计划里写着“cardinality=1000”，表示优化器估计这一步会产生1000行结果。如果你发现实际数据量和预估差了十万八千里，往往就是统计信息不准导致的。

6.4 Materialized View与Index：查询加速的两条老路

Materialized View（物化视图）和Index（索引）都是查询加速手段，但思路不同。物化视图是把查询结果预先算好并存储起来，下次直接读结果，空间换时间。数仓中的大量汇总表，本质上就是手工维护的物化视图。

Index是索引，通过额外的数据结构加速查询定位。大数据引擎里的索引往往不像传统数据库那样单一，有B+树索引、位图索引、倒排索引、跳数索引等不同形态。每种索引都有自己的适用场景：位图索引适合低基数维度列的过滤，倒排索引适合全文检索。优化查询时要先看引擎支持哪些索引类型，再决定怎么建。

7. 性能调优与排障：工作现场最高频的一批英文词

7.1 Shuffle：分布式计算里最贵的那个词

Shuffle在分布式计算里特指数据跨节点重分布的过程。Group By需要把相同Key的数据汇总到同一个节点做聚合，Join需要把相同Key的数据分发到同一节点做关联，这个“重新组织数据跨节点搬移”的动作就是Shuffle。

理解Shuffle要认识到一个现实：分布式计算中最耗时的往往不是计算本身，而是数据搬迁。一次全量Shuffle可能要移动好几个TB的数据，网络IO和磁盘IO开销巨大。所以几乎所有Spark调优技巧，归根结底就是为了减少Shuffle数据量、优化Shuffle过程。如果你听到有人抱怨“这个任务Shuffle太大了”，他不是在说某个动作，而是在说这个环节成了瓶颈。

7.2 Data Skew：数据倾斜是调优第一痛点

Data Skew（数据倾斜）的意思是数据在分布上严重不均。比如按省份统计订单，大省的数据量可能比其他省份多几十倍；按用户分组Join，头部用户的数据量远远大于长尾用户。

数据倾斜带来的典型现象是：某个Reduce任务或某个并行子任务跑了几个小时还没结束，其他任务早就跑完了，整个作业就卡在那个“最重的桶”上。排查方法通常是看执行计划的各个任务耗时分布，找到了那个异常耗时的任务再去定位Key。常用手段包括加随机前缀打散热点Key、广播小表、动态分区优化等。

7.3 Broadcast Join、Sort Merge Join与Spill：Join优化的三个关键词

Join优化是大数据调优的重头戏，三组词需要一起理解。Broadcast Join（广播连接）适用于大表Join小表：把那个小表完整复制一份发送到所有节点上，每个节点本地直接关联，避免Shuffle。它思路简单，但小表必须真小，比如几MB或几十MB级别，否则广播本身就成了负担。

Sort Merge Join是大表Join大表的常见方案：先把两个表按关联Key排序，然后类似归并排序的思维逐段匹配。代价是两边都要做一次Shuffle和排序。还有一种Shuffle Hash Join，适合中等表，通过哈希分区分发数据后，在分区内做哈希连接。实际选哪种，优化器会根据统计信息决定，但如果你能在SQL里通过Hint或调整参数影响这个决策，调优能力就又进了一步。

Spill是指内存不够时，把中间数据写到磁盘。Spark和Flink都有溢出机制，但溢写会引入大量磁盘IO，是性能杀手。所以你会经常听到“调大内存参数，减少Spill次数”这类优化思路。看日志时如果看到“Spilling to disk”字样，基本就能断定内存配置偏小了。

7.4 Watermark、Checkpoint、Savepoint：流处理稳定性的三块基石

Watermark（水位线）是流处理引擎应对乱序数据的关键机制。处理实时数据时，数据到达顺序并不一定跟事件发生顺序完全一致，比如一条1点发生的事件，可能2点才到达。如果系统直接按到达顺序计算，统计就会出错。Watermark可以理解为系统内部的一个判断标记：“我已经看到了时间戳为T的事件，所以我认为时间戳小于T的事件基本都到齐了，可以触发计算了。”它是对乱序数据的容忍度设定。

Checkpoint（检查点）是Flink等流引擎定期保存状态快照的机制。每过一个Checkpoint周期，系统就把算子状态、缓存数据一起存到持久化存储中，一旦作业故障，就从最近一次Checkpoint恢复，不用从头算。Savepoint（保存点）是手动触发的Checkpoint，通常在进行升级、调优、Bug修复前打一个，相当于游戏的“存档点”。

这三个词在流处理排障中极其常见。比如看到“作业重启后从Checkpoint恢复”，就说明它是有状态作业，恢复依赖检查点机制。

7.5 OOM和Data Locality：一虚一实，但都很要命

OOM是Out Of Memory的缩写，内存溢出，每个大数据从业者都绕不开的老朋友。内存参数没调好、数据量预估不足、Shuffle数据量过大，都可能触发OOM。遇到OOM，先别急着加内存，要结合执行计划判断是哪个环节吃掉了内存，是缓存、聚合还是Shuffle缓冲，再去做参数调整。

Data Locality（数据本地性）是一个看似朴素但影响巨大的原则：把计算尽量调度到数据所在的节点上执行，减少跨网络搬移数据。道理很直白，数据存在节点A，你非要把计算任务调度到节点B，光传输数据就得浪费大量时间。分布式计算引擎的调度器都会优先考虑本地性，但本地性不是总能满足，资源不足时会退而求其次。看任务日志时，关注“Locality Level”，能发现不少性能问题。

8. 区分度最高的几组易混词：分清楚比多背词更重要

8.1 Partition与Bucket：经常被当成一回事

Partition（分区）和Bucket（分桶）都是一种数据组织方式，但机制不同。Partition通常按业务字段的值来划分目录，比如按日期分区，每天一个目录，查询时做分区裁剪可以快速跳过无关数据。Bucket按哈希值把数据散到固定数量的文件中，目的是让数据分布更均匀、采样更友好，也能在Join时减少Shuffle。

粗暴记忆：分区是“按值切目录”，分桶是“按哈希散文件”。分区对查询过滤的帮助最直接，分桶对数据均匀性和某些Join场景帮助更大。面试时能把这个区别讲清楚，比会背十个名词都管用。

8.2 DWD与DWS：面试必问的分层对比

DWD是明细层，保留最细粒度、未经汇总的业务事实，一行对应一条真实事件。DWS是在DWD之上做的汇总层，按主题和粒度聚合，比如“按天+城市+商品”的汇总。两者最本质的区别在于是否有聚合动作：DWD面对的是明细事实，DWS面对的是汇总指标。

面试官还喜欢追问“为什么不能直接用DWD出报表”。答案在于性能和分析效率：明细层数据量巨大，报表查询如果每次直接扫明细，计算成本非常高；提炼到DWS层以后，报表查询只扫汇总结果，快得多。

8.3 Shuffle与Broadcast：一个重排，一个复制

Shuffle是把数据按Key重新分布到各个节点，涉及大量跨节点数据传输；Broadcast是把一个小的数据集复制到所有节点，让每个节点都有一份完整拷贝。前者是“我该把每一行数据送到哪里去”，后者是“我把一份数据在每个节点上都放一份”。

从开销看，Shuffle和集群规模、数据量相关，代价呈指数放大；Broadcast基本只受小表大小影响，所以能用Broadcast的场景尽量用Broadcast。但不要把Broadcast当万能药，小表太大时广播的复制开销也扛不住。

8.4 Watermark与Event Time：乱序数据的两种读法

Event Time是事件实际发生的时间，比如用户点击行为在客户端产生时的时间戳；Processing Time是事件到达处理系统的时间。流处理场景你关心的是业务真实发生时间，所以一般以Event Time为准。

Watermark不是时间戳本身，而是系统给出的一种“事件时间进度标记”，本质上是一个带延迟容忍度的判断条件：它告诉引擎“再晚的事件我也认了，超过这个水位的可以触发窗口计算”。很多人刚接触时容易把Watermark等同于“系统当前时间”，其实它描述的是“事件时间坐标系中，数据被认为到齐的截止线”。

8.5 Schema-on-read与Schema-on-write：两种截然相反的建模哲学

Schema-on-write是写数据时就严格校验结构，不符合要求直接拒绝入库，好处是数据质量可控，坏处是灵活性差，改结构成本高。传统数仓是这种思路。

Schema-on-read是先存原始数据，等到读的时候再决定怎么解释和解析它，好处是灵活，新格式老格式都能并存，坏处是数据质量的责任后移到了读数据的人身上。数据湖普遍采用这种思路。

这两种哲学没有绝对优劣，关键是看业务场景对数据质量的容忍度。做监管报表，肯定倾向Schema-on-write；做探索式分析，Schema-on-read更能留出试错空间。

为了便于对比，我把上面八组易混词汇串成一张表，平时自查够了。

9. 词表维护与更新计划：下一批进入清单的候选词

这份清单目前的收录原则很简单：优先收录“工作里天天见、但总记不住”的词，每个词尽量结合真实使用场景来解释，不搞字母序词典。现在整理了约70个高频词，但距离“常用”这个标准还不够，我会持续补充。

下一批我准备更新的方向包括几块：一是SQL与查询语法层面的高频词，比如各类Join类型在优化器中的叫法、窗口函数相关的术语；二是数据湖技术方向的新词，像Hudi、Iceberg、Delta Lake各自的定位差异和核心概念；三是数据质量方向，Data Quality、Data Profiling、数据校验规则相关的词汇；四是面试和评审中经常出现的架构类缩写，比如数据平台、存储计算分离等概念。如果你在工作中也遇到过那种“天天见但说不清”的词，也欢迎在评论区留言，我会整理进后续版本。

最后说一点我个人的体会。整理这份词表的过程，其实也是一个重新理解技术体系的过程。很多词单独看只是缩写和中文翻译，但当你把同一场景下的词汇串在一起，比如“Partition—Offset—Consumer Group—Lag—Backpressure”，你会发现它们描述的是一整条完整的数据链路。读懂了这条链路，很多架构设计和排障思路都会变得顺理成章。记单词本身不是目的，理解背后的数据流转逻辑才是。希望这份清单能帮你少走一些我当年走过的弯路。